gst-libav: Fix synchronization issues and errors created by the forwarding of
authorDevin Anderson <danderson@microsoft.com>
Tue, 18 Oct 2022 11:37:30 +0000 (11:37 +0000)
committerGStreamer Marge Bot <gitlab-merge-bot@gstreamer-foundation.org>
Fri, 21 Oct 2022 23:17:58 +0000 (23:17 +0000)
commit0812c753c61c05b05a60aca63d70792a76aa2868
tree1d02767919492cdd5dc0246e20dec06f0ed763ab
parent7bc5ed34fd8b982cddf4186beaf3b1d34c097e81
gst-libav: Fix synchronization issues and errors created by the forwarding of
segment events by demuxer.

In order to play nicely with `ffmpeg`, demuxers in `gst-libav` have to make
buffers available to `ffmpeg` while taking the blocking I/O model in `ffmpeg`
into account, which results in buffers not being sent downstream until `ffmpeg`
has processed them in its separate thread.

In constrast, many `gstreamer` events are simply forwarded downstream.
Currently `GST_EVENT_SEGMENT` events are forwarded downstream without any
processing, which can potentially result in:
 * `GST_EVENT_SEGMENT` events being out of sync with buffers
 * `GST_EVENT_SEGMENT` events going out that are incorrect because they apply
   to data seen by the demuxer, but not necessarily seen by downstream elements

I came across this bug when I was attempting to enable G723.1 demuxing/decoding
using the G723.1 demuxer and decoder provided by `ffmpeg`.  I wrote tests to
verify support for the functionality, and found that, in push mode,
`GST_EVENT_SEGMENT` events pushed to the demuxer by the upstream `filesrc`
element would be forwarded to the decoder without modification, resulting in
an internal data streaming error.  With this patch, tests work in both push and
pull mode.

This patch solves the problem by disabling the forwarding of
`GST_EVENT_SEGMENT` events downstream (an initial `GST_EVENT_SEGMENT` event is
still pushed downstream by the demuxer).  It's possible there's a better way to
do this, but, having looked at how a few different `gstreamer` demuxers deal
with `GST_EVENT_SEGMENT` events, it seems like the processing is somewhat
specific to the demuxer implementation, whereas `gst-libav` has one general way
of handling the situation for any `ffmpeg` demuxer.  Perhaps there's a better
way to solve this using the `ffmpeg` API to take advantage of specific demuxer
details.  IDK.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3218>
subprojects/gst-libav/ext/libav/gstavdemux.c