Opened 7 months ago

Last modified 7 weeks ago

#6383 new defect

Incorrect scan type (AVI DV)

Reported by: laurfb Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: avi dvvideo
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


Hi. I'm not sure if this is a normal behaviour or I'm doing something wrong.
I try to convert some videos to PAL DV AVI using ffmpeg-git (dvvideo encoder).
Always, checking resulted videos I found that mediainfo report AVI-DV as "Scan type: Progressive".
Even for simple avi dv to avi dv conversions.

Command used:
ffmpeg -i pal_dv_orig.avi -c:v dvvideo pal_dv_ffmpeg.avi

With mediainfo pal_dv_orig.avi is described as

"Scan type : Interlaced
Scan order : Bottom Field First"

while for the resulted video file (pal_dv_ffmpeg.avi) mediainfo report:

"Scan type : Progressive
Original scan type : Interlaced
Original scan order : Bottom Field First"

According to Jerome Martinez (Mediainfo developer) to whom I asked for help:

"You see the two lines with "Original", which means there is a conflict between container (AVI) metadata and stream (DV) metadata.
DV in "ffmpeg" has same scan type as DV in "orig" (Interlaced, BFF).
but "ffmpeg" AVI contains a "vprp" chunk (Video properties) with FieldPerFrame? of 1.
In your result file:
00010F4 Video properties (76 bytes)
00010F4 Header (8 bytes)
00010F4 Name: vprp
00010F8 Size: 68 (0x00000044)
00010FC VideoFormatToken?: 0 (0x00000000)
0001100 VideoStandard?: 0 (0x00000000)
0001104 VerticalRefreshRate?: 25 (0x00000019)
0001108 HTotalInT: 720 (0x000002D0)
000110C VTotalInLines: 576 (0x00000240)
0001110 FrameAspectRatio? Height: 9 (0x0009)
0001112 FrameAspectRatio? Width: 16 (0x0010)
0001114 FrameWidthInPixels?: 720 (0x000002D0)
0001118 FrameHeightInLines?: 576 (0x00000240)
000111C FieldPerFrame?: 1 (0x00000001)
0001120 Field (32 bytes)
0001120 CompressedBMHeight: 576 (0x00000240)
0001124 CompressedBMWidth: 720 (0x000002D0)
0001128 ValidBMHeight: 576 (0x00000240)
000112C ValidBMWidth: 720 (0x000002D0)
0001130 ValidBMXOffset: 0 (0x00000000)
0001134 ValidBMYOffset: 0 (0x00000000)
0001138 VideoXOffsetInT: 0 (0x00000000)
000113C VideoYValidStartLine: 0 (0x00000000)
(there is no "vprp" chunk in your "orig" file)
from specs
"Number of Fields Per Frame
One or two, depending on whether the video is interlaced or progressive"
Maybe I am wrong, but from my point of view "vprp" filling by FFmpeg is wrong for such interlaced content ("Number of Fields Per Frame" value should be 2 instead of 1), please ask FFmpeg developers for an argument about why "Number of Fields Per Frame" is 1 even for such interlaced content (maybe it means that both fields are in the same chunk? specs are not very explicit, I display what I understood from specs i.e. interlaced DV should use "2" for "Number of Fields Per Frame").
Note: in the same kind of issue, I see "25" for "refresh rate" and specs say "50 for PAL", but for frame rate I don't test this value for the moment.

So, is something about ffmpeg/dvvideo encoder, command used or mediainfo report is wrong?
Seems to be related on how ffmpeg pack DV stream in AVI container.


Video samples
pal_dv_orig.avi -
pal_dv_ffmpeg.avi -

Change History (7)

comment:1 Changed 7 months ago by laurfb

  • Keywords dvvideo added

comment:2 Changed 6 months ago by cehoyos

  • Component changed from avcodec to avformat
  • Keywords avi added; vprp chunk FieldPerFrame removed

Am I correct that this issue is not libavcodec-related?

comment:3 Changed 5 months ago by laurfb

  • Keywords muxer added; dvvideo removed

Hi. The problem seems to be related only to AVI muxer (the AVI muxers allways set scantype to "Progressive" even for interlaced content).

For example (comparing AVI and MOV containers):

ffmpeg -i test_in_file -c:v dvvideo out_file.MOV

always output files correctly marked (interlaced or progressive based on video stream properties)

while for AVI:
ffmpeg -i test_in_file -c:v dvvideo out_file.AVI

the output files is always marked as progressive even for interlaced dv video content.


comment:4 Changed 5 months ago by cehoyos

  • Keywords dvvideo added; muxer removed

comment:5 Changed 7 weeks ago by kieranjol

I just encountered this as well but with a different codec.

comment:6 Changed 7 weeks ago by kieranjol

I just encountered this as well but with a different codec.

comment:7 Changed 7 weeks ago by laurfb

Unfortunately ffmpeg always use the default scantype settings for AVI native format (mpeg4) regardless codec/settings used, marking clips as progressive.

Last edited 7 weeks ago by laurfb (previous) (diff)
Note: See TracTickets for help on using tickets.