Bug #1256
Choppy streaming/recording with media container set to "Matroska"
100%
Description
It's me again 
Noticed a choppy streaming/recording with my Synology NAS and a HDHomeRun device, especially when watching/recording
HDTV and sometimes SDTV, too. Depending on the data rate, I think. Could improve this a bit by increasing the network
buffers on my NAS, but HDTV was still very choppy - even though there were no more packet drops.
Finally I could solve this by changing the media container to "Pass-through" (seems to effect streaming and recording,
although this setting is in the DVR register card?).
The question is why I get into trouble, if the media container is set to "Matroska"? I know, the cpu of the nas is not
the best one, but if I look at the cpu stats the usage is somewhere between 20 and 50%. Same goes for the memory usage.
If I leave it at "Pass-through", do I have to accept any disadvantages?
Files
Subtasks
History
Updated by Adam Sutton about 12 years ago
Updated by - Status changed from New to Need feedback
- Assignee deleted (
Hein Rigolo)
I may have noticed something similar on a recording I have, but I put it down to playback issues on my rpi. I think it was ok on my ION.
The only real limitation of MKV v TS is that we can't add metadata tags to the recorded file for title, description etc...
Interesting though that you're seeing problems with MKV since most people are reporting a higher CPU load for TS recording which we think is down to some locking inefficiency. Since TS generally writes to file in much smaller chunks this causes more locking and thread wakeup in our code. Optimising this won't happen in 3.2.
It would be worth copying the file to a local drive of a reasonably capable PC and see whether this is a recording or playback issue.
Adam
P.S.
Can you stick proper git revision (or release version) in the version field, just gets confusing if we don't manage to deal with the issue for a while.
Updated by Rene Herbrich about 12 years ago
Updated by - File Das Erste HD-Menschen bei Maischberger.2012-09-25.23-30.mkv Das Erste HD-Menschen bei Maischberger.2012-09-25.23-30.mkv added
- File Das Erste HD-Menschen bei Maischberger.2012-09-25.23-30.ts Das Erste HD-Menschen bei Maischberger.2012-09-25.23-30.ts added
Yes, sorry, it's git revision 50d10d0 (https://github.com/adamsutton/tvheadend/commit/50d10d062e2bada1aa3039a8282a4aa04cf46432)
It tried what you suggested. It's definitely a recording issue. What's interesting: it mainly affects audio, video seems to be OK
(no artifacts, no tearing or anything like this).
I've attached two recordings of the same program, one as ts and one as mkv. Maybe I'm wrong, but ts seems to be a bit async?
The second thing I noticed: mkv is much smaller, is there some kind of conversion going on or has ts so much garbage included?
Updated by Adam Sutton about 12 years ago
- Category changed from Demultiplex to PVR / DVR
- Status changed from Need feedback to Accepted
- Assignee set to John Törnblom
- Found in version changed from latest to 50d10d0
I can certainly see what you're talking about in those files. I haven't seen it myself on my own setup.
Presumably this is fairly repeatable for you?
I'll have to pass this over to John and see if he can add anything when he's about.
Adam
Updated by Rene Herbrich about 12 years ago
Yes, it's repeatable. After changing the media container to matroska, I'm always getting choppy playback and video files.
Updated by Adam Sutton about 12 years ago
- Priority changed from Low to Normal
Actually I'm seeing this occasionally as well. It's not enough to cause me major grief, but obviously something that needs investigation.
Adam
Updated by Adam Sutton about 12 years ago
- Target version set to 3.2
If we find the answer to this problem then I think we should consider back porting to 3.2.
Adam
Updated by Ben . about 12 years ago
Updated by When I had my recording container set to .mkv, I found this quite commonly when playing files on my PC via VLC (not the web UI plugin), but never with the same file in XBMC. I wonder if something in XBMC's code handles that problem?
Updated by Adam Sutton about 12 years ago
I'm pretty sure the problem is in the recordings, some of my MKV's definitely show problems in multiple players. Not enough to really worry me as a user, but enough to concern me as a dev.
John, Is there an easy way I can extract a portion of an MKV recording so I can provide you an example?
Adam
Updated by John Törnblom about 12 years ago
Updated by Adam, best would be if you could save the TS stream while recording mkv:
wget -O rec.ts "http://localhost:9981/stream/channel/name?mux=pass"
Then I can load the ts file and see if I can hunt down the problem.
I think you can cut ts files with:
dd if=rec.ts bs=1000 skip=1 count=2 of=cropped.ts
this would remove the first 1000 bytes and keep the following 2000 bytes
Updated by xraynorm - about 12 years ago
Updated by There seems to be a playback issue with .mkv on the Linux version of VLC, a workaround is to increase the file caching in vlc.
Im not sure if this is a VLC or TVH problem.
I recorded some samples in this post :-
https://www.lonelycoder.com/redmine/boards/5/topics/5718?r=5852#message-5852
Updated by John Törnblom about 12 years ago
Is the matroska files choppy when recording a dvr file, or just when doing http streaming? The cluster size is kept at a minimum when doing live http streaming. If there is a difference between the two, increasing the cluster size might help.
Updated by Adam Sutton almost 12 years ago
It's recorded files, I have several of them, but I'm not sure which ones exactly have problems without looking back through them. Nor do I have the original TS streams to match.
But it does happen in most of my HD recordings (not sure about SD I rarely record anything in SD), maybe a handful of points in a 1 hour recording.
It's just not been high enough priority for me to investigate further, but I will try and get some test grabs of the raw data and recordings.
Adam
Updated by Adam Sutton almost 12 years ago
- Status changed from Accepted to Rejected
- Target version changed from 3.2 to 3.4
I'm going to close this on the basis that quite a bit has changed in the MKV code, I haven't checked this myself as I'm no longer using MKV, but several users report its working fine.
However if its still happening please do let me know.
Adam