- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Daniel,
I've submitted issue report for you through Intel Premier Support so you will be notified on investigation results
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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.
Vipin |
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page