Feature Enhancement request - crop video filter controls


I purchased the DVR yesterday and so far am impressed. However I ask that you add some options to allow us to manipulate the video during playback from DVR and live TV.

I have basic cable and all channels except locals are broadcasted in SD. In USA the channels are broadcasted in 4:3 however the actual content is 16:9 so the broadcaster letterboxes the content.

I have work arounds using vlc that correct this by cropping the top and bottom. For instance here is the shortcut I use for VLC.

"C:\Program Files (x86)\VideoLAN\VLC\vlc.exe" --video-filter=croppadd{croptop=60,cropbottom=60} --deinterlace=1 --deinterlace-mode=blend --qt-minimal-view

Now the video plays back in 16:9 correctly. My thoughts were you could add a section where we could add our own video manipulation profile settings. Some channels (bounce) broadcast in 16:9 however all the content other than commercials is broadcasted in a 4:3 ratio. So in this case if they play a 16:9 movie they are playing 16:9 inside of 16:9.

Here is a shortcut to combat this last described problem

"C:\Program Files (x86)\VideoLAN\VLC\vlc.exe" --video-filter=croppadd{croptop=60,cropbottom=60,cropleft=88,cropright=88} --deinterlace=1 --deinterlace-mode=blend --qt-minimal-view

A lot of channels are like this. So I asking for the ability to allow us to create these crop settings and then allow us to apply the settings to a couple of places. I would first suggest allowing us to set the custom filter on the channel listing so that any playback via live tv or via DVR would adopt the settings for the channel. The 2nd setting would be to allow an override on the actual recording when its made, because yes some things actually broadcast in 4:3. Also an override would be needed for live tv as well in case you have a 16:9 crop set at the channel level which works for 95% of the shows but that show that is being broadcast is actually in 4:3.

If you implemented the crop scenario you would have to probably resize the video to 720:480 and apply a 16:9 AR options to ffmpeg. Or if your cropping to 4:3 you would send the 4:3 AR command and also keep 720:480.

I tested another competitor app called InstaTV for appleTV and they offer a ZOOM mode button during playback. This also works but I would prefer the video is sent correctly to begin with.

Some people may say just use the ZOOM feature on your TV. However on my TV the ZOOM button only works if the incoming content is detected as 480i in the video stream. So if I am watching actual cable then the ZOOM option works and I do have my TV hard coded to go into ZOOM mode on that type of broadcast. However when using the product via appletv or roku you are no longer receiving an interlaced signal because the roku or appletv is outputting a progressive based signal from the physical unit.

I don't see this being too hard to implement, especially the actually encoding piece because you are already doing that with ffmpeg. This just adds some manipulation the original stream. For the AppleTV app since you reading directly from the HDHomeRun you would have to add a zoom control in the same manner as InstaTV. Of course when the AppleTV reads from DVR recordings you could resize on the fly there and the user wouldn't have to press any zoom button.

I am willing to do any and all testing necessary. I am pretty knowledgeable in the video encoding with ffmpeg. I am testing using the beta ROKU app, in this scenario live tv is done by the man in the middle which is the dvr server. Just hoping for some advanced controls in that man in the middle scenario. I am also testing with web player so that feature would be nice there too.

For clarification of the recording of items the drop down selector for crop filters does not alter the actual recording only the preferred playback video filter adjustment. So when you playback if its set to default on the recording it uses whatever is set at the channel level, which may be nothing at all. If its set to a pre-defined filter then during playback it uses that filter.


Lets remove these black bars from my SD channels...

Left is original broadcast via vlc, right is same broadcast being played with video filters applied. Please let us have native playback with video correction :slight_smile:

Here is an example of bounce 16:9 inside of 16:9 with corrections applied via vlc.

i had this request sometime back and @maddox shot me down. hopefully they’ll realize that this is a necessary feature. on my samsung TV i need a ‘custom’ zoom to fix 16:9 video on 4:3 channels and it is a royal pita to go in and out of that mode. so i’ve resigned myself to watching postage stamps whenever something was recorded from an SD channel.

1 Like

Well it’s a very important feature. They are already running ffmpeg and doing a re-encode. There is no harm in adding -croptop -cropbottom commands to the same command line.

I also don’t have the ability to zoom it like you said you do. I can stretch only unless it is a true 480i signal. This just makes a distorted video and that annoys me to death.

You might like my VLC shortcuts. Try them. But this is just another work around to a real problem.

Agree that this is an area where Channels is lacking.

One reason this hasn’t been a priority is because most users don’t watch standard-def channels. In fact one of the most frequent questions is about how to hide/disable them.

