Motion - FF Mpeg Increase Film Quality Patch

To increase the quality of FFMpeg films by specifying quantizer level

Description of Patch

The problem: Timelapse capture files (mpeg-1) were showing artifacts and image quality degrading after the first few frames.

On looking into the frames of the mpeg files (using VirtualDub) I saw when the artefacts occur. It is any time after the first group of pictures (GOP). GOP is 10 for Mpeg-1 (constant hardcoded into Motion). ie. Frame 0 is an I-frame, followed by 9 P-frames. By frame 9 the quality was getting worse (not good enough for a security application), then we have frame 10 (an I-frame again). However the problem seems to get worse - after a few GOPs the image detail in background areas (areas such as trees) has completely gone. Even an I-frame is not a full-detail picture any more. This kept me puzzled for some time.

I have attached a patch below (SWpatchFFMPEGquality) which is against the snap from 2006-11-30 but should work for other versions. It's only a few lines.

The patch was quite simple, in ffmpeg.c I have specified minimum and maximum quality settings for the encoder. Previously they were not specified, and it looks as though ffmpeg used a highly flexible default (max 2 min 31?) which in my application chose to encode with worse quality as time went on. It is not known why that was, maybe a memory shortage perhaps (my system has only 32Mb RAM).

I have tested the patch using timelapse capture (which only uses the mpeg-1 codec) and it works well. A sample movie is on my web server at: 84.51.146.238/movie_q2-4_1500kbps.mpg (3Mb)

This may be an issue for some: I have tried specifying a low bitrate using ffmpeg_bps and the mpeg-1 file does not seem to respect the setting. Maybe the quality setting, wins over a conflicting bitrate setting. For me, the quality is more important than the size of mpeg-file so it is acceptable. If I want a smaller file size I will reduce the q specified.

A brief explanation of ffmpeg q numbers. They relate to the quantization during encoding, and how much detail is discarded. Q=2 is the best quality. Q=31 is the worst quality.

Thus, as in the patch, setting qmin=2 and qmax=4 produces a 'very good' quality encode with a little quality variation permitted.

Before integration, I guess it will require testing with other ffmpeg codecs, although I see no reason why it should not work with all. A hard-coded ffmpeg 'q' parameter is probably not desirable, so a new config file option would be the answer (config option ffmpeg_q or similar). I suspect it is acceptable to set qmin and qmax to the same number, since it appears to over-ride any bit rate specified.

However I do not yet have the knowledge to add config file options (this I am working on) but I think in this case one is justified. I have read the comments about how little is known about the ffmpeg interface, this looks like an oversight which has been present for some time. The improvement I saw in mpeg-1 film quality was remarkable and this patch would benefit others. Could someone else add a config file option to 'drive' this patch, before I can? Many thanks if you can.

Installation of Patch

Download the patch file. If it is packed as a gz or tar.gz unpack it first. Then copy it to the motion source directory and issue the command (assuming the patch file is called filename_of_patch_file.diff)

patch < filename_of_patch_file.diff

Then re-build Motion and test the patch.

Change History of Patch

  • 1.0 Initial revision

Discussion and Comments


Simon, I'm testing this patch now and will let you know. I'm using msmpge4 codec for the normal video files and have timelapse disabled usually.

-- JoergWeber - 05 Jan 2007

Many thanks Joerg,

It will be good to find out if it works for all codecs. Even if the quality is not controlled by those parameters for msmpeg4, even if it is not harmful we know a little more.

Best regards, Simon.

-- SimonW - 06 Jan 2007

I have tried the settings with msmpeg4 and I cannot see any difference. It doesn't seem to have any effect with this codec - at least not a noticeable one.

-- JoergWeber - 07 Jan 2007

Well, it's good to know there is no visible effect. I guess you're still happy with the output quality or you would have said.

I refer everyone to the FFMPEG documentation at http://ffmpeg.mplayerhq.hu/ffmpeg-doc.html

...where all the options are listed. Unfortunately there is very little explanation of 'what they do'. I guess we should be looking for an 'MPEG Compression for Dummies' document.

Thanks for your help Joerg!

-- SimonW - 07 Jan 2007

Update: I have 'discovered' the option ffmpeg_variable_bitrate and when enabled, it produces the same effect as the patch. Only one quality setting is permitted, rather than a minimum and a maximum. eg. ffmpeg_variable_bitrate 2

I guess the only reason for this is I didn't read the docs 100%, and ffmpeg_bps seemed to be the only relevant config option, but 'hiding' lower down there was ffmpeg_variable_bitrate.... how dumb.

Patch changed to Cancelled status.

-- SimonW - 10 Jan 2007
Topic revision: r7 - 10 Jan 2007, SimonW
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Please do not email Kenneth for support questions (read why). Use the Support Requests page or join the Mailing List.
This website only use harmless session cookies. See Cookie Policy for details. By using this website you accept the use of these cookies.