VP6F Libavcodec decoding bug (slowly accumulating artifacts)

[TSR]

Hello,
Here's a report for a FLV4/VP6 Libavcodec decoding bug.
A sample is here: ​http://videoff7.free.fr/sample_artefact.flv
(also tentatively attached to this ticket).

As the video progresses, PQ becomes worse and worse, it can be seen easily on the newscaster's face 10 seconds in.

I tested with DShow based decoders (FFDShow/LAV) and also with mplayer2, all on Windows. The issue shows up with all of them.

No such issue happens when decoding with the original On2 VP6 directshow decoder [ ​http://videoff7.free.fr/On2_VP6_Decoder.zip ].

Thank you for your support.

[TSR]

I couldn't attach the file directly, too big, I'll keep it on my server as long as needed.

[Carl Eugen Hoyos]

Not a regression, afaict (see issue 965).

ffmpeg -i sample_artefact.flv -q:v 2 -an out.avi
ffmpeg version N-40448-g16b9156 Copyright (c) 2000-2012 the FFmpeg developers
  built on May  7 2012 16:44:46 with gcc 4.3.2
  configuration: --cc=/usr/local/gcc-4.3.2/bin/gcc --enable-gpl
  libavutil      51. 49.100 / 51. 49.100
  libavcodec     54. 19.100 / 54. 19.100
  libavformat    54.  4.100 / 54.  4.100
  libavdevice    53.  4.100 / 53.  4.100
  libavfilter     2. 72.104 /  2. 72.104
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 11.100 /  0. 11.100
  libpostproc    52.  0.100 / 52.  0.100
Input #0, flv, from 'sample_artefact.flv':
  Metadata:
    creationdate    : Fri Oct 29 19:33:39 2010
                    :
    lastkeyframetimestamp: 540632
    lasttimestamp   : 544207
    On2             : Technologies
  Duration: 00:02:36.19, start: 0.000000, bitrate: 508 kb/s
    Stream #0:0: Video: vp6f, yuv420p, 596x336, 30 tbr, 1k tbn, 1k tbc
    Stream #0:1: Audio: mp3, 44100 Hz, mono, s16, 48 kb/s
[buffer @ 0x8f3f160] w:596 h:336 pixfmt:yuv420p tb:1/1000000 sar:0/1 sws_param:flags=2
Output #0, avi, to 'out.avi':
  Metadata:
    creationdate    : Fri Oct 29 19:33:39 2010
                    :
    lastkeyframetimestamp: 540632
    lasttimestamp   : 544207
    On2             : Technologies
    ISFT            : Lavf54.4.100
    Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 596x336, q=2-31, 200 kb/s, 30 tbn, 30 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (vp6f -> mpeg4)
Press [q] to stop, [?] for help
frame= 3193 fps=118 q=2.0 Lsize=   28060kB time=00:01:46.43 bitrate=2159.8kbits/s
video:27978kB audio:0kB global headers:0kB muxing overhead 0.292999%

$ ffmpeg -i bleeding_pixelated_video.flv -q:v 2 -an out.avi
ffmpeg version N-40448-g16b9156 Copyright (c) 2000-2012 the FFmpeg developers
  built on May  7 2012 16:44:46 with gcc 4.3.2
  configuration: --cc=/usr/local/gcc-4.3.2/bin/gcc --enable-gpl
  libavutil      51. 49.100 / 51. 49.100
  libavcodec     54. 19.100 / 54. 19.100
  libavformat    54.  4.100 / 54.  4.100
  libavdevice    53.  4.100 / 53.  4.100
  libavfilter     2. 72.104 /  2. 72.104
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 11.100 /  0. 11.100
  libpostproc    52.  0.100 / 52.  0.100
Input #0, flv, from 'bleeding_pixelated_video.flv':
  Duration: 00:00:24.59, start: 0.000000, bitrate: 3330 kb/s
    Stream #0:0: Video: vp6f, yuv420p, 640x368, 25 tbr, 1k tbn, 1k tbc
    Stream #0:1: Audio: mp3, 44100 Hz, stereo, s16, 64 kb/s
[buffer @ 0x8f6d920] w:640 h:368 pixfmt:yuv420p tb:1/1000000 sar:0/1 sws_param:flags=2
Output #0, avi, to 'out.avi':
  Metadata:
    ISFT            : Lavf54.4.100
    Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 640x368, q=2-31, 200 kb/s, 25 tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (vp6f -> mpeg4)
Press [q] to stop, [?] for help
frame=  411 fps= 60 q=2.0 Lsize=   21966kB time=00:00:16.48 bitrate=10919.1kbits/s
video:21951kB audio:0kB global headers:0kB muxing overhead 0.070154%

[TSR]

Hi, has there been any advancements regarding this bug?

[compn]

email google and ask them to open up vp6.

iirc they didnt have time to clean it up when i asked a few years ago , maybe they have time now.

[ami_stuff]

I think that I can notice the same problem (at the end of the video - grass) with vp60 and vp61 samples which I created, while vp62 sample seems to decode much better:

​http://www.datafilehost.com/d/11dfad91

[Carl Eugen Hoyos]

I don't think the issue is reproducible with vp62.avi, mplayer -vc vp6 can be used to compare.

[pross]

ffmpeg output is different to the reference decoder for all files here (vp60, vp61 & vp61)

there are actually two bugs:

1. a subtle inter-frames drift, affecting all files.

2. loop filter is applied incorrectly, affecting vp61 & vp62.

[Carl Eugen Hoyos]

Fixed by Peter Ross in d8ebfd1bdf7e2c47af3eb057b97de5b7fe854e35