Opened 5 years ago

Closed 5 years ago

#6383 closed defect (fixed)

Incorrect scan type (AVI DV)

Reported by: laurfb Owned by: t.rapp
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 (15)

comment:1 by laurfb, 5 years ago

Keywords: dvvideo added

comment:2 by Carl Eugen Hoyos, 5 years ago

Component: avcodecavformat
Keywords: avi added; vprp chunk FieldPerFrame removed

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

comment:3 by laurfb, 5 years ago

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 by Carl Eugen Hoyos, 5 years ago

Keywords: dvvideo added; muxer removed

comment:5 by kieranjol, 5 years ago

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

comment:6 by kieranjol, 5 years ago

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

comment:7 by laurfb, 5 years ago

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

Last edited 5 years ago by laurfb (previous) (diff)

comment:8 by t.rapp, 5 years ago

It would be great to fix this but unfortunately the OpenDML 1.02 document isn't very clear to me on what to put in the field framing information of the "vprp" (video properties header) chunk. When looking for sample AVI files that contain a "vprp" chunk I haven't found an example either with two fields (except this sample which is invalid OpenDML structure and looks hand-crafted).

Does anybody have a sample file with "interlaced" information actually stored in the AVI container?

comment:9 by laurfb, 5 years ago

Hi. This is a DV file exported with Edius, correctly marked (and viewed by MediaInfo) as interlaced.

Hope this helps,

comment:10 by t.rapp, 5 years ago

Unfortunately the "pal_dv_Ok.avi" file does not contain field order information in the AVI container (i.e. there is no "vprp" chunk). I assume that MediaInfo displays the information of the coded DV frame instead.

You can verify whether some file contains a "vprp" chunk by using MediaTrace (included in MediaInfo).

Example: MediaInfo --Details=1 MyFile.avi

000010F4   Video properties (76 bytes)
000010F4    Header (8 bytes)
000010F4     Name:                               vprp
000010F8     Size:                               68 (0x00000044)
000010FC    VideoFormatToken:                    0 (0x00000000)
00001100    VideoStandard:                       0 (0x00000000)
00001104    VerticalRefreshRate:                 25 (0x00000019)
00001108    HTotalInT:                           720 (0x000002D0)
0000110C    VTotalInLines:                       576 (0x00000240)
00001110    FrameAspectRatio Height:             144 (0x0090)
00001112    FrameAspectRatio Width:              197 (0x00C5)
00001114    FrameWidthInPixels:                  720 (0x000002D0)
00001118    FrameHeightInLines:                  576 (0x00000240)
0000111C    FieldPerFrame:                       1 (0x00000001)
00001120    Field (32 bytes)
00001120     CompressedBMHeight:                 576 (0x00000240)
00001124     CompressedBMWidth:                  720 (0x000002D0)
00001128     ValidBMHeight:                      576 (0x00000240)
0000112C     ValidBMWidth:                       720 (0x000002D0)
00001130     ValidBMXOffset:                     0 (0x00000000)
00001134     ValidBMYOffset:                     0 (0x00000000)
00001138     VideoXOffsetInT:                    0 (0x00000000)
0000113C     VideoYValidStartLine:               0 (0x00000000)

The "FieldPerFrame: 1" line indicates that the video stream is progressive. An interlaced file would have "FieldPerFrame: 2" and two set of "Field (32 bytes)" information blocks.

in reply to:  8 comment:11 by Carl Eugen Hoyos, 5 years ago

Replying to t.rapp:

It would be great to fix this but unfortunately the OpenDML 1.02 document isn't very clear to me on what to put in the field framing information of the "vprp" (video properties header) chunk.

Sorry if I misunderstand: What is unclear about "one for progressive, two for interlaced"?

comment:12 by t.rapp, 5 years ago

The values for the following two field framing information blocks ("VIDEO_FIELD_DESC" in the OpenDML 1.02 document), especially the values for VideoYValidStartLine property.

comment:13 by Carl Eugen Hoyos, 5 years ago

Use either 0/1 or 0/(height/2) depending on which field comes first. It won't help waiting for a response.

comment:14 by t.rapp, 5 years ago

Owner: set to t.rapp
Status: newopen

comment:15 by t.rapp, 5 years ago

Resolution: fixed
Status: openclosed

Should be fixed with commit 26c0c84784f1f4e73e2de25b09b659781f06b0f2.

Note: See TracTickets for help on using tickets.