new doom9 codec comparission
Hi doom9 is planning to do a new codec comparission, and they are asking me to provide them with 2pass settings (lavc mpeg4 & lavc snow) for the "qualification round" against xvid 1.03 with the matrix as movie they need a single set of options not a mix of possible good ones from which they would have to select, thats also why they refuse to ask here, they are also askng which binary of mencoder they should use iam not forwarding their mail as it was in german ... so we need a volunteer who has some experience with encoding, can provide them with all that and furthermore could double check that nothing silly goes wrong like using a player with postprocessing disabled for viewing the mencoder encoded video while one with pp enabled is used in the other cases if you want to volunteer just reply to the list ... if you dont do that, then shut up and dont complain about what doom9 will say about libav*/mencoder in the unlikely case that we end up with multiple volunteers who cant agree then ill decide who is the official one they should listen to i belive this should solve the issue doom9 had with asking here PS: also dont forget to ask if the test is just quality wise or speed wise too -- Michael
Hi 1 week has passed and noone volunteers, so ffmpeg/mencoder wont be included in the next doom9 comparission i guess On Thu, Nov 24, 2005 at 03:37:05AM +0100, Michael Niedermayer wrote:
Hi
doom9 is planning to do a new codec comparission, and they are asking me to provide them with 2pass settings (lavc mpeg4 & lavc snow) for the "qualification round" against xvid 1.03 with the matrix as movie they need a single set of options not a mix of possible good ones from which they would have to select, thats also why they refuse to ask here, they are also askng which binary of mencoder they should use iam not forwarding their mail as it was in german ...
so we need a volunteer who has some experience with encoding, can provide them with all that and furthermore could double check that nothing silly goes wrong like using a player with postprocessing disabled for viewing the mencoder encoded video while one with pp enabled is used in the other cases
if you want to volunteer just reply to the list ... if you dont do that, then shut up and dont complain about what doom9 will say about libav*/mencoder
in the unlikely case that we end up with multiple volunteers who cant agree then ill decide who is the official one they should listen to i belive this should solve the issue doom9 had with asking here
PS: also dont forget to ask if the test is just quality wise or speed wise too
the test will be done on a dual core CPU, goal is best possible quality at reasonable speed, last time the worst result was 17.5 fps [...] -- Michael
On Thursday, 01 December 2005 at 12:11, Michael Niedermayer wrote:
Hi
1 week has passed and noone volunteers, so ffmpeg/mencoder wont be included in the next doom9 comparission i guess
Doh! I don't know as much as some people here, but I'll try to do my best. It'd be shame if ffmpeg were omitted. And shame on the rest of you guys. Regards, R. -- MPlayer RPMs maintainer: http://rpm.greysector.net/mplayer/ "I am Grey. I stand between the candle and the star. We are Grey. We stand between the darkness ... and the light." -- Delenn in Grey Council in Babylon 5:"Babylon Squared"
Hi On Thu, Dec 01, 2005 at 12:27:38PM +0100, Dominik 'Rathann' Mierzejewski wrote:
On Thursday, 01 December 2005 at 12:11, Michael Niedermayer wrote:
Hi
1 week has passed and noone volunteers, so ffmpeg/mencoder wont be included in the next doom9 comparission i guess
Doh! I don't know as much as some people here, but I'll try to do my best. It'd be shame if ffmpeg were omitted. And shame on the rest of you guys.
hmm are you the only volunteer? Corey Hickey do you volunteer too? if no then dominik has the job, unless of course there are objections or other volunteers if no then the final decission about what parameters will be used is yours, just a few suggestions, feel free to ignore them * give credit to whoever suggested some parameter(s) * keep disscussions about the parameters on a public mailinglist * buy a asbestos suit [...] -- Michael
Michael Niedermayer wrote:
1 week has passed and noone volunteers, so ffmpeg/mencoder wont be included in the next doom9 comparission i guess
Doh! I don't know as much as some people here, but I'll try to do my best. It'd be shame if ffmpeg were omitted. And shame on the rest of you guys.
hmm are you the only volunteer? Corey Hickey do you volunteer too? if no then dominik has the job, unless of course there are objections or other volunteers
Yeah, I've been working on it since yesterday. If somebody else wants to be the official person, I don't mind; tomorrow (probably) I'm going to submit to mencoder-users the best encoding and decoding parameters I can come up with and we can move forward from there. I think this ought to be a group effort to the extent that anyone who can contribute should contribute as much as he or she can. Doom9 wants results by "the week-end after next at the very very very latest", so we don't have a lot of time. I'm going to keep doing what I'm doing, and I'll make a list of what results I have later today.
if no then the final decission about what parameters will be used is yours, just a few suggestions, feel free to ignore them * give credit to whoever suggested some parameter(s) * keep disscussions about the parameters on a public mailinglist * buy a asbestos suit
Reasonable. -Corey
Hi On Fri, Dec 02, 2005 at 02:21:03PM -0800, Corey Hickey wrote:
Michael Niedermayer wrote:
1 week has passed and noone volunteers, so ffmpeg/mencoder wont be included in the next doom9 comparission i guess
Doh! I don't know as much as some people here, but I'll try to do my best. It'd be shame if ffmpeg were omitted. And shame on the rest of you guys.
hmm are you the only volunteer? Corey Hickey do you volunteer too? if no then dominik has the job, unless of course there are objections or other volunteers
Yeah, I've been working on it since yesterday. If somebody else wants to
good, if you volunteer then you are the official person unless there are objections from anyone ... [...] -- Michael
Hi, On 11/24/05, Michael Niedermayer <michaelni@gmx.at> wrote:
doom9 is planning to do a new codec comparission, and they are asking me to provide them with 2pass settings (lavc mpeg4 & lavc snow) for the "qualification round" against xvid 1.03 with the matrix as movie they need a single set of options not a mix of possible good ones from which they would have to select, thats also why they refuse to ask here, they are also askng which binary of mencoder they should use iam not forwarding their mail as it was in german ...
so we need a volunteer who has some experience with encoding, can provide them with all that and furthermore could double check that nothing silly goes wrong like using a player with postprocessing disabled for viewing the mencoder encoded video while one with pp enabled is used in the other cases
if you want to volunteer just reply to the list ... if you dont do that, then shut up and dont complain about what doom9 will say about libav*/mencoder
PS: also dont forget to ask if the test is just quality wise or speed wise too
I don't use libavcodec much those days, that's why I did not propose an encoding option line. All I can offer is the encoding line that I've used before switching to x264: pass1: vcodec=mpeg4:mbd=2:trell:v4mv:last_pred=2:dia=-1:vmax_b_frames=2:vb_strategy=1:cmp=3:subcmp=3:precmp=0:vqcomp=0.6:turbo:vpass=1:vbitrate=xx pass2: vcodec=mpeg4:mbd=2:trell:v4mv:last_pred=2:dia=-1:vmax_b_frames=2:cmp=3:subcmp=3:precmp=0:vqcomp=0.6:vpass=2:vbitrate=xx I worked reasonably well for live action content. As far as Snow is concerned, I really have not used it much to feel like I should give any advice Here is the encoding option line that you seemed to agree yield the best quality with Snow: pass1: vqscale=2:vcodec=snow:cmp=1:subcmp=1:vqcomp=0.6:mbcmp=1:pred=0:psnr:vstrict=-2:vpass=1 pass2: vbitrate=xx:vcodec=snow:cmp=1:subcmp=1:vqcomp=0.6:mbcmp=1:pred=0:psnr:vstrict=-2:vpass=2 I have not tested them though, so I guess I or someone should do that before the deadline (I just can't do it tonight). Also, I believe that the SIMD routines I'm working on may speed-up the encoding process. If Doom9 is wants us to provide binaries, it may be a good idea to apply that patchset too. However, the problem is that apparently when mencoder is built on on win32 platform all sse code is disabled (rich says it's because mingw malloc functions can't be trusted to give well aligned memory). Guillaume -- Remember, if you ever need a helping hand, it's at the end of your arm, as you get older, remember you have another hand: The first is to help yourself, the second is to help others. -- Audrey Hepburn
On Thu, Dec 01, 2005 at 02:11:59PM +0100, Guillaume POIRIER wrote:
Also, I believe that the SIMD routines I'm working on may speed-up the encoding process. If Doom9 is wants us to provide binaries, it may be a good idea to apply that patchset too. However, the problem is that apparently when mencoder is built on on win32 platform all sse code is disabled (rich says it's because mingw malloc functions can't be trusted to give well aligned memory).
This is only for mingw crap. Just use cygwin and it will work fine with sse. Rich
Hi, On 12/1/05, Rich Felker <dalias@aerifal.cx> wrote:
On Thu, Dec 01, 2005 at 02:11:59PM +0100, Guillaume POIRIER wrote:
Also, I believe that the SIMD routines I'm working on may speed-up the encoding process. If Doom9 is wants us to provide binaries, it may be a good idea to apply that patchset too. However, the problem is that apparently when mencoder is built on on win32 platform all sse code is disabled (rich says it's because mingw malloc functions can't be trusted to give well aligned memory).
This is only for mingw crap. Just use cygwin and it will work fine with sse.
I don't know what build Doom9 plans to use, but I do believe this is the kind of important thing to tell him: which build should he use? Can we provide such a build to him? Can mplayer-cygwin build run without the whole unix emulation environment? Guillaume -- MPlayer's doc is offline. Find some fresh one here: http://tuxrip.free.fr//MPlayer-DOCS-HTML/en/ http://tuxrip.free.fr//MPlayer-DOCS-HTML/fr/
Well, I finally went and rented The Matrix and started messing around. For now I'm concentrating only on mpeg4 -- I'll deal with the exciting part (snow) later. Also, if someone else can provide a nice windows binary, I'd appreciate it; I have little experience in that regard and probably couldn't do as well as many others on this list. I have several questions and things to comment on. ------------------------------------------------------------------------ First, the questions for Doom9. 1. The test is using the original Matrix, right? Not one of the sequels? 2. Encoding the audio using Lame 3.96.1 gives me 127632KB which is rather different from the 157455KB listed in the 2003 codec comparison. This is probably due to my Lame being newer and/or the way liba52 downmixed the 5.1 audio when I extracted it from the DVD. When you perform the test, are you going to use our Lame encoding method or your own? If you are going to use our methods for the whole process, then I'll shoot for a final filesize of 716800KB and provide the commands for each step. If you are going to use your own tools, then can you give me a target video bitrate to shoot for? You can then mux the mencoder-created video with your own audio and the filesize should end up being correct. 3. Are the cropping and scaling parameters going to be the same as in the 2003 codec comparison? 4. The 2003 comparison used a bicubic scaler; the 2004 comparison used lanczos. What method are you going to use this time? 5. How soon do you want to get results from us? ------------------------------------------------------------------------ Next, questions for mplayer people. 1. I don't know much about postprocessing. On the encoding I'm doing right now, pp=ac looks a little less blocky than pp=fa. Does anyone have a good recommendation? 2. As I mentioned before, can someone please provide a Windows binary? 3. I seem to recall that multithreaded encoding incurs a slight penalty to quality (or, at least, psnr). Do any particular lavcopts make multithreaded encoding better or worse? If not, I'm just going to find the best options I can with only one thread and, as a final step, test threads=2 to make sure nothing blows up. ------------------------------------------------------------------------ Last, some comments. Right now I'm testing the following command: for i in 1 2 ; do time mencoder ~/dumpstream/matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -ovc lavc -lavcopts \ vcodec=mpeg4:vbitrate=581:vratetol=1000:psnr:vpass=$i:mbd=2:mv0:trell:\ cbp:precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:vme=5:v4mv \ -ofps 24000/1001 done I encoded the audio separately with Lame. I'll mux it back in later -- right now I want to isolate video encoding performance. The cropping and scaling parameters are from the 2003 codec comparison. Bitrate is from 2003 as well; I might have to refine it slightly based on the response I get from Doom9. With the above command, I'm getting about 36 fps on an Athlon64 3400+ overclocked to 2544 MHz. That seems like a reasonable framerate and is about mid-range among the framerates listed in the 2004 codec comparison on an Athlon64 3500+ (the movie in that test was The Matrix Revolutions, but it should be similar). I will investigate qns=2; if it looks much better I might recommend it, depending on the fps hit. I may recommend turbo for the first pass, if it doesn't look worse. -Corey
Hi, On 12/2/05, Corey Hickey <bugfood-ml@fatooh.org> wrote:
Well, I finally went and rented The Matrix and started messing around. For now I'm concentrating only on mpeg4 -- I'll deal with the exciting part (snow) later.
Once again, I'd like to ask for anyone who has some SSE/MMX knowledge to help me fix SIMD-accelerated Snow decoding on AMD64. I should give a small encoding speed boost too. [..]
I will investigate qns=2; if it looks much better I might recommend it, depending on the fps hit.
My experience with qns is that it mostly helped when the bitrate was low enough that the video would look blocky.
I may recommend turbo for the first pass, if it doesn't look worse.
I've been talking with Nico Sabi about changing how "turbo" works to a way similar to what we do for x264: turbo=1: speed-up encode with negligible PSNR difference (this should be more or less the original version of turbo I committed) turbo=2: speed-up some more while impacting PSNR a bit. (that would be current version of turbo) That way we could safely recommend using turbo. Guillaume -- MPlayer's doc is offline. Find some fresh one here: http://tuxrip.free.fr//MPlayer-DOCS-HTML/en/ http://tuxrip.free.fr//MPlayer-DOCS-HTML/fr/
Hi On Thu, Dec 01, 2005 at 04:40:18PM -0800, Corey Hickey wrote:
Well, I finally went and rented The Matrix and started messing around. For now I'm concentrating only on mpeg4 -- I'll deal with the exciting part (snow) later. Also, if someone else can provide a nice windows binary, I'd appreciate it; I have little experience in that regard and probably couldn't do as well as many others on this list.
I have several questions and things to comment on. [...] ------------------------------------------------------------------------ Next, questions for mplayer people.
1. I don't know much about postprocessing. On the encoding I'm doing right now, pp=ac looks a little less blocky than pp=fa. Does anyone have a good recommendation?
i would recommand against pp=fa its just based on filters invented by me which are supposed to be fast and not perfect, if you want more speed try without the dering filter (pp=ha:128:7,va) but whatever you choose test it first, dont blindly trust my suggestion ... also definitly try to add some noise, it might look better, something on windows, does add noise by default, i never could figure out what part it was (the noise was vissible with ffdshow even though it had all noise adding filters disabled ..., but that was long ago) if possible also test with TFT & CRT monitors (btw, doom9 which do you use, ive seen quite some differences in artifact vissibility between CRT and TFT) also try the newer spp based postprocessing filters if the CPU is fast enough also see http://guru.multimedia.cx/?p=8 for some pp compaission, maybe ill add more variants ... [...]
3. I seem to recall that multithreaded encoding incurs a slight penalty to quality (or, at least, psnr). Do any particular lavcopts make multithreaded encoding better or worse? If not, I'm just going to find the best options I can with only one thread and, as a final step, test threads=2 to make sure nothing blows up.
hmm, a larger last_pred and preme=2 might help a little for the multithreading stuff, someone could also try to do just the motion estimation or just the bitstream encoding multithreaded (needs code change, maybe ill take a look but dont hold your breath ...) and maybe try multithreded decoding too
------------------------------------------------------------------------ Last, some comments.
Right now I'm testing the following command: for i in 1 2 ; do time mencoder ~/dumpstream/matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -ovc lavc -lavcopts \ vcodec=mpeg4:vbitrate=581:vratetol=1000:psnr:vpass=$i:mbd=2:mv0:trell:\ cbp:precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:vme=5:v4mv \ -ofps 24000/1001 done
dont forget to remove psnr in the final suggestion, it eats some precious cpu time, also try NSSE maybe [...] -- Michael
Michael Niedermayer wrote:
1. I don't know much about postprocessing. On the encoding I'm doing right now, pp=ac looks a little less blocky than pp=fa. Does anyone have a good recommendation?
i would recommand against pp=fa its just based on filters invented by me which are supposed to be fast and not perfect, if you want more speed try without the dering filter (pp=ha:128:7,va) but whatever you choose test it first, dont blindly trust my suggestion ...
I forgot to mention: I can't see any difference between pp=de and pp=ac. Decoding speed of pp=de and pp=ac is ok -- if Doom9 is doing to test on an Athlon64 the postprocessing overhead of each of those will be negligable.
also definitly try to add some noise, it might look better, something on windows, does add noise by default, i never could figure out what part it was (the noise was vissible with ffdshow even though it had all noise adding filters disabled ..., but that was long ago)
Thanks for mentioning that -- I forgot about noise.
if possible also test with TFT & CRT monitors (btw, doom9 which do you use, ive seen quite some differences in artifact vissibility between CRT and TFT)
I know what you mean. Blocking artifacts really stand out when I play video on my laptop. The postprocessing should alleviate that problem.
also try the newer spp based postprocessing filters if the CPU is fast enough
I'm starting to really like spp=2,noise=3ah - spp seems to deblock without smearing as much of the original detail - adding noise masks the smeared parts and makes places where the film grain managed to get encoded stand out a bit less.
also see http://guru.multimedia.cx/?p=8 for some pp compaission, maybe ill add more variants ...
[...]
3. I seem to recall that multithreaded encoding incurs a slight penalty to quality (or, at least, psnr). Do any particular lavcopts make multithreaded encoding better or worse? If not, I'm just going to find the best options I can with only one thread and, as a final step, test threads=2 to make sure nothing blows up.
hmm, a larger last_pred and preme=2 might help a little for the multithreading stuff, someone could also try to do just the motion estimation or just the bitstream encoding multithreaded (needs code change, maybe ill take a look but dont hold your breath ...)
and maybe try multithreded decoding too
Are you referring to something I should try or something you should write? :) I don't see anything in the man page about multithreaded decoding.
------------------------------------------------------------------------ Last, some comments.
Right now I'm testing the following command: for i in 1 2 ; do time mencoder ~/dumpstream/matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -ovc lavc -lavcopts \ vcodec=mpeg4:vbitrate=581:vratetol=1000:psnr:vpass=$i:mbd=2:mv0:trell:\ cbp:precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:vme=5:v4mv \ -ofps 24000/1001 done
dont forget to remove psnr in the final suggestion, it eats some precious cpu time, also try NSSE maybe
Got it. -Corey
Hi On Fri, Dec 02, 2005 at 01:24:34PM -0800, Corey Hickey wrote:
Michael Niedermayer wrote: [...]
also try the newer spp based postprocessing filters if the CPU is fast enough
I'm starting to really like spp=2,noise=3ah - spp seems to deblock without smearing as much of the original detail - adding noise masks the smeared parts and makes places where the film grain managed to get encoded stand out a bit less.
also try fspp
also see http://guru.multimedia.cx/?p=8 for some pp compaission, maybe ill add more variants ...
[...]
3. I seem to recall that multithreaded encoding incurs a slight penalty to quality (or, at least, psnr). Do any particular lavcopts make multithreaded encoding better or worse? If not, I'm just going to find the best options I can with only one thread and, as a final step, test threads=2 to make sure nothing blows up.
hmm, a larger last_pred and preme=2 might help a little for the multithreading stuff, someone could also try to do just the motion estimation or just the bitstream encoding multithreaded (needs code change, maybe ill take a look but dont hold your breath ...)
and maybe try multithreded decoding too
Are you referring to something I should try or something you should write? :) I don't see anything in the man page about multithreaded decoding.
hmm cvs up and RTFS ;) no seriously, i think just forget about it, its not worth it, but if you have spare time then try it, but IIRC it only works with mpeg2, the mpeg4 case isnt implemented and it would only work if the files was encoded with slices thats always the case for mpeg2 but generally not for mpeg4 [...] -- Michael
Michael Niedermayer wrote:
also try the newer spp based postprocessing filters if the CPU is fast enough
I'm starting to really like spp=2,noise=3ah - spp seems to deblock without smearing as much of the original detail - adding noise masks the smeared parts and makes places where the film grain managed to get encoded stand out a bit less.
also try fspp
I have now. Why does fspp's "quality" parameter only have a range of 4-5 while spp's range is 0-8? If I could specify fspp=2, that might be the right choice. spp=2 debocks just about the right amount. As far as speed goes, spp=2 seems to be faster than fspp=4. $ time mplayer 2.avi -vf <x> -frames 2400 -nosound -vo null -benchmark User times for <x> filters: (none) 0m1.463s spp=2 0m14.498s spp=3 0m29.919s fspp=4 0m20.526s -Corey
Am Freitag, 2. Dezember 2005 22:24 schrieb Corey Hickey:
Michael Niedermayer wrote:
1. I don't know much about postprocessing. On the encoding I'm doing right now, pp=ac looks a little less blocky than pp=fa. Does anyone have a good recommendation?
i would recommand against pp=fa its just based on filters invented by me which are supposed to be fast and not perfect, if you want more speed try without the dering filter (pp=ha:128:7,va) but whatever you choose test it first, dont blindly trust my suggestion ...
I forgot to mention: I can't see any difference between pp=de and pp=ac.
Hm, maybe you could try to increase the compression ratio - then the differences should be more visible. I think pp=ac is better than pp=de but it is also stronger. The postprocessing I like most is pp=ac whith slightly reduced strength.
also definitly try to add some noise, it might look better, something on windows, does add noise by default, i never could figure out what part it was (the noise was vissible with ffdshow even though it had all noise adding filters disabled ..., but that was long ago)
Thanks for mentioning that -- I forgot about noise.
Do not add too much noise, doom9 is going to analyse single frames. It would be bad if they would write: mencoder/mplayer is to noisy :-) Regards, Matthias
I've run across a bit of a hitch -- when I went to compare screenshots from the file I just encoded to the ones posted on doom9.org, I found out that the ones I had were considerably darker. I can only conjecture as to why they are different and which one is correct; the only thing I am pretty sure about is that mplayer/mencoder decodes the DVD that way -- it doesn't get altered during the encoding process. Compare this image of the DVD taken by -vo jpeg: http://fatooh.org/files/doom9tmp/dark.jpg To the corresponding frame (or at least very close) on doom9: http://www.doom9.org/images/codecs2/matrix-orig-142142.jpg I've posted a 1MB clip from the DVD here: http://fatooh.org/files/doom9tmp/matrix-clip.vob Can anyone shed some light on this? :) -Corey
2005/12/2, Corey Hickey <bugfood-ml@fatooh.org>:
I've run across a bit of a hitch -- when I went to compare screenshots from the file I just encoded to the ones posted on doom9.org, I found out that the ones I had were considerably darker.
I can only conjecture as to why they are different and which one is correct; the only thing I am pretty sure about is that mplayer/mencoder decodes the DVD that way -- it doesn't get altered during the encoding process. Compare this image of the DVD taken by -vo jpeg:
Hi, I personally had some "funky" results, the last time, I tried using avisynth (which is used in the 2003 test, I believe). Maybe the decoding or some processing done by avisynth is producing this difference? And he use Media-Player-Classic (a DirectShow player) for taking the shots. This means, there might be some post-processing involved, that also tweaks brightness. But I might also be completely wrong... Simply give them the best you can! :) best wishes, hco
On Thu, 01 Dec 2005 21:05:45 -0800 Corey Hickey <bugfood-ml@fatooh.org> wrote:
I can only conjecture as to why they are different and which one is correct; the only thing I am pretty sure about is that mplayer/mencoder decodes the DVD that way -- it doesn't get altered during the encoding process.
The doom9 shot has clearly been cropped, sized and aspected so why not gammaed too? I'd guess it's a screenshot so it's been postprocessed by whatever is playing it. Interestingly, when I play your clip in mplayer (vo x11 without postpro) it does not appear quite as dark as your frame does. It could be an optical illusion due to the movement though. Martin
Hi On Fri, Dec 02, 2005 at 08:44:34AM +0000, Martin Collins wrote:
On Thu, 01 Dec 2005 21:05:45 -0800 Corey Hickey <bugfood-ml@fatooh.org> wrote:
I can only conjecture as to why they are different and which one is correct; the only thing I am pretty sure about is that mplayer/mencoder decodes the DVD that way -- it doesn't get altered during the encoding process.
The doom9 shot has clearly been cropped, sized and aspected so why not gammaed too? I'd guess it's a screenshot so it's been postprocessed by whatever is playing it.
Interestingly, when I play your clip in mplayer (vo x11 without postpro) it does not appear quite as dark as your frame does. It could be an optical illusion due to the movement though.
an additonal source of brightness change is that jpeg and mpeg use different ranges for the luma component, and IIRC mplayer&mencoder ignore this, probably most other tools too, i think ffmpeg doesnt. also keep in mind that xv & x11 tend to look different on many grafic cards [...] -- Michael
Michael Niedermayer wrote:
I can only conjecture as to why they are different and which one is correct; the only thing I am pretty sure about is that mplayer/mencoder decodes the DVD that way -- it doesn't get altered during the encoding process.
The doom9 shot has clearly been cropped, sized and aspected so why not gammaed too? I'd guess it's a screenshot so it's been postprocessed by whatever is playing it.
Interestingly, when I play your clip in mplayer (vo x11 without postpro) it does not appear quite as dark as your frame does. It could be an optical illusion due to the movement though.
an additonal source of brightness change is that jpeg and mpeg use different ranges for the luma component, and IIRC mplayer&mencoder ignore this, probably most other tools too, i think ffmpeg doesnt. also keep in mind that xv & x11 tend to look different on many grafic cards
For me, xv, x11, png, and jpeg all looked the same. Doom9 told me that it was probably due to the windows programs displaying the video more brightly, and, as long as the encoded video has the same brightness as the original, I shouldn't worry about it. -Corey
On Fri, Dec 02, 2005 at 09:56:25AM -0800, Corey Hickey wrote:
Michael Niedermayer wrote:
I can only conjecture as to why they are different and which one is correct; the only thing I am pretty sure about is that mplayer/mencoder decodes the DVD that way -- it doesn't get altered during the encoding process.
The doom9 shot has clearly been cropped, sized and aspected so why not gammaed too? I'd guess it's a screenshot so it's been postprocessed by whatever is playing it.
Interestingly, when I play your clip in mplayer (vo x11 without postpro) it does not appear quite as dark as your frame does. It could be an optical illusion due to the movement though.
an additonal source of brightness change is that jpeg and mpeg use different ranges for the luma component, and IIRC mplayer&mencoder ignore this, probably most other tools too, i think ffmpeg doesnt. also keep in mind that xv & x11 tend to look different on many grafic cards
For me, xv, x11, png, and jpeg all looked the same.
Doom9 told me that it was probably due to the windows programs displaying the video more brightly, and, as long as the encoded video has the same brightness as the original, I shouldn't worry about it.
It's due to -vo jpeg generating invalid jpeg (assuming jpeg yuv scale is same as mpeg yuv scale, which it's not). Rich
Rich Felker wrote:
For me, xv, x11, png, and jpeg all looked the same.
Doom9 told me that it was probably due to the windows programs displaying the video more brightly, and, as long as the encoded video has the same brightness as the original, I shouldn't worry about it.
It's due to -vo jpeg generating invalid jpeg (assuming jpeg yuv scale is same as mpeg yuv scale, which it's not).
Are you sure? You may be right, but I don't think it's having any effect here. -vo jpeg, png, xv, and x11 all look the same. Compare these two: http://fatooh.org/files/doom9tmp/dark.png http://fatooh.org/files/doom9tmp/dark.jpg Or, download the source. The files above are from frame 18 of this clip: http://fatooh.org/files/doom9tmp/matrix-clip.vob -Corey
This is a status update and an inventory of what must be done. ------------------------------------------------------------------------ 1. mencoder binaries for windows. Doom9's usual binaries are at: http://www.aziendeassociate.it/cd.asp?dir=/mplayer The latest on that page are from 2005-11-23, and there is an athlon64-specific build. Probably these are suitable. I can't test the athlon64 build, so if anybody with access to an athlon64 windows box can test it that would be helpful. ------------------------------------------------------------------------ 2. mpeg4 encoding commands for The Matrix. This will end up being something like: -- for i in $1 $2 ; do mencoder ~/dumpstream/matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -ovc lavc -lavcopts \ vcodec=mpeg4:threads=2:vbitrate=581:vratetol=1000:1:mbd=2:mv0:trell:\ cbp:precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:vme=5:v4mv:\ vpass=$i -ofps 24000/1001 done -- * qns=2, unfortunately, is prohibitively slow * I'm hoping to add turbo for pass 1 with little negative effect * I need to test vqcomp=0.7 or vqcomp=0.6 * I need to test last_pred=2 * I need to test NSSE (*cmp=10) ------------------------------------------------------------------------ 3. mpeg4 decoding commands for The Matrix. Currently I like: $ mplayer matrix.avi -vf spp=2,noise=3ah This isn't final, but pretty darn good-looking on both my CRT and my laptop screen. ------------------------------------------------------------------------ 4. snow encoding commands for The Matrix. I just started encoding a test clip using snow, and will refine the parameters as I go. I'm starting out with the suggested command in DOCS/tech/snow.txt, but changing vqscale to vbitrate for the second pass. I'm going to try vqcomp=0.7 and vqcomp=0.6. Does anybody have any more suggestions? ------------------------------------------------------------------------ 5. snow decoding commands for The Matrix. I'll figure this out after I start narrowing down snow. ------------------------------------------------------------------------ 6. Have I missed anything? ------------------------------------------------------------------------ 7. If lavc mpeg4 and/or snow passes the preliminary round, I'll have to look at The Matrix Revolutions and Saving Private Ryan. Probably I won't have to change anything but the scaling,cropping and vbitrate/vqscale parameters. -Corey
Am Samstag, 3. Dezember 2005 03:58 schrieb Corey Hickey:
----------------------------------------------------------------------- - 2. mpeg4 encoding commands for The Matrix. This will end up being something like: -- for i in $1 $2 ; do mencoder ~/dumpstream/matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -ovc lavc -lavcopts \ vcodec=mpeg4:threads=2:vbitrate=581:vratetol=1000:1:mbd=2:mv0:trell:\ cbp:precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:vme=5:v4mv:\ vpass=$i -ofps 24000/1001 done -- * qns=2, unfortunately, is prohibitively slow * I'm hoping to add turbo for pass 1 with little negative effect * I need to test vqcomp=0.7 or vqcomp=0.6 * I need to test last_pred=2 * I need to test NSSE (*cmp=10)
What about *_mask? Doom9 does not compare PSNRs, so *_mask might help a lot. (I use border_mask=0.15 for my realtime TV recordings and it works very well) Regards, Matthias
Hi, On 12/3/05, Matthias Wieser <mwieser@gmx.de> wrote:
Am Samstag, 3. Dezember 2005 03:58 schrieb Corey Hickey:
----------------------------------------------------------------------- - 2. mpeg4 encoding commands for The Matrix. This will end up being something like: -- for i in $1 $2 ; do mencoder ~/dumpstream/matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -ovc lavc -lavcopts \ vcodec=mpeg4:threads=2:vbitrate=581:vratetol=1000:1:mbd=2:mv0:trell:\ cbp:precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:vme=5:v4mv:\ vpass=$i -ofps 24000/1001 done -- * qns=2, unfortunately, is prohibitively slow * I'm hoping to add turbo for pass 1 with little negative effect * I need to test vqcomp=0.7 or vqcomp=0.6 * I need to test last_pred=2 * I need to test NSSE (*cmp=10)
What about *_mask?
Doom9 does not compare PSNRs, so *_mask might help a lot. (I use border_mask=0.15 for my realtime TV recordings and it works very well)
I'd not recommend it: this kind of option does not improve visual quality a heck of a lot, and when they do, it widely depends on the kind of monitor you use. For instance, the encodes I did when I had a CRT now look terrible on my TFT :-( Guillaume -- MPlayer's doc is offline. Find some fresh one here: http://tuxrip.free.fr//MPlayer-DOCS-HTML/en/ http://tuxrip.free.fr//MPlayer-DOCS-HTML/fr/
Am Samstag, 3. Dezember 2005 14:18 schrieb Guillaume POIRIER:
Hi,
On 12/3/05, Matthias Wieser <mwieser@gmx.de> wrote:
What about *_mask?
Doom9 does not compare PSNRs, so *_mask might help a lot. (I use border_mask=0.15 for my realtime TV recordings and it works very well)
I'd not recommend it: this kind of option does not improve visual quality a heck of a lot,
?? The only purpose of those options is to improve visual quality. Even a slight improvement is better than nothing.
and when they do, it widely depends on the kind of monitor you use.
For instance, the encodes I did when I had a CRT now look terrible on my TFT :-(
Probably because your TFT and your CRT have differing gamma values. Maybe you can adjust them to a gamma value of 2.2. If used carefully border_mask, scplx_mask, dark_mask and lumi_mask can improve visual quality. Keep in mind, that the other competitors use those 'psychosensory' settings even more (Nero, ms, divx6, realvideo,...). Regards, Matthias
Matthias Wieser wrote:
For instance, the encodes I did when I had a CRT now look terrible on my TFT :-(
Probably because your TFT and your CRT have differing gamma values. Maybe you can adjust them to a gamma value of 2.2.
Also, I have a hypothesis that since LCD displays are grids of square pixels, they show horizontal and vertical lines very sharply, making blocking artifacts stand out more.
If used carefully border_mask, scplx_mask, dark_mask and lumi_mask can improve visual quality. Keep in mind, that the other competitors use those 'psychosensory' settings even more (Nero, ms, divx6, realvideo,...).
I'm hesitant to use these, but I'll take it into consideration and try a test with fairly conservative values for lumi_mask and dark_mask. In a side-by-side comparison with a non-masked encode, the loss of contrast is definitely noticeable and detracts from overall impression of quality. I don't want to use any complexity masking because, from what I can tell by reading the previous Doom9 comparisons, accurately rendering complex scenes is a major criterion. Thanks, Corey
Corey Hickey wrote:
I'm hesitant to use these, but I'll take it into consideration and try a test with fairly conservative values for lumi_mask and dark_mask. In a side-by-side comparison with a non-masked encode, the loss of contrast is definitely noticeable and detracts from overall impression of quality.
Sorry, I was getting mixed up with vlelim. I'm trying lumi_mask=0.05 and dark_mask=0.01 right now. -Corey
On Sunday, 04 December 2005 at 01:05, Corey Hickey wrote:
Corey Hickey wrote:
I'm hesitant to use these, but I'll take it into consideration and try a test with fairly conservative values for lumi_mask and dark_mask. In a side-by-side comparison with a non-masked encode, the loss of contrast is definitely noticeable and detracts from overall impression of quality.
Sorry, I was getting mixed up with vlelim. I'm trying lumi_mask=0.05 and dark_mask=0.01 right now.
Try naq with these, too. -- MPlayer RPMs maintainer: http://rpm.greysector.net/mplayer/ "I am Grey. I stand between the candle and the star. We are Grey. We stand between the darkness ... and the light." -- Delenn in Grey Council in Babylon 5:"Babylon Squared"
On Sunday, 04 December 2005 at 01:23, Dominik 'Rathann' Mierzejewski wrote:
On Sunday, 04 December 2005 at 01:05, Corey Hickey wrote:
Corey Hickey wrote:
I'm hesitant to use these, but I'll take it into consideration and try a test with fairly conservative values for lumi_mask and dark_mask. In a side-by-side comparison with a non-masked encode, the loss of contrast is definitely noticeable and detracts from overall impression of quality.
Sorry, I was getting mixed up with vlelim. I'm trying lumi_mask=0.05 and dark_mask=0.01 right now.
Try naq with these, too.
There are also tcplx_mask, scplx_mask, p_mask and border_mask. Regards, R. -- MPlayer RPMs maintainer: http://rpm.greysector.net/mplayer/ "I am Grey. I stand between the candle and the star. We are Grey. We stand between the darkness ... and the light." -- Delenn in Grey Council in Babylon 5:"Babylon Squared"
Hi, Am Samstag, 3. Dezember 2005 22:56 schrieb Corey Hickey:
I don't want to use any complexity masking because, from what I can tell by reading the previous Doom9 comparisons, accurately rendering complex scenes is a major criterion.
You could also use *mask to give complex scenes more bits... Regards, Matthias
On Fri, Dec 02, 2005 at 06:58:10PM -0800, Corey Hickey wrote:
This is a status update and an inventory of what must be done.
------------------------------------------------------------------------ 1. mencoder binaries for windows. Doom9's usual binaries are at: http://www.aziendeassociate.it/cd.asp?dir=/mplayer The latest on that page are from 2005-11-23, and there is an athlon64-specific build. Probably these are suitable. I can't test the athlon64 build, so if anybody with access to an athlon64 windows box can test it that would be helpful.
------------------------------------------------------------------------ 2. mpeg4 encoding commands for The Matrix. This will end up being something like: -- for i in $1 $2 ; do mencoder ~/dumpstream/matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -ovc lavc -lavcopts \ vcodec=mpeg4:threads=2:vbitrate=581:vratetol=1000:1:mbd=2:mv0:trell:\ ^^^^^^^^^
multithreaded decoding is known to reduce psnr, albeit only very slightly. is it really worth it? imo tests should be on single-cpu anyway for fairness. rich
Rich Felker wrote:
for i in $1 $2 ; do mencoder ~/dumpstream/matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -ovc lavc -lavcopts \ vcodec=mpeg4:threads=2:vbitrate=581:vratetol=1000:1:mbd=2:mv0:trell:\
^^^^^^^^^
multithreaded decoding is known to reduce psnr, albeit only very slightly. is it really worth it? imo tests should be on single-cpu anyway for fairness.
Michael said the tests would be done on a dual-core CPU. Once I get the best single-threaded command line I can, I'll try threads=2 and see if there's a big PSNR drop. Also, see Michael's email to this thread on Fri, 2 Dec 2005 17:57:33 +0100. If threads=2 ends up being bad, then I can probably omit it and we'll still do pretty well in the performance department. The machine I'm testing on is roughly equivalent to the Athlon64 3500+ used in the 2004 comparison. Although the movie in that case was The Matrix Revolutions, the resolution is the same and framerates should be roughly equal. The fastest codecs listed were 58.99 fps (HDX4), 50.76 fps (3ivX), and 50.12 (XviD). By using turbo for the first pass, I'm getting an average of 77.18 fps. -Corey
On Saturday, 03 December 2005 at 03:58, Corey Hickey wrote:
This is a status update and an inventory of what must be done.
------------------------------------------------------------------------ 1. mencoder binaries for windows. Doom9's usual binaries are at: http://www.aziendeassociate.it/cd.asp?dir=/mplayer The latest on that page are from 2005-11-23, and there is an athlon64-specific build. Probably these are suitable. I can't test the athlon64 build, so if anybody with access to an athlon64 windows box can test it that would be helpful.
------------------------------------------------------------------------ 2. mpeg4 encoding commands for The Matrix. This will end up being something like: -- for i in $1 $2 ; do mencoder ~/dumpstream/matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -ovc lavc -lavcopts \
Loren has recommended lanczos swscaler for scaling (-sws 9). Isn't it what Doom9.org said should be used anyway?
vcodec=mpeg4:threads=2:vbitrate=581:vratetol=1000:1:mbd=2:mv0:trell:\ ^ What is this lonely '1' doing here? ------------------|
And why such small vratetol?
cbp:precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:vme=5:v4mv:\
Why vme=5? According to the manpage it's "aliased to 4", which is the default.
vpass=$i -ofps 24000/1001 done -- * qns=2, unfortunately, is prohibitively slow * I'm hoping to add turbo for pass 1 with little negative effect * I need to test vqcomp=0.7 or vqcomp=0.6
Rich said something about keeping it at the default level of 0.5 on IRC the other day.
* I need to test last_pred=2 * I need to test NSSE (*cmp=10)
If there's any noise in the source, maybe add nr=400? Oh, one more thing: what about B-frames? Regards, R. -- MPlayer RPMs maintainer: http://rpm.greysector.net/mplayer/ "I am Grey. I stand between the candle and the star. We are Grey. We stand between the darkness ... and the light." -- Delenn in Grey Council in Babylon 5:"Babylon Squared"
Hi On Sun, Dec 04, 2005 at 01:32:21AM +0100, Dominik 'Rathann' Mierzejewski wrote:
On Saturday, 03 December 2005 at 03:58, Corey Hickey wrote:
This is a status update and an inventory of what must be done.
------------------------------------------------------------------------ 1. mencoder binaries for windows. Doom9's usual binaries are at: http://www.aziendeassociate.it/cd.asp?dir=/mplayer The latest on that page are from 2005-11-23, and there is an athlon64-specific build. Probably these are suitable. I can't test the athlon64 build, so if anybody with access to an athlon64 windows box can test it that would be helpful.
------------------------------------------------------------------------ 2. mpeg4 encoding commands for The Matrix. This will end up being something like: -- for i in $1 $2 ; do mencoder ~/dumpstream/matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -ovc lavc -lavcopts \
Loren has recommended lanczos swscaler for scaling (-sws 9). Isn't it what Doom9.org said should be used anyway?
iam not sure but i faintly remember doom9 said something about using avisynth based scaling (=not sws) but this maybe was in the previous comparission, dunno ... [...] -- Michael
Am Sonntag, 4. Dezember 2005 01:57 schrieb Michael Niedermayer:
Loren has recommended lanczos swscaler for scaling (-sws 9). Isn't it what Doom9.org said should be used anyway?
iam not sure but i faintly remember doom9 said something about using avisynth based scaling (=not sws) but this maybe was in the previous comparission, dunno ...
If the lavc options are optimized for -sws 9 the avisynth based lanczos scaling should be no problem. Matthias
I've been quiet for the past couple days because it took a while to get some conclusive results in the time I had. My work is paying off, however, and I should be able to submit a set of very refined mpeg-4 lavcopts for your review some time tomorrow. I have a few tests left to run overnight. Some interesting notes: Adding b-frames does indeed increase PSNR on this movie. vmax_b_frames=0: PSNR: Y:41.31, Cb:44.26, Cr:44.73, All:42.13 vmax_b_frames=1: PSNR: Y:41.72, Cb:44.83, Cr:45.42, All:42.58 vmax_b_frames=2: PSNR: Y:41.78, Cb:44.93, Cr:45.57, All:42.66 vmax_b_frames=3: PSNR: Y:41.71, Cb:44.99, Cr:45.65, All:42.61 I stuck with vmax_b_frames=2. Using vb_strategy=1 on the first pass always decreased final PSNR slightly; quality was slightly lower as well. Thanks go to Jan Knutar for pointing out a potential pitfall -- there was indeed some flickering produced by using spp=2 to play the videos with b-frames. When I looked closely, the flickering was still there without spp, just less visible. Removing the quantizer difference between p- and b-frames makes the flicker go away entirely, at a cost of decreased PSNR and a visible quality loss. I've settled on vb_qfactor=1.1:vb_qoffset=0.6 as a reasonable compromise. This lowers the overall PSNR to 42.53, which is still a substantial gain over not using b-frames, while reducing the flicker to the point at which it is hardly perceptible. I tested all the various *_mask options along with naq, but was unable to find any reasonable levels. At extreme parameter values, the raised quantizer was visible where it was supposed to be for each corresponding option, but I couldn't see any substantial gain in the rest of the video. At more moderate values, the visual quality ranged from identical to slightly less than that of the original. Also, for what it's worth, each test lowered PSNR slightly. Unless anybody has any specific favorite values they'd like me to test, I'm going to forget about *_mask. If you noticed the email I cc'd to the list earlier today, you'll see that I'm having problems tuning spp appropriately with ffdshow. I may have to settle for more traditional postprocessing. In ffdshow, enabling the "mplayer" processing method and "Accurate deblocking" looks more or less ok, but not as good as spp=2. -Corey
Hi On Mon, Dec 05, 2005 at 11:29:56PM -0800, Corey Hickey wrote:
I've been quiet for the past couple days because it took a while to get some conclusive results in the time I had. My work is paying off, however, and I should be able to submit a set of very refined mpeg-4 lavcopts for your review some time tomorrow. I have a few tests left to run overnight.
Some interesting notes:
Adding b-frames does indeed increase PSNR on this movie. vmax_b_frames=0: PSNR: Y:41.31, Cb:44.26, Cr:44.73, All:42.13 vmax_b_frames=1: PSNR: Y:41.72, Cb:44.83, Cr:45.42, All:42.58 vmax_b_frames=2: PSNR: Y:41.78, Cb:44.93, Cr:45.57, All:42.66 vmax_b_frames=3: PSNR: Y:41.71, Cb:44.99, Cr:45.65, All:42.61
I stuck with vmax_b_frames=2. Using vb_strategy=1 on the first pass always decreased final PSNR slightly; quality was slightly lower as well.
Thanks go to Jan Knutar for pointing out a potential pitfall -- there was indeed some flickering produced by using spp=2 to play the videos with b-frames. When I looked closely, the flickering was still there without spp, just less visible. Removing the quantizer difference
retry, spp shouldnt add any flicker anymore [...] -- Michael
Michael Niedermayer wrote:
Thanks go to Jan Knutar for pointing out a potential pitfall -- there was indeed some flickering produced by using spp=2 to play the videos with b-frames. When I looked closely, the flickering was still there without spp, just less visible. Removing the quantizer difference
retry, spp shouldnt add any flicker anymore
I've tried it, and spp works marvelously now. Thanks again. Unfortunately, unless somebody can convince Milan Cutka to make a last-minute build of ffdshow with the latest libavcodec CVS, I don't think we'll get a chance to show off spp. :( There's also the issue of not being able to select the spp "quality" parameter in ffdshow. I'm cc'ing Milan in case he sees us and takes pity on our plight. If he does, I'd sure appreciate it. :) For that matter, if anybody else with experience building stuff on win32 could give it a try, that would be great. I'm also going to cross-post this to mplayer-cygwin just in case. Thanks, Corey
Here is my semi-final mpeg-4 encoding line for Doom9. for i in 1:turbo 2 ; do mencoder matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -sws 9 -ovc lavc \ -lavcopts vcodec=mpeg4:vbitrate=581:mbd=2:mv0:trell:cbp:\ precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:v4mv:\ last_pred=2:vqcomp=0.6:vmax_b_frames=2:vpass=$i \ -ofps 24000/1001 done After a couple dozen full encoding tests and numerous partial ones, the best result I have is little different from the "Very high quality" suggestion in the mplayer docs. Differences are: ----docs --------mine---------------reason----------- last_pred=3 last_pred=2 slower, no difference vb_strategy=1 <default> lower PSNR, worse quality qns=2 <default> too slow for this test If anybody has anything to suggest or spots anything wrong, please speak up now. Unless I hear any dissent I'm going to send it to Doom9 tomorrow evening. Further notes: I have been unable to find a suitable value for nr. Between nr=0 and nr=400 it seems to be a general progression toward loss of detail without any corresponding reduction in blockiness. Mostly it makes stubble on men's chins look blurry. last_pred=1 is a bit better and a bit slower than the default. last_pred=2 is a bit better and a bit slower than last_pred=1. last_pred=3 seems the same as last_pred=2 and is slower still. Unfortunately, the quality drop from using threads=2 is, in my opinion, unacceptable. The quality is a little bit worse than when not using any B-frames. Fortunately, encoding speed is still pretty good: the first pass runs at 92fps and the second at 29fps, yielding an average of 44fps. My computer is about as fast as the one used in the 2004 comparison, and this puts encoding speed at the high end of mid-range when compared to the codecs in the 2004 encoding tests. I think that's good enough, especially since quality is still the primary criterion. The other item of bad news is that I can't get spp to run fast enough on windows with Media Player Classic. I don't know where the fault lies, but if it doesn't come even close to working on an AthlonXP 3200+ I doubt it will be acceptable on whatever machine Doom9 uses. I'll have to fall back to using ffdshow's "mplayer postprocessing" with "accurate deblocking". Coming up: snow I've been queuing up snow tests to run in the early morning after that night's mpeg-4 encodes finish. I have a few more that will run tonight. The snow command will be like the one above, except with these differences: for i in 1:vqscale=2.15 2:vbitrate=581 ; do ...same options as above... -lavcopts vcodec=snow:vstrict=-2:cmp=1:subcmp=1:mbcmp=1:qpel:vpass=$i done Some time tonight my computer will test the effect of threads=2 with and without last_pred=2. -Corey
On Wednesday, 07 December 2005 at 09:22, Corey Hickey wrote:
Here is my semi-final mpeg-4 encoding line for Doom9.
for i in 1:turbo 2 ; do mencoder matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -sws 9 -ovc lavc \ -lavcopts vcodec=mpeg4:vbitrate=581:mbd=2:mv0:trell:cbp:\ precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:v4mv:\ last_pred=2:vqcomp=0.6:vmax_b_frames=2:vpass=$i \ -ofps 24000/1001 done
After a couple dozen full encoding tests and numerous partial ones, the best result I have is little different from the "Very high quality" suggestion in the mplayer docs. Differences are:
----docs --------mine---------------reason----------- last_pred=3 last_pred=2 slower, no difference vb_strategy=1 <default> lower PSNR, worse quality qns=2 <default> too slow for this test
If anybody has anything to suggest or spots anything wrong, please speak up now. Unless I hear any dissent I'm going to send it to Doom9 tomorrow evening.
Looks good to me.
Further notes:
I have been unable to find a suitable value for nr. Between nr=0 and nr=400 it seems to be a general progression toward loss of detail without any corresponding reduction in blockiness. Mostly it makes stubble on men's chins look blurry.
This is disappointing, as it was advertised as fast and effective denoising measure by some people here. R. -- MPlayer RPMs maintainer: http://rpm.greysector.net/mplayer/ "I am Grey. I stand between the candle and the star. We are Grey. We stand between the darkness ... and the light." -- Delenn in Grey Council in Babylon 5:"Babylon Squared"
On Wed, 7 Dec 2005 20:34:24 +0100 Dominik 'Rathann' Mierzejewski <dominik@rangers.eu.org> wrote:
I have been unable to find a suitable value for nr. Between nr=0 and nr=400 it seems to be a general progression toward loss of detail without any corresponding reduction in blockiness. Mostly it makes stubble on men's chins look blurry.
This is disappointing, as it was advertised as fast and effective denoising measure by some people here.
Nothing always works well on every video. There are always exceptions.
On Wed, Dec 07, 2005 at 12:22:37AM -0800, Corey Hickey wrote:
Here is my semi-final mpeg-4 encoding line for Doom9.
for i in 1:turbo 2 ; do mencoder matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -sws 9 -ovc lavc \ -lavcopts vcodec=mpeg4:vbitrate=581:mbd=2:mv0:trell:cbp:\ precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:v4mv:\ last_pred=2:vqcomp=0.6:vmax_b_frames=2:vpass=$i \ -ofps 24000/1001 done
After a couple dozen full encoding tests and numerous partial ones, the best result I have is little different from the "Very high quality" suggestion in the mplayer docs. Differences are:
----docs --------mine---------------reason----------- last_pred=3 last_pred=2 slower, no difference vb_strategy=1 <default> lower PSNR, worse quality qns=2 <default> too slow for this test
qns may be slow, but it's the best perceptual-quality improvement that doesn't show up in psnr results. you really should test and see, because it might make all the difference!
Unfortunately, the quality drop from using threads=2 is, in my opinion, unacceptable.
Definitely. I'm against using threads.
Coming up: snow
I've been queuing up snow tests to run in the early morning after that night's mpeg-4 encodes finish. I have a few more that will run tonight. The snow command will be like the one above, except with these differences:
for i in 1:vqscale=2.15 2:vbitrate=581 ; do ...same options as above... -lavcopts vcodec=snow:vstrict=-2:cmp=1:subcmp=1:mbcmp=1:qpel:vpass=$i done
Some time tonight my computer will test the effect of threads=2 with and without last_pred=2.
I don't think snow supports threads. Rich
Rich Felker wrote:
----docs --------mine---------------reason----------- last_pred=3 last_pred=2 slower, no difference vb_strategy=1 <default> lower PSNR, worse quality qns=2 <default> too slow for this test
qns may be slow, but it's the best perceptual-quality improvement that doesn't show up in psnr results. you really should test and see, because it might make all the difference!
Yeah, I like qns too. I tested it extensively when Michael first wrote it, so I know what differences to look for. I wasn't able to see very much of an improvement, though, so I figured it wasn't worth sacrificing that much encoding speed. I'm re-testing qns=2 right now with my current parameters, including threads=2 (see below), to see if it works out any better this time.
Unfortunately, the quality drop from using threads=2 is, in my opinion, unacceptable.
Definitely. I'm against using threads.
Last night, on a whim, I decided to test qpel. Tests published by Rémi Guyomarch a few years ago showed a definite PSNR improvement from using qpel. My own tests confirmed that. Later on, I found that qpel was decreasing PSNR, and tests by a few other people confirmed that. Now, oddly enough, adding qpel raised the PSNR from 42.66 to 42.96, with a definite corresponding quality improvement. I can't say whether qpel should be recommended in general, but it obviously helps under these specific circumstances. Meanwhile, Michael had fixed the PSNR calculation for multithreaded encoding (thanks, Michael), so I ran a test with threads=2 and qpel. This brought PSNR down to 42.92, and I can see only a very very slight decrease in overall quality. Although "qpel" is the best, "qpel:threads=2" still looks a little better than omitting both options. Unfortunately, adding qpel brings the second pass' fps down from 29 to 18. The first pass is the same (92), so the average drops from 44 to 30. Can anyone give me a general estimate of how much of a performance improvement to expect from using threads=2 on a dual-core machine? I don't have access to any multiprocessor/multicore setups so I can't test it myself. If the improvement is better than 40% or so, then I think qpel and threads=2 is worth it. Otherwise, I think it would be good to leave them both out. I'm going to wait a bit longer before I send the results to Doom9, but I would appreciate it if anybody gave me some feedback about this ASAP.
Coming up: snow
I've been queuing up snow tests to run in the early morning after that night's mpeg-4 encodes finish. I have a few more that will run tonight. The snow command will be like the one above, except with these differences:
for i in 1:vqscale=2.15 2:vbitrate=581 ; do ...same options as above... -lavcopts vcodec=snow:vstrict=-2:cmp=1:subcmp=1:mbcmp=1:qpel:vpass=$i done
Some time tonight my computer will test the effect of threads=2 with and without last_pred=2.
I don't think snow supports threads.
Ok. Also, my test with last_pred=2 came up identical to the default (diff 1.avi 2.avi). Should that be happening? DOCS/tech/snow.txt says last_pred has "negligible effect on both speed and quality", but I was expecting the files to be at least a little different. I only ended up testing last_pred because Michael thought it might help with multithreaded encoding. Of course, he was referring to mpeg-4, but I thought I'd try it anyway. -Corey
Hi On Wed, Dec 07, 2005 at 05:41:57PM -0800, Corey Hickey wrote: [...]
Unfortunately, the quality drop from using threads=2 is, in my opinion, unacceptable.
Definitely. I'm against using threads.
Last night, on a whim, I decided to test qpel. Tests published by Rémi Guyomarch a few years ago showed a definite PSNR improvement from using qpel. My own tests confirmed that. Later on, I found that qpel was decreasing PSNR, and tests by a few other people confirmed that.
Now, oddly enough, adding qpel raised the PSNR from 42.66 to 42.96, with a definite corresponding quality improvement. I can't say whether qpel should be recommended in general, but it obviously helps under these specific circumstances.
Meanwhile, Michael had fixed the PSNR calculation for multithreaded encoding (thanks, Michael), so I ran a test with threads=2 and qpel. This brought PSNR down to 42.92, and I can see only a very very slight decrease in overall quality. Although "qpel" is the best, "qpel:threads=2" still looks a little better than omitting both options.
Unfortunately, adding qpel brings the second pass' fps down from 29 to 18. The first pass is the same (92), so the average drops from 44 to 30.
you could try subq if you still have time ...
Can anyone give me a general estimate of how much of a performance improvement to expect from using threads=2 on a dual-core machine? I don't have access to any multiprocessor/multicore setups so I can't test it myself. If the improvement is better than 40% or so, then I think qpel and threads=2 is worth it. Otherwise, I think it would be good to leave them both out. I'm going to wait a bit longer before I send the results to Doom9, but I would appreciate it if anybody gave me some feedback about this ASAP.
i dunno but my feeling is that the threads=2 speedup will be below 40% [...]
Also, my test with last_pred=2 came up identical to the default (diff 1.avi 2.avi). Should that be happening? DOCS/tech/snow.txt says last_pred has "negligible effect on both speed and quality", but I was expecting the files to be at least a little different. I only ended up testing last_pred because Michael thought it might help with multithreaded encoding. Of course, he was referring to mpeg-4, but I thought I'd try it anyway.
snow + last_pred seems broken, dont use it, i will _maybe_ look at it tomorrow [...] -- Michael
Michael Niedermayer wrote:
Unfortunately, the quality drop from using threads=2 is, in my opinion, unacceptable.
Definitely. I'm against using threads.
Last night, on a whim, I decided to test qpel. Tests published by Rémi Guyomarch a few years ago showed a definite PSNR improvement from using qpel. My own tests confirmed that. Later on, I found that qpel was decreasing PSNR, and tests by a few other people confirmed that.
Now, oddly enough, adding qpel raised the PSNR from 42.66 to 42.96, with a definite corresponding quality improvement. I can't say whether qpel should be recommended in general, but it obviously helps under these specific circumstances.
Meanwhile, Michael had fixed the PSNR calculation for multithreaded encoding (thanks, Michael), so I ran a test with threads=2 and qpel. This brought PSNR down to 42.92, and I can see only a very very slight decrease in overall quality. Although "qpel" is the best, "qpel:threads=2" still looks a little better than omitting both options.
Unfortunately, adding qpel brings the second pass' fps down from 29 to 18. The first pass is the same (92), so the average drops from 44 to 30.
you could try subq if you still have time ...
Good idea. I graphed the results of some old data I have on subq testing. subq=5 is probably a reasonable value for a significant performance increase and a fairly small PSNR decrease. I'll test that and the surrounding subq values tonight. Doom9 wants results by the weekend at the latest, but earlier is better so I'd really like to get them out by tomorrow.
Can anyone give me a general estimate of how much of a performance improvement to expect from using threads=2 on a dual-core machine? I don't have access to any multiprocessor/multicore setups so I can't test it myself. If the improvement is better than 40% or so, then I think qpel and threads=2 is worth it. Otherwise, I think it would be good to leave them both out. I'm going to wait a bit longer before I send the results to Doom9, but I would appreciate it if anybody gave me some feedback about this ASAP.
i dunno but my feeling is that the threads=2 speedup will be below 40%
Just now I used some old data from tests of material that probably isn't very similar to make some rough calculations that I probably screwed up, but if everything is correct than the speedup from using threads=2 would only have to be 13% in order to, along with qpel:subq=5, give equal quality to using neither threads=2 nor qpel. So, now the question becomes: do you think the performance improvement from threads=2 is greater than 13%? Alternatively, I could drop the idea of threads=2 but retain qpel:subq=5. This should give a mild but noticeable quality improvement at the cost of lowering average fps from 44 to 39 (versus 30 for not using subq). Again, this is based on rough calculations that might or might not be close; I'll have real numbers tomorrow. -Corey
Corey Hickey wrote:
Rich Felker wrote:
----docs --------mine---------------reason----------- last_pred=3 last_pred=2 slower, no difference vb_strategy=1 <default> lower PSNR, worse quality qns=2 <default> too slow for this test
qns may be slow, but it's the best perceptual-quality improvement that doesn't show up in psnr results. you really should test and see, because it might make all the difference!
Yeah, I like qns too. I tested it extensively when Michael first wrote it, so I know what differences to look for. I wasn't able to see very much of an improvement, though, so I figured it wasn't worth sacrificing that much encoding speed.
Upon re-reading that third sentence, I realized I worded it wrong. I should have said, "When testing qns=2 for this comparison, I wasn't able to see much of an improvement,". Trouble is, the postprocessing eliminates most of the ringing artifacts anyway, so the benefit of qns is masked. The difference is still visible, but so subtle that I doubt anyone would notice unless they already knew what to look for and where to find it.
I'm re-testing qns=2 right now with my current parameters, including threads=2 (see below), to see if it works out any better this time.
The encode still isn't finished, but I've viewed several parts already and my conclusion is that it just isn't worth it for this comparison. I still like qns=2, I'll keep using it myself, and I will still recommend it in general when speed isn't much of an issue. Since speed is a factor in Doom9's evaluation, though, I have to leave it out for now. qns=1 is barely faster, so I don't think it's an acceptable compromise either. I'll let the encode finish some time tonight and report the results for posterity. -Corey
Corey Hickey wrote:
----docs --------mine---------------reason----------- last_pred=3 last_pred=2 slower, no difference vb_strategy=1 <default> lower PSNR, worse quality qns=2 <default> too slow for this test
qns may be slow, but it's the best perceptual-quality improvement that doesn't show up in psnr results. you really should test and see, because it might make all the difference!
Yeah, I like qns too. I tested it extensively when Michael first wrote it, so I know what differences to look for. I wasn't able to see very much of an improvement, though, so I figured it wasn't worth sacrificing that much encoding speed.
Upon re-reading that third sentence, I realized I worded it wrong. I should have said, "When testing qns=2 for this comparison, I wasn't able to see much of an improvement,".
Trouble is, the postprocessing eliminates most of the ringing artifacts anyway, so the benefit of qns is masked. The difference is still visible, but so subtle that I doubt anyone would notice unless they already knew what to look for and where to find it.
I'm re-testing qns=2 right now with my current parameters, including threads=2 (see below), to see if it works out any better this time.
The encode still isn't finished, but I've viewed several parts already and my conclusion is that it just isn't worth it for this comparison. I still like qns=2, I'll keep using it myself, and I will still recommend it in general when speed isn't much of an issue. Since speed is a factor in Doom9's evaluation, though, I have to leave it out for now. qns=1 is barely faster, so I don't think it's an acceptable compromise either.
I'll let the encode finish some time tonight and report the results for posterity.
Here are the results for adding qns to the second pass. without qns: 184m54.632s with qns=2: 401m13.102s -Corey
On Thu, Dec 08, 2005 at 01:55:28PM -0800, Corey Hickey wrote:
The encode still isn't finished, but I've viewed several parts already and my conclusion is that it just isn't worth it for this comparison. I still like qns=2, I'll keep using it myself, and I will still recommend it in general when speed isn't much of an issue. Since speed is a factor in Doom9's evaluation, though, I have to leave it out for now. qns=1 is barely faster, so I don't think it's an acceptable compromise either.
I'll let the encode finish some time tonight and report the results for posterity.
Here are the results for adding qns to the second pass.
without qns: 184m54.632s with qns=2: 401m13.102s
Any comments on relative quality? Rich
Rich Felker wrote:
On Thu, Dec 08, 2005 at 01:55:28PM -0800, Corey Hickey wrote:
The encode still isn't finished, but I've viewed several parts already and my conclusion is that it just isn't worth it for this comparison. I still like qns=2, I'll keep using it myself, and I will still recommend it in general when speed isn't much of an issue. Since speed is a factor in Doom9's evaluation, though, I have to leave it out for now. qns=1 is barely faster, so I don't think it's an acceptable compromise either.
I'll let the encode finish some time tonight and report the results for posterity.
Here are the results for adding qns to the second pass.
without qns: 184m54.632s with qns=2: 401m13.102s
Any comments on relative quality?
Just like I had said before: --- Trouble is, the postprocessing eliminates most of the ringing artifacts anyway, so the benefit of qns is masked. The difference is still visible, but so subtle that I doubt anyone would notice unless they already knew what to look for and where to find it. --- PSNR dropped from 42.92 to 42.86. Not that it means anything. -Corey
On Wed, Dec 07, 2005 at 05:41:57PM -0800, Corey Hickey wrote:
Unfortunately, the quality drop from using threads=2 is, in my opinion, unacceptable.
Definitely. I'm against using threads.
Last night, on a whim, I decided to test qpel. Tests published by Rémi Guyomarch a few years ago showed a definite PSNR improvement from using qpel. My own tests confirmed that. Later on, I found that qpel was decreasing PSNR, and tests by a few other people confirmed that.
Now, oddly enough, adding qpel raised the PSNR from 42.66 to 42.96, with a definite corresponding quality improvement. I can't say whether qpel should be recommended in general, but it obviously helps under these specific circumstances.
Meanwhile, Michael had fixed the PSNR calculation for multithreaded encoding (thanks, Michael), so I ran a test with threads=2 and qpel. This brought PSNR down to 42.92, and I can see only a very very slight decrease in overall quality. Although "qpel" is the best, "qpel:threads=2" still looks a little better than omitting both options.
If there's ANY visible decrease in quality, do not use threads. Simple as that. It's stupid for an encoding benchmark anyway since no one has or uses multi-cpu machines for encoding, since they're a waste of money, electricity, etc. etc. etc. I don't want to see lavc getting chewed out for bad image quality because someone wanted to save a little time by using a dual-cpu system to encode at lower quality... If we want to make lavc look fast, why not do everything else that gets performance at the expense of quality too? Set mbd=0, disable all options like qpel, 4mv, ... etc..... :( Rich
Rich Felker wrote:
Unfortunately, the quality drop from using threads=2 is, in my opinion, unacceptable.
Definitely. I'm against using threads.
Last night, on a whim, I decided to test qpel. Tests published by Rémi Guyomarch a few years ago showed a definite PSNR improvement from using qpel. My own tests confirmed that. Later on, I found that qpel was decreasing PSNR, and tests by a few other people confirmed that.
Now, oddly enough, adding qpel raised the PSNR from 42.66 to 42.96, with a definite corresponding quality improvement. I can't say whether qpel should be recommended in general, but it obviously helps under these specific circumstances.
Meanwhile, Michael had fixed the PSNR calculation for multithreaded encoding (thanks, Michael), so I ran a test with threads=2 and qpel. This brought PSNR down to 42.92, and I can see only a very very slight decrease in overall quality. Although "qpel" is the best, "qpel:threads=2" still looks a little better than omitting both options.
If there's ANY visible decrease in quality, do not use threads. Simple as that. It's stupid for an encoding benchmark anyway since no one has or uses multi-cpu machines for encoding, since they're a waste of money, electricity, etc. etc. etc. I don't want to see lavc getting chewed out for bad image quality because someone wanted to save a little time by using a dual-cpu system to encode at lower quality...
Ok. If you feel that strongly about it then I'll leave threads=2 out. I'm pretty much neutral at this point (not to mention getting a little tired of running a zillion tests).
If we want to make lavc look fast, why not do everything else that gets performance at the expense of quality too? Set mbd=0, disable all options like qpel, 4mv, ... etc..... :(
That would be overreacting, of course. :) The point is not to make lavc look fast, the point is to cram in as many quality-improving options while still having reasonable encoding speed. qpel slows down lavc considerably (I'm pretty sure more so than any other single options under consideration besides qns). Before trying qpel, I figured speed was reasonably good, but there wasn't much headroom. ...actually, now that I look at the codec speeds in the 2004 comparison, 30fps when using qpel really isn't unfavorable... Anyway, what I was getting at was that it should be possible to have significantly better performance at very little loss of quality by combining threads=2 with qpel. As I mentioned before, the quality drop of using threads=2 is (in this instance) significantly less than when it is used without qpel. I wish I had access to a dual-core/dual-processor machine so I could actually provide some better performance numbers. The reason my argument is so shaky is that I can't get the actual data, just what "ought to" happen. Let me take a look at the subq results tomorrow morning. I'm really tired now. Probably we can settle on omitting threads=2, but using qpel and maybe subq=6 or subq=7. -Corey
Am Donnerstag, 8. Dezember 2005 08:55 schrieb Corey Hickey:
Rich Felker wrote:
Unfortunately, the quality drop from using threads=2 is, in my opinion, unacceptable.
Definitely. I'm against using threads.
Last night, on a whim, I decided to test qpel. Tests published by Rémi Guyomarch a few years ago showed a definite PSNR improvement from using qpel. My own tests confirmed that. Later on, I found that qpel was decreasing PSNR, and tests by a few other people confirmed that.
Now, oddly enough, adding qpel raised the PSNR from 42.66 to 42.96, with a definite corresponding quality improvement. I can't say whether qpel should be recommended in general, but it obviously helps under these specific circumstances.
Meanwhile, Michael had fixed the PSNR calculation for multithreaded encoding (thanks, Michael), so I ran a test with threads=2 and qpel. This brought PSNR down to 42.92, and I can see only a very very slight decrease in overall quality. Although "qpel" is the best, "qpel:threads=2" still looks a little better than omitting both options.
If there's ANY visible decrease in quality, do not use threads. Simple as that. It's stupid for an encoding benchmark anyway since no one has or uses multi-cpu machines for encoding, since they're a waste of money, electricity, etc. etc. etc. I don't want to see lavc getting chewed out for bad image quality because someone wanted to save a little time by using a dual-cpu system to encode at lower quality...
Ok. If you feel that strongly about it then I'll leave threads=2 out. I'm pretty much neutral at this point (not to mention getting a little tired of running a zillion tests).
If you think it makes lavc look better in the doom9 comparison, leave threads=2 out. But please don't leave threads=2 out only because one person does not like dual-core CPUs.
Anyway, what I was getting at was that it should be possible to have significantly better performance at very little loss of quality by combining threads=2 with qpel.
Sounds good!
I wish I had access to a dual-core/dual-processor machine so I could actually provide some better performance numbers. The reason my argument is so shaky is that I can't get the actual data, just what "ought to" happen.
Some actual benchmarks: http://www.linuxhardware.org/article.pl?sid=05/07/11/185212&mode=thread/ Athlon 64, 2.4GHz Single core: 22minutes Dual core: 17minutes Regards, Matthias
Hi On Thu, Dec 08, 2005 at 02:07:24PM +0100, Matthias Wieser wrote: [...]
I wish I had access to a dual-core/dual-processor machine so I could actually provide some better performance numbers. The reason my argument is so shaky is that I can't get the actual data, just what "ought to" happen.
Some actual benchmarks: http://www.linuxhardware.org/article.pl?sid=05/07/11/185212&mode=thread/ Athlon 64, 2.4GHz Single core: 22minutes Dual core: 17minutes
nice, but maybe that should be tested on the same OS doom9 will be using? [...] -- Michael
On Thu, Dec 08, 2005 at 01:35:16PM +0100, Michael Niedermayer wrote:
Hi On Thu, Dec 08, 2005 at 02:07:24PM +0100, Matthias Wieser wrote: [...]
I wish I had access to a dual-core/dual-processor machine so I could actually provide some better performance numbers. The reason my argument is so shaky is that I can't get the actual data, just what "ought to" happen.
Some actual benchmarks: http://www.linuxhardware.org/article.pl?sid=05/07/11/185212&mode=thread/ Athlon 64, 2.4GHz Single core: 22minutes Dual core: 17minutes
nice, but maybe that should be tested on the same OS doom9 will be using?
in any case, the interesting comparison in doom9's test is which codec is _better_, not which one is _faster_. i'm sure they'll evaluate both, but NO SANE ENCODER deciding which codec to use will choose based on speed; they'll choose based on maximum achievable quality. fyi my machine encodes at 1-8 fps even with only modest settings, and i'm perfectly happy with that. you only encode once. you have to watch the hideous artifacts you created every time you watch the movie. thus spend the time and do it right! rich
On Thu, Dec 08, 2005 at 12:24:59PM -0500, Rich Felker wrote:
On Thu, Dec 08, 2005 at 01:35:16PM +0100, Michael Niedermayer wrote:
Hi On Thu, Dec 08, 2005 at 02:07:24PM +0100, Matthias Wieser wrote: [...]
I wish I had access to a dual-core/dual-processor machine so I could actually provide some better performance numbers. The reason my argument is so shaky is that I can't get the actual data, just what "ought to" happen.
Some actual benchmarks: http://www.linuxhardware.org/article.pl?sid=05/07/11/185212&mode=thread/ Athlon 64, 2.4GHz Single core: 22minutes Dual core: 17minutes
nice, but maybe that should be tested on the same OS doom9 will be using?
in any case, the interesting comparison in doom9's test is which codec is _better_, not which one is _faster_. i'm sure they'll evaluate both, but NO SANE ENCODER deciding which codec to use will choose based on speed; they'll choose based on maximum achievable quality.
fyi my machine encodes at 1-8 fps even with only modest settings, and i'm perfectly happy with that. you only encode once. you have to watch the hideous artifacts you created every time you watch the movie. thus spend the time and do it right!
btw, to clarify: if an option gives only minor improvement in psnr or visual quality and increases encoding time by an order of magnitude, it may be ok to drop it (e.g. qns, perhaps?). on the other hand, threads will give at MOST a 2x performance boost (and in actuality maybe 20-25%) and significantly lower psnr. yes i hate threads in general, but this argument is not about threads. it's about the need to showcase lavc at its full quality, not foolishly optimized for encoding speed at the expense of quality. rich
Am Donnerstag, 8. Dezember 2005 08:07 schrieb Rich Felker:
If there's ANY visible decrease in quality, do not use threads.
If the decrease in quality caused by threads=2 is small you can use other optins to increase quality while retaining the same encoding speed.
Simple as that.
It's not that simple ;-)
It's stupid for an encoding benchmark anyway since no one has or uses multi-cpu machines for encoding,
Many people use multi-CPU machines or dual core or hyperthreading CPUs for encoding. All of those benefit from threads>=2.
since they're a waste of money, electricity, etc. etc. etc.
A dualcore *machine* generally does *not* use two times the electricity of a singel-core machine but sometimes it is significantly faster.
I don't want to see lavc getting chewed out for bad image quality because someone wanted to save a little time by using a dual-cpu system to encode at lower quality...
If we want to make lavc look fast, why not do everything else that gets performance at the expense of quality too? Set mbd=0, disable all options like qpel, 4mv, ... etc..... :(
If you do not accept any decrease in quality compared to the optimum, why not enable all quality increasing options and recommend a mencoder commandline to doom9 which results in 1fps encoding speed? -> compromise between speed and quality Regards, Matthias
Am Mittwoch, 7. Dezember 2005 09:22 schrieb Corey Hickey:
Unfortunately, the quality drop from using threads=2 is, in my opinion, unacceptable. The quality is a little bit worse than when not using any B-frames.
Do you mean "quality" or psnr? Maybe the low psnr was caused by the psnr-threads-bug? This might be of interest: http://forum.doom9.org/showthread.php?s=&threadid=61128 Regards, Matthias p.s.: Keep up the good work!
Matthias Wieser wrote:
Unfortunately, the quality drop from using threads=2 is, in my opinion, unacceptable. The quality is a little bit worse than when not using any B-frames.
Do you mean "quality" or psnr?
I mean "quality" by my perception of how accurately the original frame is represented. Most of the different options are too subtle to see except by a frame-by-frame comparison. I play the two videos simultaneously, scaling them with -xy 2 so I can see the differences more easily, and place them one above the other. Then I seek both videos to several positions I know look bad, and use framestep to compare several frames at each position. Mostly, the quality difference I see corresponds to the difference in PSNR.
Maybe the low psnr was caused by the psnr-threads-bug?
Actually, the PSNR for threads=2 was being reported as much too high: 44.09 vs. what was really something less than 42.66. I haven't repeated the test since Michael fixed that bug, but I may do so later for posterity. See the response I wrote to Rich a few minutes ago for some encouraging results with qpel:threads=2.
This might be of interest: http://forum.doom9.org/showthread.php?s=&threadid=61128
That is indeed interesting. I skimmed the thread, and also found some pictures and numbers: http://www.cns.nyu.edu/~zwang/files/research/quality_index/demo_lena.html Is there any implementation that works on Linux?
Regards, Matthias
p.s.: Keep up the good work!
You're welcome. :) -Corey
Hi, Am Donnerstag, 8. Dezember 2005 02:55 schrieb Corey Hickey:
Matthias Wieser wrote:
This might be of interest: http://forum.doom9.org/showthread.php?s=&threadid=61128
That is indeed interesting. I skimmed the thread, and also found some pictures and numbers:
http://www.cns.nyu.edu/~zwang/files/research/quality_index/demo_lena.ht ml
Is there any implementation that works on Linux?
Unfortunately I'm not aware of any Linux implementation. Regards, Matthias
On Thu, Dec 08, 2005 at 02:12:10PM +0100, Matthias Wieser wrote:
Hi, Am Donnerstag, 8. Dezember 2005 02:55 schrieb Corey Hickey:
Matthias Wieser wrote:
This might be of interest: http://forum.doom9.org/showthread.php?s=&threadid=61128
That is indeed interesting. I skimmed the thread, and also found some pictures and numbers:
http://www.cns.nyu.edu/~zwang/files/research/quality_index/demo_lena.ht ml
Is there any implementation that works on Linux?
Unfortunately I'm not aware of any Linux implementation.
best and easiest way to use this would just be to add it to lavc. the algorithm is simple and fully documented in the paper at that site. rich
Am Donnerstag, 8. Dezember 2005 18:21 schrieb Rich Felker:
On Thu, Dec 08, 2005 at 02:12:10PM +0100, Matthias Wieser wrote:
Hi,
Am Donnerstag, 8. Dezember 2005 02:55 schrieb Corey Hickey:
Matthias Wieser wrote:
This might be of interest: http://forum.doom9.org/showthread.php?s=&threadid=61128
That is indeed interesting. I skimmed the thread, and also found some pictures and numbers:
http://www.cns.nyu.edu/~zwang/files/research/quality_index/demo_len a.ht ml
Is there any implementation that works on Linux?
Unfortunately I'm not aware of any Linux implementation.
best and easiest way to use this would just be to add it to lavc.
Maybe an external implementation could be even more powerful because one could additionally investigate the effects of filters and things like that. It's comparable to the psnr calculation: "-lavc psnr" can only show (for example) if v4mv is good or bad but it is not able to show if one should use "-lavc nr=400" or better "-vf hqdn3d". An external implementation which compares the original video file and the recompressed video file can do this. Regards, Matthias
On Fri, Dec 09, 2005 at 01:03:00AM +0100, Matthias Wieser wrote:
Am Donnerstag, 8. Dezember 2005 18:21 schrieb Rich Felker:
On Thu, Dec 08, 2005 at 02:12:10PM +0100, Matthias Wieser wrote:
Hi,
Am Donnerstag, 8. Dezember 2005 02:55 schrieb Corey Hickey:
Matthias Wieser wrote:
This might be of interest: http://forum.doom9.org/showthread.php?s=&threadid=61128
That is indeed interesting. I skimmed the thread, and also found some pictures and numbers:
http://www.cns.nyu.edu/~zwang/files/research/quality_index/demo_len a.ht ml
Is there any implementation that works on Linux?
Unfortunately I'm not aware of any Linux implementation.
best and easiest way to use this would just be to add it to lavc.
Maybe an external implementation could be even more powerful because one could additionally investigate the effects of filters and things like that.
It's comparable to the psnr calculation: "-lavc psnr" can only show (for example) if v4mv is good or bad but it is not able to show if one should use "-lavc nr=400" or better "-vf hqdn3d". An external implementation which compares the original video file and the recompressed video file can do this.
yes but an external implementation is also much less efficient to use and not supported by mplayer/mencoder (without first decoding all frames to uncompressed image files...). rich
All right, everybody. I've tested pretty much everything I can. Here's a draft of the email I will send to Doom9. Please read it carefully -- I don't know as much about some parts as I do others. ---------BEGIN----------- Hello, After much testing and deliberation, I present to you the best encoding and decoding options I can come up with at this time. Please let me know if you have any trouble; I'll try to stay in contact as much as possible via email. Part 1: general The mencoder binaries you usually use will suffice: http://www.aziendeassociate.it/cd.asp?dir=/mplayer I have tested with what is currently the latest build, dated 2005-11-23. For playback, use ffdshow. I have tested with this build: http://cutka.szm.sk/ffdshow-20051129.exe Media Player Classic build 6487 works for me: http://prdownloads.sourceforge.net/guliverkli/mpc2kxp6487.7z?download I notice that in the faq for your 2004 comparison, you specify that noise added in postprocessing is disallowed. Please let me know if that is not still the case; I can provide parameters for adding a bit of noise that slightly improves perceptual quality. The video bitrates in the following commands are based on the email you sent me earlier; feel free to tweak them as needed to suit whichever container you mux into. Part 2: FFmpeg MPEG-4 This set of options to mencoder are tuned for quality, not speed, in almost every way. The only quality-oriented option left out is qns=2; this has a noticeable effect, but most of the benefits are concealed by postprocessing and in this case it isn't worth the drop in performance. I suspect you will want to use your MeGUI frontend, so I'll just give you a relatively compact unix-style command that you can translate easily. --- for i in vpass=1:turbo vpass=2 ; do mencoder matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -sws 9 -ovc lavc \ -lavcopts vcodec=mpeg4:vbitrate=581:mbd=2:mv0:trell:cbp:\ precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:v4mv:\ last_pred=2:vqcomp=0.6:vmax_b_frames=2:qpel:$i \ -ofps 24000/1001 -o mpeg4.avi done --- The only difference between the first and second pass (besides vpass, of course) is that the first pass uses turbo. For playback, I suggest using ffdshow's "mplayer" processing method with "Accurate deblocking" enabled. Leave processing strength at the default. Part 3: FFmpeg snow Snow has a lot fewer options to tweak, at this point. All these options for snow are tuned for quality. --- for i in vpass=1:vqscale=2.15 vpass=2:vbitrate=581 ; do mencoder matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -sws 9 -ovc lavc \ -lavcopts vcodec=snow:vstrict=-2:cmp=1:subcmp=1:mbcmp=1:\ qpel:vqcomp=0.6:$i -ofps 24000/1001 -o snow.avi done --- The first pass is done with a constant quantizer that approximates the bitrate used in the second pass. For playback, no postprocessing is needed. I haven't had any success with getting Media Player Classic to play MP4Box-muxed MP4 files with snow video. In the event your favorite AVI muxer doesn't understand snow either, you can use the following mencoder command: mencoder snow.avi -audiofile audio.mp3 -mc 0 -noskip \ -ovc copy -oac copy -o snow-final.avi Again, feel free to adjust the bitrate of the second pass to suit the container. You don't need to mess with vqscale for such small adjustments. Part 4: thanks The following people helped me out on the MPlayer mailing lists: Michael Niedermayer Dominik 'Rathann' Mierzejewski Guillaume POIRIER Rich Felker Hans-Carl Oberdalhoff Martin Collins Matthias Wieser Jan Knutar RC Stefan Gürtler Also, many thanks are due to all the MPlayer and FFmpeg authors, especially Michael Niedermayer, who wrote a large portion of the encoding parts of both programs and fixed a few bugs I threw at him in the course of this evaluation. -Corey Hickey ---------END---------
Corey Hickey wrote:
All right, everybody. I've tested pretty much everything I can. Here's a draft of the email I will send to Doom9. Please read it carefully -- I don't know as much about some parts as I do others.
If I don't hear any negative feedback in the next 14 hours, I'm going to send this to Doom9. -Corey
Hi, On 12/9/05, Corey Hickey <bugfood-ml@fatooh.org> wrote: [..]
for i in vpass=1:turbo vpass=2 ; do mencoder matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -sws 9 -ovc lavc \ -lavcopts vcodec=mpeg4:vbitrate=581:mbd=2:mv0:trell:cbp:\ precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:v4mv:\ last_pred=2:vqcomp=0.6:vmax_b_frames=2:qpel:$i \ -ofps 24000/1001 -o mpeg4.avi done
I note that you force the framerate to 24000/1001... I don't know what kind of source doom9 is gonna use, but it may not be NTSC dvds (mencoder need the framerate of those sources to be set). I also note here that you did not use any inverse telecine filters. Is that intended? I have little experience with ntsc contents, but if I'm not mistaken, failure to properly inverse telecine results in artifacts and bad picture quality. Now, doom9 is maybe using a frameserver such as avisynth which can probably do all the filtering, I don't know. Those are the kind of details that matter a great deal if they are forgotten or not well made. Guillaume -- MPlayer's doc is offline. Find some fresh one here: http://tuxrip.free.fr//MPlayer-DOCS-HTML/en/ http://tuxrip.free.fr//MPlayer-DOCS-HTML/fr/
On Friday 09 December 2005 10:45, Guillaume POIRIER wrote:
I note that you force the framerate to 24000/1001... I don't know what kind of source doom9 is gonna use, but it may not be NTSC dvds (mencoder need the framerate of those sources to be set). I also note here that you did not use any inverse telecine filters. Is that intended?
Though I didn't check it very thoroughly, the R1 Farscape S1 DVD I have only had soft telecine, so -ofps 24000/1001 was sufficient. Does doom9 use NTSC or PAL DVDs for source?
Guillaume POIRIER wrote:
for i in vpass=1:turbo vpass=2 ; do mencoder matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -sws 9 -ovc lavc \ -lavcopts vcodec=mpeg4:vbitrate=581:mbd=2:mv0:trell:cbp:\ precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:v4mv:\ last_pred=2:vqcomp=0.6:vmax_b_frames=2:qpel:$i \ -ofps 24000/1001 -o mpeg4.avi done
I note that you force the framerate to 24000/1001... I don't know what kind of source doom9 is gonna use, but it may not be NTSC dvds (mencoder need the framerate of those sources to be set). I also note here that you did not use any inverse telecine filters. Is that intended?
Yes. The source for the preliminary evaluation (where we compete against xvid alone) is the U.S. release of The Matrix. I played it all the way through with "-vo null -nosound -benchmark" to check, and it is entirely soft-telecine.
I have little experience with ntsc contents, but if I'm not mistaken, failure to properly inverse telecine results in artifacts and bad picture quality.
Lots of bad things happen if inverse telecine is needed but not used. MEncoder drops frames to maintain the output framerate and faithfully tries to reproduce the interlacing. This makes the movie ugly, jerky, and blocky because such things ruin compressibility.
Now, doom9 is maybe using a frameserver such as avisynth which can probably do all the filtering, I don't know.
Unless I've been misled, it will be mencoder all the way. I have it set up to use the exact same cropping and scaling parameters as Doom9 will use for the other codecs. Actually, if it were my own encode I would crop the vertical edges a couple more pixels to get rid of the black border completely, but I can't do that here because it should be fair. Besides, Doom9 would probably notice. :)
Those are the kind of details that matter a great deal if they are forgotten or not well made.
Yes. Thanks for pointing them out. -Corey
On Fri, Dec 09, 2005 at 09:45:01AM +0100, Guillaume POIRIER wrote:
Hi,
On 12/9/05, Corey Hickey <bugfood-ml@fatooh.org> wrote:
[..]
for i in vpass=1:turbo vpass=2 ; do mencoder matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -sws 9 -ovc lavc \ -lavcopts vcodec=mpeg4:vbitrate=581:mbd=2:mv0:trell:cbp:\ precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:v4mv:\ last_pred=2:vqcomp=0.6:vmax_b_frames=2:qpel:$i \ -ofps 24000/1001 -o mpeg4.avi done
I note that you force the framerate to 24000/1001... I don't know what kind of source doom9 is gonna use, but it may not be NTSC dvds
The matrix source is definitely not hard telecined. Videophiles would not put up with such shit. :) They may be using a pal version, I dunno, but if so they can correct the command line for that I'm sure.. Rich
Hi Corey Hickey! On 2005.12.08 at 17:53:25 -0800, Corey Hickey wrote next:
I suspect you will want to use your MeGUI frontend, so I'll just give you a relatively compact unix-style command that you can translate easily.
--- for i in vpass=1:turbo vpass=2 ; do mencoder matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -sws 9 -ovc lavc \ -lavcopts vcodec=mpeg4:vbitrate=581:mbd=2:mv0:trell:cbp:\ precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:v4mv:\ last_pred=2:vqcomp=0.6:vmax_b_frames=2:qpel:$i \ -ofps 24000/1001 -o mpeg4.avi done ---
You're sure about unix-style command? Maybe something that can be executed under cmd.exe will be better? If they don't know/understand what ";" and "\" are, they'll become quite irritated at converting it to windows format. I suspect they will mention mencoder's "unfriendliness" to a "common user" in review, so their job should be simplified as much as possible. The only thing I want to mention about quality is that probably mpeg_quant option will give better results, or since we know what exactly will be encoded and target bitrate, maybe even more specific quantization tables should be used, like kvcd and such. Many good ones are distributed with xvid. If you've got no time, at least please check mpeg_quant out. In my experience, it helps both on high and low bitrates. -- Vladimir
Re, 2005/12/9, Vladimir Mosgalin <mosgalin@vm10124.spb.edu>:
You're sure about unix-style command? Maybe something that can be executed under cmd.exe will be better? If they don't know/understand what ";" and "\" are, they'll become quite irritated at converting it to windows format.
I'm pretty sure, that doom9 will understand these. and cmd sucks: - I am not aware of any nice way to "break lines". - The "for" statement can only be used on files (not on arbitrary strings) To keep it short, the only cmd-useable way to do this, is to send a ready-made Batch (.bat) file, which is also a bad idea, since readability suffers a lot. My opinion: Leave it like it is. Doom9 will understand and the mail is not meant as user tutorial.
I suspect they will mention mencoder's "unfriendliness" to a "common user" in review, so their job should be simplified as much as possible. One could offer to write a user-friendly version of this stuff. But that exactly is, what Doom9 started his MeGUI-project for :) (Or, why I started my humble MeWiG-project.... ;) )
Greets, hco
Am Freitag, 9. Dezember 2005 11:42 schrieb Hans-Carl Oberdalhoff:
Re,
2005/12/9, Vladimir Mosgalin <mosgalin@vm10124.spb.edu>:
You're sure about unix-style command? Maybe something that can be executed under cmd.exe will be better? If they don't know/understand what ";" and "\" are, they'll become quite irritated at converting it to windows format.
I'm pretty sure, that doom9 will understand these.
I think for i in vpass=1:turbo vpass=2 ; do mencoder [...]$i done is quite advanced syntax (for a normal Windows user). What's the delimiter for "i"? Is it ":"," " or ";"? Each of those would result in different mencoder commandlines if one would not know how the bash works. Why not just two individual mencoder lines? This should be more easy to understand: mencoder matrix.vob [...]qpel:vpass=1:turbo -o del.avi mencoder matrix.vob [...]qpel:vpass=2 -o mpeg4.avi Regards, Matthias
Matthias Wieser wrote:
You're sure about unix-style command? Maybe something that can be executed under cmd.exe will be better? If they don't know/understand what ";" and "\" are, they'll become quite irritated at converting it to windows format.
I'm pretty sure, that doom9 will understand these.
I think
for i in vpass=1:turbo vpass=2 ; do mencoder [...]$i done
is quite advanced syntax (for a normal Windows user). What's the delimiter for "i"? Is it ":"," " or ";"? Each of those would result in different mencoder commandlines if one would not know how the bash works.
Why not just two individual mencoder lines? This should be more easy to understand:
mencoder matrix.vob [...]qpel:vpass=1:turbo -o del.avi mencoder matrix.vob [...]qpel:vpass=2 -o mpeg4.avi
Doom9 is actually the developer of MeGUI, a windows frontend to mencoder. I don't think the syntax will be a problem, but just to be sure I'll write it both ways. The main reason I want to keep the "for i in" is to emphasize what is different between the two command lines. -Corey
Am Freitag, 9. Dezember 2005 21:22 schrieb Corey Hickey:
Matthias Wieser wrote:
Why not just two individual mencoder lines? This should be more easy to understand:
mencoder matrix.vob [...]qpel:vpass=1:turbo -o del.avi mencoder matrix.vob [...]qpel:vpass=2 -o mpeg4.avi
Doom9 is actually the developer of MeGUI, a windows frontend to mencoder.
You are right! Matthias
Vladimir Mosgalin wrote:
The only thing I want to mention about quality is that probably mpeg_quant option will give better results, or since we know what exactly will be encoded and target bitrate, maybe even more specific quantization tables should be used, like kvcd and such. Many good ones are distributed with xvid.
I tested mpeg_quant and it had a significant drop in both PSNR and quality. I'd be interested in testing the kvcd tables, but I have to leave right now. -Corey
On Fri, Dec 09, 2005 at 04:23:44AM -0800, Corey Hickey wrote:
Vladimir Mosgalin wrote:
The only thing I want to mention about quality is that probably mpeg_quant option will give better results, or since we know what exactly will be encoded and target bitrate, maybe even more specific quantization tables should be used, like kvcd and such. Many good ones are distributed with xvid.
I tested mpeg_quant and it had a significant drop in both PSNR and quality. I'd be interested in testing the kvcd tables, but I have to leave right now.
mpeg_quant is good at high quality/high bitrates. at the insanely low bitrate at which this test is being performed, i think it will only hurt.. rich
Hi Rich Felker! On 2005.12.09 at 12:59:56 -0500, Rich Felker wrote next:
I tested mpeg_quant and it had a significant drop in both PSNR and quality. I'd be interested in testing the kvcd tables, but I have to leave right now.
Yes, PSNR comparison doesn't work here. If the quality is actually worse, though, don't use it.
mpeg_quant is good at high quality/high bitrates. at the insanely low bitrate at which this test is being performed, i think it will only hurt..
You know, I thought this way too, and only used it at bitrates of 1.5-2.5mbit/s. But when I tried some low-bitrate (700-800kbit/s) encodes, I found out mpeg_quant gives better results even in that case, both on high-motion and still scenes. On some frames it's hard to tell which one is actually better, but at least it's not worse. All in all, after testing it on some different material, I came to conclusion that mpeg_quant always gives better results (haven't checked out very low bitrates, though). But maybe it's just my eyes. -- Vladimir
Corey Hickey wrote:
All right, everybody. I've tested pretty much everything I can. Here's a draft of the email I will send to Doom9. Please read it carefully -- I don't know as much about some parts as I do others.
[snip]
I suspect you will want to use your MeGUI frontend, so I'll just give you a relatively compact unix-style command that you can translate easily.
--- for i in vpass=1:turbo vpass=2 ; do mencoder matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -sws 9 -ovc lavc \ -lavcopts vcodec=mpeg4:vbitrate=581:mbd=2:mv0:trell:cbp:\ precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:v4mv:\ last_pred=2:vqcomp=0.6:vmax_b_frames=2:qpel:$i \ -ofps 24000/1001 -o mpeg4.avi done ---
sorry for intervening so late, but I wonder if you tested the effect of chroma motion estimation (*cmp += 256)
On Friday 09 December 2005 14:11, Nico Sabbi wrote:
sorry for intervening so late, but I wonder if you tested the effect of chroma motion estimation (*cmp += 256)
Man page says it doesn't work with b frames?
Jan Knutar wrote:
sorry for intervening so late, but I wonder if you tested the effect of chroma motion estimation (*cmp += 256)
Man page says it doesn't work with b frames?
I did try it for snow, however, in the early stages where I was working on a several-minute clip. The result was a 0.01 dB drop in PSNR, a 75% increase in encoding time, and no result on quality that I could discern. -Corey
On Fri, Dec 09, 2005 at 04:21:35AM -0800, Corey Hickey wrote:
Jan Knutar wrote:
sorry for intervening so late, but I wonder if you tested the effect of chroma motion estimation (*cmp += 256)
Man page says it doesn't work with b frames?
I did try it for snow, however, in the early stages where I was working on a several-minute clip. The result was a 0.01 dB drop in PSNR, a 75% increase in encoding time, and no result on quality that I could discern.
chroma motion est should not be useful unless you have a movie where significant moving objects are textured only in chroma and their luma channel is constant. (i.e. the same movies that would make little sense to a colorblind user) rich
Hello, After much testing and deliberation, I present to you the best encoding and decoding options I can come up with at this time. Please let me know if you have any trouble; I'll try to stay in contact as much as possible via email. Part 1: general The mencoder binaries you usually use will suffice: http://www.aziendeassociate.it/cd.asp?dir=/mplayer I have tested with what is currently the latest build, dated 2005-11-23. For playback, use ffdshow. I have tested with this build: http://cutka.szm.sk/ffdshow-20051129.exe Media Player Classic build 6487 works for me: http://prdownloads.sourceforge.net/guliverkli/mpc2kxp6487.7z?download I notice that in the faq for your 2004 comparison, you specify that noise added in postprocessing is disallowed. Please let me know if that is not still the case; I can provide parameters for adding a bit of noise that slightly improves perceptual quality. The video bitrates in the following commands are based on the email you sent me earlier; feel free to tweak them as needed to suit whichever container you mux into. Part 2: FFmpeg MPEG-4 This set of options to mencoder are tuned for quality, not speed, in almost every way. The only quality-oriented option left out is qns=2; this has a noticeable effect, but most of the benefits are concealed by postprocessing and in this case it isn't worth the drop in performance. I suspect you will want to use your MeGUI frontend, so I'll just give you a relatively compact unix-style command that you can translate easily. Or, if you prefer, scroll down to part 4 to see a separate command for each pass. --- for i in vpass=1:turbo vpass=2 ; do mencoder matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -sws 9 -ovc lavc \ -lavcopts vcodec=mpeg4:vbitrate=581:mbd=2:mv0:trell:cbp:\ precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:v4mv:\ last_pred=2:vqcomp=0.6:vmax_b_frames=2:qpel:$i \ -ofps 24000/1001 -o mpeg4.avi done --- The only difference between the first and second pass (besides vpass, of course) is that the first pass uses turbo. For playback, I suggest using ffdshow's "mplayer" processing method with "Accurate deblocking" enabled. Leave processing strength at the default. Part 3: FFmpeg snow Snow has a lot fewer options to tweak, at this point. All these options for snow are tuned for quality. See part 4 for a separated set of commands. --- for i in vpass=1:vqscale=2.15 vpass=2:vbitrate=581 ; do mencoder matrix.vob -aid 128 -oac copy \ -vf crop=718:356:0:60,scale=640:272 -sws 9 -ovc lavc \ -lavcopts vcodec=snow:vstrict=-2:cmp=1:subcmp=1:mbcmp=1:\ qpel:vqcomp=0.6:$i -ofps 24000/1001 -o snow.avi done --- The first pass is done with a constant quantizer that approximates the bitrate used in the second pass. For playback, no postprocessing is needed. I haven't had any success with getting Media Player Classic to play MP4Box-muxed MP4 files with snow video. In the event your favorite AVI muxer doesn't understand snow either, you can use the following mencoder command: mencoder snow.avi -audiofile audio.mp3 -mc 0 -noskip \ -ovc copy -oac copy -o snow-final.avi Again, feel free to adjust the bitrate of the second pass to suit the container. You don't need to mess with vqscale for such small adjustments. Part 4: separated commands Just in case these are easier for you to interpret. My mail program is going to break them up into several lines, so put everything between the "---"s together. MPEG-4 pass 1: --- mencoder matrix.vob -aid 128 -oac copy -vf crop=718:356:0:60,scale=640:272 -sws 9 -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=581:mbd=2:mv0:trell:cbp:precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:v4mv:last_pred=2:vqcomp=0.6:vmax_b_frames=2:qpel:vpass=1:turbo -ofps 24000/1001 -o mpeg4.avi --- MPEG-4 pass 2: --- mencoder matrix.vob -aid 128 -oac copy -vf crop=718:356:0:60,scale=640:272 -sws 9 -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=581:mbd=2:mv0:trell:cbp:precmp=2:cmp=2:subcmp=2:predia=2:dia=2:preme=2:v4mv:last_pred=2:vqcomp=0.6:vmax_b_frames=2:qpel:vpass=2 -ofps 24000/1001 -o mpeg4.avi --- snow pass 1: --- mencoder matrix.vob -aid 128 -oac copy -vf crop=718:356:0:60,scale=640:272 -sws 9 -ovc lavc -lavcopts vcodec=snow:vstrict=-2:cmp=1:subcmp=1:mbcmp=1:qpel:vqcomp=0.6:vpass=1:vqscale=2.15 -ofps 24000/1001 -o snow.avi --- snow pass 2: --- mencoder matrix.vob -aid 128 -oac copy -vf crop=718:356:0:60,scale=640:272 -sws 9 -ovc lavc -lavcopts vcodec=snow:vstrict=-2:cmp=1:subcmp=1:mbcmp=1:qpel:vqcomp=0.6:vpass=2:vbitrate=581 -ofps 24000/1001 -o snow.avi --- Part 5: thanks The following people helped me out on the MPlayer mailing lists: Michael Niedermayer Dominik 'Rathann' Mierzejewski Guillaume POIRIER Rich Felker Hans-Carl Oberdalhoff Martin Collins Matthias Wieser Jan Knutar RC Stefan Gürtler Vladimir Mosgalin Also, many thanks are due to all the MPlayer and FFmpeg authors, especially Michael Niedermayer, who wrote a large portion of the encoding parts of both programs and fixed a few bugs I threw at him in the course of this evaluation. -Corey Hickey
participants (12)
-
Corey Hickey -
Dominik 'Rathann' Mierzejewski -
Guillaume POIRIER -
Hans-Carl Oberdalhoff -
Jan Knutar -
Martin Collins -
Matthias Wieser -
Michael Niedermayer -
Nico Sabbi -
RC -
Rich Felker -
Vladimir Mosgalin