Opened 8 years ago
Closed 7 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 |
Description
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.
regards,
laur
Video samples
pal_dv_orig.avi - http://www76.zippyshare.com/v/HOF8lFAG/file.html
pal_dv_ffmpeg.avi - http://www76.zippyshare.com/v/8BY8dniE/file.html
Change History (15)
comment:1 by , 8 years ago
Keywords: | dvvideo added |
---|
comment:2 by , 8 years ago
Component: | avcodec → avformat |
---|---|
Keywords: | avi added; vprp chunk FieldPerFrame removed |
comment:3 by , 7 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.
regards,
laur
comment:4 by , 7 years ago
Keywords: | dvvideo added; muxer removed |
---|
comment:7 by , 7 years ago
Unfortunately ffmpeg always use the default scantype settings for AVI native format (mpeg4) regardless codec/settings used, marking clips as progressive.
follow-up: 11 comment:8 by , 7 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 , 7 years ago
Hi. This is a DV file exported with Edius, correctly marked (and viewed by MediaInfo) as interlaced.
http://www3.zippyshare.com/v/1aoB66zE/file.html
Hope this helps,
regards,
laur
comment:10 by , 7 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.
comment:11 by , 7 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 , 7 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 , 7 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 , 7 years ago
Owner: | set to |
---|---|
Status: | new → open |
comment:15 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | open → closed |
Should be fixed with commit 26c0c84784f1f4e73e2de25b09b659781f06b0f2.
Am I correct that this issue is not libavcodec-related?