[Bug 745502] qtdemux: seek fails intermittently with video pad unlinked

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=745502

--- Comment #6 from Shaunak Gupte <shaunakg at nvidia.com> ---
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?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.