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 721602 - Pitivi renders videoless files when the projects begins with an image bigger then the project settings
Pitivi renders videoless files when the projects begins with an image bigger ...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-editing-services
git master
Other Linux
: Normal normal
: 1.5.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-01-05 22:57 UTC by Ulisse Perusin
Modified: 2015-06-24 14:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Project files with and without the rendering bug (432.41 KB, application/gzip)
2014-01-05 22:58 UTC, Ulisse Perusin
Details

Description Ulisse Perusin 2014-01-05 22:57:45 UTC
The project is set to a resolution of 960x400 px (same of the "tears of steel" sample).

If I start the timeline with an image double in size (1920x800) and the image is involved in a transition, Pitivi renders a videoless file (tried webm/vp8 and ogg/theora).

If the timeline starts with an image matching the project resolution, and the bigger image comes later, it produces a working file with audio and video.

Pitivi was compiled from GIT with the script from the wiki, on Fedora 20 64bit, and it was forced to use a local build of Gstreamer instead of the system wide one.
Comment 1 Ulisse Perusin 2014-01-05 22:58:42 UTC
Created attachment 265401 [details]
Project files with and without the rendering bug
Comment 2 Thibault Saunier 2014-11-01 08:37:14 UTC
This particular bug has been fixed:

commit 0a903cdd35b35662463eb289e5c46f0a0121056c
Author: Thibault Saunier <thibault.saunier@collabora.com>
Date:   Fri Mar 14 18:48:44 2014 +0100

    pipeline: Always set the encoding profile presence to 1
    
    We currenty do not support multiple tracks with same type in GESPipeline
    and we actually need to set the presence field to avoid a scenario where
    we have only video in a video track, and no audio in the audio track. So
    audiotestsrc is used and we end up encoding the whole audio stream but
    no decoded video frame as reached the decodebin src pad, so the pad
    has not been created and thus it will not be linked to the encodebin.
    On the audio part, the EOS will be emitted so fast that the resulting stream will
    not have any video in it as the muxer will not even have a video pad created.
    
    Setting the presence will ensure that the muxer does have a video pad
    (because of how encodebin behaves) and thus will create a pad for it
    and wait for its EOS.