Field order wrong for DV HD

[Dan]

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)

[Dan]

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;

}

[Carl Eugen Hoyos]

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.

[Dan]

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.

[Carl Eugen Hoyos]

The ftp server has no file size limit.

[Carl Eugen Hoyos]

Were you able to upload a sample?

[Michael Niedermayer]

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)

[Aleksandr]

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

[Carl Eugen Hoyos]

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).

[Carl Eugen Hoyos]

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?

[Carl Eugen Hoyos]

Remuxed sample without fiel atom

[Carl Eugen Hoyos]

Original cut sample with fiel atom replaced by free atom

[Aleksandr]

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.

[Aleksandr]

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.

[Aleksandr]

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.

[Carl Eugen Hoyos]

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?

[Aleksandr]

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.

[Carl Eugen Hoyos]

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

[Aleksandr]

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.

[Carl Eugen Hoyos]

Possibly related sample from ​http://ffmpeg.org/pipermail/libav-user/2017-May/010366.html:
​http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket5092/

[Balling]

This should be fixed after (as author says) ​https://github.com/FFmpeg/FFmpeg/commit/33203a08e0a26598cb103508327a1dc184b27bc6
​https://patchwork.ffmpeg.org/patch/15031/

though there is a problem with 16:9 when you open it in ffplay... (in particular the one file from #1307). Which is a problem.