Opened 10 years ago

Closed 8 years ago

#138 closed enhancement (fixed)

add support for rtmp live stream

Reported by: taeuber Owned by:
Priority: minor Component: avformat
Version: unspecified Keywords: rtmp live stream
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no



rtmpdump supports live streams through the live stream command line option »-v«.
Could this feature be added to ffplay/ffmpeg too?

rtmpdump -v -r rtmp:// -o 1.flv


Attachments (1)

typescript.txt (8.5 KB) - added by quandt 9 years ago.
ffmpeg log

Download all attachments as: .zip

Change History (11)

comment:1 Changed 10 years ago by compn

  • Resolution set to worksforme
  • Status changed from new to closed

please read the manual:


For example, to stream a file in real-time to an RTMP server using `ffmpeg':
ffmpeg -re -i myfile -f flv rtmp://myserver/live/mystream

To play the same stream using `ffplay':
ffplay "rtmp://myserver/live/mystream live=1"

in your case:

ffplay "rtmp:// live=1"

works for me.

Changed 9 years ago by quandt

ffmpeg log

comment:2 Changed 9 years ago by quandt

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Don't think it does work for live streams.

In testing against a red5 (specifically r4198, but also newer) server, rtmp support works great in ffmpeg and ffplay but on live streams with the parameter specified as mentioned above "live=1" simply creates an infinite loop.

Attached is a "-loglevel verbose", here's the verison of ffmpeg (ubuntu, but also tested and same results on winslow... same version)

quandt@lt001:~/Desktop$ ffmpeg
ffmpeg version N-35750-g16b771b, Copyright (c) 2000-2011 the FFmpeg developers

built on Dec 13 2011 14:22:55 with gcc 4.5.2
configuration: --enable-libfreetype --enable-libmp3lame --enable-librtmp --enable-frei0r --enable-libv4l2 --enable-libx264 --enable-gpl
libavutil 51. 32. 0 / 51. 32. 0
libavcodec 53. 43. 0 / 53. 43. 0
libavformat 53. 25. 0 / 53. 25. 0
libavdevice 53. 4. 0 / 53. 4. 0
libavfilter 2. 53. 0 / 2. 53. 0
libswscale 2. 1. 0 / 2. 1. 0
libpostproc 51. 2. 0 / 51. 2. 0

comment:3 Changed 9 years ago by quandt

In further testing including on a new red5 server this is still a problem (ie r4305). Interestingly, it almost works. If you let ffplay sit for over a minute (sometime 10 minutes) eventually it starts to play a file (or save it), but not always. I was able to modify the librtmp to get rid of the error it reports (namely a FCPublish command which apparntly not support on RED5, nor apparantly needed), but this did not cure this problem. I've been digging in the ffmpeg code, back tracking from the RTMP setup commands and and they seem to do what they shoudl (minus the FCPublish thingy).

In any case, I do happen to have a RED5 server R4305 set up in a publicly available location for anyone who happens to have a dbg or something better to trace this thing. My email is brian dot quandt @ gmail dot com in which to cooridinate access to it.

comment:4 Changed 9 years ago by cehoyos

Is there any difference between this report and tickt #797?

comment:5 Changed 9 years ago by cehoyos

Please add command line and complete, uncut console output.

comment:6 Changed 9 years ago by quandt

Yup, I think I know what is the problem, don't know the exact fix ... yet, but do know how to hack it to make it work.

approx line#2404
for(;;) infinite for loop, which keeps running until it knows it has figured things out.

hack was to put a break at the bottom of the for, under the assumption that it knew what it wanted to know, but just didn't know it knew...OBVIOUSLY THIS IS A HACK, it's late at night and why the probe functionality can't determine what the stream is to it's satisfaction I don't know (the decoder called knows how to figure it, so the probe functionality did at least a good enough job to get the right codec). More digging, then again, maybe those who actually know this code will have a real quick fix versus my hack of a fix (ie I think I'm pointing pretty close the real problem here, hopefully someone else will look).

In all these tests I was streaming to RED5 using ffmpeg (ie output) and streaming from RED5 into ffplay to test, ie
process 1) ffmpeg -re -i somesutiableflvfile.flv -vcodec copy -an "rtmp://localhost/oflaDemo/mylivestream live=1"

process 2) ffplay -i "rtmp://localhost/oflaDemo/mylivestream"

comment:7 Changed 9 years ago by quandt

editororial correction to my tests....tests were

process 1) ffmpeg -re -i somesutiableflvfile.flv -vcodec copy -an "rtmp://localhost/oflaDemo/mylivestream live=1"

process 2) ffplay -i "rtmp://localhost/oflaDemo/mylivestream live=1"

More information:
I have removed the "break" and returned the code to it's default. The test served solely to help track things down.

In more testing, ie audio only flv's streaming work fine, ie
process 1) ffmpeg -re -i input.flv -vc -acodec copy "rtmp://localhost/oflaDemo/mylive live=1"
process 2) ffplay -i "rtmp://localhost/oflaDemo/mylive live=1"

When I do a audio and video input stream playback starts correctly (and immediately, but could be described as choppy).

Video by itself causes the problem, ie playback is delayed, and we are stuck in the "for(;;) {}" loop.

Last edited 9 years ago by quandt (previous) (diff)

comment:8 Changed 8 years ago by compn

ffmpeg now has its own rtmp implementation. with live support. did you try it yet?

comment:9 Changed 8 years ago by taeuber

No I haven't tried yet.

Next time I come around a live stream I'll try.

comment:10 Changed 8 years ago by richardpl

  • Resolution set to fixed
  • Status changed from reopened to closed

Thanks, feel free to reopen ticket that if you found it still does not work with latest release/git.

Note: See TracTickets for help on using tickets.