Page 12 of 70 FirstFirst ... 210111213142262 ... LastLast
Results 166 to 180 of 1041

Thread: MUX'ing, VSplit, and MPG2 files.

  1. #166
    Join Date
    Jan 2002
    Posts
    4,809

    At long last VSplit #13a...

    Alright folks here it is. A major release for the first time in a very long time.

    This is VSplit #13 test a (VSplit13a.exe) for the Windows PC only at this point. I apologize to everyone that is using Linux and what not at this point but relax. This is just a test phase to try out a some new code en mass. Soon to come will be a true release of VSplit #14.

    This release includes a boat load of fixes. This should solve a great many problems. Namely:

    1- The -1x4 stuff should be working correctly now.
    2- A lot of timestamp issues have been fixed.
    3- A new byte-count method of checking things has been added.

    However havine said that what I need looked at is the new byte-count method code. Primarily what I am looking for is differences. Something the old code found that the new one does not and vice versa. So read over what is below and if you find something during testing that does not line up let me know...

    This new code runs before the standard existing checks on things via the PTS values. The output from this code for clarity sake is shown with 5 repeating numbers:

    11111 == BAD! There is NO audio or video data in the chunk. his would normally stop things but for now processing continues...

    33333 == The video data does not line up. These are rare... Processing does not stop here.

    55555 ==The audio data does not line up. These are not so rare. In a DTivo stream you will see a few. In an SATivo stream you will see tons. Processing does not stop here.

    77777 == Processing DOES stop here. Or at least it will. For right now it continues on.

    Now a set of examples:

    1- This is the classic data is out-of-bounds... First you see the new bytecount code... And you see the OOB packet pretty much as it used to be. The key here is that it ends in a 77777 flag. So the new code things it is OOB and in looking at what follows so does the old code...

    Code:
    33333 -> old Vid ByteCount = 28 E1 50 to 2A BC 60
    33333 -> new Vid ByteCount = 5C 45 48 to 5E 2B A4
    33333 -> NOT ALIGNED on the Video... It is an OOB chunk!
    55555 -> old Aud ByteCount = 33 C2 E8 to 33 E3 B8
    55555 -> new Aud ByteCount = 6F C9 B8 to 6F E0 90
    55555 -> NOT ALIGNED on the Audio... It is an OOB chunk!
    
    77777 -> Yep. We are out of here! Neither lined up!
    
    Found an OOB packet... The Video Diff is: 00:14:20.844
    getBoth: old Vid ByteCount = 28 E1 50 to 2A BC 60
    -1x4: We are NOT aligned on the Video... It is an OOB chunk!
    We got one that is just to far away!
    getBoth: old Vid ByteCount = 28 E1 50 to 2A BC 60
    getBoth: old Aud ByteCount = 33 C2 E8 to 33 E3 B8
    Found an OOB packet... The Audio Diff is: 00:14:20.522
    Is it in sequence??? It is OFF by exactly 35855.083333 frames.
    Nope... Not in sequence... Skipping it...
    2- Somthing that doesn't line up perfectly but is close enough... Again, first the new lines and then the same old ones. Since these are not different, I.e. they both find it to be good data. This is nothing to worry about.

    Code:
    33333 -> old Vid ByteCount = 2A E1 80 to 2C C5 84
    33333 -> new Vid ByteCount = 2C C5 88 to 2E A4 7C
    33333 -> NOT ALIGNED on the Video... It is an OOB chunk!
    
    Found an OOB packet... The Audio Diff is: 00:00:00.024
    It is in sequence... Everything is fine...
    3- There is no audio or video data in the chunk... Again, first the new lines and then the same old ones. We start with the 11111 flag so it should stop here. But for now we fall through. Then the we get the -1x4 older code (with some new lines) that show that it is an out of sequence chunk. They are the same so no worries.

    Code:
    11111 -> Chunk contains neither audio nor video data. Stop here...
    
    33333 -> There is no video data to compare...
    55555 -> There is no audio data to compare...
    
    -1x4 - No Audio or Video timestamps in this chunk... Checking byte counts...
    -1x4:	 New Vid ByteCount =  0  0  0 to  0  0  0
    -1x4:	 New Aud ByteCount =  0  0  0 to  0  0  0
    -1x4:	 Old Vid ByteCount = 6A 26 58 to 6B F7 A8
    -1x4:	 Old Aud ByteCount = 6D D8 4C to 6D FF B4
    -1x4 - The chunk contains neither audio nor video data... It is an OOB chunk!
    Nope... Not in sequence... Skipping it...
    That's pretty much it.

    --jdiner

  2. #167
    Join Date
    Feb 2002
    Posts
    54
    Got 26 semi random running in -n mode.

    I'll get back to you with results.

    Just a note: I've already seen a 77777 in a file that I know vsplit13 didn't die on. Is this signifigant?

  3. #168
    Join Date
    Feb 2002
    Posts
    116
    I've run the code against five .ty files so far, all DD5.1 shows from Showtime. It looks like all the errors are flagged by both the old and new code, except for one instance:

    First Video PTS: 00:02:11.065
    ......... 100....55555 -> There is no audio data to compare...
    ..... 200......... 300......... 400......... 500

    Not sure if that's expected or not but it's the only discrepancy I see.

    I do see several 77777 errors per file -- does that mean these files won't be muxable since vsplit will stop when it hits them?

  4. #169
    Join Date
    Jan 2002
    Posts
    4,809
    Originally posted by Kythorn
    Got 26 semi random running in -n mode.

    I'll get back to you with results.

    Just a note: I've already seen a 77777 in a file that I know vsplit13 didn't die on. Is this signifigant?
    No. Sorry I must not have been quite clear enough. It does not terminate the file. It marks a single chunk that had a truly out-of-bound status.

    --jdiner

  5. #170
    Join Date
    Jan 2002
    Posts
    4,809
    Originally posted by koreth
    I've run the code against five .ty files so far, all DD5.1 shows from Showtime. It looks like all the errors are flagged by both the old and new code, except for one instance:

    First Video PTS: 00:02:11.065
    ......... 100....55555 -> There is no audio data to compare...
    ..... 200......... 300......... 400......... 500

    Not sure if that's expected or not but it's the only discrepancy I see.

    I do see several 77777 errors per file -- does that mean these files won't be muxable since vsplit will stop when it hits them?
    No. Check the last message from me. The 77777 should just match up with a "not in sequence" message from the old code. If you have a 77777 without the other then it is significant.

    A single 55555 line is nothing worry about. It is actually good news since it means that I am now more accurately trapping things.

    --jdiner

  6. #171
    Join Date
    Feb 2002
    Posts
    116
    For the record, the 77777 errors I've seen do match up with errors from the old code so it looks like all is well.

    I've now checked all the files I most urgently want to archive to DVD and they all look good -- aside from that 55555 message the old and new code flag all the same errors.
    Last edited by koreth; 09-19-2002 at 09:29 PM.

  7. #172
    Join Date
    Jan 2002
    Posts
    4,809
    One more request for peoples. For those that had TyStream files that had termporal fixup errors, or whatever they were exactly with Spruce UP, please try them with this new version. By and large they should be fixed.

    --jdiner

  8. #173
    Join Date
    Feb 2002
    Posts
    54
    Here's the most amusing log output I've seen in a while.

    Note: this spans 3 FSIDs, but is reported as 0m in TyTool.

    I've watched this entire episode in the past, and just went through the entire thing again at the lowest level of fast forward, and it's there, beginning to end.

    Damn, the tivo's good at error correction.

  9. #174
    Join Date
    Feb 2002
    Posts
    54
    Ok, so I guess I can't actually attach that without compressing it first. Here's attempt two.

  10. #175
    Join Date
    Feb 2002
    Posts
    54
    Ran through 26 tystreams. Aside from the 1 fun log (which is really beyond hope I guess) I posted, all looked fairly well. In every case I saw, the old and new code matched up, with the exception of some of the 55555's already mentioned.

    I did catch a few
    ### The Vid Body is off! 20 50 50 -> 31 B4 50 diff == 0xFFEE9C00 (-1139712)'s

    hanging out by themselves, I don't recall seeing these before.

  11. #176
    Join Date
    Feb 2002
    Posts
    285
    Got me an error! Here's the log output:

    Processing 'bsg_ll2.ty': (10 chunks per tick)
    Detected Tivo Type: Standalone
    Detected Audio Stream Type: MPEG Layer II
    Final standardAudioSize = 880

    Final standardFrameLength = 864

    Final standardAudioDiff = 3240 or 00:00:00.036
    First Video PTS: 01:14:46.801
    ......... 100......... 200......... 300......... 400......... 500
    ......... 600......... 700......... 800......... 900......... 1000
    ......... 1100......... 1200......... 1300.### The Vid Body is off! 20 56 40 -> 25 7B DC diff == 0xFFFADA64 (-337308)
    $$$ The Aud Body is off! 2D 1C 40 -> 2D 84 E0 diff == 0xFFFF9760 (-26784)

    Found an OOB packet... The Video Diff is: 01:22:53.458
    getBoth: old Vid ByteCount = 23 59 78 to 25 31 C4
    -1x4: We are aligned on the Video so it is good!!!
    Found an OOB packet... The Audio Diff is: 00:00:00.036
    It is in sequence... Everything is fine...

    Found an OOB packet... The Video Diff is: 01:22:53.124
    getBoth: old Vid ByteCount = 25 31 C4 to 21 DF B8
    -1x4: We are aligned on the Video so it is good!!!
    We got one that is just to far away!
    getBoth: old Vid ByteCount = 25 31 C4 to 21 DF B8
    getBoth: old Aud ByteCount = 2D 69 E0 to 2D 26 60
    Found an OOB packet... The Audio Diff is: 01:22:53.400
    Is it in sequence??? It is OFF by exactly 138150.000000 frames.
    Nope... Not in sequence... Skipping it...


    33333 -> old Vid ByteCount = 25 31 C4 to 21 DF B8
    33333 -> new Vid ByteCount = 23 BB EC to 25 93 F0
    33333 -> NOT ALIGNED on the Video... It is an OOB chunk!
    55555 -> old Aud ByteCount = 2D 69 E0 to 2D 26 60
    55555 -> new Aud ByteCount = 2D 44 C0 to 2D 66 54
    55555 -> NOT ALIGNED on the Audio... It is an OOB chunk!

    77777 -> Yep. We are out of here! Neither lined up!


    Found an OOB packet... The Video Diff is: 01:22:52.790
    getBoth: old Vid ByteCount = 25 31 C4 to 21 DF B8
    -1x4: We are NOT aligned on the Video... It is an OOB chunk!
    We got one that is just to far away!
    getBoth: old Vid ByteCount = 25 31 C4 to 21 DF B8
    getBoth: old Aud ByteCount = 2D 69 E0 to 2D 26 60
    Found an OOB packet... The Audio Diff is: 01:22:53.076
    Is it in sequence??? It is OFF by exactly 138141.000000 frames.
    Nope... Not in sequence... Skipping it...


    33333 -> old Vid ByteCount = 25 31 C4 to 21 DF B8
    33333 -> new Vid ByteCount = 25 93 F0 to 27 5D 8C
    33333 -> NOT ALIGNED on the Video... It is an OOB chunk!
    55555 -> old Aud ByteCount = 2D 69 E0 to 2D 26 60
    55555 -> new Aud ByteCount = 2D 66 54 to 2D 95 C0
    55555 -> NOT ALIGNED on the Audio... It is an OOB chunk!

    77777 -> Yep. We are out of here! Neither lined up!
    etc. btw, I'm using Linux/Wine to run the test. I had sent you a sample of this stream a while back (it failed with vsplit13 as well), but you may not have it around anymore. I had used dd to split it before. I can determine the chunk where the problem starts. How much data do you want, what do you want me to use to split it with (is dd fine, or should I use your tysplit tool?), and where should I send it? This problem occurs with about half of my Battlestar Galactica streams, so I can get multiple samples if you need them.

    - Stealth Dave
    - Stealth Dave

  12. #177
    Join Date
    Dec 2001
    Location
    Seattle, WA
    Posts
    174
    Here is the only one that was truly different for me. I'm attaching the whole thing zipped. The funny part is the line that starts ###.

    Also, I'm seeing a lot of these "55555 -> There is no audio data to compare". I assume they are normal?


    Code:
    .........  100.........  200.........
    
    33333 -> old Vid ByteCount = 2E 33 94 to 30  F F0
    33333 -> new Vid ByteCount = 23 44 10 to 25 20 9C
    33333 -> NOT ALIGNED on the Video... It is an OOB chunk!
    Found an OOB packet... The Audio Diff is: 00:00:00.036
    It is in sequence... Everything is fine...
      300.........  400.........  500
    .........  600.........  700.........  800.........  900......... 1000
    ......... 1100......... 1200......... 1300.......55555 -> There is no audio data to compare...
    .. 1400......... 1500
    ......... 1600......... 1700......... 1800......... 1900......... 2000
    ......... 2100......... 2200......... 2300......... 2400......... 2500
    ......... 2600......... 2700......... 2800..55555 -> There is no audio data to compare...
    ....... 290055555 -> There is no audio data to compare...
    ......... 3000
    ......... 3100....55555 -> There is no audio data to compare...
    ..... 3200........55555 -> There is no audio data to compare...
    . 3300......... 3400......... 3500
    ......... 3600......... 3700......... 3800......... 3900......... 4000
    ......... 4100......... 4200......... 4300......... 4400......... 4500
    ......... 4600......... 470055555 -> There is no audio data to compare...
    ....55555 -> There is no audio data to compare...
    ..... 4800.....### The Vid Body is off! 23 44 18 -> 30  F F8  diff == 0xFFF33420 (-838624)
    .... 4900......... 5000
    ......... 5100......... 5200......... 5300......... 5400......... 5500
    ....55555 -> There is no audio data to compare...
    ..... 5600......... 5700......... 5800......... 5900......... 6000
    ......... 6100......... 6200......... 6300......... 6400......... 6500
    ......... 6600......... 6700......... 6800....55555 -> There is no audio data to compare...
    ..... 6900......... 7000
    55555 -> There is no audio data to compare...
    ......... 7100......55555 -> There is no audio data to compare...
    ... 7200.55555 -> There is no audio data to compare...
    ........ 7300......... 7400......... 7500
    ......... 7600......... 7700......... 7800......... 7900......... 8000
    ......... 8100.........

  13. #178
    Join Date
    Jan 2002
    Posts
    4,809
    Originally posted by Kythorn
    Ok, so I guess I can't actually attach that without compressing it first. Here's attempt two.
    Wow. That disintegrated nicely. I would like a copy of that one. Actually just the piece where it is on and then gets off so badly.

    Use the TyFileSplit program to grab just that section. Please start 40 or so chunks before it fails, and then go 100-150 chunks in length from that point. That will great a file of roughly 20-30 meg in size. Hopefully you have a decent network link and can upload it to me.

    --jdiner

  14. #179
    Join Date
    Jan 2002
    Posts
    4,809
    Originally posted by Kythorn

    I did catch a few
    ### The Vid Body is off! 20 50 50 -> 31 B4 50 diff == 0xFFEE9C00 (-1139712)'s

    hanging out by themselves, I don't recall seeing these before.
    Darn. I did not mention these because I was hoping that no one would see them. It means that my "perfect" byte count code isn't. These never show up for me any more but it did for you here. I would like a clip of this one as well. So I can figure out what is going on and how to catch it more carefully.

    Best guess at this point this. One of the reset values for the byte counting is 20 50 40. This clip reset but then had add-ons before the first real byte-count after the reset was seen to lock onto. This is not that big a deal it is just frustrating as it is yet another case I have never seen.

    --jdiner

  15. #180
    Join Date
    Jan 2002
    Posts
    4,809
    Originally posted by stealthdave

    etc. btw, I'm using Linux/Wine to run the test. I had sent you a sample of this stream a while back (it failed with vsplit13 as well), but you may not have it around anymore. I had used dd to split it before. I can determine the chunk where the problem starts. How much data do you want, what do you want me to use to split it with (is dd fine, or should I use your tysplit tool?), and where should I send it? This problem occurs with about half of my Battlestar Galactica streams, so I can get multiple samples if you need them.
    I still have it. But the one I have works. This is a related but somehow different error.

    Please split it with the TyFileSplit. Getting clips that are split on the wrong boundry just makes them tedious for me to fix. Then upload it to the same ftp site as before.

    --jdiner

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •