Opened 3 years ago

Last modified 12 months ago

#5092 open defect

Field order wrong for DV HD

Reported by: Dan203 Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords: dvvideo
Cc: michael, Aleksandr_Slobodeniuk Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

The field order (i.e. topfield first) is wrong for DV HD video. It's actually due to a stupid change they made to the spec. The bits in the VAUX are the same but their meaning changed. In SMPTE 314M, which is for SD, field 2 refers to the even fields and field 1 refers the odd fields. But in SMPTE 370M, which is for HD, field 1 refers to the even fields and field 2 refers to the odd fields. So if the FS bit in the VAUX is 1 it means BFF in SD but TFF in HD.

So we need a line in the code to flip the TFF flag if the file is HD. (the current code parses it according to the SMPTE 314M spec regardless of resolution)

Attachments (3)

sop_DVCProHD_cut.mov (2.4 MB) - added by cehoyos 21 months ago.
sop_DVCProHD_test.mov (2.4 MB) - added by cehoyos 21 months ago.
Remuxed sample without fiel atom
sop_DVCProHD_test2.mov (2.4 MB) - added by cehoyos 21 months ago.
Original cut sample with fiel atom replaced by free atom

Change History (22)

comment:1 Changed 3 years ago by Dan203

This should fix it...

/* Determine the codec's field order from the packet */
if ( *vsc_pack == dv_video_control ) {

s->frame->top_field_first = !(vsc_pack[3] & 0x40);

Reference field order is reversed in SMPTE 370M spec for HD
if (s->sys->height > 625)

s->frame->top_field_first = !s->frame->top_field_first;

}

comment:2 Changed 3 years ago by cehoyos

  • Priority changed from important to normal

Please either:

  • Send a patch made with git format-patch to the FFmpeg development mailing list that fixes the issue you see.

or

  • Provide both a sample that allows to reproduce the issue you want to report and the command line that allows to reproduce the issue and the complete, uncut console output of current FFmpeg git head to make this a valid ticket.

comment:3 Changed 3 years ago by Dan203

I don't know how to create a patch.

I have sample files that demonstrate the issue but they are big. About 1GB each so I'm not sure where I could put them for you.

comment:4 Changed 3 years ago by cehoyos

The ftp server has no file size limit.

comment:5 Changed 3 years ago by cehoyos

Were you able to upload a sample?

comment:6 Changed 3 years ago by michael

The suggested change does not compile
"libavcodec/dvdec.c:552:13: error: assignment of member ‘top_field_first’ in read-only object"

I think the change is based on a old version of FFmpeg

Also can you quote the 2 specs where the interpretation of the bit differs ?
(this will make it easier to verify that the change is correct)

comment:7 Changed 3 years ago by michael

  • Cc michael added

comment:8 Changed 21 months ago by Aleksandr_Slobodeniuk

Example DVCProHD file, recorded as TFF, and shown in some popular players (Edius, Adobe Premiere, Final Cut) as TFF, but decoded with ffmpeg as BFF:

AVFrame->interlaced_frame = 1
AVFrame->top_field_first = 0

https://www.datafilehost.com/d/c4313cdb

Last edited 21 months ago by Aleksandr_Slobodeniuk (previous) (diff)

comment:9 follow-up: Changed 21 months ago by cehoyos

  • Cc Aleksandr_Slobodeniuk added
  • Component changed from undetermined to avcodec
  • Keywords dvvideo added
  • Version changed from unspecified to git-master

How did you test this?
I ask because FFmpeg correctly shows tff here on the console and correctly uses tff when using a deinterlacer (tested with yadif).

Changed 21 months ago by cehoyos

comment:10 follow-up: Changed 21 months ago by cehoyos

I attached a sample for testing sop_DVCProHD_test.mov.
Can you test if popular players (Edius, Adobe Premiere, Final Cut) interpret this file as TFF or BFF?

Changed 21 months ago by cehoyos

Remuxed sample without fiel atom

Changed 21 months ago by cehoyos

Original cut sample with fiel atom replaced by free atom

comment:11 in reply to: ↑ 9 Changed 21 months ago by Aleksandr_Slobodeniuk

Replying to cehoyos:

How did you test this?
I ask because FFmpeg correctly shows tff here on the console and correctly uses tff when using a deinterlacer (tested with yadif).

By watching

AVFrame->interlaced_frame

and

AVFrame->top_field_first