Anyway, I have some ideas on how to improve the situation here. ffmpeg has a video filter called cropdetect which can automatically calculate crop parameters, and with some changes I think we can make that feed into the crop filter automatically as well. I would much prefer an automatic solution than asking users to try to configure manual crop parameters for each of their channels.

That would be appreciated. Never used that feature before. A quick google though came up with this


Don’t know if you could do that in a live stream though? Seems you would have to first parse the input and then do something.

With these SD channels though if cropped correctly it would usually crop part of the channel logo off or part of the tv rating. I wonder if the crop detect would consider that to be part of the actual video stream.

In my case cropping 60 from top and bottom always results in a 16:9 frame. I can’t speak for every provider though. They do other weird things too with the SD broadcasts such as always broadcast with 16:9 flags even though the content is 4:3. The whole SD broadcast with my provider is kind of a mess. It could be so much better. I don’t know why they bother with trying to support old 4:3 TV’s. Just broadcast a 16:9 480i signal already…

If I can be of any assistance let me know. I was goofing with idea of putting a wrapper script in front of your ffmpeg binary to do this automatically. When you call ffmpeg it would call my perl script or shell script and I would parse the channel detail and then call ffmpeg with your same options with added crop options :slight_smile:

Feel free to hack around, as I won’t get a chance to dig in here until October.

Note that ffmpeg is not used at all when watching recordings on the Apple TV

1 Like

OK. Did some research last night and this morning/afternoon. Here is what I have come up with so far.

TV is broadcast in SD in the following formats for me:

4:3 Modes (pretty much all of these are letterboxed 16:9 content):
352x480 [SAR 20:11 DAR 4:3]
528x480 [SAR 40:33 DAR 4:3]
544x480 [SAR 20:17 DAR 4:3]
704x480 [SAR 10:11 DAR 4:3]
720x480 [SAR 8:9 DAR 4:3]

16:9 Modes
528x480 [SAR 160:99 DAR 16:9]
704x480 [SAR 40:33 DAR 16:9]
720x480 [SAR 32:27 DAR 16:9]

All of the 4:3 modes have 16:9 video inside of their frames. The SAR corrects everything to 640x480. The following ffmpeg video filter corrects all of these to 720x480 with SAR 32:27 DAR 16:9. Which is the equivalent to a NTSC DVD at 16:9. I really wish the states would just broadcast like this.

-vf “crop=in_w:in_h-120,scale=720:480”

and here is an ffplay command to play a video.

ffplay -i “Family Guy (1999) - S01E03 - Chitty Chitty Death Bang.ts” -vf “yadif,crop=in_w:in_h-120,scale=720:480”

Here a few playbacks for some channels, to demonstrate functionality.

399 PPVB 352x480 [SAR 20:11 DAR 4:3]
42 FOOD 528x480 [SAR 40:33 DAR 4:3]
52 MSNBC 544x480 [SAR 20:17 DAR 4:3]
2 FOX 704x480 [SAR 10:11 DAR 4:3]
64 FX 720x480 [SAR 8:9 DAR 4:3]

ffplay -i “” -vf “yadif,crop=in_w:in_h-120,scale=720:480”
ffplay -i “” -vf “yadif,crop=in_w:in_h-120,scale=720:480”
ffplay -i “” -vf “yadif,crop=in_w:in_h-120,scale=720:480”
ffplay -i “” -vf “yadif,crop=in_w:in_h-120,scale=720:480”
ffplay -i “” -vf “yadif,crop=in_w:in_h-120,scale=720:480”

I haven’t made the wrapper yet as I was trying to nail down the ffmpeg video filters. Its been 5 or so years since I messed with this and all the video filters have changed for cropping and scaling.

So my original request could probably be simplified by just having a crop feature and then doing an ffprobe first to determine if one of those resolutions and then perform said crop before playback.

Problem is for live stream it really would slow down playback because it first has to ffprobe the incoming stream.

Still experimenting.

Ok the wrapper has been updated. It works with the ROKU player and web interface. It will crop both live and dvr SD recordings. I disabled scaling as its not needed and causes a lot more cpu usage. The code is very ugly having to intercept the channels dvr calls and re-write them. So don’t complain it looks so bad :frowning:

Rename ffmpeg to ffmpeg_real. Make a symbolic link to wrapper for ffmpeg. Adjust channel mappings accordingly.


channel mapping

Wrapper code above has been updated. Now works with live tv and dvr recordings. Works with roku and web interface. It also works on iOS by using the web interface. You will need a decently fast computer for it to work because it is not doing hardware acceleration.

This is a unix script. Tested on Linux (synology). You will need some unix skills to install this. You will also need to build a channel listing like I included and or modify the script too as needed.

The only thing missing is if the tuners are full, it should exit better.

