--aud?

[AntiJw]

Hey,
I wonder, what is the x264-option --aud used for?
I don't understand the x264-help info about it: "--aud
Use access unit delimiters".

Does it got something to do with standalone-compatibility?
I also noticed MeGUI uses that option for x264-encoding lately.

EDIT: Thanks G.Bouvigne and S.Sablin

[Gabriel_Bouvigne]

It adds some elements within the stream in order to ease parsing of the stream. Please note that this might be useful only if you are using raw h.264 streams (like .264 files), but AUD are usually removed when the file is multiplexed within a container (mpeg2-ts, mp4, mkv,...).

[Sergey A. Sablin]

Please note that this might be useful only if you are using raw h.264 streams (like .264 files), but AUD are usually removed when the file is multiplexed within a container (mpeg2-ts, mp4, mkv,...).

IIRC AUD is mandatory for TS muxing and can't be removed at least for this container.
For other containers which store H.264 NAL units this will break NAL HRD if both AUD and HRD were put by encoder.

[Guest]

For other containers which store H.264 NAL units this will break NAL HRD if both AUD and HRD were put by encoder. Can you please elaborate on this? How does it break and why?

[Sergey A. Sablin]

Can you please elaborate on this? How does it break and why?

in NAL HRD model encoder counts all bits including all headers, SEI messages, AUDs, everything it outputs - and given this calculates decoder' buffer state. Once you remove something from the stream (or add) - model is no longer correct as real number of bits which decoder will receive is now different from what encoder was expected. So sooner or later accumulated error will change buffer state that much so it'll break compliance.

[Guest]

I still don't follow you. Why would AUDs be any different than SEIs, for example?

[Sergey A. Sablin]

I still don't follow you. Why would AUDs be any different than SEIs, for example?

AUD is no different to SEI - that's the deal. They both go to CPB in NAL HRD, and if encoder puts AUD or SEI into bitstream, it counts bits for both into NAL HRD model. And once somebody remove any part of bitstream which shall go to CPB - he breaks HRD compliance which encoder tried to achieve, as decoder will receive different number of bits and thus CPB states will be different from what encoder calculated.

...
[edit of edit]forget about previous edit - mixed nal-hrd patch with something else[/edit of edit]

[Gabriel_Bouvigne]

IIRC AUD is mandatory for TS muxing and can't be removed at least for this container.

Thanks, my knowledge is a bit lacking regarding TS and PS


For other containers which store H.264 NAL units this will break NAL HRD if both AUD and HRD were put by encoder.
Ah, the nightmare of having to put NAL HRD information when you don't know what transport will be used (and what it will do to your stream)...

[Sergey A. Sablin]

Ah, the nightmare of having to put NAL HRD information when you don't know what transport will be used (and what it will do to your stream)...

There is VCL HRD for this matter, where only video coded data + filler are counted. Obviously if filler is not allowed, then CBR can't be muxed to this container and stream should be encoded as VBR.

[Dark Shikari]

There is VCL HRD for this matter, where only video coded data + filler are counted. Obviously if filler is not allowed, then CBR can't be muxed to this container and stream should be encoded as VBR.It sounds like VCL HRD would be a much more practical approach for use in x264, as NAL HRD requires an inextricable linkage with the transport used--which x264 of course has no way of knowing or interfacing with.

[akupenguin]

Obviously if filler is not allowed, then CBR can't be muxed to this container and stream should be encoded as VBR.
How can a container not allow filler? You can append filler bytes to any NAL you want, it's not a separate syntax element that the container has to know about.

[Sergey A. Sablin]

How can a container not allow filler? You can append filler bytes to any NAL you want, it's not a separate syntax element that the container has to know about.

you probably speaking of cabac_zero_word's, cause this is the only "filler" which might be added to VCL NAL. Standard fillers - Filler SEI and Filler Data NALU are obviously separate syntax elements.
However I'm not sure that adding more cabac_zero_word's than required by parsing process is strictly compliant. But practically this of course will do the trick.

[Manao]

Even if it is compliant, it seems to be allowed only for CABAC. What about CAVLC ?