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

[Bruno Filipe Basilio]

Ross,

Thank you for the fast feedback.
After doing some more tests it seems the video stream recovers from the blocking after a call to AlarmHandler::handleTimeout().

Here's the stack trace:

H264VideoDiscreteFramer::doGetNextFrame() at H264VideoDiscreteFramer.cpp:35 0x804fbba
InputESSourceRecord::askForNewData() at MPEG2TransportStreamFromESSource.cpp:191 0x8050e7c
MPEG2TransportStreamFromESSource::awaitNewBuffer() at MPEG2TransportStreamFromESSource.cpp:138 0x8050ef8
MPEG2TransportStreamMultiplexor::doGetNextFrame() at MPEG2TransportStreamMultiplexor.cpp:53 0x805e9ba
MultiFramedRTPSink::packFrame() at MultiFramedRTPSink.cpp:215 0x80530bd
MultiFramedRTPSink::sendNext() at MultiFramedRTPSink.cpp:402 0x8053599
AlarmHandler::handleTimeout() at BasicTaskScheduler0.cpp:34 0x8067c33
BasicTaskScheduler::SingleStep() at BasicTaskScheduler.cpp:150 0x8065a31
BasicTaskScheduler0::doEventLoop() at BasicTaskScheduler0.cpp:76 0x8067320


> IMHO, if you're able to send H.264 video directly over RTP (i.e.,
> without encapsulating it in a Transport Stream first), then you
> should continue to do this, because there will be less network
> overhead - and better resliency to packet loss - by doing this,
> compared to streaming Transport Streams. I don't know what you mean
> by Transport Streams being 'more fluid', but that should not be the
> case, especially if the presentation times on your H.264 NAL units
> (delivered by your encoder) are correct.

The goal of using Transport Stream is to use trick play in the future.
H.264 encapsulated in TS is definitely 'more fluid' with our encoder video stream, I'll try to obtain more information to verify if the presentation times in the H.264 NAL Units are correct.
At this moment the presentation times are exposed thru the encoder API and not from the NAL Unit.

> If, however, you insist on transmitting Transport Stream data (rather
> than raw H.264) over RTP, then I suggest that you first create a
> Transport Stream *file*, and then trying to stream that (e.g., using
> our existing, unmodified "testOnDemandRTSPServer" or
> "live555MediaServer" applications).  That might give you some idea
> about what's going wrong.

Thank you for you suggestion, I'll try to simulate the problem creating a big TS file with the estimated time to failure in mind.


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.

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