Suggestions for SD MPEG-2?

Useful and helpful Windows specific command line samples and examples.
Post Reply
timppa000
Posts: 4
Joined: Tue Oct 22, 2019 4:51 pm

Suggestions for SD MPEG-2?

Post by timppa000 » Tue Oct 22, 2019 5:23 pm

A total FFmpeg and video encoding newbie here. Sorry if this has been asked before, I tried to search for older discussions.

I have a bunch of old .rec video files from my old dead digi-record TV box that I salvaged to my PC. I used ProjectX to demux(?) the .rec file into two separate files, the video and audio stream:
- video.m2v (2GB, MPEG-1/2 Video (mpgv), 720x576, 25fps)
- audio.mp2 (188MB, MPEG Audio layer 1/2 (mpga))

So now I'd want to join these to some common container and encoder that hopefully shrinks it nicely with little or no loss of quality.
I am unsure even about the basics, like what container I should choose or does it matter at all, and what encoder. My last touch with any "video encoders" were when .avi and divx/xvid were the kings, but I presume things have moved on. I've understood nowadays everyone uses h264 and h265, but they are mostly optimized for HD, 4K and bigger resolutions.

There are couple of things I try to achieve: the resolution of the video hopefully stays the same, and as there is not much to gain by compressing the audio, it could remain the original. Reading various sites and suggestions, I tried e.g. this:

ffmpeg -i video.m2v -i audio.mp2 -f mp4 -vcodec libx265 -acodec copy -preset veryslow -crf 17 output.mp4

The main problem is that output.mp4 became much bigger than the original video. I am unsure why that even happened since the resolution stayed the same (of course), so what is this 1GB extra padding that the libx265 added into the video file?

Also while the picture quality was very close to the original, there was something odd with interlacing, the odd and even lines were not in sync. Removing interlacing in the VLC player options seemed to fix this, but then the original video file has no such issue.

So, yeah. What container, vcodec and other options should I use to get a smaller but good looking file? If I could shrink it to e.g. 1-1.2GB size with as little loss of quality as possible, fine. If I can't figure it out, I guess I just use the "copy" option also for video and make it a 2.2GB video file which has the exact same quality as the original .rec file?

Extra question, does the "preset" affect the size of the output file at all, or does it just give more quality by processing the output longer? It took me one whole day to process that one video file on my 6 years old PC, and I am unsure if I gain any extra quality by setting it to veryslow.

pandy
Posts: 255
Joined: Mon Feb 24, 2014 1:46 pm

Re: Suggestions for SD MPEG-2?

Post by pandy » Tue Oct 22, 2019 8:17 pm

IMHO H.264 provide best quality/size/encoding speed and your experience with size after re-encoding looks to me like something went wrong - perhaps some artefacts present in video file.
If files are interlaced then you have two options - keep interlace or deinterlace - deinterlacing is always compromise - personally i would keep interlace and address interlace by proper encoder settings.

timppa000
Posts: 4
Joined: Tue Oct 22, 2019 4:51 pm

Re: Suggestions for SD MPEG-2?

Post by timppa000 » Wed Oct 23, 2019 1:02 pm

pandy wrote:
Tue Oct 22, 2019 8:17 pm
IMHO H.264 provide best quality/size/encoding speed and your experience with size after re-encoding looks to me like something went wrong - perhaps some artefacts present in video file.
Yeah i can't quite figure it out why the output file would be (considerably) bigger than the input. My first thought was that ffmpeg had somehow "upscaled" the video file into HD or 4K resolution and that is where the extra size came from, but no, the resolution of the output file was exactly the same as with the original.

What I've read about H.264 vs. H.265, I get the impression everywhere that nowadays one should use the newer one, as it offers much better compression for the same quality, it will be the new de-facto standard with HW support in devices etc. The only downside that was mentioned was that encoding the file (like i am doing now) takes much more CPU power.

But then it also appears these are optimized for HD, 4K and higher resolutions so maybe it doesn't matter for SD videos, but unless there is some drawback in using 265, I guess I could just as well use it. I presume DIVX and XVID are nowadays obsolete, even for SD video files?
pandy wrote:
Tue Oct 22, 2019 8:17 pm
If files are interlaced then you have two options - keep interlace or deinterlace - deinterlacing is always compromise - personally i would keep interlace and address interlace by proper encoder settings.
Do you mean deinterlacing in the video player while watching the (interlaced) output video, or deinterlacing during the encoding? I am unsure if the artifacts I saw were due to deinterlacing or ffmpeg somehow just didn't handle the interlacing well. I would prefer if I could get clean deinterlaced video, shouldn't interlacing already be a thing of a past, needed only for the two decades old CRT TVs?

timppa000
Posts: 4
Joined: Tue Oct 22, 2019 4:51 pm

Re: Suggestions for SD MPEG-2?

Post by timppa000 » Wed Oct 23, 2019 1:08 pm

One more question: what container should I use, or does it matter much?

When I tried the option that ffmpeg simply copies the original video and audio into one, I tried out three choices:

mkv: it gave some error which I don't quite recall now (I'll edit this answer later), it didn't create the output file.

