GNOME Bugzilla – Bug 575759
Regression in framerates
Last modified: 2009-03-17 22:47:41 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:
Expected results should say: framerate would NOT be doubled.
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
Created attachment 130859 [details] [review] Take into account ticks_per_frame in framerate calculations
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).
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