[rtmpdump] Compatibility with librtmp?

[Andrew McClure]

Just in case this is interesting to anyone, we eventually did resolve our
problem. It turned out that LibRTMP was sending invocations (publish and
createstream) in a different order than the stock Flash player would have.
Although as far as I know the order LibRTMP uses is allowed under the
protocol, our software was implicitly assuming the other order... thanks for
the responses!

On Mon, Feb 7, 2011 at 3:24 PM, Andrew McClure <amcclure at bittorrent.com>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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mplayerhq.hu/pipermail/rtmpdump/attachments/20110215/2f0fc18f/attachment.htm>