rtmp support and librtmp

[Pavel Pavlov]

Hello all,
I'm using ffmpeg (libavformat) to read rtmp stream and I had lots of problems with it, so I decided to scrap that code. Then for rtmp I started to use original c++ librtmp from xbmc (xbox media center) and right away all my problems went away.

Since librtmp (http://rtmpdump.mplayerhq.hu/) was based on that librtmp from xbmc I thought that if I compile in librtmp then I'd also get the same nice results.

However, it appears that with librtmp compiled in I cannot even open file anymore and I get in log:
"24: Received FLV packet before play()! Ignoring."
and av_open_input_file returns -1


I use this sequence to read files:

av_open_input_file()
av_find_stream_info()

loop : av_read_frame()


is there something special that I need to do in order to be able to use new librtmp and ffmpeg? In case if it matters, the file is regular flv (created with ffmpeg) served from wowza streaming server.
Among problems with regular (without librtmp) build of ffmpeg were: quite unstable playback, freezing of playback, if the stream did not have sound then it would freeze on start up for quite a while (av_find_stream_info could take like 10 secs and usually when stream is video only it would take longer to return). With librtmp from xbmc it would work just as expected: no delays and freezing, so I guess that if I compile in librtmp support into ffmpeg I'd get the same nice results, but so far it breaks on the first step. Can you please tell me if there is anything wrong with what I'm doing? Thanks

[Howard Chu]

Post by Pavel Pavlov
Hello all,
I'm using ffmpeg (libavformat) to read rtmp stream and I had lots of problems with it, so I decided to scrap that code. Then for rtmp I started to use original c++ librtmp from xbmc (xbox media center) and right away all my problems went away.
Since librtmp (http://rtmpdump.mplayerhq.hu/) was based on that librtmp from xbmc I thought that if I compile in librtmp then I'd also get the same nice results.
"24: Received FLV packet before play()! Ignoring."
and av_open_input_file returns -1
av_open_input_file()
av_find_stream_info()
loop : av_read_frame()
is there something special that I need to do in order to be able to use new librtmp and ffmpeg? In case if it matters, the file is regular flv (created with ffmpeg) served from wowza streaming server.
Among problems with regular (without librtmp) build of ffmpeg were: quite unstable playback, freezing of playback, if the stream did not have sound then it would freeze on start up for quite a while (av_find_stream_info could take like 10 secs and usually when stream is video only it would take longer to return). With librtmp from xbmc it would work just as expected: no delays and freezing, so I guess that if I compile in librtmp support into ffmpeg I'd get the same nice results, but so far it breaks on the first step. Can you please tell me if there is anything wrong with what I'm doing? Thanks

Wowza server does quite a few things differently from genuine Adobe servers.
librtmp has been tested mainly against Adobe servers. Your best bet is to see
how your stream behaves using rtmpdump first, and ask about this on the
rtmpdump mailing list.

ffmpeg's use of librtmp involves only a few API calls; anything that might be
wrong in librtmp will have to be discussed and fixed on the rtmpdump list.

[aviad rozenhek]

Post by Howard Chu
librtmp has been tested mainly against Adobe servers.
ffmpeg's use of librtmp involves only a few API calls; anything that might
be wrong in librtmp will have to be discussed and fixed on the rtmpdump
list.
--
-- Howard Chu

I'm using ffmpeg r23391 with librtmp support, trying to read data from an
FMS 3.5.1.
I've managed to stream to the FMS using the following cmdline, and was able
to view the stream using a flash player connected to FMS.

./ffmpeg -re -i myfile -f flv rtmp://myserver/live/mystream

however using the equivalent ffplay cmdline to stream from FMS does not work
for me

./ffplay rtmp://myserver/live/mystream

it says the stream is not found

[trueice]

Post by aviad rozenhek
I'm using ffmpeg r23391 with librtmp support, trying to read data from an
FMS 3.5.1.
I've managed to stream to the FMS using the following cmdline, and was

able

Post by aviad rozenhek
to view the stream using a flash player connected to FMS.
./ffmpeg -re -i myfile -f flv rtmp://myserver/live/mystream
however using the equivalent ffplay cmdline to stream from FMS does not

work

Post by aviad rozenhek
for me
./ffplay rtmp://myserver/live/mystream
it says the stream is not found

try:
./ffplay "rtmp://myserver/live/mystream live=1"

__

_____________________________________________

ffmpeg-devel mailing list
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

[Stefano Sabatini]

Post by trueice

Post by aviad rozenhek
I'm using ffmpeg r23391 with librtmp support, trying to read data from an
FMS 3.5.1.
I've managed to stream to the FMS using the following cmdline, and was

able

Post by aviad rozenhek
to view the stream using a flash player connected to FMS.
./ffmpeg -re -i myfile -f flv rtmp://myserver/live/mystream
however using the equivalent ffplay cmdline to stream from FMS does not

work

Post by aviad rozenhek
for me
./ffplay rtmp://myserver/live/mystream
it says the stream is not found

./ffplay "rtmp://myserver/live/mystream live=1"

Just want to note that we badly need some part of the docs explaining
how each protocol is going to be used.

We should be able to have a protocols.texi file included in the ff*
tools man pages as long as I'll commit my documentation patch series,
if someone is interested into documenting protocols she's very
welcome.

Regards.

[Luca Barbato]

Post by Stefano Sabatini
how each protocol is going to be used.

And make sure that protocols _do_ use the same syntax...

embedded spaces is slightly more annoying that query strings for the user.

lu

[Howard Chu]

Post by Luca Barbato

Post by Stefano Sabatini
how each protocol is going to be used.

And make sure that protocols _do_ use the same syntax...
embedded spaces is slightly more annoying that query strings for the user.

Yes, but it's less annoying than doubly-urlencoded gibberish, which is the
only other alternative. Since actual RTMP URLs can carry query strings,
there's no way to unambiguously separate (proposed) local/ffmpeg query
parameters from the remote parameters.

[Ronald S. Bultje]

Hi,

Post by Howard Chu

Post by Luca Barbato

Post by Stefano Sabatini
how each protocol is going to be used.

And make sure that protocols _do_ use the same syntax...
embedded spaces is slightly more annoying that query strings for the user.

Yes, but it's less annoying than doubly-urlencoded gibberish, which
is the only other alternative. Since actual RTMP URLs can carry
query strings, there's no way to unambiguously separate (proposed)
local/ffmpeg query parameters from the remote parameters.

Also true for rtsp, so?

Please implement avoptions in urlprotocol.

Ronald

[Martin Storsjö]

Post by Ronald S. Bultje

Post by Howard Chu
only other alternative. Since actual RTMP URLs can carry query strings,
there's no way to unambiguously separate (proposed) local/ffmpeg query
parameters from the remote parameters.

Also true for rtsp, so?
Please implement avoptions in urlprotocol.

Since RTSP is a (de)muxer, not an URLProtocol, this doesn't really apply
for that, but it sure is needed for parameters from the RTSP (de)muxer to
the protocol handlers.

// Martin

[Luca Barbato]

Post by Howard Chu

Post by Luca Barbato

Post by Stefano Sabatini
how each protocol is going to be used.

And make sure that protocols _do_ use the same syntax...
embedded spaces is slightly more annoying that query strings for the user.

Yes, but it's less annoying than doubly-urlencoded gibberish, which is
the only other alternative. Since actual RTMP URLs can carry query
strings, there's no way to unambiguously separate (proposed)
local/ffmpeg query parameters from the remote parameters.

Actually when I implemented the code that eats the query string I though
about it. Right now the code should eat up the first instance of them
and preserve the rest. surely I should doublecheck and document it and
find a way to provide a saner protocol...

lu

[Stefano Sabatini]

Post by Luca Barbato

Post by Howard Chu

Post by Luca Barbato

Post by Stefano Sabatini
how each protocol is going to be used.

And make sure that protocols _do_ use the same syntax...
embedded spaces is slightly more annoying that query strings for the user.

Yes, but it's less annoying than doubly-urlencoded gibberish, which is
the only other alternative. Since actual RTMP URLs can carry query
strings, there's no way to unambiguously separate (proposed)
local/ffmpeg query parameters from the remote parameters.

Actually when I implemented the code that eats the query string I though
about it. Right now the code should eat up the first instance of them
and preserve the rest. surely I should doublecheck and document it and
find a way to provide a saner protocol...

Luca are you volunteering to write the first scratch of
doc/protocols.texi? ;-)

Regards.

[Howard Chu]

Post by Stefano Sabatini

Post by trueice

Post by aviad rozenhek
I'm using ffmpeg r23391 with librtmp support, trying to read data from an
FMS 3.5.1.
I've managed to stream to the FMS using the following cmdline, and was

able

Post by aviad rozenhek
to view the stream using a flash player connected to FMS.
./ffmpeg -re -i myfile -f flv rtmp://myserver/live/mystream
however using the equivalent ffplay cmdline to stream from FMS does not

work

Post by aviad rozenhek
for me
./ffplay rtmp://myserver/live/mystream
it says the stream is not found

./ffplay "rtmp://myserver/live/mystream live=1"

Just want to note that we badly need some part of the docs explaining
how each protocol is going to be used.

Funny, I just asked yesterday on IRC if such a doc existed. The URL options
for rtsp are not documented anywhere either. In this case at least, all of the
rtmp options are documented in the librtmp(3) manpage.

Post by Stefano Sabatini
We should be able to have a protocols.texi file included in the ff*
tools man pages as long as I'll commit my documentation patch series,
if someone is interested into documenting protocols she's very
welcome.
Regards.

[aviad rozenhek]

Post by trueice

Post by aviad rozenhek
it says the stream is not found

./ffplay "rtmp://myserver/live/mystream live=1"

it works!
however embedded spaces are indeed annoying.

[Howard Chu]

Post by aviad rozenhek

Post by trueice

Post by aviad rozenhek
it says the stream is not found

./ffplay "rtmp://myserver/live/mystream live=1"

it works!
however embedded spaces are indeed annoying.

Feel free to write a better solution. Take as much time as you like.

[aviad rozenhek]

Post by Howard Chu
Feel free to write a better solution. Take as much time as you like.

ROTFL

hopefully one day there will be a general mechanism to pass client-side
options to protocols, then it could look like:
ffplay -protocol_opt live=1 -protocol_opt socks=myproxy
rtmp://myserver/live/test

[aviad rozenhek]

Post by Howard Chu

Post by aviad rozenhek

Post by trueice

Post by aviad rozenhek
it says the stream is not found

./ffplay "rtmp://myserver/live/mystream live=1"
it works!

however embedded spaces are indeed annoying.

Feel free to write a better solution. Take as much time as you like.

How about this general purpose method of passing parameters to protocols?

instead of:
udp://localhost?pkt_size=1316&localport=1234
[where ?pkt_size=1316&localport=1234 are actually parameters to udp
protocol] use
udp?pkt_size=1316&localport=1234://localhost

and in the same manner, instead of
"rtmp://localhost/live/mystream live=1 buffer=100"
[where live=1 buffer=100 are actually parameters to rtmp protocol instead of
part of url] use
rtmp?live=1&buffer=100://localhost/live/mystream

this achieves a couple of things
1) it is clear which parameters are part of the real url, and which are
ffmpeg-specific flags
2) it reuses familiar syntax with the ? & notation
3) since & and ? are not legal in protocol names, this shouldnt break
anything

