RTP streaming of a m4v file

[rajesh nair-6]

Guys,
I want to stream a m4v file using rtp.
I have installed Gstbadplugin 0.10.9 to make use of the gstrtpbin available in it.I want a step by step procedure to stream the m4v file so that it can be played by a vlc player at the receiver's end
Thanks in advance
Rajesh



     

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Ron McOuat]

I have a question on the queue element.

I have a video source which is linked to a tee element. On the src pad
side of the tee element I add a queue and a processing bin for each branch.

One of the branches of the tee I would like to sometimes record for a
period of time and then turn off while the rest of the pipeline runs and
when I restart I would like to record N sec back from the current time.
I set the queue to leak old buffers using leaky=2 with the
max-size-time=N*10^9 for N sec.

When I want the bin to stop recording, I block the src pad of the queue
and send EOS to the sink pad of the bin queue is connected to and then
unlink the processing bin.

When I resume I make a new processing bin, link it in, send a new
segment to the sink pad of the processing bin and unblock the queue src pad.

This all works fine except for one problem. To figure it out I added a
src pad buffer probe to queue and printed out the buf.timestamp with the
following output which is running at 8 fps:

Element   Timestamp
queue 12098600000
queue 12222186000
queue 12345175000
queue 12474597000
queue 12604791000
queue 12721661000
stop


resume
queue 12844894000
queue 25230688000
queue 25346042000
.
Output cut to shorten listing
.
queue 35591986000
queue 35723800000
queue 35842484000
stop

resume
queue 35973339000
queue 60480289000
queue 60603448000


The queue holds one more buffer from the previous sequence based on the
timestamp and then passes in buffers starting N sec older than the
current time. The video source puts the time in the image so I believe
the buffer timestamp is correct based on observation of the video. This
messes up the mux timing further downstream with the first buffer
relative to the remaining buffers could be hours old. I reset the base
time in the downstream bin to get a zero relative time but this is set
from the first buffer.

I got around it by having the queue src pad buffer probe drop the first
buffer after a resume by returning False.

Is there something else I should be doing or is it possible this is a bug?

Thanks

Ron

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Marc Leeman]

Doesn't

gst-launch filesrc location=file.m4v ! rtpmp4vpay send-config=true ! udpsink host=224.224.224.224. port=2244

sound viable?

--
  greetz, marc
There is no likelihood man can ever tap the power of the atom.
                -- Robert Millikan, Nobel Prize in Physics, 1923
crichton 2.6.26 #1 PREEMPT Tue Jul 29 21:17:59 CDT 2008 GNU/Linux

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[rajesh nair-6]

Thanks Marc,
I tried what you suggested but got the following errors
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
ERROR: from element /pipeline0/rtpmp4vpay0: Element doesn't implement handling of this stream. Please file a bug.
Additional debug info:
gstbasertppayload.c(697): gst_basertppayload_push (): /pipeline0/rtpmp4vpay0:
subclass did not specify clock-rate
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
FREEING pipeline ...
I tried to stream an MP4 file using the pipeline you suggested but the result was the same
Regards,
Rajesh



--- On Wed, 4/22/09, Marc Leeman <[hidden email]> wrote:

> From: Marc Leeman <[hidden email]>
> Subject: Re: [gst-devel] RTP streaming of a m4v file
> To: [hidden email], "Discussion of the development of GStreamer" <[hidden email]>
> Date: Wednesday, April 22, 2009, 1:20 PM
> Doesn't
>
> gst-launch filesrc location=file.m4v ! rtpmp4vpay
> send-config=true ! udpsink host=224.224.224.224. port=2244
>
> sound viable?
>
> --
>   greetz, marc
> There is no likelihood man can ever tap the power of the
> atom.
> -- Robert Millikan, Nobel Prize in Physics, 1923
> crichton 2.6.26 #1 PREEMPT Tue Jul 29 21:17:59 CDT 2008
> GNU/Linux

     

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel