[FFmpeg-soc] [PATCH] rtsp tunneling

[Martin Storsjö]

On Tue, 8 Jun 2010, Martin Storsjö wrote:

> Ronald, Josh: What about adding if (!s->hd) return AVERROR(EIO); after the 
> if (!s->init) check? Currently, if the delayed open fails, you'd get a 
> crash on the second url_read(), if the calling code doesn't check the 

Actually it didn't crash (immediately), but still malfunctioned, so I 
added such checks.

> return value from every single call and avoid touching it again after an 
> error. Earlier, after a successful url_open(), there was always a working 
> s->hd initialized.
> 
> Also, Josh, in your patch, you said that the connection is initialized on 
> http_read, *write and *seek, but I'm not sure if http_seek handles being 
> called before the first url_read/url_write. As the very minimum, it 
> requires an if (old_hd) before the url_close at the end.

Added similar checks for http_seek too, fixing a regression with e.g. the 
image2 demuxer that does an url_fsize() before any read had been done.

Ronald: There's still an arcitectural regression introduced by the http 
delay open, that I'm a bit unsure about how to fix. url_fdopen (which is 
invoked directly by url_fopen) copies the value of is_streamed to the 
ByteIOContext directly after opening. In the http protocol, is_streamed is 
1 initially to indicate that seeking isn't supported, but is set to 0 if a 
proper reply header is found. This used to be done already within 
url_open(), but isn't anymore since the connection hasn't been opened yet. 
So this effectively removes support for seeking in http sources for now.

How do you suggest we fix this?

I'm not sure if this is the last issue - the http delay open issue feels 
like a can of worms/regressions at the moment. One option would be to 
disable delay opening by default and only enable it in the RTSP tunneling 
case by a private flag or something similar.

// Martin