mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-12-29 19:50:40 +00:00
0812c753c6
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> |
||
---|---|---|
.. | ||
libav |