Wednesday, March 18, 2009

Stutter in MediPortal streaming server

Reading the Mediaportal forum thread and seeing that others have similar stutter as I have been annoyed about for the time I've been using MediaPortal in multiseat mode with RTSP. After having compiled the DirectShowFilters solution, I modified the StreamingServer example application to stream a 2.5GB recording I had on my disk. This made it fairly easy to debug by both attaching the debugger and also adding printouts(my favourite).

My analyze shows that(at least my) stutter occurs when TsBuffer.cpp reads more data from the file using 'FileReader::read'. The time to read from file is normally below 50 usec, but sometimes I can see it takes one second or more.

Will attempt to try and fix the problem by one of:
* Add a thread to TSBuffer that keeps the buffer full by reading the following part's of the file asynchronously in the background. Since TSBuffer is using either MultiFileReader or FileReader to read from file, it's probably better to use a thread then to change both of those classes to use asynch IO with Overlapped IO. Well, that coudl be discussed, some what of reading ahead should be done anyway.
* Seems like there is less stutter when using MultiFileReader(could be because the file is "hot" since it's being recorded to). Could be a bug with FileReader, Need to be examined. For example, why are all those SetFilePointer done when the file is already positioned at the correct place? Maybe they are expensive calls?
* Start to read from file as part of putting the "frame" into the queue rather than doing the read when taking it out of the there. This could give some additional time for the read(if I have read the code correct).
* Buy new hardware :)


Have also downloaded and compiled latest version of liveMedia555 on linux, configured one test program to stream "my" file and that shows hardly any stutter. I'm not saying that the Mediaportal version need to b e upgraded, since that was on a much more powerful computer with RAID disks, but anyway good to know that it can be ,made to work!

Looking at the liveMedia code there are remarks about how the read from file are being done synchronously on Windows. And although Mediaportal have two special classes(MultiFileReader and FileReader) they are still reading from file synchronously as part of serving the packet to the client - which thus causes this stutter.

Anyway, the good thing is that I realized that the streaming part of TvServer is quite self contained and not that much code(if you exclude the actual setup of the streaming). Comparing it againt latest liveMedia555 source and incorporate any bugfixes should be quite easy. I see _one_ thing, but hard to say if it affects this at all.

Also looked at Windows socket 2 to understand the "we need Winsock 2 rumor" and would say that is not the problem in this case. The code already initializes winsock to use version 2(which has been around since Windows 2000). And of course there are some "new" features but I have a hard time to see which one would benefit the streaming server. Of course Scatter I/O and QOS sound nice but how does it fit into the current architecture?

Comments?

2 comments:

Unknown said...

Magnus,

Very keen to follow your developments. As most of us use multiple ts buffer files when streaming live tv I found multifilereader the main class in use.

I've found the stuttering varies based on what other activities are happening on the server (epg, other load) as well as the speed of the LAN.

I suspect there are multiple problems; one possibly timing (as the RTSP code may drop packets that are too late).

All the best.. send a PM to erosco (on the mp forum) if there's anything I can do to help.

Magnus said...

After buying a new computer with two fast disks configured as RADI0, this problem has totally disappeared. Very nice indeed.

The old one started to get CRC checksum errors and I could see how CPU kernel time was at 50% while reading from the disk - definitely a bad disk.

It would of course be nice to at least put in some code in the FileReader so that other people with same problem could check the log and it would say "Hey, your disk is slow!" :)