[MPlayer-users] detc not working

[D Richard Felker III]

On Fri, Feb 28, 2003 at 07:50:07PM -0500, mplayer at interlinx.bc.ca wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]

> On Fri, Feb 28, 2003 at 04:27:43PM -0500, D Richard Felker III wrote:
> > [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> > On Fri, Feb 28, 2003 at 04:10:38PM -0500, Brian J. Murrell wrote:
> > > 
> > > [ offlist until there is something people will be even remotely
> > > interested in reading about... ]
> > 
> > ALWAYS keep mplayer mail on list!!!
> 
> Well, sure.  I dont' care where I reply but I thought I would save the
> rest from the chit-chat and just followup with an answer.  But
> whatever, it don't matter to me.

Yes, but replying direct to me fills my (non-mplayer) main inbox
(which is already overflowing) with more clutter, and makes it
difficult to keep mail organized by threads. Most of the other
developers feel the same, I think.

> > Hmm, this file is very weird.
> 
> Yeah?  Funny thing is I have some broadcast television which does not
> seem to want to "detc" either.  Same effect.  2 good frames, 2
> interlaced frames...

That just means it's failing to sync to the telecine at all, so it's
just dropping 1 frame out of every 5 to keep the framerate right. Try
running with -v to see detc's telecine tracking in action. Frame -1
means it's not synced to telecine and operating in progressive (drop
1/5) mode. Frame 0-2 are the 'clean' frames in the telecine sequence,
and frames 3 and 4 are the two interlaced ones. You also get to see
the metrics detc is using to try to find the telecine pattern.

BTW, the changes I mentioned to detc aren't in CVS yet. I've been
playing around a lot with alternative algorithms trying to find what
works best, and the original code in CVS has worked better than almost
all the other algorithms I've tried. I am working on a "2pass"
version, though, which should definitely give better results.

> > I'm trying to figure out what's been
> > done. It looks like a weird/broken/nonstandard sort of telecine...
> 
> :-)
> 
> On Fri, Feb 28, 2003 at 04:45:48PM -0500, D Richard Felker III wrote:
> > 
> > BTW, this looks like an SVCD...
> 
> Indeed it does.  It's been sized to fit a CD so you are most probably
> correct.  My guess is that it was "hard" telecined by whatever
> software ripped it from the DVD.

Hmm. Any idea what software might have been used? My guess is that
some broken windows program did the telecine in RGB-space, without
realizing that windows RGB images are stored upside-down... It would
be nice if we knew what software so we could report this nonsense to
the author, to prevent more bad encodes like this in the future...

> > I imagine it will look REALLY bad,
> 
> It was juddery but I just chalked that up to a weak CPU.

That sounds like it might be caused by the backwards telecine.

> > since the telecine seems to be done backwards (pretending the bottom
> > frame comes before the top one).
    ^^^^^
> 
> Interesting.

Oops I meant to say field. I think you understood, though.

> > BTW, the following command line plays
> > it mostly right, at least with a few changes I've made to detc:
> > 
> > mplayer -vop flip,scale,detc,flip ...
> 
> Any plans to make detc detect and deal with this anomoly?  In CVS yet?
> I just did an update and it didn't touch vf_detc.c.

Probably not. Like I said, I don't think it will display properly on
an actual TV, and it requires messing around with lots of the logic to
get it right. Maybe I'll add a hack for it if I find an easy way,
though.

BTW, if you notice, the chroma channels are still interlaced in a few
frames even with this 'fix'... :( So the software that telecined it
probably did something really broken...

> > The scale filter is just there to prevent a segfault. :)
> 
> Nice.  :-)

Hmm, it'd be nicer if I knew why the segfault was happening... :(

Maybe detc doesn't work right when the output image's stride is
negative...

Rich