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 723243 - h264parse: Default framerate to 25/1 when no informations found
h264parse: Default framerate to 25/1 when no informations found
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
unspecified
Other All
: Normal normal
: 1.3.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-01-29 15:36 UTC by Thibault Saunier
Modified: 2014-01-31 12:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
h264parse: Default framerate to 25/1 when no informations found (1.57 KB, patch)
2014-01-29 15:36 UTC, Thibault Saunier
reviewed Details | Review
h264parse: Default framerate to 0/1 when no informations found (2.85 KB, patch)
2014-01-30 14:16 UTC, Thibault Saunier
none Details | Review
h264parse: Default framerate to 0/1 when no informations found (2.85 KB, patch)
2014-01-30 16:35 UTC, Thibault Saunier
committed Details | Review

Description Thibault Saunier 2014-01-29 15:36:00 UTC
This is actually what we do in gstavviddec, and even if it is not
perfect, it allows us to be sure that some framerate informations
will be present in the caps.

As soon as some information is found in the stream, that will be
updated.
Comment 1 Thibault Saunier 2014-01-29 15:36:10 UTC
Created attachment 267540 [details] [review]
h264parse: Default framerate to 25/1 when no informations found
Comment 2 Sebastian Dröge (slomo) 2014-01-29 19:27:18 UTC
Comment on attachment 267540 [details] [review]
h264parse: Default framerate to 25/1 when no informations found

Why not use 0/1?
Comment 3 Thibault Saunier 2014-01-29 21:45:24 UTC
Because it would more likely break other things and create a weird behaviour I would say.
Comment 4 Olivier Crête 2014-01-29 22:20:17 UTC
I think making up a "fake" FPS sounds like a pretty bad idea.. If a downstream element absolutely needs a fixed FPS, then it should make a guess or you should add a videorate (possibly with drop-only=true), not put that in the caps.
Comment 5 Nicolas Dufresne (ndufresne) 2014-01-30 00:26:54 UTC
IMHO, framerate 0/1 is only valid if duration is valid. In the case we don't have valid duration, and no framerate, I think we are pretty much screwed, whatever the fix is won't be ideal.

For this reason I'd go fo Sebastien solution but check the duration is valid, if not, we don't do anything.
Comment 6 Tim-Philipp Müller 2014-01-30 00:41:16 UTC
I think you will rarely have a valid duration if the framerate is 0/1, since by definition duration is then based on the timestamp of the following frame, which we don't know yet (and it would introduce latency to wait for it), no?
Comment 7 Olivier Crête 2014-01-30 05:44:06 UTC
The super common case is RTP, where you have no duration and no framerate, all you have is a buffer with a timestamp, nothing more is required for accurate playback.
Comment 8 Thibault Saunier 2014-01-30 14:16:23 UTC
Created attachment 267632 [details] [review]
h264parse: Default framerate to 0/1 when no informations found

It is not perfect but it allows us to be sure that the mandatory 'framerate'
field is present in the caps.

As soon as some information is found in the stream, that will be
updated.
Comment 9 Thibault Saunier 2014-01-30 16:35:41 UTC
Created attachment 267661 [details] [review]
h264parse: Default framerate to 0/1 when no informations found

It is not perfect but it allows us to be sure that the mandatory 'framerate'
field is present in the caps.

As soon as some information is found in the stream, that will be
updated.
Comment 10 Sebastian Dröge (slomo) 2014-01-30 19:09:11 UTC
Comment on attachment 267661 [details] [review]
h264parse: Default framerate to 0/1 when no informations found

Since when is the framerate field in h264 mandatory? :)

But looks good, yes. And 25fps or another fake framerate is really not a good idea. Also 0/1 framerate does not depend on a duration at all, just on timestamps.
Comment 11 Nicolas Dufresne (ndufresne) 2014-01-30 20:20:32 UTC
(In reply to comment #10)
> (From update of attachment 267661 [details] [review])
> Since when is the framerate field in h264 mandatory? :)
> 
> But looks good, yes. And 25fps or another fake framerate is really not a good
> idea. Also 0/1 framerate does not depend on a duration at all, just on
> timestamps.

good point.
Comment 12 Thibault Saunier 2014-01-30 21:44:16 UTC
(In reply to comment #10)
> (From update of attachment 267661 [details] [review])
> Since when is the framerate field in h264 mandatory? :)
> 
> But looks good, yes. And 25fps or another fake framerate is really not a good
> idea. Also 0/1 framerate does not depend on a duration at all, just on
> timestamps.

I guess we should change that in gst-libav too then as it defaults to 25/1 there?
Comment 13 Thibault Saunier 2014-01-30 21:47:14 UTC
(In reply to comment #10)
> (From update of attachment 267661 [details] [review])
> Since when is the framerate field in h264 mandatory? :)

Just that gst-validate conciders that "framerate" is mandatory for any video caps, that might actually be a bit excessive for encoded formats.
Comment 14 Nicolas Dufresne (ndufresne) 2014-01-30 22:02:37 UTC
(In reply to comment #13)
> Just that gst-validate conciders that "framerate" is mandatory for any video
> caps, that might actually be a bit excessive for encoded formats.

Currently, demuxing certain TS file result in no framerate and has been so far considered valid. Though your patch would add a framerate, that reflects well the situation, so personally I'm not against doing it this way.

I suspect that libav code was there a long time before we introduce 0/1. Note that no-framerate, and 0/1 is pretty much that same.
Comment 15 Thibault Saunier 2014-01-31 08:31:37 UTC
Attachment 267661 [details] pushed as 5fd9b42 - h264parse: Default framerate to 0/1 when no informations found