[Bug 778690] Possible bug on gst-1.11 gst_element_seek

[GStreamer (GNOME Bugzilla)]

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

--- Comment #10 from christophe vr <christophevr at telenet.be> ---
Hello, Yes indeed. I self I'm bussy with main e2 player for stb's, called a bit
odd servicemp3.cpp. Since on a stb we only can with sync false for video (stb
does not have enough cpu power to handle the vsync on streams higher then sd
resolutions) and the quit high audio queue mem (up to +60 seconds on aac audio)
and up to 90 seconds by some video codecs. We must work with sync false and
async false. Up on pausing media to avoid a to long wait on the state change of
the pipeline we do a such seek-flush a seek based on the real playposition
which is polled in the video mem by ioctl command. and audio mem for audio only
media.

But indeed it took me quit a while to find out why in some cases I had reports
of such strange issues with a movie restart or .. And then the discovering that
with gst-0.1 no problems.

But now I'm happy I self have a tool to investigate some working ways or
actions on ubuntu pc with last master git.
I will check with qtdemux, hope that in that log can be found why it does not
find a KEY_UNIT by some media , think it is related to the difference in video
start segment and audio start segment. By the media I posted here we do have a
video start segment of 41711111 and audio start segment off 0 .so here almost
42 ms difference. That is quit typic for a lot off HD media using h264 or h265
codecs.

up to gst-1.8.2 this was no problem at all, the problem must come from some
changes between 1.8.2 and the currently used master git.

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