Log in

View Full Version : mkvtoolnix 4.1.1 released

Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 [33]
moviefan
5th June 2010, 14:31
If your goal is to output a compliant Blu-ray Disc structure, which from what I've read is the only reason to use open-gop, then you shouldn't be muxing to MKV. AFAIK, once you mux the raw 264 stream generated by x264 to MKV you lose NAL-HRD. If you use the MKV file to generate the Blu-ray Disc structure then txMuxeR assumes VBV values to generate NAL-HRD if no information exists.

I thought open-gop gives more efficiency (probably only slightly) so that file sizes decrease. I do not intend to encode Blu-ray compliant streams.



I ran my file (encoded with the latest rev of x264 with open-gop and muxed with mkvmerge) through mkvalidator and it returns a huge amount of messages like: "ERR0B1: Block at -1234567890 track #4 is not a keyframe". Does this have to do with open-gop and does it help to fix the issue?
rack04
5th June 2010, 14:47
I thought open-gop gives more efficiency (probably only slightly) so that file sizes decrease. I do not intend to encode Blu-ray compliant streams.

Here are a couple quotes from this (http://forum.doom9.org/showthread.php?t=148004) thread.

This patch really is only useful if you have small gops (ie bluray) . my tests were at min keyint of 12. This patch is not for your production encodes as it is experimental. Do not create any binaries with this patch that may be in automatic upgrading scripts to protect the innocent.

As Trahald already said, this patch is useful mostly when you use a low max keyint interval. The reason for its usefulness is that, without the patch, x264 considers that key frames are IDR, which are special picture types that prevents the previous picture type to be a B frame. So, even if x264 would have wanted to use a B frame, if the following frame must be a key frame because of max keyint, without the patch the B will be transformed into a P frame, which isn't as good.
moviefan
5th June 2010, 14:52
The first one about the patch being experimental is OK. I know about this but I've not found any drawbacks so for me it seems fine. About its gain in situations with longer GOPs, I sure there's not such a big difference between encoding with and without open-gop if keyframe intervals range around 250 but there isn't any disadvantage to use open-gop is there?
Mosu
5th June 2010, 15:14
Apart from a couple of programs being incompatible with it...
moviefan
5th June 2010, 15:21
But that's a thing that will be fixed at some point in the future... right?
Mosu
5th June 2010, 15:31
Maybe. h264 doesn't have a high priority for me at the moment. Like always: patches are welcome.
shon3i
5th June 2010, 16:40
OpenGOP will be soon merged to GIT, we done some testing that show everything pass. Anyway OpenGOP help in all situations, even default x264 settings (250,25) so should be used in normal encodes, not only in Blu-Ray ones.
moviefan
5th June 2010, 17:52
Ah great, thanks for the comment, shon3i! Without in-depth knowledge of video encoding, I basically thought it should benefit efficiency.
Keiyakusha
5th June 2010, 18:09
If we will do encoding with opengop to mkv (in x264), everything will be fine? No changes should be made to the x264's muxer?
The resulting mkv will be remuxed fine with mkvmerge? (afaik mmg uses some king of pass-through for mkv->mkv muxing, no?)
If there is some changes need to be made to x264's muxer, maybe they can be ported to mkvmerge?

P.S.
So much questions, sorry for that.
Mosu
5th June 2010, 18:46
I don't know. Try it.