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 780746 - qtmux doesn't remove 'trak' atom when request pad is removed
qtmux doesn't remove 'trak' atom when request pad is removed
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.10.0
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-03-31 01:13 UTC by Brendan Shanks
Modified: 2018-11-03 15:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Brendan Shanks 2017-03-31 01:13:33 UTC
GStreamer 1.10.0 on my device is creating MP4 files (using qtmux) that qtdemux says are corrupt and refuses to decode.

The problem appears to be that the file contains additional streams/tracks which have timescales of 0, and I believe this is because my code requests pads from qtmux and then releases them before qtmux starts (goes to paused/playing).

gst_qt_mux_request_new_pad() creates a new trak atom and adds it to the moov with atom_moov_add_trak(), but gst_qt_mux_release_pad() never removes the trak from the moov atom.

I'll work on a patch, and I can attach a test file with the bad 'trak' atoms if anyone is interested.
Comment 1 Sebastian Dröge (slomo) 2017-03-31 09:16:29 UTC
A patch to remove the traks if they're empty would seem useful. But if they're not empty (they have samples), we should keep them and consider the streams as finished at the time of removal.
Comment 2 Brendan Shanks 2017-03-31 20:17:47 UTC
I was able to fix my application so it doesn't request/release pads from qtmux before buffers start arriving, and unfortunately I don't have time to work on this patch.

For future reference, here's what FFmpeg reports when it plays a file with these extra 'trak' atoms/streams (playback does work however):
[mov,mp4,m4a,3gp,3g2,mj2 @ 0xaa803900] stream 0, timescale not set  
[mov,mp4,m4a,3gp,3g2,mj2 @ 0xaa803900] stream 1, timescale not set


GStreamer qtdemux fails because of the timescale being 0, but doesn't specifically print that (might be a good thing to add):

$ gst-launch-1.0 filesrc location=../3mb.mp4 ! qtdemux ! fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstQTDemux:qtdemux0: This file is corrupt and cannot be played.
Additional debug info:
qtdemux.c(10575): qtdemux_parse_trak (): /GstPipeline:pipeline0/GstQTDemux:qtdemux0
Comment 3 GStreamer system administrator 2018-11-03 15:17:43 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/issues/359.