rbsp_alignemnt_zero_bit

[leoenc]

We're getting some x264 streams rejected by the decoder, claiming that they have rbsp_alignment_zero_bit = 1, where only rbsp_alignment_zero_bit = 0 is allowed.

Anyone knows how to fix this?

Thanks

[Guest]

What decoder are you talking about? Can you post a sample source stream that invokes this problem?

[leoenc]

Thanks for your reply, neuron2

The decoder is a Tektronix Cerify.

Would the command line be enough?

x264.exe --pass 1 --stats "test.stats" --preset medium --bitrate 1500 --profile high --level 4.1 --keyint 25 --open-gop --ref 3 --mixed-refs --b-pyramid strict --bframes 3 --vbv-bufsize 1500 --vbv-maxrate 6000 --thread-input --threads auto --interlaced --tff --sar 64:45 --nal-hrd cbr --videoformat component --colorprim bt709 --transfer bt709 --colormatrix bt709 --pic-struct --output x264.264 source.avs

x264.exe --pass 2 --stats "test.stats" --preset medium --bitrate 1500 --profile high --level 4.1 --keyint 25 --open-gop --ref 3 --mixed-refs --b-pyramid strict --bframes 3 --vbv-bufsize 1500 --vbv-maxrate 6000 --thread-input --threads auto --interlaced --tff --sar 64:45 --nal-hrd cbr --videoformat component --colorprim bt709 --transfer bt709 --colormatrix bt709 --pic-struct --output x264.264 source.avs

[Guest]

I ask again: Can you post a sample source stream that invokes this problem?

[leoenc]

I will prepare a sample asap

[LoRd_MuldeR]

Found some info, that might be helpful here:
http://mailman.videolan.org/pipermai...er/005169.html

[leoenc]

Source:
http://www.hamburgpromedia.com/hpm-downloads/MXF-Testfiles/IMX_XDCAM_50Mbit_SD.mxf

And output:
http://www.sendspace.com/file/eewy8a

[Guest]

Sorry but I can't process MXF. Can you demux the raw AVC and link that?

[LoRd_MuldeR]

From what I see the "output" is TS. Since x264 doesn't output TS, how did you create that?

[leoenc]

Sure:
http://www.sendspace.com/file/jw381e
(raw MPEG-2, not AVC)

[leoenc]

@LoRd_MuldeR, with a Manzanita multiplexer.

[Guest]

Originally Posted by leoenc

(raw MPEG-2, not AVC)

You're confusing me now. Your original post says you have some AVC streams that are confusing the decoder. So why are you giving us an MPEG2 stream?

Please give us the AVC stream that is not properly decoded. Or please better explain your issue to resolve the confusion. Thank you.

[nevcairiel]

I thought it was pretty clear.
He has this MPEG-2 stream which he transcodes to H.264 using the command lines mentioned earlier.

He provided both the input MPEG-2 and the output H.264 (in TS).

This was his output H.264 stream:
http://www.sendspace.com/file/eewy8a
as linked a few posts above.

[LoRd_MuldeR]

So I think we have three options here:

(1) His H.264 decoder is parsing the stream in the wrong way (rbsp_alignemnt_zero_bit can not be non-zero, see link above)

(2) x264 creates invalid bitstream, which I think is unlikely - but you never know

(3) His TS muxer somehow screwed up the stream or at least produced something his decoder/demuxer doesn't handle right

[nevcairiel]

If its truely syntactically impossible for this to be non-zero, it would seem odd that a validation would check this, unless its an assert that somehow checks its own function for correctness instead of the bitstream.

[leoenc]

Sorry about the confusion, nevcairiel got it right, the AVC stream which is causing the error is here: http://www.sendspace.com/file/eewy8a.

@LoRd_MuldeR, I agree. I'll check with the Manzanita team if option 3 is a possibility.

[LoRd_MuldeR]

For testing purposes: Can you pump the "raw" AVS, exactly as it pops out of x264, into the "Tektronix Cerify" decoder directly and avoid the TS muxing+demuxing altogether?

(If that does work, you know where the problem is probably located)

[leoenc]

Just tried that. The raw x264 stream passes the test.
It is strange, as the stream isn't altered in a way by the muxer. I have demuxed it and compared it to the pre-muxed .264 and they are identical bit for bit.

[leoenc]

Strike my last message, I was looking at the wrong place.
The raw x264 stream DOESN'T pass the test too.

[akupenguin]

As nevcairiel said, this should be syntactically impossible. rbsp_stop_one_bit is defined to be the last 1-bit in a RBSP, and rbsp_alignment_zero_bit are the trailing 0-bits (if any). rbsp_stop_one_bit determines which bit a slice ends at, not the other way around.