[Bug 780746] qtmux doesn't remove 'trak' atom when request pad is removed

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=780746

--- Comment #2 from Brendan Shanks <brendan.shanks at teradek.com> ---
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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.