After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 728324 - h264parse: wait for resolution to be known before pushing
h264parse: wait for resolution to be known before pushing
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-04-16 09:16 UTC by Vincent Penquerc'h
Modified: 2018-11-03 13:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
wait to get resolution before pushing buffers (3.43 KB, patch)
2014-04-16 09:16 UTC, Vincent Penquerc'h
none Details | Review
delay setting passthrough mode when waiting to known resolution (2.55 KB, patch)
2014-04-16 09:17 UTC, Vincent Penquerc'h
none Details | Review
add num-ref-frames in caps (2.20 KB, patch)
2014-04-16 09:17 UTC, Vincent Penquerc'h
reviewed Details | Review

Description Vincent Penquerc'h 2014-04-16 09:16:37 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.
Comment 1 Vincent Penquerc'h 2014-04-16 09:17:05 UTC
Created attachment 274434 [details] [review]
delay setting passthrough mode when waiting to known resolution
Comment 2 Vincent Penquerc'h 2014-04-16 09:17:37 UTC
Created attachment 274435 [details] [review]
add num-ref-frames in caps
Comment 3 Tim-Philipp Müller 2014-04-16 09:26:04 UTC
Comment on attachment 274435 [details] [review]
add num-ref-frames in caps

I don't think this should be in the caps directly.
Comment 4 Vincent Penquerc'h 2014-04-17 08:08:22 UTC
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 ?
Comment 5 Tim-Philipp Müller 2014-04-17 08:24:38 UTC
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?
Comment 6 Vincent Penquerc'h 2014-04-17 08:46:02 UTC
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...
Comment 7 Tim-Philipp Müller 2014-04-17 09:09:39 UTC
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)
Comment 8 Olivier Crête 2014-04-17 21:45:38 UTC
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).
Comment 9 Tim-Philipp Müller 2014-04-27 11:05:39 UTC
> 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.
Comment 10 Nicolas Dufresne (ndufresne) 2014-04-27 14:30:04 UTC
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).
Comment 11 GStreamer system administrator 2018-11-03 13:22:23 UTC
-- 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.