[MPlayer-G2-dev] extra dr types (oh no not more!! :)

[D Richard Felker III]

On Sat, May 17, 2003 at 06:40:45PM +0200, Arpi wrote:
> > Probably most of this can be done by other methods without too much
> > performance loss, tho, so maybe it's all nonsense. :)
> 
> imho we should avoid this kind of hacks in g2, at least for now.

OK, sounds fine.

> btw, about interlacing.
> i'm thinking of interlacing support in vf layer, and so in codecs/vo too.
> it would mean a 'field' parameter in mpi, 0=frame 1=top 2=bottom field.
> if both vo, codec and filters inbetween supports fields, then codec could
> decode per field and pass fields to vo, without 'interlacing them together'.

Yes, definitely. In addition, for interlaced fields paired into
frames, there should be codes for bff and tff. For real 60 or 50 fps
content, this is just nonsense of the way the mpeg2 is encoded. But
for pulldown content, bff/tff really means something regarding the way
the frames are done. In order to have filters that gracefully handle
all the different cases (see samurix_detc.avi) without tons of user
intervention, I think we need to have bff/tff flags, or at least a
mode where the decoder outputs fields (in order).

BTW, if the decoder inherently outputs fields, and mplayer has to have
code to interleave those fields, I think it makes much more sense to
move the interleaving OUT of the vd_* driver(s) and into its own
vf_interleave or something. Then, based on user settings, we could
auto-insert vf_interleave or else output translated/interpolated
fields to the vo driver (with another filter) at 50/60 fps. This also
allows scaling, denoising, sharpening, etc. of interlaced content to
work without having to wrap the other filters in il=i:i and il=d:d.

In reality, I think the ONLY time you'd want vf_interleave is when
encoding interlaced video with a codec that expects interleaved
fields, or when displaying on TVout. All other times, it'd be better
to have the fields independent.

> btw 2, i'm thinking about a bigger change of the codec/vfilter layer,
> by dropping away mpi->type (MP_IMGTYPE_*) 'buffering templates' and
> introduce get_buffer/release_buffer style (already used in libavcodec).
> but i'm not sure if it's a really good idea...

Perhaps explain how that would work in all the existing image type
cases... I'm not so sure it's a good idea either -- it's harder to
optimize buffer allocation when you don't know in advance how many
buffers you'll need.

Rich