GES 1.12.4 and 1.14.2: Problem with slide transitions

[David Ing]

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/ee19891a/attachment-0001.html>