in the debugger, and watching how they're filling in libavcodec/dvdec.c :

/* Determine the codec's sample_aspect ratio from the packet */
    vsc_pack = buf + 80 * 5 + 48 + 5;
    if (*vsc_pack == dv_video_control) {
        apt    = buf[4] & 0x07;
        is16_9 = (vsc_pack[2] & 0x07) == 0x02 ||
                 (!apt && (vsc_pack[2] & 0x07) == 0x07);
        ff_set_sar(avctx, s->sys->sar[is16_9]);
    }

    if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
        return ret;
    frame->interlaced_frame = 1;
    frame->top_field_first  = 0;

    /* Determine the codec's field order from the packet */
    if ( *vsc_pack == dv_video_control ) {
        frame->top_field_first = !(vsc_pack[3] & 0x40);
    }

The situation is strange, because SMPTE 370m and 314m tells about bit (vsc_pack[3] & 0x40), that:

FS: First/second field flag
FS indicates a field which is delivered during the field one period.
0 = Field 2 is delivered; 1 = Field 1 is delivered.

FF FS Output field
1  1  Field 1 and field 2 are output in this order (1,2 sequence)
1  0  Field 2 and field 1 are output in this order (2,1 sequence)
0  1  Field 1 is output twice
0  0  Field 2 is output twice

same for both 1080 system and 720 system.

This is actually not what ffmpeg does:

frame->top_field_first = !(vsc_pack[3] & 0x40);

but this code works correctly for dv sd files.

comment:12 Changed 21 months ago by Aleksandr_Slobodeniuk

for 720 system it tells:

For the 720-line system (see table 17)
FS indicates a video frame which is delivered during the video frame one period.
0 = Video frame 2 is delivered.
1 = Video frame 1 is delivered.

Table 17 – FF/FS for the 720-line system
FF FS Output video frame
1  1  Video frame 1 and video frame 2 are output in this order (1,2 sequence).
1  0  Video frame 2 and video frame 1 are output in this order (2,1 sequence).
0  1  Video frame 1 is output twice.
0  0  Video frame 2 is output twice.

but this is for 720p (smpte 370m), not 720i.

comment:13 in reply to: ↑ 10 ; follow-up: Changed 21 months ago by Aleksandr_Slobodeniuk

Replying to cehoyos:

I attached a sample for testing sop_DVCProHD_test.mov.
Can you test if popular players (Edius, Adobe Premiere, Final Cut) interpret this file as TFF or BFF?

sorry, I can check it only visual, now I understand I couldn't say they "interpret file as TFF". All I can say, they show fields correctly.
I have remuxed sop_DVCProHD_test.mov into avi (with -vcodec copy) and watched in Adobe Premiere. The fields are still shown correctly. So, this is not because of the container's priority.

comment:14 in reply to: ↑ 13 ; follow-up: Changed 21 months ago by cehoyos

Replying to Aleksandr_Slobodeniuk:

Replying to cehoyos:

I attached a sample for testing sop_DVCProHD_test.mov.
Can you test if popular players (Edius, Adobe Premiere, Final Cut) interpret this file as TFF or BFF?

sorry, I can check it only visual

Is it possible to test the two files I attached visually or are they too short?

comment:15 Changed 21 months ago by cehoyos

  • Status changed from new to open

comment:16 in reply to: ↑ 14 Changed 21 months ago by Aleksandr_Slobodeniuk

Replying to cehoyos:

Is it possible to test the two files I attached visually or are they too short?

What you want to know wrom this test - is if Adobe Premiere gets field interlace from the container. So, answering this question I have tested the whole video with avi container, that doesn't store field interlace information. The video was shown correctly.

comment:17 Changed 19 months ago by cehoyos

Feel free to explain what ffmbc does, feel free to add links, please do not post code under license stricter than LGPL here.

comment:18 Changed 19 months ago by Aleksandr_Slobodeniuk

useful information from ffmbc:
commit "dvenc: correctly set interlaced and tff bits"
https://github.com/bcoudurier/FFmbc/commit/736133a20bf6fab65b06f447e07b6b91fcdc0270

take a look at dv.c:459.

ffmbc does exactly what author of this bug were writing about: when it's decoding HD, it flips "fs" flag.

Unfortunately, I can't find the explanation of this action in SMPTE.

Last edited 19 months ago by Aleksandr_Slobodeniuk (previous) (diff)
Note: See TracTickets for help on using tickets.