Bug(s) in the UMC-threaded demuxer?

[dewildt_daniel]

Hello,
I'm trying to implement a network and file-IO video streaming-client based on the UMC-samples with the threaded-demuxer as splitter. I think I found some bugs in ThreadedDemuxer::ThreadRoutine() of the UMC 5.3.2

1) If in the initialization loop the result of m_pDemuxer->CheckNextData() is UMC_WRN_INVALID_STREAM then m_OnInit.Reset() is called and the thread es terminated. In that case ThreadedDemuxer::Init() will never terminate because it's waiting for the event in m_OnInit.wait().

2) In the initialization-loop is a detection if all track-rules are matched. But this test will never occur in normal situations, because the test for
m_pRulesState->m_iMatchedTracks >= m_pRulesState->m_iMaxTracks
is placed outside the block in case of the results of m_pDemuxer->CheckNextData() is UMC_OK.

3) The main-loop is only skipped (FLAG_VSPL_STOP_AFTER_INIT is set) when the initialization loop is processed. I have a situation in which I will skip both loops in the initialization-process of the threaded demuxer. (I will start playing at a speedrate unequal to one. In that case are the already created FrameConstructors reset and all parsed data is lost. As a work-a-round I stop the thread and jump back to the initial start-position in the stream.)

Maybe a RFE:
4) It seems that the main-loop is written for file-playback and not for network-streaming. If I have some network latency or packet lost, then I receive from m_pDemuxer->CheckNextData() either (depending on the implementation of the self-written network-datareader) an UMC_ERR_END_OF_STREAM or UMC_ERR_NOT_ENOUGH_DATA. In both cases will the main loop terminate. It would be nice if the main-loop goes into a sleep-mode, if there is not enough data on the input of the datareader.

regards,
Daniel

[Vladimir_Dudnik]

Hello Daniel,

I've submitted issue report for you through Intel Premier Support so you will be notified on investigation results

Regards,
Vladimir

[VipinKumar_E_Intel]

Quoting - dewildt.daniel@rheinmetall-de.com

Hello,
I'm trying to implement a network and file-IO video streaming-client based on the UMC-samples with the threaded-demuxer as splitter. I think I found some bugs in ThreadedDemuxer::ThreadRoutine() of the UMC 5.3.2

1) If in the initialization loop the result of m_pDemuxer->CheckNextData() is UMC_WRN_INVALID_STREAM then m_OnInit.Reset() is called and the thread es terminated. In that case ThreadedDemuxer::Init() will never terminate because it's waiting for the event in m_OnInit.wait().

2) In the initialization-loop is a detection if all track-rules are matched. But this test will never occur in normal situations, because the test for
m_pRulesState->m_iMatchedTracks >= m_pRulesState->m_iMaxTracks
is placed outside the block in case of the results of m_pDemuxer->CheckNextData() is UMC_OK.

3) The main-loop is only skipped (FLAG_VSPL_STOP_AFTER_INIT is set) when the initialization loop is processed. I have a situation in which I will skip both loops in the initialization-process of the threaded demuxer. (I will start playing at a speedrate unequal to one. In that case are the already created FrameConstructors reset and all parsed data is lost. As a work-a-round I stop the thread and jump back to the initial start-position in the stream.)

Maybe a RFE:
4) It seems that the main-loop is written for file-playback and not for network-streaming. If I have some network latency or packet lost, then I receive from m_pDemuxer->CheckNextData() either (depending on the implementation of the self-written network-datareader) an UMC_ERR_END_OF_STREAM or UMC_ERR_NOT_ENOUGH_DATA. In both cases will the main loop terminate. It would be nice if the main-loop goes into a sleep-mode, if there is not enough data on the input of the datareader.

regards,
Daniel

Please see the comments below.

1) it is a very special use-case (when m_pOnPSIChangeEvent != NULL). If you don't pass m_pOnPSIChangeEvent in Init you will never getMFX_WRN_INVALID_STREAM. 2) It is fixed in Intel IPP 6.0 which was released recently. 3) All buffered data is always flushed at every trick-mode operation (SetRate/SetTimePosition). Such work-around is the only way to start from rate!=1. 4) For network-streaming we use DataReader which returns GetSize = 0. Then demuxer will be respectful to streaming. And it is assumed that DataReader goes into sleep-mode when data isn't ready. Vipin

[Rodolphe_Fouquet]

Hi,

We're trying to implement a demuxer from a network Mpeg2TS stream, and our demuxer if creeping slow.

Our problem seems to be similar to the one explained here, do you know if the problem appeared again?


The Ipp version is 7.0.3.174 and ipp-samples 7.0.3.040.