[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

--- Comment #10 from Mark Nauwelaerts <manauw at skynet.be> 2010-01-11 17:42:51 UTC ---
(In reply to comment #7)
> I terminate gst-launch with ctrl-c but after than i use this pipeline to close
> the file:
> 
> gst-launch filesrc location=file.mkv ! matroskademux ! matroskamux ! filesink
> location=file_closed.mkv
> 
> As far as i know this is a good way to closing the output file... Maybe not?
> (Your example works for me without any errors, too)

Unfortunately, it is not.  Matroska version 1 files (which matroskamux produces
by default, see version property) actually do not record whether or not a frame
is a keyframe.  So, the remuxing pipeline above has no real keyframe input
info.  As such, the output file may have sort of an index, but hardly one that
is really certified for "complaint-free" seeking etc 

[it might work for version 2 files, but such abort-and-patch later approach
would not work for many formats, not for avi, qt, mkv version 1, etc].

> 
> I made some test with the num-buffers property to avoid it, but the result
> generates "non-existing PPS referenced" errors, and with 1 fps the results
> either can't be playable with gstreamer. (Btw what means exactly this message?
> i can't find a proper description about that.) 
> 
> Pipeline:
> gst-launch lannersrc num-buffers=100 ! capsfilter
> caps="video/x-h264,framerate=10/1" ! matroskamux ! filesink
> location=10fps_lanner2matroska.mkv

PPS (picture parameter set) contain some 'global' data needed/useful for
decoding frames/slices.  Such message would suggest a referenced (by number)
PPS has not been seen before in the stream.  Either it really was not there
(corrupt stream) or the id has been misparsed (possibly due to bytestream vs
avc sample problems), or the decoder is in a wrong state due to seeking to
wrong place (non-keyframe).

> 
> Then i tried reencoding the stream of our capture card, and everything was fine
> and seekable:
> 
> gst-launch lannersrc num-buffers=20 ! capsfilter
> caps="video/x-h264,framerate=1/1" ! ffdec_h264 ! x264enc byte-stream=false !
> matroskamux ! filesink location=10fps_reencoded.mkv
> 
> Maybe there's a problem with the h264 stream of the capture card?

Could be, or with the plugin.  Maybe its output caps contain codec-data while
the stream itself is in byte-format, which could confuse matters.  Or much more
likely, it simply never sets the DELTA_UNIT buffer flag.  This misleads the
muxer into believing every frame is a keyframe and every frame can be seeked
to, which is likely wrong and messes up seeking.

Btw, mkvinfo (which comes alongside mkvmerge) should allow for some dumping of
a mkv (though apparently unfortunately not frame content itself).
In particular, using mkvinfo on a 2fps lannersrc sample file shows that every
frame has a cue (index) entry, which typically means muxer was told every frame
is a keyframe.

It is then an exercise to confirm that really not every frame is an I(DR)-frame
;)

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