[MPlayer-users] detc not working

[mplayer at interlinx.bc.ca]

On Fri, Feb 28, 2003 at 08:50:55PM -0500, D Richard Felker III wrote:
> 
> 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.

I hear ya.  Fair enough.

> 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.

That is what I thought.

> 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.

Oh cool.  I will have to do that the next time I get some telecined
material from broadcast.

> 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.

OK.

> I am working on a "2pass"
> version, though, which should definitely give better results.

Cool.

> Hmm. Any idea what software might have been used?

None at all.  I d/led this sucker off of Usenet at some point.

> My guess is that
> some broken windows program did the telecine in RGB-space, without
> realizing that windows RGB images are stored upside-down...

That could do it.

> 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...

Sorry.  No idea.  :-(

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

Yeah, the more I look at it, the more I think that this is the case
and it's not just random judder.  It would be nice to recover the
original 24fps stream from this sucker and re-telecine it (during
playback would be sweet :-) properly.

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

Yeah, I got it.  :-)

> 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?

> 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'... :(

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?

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

> So the software that telecined it
> probably did something really broken...

Seems like it.

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

:-)

b.

-- 
Brian J. Murrell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20030228/08c919e2/attachment.pgp>