Video transcoding with ffmpeg

ParadoxWolf

unread,

Mar 22, 2012, 4:06:43 PM3/22/12

to c-rtmp...@googlegroups.com

Hello everyone!

I'm doing a live video feed from a studio in HD. The stream works great going from Adobe FME into CRTMP on our server, and out to the viewers. The bitrate is around 1,000kbps and the resolution is 720p. With a 100mbps line we can fit a decent enough amount of users for our needs.

The problem is, some of our viewers can not handle that resolution/bitrate based on their computer/network conditions of course. Normally I'd try and make my encoding PC in the studio do all the work with multiple streams at different resolutions/bitrates with FME, but even with a 6-core processor, it can only handle encoding 1 HD 720p video feed, with audio, and all the other audio recording we do with that machine. The machine can not successfully render an HD video feed from our HDMI capture card, AND scale to SD and encode that as well. There's frame drops all over the place, and after several days of playing around with the settings, we've concluded that the machine just can't stably do the job.

I have heard of methods to pipe the stream from CRMTP into FFMPEG and let it scale and re-encode the H.264 video stream, and then pipe it back into CRTMP. After a bit of testing and playing around, I have concluded that I can not get FFMPEG to authenticate with CRTMP and I am un-sure on how to get it all working properly. Is this a configuration issue with CRTMP? The streaming server we are using can certainly handle the transcoding, and we only need it to scale and encode one SD resolution feed for all the rest of our users who can't handle the HD, which we can just configure JW Player options on our website in order to connect to a second stream.

Thanks,

Paradox

Dan

unread,

Mar 22, 2012, 4:39:13 PM3/22/12

to C++ RTMP Server

Paradox:

Been there - let's see if I can help a little.

Here's an example ffmpeg string:
ffmpeg -y -i "rtmp://127.0.0.1/flvplayback/Live1 live=1" -vcodec copy -
acodec copy -f mpegts -s 320x240 -metadata streamName=Live2
udp://127.0.0.1:9999?pkt_size=1316

This is from my notes on a previous project, so the exact commands may
differ. Notice the -i wrapped in quotes with the live=1 after it.
That took awhile to figure out - and it's apparently required.

So it grabs rtmp from localhost, then pipes it back over udp (just b/c
that's fast and easy) with an explicit streamName set. Of course
you'll want to alter -vcodec and -acodec to meet your needs on the
transcode (and likely the 320x240 bits).

Happy to lend a hand further if needed - others may have better ways
of doing this as well...

--dan

Message has been deleted

Alexandru Ionut Grama

unread,

Mar 22, 2012, 8:03:00 PM3/22/12

to c-rtmp...@googlegroups.com

Hello!

I supose that you're trying to use RTMP/T/E to publish to crtmpserver. As I know (maybe it has been changed), ffmpeg it's not able to handshake RTMP. The way I've achieve to publish with fffmpeg is using a fork of the ffmpeg project called xuggle: http://www.xuggle.com/xuggler/index

I've been tested that program on windows and it work perfectly, but sometimes fails to publish at first try (I don't know why). The procedure that I use it's the next (in a cmd)

ffmpeg -i H:\video.flv -re -acodec copy -vcodec copy -f flv rtmp://10.10.10.100/live/cameraFeed