[Stefano Sabatini]

Post by aviad rozenhek

Post by Howard Chu

Post by aviad rozenhek

Post by trueice

Post by aviad rozenhek
it says the stream is not found

./ffplay "rtmp://myserver/live/mystream live=1"
it works!

however embedded spaces are indeed annoying.

Feel free to write a better solution. Take as much time as you like.

How about this general purpose method of passing parameters to protocols?
udp://localhost?pkt_size=1316&localport=1234
[where ?pkt_size=1316&localport=1234 are actually parameters to udp
protocol] use
udp?pkt_size=1316&localport=1234://localhost
and in the same manner, instead of
"rtmp://localhost/live/mystream live=1 buffer=100"
[where live=1 buffer=100 are actually parameters to rtmp protocol instead of
part of url] use
rtmp?live=1&buffer=100://localhost/live/mystream
this achieves a couple of things
1) it is clear which parameters are part of the real url, and which are
ffmpeg-specific flags
2) it reuses familiar syntax with the ? & notation
3) since & and ? are not legal in protocol names, this shouldnt break
anything

Another "option": use something like -proto_opts="..." and use
av_parse_options() (currently in libavfilter/parseutils.c, but can be
moved to lavu now that AVOptions are there) for setting the options in
the url context.

That should be more generic and possibly more robust, as it shouldn't
require &/? escaping.

