[FFmpeg-user] ffmpeg architecture question

[Mark Filipak]

I'm hooking into this to reply in order to get the message below into the thread.

But first, I'd like to say that I had no idea this would be controversial. I asked whether ffmpeg 
traversed filter complexes recursively because that was not happening. Apparently it does recurse, 
but only if you connect certain pads to certain other pads. Specifically, it depends on how you 
'wire up' a 'blend' filter. I learned that from Michael Koch after he suggested that I reverse the 
connections to the 'blend' filter. It worked and instead of getting 80% of the input frames in the 
output, I got 100% of the frames (minus a couple of frames, but that doesn't matter). I will be 
conducting experiments to determine what are the 'magic' pads. In the meantime, I spoke with an 
engineer...

I just got off the phone with a video production engineer who's very familiar with ffmpeg and who 
graciously requested the call to attempt to straighten me out. I didn't ask him for permission to 
mention his name, so I don't.

Regarding soft telecine:
According to the engineer -- and I have no reason to doubt him; I take what he says as gospel -- 
ffmpeg decoders are compliant and therefore always output 30fps, interlaced (per the metadata flags) 
even though you and I know the content is actually progressive.

Now I begin to understand why pdr0 is so focused on detelecine. I am not explicitly detelecining, 
but apparently, ffmpeg is detelecining as a first step. I'm thinking about that and trying to reason 
out how that affects what I'm doing, or indeed, whether it affects what I'm doing at all.

Regarding 55-telecine:
 From the above, and from 'telecine=pattern=5', it's clear to me now that ffmpeg is doing the following:

Step 1: Unpackage the p24 packets, decode the pictures, and output i30 via 23-telecine.

Step 2: Detelecine the i30 back to p24. Okay, that reconstructs the 'pictures' (as 'pictures' are 
defined in the MPEG spec) -- Caveat: Provided that the metadata read by the decoder is correct 
(which is not always true, and is the reason for the '-analyzeduration' and '-probesize' directives 
(options, if you prefer) -- which I always understood and have used, e.g., "-analyzeduration 
5000000000 -probesize 5000000000").
Sanity check: Am I correct so far?

Step 3: Apply 'telecine=pattern=5' to obtain 60fps with frames = A A A+B B B.

...and I'm right back where I started, to wit: Frames that are duplicated and, for the center frame, 
combed. So what have I learned? I'm not sure, maybe nothing.

The result looks beautiful on a 60Hz TV. The samples I've made so far have PTS failures at about 
2:30 running time, but I can't see how those failures are related to 55-telecine. And I don't 
understand why my explorations are worthless and a waste of time.

It seems to me that whether a decoder outputs p24 or i30 is moot. It does come as a surprise that 
the decoder honors the metadata flags and therefore outputs i30. Given that, I understand how bogus 
metadata would result in failure -- I have 2 DVDs from a fellow in South Korea via ebay that have 
bad metadata. They're soft telecined but the metadata is wrong:

frames.frame.0.interlaced_frame=1 <- should be '0'
frames.frame.0.top_field_first=0
frames.frame.0.repeat_pict=1
frames.frame.1.interlaced_frame=0
frames.frame.1.top_field_first=1
frames.frame.1.repeat_pict=0
frames.frame.2.interlaced_frame=1 <- should be '0'
frames.frame.2.top_field_first=1
frames.frame.2.repeat_pict=1
frames.frame.3.interlaced_frame=0
frames.frame.3.top_field_first=0
frames.frame.3.repeat_pict=0

but I'm not transcoding from those discs.