Setting [in] and [out] in a filter is incompatible with setting a target of pal-imx30

[GoogleCodeExporter]

Simple example, include in a command line "-vf '[in]null[out]' -target 
pal-imx30" will cause the filter chain to complain that there are 'Not enough 
inputs specified for the "scale" filter'.

It's because specifying -target -pal-imx30 appends 
",scale=720:576,pad=720:608:0:32:black:1" into the filters (ffmbc.c line 4685).

If [in] and [out] are already pinned to the null filter, as demonstrated above, 
then that creates an impossible filter chain. 

Original issue reported on code.google.com by mark.him...@gmail.com on 27 Mar 2011 at 6:23

[GoogleCodeExporter]

Thanks for the report, will be fixed in next release.

Original comment by baptiste...@gmail.com on 28 Mar 2011 at 10:35

[GoogleCodeExporter]

This should be fixed in rc4, can you please double check ?

Original comment by baptiste...@gmail.com on 1 May 2011 at 12:57

[GoogleCodeExporter]

Confirmed fixed in 0.6-rc4, because you have removed the automatic addition of 
the scale,pad filters. A much more deterministic result :-)

Original comment by mark.him...@gmail.com on 3 May 2011 at 3:59

[GoogleCodeExporter]

Yes, I'm trying to figure what's the best way to handle this case.

Original comment by baptiste...@gmail.com on 4 May 2011 at 10:33

[GoogleCodeExporter]

This issue has returned in later versions of rc4 and rc5 - all be it that the 
target is imx30 not pal-imx30. I've applied locally a fix (taken from previous 
rc4 versions) which includes [out] at the start of the opt_vf() calls on lines 
4744 4746 of ffmbc.c

The problem I have is that I want to use a command line line this -vf 
"tinterlace=4,scale=702:576:1,colormatrix=bt709:bt601,pad=720:608:9:32" and I 
do not expect "scale=720:576,pad=720:608:0:32:black:1" to be added at the end 
because that really breaks my encode (scaling the carefully created 720x608 
back down to 720:576 and padding again up to 720x608).

Thanks.

Original comment by mark.him...@gmail.com on 9 May 2011 at 1:53

[GoogleCodeExporter]

I'm curious here, why are you scaling to 702:576 ? This doesn't make sense if 
you are coming from HD, given that the production aperture is the full 
resolution.

Original comment by baptiste...@gmail.com on 9 May 2011 at 7:39

[GoogleCodeExporter]

Can you try with the updated tarball ? I tried to come up with a more elegant 
solution.

Original comment by baptiste...@gmail.com on 10 May 2011 at 5:39

[GoogleCodeExporter]

I'm scaling to 702 because it PAL land 702 pixels is the active area of the 720 
pixels of a full line. If you scale to 720 then everything is 2.5% too wide.

The maths behind that is...

In the analogue world, a PAL TV line is 64 micro-seconds long, of which 52 
micro-seconds is active picture and the rest is sync-pulse.

Digital PAL television is sampled at 13.5MHz.
That makes the active 52 micro-seconds have exactly 702 pixels 
(0.000052×13500000).

The BBC used to have page explaining it, but it's been taken down in the 
great-BBC-web-site-clean-up of 2011, so here's a link to the archive machine:

http://replay.web.archive.org/20100826080627/www.bbc.co.uk/commissioning/tvbrand
ing/picturesize.shtml

Original comment by mark.him...@gmail.com on 10 May 2011 at 12:56

[GoogleCodeExporter]

I tried with the new 0.6-rc5 tarball. It looks like a nice idea, but it 
seg-faults if I have any filter in the chain.

ffmbc -i ~/Videos/full_sony_ex1r_set/mpeg2_35mbit_1280x720_25p.mp4 -vf 
crop=720:576:0:0 -threads 4 -r 25 -target imx30 -f d10_mxf -y 475_0032_01.mxf
FFmbc version 0.6-rc5
Copyright (c) 2008-2011 Baptiste Coudurier and the FFmpeg developers
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 
'/home/himslm01/Videos/full_sony_ex1r_set/mpeg2_35mbit_1280x720_25p.mp4':
  Metadata:
    major_brand: mp42
    minor_version: 0
    compatible_brands: mp42
    creation_time: 2010-09-30 08:39:13
  Duration: 00:00:31.88, start: 0.000000, bitrate: 36170 kb/s
    Stream #0.0(eng): Video: mpeg2video, yuv420p, 1280x720p [PAR 1:1 DAR 16:9], 35000 kb/s, 25.00 fps
    Stream #0.1(eng): Audio: pcm_s16be, 48000 Hz, 2 channels, s16, 1536 kb/s
[crop @ 0x9179600] auto-inserting filter 'auto-inserted scaler 0' between the 
filter 'src' and the filter 'Parsed filter 0 crop'
[scale @ 0x9179f90] w:1280 h:720 fmt:yuv420p -> w:1280 h:720 fmt:yuv422p 
flags:0x4 interlaced:0
[crop @ 0x9179600] w:1280 h:720 -> w:720 h:576
auto-rescaling to IMX resolution
[scale @ 0x91882a0] w:720 h:576 fmt:yuv420p -> w:720 h:576 fmt:yuv422p 
flags:0x4 interlaced:1
[pad @ 0x9188670] w:720 h:576 -> w:720 h:608 x:0 y:32 color:0x108080FF[yuva]
Warning, QMAT_SHIFT is larger than 21, overflows possible
    Last message repeated 1 times
Output #0, mxf_d10, to '475_0032_01.mxf':
  Metadata:
    encoder: FFmbc 0.6
    Stream #0.0(und): Video: mpeg2video, yuv422p, 720x608i tff [PAR 19:18 DAR 5:4], cbr, 30000 kb/s, 25.00 fps
    Stream #0.1(und): Audio: pcm_s16le, 48000 Hz, 2 channels, s16, 1536 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
  Stream #0.1 -> #0.1
Press [q] to stop encoding
Stream #0.1 dropping frames before start time
Segmentation fault

Original comment by mark.him...@gmail.com on 10 May 2011 at 1:03

[GoogleCodeExporter]

Mark, could you please share your input file ? Also you don't need -f with 
-target, it will auto-select d10 if target is specified.

Original comment by baptiste...@gmail.com on 10 May 2011 at 7:52

[GoogleCodeExporter]

Thanks for the hints.
Link to the original media sent in private email

Original comment by mark.him...@gmail.com on 11 May 2011 at 11:40

[GoogleCodeExporter]

Should be fixed in rc7

Original comment by baptiste...@gmail.com on 7 Jun 2011 at 3:47

[GoogleCodeExporter]

Original comment by baptiste...@gmail.com on 15 Jun 2011 at 3:06

• Changed state: Fixed