[Live-devel] Possible bug in liveMedia + info request about H263 / H263plus compatibility

[Cristiano Belloni]

Greetings to all,

As I explained in the previous emails, I'm trying to set up an rtsp 
server that streams h263 video, taken from a process that writes the 
stream on a unix named pipe.

The "encoder" process sets up ffmpeg libraries, takes video frames from 
an analog camera and encodes them in h263 format, writing them on a 
named pipe (fifo) on the filesystem.

The server process adds an H263plusVideoFileServerMediaSubsession, using 
the filename of the named pipe as the second parameter.

When I start the encoder process, it sets itself up and blocks opening 
the fifo write only. That's ok, because no one has yet opened the fifo 
for reading.

Then I start the server, and start an rtsp client to do the right request.

The server then open()s the fifo for reading. Consequently the encoder 
process unblocks and starts encoding frames and writing them on the fifo.

The odd thing is that, then, the server close()s the fifo, only to re - 
open() it after a bit.

After the server close()s, and before it re - open(s) them, the encoder 
process has encoded some frames and tries to write them on the fifo. But 
the other end of the fifo is now closed, and the encoder process gets a 
SIGPIPE  and dies.

The strace of the server process goes like this:

open("camera0fifo", O_RDONLY|O_LARGEFILE) = 5    -->(opens the fifo for 
the 1st time)
[...]
close(5)     -->(closes fd 5, which is the fifo  descriptor)
[...]
---> Here the encoder process tries to write() on the fifo, and gets the 
SIGPIPE
[...]
open("camera0fifo", O_RDONLY|O_LARGEFILE) = 5 -  ->(opens the fifo 
again, for the last time)

If I make the encoder process sleep() for two seconds, however - that's 
bad practice, I know, but just to prove my point - the server has time 
to re - open() the read end of the fifo, and all consequent write()s on 
it are successful.

To avoid this, I would either ignore the SIGPIPE or poll the file 
descriptor until its read end is opened again, but I don't particularly 
like these solutions.

Is there a particular reason why liveMedia open()s the file descriptor 
twice? Is it meant to be like this or is it misbehaving?

And if it's meant, how would you recommend to handle this situation? 
Maybe I'm missing something, and someone could be kind and enlighten me :)

The second part of the question is a bit trickier.

Server sends correctly H263plus packets, as far I can see. 
Unfortunately, my implementation is meant to stream to cellular phones 
using the standard realplayer.

Realplayer behaves well with the server in rtsp/rtp interaction, but it 
won't read H263plus packets as encoded by ffmpeg. Instead, it would read 
H263 (non-plus, first version, with fixed screen sizes).
When I try to stream H263 streams with an 
H263plusVideoFileServerMediaSubsession, it behaves quite oddly: servers 
sends packets very slowly, with short bursts of rtp packets interleaved 
with 2/3 seconds of sending nothing, as I could observe in wireshark.

As it consumes much slower than the encoder process produces, the fifo 
gets filled, the writes block, then the server finally consumes its 
buffer (taking minutes), and the encoder process fills the fifo again 
and so on.

I realize H263plusVideoFileServerMediaSubsession is meant to send H263+ 
streams, which it does, but I thought H263+ was backwards compatible 
with H263.

Anyone managed to stream pure H263 first version with liveMedia?
Anyone knows how can I achieve this goal?

Thanks to everybody.

-- 
Belloni Cristiano
Imavis Srl.
www.imavis.com <http://www.imavis.com>
belloni at imavis.com <mailto://belloni@imavis.com>