On 10/29/2018 7:33 PM, Chris Cunningham wrote: > Thanks for pushing the profile part. Turns out I'm also interested in > pixel format, but I follow your comments about dropping the rest of > patch. With the code as-is, how busted are we when parsing a super > frame. Does it correctly grab the profile of the first frame?
It grabs the profile from the first frame in a super frame, which should be safe since even if it's an invisible one it's not really going to be different than the visible one, i think. 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. > > Chrome actually has a fairly complete VP9 parser > <https://cs.chromium.org/chromium/src/media/filters/vp9_parser.cc?rcl=adf255ef1da95255174643a6c1482e4305f877fd&l=478> > but the CodecPrivate is no longer set in extradata for VP9 so we don't > (AFAIK) have easy access to the frame header. Would you be open to > surfacing codec private via extradata (reverting this change > <http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225548.html>)? 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. Also, what muxer currently writes that to CodecPrivate? I've looked at Youtube samples and none has it. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel