After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 748978 - Video is frozen for a bit when a new clip starts
Video is frozen for a bit when a new clip starts
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-editing-services
git master
Other Linux
: Normal normal
: 1.12.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-05-05 21:11 UTC by Alex Băluț
Modified: 2017-10-16 12:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
track: Add a queue at the end of the composition (2.54 KB, patch)
2015-10-19 09:09 UTC, Thibault Saunier
none Details | Review

Description Alex Băluț 2015-05-05 21:11:54 UTC
You can notice the video is frozen for a small period when the second clip starts, this should not happen:
$ ges-launch-1.0  +clip 00159.MTS d=1  +clip 00159.MTS i=7.5 d=2
Comment 1 Alex Băluț 2015-05-05 21:23:15 UTC
Might be related..

This shows some noise in the video:
$ ges-launch-1.0  +clip 00159.MTS i=10 d=1

This is not fluid (MTS seeking broken?):
$ c="00159.MTS";  ges-launch-1.0  +clip "$c" i=0 d=1  +clip "$c" i=1 d=1  +clip "$c" i=2 d=1  +clip "$c" i=3 d=1  +clip "$c" i=4 d=1  +clip "$c" i=5 d=1
Comment 2 Alex Băluț 2015-09-27 21:06:15 UTC
I think this is the same bug:

The command below creates a file which every 2 seconds pauses for a bit. The video should be fluid though because there is a single video clip "+clip 00159.MTS layer=1 s=0 i=0 d=14.912000" and the others are transparent images on top of it.

ges-launch-1.0 \
+clip tmph72h4ynj.png layer=0 s=0 d=2 \
+clip tmph72h4ynj.png layer=0 s=2 d=2 \
+clip tmph72h4ynj.png layer=0 s=4 d=2 \
+clip tmph72h4ynj.png layer=0 s=6 d=2 \
+clip tmph72h4ynj.png layer=0 s=8 d=2 \
+clip tmph72h4ynj.png layer=0 s=10 d=2 \
+clip tmph72h4ynj.png layer=0 s=12 d=2 \
+clip tmph72h4ynj.png layer=0 s=14 d=0.912000 \
+clip 00159.MTS layer=1 s=0 i=0 d=14.912000 \
-o out.ogv

The files can be retrieved from the Pitivi ftp.
Comment 3 Thibault Saunier 2015-10-19 09:09:57 UTC
Created attachment 313646 [details] [review]
track: Add a queue at the end of the composition

Allowing better transition from one clip to another

We should make it easily configurable in the API
Comment 4 Alex Băluț 2015-10-19 11:12:44 UTC
Review of attachment 313646 [details] [review]:

With this patch the rendered ogv (see Comment 2) still has the same problems.
Comment 5 Thibault Saunier 2015-10-26 09:14:02 UTC
(In reply to Alex Băluț from comment #4)
> Review of attachment 313646 [details] [review] [review]:
> 
> With this patch the rendered ogv (see Comment 2) still has the same problems.

Indeed, my guess was wrong and the problem is not due to to small queues but it looks like it has to see with wrong timestamps or something like that as if we transcode/transmux that video, the result is correct.
Comment 6 Thibault Saunier 2017-10-16 12:27:31 UTC
Done by:

commit ce4d2d8102e98ca08c9ab9a6c511238174cf5a06
Author: Thibault Saunier <thibault.saunier@osg.samsung.com>
Date:   Sat Aug 19 11:42:57 2017 -0300

    pipeline: Allow up to 2 seconds queueing in the playsink video queue
    
    In playsink the default video queue max size is 3 buffers, which is
    sometimes not enough for our use case.
    
    Allow up to 2 seconds of buffered data, giving us more time to do
    the transition between clips, and thus avoiding dropping frames in
    the sink when bringing up new clip takes too much time.
    
    Differential Revision: https://phabricator.freedesktop.org/D1854