open-gop patch for x264 (committed)

[sneaker_ger]

Originally Posted by LoRd_MuldeR

Well, if the I-Frame is a Non-IDR I-Frame, then we have to decode the frames before the I-Frame, as the None-IDR I-Frame doesn't flush the reference buffer and thus frames after the I-Frame (in display order) may reference to frames before the I-Frame. But that's nothing specific to OpenGOP. The same applies to all Non-IDR I-Frames, even when OpenGOP is not used.

That's why it was bugging me that some devs were talking about reading the previous gop as something special why from my understanding it was necessary all along.

Originally Posted by LoRd_MuldeR

Also, in my understanding, a GOP goes from an IDR-Frame to an IDR-Frame, i.e. None-IDR I-Frames are not GOP delimiters. Not sure what the "official" definition is here.

Then open-gop wouldn't really be open gop, would it? But ok, the term might just be a "tradition" coming from older standards.

[Guest]

There are cases other than IDR where you do not have to go back a GOP. E.g.:

Recovery point SEI
non-IDR I picture
...

The sample posted earlier in the thread places recovery points before the non-IDR I pictures as above. In fact, in the very first post Trahald states that is what the "open GOP" patch does. I do not consider those to be open GOPs! For me a GOP is open if you have to go back a GOP to decode without errors.

The decision whether to go back is quite tricky. I see it like this (coding order):

IDR starts closed GOP.
RPS+I starts closed GOP.
I P B starts closed GOP. (This is the controversial one. Theoretically not so, but practically yes.)
I B P starts open GOP.

For me a GOP is just a sequence of pictures starting with IDR/I and it is seekable without going back if it is closed.

[sneaker_ger]

Originally Posted by neuron2

The decision whether to go back is quite tricky. I see it like this (coding order):

RPS+I starts closed GOP.

But the open-gop option of x264 uses recovery points on the open gops, so if you seek to a b-frame in a gop that starts with RPS+I we will still need information from the previous gop.

This hole debate is a real mess when we do not have a common opinion on the definition of a gop (and/or forget to mention whether we're talking coded or display order). Is there any definition in the h.264 standard?

[Guest]

Originally Posted by sneaker_ger

But the open-gop option of x264 uses recovery points on the open gops, so if you seek to a b-frame in a gop that starts with RPS+I we will still need information from the previous gop.

The RPS declares that you do not need previous information.

[Trahald]

blurays definition of open-gop says this
1. the first frame in decode order must be a non-idr i frame and the frames that proceed it in display order are allowed to reference forward and backward. these frames cannot be correctly decoded during a random seek and are skipped.
2. frames after the non idr i-frame in display order must NOT reference frames prior to the i-frame in display order.

recovery points are not mentioned. (and there is plenty of room for a 'shall not' if that were the intent)

the frames in 1. are always b frames in x264. p frames that preceed the i-frame in display order (yet follow in coded order) are allowed but x264 doesnt generate p-frames in this condition. if b-frame decision decides that b-frames arent needed following the iframe in display order, that gop will essentially be closed (again based on blurays definition). The command open gop is ignored when --bframes == none.



blurays definition of open gop is the only one i know of. I modeled its behavior after AVC blurays.

[RBO]

Originally Posted by Audionut

I'm going to go way out on a unfounded claim, and say it's an open-gop related issue.

FYI, h264 open-GOPs feature withing MP4 (MPEG4 part 12 spec) is not specified enough. There have been propositions at MPEG in 2010 to provide a solution. The problem comes from the collusion between RAP and sync points.

The compliant solution is implemented in GPAC. However it is not usable as seeking big files takes a lot of time. x264 (with GPAC MP4 support) marks all key frames as sync points, which is less compliant but practically allows you to seek within the file flawlessly.

Practically, I would advise you to create your MP4 files using x264, and then adding your audio with:

mp4box -add my_audio.xxx my_h264_muxed_with_x264.mp4

We are waiting the normalization decision from MPEG.

Romain

[kypec]

Originally Posted by RBO

Practically, I would advise you to create your MP4 files using x264, and then adding your audio with:

mp4box -add my_audio.xxx my_h264_muxed_with_x264.mp4

Are you suggesting to create raw H264 streams in x264? Because that's what I was doing since I started to work with x264 CLI.

[kieranrk]

Originally Posted by RBO

The compliant solution is implemented in GPAC. However it is not usable as seeking big files takes a lot of time. x264 (with GPAC MP4 support) marks all key frames as sync points, which is less compliant but practically allows you to seek within the file flawlessly.

Why should the container care about the underlying gop structure? Surely it's a job for the decoder to ignore b-frames from the previous gop.

[VFR maniac]

According to 14496-15, sync samples are just IDR-pictures, so treating a I-picture as a sync sample is out-of-spec.
(Current x264's mp4 muxer module sets key-frame (IDR or I) as sync sample.)
I think it is the better solution using sdtp box (Independent and Disposable Samples Box) for marking random access point when Open-GOP is available.

[Selur]

Are you suggesting to create raw H264 streams in x264?

No, he suggested to:
1st use x264s internal muxer to pack the videostream into a .mp4 file
2nd use mp4box to add additional streams

----

*snip*

Cu Selur

[jethro]

Originally Posted by RBO

Practically, I would advise you to create your MP4 files using x264, and then adding your audio with:

mp4box -add my_audio.xxx my_h264_muxed_with_x264.mp4

Romain

But it does not work, unless I'm doing something wrong.

>mp4box -add The Best of Science Fiction
Movies_audio.mp4  The Best of Science Fiction Movies_video.mp4

Error - 2 input names specified, please check usage

EDIT:
SOLVED
DOH, it needed quotes around filenames...