[FFmpeg-devel] [PATCH/RFC] Detecting EOF in RTMP

Kostya kostya.shishkov
Fri Dec 11 12:46:34 CET 2009


On Fri, Dec 11, 2009 at 01:16:48PM +0200, Martin Storsj? wrote:
> On Thu, 10 Dec 2009, Kostya wrote:
> 
> > On Thu, Dec 10, 2009 at 12:12:50PM -0500, compn wrote:
> > > On Thu, 10 Dec 2009 17:23:03 +0200, Kostya wrote:
> > > >On Thu, Dec 10, 2009 at 04:37:59PM +0200, Martin Storsj? wrote:
> > > >> 
> > > >> When the live broadcast ends, the current rtmp protocol handler doesn't 
> > > >> detect this as an eof, and thus sits and waits for more data on the 
> > > >> connection.
> > > >
> > > >Looks like Wowza does not follow RTMP standards :(.
> 
> What would be the proper standard way of indicating that the stream has 
> reached the end, by the way? I tried all the streams on the RTMP 
> MultimediaWiki page (most of them were dead, but a few of them worked), 
> and found a few different cases:
> 
> - Some streams end without sending a single hint that there won't be any 
> more data (e.g. 
> rtmp://fsapfs.fplive.net/fsap/Videos/foie_gras_uk_high.flv)
> 
> - Some streams send a NetStream.Play.Stop event, followed by a server 
> error (e.g., 
> rtmp://fl9.maelstrom.jet-stream.nl:80/vod/vdoxadmin/jeroen/bunny.mp3 sends 
> this immediately, to indicate that the file isn't found at all)
> 
> - Some streams send an NetStream.Play.UnpublishNotify event, followed by a 
> server error ("Failed to play foobar; stream not found."), when the stream 
> ends. This occurred with the "live" example in Wowza.
> 
> - Some streams send an NetStream.Play.Stop event, not followed by any 
> server error. This occurred when serving a static file through Wowza.
> 
> In my patch from yesterday, I reacted to the 
> NetStream.Publish.UnpublishNotify event, but when testing things today, I 
> only receive NetStream.Play.UnpublishNotify events instead. Either the 
> former was a mistake in documenting my findings yesterday, or some servers 
> can return either one. I only kept the Play.UnpublishNotify version for 
> now.
> 
> Adding the STREAM_STOPPED behaviour as in my patch makes some of these eof 
> error messages be lost, since the Stop/Unpublish status codes preceding 
> the error messages terminate reading from the stream at that time.

I think this is correct behaviour - client connects to server, server
notifies him when data is available, when it can start playing, so
notifying about end of stream is logical too.
BTW, looks like server can also send EOF in control command.
I'll look at that.

> > > is it possible to detect wowza server and then use non-standard exit
> > > procedure?
> > 
> > Yes, it sends notification with full server name and version. 
> 
> I guess that would be an option, but I'm not sure if this is a general 
> wowza-specific behaviour.
> 
> Attached is an updated patch.

Applied.

> Kostya, do you want me to add wowza detection and enable this only in that 
> particular case?

Who knows what servers may do that. I'll try to commit my code for
printing packet contents so it will be easier to debug RTMP streams.
 
> // Martin

BTW, it is convenient having last name same as the place you live?



More information about the ffmpeg-devel mailing list