Roman Shaposhnik schrieb: >> hmm, great? Great would be something which allows for reencoding 10 >> times and is still hard to see... >> > > I guess I find it a bit hard to parse this particular statement. Are > you referring to a particular degradation of a quality you've observed > or is it just a bit of FUD on your part ? > Yes, I do refer to massive quality-loss I have observed in such an "encoder-stress-test". I can, if you wish, do this test again. Last time I did it, none(!) of the free codecs passed it -- worst being libdv. Ffmpeg being way better, but still far away from good ... (but I must admit this is slightly over a year ago... so perhaps ffmpeg will pass it this time? I don't know...)
Why such a multiple-encoding-stress-test? Well, most applications do encode any transition, any change of the material over and over again. So you have a little quality loss, with every encoding. Five to ten re-encodings are typical for video-editing... FUD? I am not sure I want to discuss visual-quality with someone who refers me to FUD in the first reply... I beg your pardon, young man, but I do think your words are somewhat a little bit insulting... > Once again, I'm CCing Dan Maas who once compared the *latest* DV > encoder with Apple's. And if memory serves me right the comparison > was in terms of quality (although, Dan -- please correct me if > I'm wrong). > I would not compare with Apple's DV-Encoder (which has bad chroma-problems on re-encoding-tests). BTW: you can find some other stress-test here (*not* done by me, including the Apple DV-Codec): http://www.adamwilt.com/pix-stress.html after 5 iterations the results of all encoders are not good, but the Apple Encoder reaches (on my visual scale) the worst possible place... I *bet* that ffmpeg is better than that! So, I do not understand what you want? I didn't say that ffmpeg is the worst encoder I know (This place clearly is given to libDV!). You seem to have not carefully read what I wrote: It is good. It is far better than libDV. It is just *not* the best DV-Encoder I know. So what? > If you compare this to the ffmpeg's DV codec you might notice that > not only we add things like DV50, etc. to it but we also take your > quality concerns very seriously. Given, of course, that you express > them in a conscious manner and not with a bunch of statements like the > above. > "bunch of statements like..." ??? you really should take more time to carefully choose your words. I always thought we would discuss technical aspects here on this list. These can be true or false, but I can't see they can be personal and leading to insulting statements?! So why do *you* get personal? > Once again -- Michael takes mpeg2 quality concerns quite seriously, > albeit with his usual somewhat rough attitude towards people simply > saying things without proof. If, on the other hand, you have a > particular criteria in mind you're mostly welcome to send it to > me in private or post it to the ffmpeg's mailing list. > Well, it produces visible blocks, even on a ridiculously low vqscale. I assume (I have not taken time to deeply investigate that - I rather than that used mpeg2enc...) that there is some quantizer-coefficient-elimination-step which just is acting to harsh. This was even more puzzling for me, as the bitrate at that particular sequence was far below the maximum limit and there was no way of getting the encoder to use a higher one. (ffmpeg was about 2MBit at that sequence while as mpeg2enc easily consumed 9MBit, but had no visible blocks...) > Thanks, > Roman. > dito. Stefan ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
