[gst-devel] MP4 file streaming over RTP

Farah farahakhtar_24c at yahoo.com
Mon May 31 17:22:38 CEST 2010



Thanks a lot Irfan, for the help.

Ok, one correction: I was wrong about it being an h264 stream. I just
checked and all this problem is coming with an mpeg-4 stream. Sorry, i got
it wrong initially.

>> May be i guess since already you have demuxed the mp4 file, it is no
>> longer in mp4 container file format. Streaming of mp4 files is generally
>> supported if it has hint tracks.

==>
You're right. It's not in mp4 format when it's received but an mpeg4 stream
but that's why we are using "ffmux_mp4" muxer in the pipeline before putting
it in a file. Part of pipeline:

"! rtpmp4vdepay ! ffmux_mp4 ! filesink location=test.mp4" 

Shouldnt that work? Is there something more I should do to put it in an mp4
file?

Can you gimme a simple pipeline that takes an mpeg-4 stream to be stored as
an .mp4 container? (And adds hint tracks to it? Shoudnt they still be there
since it was already in an mp4 file from where we streamed it in the first
place?)  I thought a muxer in gstreamer would do that. I have used MP4Box to
add hint tracks to h264 files and even used some other softwares to do the
conversion from h264 file to mp4 file. These files play fine but I'm not
able to do it using gstreamer. 

Also,
>> rtpmp4vpay is rtp packetizer for mpeg4 video. As you told you have h264
>> video stream, You cannot >>packetize with rtp mpeg4 paketizer.

As I said, I just checked that I'm wrong on that. It was an mpeg-4 stream
all along! 

I did the same thing with an mpeg-4 stream AGAIN and the problem remains the
same. Though, if the packetizer was the problem, should my stream PLAY fine?
Coz it does play fine using the same encoder and decoder and rtp payloaders.
Caps given to the receiver are those generated by the sender. I think it is
in these caps that the receiver finds the stream information (MP4V-ES). So,
I dont think the packetizer is the problem with the file being saved. Let me
copy the sender and receiver pipelines here. This is the case where they
PLAY fine. I only replace the last part of the receiver :

"! rtpmp4vdepay ! ffdec_mpeg4 ! xvimagesink" with "! rtpmp4vdepay !
ffmux_mp4 ! filesink location=test.mp4"

and that way, it doesnt work. The file is empty, 0 bytes and I have to press
Ctrl+c to terminate the receiver. The sender exits having received EOS from
its own side.


Sender:

gst-launch-0.10 -v  filesrc location=Filename1.mp4 ! qtdemux !
rtpmp4vpay pt=96 ! udpsink host=127.0.0.1 port=42040 sync=false

Receiver:

gst-launch-0.10 -v  udpsrc port=42040 caps="application/x-rtp,
media=(string)video, clock-rate=(int)90000,
encoding-name=(string)MP4V-ES, profile-level-id=(string)1,
config=(string)000001b001000001b58913000001000000012000c48d885dad0a041e1463000001b24c61766335322e32302e30,
payload=(int)96, ssrc=(guint)444569327, clock-base=(guint)144078977,
seqnum-base=(guint)4650" ! rtpmp4vdepay ! ffdec_mpeg4 ! xvimagesink
-- 
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/MP4-file-streaming-over-RTP-tp2236379p2237514.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.




More information about the gstreamer-devel mailing list