[MPlayer-users] detc not working

[D Richard Felker III]

On Fri, Feb 28, 2003 at 10:31:01PM -0500, mplayer at interlinx.bc.ca wrote:
> > Probably not. Like I said, I don't think it will display properly on
> > an actual TV,
> 
> Even if the original 24fps is recovered and it's re-telecined, either
> off-line or during playback?  BTW, as an aside, any idea if MPEG4 (as
> in libavcodec or otherwise) supports the TFF/RFF flags of MPEG2?  Or
> is there any alterative method of storing 24fps content for display on
> NTSC in MPEG4?

I meant as-is. If you recover the original 24 fps, then re-telecine,
it should be fine. BTW, since the telecine in your movie seems to have
been applied as a final step (rather than before editing), it should
be possible to reverse it without any auto-detection, just assuming
the telecine frames come at regular intervals. vf_detc is supposed to
be able to do this, but there's no way to enable the behavior right
now because it's all in an experimental state. It shouldn't be too
hard to hack the code if you want to do that, though...

However, it still probably needs the flip filters before and after.

> > BTW, if you notice, the chroma channels are still interlaced in a few
> > frames even with this 'fix'... :(
> 
> I have not noticed.  I did not try detc on this stream because I got
> the impression you had to make some code changes (that are not in CVS)
> to get even the -vop flip,scale,detc,flip to work.  Should this VOP
> stream work with what's in CVS?

I didn't make any changes specifically for this. I'm just saying I
made a few improvements to the interlacing detection code, so it's
possible that the copy in CVS right now isn't good enough to detect
the interlacing. However, it should be fine.

> BTW: I want to go look closer and see if I can reconize that the
> telecine inverted the fields for future reference.  

Use -v. Normally, with telecine, you have one frame where "even" drops
very low, then a frame where both "even" and "odd" are high, then a
frame where "odd" is drops low. (These numbers represent the amount of
change in the even and odd fields from the previous frame.) In your
file, the opposite happens -- "odd" drops, then both go high, then
"even" drops.

Rich