problems creating a live stream with AAC using rtp to quicktime player

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

problems creating a live stream with AAC using rtp to quicktime player

eshoquist

Hi,

 

I am trying to create a pipeline to stream AAC using rtp, then using Darwin Streaming Server to relay it to a client’s quicktime player. I am able to do this successfully with video (by itself) with the following pipeline

 

   gst-launch -v v4l2src always-copy=false do-timestamp=true \         

                num-buffers=$(( 30 * 60 * 5 )) ! \                     

        video/x-raw-yuv, format=\(fourcc\)UYVY, \                      

                width=720, height=480, framerate=\(fraction\)30/1 ! \  

        TIVidenc1 codecName=h264enc engineName=codecServer \           

                rateControlPreset=2 bitRate=512000 iColorSpace=UYVY \  

                resolution=720x480 frameRate=30 ! \                    

        rtph264pay scan-mode=bytestream ! \                            

        udpsink host=225.1.1.2 auto-multicast=true port=9010

 

Audio however seems to be a different beast. I’ve found even when piping AAC to a filesink, in order for quicktime to play the audio, I have to use qtmux or mp4mux after the encoding phase.  When I attempt to mimic my video pipeline for audio like the following:

 

gst-launch -v alsasrc device=hw:0,0 num-buffers=$((30*60*5)) ! \

        audio/x-raw-int, endianness=1234 ! \

        queue ! \

        TIAudenc1 engineName=codecServer codecName=aacheenc ! \

        qtmux  ! \

        rtpmp4vpay pt=96 ! \

        udpsink host=225.1.1.2 port=9010 auto-multicast=true

 

The pipeline doesn’t play – I get errors linking mp4mux to rtpmp4apay (caps don’t match). Using gst-inspect I see that qtmux has only 1 src - video/quicktime, and when looking at the rtpmp4 plugins none of them take that as a sink. So I’m unclear how I can stream the audio with rtp. Is there a different mux I can use that doesn’t put out video/quicktime, but still works with quicktime player? Or is there some other plugins to use between qtmux and one of the rtpmp4[a,v,g]pay plugins that will convert the caps to video/mpeg?

 

Thanks

eric


_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: problems creating a live stream with AAC using rtp to quicktime player

Marco Ballesio
Hi,

On Fri, May 20, 2011 at 10:33 PM, Eric Shoquist <[hidden email]> wrote:
..snip..
 

Audio however seems to be a different beast. I’ve found even when piping AAC to a filesink, in order for quicktime to play the audio, I have to use qtmux or mp4mux after the encoding phase.


it's understandable as long as it's about playing local files.. streaming is a different beast and usually the muxer role is played from the payloader (see below).

 

  When I attempt to mimic my video pipeline for audio like the following:

 

gst-launch -v alsasrc device=hw:0,0 num-buffers=$((30*60*5)) ! \

        audio/x-raw-int, endianness=1234 ! \

        queue ! \

        TIAudenc1 engineName=codecServer codecName=aacheenc ! \

        qtmux  ! \

        rtpmp4vpay pt=96 ! \

        udpsink host=225.1.1.2 port=9010 auto-multicast=true

 

The pipeline doesn’t play – I get errors linking mp4mux to rtpmp4apay (caps don’t match). Using gst-inspect I see that qtmux has only 1 src - video/quicktime, and when looking at the rtpmp4 plugins none of them take that as a sink. So I’m unclear how I can stream the audio with rtp. Is there a different mux I can use that doesn’t put out video/quicktime, but still works with quicktime player? Or is there some other plugins to use between qtmux and one of the rtpmp4[a,v,g]pay plugins that will convert the caps to video/mpeg?


you should use NO muxers if yoiu're already payloading, that is, try connecting the encoder directly to the payloader. It should just work (r).

Besides, you should make sure that in the rtpsp negotiation (I didn't understand how it's done prior using these pipelines, but I'll assume some magic happens under the hood) the audio format is specified as something like MP4A-LATM (as for rfc3016). Indeed, RealMedia has its own payloading format and it might happen that the negotiation assumes that one to be used.

Regards

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel