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.
--------------------------------------------------------------------------------
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
