Hi On Fri, 2006-11-24 at 11:19 +0100, stefan wrote: > 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.
That'll be *very* much appreciated (if not the tests themselves, then just a complete recipe for reproducing your results). > 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... No disagreement here. I do think this is a valid benchmark for a codec. However, whenever such tests do occur I think it is quite important to use decoder and encoder from the same codec. I've seen people doing such tests with a decoder taken from libdv and encoder taken from FFmpeg. > FUD? I am not sure I want to discuss visual-quality with someone who > refers me to FUD in the first reply... I apologize for my, somewhat poor choice of words, but unfortunately my biggest problems with convincing folks to adopt (or at least try!) ffmpeg's DV codec has been that somebody in a position of an expert on a particular occasion assessed its quality as being poor. I do think it is unfair, especially in cases where the person has either used and older release or unclear metrics. In your particular case, your status on this list definitely puts you in such a position. Whether to call it FUD or something else -- I don't know perhaps FUD is too strong a word, but as long as the bottom line is people shying aways from FFmpeg's DV codec I can't help but feel pretty strongly about it. Hope you can understand it. > I beg your pardon, young man, but I am, indeed, young ;-) but then again, not knowing your age it all might seem quite backwards in perspective ;-) > I do think your words are somewhat a little bit insulting... Hopefully you can understand my reasons for calling it that from the statement I've just made. If you didn't mean it that way -- I must say that I've been wrong and I do beg you pardon. I definitely *do* want to continue our conversation, especially if it has any potential of improving things with FFmpeg's DV codec. > 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? So please provide a way to comapre it with others! That's all I really want. I have no problem with folks saying FFmpeg's DV codec produces inferior compared to codec 'Y' when I do 'X'. I hope you can appreciate my reasons. > "bunch of statements like..." ??? I'm sorry but I think you're overreacting. If really want to know the two statements that jumped at me were: "hmm, great? Great would be something which allows for reencoding 10 times and is still hard to see..." "BTW: the mpeg2 encoder in ffmpeg is fast, yes... but not good either..." And yes I do think it was unfair to FFmpeg to say that without substantiating your claims. Especially given the high esteem lots of folks hold you in on this list. > 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? I try not to. Please consider my reply to you a poorly worded solicitation for proof of the two statements I've quoted above. > 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...) That all might very well be true, but could you, please post an URL where I can get the same material you've been experimenting with and also post an exact ffmpeg's version and a complete command line you've used. Thanks, Roman. ------------------------------------------------------------------------- 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