I’ve tested it for a while and it seems to work pretty good. More testers appreciated. Please let me know if you try it and your thoughts. Love to hear some feedback. Be great if devs tested it and decided to implement something similar to make this script useless. As is, everything is now automated for me. Well, there are some improvements. Right now it crops everything though there are some tv shows for instance that do actually play in 4:3, frasier for instance. My original suggestion would allow us to record those in the original aspect ratio.

I think the amount of people who are looking for something like this (ie: the subset of users who watch SD channels that are broadcast in the wrong aspect ratio) is going to be extremely small. But it is cool that you got it to work. I remember using one of your scripts years ago… I don’t even remember what it was, but I recognize your username and remember that your scripts were popular.

You are probably correct in your assessment. Only people who need this are probably people in USA who only have basic cable without a digital HD package. Sometimes its free with internet service. On Comcast it was cheaper to buy basic cable + internet than just internet. On Charter they gave it away free. Though this was years ago.

For me it adds a lot of value to have things actually displayed properly. Even if it is a poor picture quality. This is actually less than DVD quality due to their dumb letter boxing. I’ll look at updating this code to support a couple other platforms. I’ve tested another competitor product and it looks like it will work, but that competitor doesn’t announce their channel number in their data, so I have to probe the stream to decide what to do. That slows things down a lot :frowning:

we watch a lot of PBS and the local affiliate’s 2nd sub channel is SD. so you end up with a lot of HD-in-SD programs. outside of that, i agree that whatever is being presented in these formats are probably infomercials or something :slight_smile:

i guess my thinking is that this was a feature found in that “cat” product for the mac and we used it all the time, and i’m missing it now.

Been working on this most of the day. The version now on dropbox uses crf encoding and some extra x264 options. It is very efficient. Uses a fraction of the cpu I was using before. Using about 15% of my cpu (Intel® Pentium® CPU N3710 @ 1.60GHz). This is a crap cpu that comes with the synology.

I’m very satisfied with the progress. Still need to make wrapper work with other vendors.

The channels DVR auto updates often however. It undos my modifications. Will need to create another job to monitor if they pushed a new release and make necessary corrections.

For those members of the community who state a feature like this is only applicable to a subset of users please stop functionality is functionality not all channels are broadcasted HD that all stations have HD frequencies.
I have full premium packages 584 channels yet some stations just did not plan to spend for HD as an example Nicktoons on Comcast those cheap SOB's.

Referring to channels development team simply added stop being lazy you're already re encoding "autpcrop" the channels DVR service is sweet low-fat and dependable the price is steep so I expect so I expect you divvy up that workload and get it done

Why don’t you just use the wrapper supplied by @HolyRoses?

@tmm1 already mentioned he would be looking into it this fall. Calling people lazy is not very nice, and doesn’t normally excite people to help. He has to prioritize fixes and features.

1 Like

“Why don’t you just use the wrapper supplied by @HolyRoses?”

I’m using the dockerized channels, as part of a bigger whole purposely focusing on the data and not the underlying config effective keeping my setup wonderfully easy to support. I may have to implement the wrapper but hoped to see this brought to the main line. Thanks to the creator for the effort BTW. as for the numerous channel pass-through recommendations given to my customers, i wont be able to assist them.

@tmm1 already mentioned he would be looking into it this fall. Calling people lazy is not very nice, and doesn’t normally excite people to help. He has to prioritize fixes and features”

IMO i call it as I see it and MO is a vastly creditable.

I should not justify calling an entity lazy, but if it should have been address then tell my a better reason why it has not happened.

This product does what?

  • warehouse guide info
  • record / save a stream from tuner
  • can be later played back

Those functions should always be at the top of the offering / capability matrix

if “can be later played back” but with inherit visibility defect happens it should be addressed. losing 1/3 picture is a defect.

upon examining the reason why, and seeking out a resolution.


possibly at 33% 66% to avoid inaccurate cropping.

I retract and apologize for calling Channels Lazy . I should have said, Channels you charge $20 /app + 8$ / mo why wouldn’t you add more resources to address this.


  • warehouse guide info – is working stable
  • record / save a stream from tuner-- is working stable
  • can be later played back – possibly 70% working

A fix for this is in the works. It’s much more technically challenging than you might guess at first glance.

much appreciated, and for such a wonderfully developed app i wouldn’t call the solution a fix. / i.e. was never broken just overlooked or not exposed.
To be 100% clear channels is tight / small and 100% a must have app to complement a HDhomerun(s).

post processing for file size (encoding), cropping would be terrific with these sometimes watered down broadcast. You’re already keeping me from using the plexdvr attributed to your great interface and better live TV experience.