Ukraine
It`s work now!!!!
Smooth stutter free playback, fast channel switch (>3 hour stable play).
*.flv streams not tested.
IPTV/DVB-IP in MP: Support for http, rtp and udp (2 Viewers)
- Thread starter Stepko
- Start date
Smooth stutter free playback, fast channel switch (>3 hour stable play).
*.flv streams not tested.
Stream is FLV not MPEG-TS which is required for Tv Service. If anybody knows, how to convert real-time FLV stream to MPEG-TS stream, let me know (I tried it with VLC but it fails).
OK,
I'm terminating my separate development and using Georgius' filter. This latest filter has excellent properties. CPU usage dropped to ~6% (of one core - 3% CPU as compared to previous reports) and there seems to be no packet dropping. The most what I got was a couple of late frames in half an hour. Edit: one discontinuity in 4+ hours
To clarify: my version had extremely erratic CPU usage in grabber thread that I was unable to resolve. It was able to take 0% CPU and then jump to >20% for no apparent reason. It even did that when I changed the socket to blocking, which should by definition drop the CPU usage to 0%... The funniest thing was that this CPU usage "dancing around" was very smooth (0% for 30 sec, then gradually rise up to 25% then gradually drop down back to 0% - the entire cycle taking from one to 3 minutes)
Top all this off with Georgius' great implementation and I see no further reason to continue on this separate path...
Since I *know* the filter *can* take 0% CPU, I will attempt to achieve that on Georgius' version instead of mine.
- Thread starter
- #55
AW: Re: IPTV/DVB-IP in MP: Support for http, rtp and udp
Hi georgius and velis,
good to hear (well, read) that you are making progress. From what I read here it really looks promising!
I had a really quick look at georgius' last source code. RTP still not working/supported at the moment, right? I also saw that you switched the way of getting the data from the winsocket back to polling. Is there a reason for this? The callback mechanism was the main reason to add the winsock-worker thread. Theoretically this should be the better way. I think the main problem with polling is the wait time. You set it to 10ms, but the value depends heavily on the bandwith of the stream and on the cpu speed. Did you have better results with polling?
SMak044: I don't think that the tv server can handle flv streams. Even though the MP can play the video and audio contained in the flv file, the TV server is not compatible with the flv format. You could try to get the stream running with the "OnlineVideos" plugin.
Stepko
Hi georgius and velis,
good to hear (well, read
) that you are making progress. From what I read here it really looks promising!I had a really quick look at georgius' last source code. RTP still not working/supported at the moment, right? I also saw that you switched the way of getting the data from the winsocket back to polling. Is there a reason for this? The callback mechanism was the main reason to add the winsock-worker thread. Theoretically this should be the better way. I think the main problem with polling is the wait time. You set it to 10ms, but the value depends heavily on the bandwith of the stream and on the cpu speed. Did you have better results with polling?
SMak044: I don't think that the tv server can handle flv streams. Even though the MP can play the video and audio contained in the flv file, the TV server is not compatible with the flv format. You could try to get the stream running with the "OnlineVideos" plugin.
Stepko
Re: AW: Re: IPTV/DVB-IP in MP: Support for http, rtp and udp
Yes, you're right actually is not working (all RTP code is commented). I'm planning to add support as soon as possible, but I don't know any RTP stream. I can simulate streams with VLC, but it's not as real stream.
I choose non-blocking sockets, so on any of network methods code did't stop. Filter must periodicaly check requests in DoBufferProcessingLoop() method and also gather data from network (doesn't matter if UDP or HTTP). Also gathering data must periodicaly check if filter don't stopping its work.
10 ms is enough time to give other threads some time to work (at least for DoBufferProcessingLoop() and in case of received data for FillBuffer() too). Because non-blocking sockets are used, the recvfrom() method exits immediately if no data received. It can cause high CPU load, if no data available and gathering thread is always checking if data are received. Also internal socket buffer is set to much higher value (from 32 KB to 1MB), which should be enough - if gathering thread waits longer, data are not lost.
Friendly, I didn't compare polling and winsock implementation. I just reverted to old code (the code in TvService 1.1.3 on SVN) because it was working (your version wasn't working - at least for me).
Yes, you're right actually is not working (all RTP code is commented). I'm planning to add support as soon as possible, but I don't know any RTP stream. I can simulate streams with VLC, but it's not as real stream.
I choose non-blocking sockets, so on any of network methods code did't stop. Filter must periodicaly check requests in DoBufferProcessingLoop() method and also gather data from network (doesn't matter if UDP or HTTP). Also gathering data must periodicaly check if filter don't stopping its work.
10 ms is enough time to give other threads some time to work (at least for DoBufferProcessingLoop() and in case of received data for FillBuffer() too). Because non-blocking sockets are used, the recvfrom() method exits immediately if no data received. It can cause high CPU load, if no data available and gathering thread is always checking if data are received. Also internal socket buffer is set to much higher value (from 32 KB to 1MB), which should be enough - if gathering thread waits longer, data are not lost.
Friendly, I didn't compare polling and winsock implementation. I just reverted to old code (the code in TvService 1.1.3 on SVN) because it was working (your version wasn't working - at least for me).
Hi,
there is new version of filter. The previous version has small bug - in case of chunked HTTP streams when chunk of zero size is received (this means end of transmission) than probably receiving is stopped and connection is not reopened (it didn't happen - at least nobody reported this). Now it this case is connection closed and reopened.
And now I'm going to RTP streams
there is new version of filter. The previous version has small bug - in case of chunked HTTP streams when chunk of zero size is received (this means end of transmission) than probably receiving is stopped and connection is not reopened (it didn't happen - at least nobody reported this). Now it this case is connection closed and reopened.
And now I'm going to RTP streams
Testing on HTTP streams. Work great!!!!!
This version works much better than versions from Stepko and Dimka.
one hour of continuous work on internet stream,not intranet, are stable, lost-free, stutter-free.
Big thanks georgius!!
Unfortunately I have to report that this evening I've had some of the worst stutter in a long time. So much so that I had to restore my old version of the filter
Using UDP of course
Using UDP of course
Unfortunately I have to report that this evening I've had some of the worst stutter in a long time. So much so that I had to restore my old version of the filter
Using UDP of course
Thanks for reporting. It's strange problem because in MPIPTVSource.Log are many of these messages:
It means that no data can be received (=> stuttering) because there is no space in buffer. Because it's linear buffer, it have to be released full and than new data can be received. But in case of using cyclic buffer it don't have to be better.
My opinion is that problem is on another place. When I look in source code I think that problem is in getting of media sample from allocator. Unfortunately, there is no logging if allocator returns invalid handle.
Code:
EnterCriticalSection(&criticalSection);
int occupiedSpace = this->buffer.GetBufferOccupiedSpace();
LeaveCriticalSection(&criticalSection);
#ifdef EXTENSIVELOGGING
LogDebug("DoBufferProcessingLoop(): occupied space: %i", occupiedSpace);
#endif
if (occupiedSpace > 0)
{
IMediaSample *pSample;
HRESULT hr = GetDeliveryBuffer(&pSample, NULL, NULL, 0);
if (FAILED(hr))
{
Sleep(1);
continue; // go round again. Perhaps the error will go away
// or the allocator is decommited & we will be asked to
// exit soon.
}
...
}I'll add logging code and post new version.