[rtmpdump] Compatibility with librtmp?

[Howard Chu]

Andrew McClure wrote:
> Hi. We are developing an RTMP application and are having trouble getting it to
> interoperate with the librtmp (as used in FFmpeg).
>
>
> Our application acts like a proxy. In our test configuration, we have a port
> 1936 which accepts RTMP publishing, and a different port 1935 which accepts
> RTMP playing. Packets received from the publisher connected to port 1936 are
> forwarded to the player connected on port 1935 (with some minimal munging). We
> have two simple flash applets (written in Flex, using the standard
> Video/Camera/NetConnection objects) which connect to these ports; one streams
> video from a webcam, the other plays the video thus streamed.
>
>
> When we try to play video originating in Flex, forwarded through our proxy and
> played back in Flex, it works. The video appears on the screen.
>
>
> However then we try something different. We compiled a version of ffmpeg (svn
> r26326) with librtmp (from rtmpdump svn r555). (If there is a better way to
> test publish with librtmp than this, I would be curious to know.) We try using
> ffmpeg to publish to our port 1936:
>
>
> ./ffmpeg -loglevel debug -i ~/Downloads/20051210-w50s.flv -re -ac 1 -acodec
> copy -vcodec flv -f copy rtmp://localhost:1936/
>
>
> And then play back the video by connecting the Flex applet to port 1935. We
> are having a problem where we are able to handshake, understand ffmpeg's
> publish commands and forward the packets through to the Flex applet as
> appropriate... *but* the Flex applet does not display video or audio. We get a
> black windowpane and silence.
>
>
> When we forward the ffmpeg streams, we appear to be doing (or failing to do)
> something to the RTMP packets such that the Flex player no longer understands
> the RTMP stream. But of course this problem only occurs with streams generated
> through ffmpeg. So it appears this is due to some slight difference between
> the RTMP protocol as implemented by ffmpeg and Flex-- we are compatible with
> the Flex publisher's notion of RTMP but not ffmpeg's. What I am trying to
> figure out:
>
>
> - What might this difference in RTMP implementation be, which is causing
> ffmpeg to apparently not be compatible with our RTMP proxy?
>
>
> - Is there a way to get ffmpeg (or another librtmp tool) to act like a
> "server", such that our Flex video object could connect directly to ffmpeg,
> issue a play request, and start receiving a video? I ask this in case the
> problem is not in fact that we are damaging ffmpeg's stream, but rather that
> ffmpeg just is not generating data Flex knows how to work with in the first
> place. (I find this "ffserver" tool, however this does not look like what I am
> looking for; the docs seem to imply it does RTP/RTSP only, and the html doc
> also says "It can also stream from files, though that is currently broken.")
>
>
> One possible source of concern is that when the player connects on 1935, it
> does not see the beginning of the stream-- it comes in after the stream has
> been waiting a few seconds. However once connected we do wait until we see a
> keyframe to begin streaming, and we forward a cached copy of the metadata
> packet at that time.
>
>
> We also did try forcing ffmpeg to publish in codecs I know Flex understands,
> but it does not help:
>
>
> ./ffmpeg -loglevel debug -i ~/Downloads/20051210-w50s.flv -re -ac 1 -acodec
> nellymoser -vcodec flv -f flv rtmp://localhost:1936/
>
>
> Do you have any suggestions? What are the requirements our application must
> follow to interoperate with ffmpeg/librtmp? To our understanding we are
> compatible with the published RTMP spec but the spec is ambiguous on many points.
>
>
> Note, I was unsure the most appropriate place to ask these questions so I also
> sent this post to the ffmpeg-user list. Thanks.

The last time I checked, ffserver worked fine for serving FLV files over http. 
(There were a few bugs in that before but I fixed them several months ago. 
It's of course entirely possible that someone else has re-broken it again 
since then...)

I've only been using H.264/AAC FLV files, they worked fine the last time I 
tried publishing, but again, that all depends on your clients.