White line in top macroblock of dvvideo

[Carl Eugen Hoyos]

​http://thread.gmane.org/gmane.comp.video.ffmpeg.user/47955
A user uploaded a dvvideo sample (made with Quantel server) that shows a white line in the top macroblock (near to the sun) that is apparently not supposed to be there.

$ ffmpeg -i dv5p-from-quantel-server_white-line-on-decode.dv -vframes 1 out.jpg
ffmpeg version N-56404-g4d09d2e Copyright (c) 2000-2013 the FFmpeg developers
  built on Sep 18 2013 09:55:31 with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl
  libavutil      52. 44.100 / 52. 44.100
  libavcodec     55. 31.101 / 55. 31.101
  libavformat    55. 17.100 / 55. 17.100
  libavdevice    55.  3.100 / 55.  3.100
  libavfilter     3. 86.100 /  3. 86.100
  libswscale      2.  5.100 /  2.  5.100
  libswresample   0. 17.103 /  0. 17.103
  libpostproc    52.  3.100 / 52.  3.100
[dv @ 0x2520880] Estimating duration from bitrate, this may be inaccurate
Input #0, dv, from 'dv5p-from-quantel-server_white-line-on-decode.dv':
  Metadata:
    timecode        : 09:59:50:00
  Duration: 00:00:00.32, start: 0.000000, bitrate: 57600 kb/s
    Stream #0:0: Video: dvvideo, yuv422p, 720x576 [SAR 64:45 DAR 16:9], 57600 kb/s, 25 tbr, 25 tbn, 25 tbc
    Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s
[swscaler @ 0x250a680] deprecated pixel format used, make sure you did set range correctly
Output #0, image2, to 'out.jpg':
  Metadata:
    timecode        : 09:59:50:00
    encoder         : Lavf55.17.100
    Stream #0:0: Video: mjpeg, yuvj422p, 720x576 [SAR 64:45 DAR 16:9], q=2-31, 200 kb/s, 90k tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (dvvideo -> mjpeg)
Press [q] to stop, [?] for help
frame=    1 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A
video:31kB audio:0kB subtitle:0 global headers:0kB muxing overhead -100.068504%

[Carl Eugen Hoyos]

QT 10.2 plays the sample without the white line.

[Christophe]

For info, the sequence is SD 4:2:2, and the strange blocks are all coded as 2x4x8 (as in interlaced), ie dct_mode=1 at dvdec.c:205

By using factor_table as if it was dct_mode=0, the decoded result looks much better. It is possible that the quantization scale derivation is wrong in case of 4:2:2. I couldn't decipher what to make of section 5.3/figure 28/table 23 here, and the whole code is somewhat hard to follow.

This is strange also because nobody ever complained about 4:2:0 interlaced, and this also uses the quantization scale derivation I'm talking about.

[Christophe]

The error is indeed in the weight table for interlaced blocks, and should impact the decoding of any such content. I haven't checked the encoder.

On the other hand, the weight tables for 8x8 and 2x4x8 (non-HD) have values somewhat diverging from the mathematical ones. I wonder if that would be related to simple idct, but on the other hand they are not the inverse of what the encoder use.

[Carl Eugen Hoyos]

The problem with the keyword dvdec is that all other dvvideo-related tickets use dvvideo.

[Michael Niedermayer]

Replying to cehoyos:

The problem with the keyword dvdec is that all other dvvideo-related tickets use dvvideo.

yes but this is also an issue in the dv _DECODER_ and dvvideo AFAIK is not decoder specific, so adding dvdec makes sense IMO

[Christophe]

Well, sorry for the fuss. That's why I *added* the keyword, as I can understand that filtering using a specific keyword is within your work habits. It's hard to figure at first glance what rationale would apply here for adding keywords. If that's such a big deal, maybe having a whitelisted set (if trac supports it)?

But, like Michael stated, my intent with it was to indicate indeed the module having the issue. It should not impact the encoder (it has a separate table) and it's specifically in the decoder (and not generic code for idct or bitstream reading or...).

I understand also that keywords may become obsolete/wrong depending on code refactoring, but it sounded fair here.

[Carl Eugen Hoyos]

My only concern is that if you click on the dvdec keyword on this page, you (or actually anybody else who is also interested) may believe that there is exactly one ticket related to the dv decoder (and that there never has been another ticket) which is not the case. Or in other words: I believe the keyword feature of trac is very helpful but only if great care is taken when setting the keywords. I have seen other trac installations where an enormous number of keywords is added for each ticket: I can only use the full text search there...
Note that I am neither claiming that my choice of keywords was always good nor that I didn't make many mistakes when setting them: Just that adding an additional dv-related keyword doesn't improve the keyword-situation (on the contrary). That this ticket is not encoder-related seems less important to me.
And you actually working on a ticket that I hardly understand is of course much more important than my trac-related concerns!

[Carl Eugen Hoyos]

The "whitelist" is ​https://trac.ffmpeg.org/tags which has a link tags on top of this page. As said it does not claim to be complete or even stringent but I consider it a useful list.

[Christophe]

I think I have fixed this particular issue, but as this causes several other questions to pop up, I'll need more time before submitting the related series of patches. Just a heads up in case anyone was looking at that code.

[Michael Niedermayer]

Fixed by Christophe Gisquet in 6fe02d25ee6816e44de8d8b23b6905d307e1ed28