(Described in http://wiki.xuggle.com/Live_Encoding_Tutorial )

Of course, try more modifiers for transcode/rescale, but the important stuff is -re modifier (live) and -f flv <url>, which says the uri of your stream where it will be published.

Good luck.

Regards,
Alexandru.

You received this message because you are subscribed to "C++ RTMP Server" mailing list.
To post to this group, send email to c-rtmp...@googlegroups.com
To unsubscribe from this group, send email to
c-rtmp-serve...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/c-rtmp-server?hl=en

--
---------------------------------------------------------------
Alexandru Ionut Grama
email: gramaalex...@gmail.com

RCP

unread,

Mar 22, 2012, 8:08:51 PM3/22/12

to c-rtmp...@googlegroups.com

I want to use ffmpeg not xuggle also here is ctrmp debug log

\\\\\Staring ffmpeg

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/netio/epoll/tcpacceptor.cpp:154 Client connected: 50.7.8.51:50869 -> 50.7.8.51:1935

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/netio/epoll/iohandlermanager.cpp:100 Handlers count changed: 6->7 IOHT_TCP_CARRIER

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/protocols/rtmp/inboundrtmpprotocol.cpp:123 This version of player doesn't support validation

ation

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/protocols/rtmp/basertmpappprotocolhandler.cpp:1508 Incorrect user agent

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/protocols/rtmp/basertmpappprotocolhandler.cpp:507 User control message type: RM_USRCTRL_TYPE_STREAM_SET_BUFFER_LENGTH

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/application/baseclientapplication.cpp:227 Stream NR(214) with name `` registered to application `flvplayback` from protocol IR(152)

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/protocols/rtmp/basertmpappprotocolhandler.cpp:1241 Default implementation of ProcessInvokeGeneric: Request: FCSubscribe

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/protocols/rtmp/basertmpappprotocolhandler.cpp:1241 Default implementation of ProcessInvokeGeneric: Request: _checkbw

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/application/baseclientapplication.cpp:238 Stream NR(214) with name `` unregistered from application `flvplayback` from protocol IR(152)

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/application/baseclientapplication.cpp:227 Stream NR(215) with name `` registered to application `flvplayback` from protocol IR(152)

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/protocols/rtmp/basertmpappprotocolhandler.cpp:892 Play request for stream name `xbn`. Start: -2; length: -1

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/application/baseclientapplication.cpp:238 Stream NR(215) with name `` unregistered from application `flvplayback` from protocol IR(152)

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/application/baseclientapplication.cpp:227 Stream ONR4R(216) with name `xbn` registered to application `flvplayback` from protocol IR(152)

tion.cpp:227 Stream ONR4R(216) with name `xbn` registered to application `flvplayback` from protocol IR(152)

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/application/baseclientapplication.cpp:227 Stream ONR4R(216) with name `xbn` registered to application `flvplayback` from protocol IR(152)

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/protocols/rtmp/basertmpappprotocolhandler.cpp:507 User control message type: RM_USRCTRL_TYPE_STREAM_SET_BUFFER_LENGTH

\\\\\\\\\\\\\

STOPing

\\\\\\\\\\\\\\/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/netio/epoll/iohandlermanager.cpp:259 ***Event handler HUP: 0x19087f0

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/netio/epoll/iohandlermanager.cpp:259 ***Event handler HUP: 0x19087f0

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/protocols/rtmp/streaming/innetrtmpstream.cpp:230 outbound stream 216 detached from inbound stream 91

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/application/baseclientapplication.cpp:238 Stream ONR4R(216) with name `xbn` unregistered from application `flvplayback` from protocol IR(152)

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/netio/epoll/iohandlermanager.cpp:109 Handlers count changed: 7->6 IOHT_TCP_CARRIER

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/protocols/protocolmanager.cpp:44 Enqueue for delete for protocol [IR(152)]

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/application/baseclientapplication.cpp:216 Protocol [IR(152)] unregistered from application: flvplayback

RCP

unread,

Mar 22, 2012, 8:54:23 PM3/22/12

to c-rtmp...@googlegroups.com

I got it to work I used TCP not UDP... but not I get this error...

/home/rtmp/crtmpserver-717/builders/packing/debian/crtmpserver-0.exported/thelib/src/protocols/ts/innettsstream.cpp:209 Back time

BTW Dan I'm the onefixing this for ParadoxWolf

ParadoxWolf

unread,

Mar 22, 2012, 8:55:47 PM3/22/12

to c-rtmp...@googlegroups.com

Ha, yes, me and Richard are working together on the project.

In the end, CRTMP is still not handling the request properly, from FFMPEG...

Alexandru Ionut Grama

unread,

Mar 22, 2012, 10:37:10 PM3/22/12

to c-rtmp...@googlegroups.com

You can try with Wowza or FMS and see if it's working; maybe is an issue of ffmpeg.
The back time is an issue of ffmpeg. RTMPd is receiving a timestamp past from the current time, and you can do it only when you're seeking, but with a live stream you can't seek, so seems to be a issue of ffmpeg. I recomend you try xuggle, it works :-)

El 23 de marzo de 2012 01:55, ParadoxWolf <ctcw...@gmail.com> escribió:

Ha, yes, me and Richard are working together on the project.

