[gstreamer-bugs] [Bug 606307] mastroska muxer bad in case of 1fps

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=606307
  GStreamer | gst-plugins-good | 0.10.17

Mark Nauwelaerts <manauw> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |manauw at skynet.be
         Resolution|                            |NOTABUG

--- Comment #3 from Mark Nauwelaerts <manauw at skynet.be> 2010-01-07 18:06:49 UTC ---
I had a look at the files that were mentioned in the [gst-devel] mail.
The problematic 1fps_* files have either no or very few frames, so there is not
much to play (or seek).  I have no idea why, since using the pipelines
mentioned above on the raw h264 file produces mkv files that have a lot more
stuff in it.

At the core of the matter, you might possibly not know something here.  That
is, h264 data can be passed around in (at least) 2 ways, e.g. the "bytestream"
format (as defined in the H264 spec) or the "AVC sample format" (as defined in
some MP4 file spec).  The former is typically used for 'raw h264' data (e.g. on
its way to be rtp payloaded etc), the latter must be used for storage in a
mp4/mov container (and by extension say also in other containers).  Bytestream
format stashed into a container can lead to all sorts of surprises for
player/decoder (and corresponding messages).

The raw file (and possibly also lannersrc output) provide bytestream formatted
data.  Until recently, h264parse only provided bytestream formatted output,
which should as such explain that it could not work that way.  And no
(matroska)muxer is not buggy here.  It works with mkvmerge as it may be aware
of all this and perform the necessary transformations.

Using a (properly configured) recent h264parse, such as in following pipeline,
the resulting file runs/seek fine in mplayer/gstreamer:
gst-launch filesrc location=1fps_raw.h264 ! h264parse access-unit=true
output-format=0 ! matroskamux ! filesink location=1fps_file2matroska.mkv

BTW: The problem in 3) given above is due to x264enc producing avc sample
format output by default (for convenient muxing).  However, when dumped into a
file, there is no real decent way for a parser to reconstruct frames, so no
decent mkv files results from it.

In summary, this is not really a bug (least of all in matroskamux), at best a
distant relative/duplicate of bug #604925 (as in: some more caps fields might
help with automagic negotiation).

-- 
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.