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 575759 - Regression in framerates
Regression in framerates
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-libav
git master
Other All
: High blocker
: 0.10.7
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-03-17 21:23 UTC by Tristan Matthews
Modified: 2009-03-17 22:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
Take into account ticks_per_frame in framerate calculations (3.76 KB, patch)
2009-03-17 21:50 UTC, Edward Hervey
committed Details | Review

Description Tristan Matthews 2009-03-17 21:23:30 UTC
Please describe the problem:
When streaming h264 over rtp, the framerate on the output is doubled. For example, if your video source has 30fps, it will come out at 60fps.

Steps to reproduce:
gst-launch -v v4l2src ! x264enc ! rtph264pay ! rtph264depay ! ffdec_h264 ! xvimagesink

Actual results:
Setting pipeline to PAUSED ...
/GstPipeline:pipeline0/GstV4l2Src:v4l2src0.GstPad:src: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)768, height=(int)480, framerate=(fraction)30000/1001
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
/GstPipeline:pipeline0/GstX264Enc:x264enc0.GstPad:src: caps = video/x-h264, width=(int)768, height=(int)480, framerate=(fraction)30000/1001, codec_data=(buffer)014d4033ffe10016674d403392540601ed808800001f480007530478c19501000468ee3c80
/GstPipeline:pipeline0/GstX264Enc:x264enc0.GstPad:sink: caps = video/x-raw-yuv, format=(fourcc)I420, width=(int)768, height=(int)480, framerate=(fraction)30000/1001
/GstPipeline:pipeline0/GstRtpH264Pay:rtph264pay0.GstPad:src: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, profile-level-id=(string)4d4033, sprop-parameter-sets=(string)\"Z01AM5JUBgHtgIgAAB9IAAdTBHjBlQ\\=\\=\\,aO48gA\\=\\=\", payload=(int)96, ssrc=(guint)30712840, clock-base=(guint)30267285, seqnum-base=(guint)33183
/GstPipeline:pipeline0/GstRtpH264Pay:rtph264pay0.GstPad:sink: caps = video/x-h264, width=(int)768, height=(int)480, framerate=(fraction)30000/1001, codec_data=(buffer)014d4033ffe10016674d403392540601ed808800001f480007530478c19501000468ee3c80
/GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:src: caps = video/x-h264
/GstPipeline:pipeline0/GstRtpH264Depay:rtph264depay0.GstPad:sink: caps = application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, profile-level-id=(string)4d4033, sprop-parameter-sets=(string)\"Z01AM5JUBgHtgIgAAB9IAAdTBHjBlQ\\=\\=\\,aO48gA\\=\\=\", payload=(int)96, ssrc=(guint)30712840, clock-base=(guint)30267285, seqnum-base=(guint)33183
/GstPipeline:pipeline0/ffdec_h264:ffdec_h2640.GstPad:sink: caps = video/x-h264
/GstPipeline:pipeline0/ffdec_h264:ffdec_h2640.GstPad:src: caps = video/x-raw-yuv, width=(int)768, height=(int)480, framerate=(fraction)60000/1001, format=(fourcc)I420, pixel-aspect-ratio=(fraction)1/1
/GstPipeline:pipeline0/GstXvImageSink:xvimagesink0.GstPad:sink: caps = video/x-raw-yuv, width=(int)768, height=(int)480, framerate=(fraction)60000/1001, format=(fourcc)I420, pixel-aspect-ratio=(fraction)1/1


Expected results:
The framerate would be doubled.

Does this happen every time?
Yes.

Other information:
Comment 1 Tristan Matthews 2009-03-17 21:26:26 UTC
Expected results should say: framerate would NOT be doubled.
Comment 2 Edward Hervey 2009-03-17 21:45:02 UTC
great... thanks to a last minute commit to ffmpeg by M.Niedermayer we get a great surprise... by having a regression in framerates for mpeg2 and h264 decoding ! yay !

We need to take into account ticks_per_frame in all framerate conversions between framerate and time_base.

The two commits changing that are as follow:

commit 68f29ac60ec3f3c33f142497337666a36288d54d
Author: michael <michael@9553f0bf-9b14-0410-a0b8-cfaf0461ba5b>
Date:   Thu Feb 26 23:47:32 2009 +0000

    Add ticks_per_frame, this should hopefully fix the regressions caused
    by the time_base change.
    
    
    git-svn-id: file:///var/local/repositories/ffmpeg/trunk@17630 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b


commit 9689f4f468988d2b2ceb1231c3637c091920307d
Author: michael <michael@9553f0bf-9b14-0410-a0b8-cfaf0461ba5b>
Date:   Sat Feb 28 20:58:07 2009 +0000

    Adjust time_base exactly when changing ticks_per_frame to 2 this is safer
    and for some raw h264 we managed to change the timebase twice before.
    
    
    git-svn-id: file:///var/local/repositories/ffmpeg/trunk@17669 9553f0bf-9b14-0410-a0b8-cfaf0461ba5b

Comment 3 Edward Hervey 2009-03-17 21:50:43 UTC
Created attachment 130859 [details] [review]
Take into account ticks_per_frame in framerate calculations
Comment 4 Jan Schmidt 2009-03-17 21:54:52 UTC
Awkward looking change from ffmpeg, but the patch looks fine. Please commit. I'll make some new pre-releases, and push them out, and delay the release another 2 days (to Friday).
Comment 5 Edward Hervey 2009-03-17 22:47:41 UTC
committed without the rogue "fps" debug statement.

commit 7ca2836193baa85387484d1f85aa56dc7e02ba5d
Author: Edward Hervey <bilboed@bilboed.com>
Date:   Tue Mar 17 23:44:43 2009 +0100

    Take into account ticks_per_frame for framerate calculation. Fixes #575759