HandBrake

Oops. I now that I think about it, it was the ffmpeg code that calculates the duration that way. Bumping NDURSAMPLES to 32 did the trick as far as the duration problem goes. For now, I guess I'll have to write up a script that encodes the segments independently and splice them together with mkvmerge...

Oooo, so close. But no cigar. Dropping 1 frame at several of the boundaries. Causes a video glitch in playback. Missing IDR frame kind of thing. 10:45:53] sync: video time didn't advance - dropped 1 frames (delta 740 ms, current 61629832, next 61633586, dur 3754) [10:45:53] sync: video time didn't a...

Gave the new patch a try. It helped, but still has occasional problems. At the beginning of the 5th segment, I got another "video time went backwards" and it dropped about 1200 frames. Upon playback audio continues playing cleanly, and I get a frozen video frame for what appears to be abou...

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 bou...

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. ...

Very cool. I'll give it some testing.

I did that other patch because I got the impression that it would take you longer to crank that out. I thought it would make a good compromise till the real work could be done. I should have known better.

I took a crack at implementing multiplexed truehd/ac3 handling per van's suggestion. Everything is self-contained in stream.c. The stream is marked as an ac3 stream. The truehd protions are dropped. Also, there seem to be a significant number of blu-rays that have digicipher streams(stream id 0x80)....

Van, thanks for taking the time to give such a detailed critique. I agree with it all. I've very glad to here that you had planned on separating TS demuxing from PS. I don't know how closely you looked at my code changes to handle the interleaved truehd/ac3. What I was trying to do was move as much ...

Found another glitch in m2ts parsing. It's trying to interpret a DigiCypher PID as ac3 audio. deca52 eventually crashes badly on the digicypher data. In stream.c, we mark pretty much all PIDS that we don't handle an "unknown", even when the type is known such as digicypher. Then we expect ...

What kind of cpu do you have? I just tried on 2 systems running Ubuntu 8.10. one is a core 2 duo and the other it a core 2 quad. One is running i686 and the other x86_64. Both get the following caps: x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 Perhaps you have an amd cpu or an o...

This looks to be the same problem as http://forum.handbrake.fr/viewtopic.php ... 2ts#p42026
Van has a pending solution.

For any interested parties, here's a patch for live preview for the linux gui. You also need the patch I posted previously for libhb. It uses gstreamer. So you need all the appropriate plugins (base, good, ugly, bad, ffmpeg). http://handbrake.fr/pastebin/pastebin.php?show=196 http://www.stebbins.biz...

Here's a tweak to van's patch to make hb_state.param.working.progress accurate during live preview encodes.
It takes pts_to_stop into account when calculating the number of frames to expect in sync.c
http://handbrake.fr/pastebin/pastebin.php?show=189

If your going to do much video encoding, you really need to educate yourself first. See the big pink box at the top of the forum page. If you don't you'll probably end up re-encoding multiple time's as you learn new things. This particular problem is covered either here http://trac.handbrake.fr/wiki...

And that brings us back around to my original suggestion. You'ld be better off just doing a few encodings to get a feel for quality vs. file size vs. resolution tradeoffs, then winging it from there. The "sweet" spot is going to depend on several things. One of the bigger factors is the co...

Quality is not equivalent to resolution. Video compression is *lossy*. That means that the algorithm will throw away detail in order to achieve certain constraints (like bitrate). (And "detail" is not exactly equivalent to resolution either by the way). When you set a certain bitrate, thos...

locking to 700Mb something has to give, which is the resolution Your assumption is wrong here. Resolution isn't the only thing that *has* to give. The other alternative is that the quality gets reduced, and that's what handbrake does. In order to keep a certain quality and reduce the resolution ins...

Basically, your asking for a "tool" that will analyse the overall quality of the encoded video for multiple output resolutions. Quality is a tricky metric to measure and you would have to include in that metric both the artifacts from encoding and quality loss due to the reduced resolution...

The patch I posted has a lot of things mixed together, some of which probably need more thought. So I'm splitting things up so they can be review and worked on independently. Here are the 2 that I'm really most interested in. Interleaved truhd/ac3 parsing http://handbrake.fr/pastebin/pastebin.php?sh...

Van, where did you read that PPS and SPS mark random access points. When I add these nal unit types to isIframe(), I get previews that are messy. Note I get the same messy previews when the "i-frame" match is on nal unit type 1 with a slice type of 2 4 or 7. I addressed this issue in my ot...

I've got an idea about this. ffmpeg's decoder is complaining that the stream is referencing a picture parameter set that doesn't exist. These are delivered in the stream before the slice. The slice references them. Our transport decoder always skips data in the stream until it sees the first i-frame...

What Rodney is saying is that handbrake does not produce files that are suitable for input into iMovie. This is talked about in the faq and there are some suggestions there.

Van, thanks for having a look. I can stand in line and wait my turn for you to catch up. That extra complexity I added to demuxmpeg doesn't have to be there. I added it to reduce code duplication. The stream code needs to access the stream id extension to distinguish ac3 from truehd. There's no exis...

While working on getting blu-ray encoding working, I've run across a few more glitches with transport stream processing. 1. when the program list in the pat contains a network PID, the pmt parsing code doesn't properly skip this entry. this causes attempts to interpret a pat as a pmt since the pid e...

Given the information in my last post, I've come up with a better way of handling the ac-3/TrueHD interleaved stream. If the stream id is 0x83, I check the format_identifier from the registration descriptor for the stream. If it is "AC-3", then it's ac-3/truehd, and the id assigned is the ...