avi and mp4: both created a similar-sized video file (2.2GB), seemed identical when playing the video files in VLC.

When I googled for differences between e.g. mkv vs. mp4, or mp4 vs. avi, I just became more confused as they were suggesting one container may create smaller or bigger video files than the other etc. Isn't it the encoder that decides what the quality and size will be, not the container?

Sorry if my terms are wrong, I don't recall if they are called containers or whatever. I just presume they are there to glue different streams together (video, audio, subtitles), a bit like tar puts files and directories into one tar file without real size benefits, but on top of that you can use compression like gzip to make the tar file smaller.

pandy
Posts: 255
Joined: Mon Feb 24, 2014 1:46 pm

Re: Suggestions for SD MPEG-2?

Post by pandy » Wed Oct 23, 2019 6:39 pm

Well - perhaps new sources are progressive but your sources appear (based on your description) to be interlace - from CRT era... as such you need to choose by yourself what is better for you.

Containers are usually responsible for relatively small overhead - somewhere between 5% and 1% of overall filesize increase.

MP4 container seem to be more popular (native for Apple ecosystem) but relatively restricted - support very limited amount of audio and video codecs, MKV is more versatile but also less popular - some large companies ignore this format so your TV will not play MKV video files for example - if you stick with standard (industry) video and audio codecs then MP4 seem to be better choice for target container.

Your understanding of container seem to be proper - role of container is to pack video, audio, other streams (called elementary streams) in single package easy to use.

To create smaller size you need to focus on video and audio encoder settings - this is crucial and only way to significantly reduce overall size of your files.

Not sure about your source video/audio parameters but i can provide something like this:

Code: Select all

@setlocal
@rem bt470bg, smpte170m
@set color=bt470bg
@set filename=%~1
@set quality=20
@set x264opts="crf=%quality%:level=4.0:qpmin=8:vbv_maxrate=20000:vbv_bufsize=15000:cabac=1:interlaced=1:no_psnr=1:no_ssim=1:bluray_compat=1:open-gop=0:pic_struct=1:aud=1:nal_hrd=vbr:force_cfr=1:fullrange=off:overscan=show:colorprim=%color%:transfer=%color%:colormatrix=%color%:stitchable=1"
@ffmpeg.exe -hide_banner -v 32 -stats -y -i "%filename%" -flags:v +ilme+ildct+cgop -top -1 -c:v libx264 -profile:v high -level:v 4.0 -x264opts %x264opts% -x264-params %x264opts% -c:a ac3 -b:a 192k -movflags faststart -f mp4 "%~n1_.mp4"
Script should encode SD interlace source without deinterlacing with decent quality.
(btw didn't tested script as it is compilation of few other scripts but hope it should work as is).

timppa000
Posts: 4
Joined: Tue Oct 22, 2019 4:51 pm

Re: Suggestions for SD MPEG-2?

Post by timppa000 » Sun Nov 17, 2019 11:28 am

pandy wrote:
Wed Oct 23, 2019 6:39 pm
Well - perhaps new sources are progressive but your sources appear (based on your description) to be interlace - from CRT era... as such you need to choose by yourself what is better for you.
Thanks for the suggestion. I tried your example with some video file but I still decided to try out some simpler method because I don't understand all the options in your example, why are they there etc. Also why use ac3 for audio encoding, shouldn't aac be a better choice, even for stereo?

I found the answer to my question "why does the filesize increase?":

https://superuser.com/questions/1315664 ... -file-size

So it was a misconception on my part. I thought that when encoding already encoded stuff (video and/or audio), at worst, with lossless encoding, the filesize would be the same as the original. Any lossy compression should decrease the size of the file.

But obviously that is wrong, unless the input material is completely uncompressed/non-encoded. If I re-encode an encoded file with a "weaker" lossy compression than the existing one, or lossless, naturally the size will increase because the new encoding will consider the source material as "non-encoded". I will not get any (size) benefits from the original encoding, when re-encoding the file.

So I guess I just need to experiment with different -crf values with either libx264 or libx265 if I can get good enough quality with good enough size decrease (the crf 17 and 18 values I've tried out so far are obviously "too good", increasing the file size). If not, one option is that I merely copy the streams to the new container (-c:v copy -c:a copy) and be done with it. That way both the filesize and quality will remain the same as in the original.

So I will still experiment with something like this, trying out different crf values both with x264 and x265:

ffmpeg -i "video.m2v" -i "audio.mp2" -vf yadif=1 -c:v libx264 -crf 23 -c:a aac -b:a 192k -preset veryslow "output.mp4"

This site:
https://slhck.info/video/2017/03/01/rate-control.html
suggested trying crf 23 for x264, and crf 28 for x265. I've yet to try them, I tried "too good" values like crf 17 and 18.

"-vf yadif=1" is there to get rid of interlacing in the output video. It seems to turn the video file from a 25 fps interlaced into a 50 fps non-interlaced, and at least to me the output seemed quite clean and stable. Similar as to enabling removal of interlacing in the VLC options when playing the original interlaced file. Then again apparently that will also increase the filesize if there are more frames...?

Yeah, still need to experiment more, and maybe I will indeed end up just copying the original streams without re-encoding.

Post Reply
'