avdec_g722
Locked
 
|
Hi all… I’ve been playing with the 722 decoder because I’m looking at a telephony app. I create a g722 audio file with the following pipeline: gst-launch-1.0 alsasrc device=hw:0,0 ! audio/x-raw, rate=48000, channels=2, width=16, depth=16 ! audioresample ! audioconvert ! audio/x-raw, format=S16LE, channels=1, rate=16000 ! avenc_g722 ! filesink location=./testing.g722 my issue come down to decoding this input file. I pared down the decoding to the following pipeline: gst-launch-1.0 filesrc location=./testing.g722 ! audio/G722 ! avdec_g722 ! fakesink and still get an error ERROR: from element /GstPipeline:pipeline0/GstFileSrc:filesrc0: Internal data stream error. There is some additional information that gstbasesrc.c (3055) streaming stopped, reason error (-5) Running in higher debug levels I get more information that in gstaudiodecoder.c (2199) indicates that it is an unsupported format. The code seems to fail when checking if we should change from a byte to time format (gstaudiodecoder.c:2184)
that either the context.d_estimate_rate is false, or the format couldn’t be converted from a bytes format to a time format.
Where do I look now for the cause of this error? I would think that a file created with the avenc_g722 would be able to be decoded with the avdec_g722. Am I missing something fundamental? My version of gstreamer, gstreamer-libav, gstreamer-plugins-base are all 1.14.4 Thanks in advance, Tom Green _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Hi Thomas,
> my issue come down to decoding this input file. I pared down the > decoding to the following pipeline: > > gst-launch-1.0 filesrc location=./testing.g722 ! audio/G722 ! > avdec_g722 ! fakesink > > and still get an error > > ERROR: from element /GstPipeline:pipeline0/GstFileSrc:filesrc0: > Internal data stream error. > > There is some additional information that gstbasesrc.c (3055) > streaming stopped, reason error (-5) > > Running in higher debug levels I get more information that in > gstaudiodecoder.c (2199) indicates that it is an unsupported format. > The code seems to fail when checking if we should change from a byte > to time format (gstaudiodecoder.c:2184) that either the > context.d_estimate_rate is false, or the format couldn’t be converted > from a bytes format to a time format. > > Where do I look now for the cause of this error? I would think that > a file created with the avenc_g722 would be able to be decoded with > the avdec_g722. Am I missing something fundamental? Two things: 1) a "not-negotiated" error usually indicates a problem with the caps (media format signalling): either caps are wrong, incomplete or there were no caps signalled. In this case the problem is likely that filesrc just outputs data without any caps, and the decoder wants caps being signalled. You could fix this by adding a capsfilter with the right G722 caps, but: 2) the audio decoder probably wants the data being fed to it being nicely packetised and timestamped. Typically such data will be packetised by a container (e.g. matroska, quicktime) or transport (RTP). You could try adding a matroskamux to your creation pipeline, and a matroskademux to your playback pipeline, otherwise the decoder will be fed audio data in chunks of 4kB (or whatever), which is probably not right. Cheers Tim -- Tim Müller, Centricular Ltd - http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Tim,
Thank you for the quick response. I've been playing around with this, and adding the muxer/de-muxer seems to work. So, as a next step, I'm taking a live stream of G722 data and trying to decode that: My pipeline is (in c++ code now): appsrc is-live=true, max-bytes=1 ! audio/G722, rate=16000, channels=1 ! avdec_g722 ! audioresample ! audioconvert ! audio/x-raw, rate=48000, channels=2, width=16, depth=16 ! alsasink device=hw:0,3 and I'm back to getting the error gstbasesrc.c(3055): gst_base_src_loop (): /GstPipeline:audio_decode_pipeline/GstAppSrc: appsrc0: streaming stopped, reason error (-5) Error from alsasink0: The stream is in the wrong format. I was thinking the appsrc element added a clock so that the timestamp would be recoded. I also tried the appsrc with the property "do-timestamp" set to true, and alas, no difference. The caps seem to be fully defined, and I'm sure the incoming audio is in G722 format. Anything else I could be getting wrong? -----Original Message----- From: gstreamer-devel [mailto:[hidden email]] On Behalf Of Tim Müller Sent: Friday, July 26, 2019 2:09 AM To: [hidden email] Subject: Re: avdec_g722 [EXTERNAL] Hi Thomas, > my issue come down to decoding this input file. I pared down the > decoding to the following pipeline: > > gst-launch-1.0 filesrc location=./testing.g722 ! audio/G722 ! > avdec_g722 ! fakesink > > and still get an error > > ERROR: from element /GstPipeline:pipeline0/GstFileSrc:filesrc0: > Internal data stream error. > > There is some additional information that gstbasesrc.c (3055) > streaming stopped, reason error (-5) > > Running in higher debug levels I get more information that in > gstaudiodecoder.c (2199) indicates that it is an unsupported format. > The code seems to fail when checking if we should change from a byte > to time format (gstaudiodecoder.c:2184) that either the > context.d_estimate_rate is false, or the format couldn’t be converted > from a bytes format to a time format. > > Where do I look now for the cause of this error? I would think that a > file created with the avenc_g722 would be able to be decoded with the > avdec_g722. Am I missing something fundamental? Two things: 1) a "not-negotiated" error usually indicates a problem with the caps (media format signalling): either caps are wrong, incomplete or there were no caps signalled. In this case the problem is likely that filesrc just outputs data without any caps, and the decoder wants caps being signalled. You could fix this by adding a capsfilter with the right G722 caps, but: 2) the audio decoder probably wants the data being fed to it being nicely packetised and timestamped. Typically such data will be packetised by a container (e.g. matroska, quicktime) or transport (RTP). You could try adding a matroskamux to your creation pipeline, and a matroskademux to your playback pipeline, otherwise the decoder will be fed audio data in chunks of 4kB (or whatever), which is probably not right. Cheers Tim -- Tim Müller, Centricular Ltd - http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
| Free forum by Nabble | Edit this page |