Kodi Filmic Effect

Not sure if this is something that this particular forum can help with but I figure what the hell.

I've gone down the route of digitising all my DVDs and Blu-Rays recently and I've been using Handbrake (or MakeMKV where necessary and Handbrake later) to do the ripping and get it into a compressed format that doesn't take up an obscene amount of room on my NAS drive, this is fed to Kodi through a Raspberry Pi that I can control from Kore, an Android App that acts as a Kodi remote control.

However I have noticed there appears to be a curious filmic effect that happens on most of the ripped TV material that doesn't appear on the ripped movies when I play back. This effect doesn't occur on the original DVDs and it doesn't matter what settings I use in Handbrake to encode, it still manifests on playback regardless of whether I use my Pi or a Firestick or fiddle with the Kodi settings or change the display settings on the TV (I will admit this is 10 years old already). If I play the files on my laptop I can still see the filmic effect but its nowhere near as bad on the laptop screen as the TV makes out.

The only common cause seems to be sitcoms and TV shows that were done primarily or exclusively on videotape (those external scenes in the Gourmet Night episode of Fawlty Towers where Basil's faffing around running to and from Andre's and beating his car up and what not are slightly filmic but not to the exaggerated effect the videotape stuff is) so presumably I'm wondering if this is possibly a interlacing issue that I've inadvertently introduced?

There are two places this can happen.

1. Handbrake will usually convert 50Hz motion to 25Hz motion as it deinterlaces to frame rate not field rate (fine for movies and 25Hz TV but terrible for anything shot using 50Hz interlaced video)

2. Some Kodi platforms have lousy deinterlacing. The Pi isn't one of them though - it does a very good job of deinterlacing.

Personally I don't recommend ripping DVDs using Handbrake for Kodi use - I'd always just rip to ISO or VIDEO_TS folder losslessly, and only use Handbrake to do a second encode for mobile devices that won't cope with the original (or where you need a smaller file)

If you play the .ISO or VIDEO_TS in Kodi on a Pi you should get nice 50Hz video (ensure that adjust refresh on start/stop is enabled and that you have 50Hz modes whitelisted)

If you have a Pi 3B or 3B+ you won't need to buy the MPEG2 licence for the Pi, but if you are running something less powerful then the MPEG2 licence (£2.40) will avoid software decoding, allowing the higher quality deinterlace.

