> Also, when dealing with a super frame, to get other values like pixel > format and frame dimensions we'd have to make sure to parse the visible > frame, and if it's an inter frame also keep the reference frames around > to take said values from them.
Could we avoid the challenges around reference and invisible frame by only doing this parsing for key frames? IIUC these properties would only be expected to change at the GOP boundary. > I don't think that change should be reverted, at least not without > further changes. Otherwise, WebM specific extradata (the one defined in > https://www.webmproject.org/docs/container) could make its way to other > containers. We'd have to add checks in supported muxers to ignore it > instead. Sorry, I forgot just how different webm is in this regard. We do have some separate parsing code for the CodecPrivate, but you're also correct that it is often not set. > Also, what muxer currently writes that to CodecPrivate? I've looked at > Youtube samples and none has it. Maybe libWebM https://github.com/webmproject/libwebm/blob/01c1d1d76f139345c442bfc8e61b4e1cba809059/common/hdr_util.h#L31 YouTube isn't doing it yet for VP9. But I think its required with AV1 content, so maybe we'll see it with new VP9 encodes too down the road. Parsing the frame is definitely our best bet. Chris _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
