Page 8 of 22 FirstFirst ... 67891018 ... LastLast
Results 106 to 120 of 326

Thread: hdemux: New tystream demuxer

  1. #106
    Join Date
    Nov 2002
    Posts
    1,076

    hdemux 0.13

    Here is a new release of hdemux. Changes:

    Fix PES audio payload size computation
    Relax timestamp validity checking to not kick-in until we've seen a valid video sequence. This should allow audio-only recordings to demux without any user intervention.
    Don't require both a&v output files for processing (allow audio only)
    Fix processing for PAL resolutions and frame rates

  2. #107
    Join Date
    Oct 2003
    Posts
    7
    Quote Originally Posted by bcc
    Actually no, this is not an illegal case. It just sounds that way if you think of it as byte sharing.
    Byte sharing is your phrase, not mine.

    Quote Originally Posted by bcc
    If you look at the way start code processing is defined in iso13818, you must merely have 23 zero bits, and a 1 bit before the start code. The spec doesn't say that you must insert 23 zero bits and a 1 bit before the next start code. In other words there is no requirement that those bits must not overlap the end of an access unit.
    That is absurd. MPEG is a nested containment architecture. Nothing ever overlaps.

    Quote Originally Posted by bcc
    Now, you've shown me some diffs that break the above cases. Even if you're unable to admit that the above cases are "legal" your changes violate the "be liberal in what you accept" rule, and thus break real world streams. You're supposedly fixing another case, but you have not made fully clear the circumstances for that case..
    The problem you have in your code is that you inserted this hack based on a misunderstanding and created the idea of byte sharing to explain it. In fact, as I showed you with your own gdb example, the correct data is in the stream immediately prior to the 0xb77 code. There is no need to resort to such fictions.

    Its clear that nothing I can do will 'show' you these bugs.

    I have given you specifics which you have chosen to ignore.

    I have asked you specific questions about your code, which if answered truthfully, would require you to admit these bugs. You ignored that.

    It is sad that your pride will prevent you from improving the quality of your software which had potential.

    People who have programmed for some time generally learn to deal with their own fallibility. I write code. It generally has bugs, and they must be fixed. This is life. You will do better work when you realize this.

    You will be glad to hear that I will not bother to inform you of other bugs in your software.

  3. #108
    Join Date
    Nov 2002
    Posts
    1,076
    Quote Originally Posted by MelvinPurvis
    Byte sharing is your phrase, not mine.
    Yes, it was a convenient way to explain the special case processing. Not so convenient for explaining how it isn't forbidden from a protocol point of view unfortunately. Sorry to confuse you.
    Quote Originally Posted by MelvinPurvis
    In fact, as I showed you with your own gdb example, the correct data is in the stream immediately prior to the 0xb77 code. There is no need to resort to such fictions.
    Oh right, damn I didn't capture the failure scenario with that gdb output. The real failure case, from NBC (leno), is:
    Code:
    (gdb) p payoffset
    $4 = 14
    (gdb) p paybytes
    $5 = 6142
    (gdb) p *framesize
    $6 = 1536
    (gdb) x/20b &astream.buf[14+paybytes-4]
    0x40013810:     0x84    0xf3    0x70    0x00    0x00    0x00    0x01    0xbd
    0x40013818:     0x18    0x08    0x85    0x80    0x05    0x21    0x52    0x83
    0x40013820:     0xd1    0x87    0x0b    0x77
    (gdb)
    In this case the advertised payload size is again 2 bytes too short (given where the next_start_code is), and the 2 bytes before the next ac3_sync are part of the PES header. Ie you can't pick up the leftover payload from the next PES packet. The special case code kicks in and handles this. With your diffs we fail to write a 1536 byte ac3 frame, and mplex blows up. Clearly worse behavior.

    Anyways, so you're right in that I had a bug here (introduced in more recent changes). And that bug was causing the special case code to go off far too often. Fixed in 0.13 already.
    Quote Originally Posted by MelvinPurvis
    I have asked you specific questions about your code, which if answered truthfully, would require you to admit these bugs. You ignored that.
    Right, I did ignore you after case 1., because your understanding of the code was off track at that point, and thus a waste of my time to counter further.
    Quote Originally Posted by MelvinPurvis
    It is sad that your pride will prevent you from improving the quality of your software which had potential.

    People who have programmed for some time generally learn to deal with their own fallibility. I write code. It generally has bugs, and they must be fixed. This is life. You will do better work when you realize this.
    Spare me the inappropriate lecture, I don't know you from Joe content pirate.
    Nice of you to have introduced yourself with a: Hi I'm sure your code is buggy here, I commented it out without fully understanding, never mind any complete details about the actual problem I'm fixing.
    You come in here with a diff that "fixes" some undisclosed scenario that you have and blows up my test suite, and you expect me to integrate your diff? You should know that's not how things work. Here, in this thankless user "community" your "must be fixed" assumption about bugs do not even hold true. This code is all just for the hell of it.
    Quote Originally Posted by MelvinPurvis
    You will be glad to hear that I will not bother to inform you of other bugs in your software.
    I am. Bugs that are only seen by you, should now matter to me?

  4. #109
    Join Date
    Feb 2004
    Posts
    155
    0.13 compiles on Mac OSX perfect for me. Tested on S2SA, S2DTivo and S1UK test streams. All worked fine. Thanks for the new release again, I really appreciate it bcc.
    Last edited by johnsolo; 12-05-2005 at 04:36 AM.
    TivoTool - Easy OSX Video Extraction

  5. #110
    Join Date
    May 2004
    Posts
    233
    [never mind, may have had a disk full problem]...

  6. #111
    Join Date
    Dec 2005
    Posts
    5

    Problem Demuxing stream Segmentation Fault

    After reading many forums on this server I finially found this thread. THANK YOU. So I got hdemux installed and I first tried running this on a SD recording I did as it said and ran mplex as the command was printed. Playing it on a different computer preduced some weird Video effects. It just had lines through it the entire time they didn't move. I kinda thought it might have been the computer It was playing on since it's been having some problems, so I figured I would try it later on another computer. I then tried to demux an HD stream and got a Segmentation fault with the program.

    Code:
    Version 0.13
    Source is Video.ty
    Video frame size is 1280x1088  - high definition. Frame rate 29.970030
    Video bit rate is 65000000 bits/sec., 65000 Kbit/sec.
    Audio timestamp offset: 625.255556 ms
    AC3 audio at 48kHz, 1536 bytes/sync frame
    Reported datarate 65384 Kbit/sec. (65000+384)
    Proceed with remuxer:
            mplex -f 8 -O 625ms -r 153701 Video.m2a Video.m2v -o <outfile>.mpg
    Warning: Skipping chunk 4098 due to timestamp discontinuity
    Warning: Attempting resync due to repeated time discontinuity
    Segmentation fault
    So I thoguht I would apply some of the Hacks in the message board about this. The one I found that was related was the Audio stream problem I didn't know if it would fix it or not but Hey give it a shot. So this is the result from that.

    Code:
    zoop@yours /files2 $ hdemux -i Video.ty -v Video.m2v -a Video.m2a
    Version 0.13
    Source is Video.ty
    Video frame size is 1280x1088  - high definition. Frame rate 29.970030
    Video bit rate is 65000000 bits/sec., 65000 Kbit/sec.
    Audio timestamp offset: 625.255556 ms
    AC3 audio at 48kHz, 1536 bytes/sync frame
    Reported datarate 65384 Kbit/sec. (65000+384)
    Proceed with remuxer:
            mplex -f 8 -O 625ms -r 153701 Video.m2a Video.m2v -o <outfile>.mpg
    Segmentation fault
    That didn't help might might give you some info on where it's failing. not sure what the problem might be but this is a 64bit proc, and it's installed on a system compiled as 64bit (Gentoo). I'm happy to install any debugging software to help figure this out or if you have any info that could help. I tried an strace frist as that's what I normally use, but I didn't have it installed. So I'll give that a whoorl later. Also I was going to try this on a Non 64 bit system too to see if that made a difference. I'll let you know.

    Thanks again.

    OK did an strace I guess a little useless, but here yea go. Shoot or maybe not I didn't see that priority set crap. that's gotta be it. I'll get that cleaned out of the MFS tools.

    Code:
    read(3, "\21\0\377\377\0\0O *\255X\f\0\0\0j\21\353\371\305\7\365"..., 131072) = 131072
    write(5, "\vwH\7\0340\341\347\354\354\222@\0\3\377o\355KP0!\241\n"..., 1536) = 1536
    write(5, "\vw\33\343\0340\341\347\354\354\222@\0\3\377o\355KP@Aa"..., 1536) = 1536
    write(5, "\vw<)\0340\341\347\354\354\222@\0\3\377o\355KP\20\21\221"..., 1536) = 1536
    write(4, "\0\0\1\0\2\327\377\373\200\0\0\1\265\206_\373]\200\0\0"..., 60084) = 60084
    write(4, "\0\0\1\0\2_\377\373\270\0\0\1\265\206V[\335\200\0\0\1\262"..., 35276) = 35276
    write(4, "\0\0\1\0\2\237\377\373\270\0\0\1\265\206V[\337\200\0\0"..., 33704) = 33704
    read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 131072) = 131072
    read(3, "Priority set...\n\365Fz\275\0\0\0\2\0\2\0\0\0\17\377\4"..., 131072) = 131072
    read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\37\0\16\200\0\0O *\255"..., 131072) = 131072
    read(3, "/\346\326\361\240\206\0\255\345\234\215\3527\372\260\20"..., 131072) = 131072
    --- SIGSEGV (Segmentation fault) @ 0 (0) ---
    +++ killed by SIGSEGV +++
    Last edited by zooppoop; 12-24-2005 at 12:20 PM.

  7. #112
    Join Date
    Nov 2002
    Posts
    1,076
    Quote Originally Posted by zooppoop
    read(3, "Priority set...\n\365Fz\275\0\0\0\2\0\2\0\0\0\17\377\4"..., 131072)
    This shows that you're using an ancient version of the mfs_export utility to extract your recording, and that program is corrupting your stream. I wonder where you got it. I recommend you replace the mfs_export program you installed with the one here
    http://www.dealdatabase.com/forum/sh...ad.php?t=39487
    You'll have to either re-extract the recording, or use something like unpriority to repair: http://www.dealdatabase.com/forum/sh...&postcount=646
    For debugging under linux, gdb's backtrace command will show where the error occured. For example: gdb hdemux core.11354<ret>backtrace<ret>

  8. #113
    Join Date
    Dec 2005
    Posts
    5
    Kewl that was it. Yea don't know where I got those tools from. I belive it was one of these forms. Would be nice if this was a wiki or something that could have one document that could be updated. Took quite a while to go through the forms. Thanks for your help, it's much appreciated.

  9. #114
    Join Date
    Dec 2005
    Posts
    5

    Problems with Mplex after hdemux

    I'm running into a problem with some of my streams, this is the error that I get from mplex.

    Code:
    zoop@yours /files2 $ mplex -f 8 -O -10169ms -r 23076 m2a m2v -o Video.mpg
       INFO: [mplex] mplex version 1.6.2 (2.2.3 $Date: 2004/01/13 20:45:26 $)
       INFO: [mplex] File m2a looks like an AC3 Audio stream.
       INFO: [mplex] File m2v looks like an MPEG Video stream.
       INFO: [mplex] Video stream 0: profile 8 selected - ignoring non-standard options!
       INFO: [mplex] Found 1 audio streams and 1 video streams
       INFO: [mplex] Selecting dvdauthor DVD output profile
       INFO: [mplex] Multiplexing video program stream!
       INFO: [mplex] Scanning for header info: AC3 Audio stream 00 (m2a)
       INFO: [mplex] AC3 frame size = 1536
    
       INFO: [mplex] AC3 AUDIO STREAM:
       INFO: [mplex] Bit rate       :    49152 bytes/sec (384 kbit/sec)
       INFO: [mplex] Frequency      :     48000 Hz
       INFO: [mplex] Scanning for header info: Video stream e0 (m2v)
       INFO: [mplex] VIDEO STREAM: e0
       INFO: [mplex] Frame width     : 480
       INFO: [mplex] Frame height    : 480
       INFO: [mplex] Aspect ratio    : 4:3 display
       INFO: [mplex] Picture rate    : 29.970 frames/sec
       INFO: [mplex] Bit rate        : 15000000 bits/sec
       INFO: [mplex] Vbv buffer size : 229376 bytes
       INFO: [mplex] CSPF            : 0
       INFO: [mplex] SYSTEMS/PROGRAM stream:
       INFO: [mplex] rough-guess multiplexed stream data rate    : 15710000
       INFO: [mplex] target data-rate specified               : 23076000
       INFO: [mplex] Setting specified specified data rate: 23076000
       INFO: [mplex] Run-in Sectors = 698 Video delay = 44602 Audio delay = 968821
       INFO: [mplex] New sequence commences...
       INFO: [mplex] Audio bd: buf=  16384 frame=000000 sector=00000000
       INFO: [mplex] Video e0: buf=1900544 frame=000000 sector=00000000
    **ERROR: [mplex] Can't find next AC3 frame: @ 231936 we have fffd - broken bit-stream?
    This one I get right away in another stream that I d/l'ed it converted most of the video then had a failure. I have successfully converted other streams from this tivo. Any help would be appreciated. I know this isn't your software just thought you could give me some direction to trouble shoot it.

    Thanks agian.

  10. #115
    Join Date
    Nov 2002
    Posts
    1,076
    Yes, a wiki *could* be nice. But, there is already one over at alt.org, and it suffers from wiki spam, and so would have to be actively administrated. Maintaining 3rd party how-to guides on this stuff has proven rather thankless, and usually the guide gets abandoned and becomes stale.
    Code:
    **ERROR: [mplex] Can't find next AC3 frame: @ 231936 we have fffd - broken bit-stream?
    That fffd looks suspiciously like an mpeg2 audio sync code. I would suspect your audio stream switched from ac3 to mpeg2 mid stream, and mplex is not able to handle that. Maybe you can play back the audio stream with xine and check whether it is flip flopping (check alt-i)

  11. #116
    Join Date
    Nov 2005
    Posts
    44

    error: Cannot fit Audio buffer

    Folks, any ideas on how to troubleshoot the following error?

    $> hdemux -i show.ty+ -v show.m2v -a show.m2a
    Video frame size is 1280x720 - high definition. Frame rate 59.940060
    Video bit rate is 19000000 bits/sec., 19000 Kbit/sec.
    Audio timestamp offset: 389.522222 ms
    AC3 audio at 48kHz, 1792 bytes/sync frame
    Recovered AC3 sync, offset 152, chunk 1
    Reported datarate 19448 Kbit/sec. (19000+448)
    Proceed with remuxer:
    mplex -f 8 -O 389ms -r 29172 ws2005.m2a ws2005.m2v -o <outfile>.mpg
    Warning: Tossing AC3 audio frame with bad sync data. Chunk 943 length 1840
    Warning: Tossing AC3 audio frame with bad sync data. Chunk 1965 length 1840
    Warning: Tossing AC3 audio frame with bad sync data. Chunk 4576 length 1840
    Warning: Tossing AC3 audio frame with bad sync data. Chunk 4848 length 1840
    Warning: Skipping chunk 5760 due to timestamp discontinuity
    Warning: Attempting resync due to repeated time discontinuity
    Warning: Skipping chunk 5826 due to timestamp discontinuity
    Warning: Attempting resync due to repeated time discontinuity
    error: Cannot fit Audio buffer, size 473313 offset 4928

  12. #117
    Join Date
    Nov 2005
    Posts
    44
    I got past my hdemux error using a different version of the mfs_* tools (unified ones). But my mplex command is now failing with the following error:

    **ERROR: [mplex] Can't find next AC3 frame: @ 3596544 we have 886b - broken bit-stream?

    Very similar to what zooppoop posted previously. The full output here:

    $ mplex -f 8 -O 389ms -r 29172 show.m2a show.m2v -o f:/show.mpg
    INFO: [mplex] mplex version 1.8.0 (2.2.4 $Date: 2005/08/28 17:50:54 $)
    INFO: [mplex] File show.m2a looks like an AC3 Audio stream.
    INFO: [mplex] File show.m2v looks like an MPEG Video stream.
    INFO: [mplex] Video stream 0: profile 8 selected - ignoring non-standard options!
    INFO: [mplex] Found 1 audio streams and 1 video streams
    INFO: [mplex] Selecting dvdauthor DVD output profile
    INFO: [mplex] Multiplexing video program stream!
    INFO: [mplex] Scanning for header info: AC3 Audio stream 00 (show.m2a)
    INFO: [mplex] AC3 frame size = 1792
    INFO: [mplex] AC3 AUDIO STREAM:
    INFO: [mplex] Bit rate : 57344 bytes/sec (448 kbit/sec)
    INFO: [mplex] Frequency : 48000 Hz
    INFO: [mplex] Scanning for header info: Video stream e0 (show.m2v)
    INFO: [mplex] VIDEO STREAM: e0
    INFO: [mplex] Frame width : 1280
    INFO: [mplex] Frame height : 720
    INFO: [mplex] Aspect ratio : 16:9 display
    INFO: [mplex] Picture rate : 59.940 frames/sec
    INFO: [mplex] Bit rate : 19000000 bits/sec
    INFO: [mplex] Vbv buffer size : 999424 bytes
    INFO: [mplex] CSPF : 0
    INFO: [mplex] SYSTEMS/PROGRAM stream:
    INFO: [mplex] rough-guess multiplexed stream data rate : 19858896
    INFO: [mplex] target data-rate specified : 29172000
    INFO: [mplex] Setting specified specified data rate: 29172000
    INFO: [mplex] Run-in Sectors = 89 Video delay = 39508 Audio delay = 9003
    INFO: [mplex] New sequence commences...
    INFO: [mplex] Audio bd: buf= 0 frame=000000 sector=00000000
    INFO: [mplex] Video e0: buf= 0 frame=000000 sector=00000000
    **ERROR: [mplex] Can't find next AC3 frame: @ 3596544 we have 886b - broken bit-stream?


    Quote Originally Posted by bigcat400
    Folks, any ideas on how to troubleshoot the following error?

    $> hdemux -i show.ty+ -v show.m2v -a show.m2a
    Video frame size is 1280x720 - high definition. Frame rate 59.940060
    Video bit rate is 19000000 bits/sec., 19000 Kbit/sec.
    Audio timestamp offset: 389.522222 ms
    AC3 audio at 48kHz, 1792 bytes/sync frame
    Recovered AC3 sync, offset 152, chunk 1
    Reported datarate 19448 Kbit/sec. (19000+448)
    Proceed with remuxer:
    mplex -f 8 -O 389ms -r 29172 ws2005.m2a ws2005.m2v -o <outfile>.mpg
    Warning: Tossing AC3 audio frame with bad sync data. Chunk 943 length 1840
    Warning: Tossing AC3 audio frame with bad sync data. Chunk 1965 length 1840
    Warning: Tossing AC3 audio frame with bad sync data. Chunk 4576 length 1840
    Warning: Tossing AC3 audio frame with bad sync data. Chunk 4848 length 1840
    Warning: Skipping chunk 5760 due to timestamp discontinuity
    Warning: Attempting resync due to repeated time discontinuity
    Warning: Skipping chunk 5826 due to timestamp discontinuity
    Warning: Attempting resync due to repeated time discontinuity
    error: Cannot fit Audio buffer, size 473313 offset 4928

  13. #118
    Join Date
    Nov 2002
    Posts
    1,076
    bigcat400,
    Code:
    **ERROR: [mplex] Can't find next AC3 frame: @ 3596544 we have 886b - broken bit-stream?
    So it looks like that error is about 60 seconds into your audio stream. Perhaps it is a real audio glitch in your source. Can you play back the source .ty with no glitch at 62 seconds? What about the demultiplexed audio stream? Can you play it back by itself OK?

  14. #119
    Join Date
    Nov 2005
    Posts
    44
    Thanks for your response bcc.

    Yes this .ty+ was from HD OTA which has glitches every once in a while (due to my antenna probably). I was able to play the full audio stream with GoldWave so at least I knew it was complete, with some issues along the way I guess.

    Anyway I was able to put the audio and video back together (mpeg) using TMPEnc and created my DVD.

    I've realized that with HD OTA streams the thing is to try different tools until finding something that will work .

    I have used hdemux/mplex successfully with many HD extractions. But, yesterday for example I was working with one that neither mplex nor tmpenc liked, they both aborted claiming audio issues... but then I tried tytool and worked great (ty+ directly to mpeg) . It'd be nice to always use one tool, but oh well, as long as something works we should be ok.

    I always use mfs_ftp to extract (ty+ files).

    Quote Originally Posted by bcc
    bigcat400,
    Code:
    **ERROR: [mplex] Can't find next AC3 frame: @ 3596544 we have 886b - broken bit-stream?
    So it looks like that error is about 60 seconds into your audio stream. Perhaps it is a real audio glitch in your source. Can you play back the source .ty with no glitch at 62 seconds? What about the demultiplexed audio stream? Can you play it back by itself OK?

  15. #120
    Join Date
    Jul 2005
    Posts
    1
    Hello,

    I'm trying to downloads hdmux and it keeps asking me to login, accepting my credentials, then asking me to login again. Is there something I'm missing? Is there anywhere else I can download hdmux?

    edit: Nevermind. I switched from Safari to Firefox and it downloaded fine.

    Thanks,

    --Rick
    Last edited by ricka; 05-15-2006 at 08:21 PM.

Posting Permissions

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