James Almer: > On 9/29/2023 1:01 PM, Andreas Rheinhardt wrote: >> We have to write an explicit BlockDuration element (and use >> a BlockGroup instead of a SimpleBlock) in case the Track >> has a DefaultDuration that is inconsistent with the duration >> of the packet. >> >> The matroska-h264-remux test uses a file with coded fields >> where the duration of a Block is the duration of a field, >> not of a frame, therefore this patch writes said BlockDuration >> elements. >> >> (When using a BlockGroup, one has to add ReferenceBlock elements >> to distinguish keyframes from non-keyframes. Unfortunately, >> the AV1 codec mapping [1] requires us to reference all references >> and to really use the real references, which requires a lot of >> effort for basically no gain. When BlockGroups are used with AV1, >> the created files are most likely invalid, both before and after >> this patch, but this patch makes this more likely to happen.) > > AV1 has no fields, and the vast majority of samples will also have fixed > frame duration across the entire coded stream, so i doubt this will make > a difference. > > There's also the fact it's unlikely parsers will care about > ReferenceBlock elements at all to begin with, and instead just have the > decoder handle things relying on the bitstream level information. >
That's why I consider this requirement to be nonsense. In fact, I would only require one thing from the ReferenceBlock elements: If one recursively goes back the ReferenceBlock elements until one has reached a keyframe, then decoding these blocks is sufficient to be able to decode the actually desired block. That way a simple muxer like ours could always reference the preceding block (in case the current packet is not a keyframe) and create a valid stream. - Andreas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
