Re: h264 over RTSP to RTMP

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

Re: h264 over RTSP to RTMP

Maciej Sawicki
On Thu, Nov 19, 2009 at 12:12, Nick Chadwick <[hidden email]> wrote:

> That script has a few issues;
>
> Firstly, the frame-rate is "locked" to 10fps - If your video source isn't
> 10fps it won't work.
>
> Also, it de-codes and then re-encodes any streams you give it. Whilst for
> most things this "just works", it is by no means a high-perfomance solution.
>
> I've tried fixing both of these issues, but unfortunately my fix relied on
> the Gstreamer-java bindings, which didn't give me access to whether or not a
> packet was a keyframe or not. Needless to say, sending a video stream of
> all-keyframes is not very efficient >.<
>
> I gues what I'm trying to say is that if Red5 had in-built support for
> taking an RTSP stream, stripping the RTSP headers and re-streaming as a
> native RTMP stream, that would really kick-ass.
>
> In fact, I'd go so far as to say that if anyone were to implement this (I
> tried but I failed) I'd release some software which would allow you to build
> something like http://www.gaikai.com/ in, oh, I don't know, half an hour?
>

Thank you for explanation. I think re-encoding looks like a waste of
cpu time, but it's not problem for me. But 10 fps probably will not be
enough. Any way i will probably try it. Two more questions:
1. You sad that it's reencoded on server, what input streams are supported?
2. You sad that you use gstreamer wouldn't be easier to use xuggle?

regards,
Maciej Sawicki
Reply | Threaded
Open this post in threaded view
|

Re: h264 over RTSP to RTMP

Nick Chadwick
2009/11/22 Maciej Sawicki <viroos.pl@gmail.com>
On Thu, Nov 19, 2009 at 12:12, Nick Chadwick <[hidden email]> wrote:
> That script has a few issues;
>
> Firstly, the frame-rate is "locked" to 10fps - If your video source isn't
> 10fps it won't work.
>
> Also, it de-codes and then re-encodes any streams you give it. Whilst for
> most things this "just works", it is by no means a high-perfomance solution.
>
> I've tried fixing both of these issues, but unfortunately my fix relied on
> the Gstreamer-java bindings, which didn't give me access to whether or not a
> packet was a keyframe or not. Needless to say, sending a video stream of
> all-keyframes is not very efficient >.<
>
> I gues what I'm trying to say is that if Red5 had in-built support for
> taking an RTSP stream, stripping the RTSP headers and re-streaming as a
> native RTMP stream, that would really kick-ass.
>
> In fact, I'd go so far as to say that if anyone were to implement this (I
> tried but I failed) I'd release some software which would allow you to build
> something like http://www.gaikai.com/ in, oh, I don't know, half an hour?
>

Thank you for explanation. I think re-encoding looks like a waste of
cpu time, but it's not problem for me. But 10 fps probably will not be
enough. Any way i will probably try it. Two more questions:
1. You sad that it's reencoded on server, what input streams are supported?

Pretty much anything that ffmpeg supports can be decoded on the server - All you need is to know what URL your data resides at, and ffmpeg can figure it out from there. Since it gets totally decoded before being re-encoded its able to handle almost anything you can throw at it.

 
2. You sad that you use gstreamer wouldn't be easier to use xuggle?

regards,
Maciej Sawicki

Yeah, it'd be really easy to use Xuggle, but I couldn't find a way to take my RTSP stream, and stream it into RTMP without first de-coding and re-encoding it.

In my case, I'm encoding my RTSP stream using GStreamer, so i can put it into whatever format I want; so using Xuggle it was encoding from flv, decoding flv, re-encoding flv and streaming, instead of just streaming the already-encoded flv!


--

-Nick