GNOME Bugzilla – Bug 728324
h264parse: wait for resolution to be known before pushing
Last modified: 2018-11-03 13:22:23 UTC
Created attachment 274433 [details] [review] wait to get resolution before pushing buffers This is something done a few years back for 0.10, and which may be useful to upstream.
Created attachment 274434 [details] [review] delay setting passthrough mode when waiting to known resolution
Created attachment 274435 [details] [review] add num-ref-frames in caps
Comment on attachment 274435 [details] [review] add num-ref-frames in caps I don't think this should be in the caps directly.
Do you mean you'd rather this goes in a GstMeta ? This value would be useful in knowing the max latency for a video, so should be "global", and thus on caps. AFAIK, GstMeta is per buffer. Or did you have another place in mind for this ?
Isn't the value in the SPS already? Which is in the caps already for AVC in form of the codec_data, and is in the stream in the byte-stream case. I don't see what makes this particular field so special that we need to put it separately into the caps. Does it need to be negotiated?
It can need negotiation in case of a hardware decoder that has a fixed max number of buffered frames (at least a rudimentary accept/deny caps cutoff). If it's in the codec data, then the decoder would need to parse it to extract the information. That's the kind of job a parser is for. That said, if you have a hardware decoder, it might already be able to extract this and error out...
I would have expected this to be implicit in the profile/level restrictions then. I think it should just parse the SPS and error out. (And if it's byte-stream, the SPS/PPS can be in caps also as stream headers if needed)
At lest with RTP, you can explicitly give a maxdbp that exceeds the level, so it may make sense to make that negotiable through caps or something. Also, to negotiate a buffer pool, after the decoder, that can not grow, you need to know this, and libav doesn't provide that informations for codecs other than H.264 (it normally parses it from the container in libavformat).
> Also, to > negotiate a buffer pool, after the decoder, that can not grow, you need to know > this, and libav doesn't provide that informations for codecs other than H.264 > (it normally parses it from the container in libavformat). The decoder could still just parse this out of the SPS, no? If libav doesn't provide it, it will have to parse itself (or wait until the h264 parser meta lands.) So is there an actual non-theoretical use case where this needs to be negotiated, or is it just a patch you found lying around somewhere where stuffing the info into the caps was the quickest and easiest thing to do for whatever needed solving? I'm strongly opposed to adding random crap into caps if it can be avoided. (I can't comment on the RTP issue, since I haven't looked at it, but it's a separate issue, isn't it?) I would suggest to go ahead with the other patches, and clone a separate bug for this somewhat marginal issue if needed.
For anything *not* H264, this information (the number of reference frames) is stored in the container (if stored at all). The use case I see is: demux ! parser ! decocder ! converter If the converter wants to provide a pool to the decoder, the decoder will be responsible to request enough buffers. For the H264 case, the decoder could parse the SPS/PPS and will find the information, for other formats it can't guess (though many will simply hardcode a value). Though, I must agree that demuxer (or parser) may pass this information along with the buffers (even though this means duplication). In that use case, this information is not actually negotiated but informative. My interest in having that information in general is to be able to provide a pool with sufficient amount of buffers in v4l2. Since most driver can't grow the queue size after streaming has started. Currently I need to prevent libav from using fixes size pools and do copies to make it work (this is v4l2sink and upcoming v4l2transform).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/139.