[MPlayer-G2-dev] Rich's TODO

[D Richard Felker III]

On Thu, Jan 01, 2004 at 03:43:35AM +0100, Arpi wrote:
> Hi,
> 
> pre-note: here is already 2004, so time to get back to g2 development :)

:))

> notes for http://brightrain.aerifal.cx/~dalias/vp-in-progress/TODO:
> 
> vo2-vp wrapper
> ==============
> * remove and make vo drivers vp-native (?????)
> 
> NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
> OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!
> 
> my No.1 goal making g2 was to keep vo driver as simple and minimal
> as possible. they should not do more than knowing the underlaying driver
> or hardware, and exporting the resource.

No need to explain, I agree. All the ? marks there meant "is this
really a good idea?" and you're right that the answer is no. On the
other hand, the vo drivers need to be more intelligent in how they
provide buffers or we're going to run into trouble. The current method
is too naive...

> yes i know you hate wrappers, i also hate them, at least silly ones.

I hate wrappers when they just change the names of the functions and
structs and have no good reason to be there. For example in G1 we had
VFCTRL_* and VOCTRL_* which were identical, mappings between control
and query_format, and other nonsense which just complicated matters
for developers by introducing gratuitous differences between the
different api's. But if we can really make the vo api simple enough
that it can be wrapped nicely, I have no objection to using a wrapper.

> demuxers
> ========
> * convert to use rate_d/rate_m based pts rather than 1/rate_d
> already discussed, ok

Thanks!

> * clean up nonsense pts flags
> for example?

PTS_FOR_BLOCK doesn't seem to be used. (or useful?)
PTS_FOR_NEXT was only created because you misunderstood mpeg audio
pts, and you already said you were going to remove it.
PTS_IN_DISPLAY_ORDER is at least a confusing name, and might not even
be useful. (The framer could take care of the problem using DTS or
something...)
PTS_ACCURATE is kinda pointless. Why even set pts if it's likely to be
wrong? The framer should be able to give valid pts based on the last
known pts.

> * pts==0 is used to indicate "not available", this is broken. change!
> agree. i also found it broken, but it was too late then :)
> anyway i'm open for idea how to pass 'broken' value in an 'int' variable?
> (actually 'int' may be too limited for pts anyway)

Do you think it's too limiting to require pts to be nonnegative? Then
we could use -1 for invalid. If you'd prefer, we could have a flag for
whether pts is valid instead.

> * always seek to a point with known exact pts!
> why? for raw streams, you simply cannot do that. for example .mp3

Hmm, sounds like a job for runtime indexbuilder.

> * remove resync_audio_stream
> already discussed, i agree. it should even be done for g1 too.

:)

> * instead have seek be driven from vp/ap layer
> huh?

My idea was for seek requests to be passed back thru the vp or ap
layer (depending on whether the user has selected audio-based seeking
or video-based...maybe this is dumb) so that one could have vf_edl
(editlist) that does seeking on its own and intercepts seek requests
for transparent seeking in files with editlists. But maybe you think
this is dumb. IMO it could be added later without too much pain, so we
could leave it out for the time being anyway until we decide if it's a
good idea.

Rich