(Amazon Fire TV sticks aren't a great Kodi platform for decent interlaced video)

I run quite a few Pi 3Bs and 3B+s running LibreElec and they handle DVDs, Blu-rays, HDTV and SDTV with proper deinterlacing to 1080p50 with decent MMAL Advanced deinterlacing (similar quality to YADIF 2x)

Thanks Noggin, I sort of had a feeling it was a Handbrake thing. It is a Pi 3B I have. I should have probably said I used LibreElec as a boot OS on the Pi too.

I'll rip a DVD with MakeMKV to see how it looks in its raw form through Kodi and then see if I can use FFMPEG directly or something to cut the file size down rather then letting Handbrake make a hash of it.

Thanks

I imagine you'll need to convert the footage to a format that either keeps it interlaced, or converts it to 50p. Sounds like the way you're doing it is converting the footage to 25p.

I'd probably deinterlace to 50p if I were transcoding (and I do) - which will avoid problems on platforms that don't handle deinterlacing properly.

The w3fdif deinterlacer in ffmpeg is pretty good - so a -vf "w3fdif=complex:all" filter in your ffmpeg command line is a good bet. (It's a deinterlacer designed by the BBC for use in standards converters and digital video effects gear, and uses a neat V/T filtering approach that avoids motion compensation or adaption that can go wrong)

I'd probably use h.264 for the video codec - and use libx264 (not any hardware accelerated encoding - as the quality hit you take will mean an increased file size or lower quality pictures at a given bitrate) You can chose to run at a constant bitrate, constant quality, or do a two pass encode that increases quality at the expense of encode time (for a target average bitrate)

I used to use two-pass encoding when storage space was tight, I know just use a reasonable -crf (constant quality) option (-crf 18 is pretty visually lossless, but won't reduce file sizes much. -crf 23 is a default that is OK - and lower bitrate - but I can see additional artefacts being introduced)

So I'd use -vcodec libx264 -crf 18 for my video codec parameters.

For audio I'd usually keep that untouched using -acodec copy unless I was going to playback DVDs (which usually use AC3/Dolby Digital) on a system without Dolby support . If that is the case I'd transcode to AAC, using something like -acodec aac -ab 256k for a decent quality stereo AAC

I'd usually .mp4 as my output wrapper as it has good support (though mkv can be more flexible)

Example would be - with an input 576i25 MPEG2 + AC3 DVD in a .mkv wrapper where I want the first track (video) and second track (audio) and no subtitles or additional audio tracks output as 576p50 h.264 with AAC audio.

ffmpeg -i "DVD.mkv" -map 0:0 -map 0:1 -acodec aac -ab 256k -vcodec libx264 -crf 18 -vf "w3fdif=complex:all" "DVD.transcoded.mp4"

If you don't know how many tracks there are in a file, and which ones are which, then you can run ffmpeg on the file with nothing other than the -i option with the source filename and it will tell you.

(And yes - ffmpeg experts - I know I should have switched to the new format of -v:c -a:b -v:filter etc. but I can never remember the precise syntax!)

noggin: when you say "some Kodi platforms" is this basically referring to devices with GPUs? I don't think it uses hardware acceleration on the Pi unless you have the licence code and then only for MPEGs.

The Pi does it all in software I think, but it does it very well. I watch 720p60 streams all the time and they work great.

Yes - though outside the x86 PC arena, in the ARM SoC arena it isn't usually GPUs that handle video acceleration and deinterlacing, but a separate VPU (Video Processing Unit) block. (Though sometimes GPU blocks are used for some deinterlacing processes)


The Pi is slightly different because they are squeezing a lot of processing out of a small platform and the Broadcom Videocore SoC it is based on is effectively a GPU with an added ARM CPU, not an ARM SoC with an integrated GPU+VPU (the way the Pi boots is different to most ARM SoCs as a result).


1. The Pi comes as standard with h.264 decode and encode without a licence.

2. The Pi has optional MPEG-2 and VC-1 decode with paid for licences (£2.40 for MPEG2, £1.20 for VC-1 last time I checked)

3. Deinterlacing of h.264, MPEG-2, and VC-1 interlaced content is usually hardware accelerated using MMAL code (which runs in the GPU/VPU I believe. The balance of VPU/GPU grunt used for MMAL deinterlacing has changed over the years I believe (with some code moving to the GPU)

In the early days only the Quad Core Pi's (2B, and now 3B/3B+/3A+) could use MMAL advanced (roughly equivalent to YADIF 2x) deinterlacing for HD 1080i content, with the single core Pi's (Zeroes, original A/B, A+ and B+) only initially able to use MMAL Bob at 1080i.

Similarly the single core Pi's couldn't software decode MPEG2 - so you had to have the licence key to watch SD or HD MPEG2.

Now the 3-series models (and I think the 2B) have enough CPU power to software decode 576i SD MPEG2 (not sure about 1080i HD MPEG2) so the licence isn't required for basic Freeview SD and DVD viewing (and I think there is still power for SD MMAL Advanced de-interlacing too - though your power consumption and heat dissipation issues will increase)

For HD interlaced MPEG2 (US OTA TV, very early Blu-rays etc.) it is worth having the MPEG2 licence whatever model you have.



Well 720p60 has no deinterlacing - so that won't be an issue - but h.264 decoding with hardware acceleration (which is likely to be the dominant standard for any streaming service) is standard in all models of Pis - even the Zero.

The Pi has no full hardware VPU accelerated decode for h.265/HEVC encoded content - but a huge amount of work has gone into optimising h.265 decoding using CPU/GPU/VPU elements working together which means the Quad core Pis can handle 720p HEVC/h.265 streams and moderate bitrate 1080p24 stuff (though I think 1080p50 is pushing it, though may be possible with some overclocking)

More recent SoCs like the AMLogic S905/905X/905D/912, a lot of the Rockchips etc. have built in hardware VPU decode for h.265/HEVC stuff up to 4K (even the older S8xx series did 1080p HEVC/h.265)

Hi Noggin, I've had chance to have another play with this.

MakeMKV seems for whatever reason be applying a slight filmic effect on the TV material but that's insignificant compared to what Handbrake was introducing on TV material. Feeding a ripped MakeMKV file through FFMpeg with the above syntax gives me a file size twice what I had before but presumably that'll be because of the 256k sound and also the constant bitrate (Handbrake defaulted 192k for audio and defaulted to VBR because it was trying to be clever), but in any case I got a smoother picture out of the above syntax looking like the DVD source and some smooth scrolling credits to match, so I'm happy.

Thank you very much for your help on this, much appreciated. You can have some kudos.

MakeMKV shouldn't touch the video encoding or the audio encoding. If you are seeing a filmic effect on the output of MakeMKV, it's almost certainly caused by your playback solution not handling interlaced content correctly (not MakeMKV adding any artefacts.) MakeMKV literally just takes the video and audio streams from the DVD VOB files and puts them in a Matroska MKV wrapper - leaving the actual video and audio data untouched.

My suggested ffmpeg solution deinterlaces from native 25 interlaced frames (i25) per second (which has 50 fields per second motion) to 50 progressive frames (p50) (which preserves the 50 fields per second motion)

50p content removes deinterlacing limitations on your playback device (you've shifted the deinterlacing offline to ffmpeg) - and assuming your playback device is properly configured to output at 720p or 1080p 50Hz not 59.94/60Hz you will get nice smooth motion of native interlaced 576i25 content that has been converted to 576p60.

Also note that the command line I suggested is only using a constant bitrate for the audio (if you are happier with lower quality 192k or 128k audio - feel free to drop it).

For the libx264 video encoding it is using constant quality (-crf) not constant bitrate (-vb). A -crf of 18 is deemed close to visually lossless, a -crf of 23 is seen as pretty good. CRF encoding is a good compromise for speed vs quality - but you can switch to constant bitrate (replace the -crf value with -vb value e.g. -vb 4M for 4Mbs), or do variable bitrate two pass.

For two pass you still use "-vb" for the target average bitrate but then also add "-pass 1" for the first pass and "-pass 2" for the second pass. You can use "-an" rather than "-acodec aac -ab 256k" for the first pass to avoid time wasting by encoding the audio twice. The first pass is used by ffmpeg to analyse the entire video file, the second pass then uses this information to work out the optimum bitrate for each section of video based on this analysis. As a result you'll see a few log files generated by the first pass, which you shouldn't touch. You can also output the video for the first pass to a Null device rather than a file (as you don't need the video encode from the first pass) - but this varies depending on whether you are on a PC, Mac or Linux box.

I noticed if you deinterlace 1080i25 to 1080p50 then back to 1080i25 whilst it preserves the motion softens the picture very subtle though.

That will depend on your deinterlacer.

If you are watching any interlaced content on an LCD/LED, OLED or Plasma - then your TV is deinterlacing (or your DVD/Blu-ray player might be if you are playing a DVD on that and outputting a progressive video signal), and you are simply comparing your TV/Player's deinterlacing and scaling algorithm with ffmpeg's deinterlacing algorithm (and your Kodi platform's scaling algorithm)

Only CRTs (and the very early Hitachi ALiS plasmas) display interlaced content as natively interlaced after all. (And ALiS only did it for HD content)

If you are offline deinterlacing in ffmpeg you will also be decoding and re-encoding - so the concatenation of codecs may knock the edges off the picture a bit. That's why I use quite a high -crf of 18 when doing libx264 re-encodes.

w3fdif (aka Weston 3-field) is a BBC-designed deinterlacer that uses a clever V/T filter rather than any motion adaption or compensation. It delivers a consistent and pretty high-quality deinterlace. YADIF 2x is also a popular deinterlacer, but it is adaptive, so can get things 'wrong'. I personally prefer w3fdf as it's more consistent - but it does expose alias artefacts in your source material (such as caused by LED matrix walls etc .)

This makes sense as I was just looking at the file through the laptop screen (which I have checked is actually refreshing at the standard rate of 60Hz and the file was at 25fps so yes that would explain that effect).



Is there any real difference in final file size between 256k audio and lower (most DVDs seem to be encoded to 192k) and variable bit two pass rate for the video? I know it really depends on the source material and how complicated it is but the general consensus from everything I've read online seems to suggest the variable bit rate generates a better picture but will obviously take longer to render all other things being equal.