No more interlacing when resizing Quicktime files

[GoogleCodeExporter]

What steps will reproduce the problem?
1. take a image sequence in input
2. convert the sequence to Uncompressed 8 or 10 bits Quicktime file whith 
resize from HD (1080) to SD (PAL)
3. indicate -tff (top field first in my case)

What is the expected output? What do you see instead?

When monitoring on a TV, the SD quicktime (720x576 PAL 16:9) is no more 
interlaced (i see the two fields in the same time). But with the same command 
line, without resizing (still in HD), no problem

What version of the product are you using? On what operating system?

FFmbc version 0.7-rc4, MacOS X 10.6.8

Please provide any additional information below:

- Full commandline run (with -v 3) and everything the program printed
without
the repeating parts.

command line :

ffmbc -i 
/Volumes/prod-3d/Images_3d/I2011_TDF2012_OCT/02_Etapes_2D/E07/E_07_%04d.tga 
-tff -f mov -vcodec rawvideo -pix_fmt uyvy422 -s 720x576 -aspect 16:9 -vtag 
2vuy uncompressed4.mov -r 25 -v 3
FFmbc version 0.7-rc4
Copyright (c) 2008-2011 Baptiste Coudurier and the FFmpeg developers
Input #0, image2, from 
'/Volumes/prod-3d/Images_3d/I2011_TDF2012_OCT/02_Etapes_2D/E07/E_07_%04d.tga':
  Duration: 00:00:16.00, start: 0.000000, bitrate: N/A
    Stream #0.0(und): Video: targa, bgr24, 1920x1080p, 25.00 fps
[scale @ 0x100e00e20] w:1920 h:1080 fmt:bgr24 -> w:720 h:576 fmt:uyvy422 
flags:0x4
Output #0, mov, to 'uncompressed4.mov':
  Metadata:
    encoder: FFmbc 0.7
    Stream #0.0(und): Video: rawvideo, uyvy422, 720x576i tff [PAR 64:45 DAR 16:9], 165888 kb/s, 25.00 fps
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop, [?] for help
frame=  389 fps= 22 q=0.0 size=  315090kB time=00:00:15.56 
bitrate=165888.0kbits/s eta=00:00:00.50    
[mov @ 0x101000c00] color primaries unspecified, assuming bt470bg
frame=  400 fps= 22 q=0.0 Lsize=  324002kB time=00:00:16.00 
bitrate=165889.2kbits/s    
video:324000kB audio:0kB global headers:0kB muxing overhead 0.000743%

ffmbc -i on the result file : 

FFmbc version 0.7-rc4
Copyright (c) 2008-2011 Baptiste Coudurier and the FFmpeg developers
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/Users/3d/uncompressed3.mov':
  Metadata:
    major_brand: qt  
    minor_version: 0
    compatible_brands: qt  
    creation_time: 2011-11-16 15:19:20
    encoder: FFmbc 0.7
  Duration: 00:00:16.00, start: 0.000000, bitrate: 165889 kb/s
    Stream #0.0(eng): Video: rawvideo, uyvy422, 720x576i tff, 165888 kb/s, PAR 64:45 DAR 16:9, 25.00 fps
    Metadata:
      codec_name: rawvideo
At least one output file must be specified

- Upload your sample somewhere and supply url

https://www.wetransfer.com/dl/TEHVdMS6/19e6345af8e35328578f999614b3b3425f884a988
762bb04998179ccd9f6bdcce345090b1a2c873

Original issue reported on code.google.com by nkir...@gmail.com on 16 Nov 2011 at 3:47

[GoogleCodeExporter]

With thanks to MDSH...

Command changes between FFmbc 0.6 and FFmbc 0.7

Interlaced aware scaling

If you require interlaced aware scaling and you are using FFmbc 0.7 then add 
:interl=1 to the end of any -vf scale command to enable interlaced aware 
scaling.
This is a change from previous FFmbc versions, which previously required only 
:1 to be added the the end of a -vf scale command.

Non-interlaced aware scaling:

-vf scale=720:576

or

-vf scale=720:576:interl=0

Force Interlaced scaling:

-vf scale=720:576:interl=1

Use interlaced scaling if the input is interlaced:

-vf scale=720:576:interl=-1

Flagging interlaced material

If you are encoding interlaced material it is important that you flag it as 
such. This allows the encoder to optimise its encoding for interlaced material, 
and stops encoders from optimising out interlaced detail.

If you are encoding Top Field First (SD D10, all interlaced HD, and many 
others) then use the encoding parameter -tff

If you are encoding Bottom Field First (SD DV, SD NTSC, and a few others) then 
use the encoding parameter -bff

You DO NOT need to use the -flags +ildct+ilme parameters any more. Setting -tff 
or -bff automatically enables those parameters.

REMEMBER: always flag interlaced media as interlaced!

Video format conversion

Often we are changing the video format during our conversions. For instance; a 
DV to IMX30, an MPEG2 to IMX30, or an MPEG4 to IMX30 are all very likely to 
require a 420 to 422 conversion. It is important to use and interlaced aware 
video format converter if you are making these format changes.

The video filter scale=0:0:interl=1 is used in the examples below as an 
interlaced video format converter. It does not scale (0 means use the incoming 
video width/height) but by placing a video filter like this in strategic places 
in the video filter chain they will be used to do format conversions. If a 
format change is required, and FFmbc cannot reuse a video filter like this, 
then FFmbc will insert a non-interlaced aware scale video filter. That can ruin 
your video's chroma.

Examples

SD 'PAL' to IMX30

If you know your input file is tff 720x576 25 fps then I think this is about 
the minimum for a conversion to Quantel IMX30:

ffmbc -i <720x576 input> \
 -vf scale=0:0:interl=1 \
 -target imx30 -tff 
 -y <output>

If you know your input file is 720x576 25 fps but don't know it if's tff then I 
think this is about the minimum for a conversion to Quantel IMX30:

ffmbc -i <720x576 input> \
 -vf scale=0:0:interl=1,fieldorder=tff,scale=0:0:interl=1 \
 -target imx30 -tff \
 -y <output>

SD 'PAL' to DVCPROHD

If you know your input file is tff 720x576 25 fps then I think this is about 
the minimum for a conversion to FCP compatible DV100:

ffmbc -i <720x576 input> \
 -vf crop=702:576:9:0,colormatrix=bt601:bt709,scale=1440:1080:interl=1 \
 -vcodec dvvideo -tff -pix_fmt yuv422p -aspect 16:9 \
 -acodec pcm_s16le -ac 2 -ar 48000 \
 -f mov -y <output.mov>

Original comment by bevan...@gmail.com on 23 Nov 2011 at 11:45

[GoogleCodeExporter]

Thank you very much!
i think i never found the answer without your comment!

I'll try that as soon as possible

Original comment by nkir...@gmail.com on 24 Nov 2011 at 8:13

[GoogleCodeExporter]

This should not be considered an issue

Original comment by baptiste...@gmail.com on 12 Jan 2012 at 5:51

• Changed state: Invalid