Question about elementary AVC streams

[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]

Originally Posted by 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.

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]

Originally Posted by eXtremeDevil

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]

Originally Posted by eXtremeDevil

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]

Originally Posted by Z2697

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]

Originally Posted by eXtremeDevil

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]

Originally Posted by 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

Any chance they align with chapter or title boundaries?