GNOME Bugzilla – Bug 745502
qtdemux: seek fails intermittently with video pad unlinked
Last modified: 2018-05-05 15:42:46 UTC
Created attachment 298380 [details] The compressed file contains the debug log and the mediainfo dump Seeking operation with qtdemux in the pipeline fails intermittently with the video pad left unlinked leading to the pipeline being stalled. The seek operation works fine when both the audio and video pads or just the video pad is linked. I extracted the aac audio and dumped it to a file. Seeking operation on the extracted audio file also works properly. Also tried with different sinks (fakesink, filesink) and different decoders (faad, mad) and the issue is still reproduced. This issue is not reproducible on 0.10. I have attached debug logs for both cases when the seek is successful and when the seek fails. The difference that I can make out is that the stream-start event is not sent on the audio pad. I have also attached the mediainfo dump of the test stream.
The pipeline looks like filesrc ! decodebin ! alsasink The src pad of h264parse in the decodebin is left exposed using autoplug_select signal.
Which exact version of GStreamer is this with? gst-inspect-1.0 qtdemux | grep Version
I have tried this with 1.2.4 as well as 1.4.5 and the issue is reproduced. However, it is not reproducible with 0.10.36.
Can you share the file you used? Does it happen with all files? Does it happen if you always seek to the same position? It seems like the multiqueue gets only video frames for some time and the not-linked return makes it wait until it knows it can push a buffer by comparing with the other queue's timestamp. As the audio doesn't get any buffer the multiqueue stalls and its video queue fill up, making the whole pipeline stop.
I will not be able to share the file as it is a proprietary. The issue is observed only with this file. The position does not matter. For the same file, the seek might work a few times and then get stuck or it might get stuck during the first seek itself.
Hi, Sorry for not replying. I debugged this further. I observed something similar to what Thiago said would be happening. In gst_qtdemux_loop_state_movie, I printed stream->time_position. When seek is unsuccessful, stream->time_position = 3533333333 stream = 0x7f6c18005c00 (video) stream->time_position = 3552653061 stream = 0x7f6c1801c720 (audio) ^[[C** Message: <exec_ops:760> seeking to 0:00:12.115827664 stream->time_position = 12115827664 stream = 0x7f6c18005c00 (video) stream->time_position = 12115827664 stream = 0x7f6c1801c720 (audio) stream->time_position = 10066666666 stream = 0x7f6c18005c00 (video) stream->time_position = 12115827664 stream = 0x7f6c1801c720 (audio) stream->time_position = 10100000000 stream = 0x7f6c18005c00 (video) stream->time_position = 12115827664 stream = 0x7f6c1801c720 (audio) The time_position for video is almost 2 seconds behind that for audio. So, qtdemux keeps pushing data on the video_pad (until time_position of video > time_position of audio). multiqueue src only accepts data until it becomes full. Since no audio data is received, multiqueue does not pop data from the video queue, and the whole pipeline hangs when qtdemux tries to push more video data to the multiqueue. (max-size-bytes condition is hit in this case) For successful seek, the difference between video and audio time_position is ~600ms. Is this because the stream has been muxed wrongly or could this be an issue with qtdemux?
I tried setting the max-size-bytes property of the decodebin to 20MB and I could seek successfully. However, the property comes into effect only with buffering.
This shouldn't happen anymore with decodebin3 based on the description of the issue. If you see the same issue with decodebin3, please open a new bug mentioning this one. Thankyou