Gapless Playback with Playbin

[Luis de Bethencourt]

Seeing that duration before a real value is discovered by the demuxer is
normal. But those FIXME lines do look scary.

Will read your log in a while.

Thanks,
Luis


On 14 July 2014 13:43, David W. Harks <dave at dwink.net> wrote:

> Sure, here you go, at debug level 4.
>
> https://www.dropbox.com/s/cdh1ur7vsmt6q5m/dbg_4.log
>
> One thing I noticed: the segment start events go like this, with a
> duration of 99:99:99 and then complaints about duration caching:
>
> creating segment event time segment start=0:00:00.066733333, stop=0:00:
> 14.347666666, rate=1.000000, applied_rate=1.000000, flags=0x00,
> time=0:00:00.000000000, base=0:00:00.000000000, position 0:00:00.066733333,
> duration 99:99:99.999999999
> 0:00:00.675879247 14212      0x1f99a00 FIXME                    bin
> gstbin.c:4008:gst_bin_query: implement duration caching in GstBin again
> 0:00:00.675908879 14212      0x1f99a00 FIXME                    bin
> gstbin.c:4008:gst_bin_query: implement duration caching in GstBin again
> 0:00:00.675919229 14212      0x1f99a00 FIXME                    bin
> gstbin.c:4008:gst_bin_query: implement duration caching in GstBin again
>
> I'm not sure if that has much to do with what I'm seeing, but it would
> mean the segment starts on the third frame(at apprximately 30fps).
>
> Thanks in advance for looking!
>
> -d
>
>
>
> On Mon, Jul 14, 2014 at 11:35:09AM -0400, Luis de Bethencourt wrote:
>
>> Hi David,
>>
>> Can you generate the log again with a lower debug level? Your current log
>> is 100mb big and very very long. Would be easier to debug with a lower
>> debug level.
>>
>> Thanks,
>> Luis
>>
>>
>> On 11 July 2014 08:35, David W. Harks <dave at dwink.net> wrote:
>>
>>  GStreamer wizards,
>>>
>>> My GStreamer-based app is intended to play H.264 video clips back-to-back
>>> in gapless fashion. It uses playbin and the 'about-to-finish' signal to
>>> change URIs, as the various examples and advice about this shows.
>>>
>>> Unfortunately, I'm seeing a 5-10 frame 'pause' when switching URIs. What
>>> seems to be happening is that the sink stops rendering frames for a brief
>>> period, leaving a static frame visible, then 'catches up' and starts
>>> rendering again, skipping the first few frames of the next clip. I tried
>>> taking the same clips and playing them with gst-play-1.0 --gapless and I
>>> get the same result.
>>>
>>> My question is, how can I narrow down what's going on here? And is there
>>> anything I can do to get frame-perfect transitions? I created a debug log
>>> with GST_DEBUG=5 here: https://www.dropbox.com/s/
>>> 0rdzlrcaz77wbkc/dbg.out.gz
>>>
>>> Unfortunately, I'm not quite sure how to interpret this output.
>>>
>>> Thanks for your expertise!
>>>
>>> -d
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>>
>  _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140714/7e509471/attachment-0001.html>