GES 1.12.4 and 1.14.2: Problem with slide transitions
David Ing
ding at panopto.com
Fri Aug 10 05:01:05 UTC 2018
I forgot to say that the log messages appear at the time of each slide
transition.
On Thu, Aug 9, 2018 at 9:58 PM, David Ing <ding at panopto.com> wrote:
> I wrote a sample application to demonstrates a problem that I'm having
> with GES:
>
> https://github.com/adaviding/gstreamer-playground/blob/
> 680b203603ffa35e27493e28fe1620edacb8d655/ges-slide-composition/main.cpp
>
> The problem is with scenario #2 only, and I observe the problem running on
> Windows 10 with GES 1.12.4 and 1.14.2. I have only tried this on Windows.
>
> Scenario 1 ( *#define INCLUDE_FOREGROUND_VIDEO false* )
>
> - The sample application builds a video consisting of 5 jpeg images
> (i.e. "slides"). Each slide is up for 2 seconds so the movie is 10 seconds
> long. There is no audio in the sample application, and no audio track.
>
> Scenario 2 ( *#define INCLUDE_FOREGROUND_VIDEO true* )
>
> - This is just like scenario 1, but there is also a picture-in-picture
> style video in the corner of the screen, in front of the slides. I am
> using a video which has no audio track.
>
> The problem is that in scenario #2, during the slide transition (which
> occurs every 2 seconds), the screen goes black for a fraction of a second.
> Interestingly, the foreground video does not go black ... only the portion
> of the screen subtended by the slides does this (which is most of the
> screen). And this happens for every slide transition.
>
> Some other things to note about my application.
>
> - I am using a GESTimeline with a GstPipeline (not GESPipeline)
> because I need to encode the composition in many different ways.
> Computational efficiency is of paramount importance, which means I only
> want to execute the pipeline once. I cannot achieve this using a
> GESPipeline, so I need to use a GstPipeline
> - I wired the NleComposition "query-position" signal so that it
> fetches the current position of the GstPipeline.
>
> Running with *--gst-debug=3*, I observe the following logs under each
> scenario.
>
> - No highlights = the log appears in both scenarios.
> - Yellow highlights = the log only appears in scenario #2.
> - Pink highlights = the log appears in both scenarios, but is being
> repeated more often.
>
>
> Scenario 1:
>
> 0:00:09.110542588 13280 0000016292B0B940 WARN aggregator
> gstaggregator.c:1397:gst_aggregator_query_latency_
> unlocked:<gessmartmixer0-compositor> Latency query failed
> 0:00:09.110791659 13280 0000016292B0BD00 WARN GST_URI
> gsturi.c:837:gst_file_utils_canonicalise_path: FIXME: canonicalise win32
> path
> 0:00:09.113365512 13280 0000016292B0BD00 WARN basesrc
> gstbasesrc.c:3480:gst_base_src_start_complete:<source> pad not activated
> yet
> 0:00:09.115511241 13280 0000016292B0BD00 WARN basesrc
> gstbasesrc.c:3480:gst_base_src_start_complete:<source> pad not activated
> yet
> 0:00:09.118815897 13280 0000016292D3CD00 FIXME videodecoder
> gstvideodecoder.c:928:gst_video_decoder_drain_out:<jpegdec9> Sub-class
> should implement drain()
> 0:00:09.120799711 13280 0000016292D3CD00 FIXME videodecoder
> gstvideodecoder.c:928:gst_video_decoder_drain_out:<jpegdec9> Sub-class
> should implement drain()
> 0:00:09.121881327 13280 0000016292D3CD00 WARN videodecoder
> gstvideodecoder.c:2438:gst_video_decoder_chain:<jpegdec9> Received buffer
> without a new-segment. Assuming timestamps start from 0.
>
>
> Scenario 2:
>
> 0:00:09.250672090 16592 000001F366DE7200 WARN aggregator
> gstaggregator.c:1397:gst_aggregator_query_latency_
> unlocked:<gessmartmixer0-compositor> Latency query failed
> 0:00:09.250841298 16592 000001F366DECE40 WARN GST_URI
> gsturi.c:837:gst_file_utils_canonicalise_path: FIXME: canonicalise win32
> path
> 0:00:09.253852393 16592 000001F366DECE40 WARN basesrc
> gstbasesrc.c:3480:gst_base_src_start_complete:<source> pad not activated
> yet
> 0:00:09.255128014 16592 000001F366DECE40 WARN basesrc
> gstbasesrc.c:3480:gst_base_src_start_complete:<source> pad not activated
> yet
> 0:00:09.256701573 16592 000001F366DECE40 WARN GST_URI
> gsturi.c:837:gst_file_utils_canonicalise_path: FIXME: canonicalise win32
> path
> 0:00:09.257970631 16592 000001F366DECAC0 WARN qtdemux
> qtdemux_types.c:228:qtdemux_type_get: unknown QuickTime node type uuid
> 0:00:09.262471410 16592 000001F366DECAC0 WARN qtdemux
> qtdemux_types.c:228:qtdemux_type_get: unknown QuickTime node type pasp
> 0:00:09.258281331 16592 000001F366DECE40 WARN basesrc
> gstbasesrc.c:3480:gst_base_src_start_complete:<source> pad not activated
> yet
> 0:00:09.263756148 16592 000001F366DECAC0 WARN qtdemux
> qtdemux.c:3017:qtdemux_parse_trex:<qtdemux5> failed to find fragment
> defaults for stream 1
> 0:00:09.265397171 16592 000001F366DECE40 WARN basesrc
> gstbasesrc.c:3480:gst_base_src_start_complete:<source> pad not activated
> yet
> 0:00:09.266319062 16592 000001F366DECAC0 WARN basesrc
> gstbasesrc.c:2389:gst_base_src_update_length:<source> processing at or
> past EOS
> 0:00:09.268796277 16592 000001F366F6A500 FIXME videodecoder
> gstvideodecoder.c:928:gst_video_decoder_drain_out:<jpegdec9> Sub-class
> should implement drain()
> 0:00:09.273111438 16592 000001F366F6A500 FIXME videodecoder
> gstvideodecoder.c:928:gst_video_decoder_drain_out:<jpegdec9> Sub-class
> should implement drain()
> 0:00:09.274373567 16592 000001F366F6A500 WARN videodecoder
> gstvideodecoder.c:2438:gst_video_decoder_chain:<jpegdec9> Received buffer
> without a new-segment. Assuming timestamps start from 0.
> 0:00:09.313360990 16592 000001F366CFBD00 WARN GST_PADS
> gstpad.c:4161:gst_pad_peer_query:<queue11:src> could not send sticky
> events
> 0:00:09.315771835 16592 000001F366DE7D00 WARN aggregator
> gstaggregator.c:1397:gst_aggregator_query_latency_
> unlocked:<gessmartmixer0-compositor> Latency query failed
>
>
> Does anybody know how I might fix the problem with scenario #2?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20180809/6fa2f46a/attachment.html>
More information about the gstreamer-devel
mailing list