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 583901 - aacparse fails for remuxing
aacparse fails for remuxing
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
0.10.22
Other Linux
: Normal normal
: 0.10.15
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-05-26 15:55 UTC by Christian Fredrik Kalager Schaller
Modified: 2009-10-15 14:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christian Fredrik Kalager Schaller 2009-05-26 15:55:24 UTC
Tested remuxing today and aacparse seems to fail with the pipeline below. The input file contains just aac audio and I created it using faac and qtmux. Replacing the aac audio with either mp3 audio or h264 video and using mp3parse or h264parse work, so I am pretty sure its the aac parser which is not doing the right thing here. Tried both Low Complexity and Main profile aac audio, same result for both:

gst-launch-0.10 filesrc location=aac.mov ! qtdemux ! aacparse ! qtmux ! filesink location=aac2.mov

Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /GstPipeline:pipeline0/GstQTDemux:qtdemux0: GStreamer encountered a general stream error.
Additional debug info:
qtdemux.c(2408): gst_qtdemux_loop (): /GstPipeline:pipeline0/GstQTDemux:qtdemux0:
streaming stopped, reason not-linked
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...
Comment 1 Tim-Philipp Müller 2009-05-26 23:03:44 UTC
The reason for this is that qtdemux caps with framed=true and aacparse accepts only caps with framed=false.

As I see it parsers should accept input with framed=true/false or the field absent entirely, but then that might cause problems with autoplugging. Arguably you don't really want an aacparse in there anyway, since last I checked it did unspeakable things to timestamps. Alternatively qtdemux could be made to output framed=false, which currently shouldn't make a big difference since aacparse has a rank of 0 and won't be autoplugged anyway, and faad accepts anything.
Comment 2 Christian Fredrik Kalager Schaller 2009-05-27 09:10:50 UTC
Are you saying that remuxing of AAC should work even without an aacparser?
Comment 3 Tim-Philipp Müller 2009-05-27 09:18:38 UTC
> Are you saying that remuxing of AAC should work even without an aacparser?

If qtdemux's output caps are correct (which is quite likely), yes. This might not be true for all other container formats though.
 

Comment 4 Christian Fredrik Kalager Schaller 2009-05-27 12:20:14 UTC
Personally I would prefer if I could keep aacparse in the pipeline, even if it did nothing and just passed the data through, since it is for me as an application developer much easier to deal with this codewise if all remuxing pipelines are essentially the same -
gst-launch-0.10  src uri ! emux name="demux" demux. ! videoparse ! queue ! mux name=mux ! sink uri demux. ! audioparse ! queue ! mux.
Comment 5 Thiago Sousa Santos 2009-10-15 14:04:11 UTC
Any possible solution(s) for this?

Would remove framed attribute from qtdemux output caps work and cause no harm to existing applications?
Comment 6 Mark Nauwelaerts 2009-10-15 14:17:35 UTC
[assuming here that the input contains proper raw AAC and codec-data]

aacparse used to break raw AAC streams, latest -bad should be fixed and have aacparse behave as passthrough on raw AAC:

commit 6c9a9d330418c5a0c7444dc30d12f0f706cc6514
Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk>
Date:   Fri Sep 25 17:02:53 2009 +0200

    aacparse: forego (bogus) parsing of already parsed (raw) input


[Feel free to re-open if it still fails]