[gstreamer-bugs] [Bug 624212] mp4mux produces incorrect frame rates when h264 input uses bframes

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=624212
  GStreamer | gst-plugins-bad | git

Tim-Philipp Müller <t.i.m> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |t.i.m at zen.co.uk
     Ever Confirmed|0                           |1
           Severity|normal                      |major

--- Comment #1 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2010-08-15 15:55:07 UTC ---
Still an issue with git  latest pre-release.

> bframes=0: video H264 Main at 2.1, 3.336 secs, 1121 kbps, 320x240 @ 29.976019 fps
> bframes=1: video H264 Main at 2.1, 6.573 secs, 563 kbps, 320x240 @ 15.213753 fps

$ gst-launch-0.10 -v videotestsrc num-buffers=5 !
"video/x-raw-yuv,framerate=(fraction)30000/1001" ! x264enc bframes=1 ! fakesink
| grep chain
timestamp: 0:00:00.000000000, duration: 0:00:00.033366666
timestamp: 0:00:00.066733333, duration: 0:00:00.033366667
timestamp: 0:00:00.033366666, duration: 0:00:00.033366667
timestamp: 0:00:00.133466666, duration: 0:00:00.033366666
timestamp: 0:00:00.100100000, duration: 0:00:00.033366667

$ gst-launch-0.10 -v videotestsrc num-buffers=5 !
"video/x-raw-yuv,framerate=(fraction)30000/1001" ! x264enc bframes=0 ! fakesink
| grep chain
timestamp: 0:00:00.000000000, duration: 0:00:00.033366666
timestamp: 0:00:00.033366666, duration: 0:00:00.033366667
timestamp: 0:00:00.066733333, duration: 0:00:00.033366667
timestamp: 0:00:00.100100000, duration: 0:00:00.033366666
timestamp: 0:00:00.133466666, duration: 0:00:00.033366667


> I expect the duration and frame rate of the resulting stream to be the same
> whether bframes are used or not.

Agreed. My guess would be that mp4mux tries to estimate the framerate or
durations or something from the timestamps of the first two buffers, that could
explain the factor 2.


Worse, it's not just some value in the header that's wrong, but the timestamps
on demuxing are all off too:

  gst-launch-0.10 filesrc location=foo-N.mp4 ! qtdemux ! progressreport !
fakesink

yields last timestamp of ca. 6 secs vs. 3 secs.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.