GNOME Bugzilla – Bug 754664
Can't link tsdemux to aacparse and rtpmp4gpay
Last modified: 2018-11-03 15:03:56 UTC
I'm trying to extract AAC audio from an mpeg2 ts stream and post it off in it's own rtp stream. This the the command line: gst-launch-1.0.exe udpsrc caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,payload=(int)96" port=41010 address=229.10.10.10 ! rtpmp2tdepay ! queue ! tsdemux ! "audio/mpeg" ! aacparse ! "audio/mpeg,stream-format=(string)raw" ! rtpmp4gpay ! fakesink -v It gets as far as this graph before failing: http://postimg.org/image/guvorbizt/full/ However, if I remove rtpmp4gpay and hook aacparse direct to fakesink it creates this working graph: http://postimg.org/image/rm1lqqxrx/full/ As a test the following command line using audiotestsrc appears to produce the same issue: gst-launch-1.0.exe audiotestsrc ! voaacenc ! mpegtsmux ! tsdemux ! "audio/mpeg" ! aacparse ! rtpmp4gpay ! fakesink
tsdemux can't differentiate from audio/mpeg, mpegversion=2 or mpegversion=4 when it is using ADTS because there is no further info about it. Right now it always considers it to be 2. In this case, it isn't. Then it fails linking because aacparse will only accept mpegversion=4 because downstream can't handle mpegversion=2 and we get not-linked error.
Could you make a test stream available by any chance? Just use ... ! rtpmp2tdepay ! filesink location=test.ts And then attach the first MB or so here to the bug (head --bytes=1M test.ts > start.ts).
Hi Thiago Sousa Santos Thank you. But I'm a little confused as the second graph I uploaded without rtpmp4gpay shows aacparse accepting mpegversion=2 on the left side and pushing out mpegversion=4 on the right side. Hi Tim-Philipp Müller I'll get a sample ASAP
Created attachment 311004 [details] ts stream sample Sample attached as requested
(In reply to davywj from comment #3) > Hi Thiago Sousa Santos > > Thank you. But I'm a little confused as the second graph I uploaded without > rtpmp4gpay shows aacparse accepting mpegversion=2 on the left side and > pushing out mpegversion=4 on the right side. In the 2nd pipeline you have fakesink instead of the payloader. The payloader only accepts mpegversion=4 so when aacparse and tsdemux are linking aacparse will report only to accept mpegversion=4 as it can't convert from mpegversion=2 to 4. It can actually fix the caps from 2 to 4, but that's not converting it. So it fails linking because it is assumed that tsdemux is not lying on its caps.
Thank you for that explanation. Why does aacparse bother to convert the mpegversion caps when fakesink will accept ANY? Further more, the avdec_aac decoder accepts both mpegversion 2 and 4 and so it will decode the output of aacparse. However, looking at the graph this creates, aacparse is still converting caps from 2 to 4 even though avdec_aac accepts 2. I would expect that if mpegversion=2 goes in to aacparse and it is unable to convert then mpegversion=2 should come out of it. This unexpected change from 2 to 4 is what led me to believe rtpmp4gpay would work.
(In reply to davywj from comment #6) > Thank you for that explanation. > > Why does aacparse bother to convert the mpegversion caps when fakesink will > accept ANY? > > Further more, the avdec_aac decoder accepts both mpegversion 2 and 4 and so > it will decode the output of aacparse. However, looking at the graph this > creates, aacparse is still converting caps from 2 to 4 even though avdec_aac > accepts 2. > > I would expect that if mpegversion=2 goes in to aacparse and it is unable to > convert then mpegversion=2 should come out of it. This unexpected change > from 2 to 4 is what led me to believe rtpmp4gpay would work. It is not actually converting, it just fixes the caps because it is wrong. It is mpegversion=4 just that tsdemux says it is mpegversion=2 but it isn't.
Sorry, I meant fixing the caps not converting. I know there is no conversion going on. If aacparse identifies the stream as mpegversion 4 and fixes the caps, why then doesn't rtpmp4gpay accept it? You said in comment 5 that it won't link because it assumes that tsdemux isn't lying about its caps. But why does rtpmp4gpay care about tsdemux when aacparse is in between?
rtpmp4gpay wants audio/mpeg mpegversion: 4 stream-format: raw but aacparse outputs audio/mpeg mpegversion: 4 stream-format: adts It needs to convert to raw, but doesn't seem to do that yet. See bug #615740 and bug #723551. In fact, it seems this is a duplicate of bug #723551.
I think it doesn't even get linked, indeed #723551 is related but there is one extra step here that is the negotiation step. Edward was looking if there is any way to differentiate mpeg versions 2 and 4 from mpegts without having to look into the data itself. It would be the easiest solution for this first step.
I didn't see any descriptors that we can use in the sample file. Also, my reading of the specs is that this is not a valid stream and ADTS should signal version 2 in this case for this stream id.
I can't say whether or not the stream is valid. It comes from a hardware encoder and plays happily in vlc, ffmpeg and gstreamer. Looking at one of the PES packets for the audio stream I can see the ADTS syncword (0xFFF) followed by a 1 indicating mpeg version 2. The encoder can also be set to stream ADTS directly in RTP payload. I put the following pipeline on it: udpsrc ! rtpmp4gdepay ! aacparse ! rtpmp4gpay ! multiudpsink In this case rtpmp4gpay is happy to accept the output of aacparse. The RTP packets coming out contain raw AAC (RFC3640). The RTP payload of the input stream contains the same ADTS header found in the MPEG TS stream. Setting the debug to level 6 I can see this in the output: 0:00:04.721707416 5364 0306D9A0 LOG aacparse gstaacparse.c:459:gst_aac_parse_check_adts_frame: ADTS frame found, len: 311 bytes so I can see aacparse is recognizing the ADTS frames and does in fact convert them to raw.
-- 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/218.