« Topics
12
noggin14,159 posts since 26 Jun 2001

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?

If you are playing back content on a platform that decodes (or will passthrough) Dolby Digital then there is no need to transcode it - so you can do an "-acodec copy" and leave it untouched.

However if you are taking a 192k Dolby Digital (aka AC3) 2.0 source and transcoding it, you want to avoid concatenation compression artefacts (i.e. the Dolby Digital psychoacoustic encoding interacting with the different AAC psychoacoustic.) As a result I usually bump up the AAC bitrate a bit to try to avoid introducing needless compression artefacts. You could go a bit lower if you were starting with a cleaner, lossless compressed (or uncompressed) source like WAV, FLAC, Dolby True HD, DTS HD MA etc. However for the sake of 64kbps it seems a bit pointless. If you can't hear the difference, go for your life !

Quote:

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.


Variable bitrate will give a better picture for a given average bitrate, than constant bitrate at the same bitrate - and thus eventual file size (everything else being equal), and two-pass encoding will optimise quality for a given bitrate yet further, at the expense of encoding speed. However if you use -crf encoding you're chosing to use a variable bitrate to achieve a constant quality, at the expense of fixing the bitrate and file size. However the result is also faster. For me it offers the best compromise between speed and quality - as storage is of relatively low importance to me (so I don't mind if the files are a bit bigger)
noggin14,159 posts since 26 Jun 2001
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.


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).


Ah - never judge any video quality on a laptop, PC monitor, tablet or phone (with the possible exception of the current iPad Pros which have support for multiple refresh rates). Only ever make judgements on a display that is correctly displaying your content at the right refresh rate. (This is why broadcast edit suites still have monitors as well as PC screens in them...)
harshy5,961 posts since 24 Mar 2001
I noticed if you deinterlace 1080i25 to 1080p50 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 .)

Thanks noggin after reading your advice sometime ago I been using the bbc based deinterlacer but not the crf so I’ll build that into the script and try, it’s really fascinating I wish I could find a job doing this 👍🏼
noggin14,159 posts since 26 Jun 2001
I noticed if you deinterlace 1080i25 to 1080p50 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 .)

Thanks noggin after reading your advice sometime ago I been using the bbc based deinterlacer but not the crf so I’ll build that into the script and try, it’s really fascinating I wish I could find a job doing this 👍🏼


-crf is just a way of fixing picture quality, rather than bitrate. If storage space isn't a major issue then -crf 18 should be pretty transparent.
1
harshy gave kudos