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 778330 - qtmux: Creates two edit lists with reserved-* options enabled
qtmux: Creates two edit lists with reserved-* options enabled
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 1.11.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-02-08 10:44 UTC by Vivia Nikolaidou
Modified: 2017-02-09 00:28 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Vivia Nikolaidou 2017-02-08 10:44:27 UTC
I have the following pipeline:

gst-launch-1.0 -e qtmux name=m reserved-max-duration=43200000000000 reserved-moov-update-period=5000000000 ! filesink location=arxeio.mov videotestsrc ! x264enc ! h264parse ! queue ! m.

I let it run for a few seconds and then inspect it with qtdump:

  edit atom (edts)
   edit list (elst)
    version 0
    flags 0
    total_entries 2
    edit list table
     duration 100
     time 200
     rate 1.000000
    edit list table
     duration 573100
     time 200
     rate 1.000000
Comment 1 Vivia Nikolaidou 2017-02-08 12:43:53 UTC
Maybe x264 was a bad example. because it has to write two edit lists anyway. So I tried with prores instead, and adding an audio stream just in case:

gst-launch-1.0 -e qtmux name=m reserved-max-duration=43200000000000 reserved-moov-update-period=5000000000 ! filesink location=arxeio.mov videotestsrc ! avenc_prores ! queue ! m. audiotestsrc ! queue ! m.

When I have the reserved-* options blank (tried this in git master), the edit list works correctly.

When I have the reserved-* options enabled, I observe either no edit list at all or two of them. It apparently never worked correctly. I ran a git bisect (assuming no edit lists is "good") and it gave me this commit, though I'm not sure if this knowledge can be of any use:

7fb278d7d230c51c28754e67e05ad0e836acc28f is the first bad commit
commit 7fb278d7d230c51c28754e67e05ad0e836acc28f
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Mon Nov 14 14:44:11 2016 +0200

    qtmux: Always write edit lists for the tracks to give a more accurate duration
    
    Always write an edit list for the whole track. In general this is not
    necessary except for the case of having a gap or DTS adjustment but
    it allows to give the whole track's duration in the usually more
    accurate media timescale.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=774403

:040000 040000 2a16328a01c19028a571eeb6df948d78bd0c4f62 dc3417a325f11d6c28e92aec71ff592f7a7d0964 M	gst
Comment 2 Sebastian Dröge (slomo) 2017-02-08 15:26:43 UTC
commit 1426a55a83f054d8e2da687f3bb30cde009f9221
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Wed Feb 8 17:24:26 2017 +0200

    qtmux: Clear edit lists every time we recalculate them
    
    We recalculate them, so any old information has to be forgotten.
    Otherwise we write invalid edit lists when writing headers multiple
    times.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=778330
Comment 3 Jan Schmidt 2017-02-09 00:28:28 UTC
I was a bit confused by this fix because the existing code to create an edit list entry for the 'entire track' calls atom_trak_set_elst_entry() - which seems like it should replace the entry at index 1 in the edit list.

In fact, the function either replaces an existing entry, or simple appends at whatever index if the entry doesn't yet exist - so calling atom_trak_set_elst_entry(1) on an empty edit list actually creates entry 0. Confusing.