Question about elementary AVC streams

[eXtremeDevil]

So, I have two .avc streams, extracted from a BD, they are both a remux, no reencode whatsoever, the number of frames are the same, and comparing side by side the frames are virtually the same, no differences at all, same source, same result.

But for some reason, the hashes of the files are different. I was wondering, why could that be?

Thanks in advance!

[Selur]

So, I have two .avc streams, extracted from a BD, they are both a remux,..
not clear what you did in detail, so my guesses are:

a. If there were encoding involved: Multithreading,.. encode the same source with x264 and use '--non-deterministic' and the outputs will not be identical.

b. If I remember correctly, even without encoding, muxing into mkv and extracting with different mkvtoolnix versions might result in non-identical outputs due to header handling,...

Cu Selur

[eXtremeDevil]

not clear what you did in detail, so my guesses are:

a. If there were encoding involved: Multithreading,.. encode the same source with x264 and use '--non-deterministic' and the outputs will not be identical.

b. If I remember correctly, even without encoding, muxing into mkv and extracting with different mkvtoolnix versions might result in non-identical outputs due to header handling,...

Cu Selur

Hi, thanks for the answers, let me clarify:

a. No encoding, both should be just a remux.

b. I extracted the avc streams them with the same mkvtoolnix versions, but maybe they were muxed into mkvs before with different mkvtoolnix versions, would that affect the result? I guess it shouldn't...

It's not like I want to achieve something here, I'm just curious.

[Selur]

Yes, different version or muxing setting could alter which headers got stripped.

[Z2697]

Yes, different version or muxing setting could alter which headers got stripped.

...or duplicated

