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)

If that's the case then I need to find out why the decoder received 0/1 in the first place.

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?

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)

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".

- 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?

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).

So if 0/1 and the flag is not set, we could trust the decoder to give us something sensible

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?

What should we do here?

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.

I think so too, I don't understand how Wim's comment relates to this bug either :)
Can you prepare a new patch?

So patched this in line with previous comments, which makes sense afaik:

commit 039b608b249f5d8ccc820dce25c931a807538b20
Author: Mark Nauwelaerts <mnauw@users.sourceforge.net>
Date:   Mon Dec 2 20:21:34 2013 +0100

    avviddec: only use upstream framerate if really specified
    
    Fixes https://bugzilla.gnome.org/show_bug.cgi?id=704161