mkvtoolnix 4.1.1 released - Page 81

moviefan · 5th June 2010, 14:31

Quote:

Originally Posted by rack04

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

Quote:

Originally Posted by moviefan

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

Quote:

Originally Posted by Trahald

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.

Quote:

Originally Posted by Manao

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.

5th June 2010, 15:14	#1604 \| Link
Mosu MKVToolNix author Join Date: Sep 2002 Location: Braunschweig, Germany Posts: 4,304	Apart from a couple of programs being incompatible with it... __________________ Latest MKVToolNix is v87.0 If I ever ask you to upload something, please use my file server.

5th June 2010, 15:31	#1606 \| Link
Mosu MKVToolNix author Join Date: Sep 2002 Location: Braunschweig, Germany Posts: 4,304	Maybe. h264 doesn't have a high priority for me at the moment. Like always: patches are welcome. __________________ Latest MKVToolNix is v87.0 If I ever ask you to upload something, please use my file server.

5th June 2010, 18:46	#1610 \| Link
Mosu MKVToolNix author Join Date: Sep 2002 Location: Braunschweig, Germany Posts: 4,304	I don't know. Try it. __________________ Latest MKVToolNix is v87.0 If I ever ask you to upload something, please use my file server.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

5th June 2010, 14:52	#1603 \| Link
moviefan Registered User Join Date: Jul 2005 Posts: 438	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?

5th June 2010, 15:21	#1605 \| Link
moviefan Registered User Join Date: Jul 2005 Posts: 438	But that's a thing that will be fixed at some point in the future... right?

5th June 2010, 16:40	#1607 \| Link
shon3i BluRay Maniac Join Date: Dec 2005 Posts: 2,419	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.

5th June 2010, 17:52	#1608 \| Link
moviefan Registered User Join Date: Jul 2005 Posts: 438	Ah great, thanks for the comment, shon3i! Without in-depth knowledge of video encoding, I basically thought it should benefit efficiency.

5th June 2010, 18:09	#1609 \| Link
Keiyakusha 契約者 Join Date: Jun 2008 Posts: 1,576	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.