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 768901 - qtdemux: Use upstream framerate if available
qtdemux: Use upstream framerate if available
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-07-17 12:58 UTC by Seungha Yang
Modified: 2018-11-03 15:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
qtdemux-Use-upstream-framerate-if-available.patch (1.58 KB, patch)
2016-07-17 13:00 UTC, Seungha Yang
none Details | Review

Description Seungha Yang 2016-07-17 12:58:37 UTC
In case of dash streaming, dashdemux provides framerate.
So, let's use it rather than calculate it in order to prevent noisy
caps event which results from slightly varying calculated framerate.
Comment 1 Seungha Yang 2016-07-17 13:00:24 UTC
Created attachment 331646 [details] [review]
qtdemux-Use-upstream-framerate-if-available.patch
Comment 2 Edward Hervey 2017-01-31 15:17:05 UTC
Seungha, do you have examples of streams that would cause such erratic framerates ?
Comment 3 Seungha Yang 2017-02-01 12:39:31 UTC
(In reply to Edward Hervey from comment #2)
> Seungha, do you have examples of streams that would cause such erratic
> framerates ?

Sorry, I cannot find the url...

But, noisy caps is still there with any dash streams.

Example
http://dash.akamaized.net/dash264/TestCases/5c/nomor/4_1a.mpd

qtdemux tries to pushes caps whenever get new moov.
https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/isomp4/qtdemux.c#n6444

At this moment, framerate cannot be set since demux has no moof.

Then, when demux get a moof, new caps is set to TRUE
https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/isomp4/qtdemux.c#n3902

And then new caps will be pushed since demux can calculate the framerate now.
https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/isomp4/qtdemux.c#n6758

This makes noisy caps event.
Comment 4 Jan Schmidt 2017-02-01 12:54:41 UTC
I've seen the same behaviour. Really, any fragmented stream with short-ish fragment durations can cause flip-flopping framerates, because there's not really enough samples (or the timescales aren't accurate enough) to really pin down a framerate.

I think it makes sense to use an upstream framerate where available. Where it's not, I was thinking of an approach for only changing framerate at fragment boundaries if the difference crosses a threshold.
Comment 5 Vivia Nikolaidou 2018-05-06 13:08:36 UTC
Setting to NEW again until someone has time to start working on it.
Comment 6 GStreamer system administrator 2018-11-03 15:10:33 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-good/issues/287.