Trouble getting fully valid files with matroskamux
Pedro Côrte-Real
pedro at pedrocr.net
Sun Jan 5 11:14:16 PST 2014
On Sun, Jan 5, 2014 at 9:27 AM, Sebastian Dröge
<sebastian at centricular.com> wrote:
> After the bugs mentioned below are fixed, the cleaner solution would be
> to just adjust the segment that the muxer gets, and let the muxer
> convert the buffer timestamps to the correct running time itself.
>
> But at least in your case when you probe every single buffer anyway it
> doesn't matter much ;)
That's true for the filesplit code and not for the filejoin code. The
filejoin one only has a buffer probe to apply the offset. So for that
one I could refactor it around the segments. The only issue with that
might be to know what the last buffer offset is. Does the EOS event
have a timestamp that corresponds to PTS+DURATION of the last buffer?
That would be convenient and sounds correct to me anyway (the
timestamp of EOS is the final display timestamp of the stream).
> Note that in your code you need to make sure that the buffer is writable
> before changing the timestamp:
> GST_PAD_PROBE_INFO_BUFFER (info) = gst_buffer_make_writable (GST_PAD_PROBE_INFO_BUFFER (info))
Thanks, didn't realize I needed to do this. The probe example in the
manual does include this. For the benefit of the mailing list archives
the correct code is:
GST_PAD_PROBE_INFO_DATA (info) = gst_buffer_make_writable
(GST_PAD_PROBE_INFO_BUFFER (info));
GST_PAD_PROBE_INFO_BUFFER doesn't work as an lvalue.
> Also there might be a problem because you take the start timestamps of
> buffers only. After a buffer is handled, the running time is usually the
> one of the end timestamp (i.e. timestamp + duration, see matroskamux
> commit).
Right, this is needed for the filejoin code, otherwise you end up with
two consecutive frames with the same timestamp, good catch, thanks!
The filesplit code is correct as is because there I want the first
frame to end up with a timestamp of 0 and since the probe fires on
that frame twice (once to block, once to unblock), on the first I save
the timestamp and on the second I subtract it as an offset and it ends
up being 0. All the other frames are then relative to that first one.
Correct code is now here:
https://github.com/pedrocr/camerasink/blob/9b28532d77d79cbec87b48acf167a5191b0c7684/bin/camerasave.c
https://github.com/pedrocr/camerasink/blob/5cbc31a7077bb755485f801887a6e9459cbf27e8/bin/filejoin.c
> This is the matroskamux fix btw:
> http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=b3aa8755fe07639f22e4104f4932d769d6c9075a
Thanks again for this!
Pedro
More information about the gstreamer-devel
mailing list