Use mkv containers instead of mpeg-ts

Channels DVR Server Feature Requests
#1

I would love it if Channels DVR recordings were stored in a mkv container, rather than mpeg-ts. Specifically, I'd like the container to be capable of storing chapter information, like that generated by comskip, for example.

I'm guessing that there's already some support in Channels for playback of mkv containers, since the movie folder support seems to handle my movies just fine, and they're all mkv files :slight_smile:

Bonus points for storing the EPG information as mkv tags in that same file.

I realize the way I'm using Channels DVR isn't entirely mainstream, but I'm hoping this would still make sense for the general case, too.

#2

I use MCE buddy to convert the recordings to .MKV as I use chapters for commercial skip within Kodi. It is pretty painless and is highly flexible to your needs.

Rob

1 Like
#3

It's unlikely that we will ever change the format we are storing the recordings on disk. The benefit of the current format is that it is basically what we are getting off the airwaves and requires very little processing. This means that there are fewer chances of bugs and glitches making your recordings unwatchable.

Doing what @robmich suggested of post-processing is a good strategy that we currently have customers using if you want it in a different format.

2 Likes
#4

I personally feel that this is one of the things that makes Channels great. I prefer to have the format remain original, it just makes the playback that much better. Storage is inexpensive these days, so file size isn't much of an issue.

Since MCEBuddy works well, at least we have a good work-around for times where I may want post-processing done.

#5

Yep, I'm post-processing the files currently (using ffmpeg - MCEbuddy is purely a Windows thing, right?)

I completely understand the benefits of simplicity, fair enough :slight_smile:

#6

I believe you are correct. Maybe someday Channels will support post-processing scripts for post-processing automation with 3rd party programs. Then you could at least easily automate the conversions if you can't already.

1 Like
#7

You can easily do a remux to MKV with handbrake and ffmpeg.

#8

Why not just make the recording format user-definable? Those that have the hardware to support it can run MP4 or MKV, and those that don't can run mpg. For me it's a space issue. CDVR chokes the life out of my cache disks.

No, I'm not interested in running a simple 72 step process once a week, or writing custom scripts. That changes what should be a simple solution into a time-consuming hobby.

#9

This was addressed above:

#10

Changing mpg to mkv or mp4 doesn't save any space. To do that you have to decode and reencode the video frames into a more efficient format (h264 vs mpeg2).

#11

I think some people are confusing what they want.

Remux a video file's container extension (like .ts) to another, like .MKV or .MP4 is just taking the video and audio tracks untouched, and re-inserting them into the new container extension, the only thing changes is the headers etc for the file extension.

I do this when needed, to like when i trim out commercials for a file i want to save, using MKVToolNix. This is remuxing.

Re-encoding, or converting the file, this means you are reprocessing the video and audio tracks, which no matter how u do it, degrades quality. This is for when one wants to take a video file (no matter the extension) and make it into a different video codec format. Like taking a mpeg2 video track and a AC3 audio track, and encode it into a mpeg4 H264 and MP3 audio track file....and the final file can be a .ts, .mp4, and .mkv...doesn't matter. Or convert a mp4 H264 to HEVC H265 etc.

I like and much prefer that Channels leave the files as they are raw from the tuner source.

Emby, does have a convert to "portable" format where it will transcode the recording on the fly to make it a mp4 h264...but it had its issues and never was very reliable.
And also, i noticed that only certain channels were still mpeg2 while most of them were all already h264. (from the HDHR Prime Tuner i used back then)

1 Like
#12

Well that's what I meant. Why not add ffmpeg to the product with options in the gui to convert and compress recordings overnight?

2 Likes
#13

they dont want to add complexity i guess.

u can easily make your own shell script to do this automatically yourself if u wish.
though, i prefer Handbrake over ffmpeg for video encoding.

#14

This has been discussed in the past and it’s something we want to do. It’s just not high on the priority list.

1 Like
#15

You're talking about the same thing under the covers. The goal with using ffmpeg directly would be to control it through the admin page as an automated task. Handbrake is a desktop tool that is basically a GUI for ffmpeg. One would be a new feature for CDVR, and the other is an extra task with a third party product that is separate and apart from CDVR.

#16

Sorta. The ffmpeg included with Handbrake (and Emby for that matter) is a custom compiled binary. In my experience and testing, using handbrake with the easy to access settings and its tweaks, gives far better results then just using the stock normal ffmpeg.exe u can download.

#17

...and you're more than welcome to spend your time doing that. Once again, apples and oranges.

#18

Yes - I could have been clearer, sorry. I'm not suggesting that anything be re-encoded. Like @speedingcheetah said, keep the streams virgin, just put them in a more capable container. In fact, that's why I'm asking - I want to use chapter marks to annotate where the commercials are, non-destructively.

I don't know of any 'magic' configuration for comskip that nails the transitions accurately 100% of the time, particularly on a mix of HDHR and TVE-sourced content. So I just want to annotate the container with chapter marks determined by comskip. This also allows me to adjust incorrect chapter marks manually later, when comskip doesn't get it right.

I'm just asking if the same audio and video streams could be saved into a more flexible container than MPEG-TS, to avoid having to remux it into MKV as an extra post-processing step.

Not the end of the world if not, just more electrons to re-arrange after the recording is complete.

#19

If that ever happens I hope it's optional and not default.
I prefer the DVR records the native unadulterated stream. Too many things to go wrong otherwise (like Plex tried to do with their dvr).

#20

While Matroska is great for archival purposes, it doesn't do well with live streams. The WebM subset of Matroska does make some improvement on this front, MPEG-TS is still the best for live streams. (That's why it's the standard for broadcast streams.)

Edit: As a follow up, I can speak from personal experience that seeking through a Matroska container while it is constantly changing due to the live stream is a painful experience. Mostly this is because Mastroka likes a header at the beginning, but this isn't possible when streaming live.

If you want to experience what it's like, Tvheadend offers the choice of using either Matroska containers or transport streams (TS). You can give it a try and see how not-great an experience it is.

2 Likes