I recommend YUView (https://github.com/IENT/YUView) for "inspect the inside of the bitstream" and many other features it has.

[eXtremeDevil]

Yes, different version or muxing setting could alter which headers got stripped.

I get that, but if I demux the elementary streams, shouldn't they be the same again??

[Selur]

No, afaik only the actual video data would be the same, none essential headers might be changed.

[eXtremeDevil]

Sorry, but I still don't get it. Isnt the "the actual video data" the extracted avc stream? Are you saying that the .avc file has headers inside that cannot be removed/ignored in order to create a hash for only video data?

[Selur]

SEI (supplemental enhancement information) messages do not affect the core decoding process, but can indicate how the video is recommended to be post-processed or displayed. So parts of SEI messages can be dropped, modified,... (repeated more or less frequent) when extracting the video stream.
So if you have a source stream that had the (complete) SEI data only in the first IDR frame but upon extraction is added to each IDR frame the extracted stream would be more 'robust' (to cutting/damage) than the original, while the data for the core decoding process hasn't changeg.
=> you might want to read up on SEI

[eXtremeDevil]

You mean that, even with the same extraction tool, the elementary avc stream could have different SEI/IDR data inside?

[SeeMoreDigital]

It's a shame there's not a tool for adjusting the properties of AVC and HEVC elementary streams like 'Re-stream' has been able to do for many years ago with MPEG-2 elementary streams.

[eXtremeDevil]

It's a shame there's not a tool for adjusting the properties of AVC and HEVC elementary streams like 'Re-stream' which was available many years ago for adjusting the properties of MPEG-2 elementary streams.Is that a yes to my last question? xD

[Z2697]

SPS and PPS can also be duplicated.

[ivanb]

You can try to open both files in the analyzer like https://media-analyzer.pro/. Perhaps you might spot some differences right away. Once you find them, it’ll be easier to fix them if needed.

[Selur]

You mean that, even with the same extraction tool, the elementary avc stream could have different SEI/IDR data inside?
If you use different version or setting in the tool: yes, you can have different SEI data.

[eXtremeDevil]

If you use different version or setting in the tool: yes, you can have different SEI data.

No no, I used the exact same tool and options for extracting both .avc out of both. mkv.

[eXtremeDevil]

You can try to open both files in the analyzer like https://media-analyzer.pro/. Perhaps you might spot some differences right away. Once you find them, it’ll be easier to fix them if needed.

Great tool, but I can't see the differences side by sides, there's too many data :(

EDIT

I actually managed to find differences, seems like one of the streams have a few of these:

00324107b7AVC End Of Sequence #31789

Is there a way to edit them or something similar, remove that data (or whatever it is), just to check again both files and see if they have the same hash?

If not, in any case, which stream would be better, if I had to keep one?

Thanks guys!

[Z2697]

Is there a way to edit them or something similar, remove that data (or whatever it is), just to check again both files and see if they have the same hash?

FFmpeg bitstream filter "filter_units".
ffmpeg -i bfd.264 -bsf:v filter_units=pass_types=1-5 -c copy out.264
NALU type id 1-5 in AVC is VCL. The result file is not decodeable due to the lack of SPS and PPS, it only contains all of the encoded frames' data.

[ivanb]

ffmpeg -i bfd.264 -bsf:v filter_units=pass_types=1-5 out.264

I guess for this particular case we would need something like
ffmpeg -i bfd.264 -bsf:v filter_units=remove_types=10 out.264 to filter out EOS NALUs

[eXtremeDevil]

I tried both commands, and the results of the "different" avc files are identical, same hash. Can we then say the videos are virtually the same? Since one has those "End Of Sequence" data, which video could be better to keep? I don't quite understand what "End Of Sequence" data do, and if it's better or irrelevant to have it.

EDIT

BTW, why the result file is 3gb and the .avc file is 28gb?

[ivanb]

> I don't quite understand what "End Of Sequence" data do
It basically tells the decoder to flush any frames it might have buffered. The same thing happens at the end of a file anyway, so "End Of Sequence" doesn’t really make much of a difference.

[ivanb]

> BTW, why the result file is 3gb and the .avc file is 28gb?
Maybe besides EOS there are also some additional padding or something

[eXtremeDevil]

Additional padding? We're talking about a BD remux, the video should not be less than about 30gb...

[eXtremeDevil]

> I don't quite understand what "End Of Sequence" data do
It basically tells the decoder to flush any frames it might have buffered. The same thing happens at the end of a file anyway, so "End Of Sequence" doesn’t really make much of a difference.

And it makes sense to have it in the middle of the video?

[Z2697]

Oops, you should include "-c copy" in the command otherwise it's actually re-encoding, I forgot to put it in the exmaple.

Check out this wikipedia page or H.264 standard / "recommendation" for more information about NALU types
https://en.wikipedia.org/wiki/Network_Abstraction_Layer

[eXtremeDevil]

OK, this is fun, when added the "-c copy" to the command, I got this:

[h264 @ 000001bdbfe4f5c0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 28923 >= 28923
[h264 @ 000001bdbfe4f5c0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 154047 >= 154047

Same indexes on both files, BTW.

And both result files have the same hash :) so again, they should have the exact same video/frames inside.

What is that about DTS?? I don't have any audio, is a pure video .avc stream!

I've read that link, but it doesn't say much about the extra "End Of Sequence" data found in one of my two streams. I mean, I get what it does, but I don't quite understand if there would be a performance difference between both, if one have them and the other does not. Maybe that data is there to "mark" the end of a chapter of the BD? Would that make that stream more "efficient" or more "complete" somehow?

[Emulgator]

A decoding time stamp (DTS) is a field that may be present in a PES packet header that indicates the time that an access unit is decoded in the system target decoder.

DTS - Decode Time Stamp

The Decode Time Stamp (DTS) indicates the time at which an access unit should be instantaneously removed from the receiver buffer and decoded.
It differs from the Presentation Time Stamp (PTS) only when picture reordering is used for B pictures.
If DTS is used, PTS must also be provided in the bit stream.

PTS (or DTS) is entered in the bitstream at intervals not exceeding 700ms.
ATSC further constrains PTS (or DTS) to be inserted at the beginning of each access unit.
In your stream 2 packets have the same DTS, so together with the other findings this stream can be considered buggy.

[eXtremeDevil]

Oh OK, I still don't know why those errors appears, but thanks for the explanation haha.

[ivanb]

I don't quite understand if there would be a performance difference between both, if one have them and the other does not. Maybe that data is there to "mark" the end of a chapter of the BD? Would that make that stream more "efficient" or more "complete" somehow?

I highly doubt that the presence or absence of EOS units would affect decoding performance. For example, the x264 encoder doesn’t produce such NAL units at all, but that doesn’t prevent players from correctly playing back such streams.

[eXtremeDevil]

So, in conclusion, one video has multiple EOS and the other does not, this is probably due to the original extraction method from the BD, it doesn't affect anything, and pretty much that seems to be the only differences between the files.

Did I miss something, or that's all?

[Z2697]

The essential NALU types are VCL, SPS, PPS and (rarely) SEI.

VCL is the actual frames' data, SPS and PPS and (rarely) SEI ensures the parameters the decoder uses are correct (as the name suggests, Parameter Set), and some less essential SEI provide extra metadata or flags to the picture or stream. (Because SEI have many types...)

Now since the two VCLs you extracrted are the same, and the original files are decodable, you know the SPS and PPS should be correct, so these two files are essentailly the same.

At the end of day, feel free to decode the whole stream and compare, you know, calculate SSIM with FFmpeg filter_complex or else.

[eXtremeDevil]

And what NALU type is those "End Of Sequence"?

[Z2697]

And what NALU type is those "End Of Sequence"?

10 End of sequence
end_of_seq_rbsp( )

11 End of stream
end_of_stream_rbsp( )

[eXtremeDevil]

10 End of sequence
end_of_seq_rbsp( )

11 End of stream
end_of_stream_rbsp( )

So, they are not VCL, SPS, PPS or SEI, as I thought. So, the presence or absence of those End Of Sequence on one of the videos is probably due to the original extraction method from the BD, right? Or could they have different sources? It doesn't affect at all, right? I wonder why they are there if they change nothing...

[Z2697]

So, they are not VCL, SPS, PPS or SEI, as I thought. So, the presence or absence of those End Of Sequence on one of the videos is probably due to the original extraction method from the BD, right? Or could they have different sources? It doesn't affect at all, right? I wonder why they are there if they change nothing...

Yeah, they are just their own types, and they should be 99.9% doesn't matter, just don't want to be too absolute, I guess there's still some reason for including them in the specification.

As for how they got there, I think we can't be sure unless we have the original Blu-ray files.

[eXtremeDevil]

So they should be from the original BD or from the extraction method, I guess, but since they doesn't seem to do anything, I don't know why someone put them there xD

[benwaggoner]

So they should be from the original BD or from the extraction method, I guess, but since they doesn't seem to do anything, I don't know why someone put them there xD
Any chance they align with chapter or title boundaries?

[eXtremeDevil]

Any chance they align with chapter or title boundaries?

That's my suspicions, but all I see is this:

00d351f2b4AVC End Of Sequence #139252
start_code_prefix 00 00 01, len = 3
forbidden_zero_bit 0
nal_ref_idc 0
nal_unit_type 10 (0xA), 'End Of Sequence'
rbsp_trailing_bits not found

No idea of the timestamp.


EDIT

In any case, if that was the case... what's the point? Why would any demuxer or BD authoring tool / studio put those "End Of Sequence" bits? You guys told me they have no real purpose /effect...