Teddl
3rd March 2011, 00:32
Hi there,
almost 2 years after my Megui Experience with encoding speeds, I was curious what has happened to x264 video encoding and Megui.
Because I've never had a good experience with constant quality encodes (output file too big, too small and ugly using DivX & Xvid) and since everybody seems to love the popular constant ratefactor, I have taken some effort to test crf myself. So, this is not realy a Megui Experience 2.0.
One conclusion first: My English hasn't improved, I'm afraid. So I beg you pardon.
And secondly: The second diagram helped understand crf better. So I might encode any file with preset faster and then I know which crf gives me the right bitrate.. wasn't there a compressibility test somewhere? Can't I just do a 1st pass encode of a 2 pass encode with the bitrate and settings I want and then just take the final rate factor? However..
Again, Megui is what I used to take care of the jobs. Of Course!
At the point of my test the latest version was 1911 and the x264.exe v.1867 from the stable update server. X264 64-bit mode enabled (1 of my wishes came true.. the other one was more presets. Now there is 1 more.*smile).
For testing I found this Trailer about this lion, these kids and this epic wave at the beginning. It contains everything I wanted to test x264 with (camera movements, complex/simple scenes, faces, smoke, noise/grain)
2:15 min, 2593 frames, .mov 1280x544p 1:1 @ 2000000/104271 fps ~92MiB
Avisynth-script:
DirectShowSource("J:\Int\This.Lion.and.these.kids.mov", fps=23.976, audio=false, convertfps=true)
LoadPlugin("J:\Int\MeGUI_1911_x86_WithoutInstaller\tools\avisynth_plugin\TIVTC.dll")
Tdecimate(cycleR=1)
Maybe not the best choice of format and lenght for a source video. Well, I decided to download and use the shortfilm about this girl and that Dragon from the Durian Project (http://media.xiph.org/sintel/) uncompressed in 1920x818 for some good image comparison, in the future. But I have just finished the trailer testing.
The following is what I've seen from comparing the preset placebo encodes:
1.What realy buged me was the fact that from crf 64 to crf 46 there was no difference regarding bitrate nor PSNR results. My Eyes confirmed this. Only with superfast and ultrafast it kicked in at crf 50 using the .mov source. A negative quality placebo? If so.. whoever came up with it is a genius!! I mean, with those placebo presets it took at least 12 min/job, seriously!!! Or what am I missing?
2.The lower the crf, the more details are saved, blocking is reduced and blurriness is applied weaker and weaker.
Faces are „OK“ with crf 33 (~500kbits). But those strange encoding artefacts like a nervouse background is gone at crf 25 (~1400kbits). How is that corelated? I would do anything to get rid of anoying encoding artefacts first and then add details. Most issues with the default deblocking strengh of 0:0 is resolved with crf 27. ~1100kbits archived that in my test.
Even lower crf gets rid of specific problems. More saved details – little noise looks acceptable at crf 22. That would be ~2200kbits.
If you forget you know the source, crf 21 looks realy good (~2500kbits). Crf 20 (~3000kbits) and below didn't make much of a different in my 1280x544 lion and kids encodes besides even better quality in areas you would only look when you want to check the quality and I saw noticable better screenshots.
In terms of subjective, subconscience quality, crf 19 is very pleasant. That would be an SSIM of ~0,9851 and in this incidence it means ~24mb/min (~3400kbits)
For crf 18 (~3900kbits) and below the image gets realy crispy, detailed. Crf 17 (~4400kbits) gets more intense grain better done and crf 16 (~4900kbits) gives grainy parts an excellent look.
The term „homogeneous“ comes to mind, watching with crf 15 encoded (~5500kbits). Every part of the image seems to be of good quality.
3.Lastly, everything below crf 15 exceeds the size of the trailer. But for me, crf 14 looks better than the original. And this means from my personal taste, 1:1 copy was almost same quality looking at the bitrate.
For what it's good: Here a comparison from crf 64 – crf 15 with the original at the end of this lossless x264 video: http://www.mediafire.com/?z9bq7xcsc81qymj
(may not play in vlc player)
And.. I've made this SSIM db *diagram. Again, this was with x264.exe v.1867. Have there been big changes hence 1913 exists?
http://i652.photobucket.com/albums/uu244/Teddl1/SSIMdb.png
Looks very progressive to me..
And here are the extended filesizes*: (at that point I didn't know I can go down to zero). Here I know things have already changed, because I encoded the last preset placebo crf 3,2 and 1 with x264.exe v1913 and the size was smaller than expected.
http://i652.photobucket.com/albums/uu244/Teddl1/MB_crf.png
Looks parabolically to me..
This looks better*:
http://i652.photobucket.com/albums/uu244/Teddl1/MB_crf33-15.png
*Errors are kept to keep it genuine.
The five questions left are:
What about crf 64-46?
How is retaining details and stranger artefacts like stuttering background when camera moves related in high crf/low bitrate? Motion estimation is set by the pressed, but it requires a certain bitrate to work with I presume.
Answers? Comments? Critique?
So far,
Teddl
Correction: The source was 92,9MB only the video, 5763kbits. Everything below crf 15 exceeds the size of the trailer. And this means from my personal taste, 1:1 copy was almost same quality looking at the bitrate.
almost 2 years after my Megui Experience with encoding speeds, I was curious what has happened to x264 video encoding and Megui.
Because I've never had a good experience with constant quality encodes (output file too big, too small and ugly using DivX & Xvid) and since everybody seems to love the popular constant ratefactor, I have taken some effort to test crf myself. So, this is not realy a Megui Experience 2.0.
One conclusion first: My English hasn't improved, I'm afraid. So I beg you pardon.
And secondly: The second diagram helped understand crf better. So I might encode any file with preset faster and then I know which crf gives me the right bitrate.. wasn't there a compressibility test somewhere? Can't I just do a 1st pass encode of a 2 pass encode with the bitrate and settings I want and then just take the final rate factor? However..
Again, Megui is what I used to take care of the jobs. Of Course!
At the point of my test the latest version was 1911 and the x264.exe v.1867 from the stable update server. X264 64-bit mode enabled (1 of my wishes came true.. the other one was more presets. Now there is 1 more.*smile).
For testing I found this Trailer about this lion, these kids and this epic wave at the beginning. It contains everything I wanted to test x264 with (camera movements, complex/simple scenes, faces, smoke, noise/grain)
2:15 min, 2593 frames, .mov 1280x544p 1:1 @ 2000000/104271 fps ~92MiB
Avisynth-script:
DirectShowSource("J:\Int\This.Lion.and.these.kids.mov", fps=23.976, audio=false, convertfps=true)
LoadPlugin("J:\Int\MeGUI_1911_x86_WithoutInstaller\tools\avisynth_plugin\TIVTC.dll")
Tdecimate(cycleR=1)
Maybe not the best choice of format and lenght for a source video. Well, I decided to download and use the shortfilm about this girl and that Dragon from the Durian Project (http://media.xiph.org/sintel/) uncompressed in 1920x818 for some good image comparison, in the future. But I have just finished the trailer testing.
The following is what I've seen from comparing the preset placebo encodes:
1.What realy buged me was the fact that from crf 64 to crf 46 there was no difference regarding bitrate nor PSNR results. My Eyes confirmed this. Only with superfast and ultrafast it kicked in at crf 50 using the .mov source. A negative quality placebo? If so.. whoever came up with it is a genius!! I mean, with those placebo presets it took at least 12 min/job, seriously!!! Or what am I missing?
2.The lower the crf, the more details are saved, blocking is reduced and blurriness is applied weaker and weaker.
Faces are „OK“ with crf 33 (~500kbits). But those strange encoding artefacts like a nervouse background is gone at crf 25 (~1400kbits). How is that corelated? I would do anything to get rid of anoying encoding artefacts first and then add details. Most issues with the default deblocking strengh of 0:0 is resolved with crf 27. ~1100kbits archived that in my test.
Even lower crf gets rid of specific problems. More saved details – little noise looks acceptable at crf 22. That would be ~2200kbits.
If you forget you know the source, crf 21 looks realy good (~2500kbits). Crf 20 (~3000kbits) and below didn't make much of a different in my 1280x544 lion and kids encodes besides even better quality in areas you would only look when you want to check the quality and I saw noticable better screenshots.
In terms of subjective, subconscience quality, crf 19 is very pleasant. That would be an SSIM of ~0,9851 and in this incidence it means ~24mb/min (~3400kbits)
For crf 18 (~3900kbits) and below the image gets realy crispy, detailed. Crf 17 (~4400kbits) gets more intense grain better done and crf 16 (~4900kbits) gives grainy parts an excellent look.
The term „homogeneous“ comes to mind, watching with crf 15 encoded (~5500kbits). Every part of the image seems to be of good quality.
3.Lastly, everything below crf 15 exceeds the size of the trailer. But for me, crf 14 looks better than the original. And this means from my personal taste, 1:1 copy was almost same quality looking at the bitrate.
For what it's good: Here a comparison from crf 64 – crf 15 with the original at the end of this lossless x264 video: http://www.mediafire.com/?z9bq7xcsc81qymj
(may not play in vlc player)
And.. I've made this SSIM db *diagram. Again, this was with x264.exe v.1867. Have there been big changes hence 1913 exists?
http://i652.photobucket.com/albums/uu244/Teddl1/SSIMdb.png
Looks very progressive to me..
And here are the extended filesizes*: (at that point I didn't know I can go down to zero). Here I know things have already changed, because I encoded the last preset placebo crf 3,2 and 1 with x264.exe v1913 and the size was smaller than expected.
http://i652.photobucket.com/albums/uu244/Teddl1/MB_crf.png
Looks parabolically to me..
This looks better*:
http://i652.photobucket.com/albums/uu244/Teddl1/MB_crf33-15.png
*Errors are kept to keep it genuine.
The five questions left are:
What about crf 64-46?
How is retaining details and stranger artefacts like stuttering background when camera moves related in high crf/low bitrate? Motion estimation is set by the pressed, but it requires a certain bitrate to work with I presume.
Answers? Comments? Critique?
So far,
Teddl
Correction: The source was 92,9MB only the video, 5763kbits. Everything below crf 15 exceeds the size of the trailer. And this means from my personal taste, 1:1 copy was almost same quality looking at the bitrate.