Cannot achieve better picture quality with MPEG2 - help needed
I'm struggling to achieve better picture quality with mencoder and MPEG2, especially with video that contains gradients. I've uploaded a test example to ftp://upload.mplayerhq.hu/MPlayer/incoming/ File : gradient.avi (an lossless FFV1 rgb32 video file used for encoding) File : screenshots_gradient.psd (a photoshop file containing screenshots to compare original to encoded screenshots) The PSD contains three labeled layers: - the first, the source, an uncompressed gradient - the second, a screenshot of the resulting MPEG-2 created with MEncoder (command line to follow) - the third, a screenshot of the resulting MPEG-2 created with Adobe Media Encoder. You'll notice that the Adobe Media Encoder screenshot has a much better picture (far less color distortion and far less banding) than the MEncoder screenshot. I'm hoping to achieve better results with MEncoder. I'm not concerned with bitrate or time to encode, I simply want to match the picture as best I can. I've tried countless command line options but still to no avail. Can someone help me with this? Is it possible to get the picture retention I'm after with mencoder and MPEG-2? Here is the command line (pass 1 of 2 passes) I used for the above example: mencoder -sws 9 -oac lavc -ovc lavc -of mpeg -mpegopts format=mpeg2:muxrate=10080:tsaf:telecine -vf scale=720:480,harddup -srate 48000 -af lavcresample=48000:0:2 -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=7000:vbitrate=6000:trell: mbd=2:preme=2:dia=4:predia=4:precmp=2:cmp=2:subcmp=2:cbp:mv0:acodec=ac3: abitrate=224:keyint=12:vpass=1:autoaspect:lmin=0.01:dc=10:vstrict=0 -ofps 24000/1001 input -o output
On Fri, 23 May 2008 13:38:35 -0400 Nicolas Hesler <nicolas.hesler@sheridanc.on.ca> wrote:
Here is the command line (pass 1 of 2 passes) I used for the above example:
mencoder -sws 9 -oac lavc -ovc lavc -of mpeg -mpegopts format=mpeg2:muxrate=10080:tsaf:telecine -vf scale=720:480,harddup -srate 48000 -af lavcresample=48000:0:2 -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=7000:vbitrate=6000:tr ell: mbd=2:preme=2:dia=4:predia=4:precmp=2:cmp=2:subcmp=2:cbp:mv0:acodec=a c3: abitrate=224:keyint=12:vpass=1:autoaspect:lmin=0.01:dc=10:vstrict=0 -ofps 24000/1001 input -o output
Don't use encoding options you don't (at least basically) understand... *cmp=2, mv0, and possibly dc=10 are the likely cause of your problems.
RC wrote:
On Fri, 23 May 2008 13:38:35 -0400 Nicolas Hesler <nicolas.hesler@sheridanc.on.ca> wrote:
Here is the command line (pass 1 of 2 passes) I used for the above example:
Don't use encoding options you don't (at least basically) understand...
*cmp=2, mv0, and possibly dc=10 are the likely cause of your problems.
The command line I provided was simply a sample. I did try countless iterations of options. This just happened to be the last one I had tried. dc=10 was in there because if I set vqmin to 1, dc=10 was the only way I could eliminate strobing artifacts. mv0, and cmp=2 were taken from the docs. (14.8.3.4. Advanced Options)
RC wrote:
and possibly dc=10 are the likely cause of your problems.
See www.cinemacraft.com/files/doc/ccb_267e.pdf on page 23 of the document or 29 of the PDF, "2.5.8 Intra-DC precision In case of encoding in MPEG-2, the bit precision of the DC coefficient of intra-blocks can be specified. To create DVD-Video, 10 is recommended." is this recommendation different for different encoders??
Nicolas Hesler wrote:
I'm struggling to achieve better picture quality with mencoder and MPEG2, especially with video that contains gradients.
I've uploaded a test example to ftp://upload.mplayerhq.hu/MPlayer/incoming/
File : gradient.avi (an lossless FFV1 rgb32 video file used for encoding) File : screenshots_gradient.psd (a photoshop file containing screenshots to compare original to encoded screenshots)
The PSD contains three labeled layers:
- the first, the source, an uncompressed gradient - the second, a screenshot of the resulting MPEG-2 created with MEncoder (command line to follow) - the third, a screenshot of the resulting MPEG-2 created with Adobe Media Encoder.
You'll notice that the Adobe Media Encoder screenshot has a much better picture (far less color distortion and far less banding) than the MEncoder screenshot.
This appears to be an effect of the colorspace conversion from BGRA to YV12. -sws 8 appears to produce more even banding. You can try the different scalers yourself. For example: $ mplayer gradient.avi -vf scale=720:480,format=yv12 -sws 8 -Corey
Corey Hickey wrote:
This appears to be an effect of the colorspace conversion from BGRA to YV12. -sws 8 appears to produce more even banding. You can try the different scalers yourself. For example:
$ mplayer gradient.avi -vf scale=720:480,format=yv12 -sws 8
-Corey
I've uploaded another PSD comparison to ftp://upload.mplayerhq.hu/MPlayer/incoming/ The file is called: rgb24_vs_rgb32.psd It seems as though the colorspace conversion is a part of the problem. If I use a rgb24 source (FFV1 file) instead of the rgb32 source, the colors are more accurate. I've broken the PSD file into several layers to show screenshots of the same gradient. If you look at all of the samples (rgb32 vs rgb24), the green in the upper left corner of the frame is much closer to the original in the rgb24 samples (perceptually, the colors are better everywhere in the rgb24 screenshots). A quick test with ffmpeg reveals that the same problem (inaccurate colors with rgb32 source) exists in ffmpeg. Is this a bug? If not, how can it be explained/fixed? Now, the secondary issues is the complexity of the banding. In all of the rgb32 screenshots, the banding is more complex (retains more detail??) than the rgb24 screenshots. Can I improve the complexity of the banding with the rgb24 source? Is this another symptom of the colorspace conversion??? Your help is much appreciated. Thanks!!!
Nicolas Hesler wrote:
Corey Hickey wrote:
This appears to be an effect of the colorspace conversion from BGRA to YV12. -sws 8 appears to produce more even banding. You can try the different scalers yourself. For example:
$ mplayer gradient.avi -vf scale=720:480,format=yv12 -sws 8
I've uploaded another PSD comparison to ftp://upload.mplayerhq.hu/MPlayer/incoming/
The file is called: rgb24_vs_rgb32.psd
Personally, I would prefer a tar or zip of png files...
It seems as though the colorspace conversion is a part of the problem. If I use a rgb24 source (FFV1 file) instead of the rgb32 source, the colors are more accurate. I've broken the PSD file into several layers to show screenshots of the same gradient. If you look at all of the samples (rgb32 vs rgb24), the green in the upper left corner of the frame is much closer to the original in the rgb24 samples (perceptually, the colors are better everywhere in the rgb24 screenshots). A quick test with ffmpeg reveals that the same problem (inaccurate colors with rgb32 source) exists in ffmpeg. Is this a bug? If not, how can it be explained/fixed?
As far as I know, mplayer and ffmpeg are using the same libswscale code for the conversion. Either way, libswscale is part of the ffmpeg project, so you'll need to ask on the ffmpeg-user mailing list. I don't think I can help you further on this subject.
Now, the secondary issues is the complexity of the banding. In all of the rgb32 screenshots, the banding is more complex (retains more detail??) than the rgb24 screenshots. Can I improve the complexity of the banding with the rgb24 source? Is this another symptom of the colorspace conversion???
I would expect dithering to help with that, but I don't know of any way to dither with mencoder. If all else fails, you can dump the individual frames, process them externally with imagemagick or something, and then encode from the processed frames. -Corey
As far as I know, mplayer and ffmpeg are using the same libswscale code for the conversion. Either way, libswscale is part of the ffmpeg project, so you'll need to ask on the ffmpeg-user mailing list.
I don't think I can help you further on this subject.
I will take it to the ffmpeg list. There is definitely a colorspace conversion issue. It was brought up in a previous thread, although the solution discussed there did not help me. http://thread.gmane.org/gmane.comp.video.mencoder.user/6668 You can easily reproduce the color space conversion problem by taking any rgb24 png image sequence, and then encode it with mencoder. Compare the resulting image with the original and you'll see colors change far more than they should. It is very apparent if you use a video source with large flat color areas, or just a matte color. (I can provide samples if anyone wants them) I converted the same rgb24 pngs to yuy2 and back again to a bitmap using premiere to use as a reference - perceptually the colors were the same. Although, I know relatively little about color space conversion, could the matrices discussed on this avisynth page have something to do with the color shifting? http://avisynth.org/mediawiki/Convert
Nicolas Hesler wrote:
You can easily reproduce the color space conversion problem by taking any rgb24 png image sequence, and then encode it with mencoder. Compare the resulting image with the original and you'll see colors change far more than they should. It is very apparent if you use a video source with large flat color areas, or just a matte color. (I can provide samples if anyone wants them)
That's probably a good idea.
I converted the same rgb24 pngs to yuy2 and back again to a bitmap using premiere to use as a reference - perceptually the colors were the same.
Although, I know relatively little about color space conversion, could the matrices discussed on this avisynth page have something to do with the color shifting?
I don't know (in case you were hoping for an answer from me). -Corey
Corey Hickey wrote:
That's probably a good idea.
I uploaded a number of files to incoming/rgb_conversion/ original.png (the source image, this image is single image in a sequence of images generated with Adobe Flash) png_movie.mpg (the mencoder encoded mpeg2 - command line below) bmp_from_premiere.bmp (rgb->yuy2->rgb) shot_using_vlc.png (screenshot using vlc) shot_using_mplayer.png (screenshot using mplayer) if you compare the original.png with either of the screenshots, you will the change in color in the green. the bmp_from_premiere does not suffer from this problem. See below the mencoder output for more... mencoder -oac lavc -ovc lavc -of mpeg -mpegopt s format=mpeg2:muxrate=18080:tsaf -vf harddup -lavcopts vcodec=mpeg2video:vrc_bu f_size=3835:vrc_maxrate=18000:vbitrate=14000:trell:mbd=2:lmin=0.01:vpass=1:aspec t=16/9 -ofps 24 mf://*.png -mf fps=24 -o png_video.mpg MEncoder Sherpya-SVN-r26446-4.2.3 (C) 2000-2008 MPlayer Team CPU: Intel(R) Xeon(TM) CPU 3.73GHz (Family: 15, Model: 6, Stepping: 4) CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Compiled with runtime CPU detection. success: format: 16 data: 0x0 - 0x0 MF file format detected. [mf] search expr: *.png [mf] number of files: 60 (240) [demux_mf] file type was not set! trying 'type=png'... VIDEO: [MPNG] 0x0 24bpp 24.000 fps 0.0 kbps ( 0.0 kbyte/s) [V] filefmt:16 fourcc:0x474E504D size:0x0 fps:24.00 ftime:=0.0417 PACKET SIZE: 2048 bytes, deltascr: 24467 Opening video filter: [expand osd=1] Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1 Opening video filter: [harddup] ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffpng] vfm: ffmpeg (FFmpeg PNG decoder) ========================================================================== Limiting audio preload to 0.4s. Increasing audio density to 4. VDec: vo config request - 1280 x 720 (preferred colorspace: RGB 24-bit) Could not find matching colorspace - retrying with -vf scale... Opening video filter: [scale] VDec: using RGB 24-bit as output csp (no 5) Movie-Aspect is undefined - no prescaling applied. SwScaler: reducing / aligning filtersize 1 -> 4 SwScaler: reducing / aligning filtersize 1 -> 4 SwScaler: reducing / aligning filtersize 1 -> 1 SwScaler: reducing / aligning filtersize 9 -> 8 [swscaler @ 00D71CD4]BICUBIC scaler, from rgb24 to yuv420p using MMX2 [swscaler @ 00D71CD4]using 4-tap MMX scaler for horizontal luminance scaling [swscaler @ 00D71CD4]using 4-tap MMX scaler for horizontal chrominance scaling [swscaler @ 00D71CD4]using 1-tap MMX "scaler" for vertical scaling (YV12 like) [swscaler @ 00D71CD4]1280x720 -> 1280x720 videocodec: libavcodec (1280x720 fourcc=3267706d [mpg2]) [VE_LAVC] High quality encoding selected (non-realtime)! [mpeg2video @ 00D8A3B0][lavc rc] Using all of requested bitrate is not necessary for this video with these parameters. Writing header... INITV: 0.200, 0.158, fps: 24.000 Pos: 2.5s 60f (100%) 19.85fps Trem: 0min 0mb A-V:0.000 [214:0] Flushing video frames. Writing index... Overhead: 7.118% (4763 / 66917) Writing header... Video stream: 214.134 kbit/s (26766 B/s) size: 66917 bytes 2.500 secs 60 fr ames i dropped another file in the root of incoming, export_premiere_avisynth.mpg (for this file, I frameserved the original png out of premiere in yuy2, and encoded using mencoder, only this time, mencoder doesn't have to do the colorspace conversion, and the color looks as it should. ========================================================================== Opening video decoder: [raw] RAW Uncompressed Video VDec: vo config request - 1280 x 720 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is undefined - no prescaling applied. videocodec: libavcodec (1280x720 fourcc=3267706d [mpg2]) [VE_LAVC] High quality encoding selected (non-realtime)! [mpeg2video @ 00D8A3B0][lavc rc] Using all of requested bitrate is not necessary for this video with these parameters. Selected video codec: [rawyv12] vfm: raw (RAW YV12) Should I still take this to the ffmpeg list? or am I doing something wrong?
Nicolas Hesler wrote:
Should I still take this to the ffmpeg list? or am I doing something wrong?
I don't see anything wrong, except maybe that you should try -sws 8 as I mentioned in my first post of this thread. Other than that, try posting on ffmpeg-user, if you haven't already. I'm not subscribed there, but I don't think I can help you further on this anyway. -Corey
participants (3)
-
Corey Hickey -
Nicolas Hesler -
RC