In the end, CRTMP is still not handling the request properly, from FFMPEG...

You received this message because you are subscribed to "C++ RTMP Server" mailing list.

To post to this group, send email to c-rtmp...@googlegroups.com
To unsubscribe from this group, send email to
c-rtmp-serve...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/c-rtmp-server?hl=en

Alexandru Ionut Grama

unread,

Mar 22, 2012, 10:40:20 PM3/22/12

to c-rtmp...@googlegroups.com

I've forgot: the packet with back timestamp it's dropped....

Dan

unread,

Mar 23, 2012, 9:30:44 AM3/23/12

to C++ RTMP Server

So the 'back time' issue is known here. It turns out that when you
start ffmpeg (or any feeder into mpegts), rtmpd will start tracking
the timestamps.

When you stop and re-start the feeder, rtmpd sees a timestamp that's
less than the last one it had before you restarted the feeder and does
not recover.

So you can just re-start rtmpd before (or after) you restart the
feeder - and all should be good. It looks like you guys are really
close on this!

--dan

On Mar 22, 9:40 pm, Alexandru Ionut Grama

<gramaalexandruio...@gmail.com> wrote:
> I've forgot: the packet with back timestamp it's dropped....
>
> El 23 de marzo de 2012 03:37, Alexandru Ionut Grama <

> gramaalexandruio...@gmail.com> escribió:

>
>
>
>
>
>
>
>
>
> > You can try with Wowza or FMS and see if it's working; maybe is an issue
> > of ffmpeg.
> > The back time is an issue of ffmpeg. RTMPd is receiving a timestamp past
> > from the current time, and you can do it only when you're seeking, but with
> > a live stream you can't seek, so seems to be a issue of ffmpeg. I recomend
> > you try xuggle, it works :-)
>

> > El 23 de marzo de 2012 01:55, ParadoxWolf <ctcwi...@gmail.com> escribió:
>
> > Ha, yes, me and Richard are working together on the project.
>
> >> In the end, CRTMP is still not handling the request properly, from
> >> FFMPEG...
>
> >> You received this message because you are subscribed to "C++ RTMP Server"
> >> mailing list.
> >> To post to this group, send email to c-rtmp...@googlegroups.com
> >> To unsubscribe from this group, send email to
> >> c-rtmp-serve...@googlegroups.com
> >> For more options, visit this group at
> >>http://groups.google.com/group/c-rtmp-server?hl=en
>
> > --

> > *---------------------------------------------------------------
> > Alexandru Ionut Grama
> > **email: gramaalexandruio...@gmail.com**
> > *
>
> --
> *---------------------------------------------------------------
> Alexandru Ionut Grama
> **email: gramaalexandruio...@gmail.com**
> *

C++ RTMP Server

unread,

Mar 23, 2012, 9:35:06 AM3/23/12

to c-rtmp...@googlegroups.com

Yes, that is accurate. This is happening because you deliver the mpegts over udp. If you deliver it via TCP, the connection will disappear once ffmpeg dies and a new connection is re-made after it re-connects. This will naturally destroy any context values associated with that stream. That is not possible over UDP because UDP is connection-less and I can't tell when a stream is not available anymore.

Just use inboundTcpTs and all should be fine :)

Cheers,
Andrei

C++ RTMP Server
crtmp...@gmail.com

RCP

unread,

Mar 23, 2012, 1:44:23 PM3/23/12

to c-rtmp...@googlegroups.com

I Did it even better

I used ffmpeg -y -i rtmp://[SomeURL]/live/xbnhd live=1 -s 640x360 -r 30 -b 500k -bt 540k -coder 0 -bf 0 -flags2 -wpred-dct8x8 -level 13 -maxrate 500k -bufsize 3M -ar 44100 -ab 192k -g 500 -metadata streamName=xbnsd -f flv tcp://127.0.0.2:6666

With....

{

ip="127.0.0.2",

port=6666,

protocol="inboundLiveFlv",

waitForMetadata=true,

},

Works Kick Ass!! CRTMP Rocks

RCP

unread,

Mar 23, 2012, 1:51:11 PM3/23/12

to c-rtmp...@googlegroups.com

Person with the IP of 84.210.17.36 Please Don't try to broadcast with our CRTMP Server

Reply all

Reply to author

Forward