GNOME Bugzilla – Bug 766261
inputselector: should proceed non-active pad buffer even if active pad reach eos
Last modified: 2018-05-07 15:47:55 UTC
non-active pad will be block if active pad reach eos currently. Has following issues: - Hard to catch up audio if change video track which be blocked long time. - Pipeline will hang if demux need push all video/audio data, it is our demux's design for some container format. Change to sync with clock for better user experience.
Created attachment 327631 [details] [review] Patch to fix the issue.
(In reply to kevin from comment #0) > non-active pad will be block if active pad reach eos currently. Has > following issues: > > - Hard to catch up audio if change video track which be blocked long time. What do you mean with that? > - Pipeline will hang if demux need push all video/audio data, it is our > demux's design for some container format. What does this mean? Your demuxer fails if it can't push all data? Once the pipeline goes to EOS, at some point the demuxer would just be shut down. It shouldn't care if there would be more data to send or not. > Change to sync with clock for better user experience. As explained on IRC this is wrong. Not every pipeline has a clock, not every input-selector should run in real-time.
Let me explain our problem: One stream has two video tracks and one audio track. One of video track has less duration than other track, so it will send eos while other track still running. Switch to the video track which reach eos. another video track buffer will be blocked in inputselector. So demuxer will be blocked when call pad push buffer for the blocked video track. As demuxer run in one thread, audio pipeline can't get audio data buffer as demuxer is blocked by video pad push buffer. So the whole playback pipeline is be blocked. Is my understand wrong or our design wrong?
You need to have queues downstream of the demuxer after every srcpad. decodebin is doing that for you already. But those might run full (do they?) if the EOS track is a lot shorter than the others. I think the EOS blocking was added some time during 1.6 or 1.8 to make it possible to switch to another (longer) track if the current one went EOS.
(In reply to Sebastian Dröge (slomo) from comment #4) > You need to have queues downstream of the demuxer after every srcpad. > decodebin is doing that for you already. > > But those might run full (do they?) if the EOS track is a lot shorter than > the others. Yes, the queue will full and then block demuxer. > > I think the EOS blocking was added some time during 1.6 or 1.8 to make it > possible to switch to another (longer) track if the current one went EOS. So what's your option to fix our problem?
I don't know, this would need more thinking about how to solve both problems at once.
(In reply to Sebastian Dröge (slomo) from comment #6) > I don't know, this would need more thinking about how to solve both problems > at once. What's mean of "both problem"? Do you mean my patch will cause problem to switch to another (longer) track? My patch will proceed pad buffer sync with clock if the pipeline has clock. inputselector will drop all received buffer if the pipeline haven't clock. In this case, there is several seconds without video output if switch to another (longer) track.
Those two problems, yes. Your patch is wrong because it requires a clock and requires to run at clock speed as explained in comment 2
What shall we do with this?
Closing I guess, there was no progress here for years