[Live-devel] Problem streaming continuous H.264 video over Transport Stream

[Bruno Filipe Basilio]

Ross,

The time period between the stream stopping and consequent recover is exactly 35:47.50 with a variance less than 10 msecs and this goes forever.
Could you know any action that could be causing this behavior (so deterministic) in my linux system?

In my previous post I think didn't understand your question and poorly explain myself about the meaning of "more fluid video stream" when preferring H.264 over TS to only H.264. I came to this conclusion comparing video streams visualized in VLC.
But I agree with you that TS is more resource intensive in terms of network and processing.
A subject to another thread is the compatibility on the client, i.e. Set-Top-Boxes.

> I notice that you're feeding your TransportStream data (from the
> "MPEG2TransportStreamMultiplexor") directly into a RTPSink.  Although
> that *might* work in this case (because you're reading from a live
> source rather than from a file), it would be safer to have a
> "MPEG2TransportStreamFramer" object sitting between your
> "MPEG2TransportStreamMultiplexor" and your RTPSink.  This may cause
> RTP packets to get sent out at a more even rate.

My first test wasn't successful because no frames have been sent, but I will try this in more detail latter.
Thank you for pointing this out.

> You also didn't say anything about your H.264 input source
> implementation - i.e., the class that feeds into the
> "H264VideoStreamDiscreteFramer" - but it's conceivable that the
> blockage is happening there.  I.e., you should make sure that the
> call to "doGetNextFrame()" on your input source object is always
> causing data to be delivered to the downstream object (the
> "H264VideoStreamDiscreteFramer") without excessive delay.

The class that feeds into the "H264VideoStreamDiscreteFramer" is MyDeviceSource as I mentioned in my first post in this subject and in normal situation, after being called "doGetNextFrame()", the data is successfully delivered. The abnormal situation his being discussed here.

> It sounds like you're going to want to do this (write incoming data
> into a Transport Stream File) in the future anyway, because you
> mentioned that you eventually want to support 'trick play'.  ('Trick
> play' operations are only for pre-recorded data, not for live
> streams.)  So you might as well get used to recording files.

Doing the first tests as we speak. ;)

Best Regards,
Bruno Basilio



--------------------------------------------------------------------------------

Declara??o:
A informa??o contida nesta mensagem, e os ficheiros anexos, ? privilegiada e confidencial, destinando-se exclusivamente ao(s) destinat?rio(s).Se n?o ? o destinat?rio (ou o respons?vel pela sua entrega ao destinat?rio) e recebeu a mesma por engano, fica notificado que ? estritamente proibido reproduzir, guardar ou distribuir toda ou qualquer parte desta mensagem e ficheiros anexos.Por favor reencaminhe a mensagem para o respons?vel pelo seu envio ou contacte-nos por telefone e elimine a mensagem e ficheiros anexos do seu computador,sem os reproduzir.

Disclaimer:
The information contained in this message, and any files attached, is privileged and confidential, and intended exclusively for the included addresses.If you are not the intended recipient (or the person responsible for delivering to the intended recipient) and received this message by mistake, be aware that copy, storage, distribution or any other use of all or part of this message and the files attached is strictly prohibited. Please notify the sender by reply e-mail or contact us by telephone and delete this message and the files attached, without retaining a copy.

--------------------------------------------------------------------------------