Regards.

[Michael Niedermayer]

Post by aviad rozenhek

Post by Howard Chu

Post by aviad rozenhek

Post by trueice

Post by aviad rozenhek
it says the stream is not found

./ffplay "rtmp://myserver/live/mystream live=1"
it works!

however embedded spaces are indeed annoying.

Feel free to write a better solution. Take as much time as you like.

How about this general purpose method of passing parameters to protocols?
udp://localhost?pkt_size=1316&localport=1234
[where ?pkt_size=1316&localport=1234 are actually parameters to udp
protocol] use
udp?pkt_size=1316&localport=1234://localhost
and in the same manner, instead of
"rtmp://localhost/live/mystream live=1 buffer=100"
[where live=1 buffer=100 are actually parameters to rtmp protocol instead of
part of url] use
rtmp?live=1&buffer=100://localhost/live/mystream
this achieves a couple of things
1) it is clear which parameters are part of the real url, and which are
ffmpeg-specific flags
2) it reuses familiar syntax with the ? & notation
3) since & and ? are not legal in protocol names, this shouldnt break
anything

i like the idea

[...]

[aviad rozenhek]

Post by Michael Niedermayer

Post by aviad rozenhek

Post by Howard Chu

Post by aviad rozenhek

Post by trueice

Post by aviad rozenhek
it says the stream is not found

./ffplay "rtmp://myserver/live/mystream live=1"
it works!

however embedded spaces are indeed annoying.

Feel free to write a better solution. Take as much time as you like.

How about this general purpose method of passing parameters to protocols?
udp://localhost?pkt_size=1316&localport=1234
[where ?pkt_size=1316&localport=1234 are actually parameters to udp
protocol] use
udp?pkt_size=1316&localport=1234://localhost
and in the same manner, instead of
"rtmp://localhost/live/mystream live=1 buffer=100"
[where live=1 buffer=100 are actually parameters to rtmp protocol instead

of

Post by aviad rozenhek
part of url] use
rtmp?live=1&buffer=100://localhost/live/mystream
this achieves a couple of things
1) it is clear which parameters are part of the real url, and which are
ffmpeg-specific flags
2) it reuses familiar syntax with the ? & notation
3) since & and ? are not legal in protocol names, this shouldnt break
anything

i like the idea

I'll try to get a patch ready next week