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 704161 - avviddec: should use upstream fps only if valid
avviddec: should use upstream fps only if valid
Product: GStreamer
Classification: Platform
Component: gst-libav
git master
Other All
: Normal normal
: 1.2.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2013-07-13 18:52 UTC by Matej Knopp
Modified: 2013-12-04 13:05 UTC
See Also:
GNOME target: ---
GNOME version: ---

Patch (877 bytes, patch)
2013-07-13 18:52 UTC, Matej Knopp
none Details | Review

Description Matej Knopp 2013-07-13 18:52:49 UTC
Created attachment 249068 [details] [review]

Currently gstavviddec will use upstream FPS even if it is 0/1. I think in this case it should let decoder override the FPS.
Comment 1 Tim-Philipp Müller 2013-07-13 19:19:35 UTC
0/1 is not an invalid framerate, it signals 'variable' framerate - in many contexts there may not be a fixed framerate (e.g. RTP, frames captured from webcam and encoded)
Comment 2 Matej Knopp 2013-07-14 01:04:53 UTC
If that's the case then I need to find out why the decoder received 0/1 in the first place.
Comment 3 Matej Knopp 2013-07-14 10:15:54 UTC
Okay, so the problem seems to be in gst_video_info_from_caps

it sets 0/1 framerate even when NO FRAMERATE is specifid in caps. So it seems like there is no way currently to get the actual framerate from decoder, because
  - if there is upstream framerate it will be preserved
  - if there isn't upstream framerate gst_video_info_from_caps will set it to 0/1 anyway

Now I have a file where parser is unable to provide framerate, but the decoder is. What would be the proper way of fixing this?
Comment 4 Matej Knopp 2013-07-14 11:41:58 UTC
So the bigger issue here is that the parser is unable to determine the framerate (will create separate bug for that), but I'd like for someone to confirm that it is correct behavior that the decoder will never override upstream fps (unless fps_den == 0 - is that even valid)
Comment 5 Sebastian Dröge (slomo) 2013-07-15 08:05:14 UTC
No, fps_d == 0 can not really happen.

The question is when should we trust libav to give us useful information? What if upstream is really variable framerate and some random framerate is encoded in the h264 stream? Currently there's no way from GstVideoInfo to distinguish between "no framerate" and "variable framerate".
Comment 6 Wim Taymans 2013-07-15 08:14:48 UTC
- if 0/1 is set in caps, GST_VIDEO_FLAG_VARIABLE_FPS is set and then num/denom is set to max-framerate when present

- if 0/1 is not set, GST_VIDEO_FLAG_VARIABLE_FPS is not set and 0/1 is in the framerate

Doesn't that catch all cases?
Comment 7 Matej Knopp 2013-07-15 08:19:17 UTC
In this case the missing H264 framerate can be fixed in parser. But can't there be situation where gstreamer doesn't have parser for codec, doesn't get the framerate from demuxer but decoder can provide it? Because if so, it will not be used (it will be set to 0/1 instead).
Comment 8 Sebastian Dröge (slomo) 2013-07-15 08:21:56 UTC
So if 0/1 and the flag is not set, we could trust the decoder to give us something sensible
Comment 9 Wim Taymans 2013-07-15 08:31:27 UTC
It's all a question about who creates meaningful timestamps.

If the demuxer creates timestamps, a decoder should always place them on the outgoing buffers.

If the demuxer does not place timestamps on (all) the buffers, you could let the decoder interpolate the missing timestamps from the framerate in the header.

Is there possibly a case where a demuxer sets a framerate but doesn't put timestamps?
Comment 10 Sebastian Dröge (slomo) 2013-07-23 13:12:15 UTC
What should we do here?
Comment 11 Matej Knopp 2013-07-23 16:18:00 UTC
I'm bit confused from the last comment. I think the proper solution here would be to use decoder FPS when framerate is 0/1 and the GST_VIDEO_FLAG_VARIABLE_FPS is not set.
Comment 12 Sebastian Dröge (slomo) 2013-07-23 16:25:42 UTC
I think so too, I don't understand how Wim's comment relates to this bug either :)
Can you prepare a new patch?
Comment 13 Mark Nauwelaerts 2013-12-02 19:33:38 UTC
So patched this in line with previous comments, which makes sense afaik:

commit 039b608b249f5d8ccc820dce25c931a807538b20
Author: Mark Nauwelaerts <>
Date:   Mon Dec 2 20:21:34 2013 +0100

    avviddec: only use upstream framerate if really specified