HandBrake

I just bought WALL-E and was forced to figure out another piece of the puzzle. Type 0x86 is DTS-HD which is another multiplexed form with substream id 0x71 as the DTS component. It also looks like this disk doesn't have any random access points in the TS so rather than wait 15 minutes while scan sea...

This is due to a bug in the ffmpeg vc1 decoder - it occasionally returns a bogus packet size (> 50MB) that messes up HB's memory allocator. I've committed a work-around as r1925.

For "Initial frames missing from FLV source", I think the problem is a bug in the ffmpeg vp6f codec. Almost the the flv's I have drop the first second or so of video because the codec thinks it's missing the initial keyframe. I don't have the vp6 spec but I think the initial state of the c...

Van and John: Should the keyframe issue decoding the beginning of h.264 streams be postponed until 0.9.4? Seems like you're still hashing out the details... If John's theory SPS/PPS theory is right, and I strongly suspect it is, a fix is in the patch mentioned here . There's one small piece to fini...

750ms is about how much audio lags video in typical HD content. What's probably happening is that since we zap the first video timestamp to re-sync on the audio, we lose information on the relative offset between audio & video at the splice then end up correcting the next time we see a video tim...

Hmm. I made two changes to help the problem. One was to send up PES packets as soon as we hit the end rather than waiting to the start of the next packet of that media stream. This reduces the window of vulnerability. The other was to explicitly detect the reordering & smash the timestamps so it...

I have a question about discontinuities. On some blu-rays (e.g. Ratatouille), the title is divided into several segments (an m2ts file per segment). Each m2ts has its own time base. If I try to concatenate the segments together, hb gets "video time went backwards" errors at the segment bo...

After looking over your patch, I've got a couple comments. When you lookup the stream extension id, your assuming it's at pes[[es[8]+8]. This works only if the pes extension doesn't have any extra bytes. The extension has a length field and could have additional bytes after the stream extension id....

Looks like we were working in parallel John. I tried to fold your older code into my new ts stream architecture. Thanks to your great detective work it seems to handle type 0x83 just fine and so far has converted Iron Man & Crystal Skull with no problem. I haven't finished the performance work b...

It's a known problem. Both VC1 and H.264 have issues finding good restart points when you jump to a random point (which is what happens when constructing previews). This is what results in the missing or corrupt preview images. We're working on this but it's hard to fix.

The fix looks good to me. Sorry about the bug. While cut & pasting my test script I forgot to change an extension so I tested avi twice & theora zero times -- naturally I screwed up the testing of the code I'd broken

John, Sorry for the long delay in replying. The reason I'm uncomfortable with the scope of this change has to do with a future direction possibility that you couldn't know about (because it's not done & I haven't talked about it). Let me give that background: When awk wrote the original stream c...

Committed. Also committed a DTS patch that I hope will fix the problems in topics 7092, 7329 & part of 7506/7497. Turned out there were two more bugs in our DCA decoder that appeared after doing the one line fix in stream.c. I'll try to get the AAC auto rate stuff in tomorrow. I've also got a th...

atticus1214 - try r1904 or later. It may the fix the aborts you're seeing which I believe are due to DTS/DCA decoding problems.

Note that this won't have any effect on the issues northy is seeing - those are not DTS related and so far I haven't had any luck reproducing them.

refulgentis - try r1904. I fixed three different DTS bugs. With luck this one will work for you.

A patch to make HB use the correct size for the U & V components of a raw video frame is at http://handbrake.fr/pastebin/pastebin.php?show=200 . Basically, all calls to hb_buffer_init to allocate a raw video frame have been replaced by a call to hb_video_buffer_init( width, height ) which correc...

For "odd dimensions and chroma rounding", I've got a patch that allocates the video buffer correctly (round up to even, same as ffmpeg does) so HB will work for odd dimensions. But x264 aborts because the standard *requires* even dimensions for YUV420 video (there's no way even to specify ...

Serious Concern: I do not want this implementation to replace true frame accurate point to point, now with our fantastic universal file input, it is more important than ever to allow HB to really have the ability to encode what the user really wants to encode. I don't think there's any incompatibil...

Possibly the problem with the wrong stopping time is the stupid way I'm using output frame counts as the stopping condition & feeding it back from sync to reader. Since there can be a lot of audio in the pipeline between them you can get funny output that's much longer than you've requested. Aft...

Sorry dynaflash. I know you've been waiting patiently for this forever. The hard part of A-to-B is constructing an index for frame accurate positioning of the start point. For live preview I suspect you don't really need that & only want the encoding to start at exactly the same frame as the pre...

The crash you show has DTS audio, not AC-3, and the symptoms you report sound like the bug that was fixed by r1827 . So this might be fixed in the next snapshot. EDIT- Sorry, I wasn't reading carefully. 1827 was DTS in m2ts, not mkv. The DTS in mkv problem is happening because HB uses the ffmpeg DTS...

Got it. Here's what a blow up of the right side looks like: http://img296.imageshack.us/img296/8459/preview1bj9.jpg They've added a taper to the luma, probably to minimize DCT ringing at the edge. The rightmost 4 columns are black, the 5th has been attenuated 60% and the 6th 20%. When the dark thres...

Brilliant!!! That's almost certainly the problem. The spec says a PPS or SPS marks a random access point so I'll change the h.264 isIframe test to include them.

Nice detective work John & it's good to see others digging into the stream stuff. But I'm a little concerned about the scope of the changes. Titer provided an elegant & very fast PS demuxer in libhb/demuxmpeg. I'd like to convince myself that it's absolutely necessary to push the complexity ...

I don't know whether I screwed up the bounding box logic or the thresholds. I suspect that a short clip won't manifest the problem since the decision is made on the statistics of a bunch of frames. But if you could tar up the /tmp/hb.NNN/* directory that contains the preview images from this title I...