[libdv-dev] DV encoder improvements

[Roman S. <rv...@su...>]

I've just commited quite a lot of changes to the CVS and I'd like to
share what I've learned while evaluating how my implementation of
the DV encoder compares to the libdv's one. I don't think I've screwed
up in any major way in my evaluation, but since this is the first time
I try to compare different video codecs I could have. Therefore all
corrections will be greatly appreciated. Especially if there's anything
in my use of libdv that makes it suboptimal. 

Here's what I used:
    
    * latest ffmpeg CVS
    * libdv from the CVS HEAD.
    * testbed application from the attachment.
    * pond.dv as a source for raw YUV422 video data ( /tmp/test.yuv )

and here's what I found:

  1. The good news is that we seem to be on par with libdv at least
     as far as Intel platform is concerned. The numbers I get on
     my 1.4Ghz Intel system are:

      $ ./test 1 /tmp/test.yuv
      iter| libdv mse|libdv PSNR| avlib mse|avlib PSNR
         0|  8.905604| 38.634171|  4.738306| 41.374573
      
      libdv enc| libdv dec| avlib enc| avlib dec
            329|       197|       307|         0
    
     As you can see we are doing it a bit faster than libdv does: 307 < 329.
 
     We actually seem to have higher PSNR but it's where comparison
     gets a bit twisted. Since there's no (or at least I don't know 
     of any) interface to the libdv that permits extracting raw
     unmodified video from the DV stream we have to take into 
     account pix_fmt conversions. Which means that ffmpeg really
     has higher PSNR than above, and libdv is probably not that bad
     either.
  
  2. The second piece of good news is, actually, a bit surpsing to me. And
     I will appreciate libdv developers giving me any insights. Here's 
     what I get when I try to do 5 recode iterations over each frame:

     $ ./test 5 /tmp/test.yuv
     iter| libdv mse|libdv PSNR| avlib mse|avlib PSNR
        0|  8.905604| 38.634171|  4.738306| 41.374573
        1| 14.288144| 36.581047|  4.738306| 41.374573
        2| 19.104561| 35.319431|  4.738306| 41.374573
        3| 23.657274| 34.391155|  4.738306| 41.374573
        4| 28.130415| 33.639042|  4.738306| 41.374573

     libdv enc| libdv dec| avlib enc| avlib dec
          1309|       907|      1563|         0

     
     Surprisingly enough, libdv degrades with each iteration, but gets faster 
     and faster at the same time. This is puzzling.
   
Of course I would also like to encourage people to try all these changes out
and report as many bugs as possible. Personally, I'll try to do just that
over the Thanksgiving break.

Happy Thanksgiving everyone!

Thanks,
Roman.