[FFmpeg-devel] [PATCH] Generic part of frame multithreading

[Uoti Urpala]

On Thu, 2008-08-21 at 17:10 +0200, Michael Niedermayer wrote:
> On Thu, Aug 21, 2008 at 02:22:00PM +0300, Uoti Urpala wrote:
> > Direct rendering allowed the buffer callback hacks. Is that what you
> > mean? 
> 
> I mean that lavc supported reordering timestamps. Maybe it needed 5 more lines
> of code than now but it was supported.

It would have needed significantly more in that case (for reasons like
needing varying other callback functionality for direct rendering, and
already using the opaque field for that). IMO it's inconsistent to
complain about related things being "hacky" but claim the buffer
callback hacks were not problematic.

> > What I'm "complaining" about are your claims that what I did with the
> > available API was particularly hacky or ugly, when in fact you could do
> > no better yourself and even defended similar usage earlier.
> 
> What i meant was that your attempts to count buffers is hacky as such
> not how this buffer counting is done.

You mean you consider trying to find out the current decoder delay
somehow "hacky" regardless of implementation? It's quite normal
information IMO. I already explained the rationale for using a pts
reordering buffer with that size a couple of mails ago.

> > Sure void * does have negative sides, which is why having the other
> > types as alternatives is a good thing. However it is IMO not safe to
> > assume that the other types will always be enough for everyone, and when
> > they're not supporting void * directly is less ugly than the
> > alternatives.
> 
> Its not my goal to make things enough for everyone, theres alway an odd
> guy with a CRAY-1 in his basement who might have different needs.
> My goal is to find a compromise between simplicity and features. And make
> useage easy and straightforward for the majority. void * in this specific
> case is going to cause bugs when the user application is not carefull ...

Having void * as an alternative makes usage no less easy for the majority.

> using void* successfully requires the user to understand the internal buffer
> handling so he doesnt loose his pointers, these problems are not worth the
> merely hypothetical gain of being more generic.

Yes you need to be more careful if you use void * with allocated memory.
But you do need something like that if you have more than 64 bits of
data per frame. And in that case not having support for void * only adds
even _more_ complexity. You can't make all user data fit into one data
type by not supporting the others. You're not helping reduce complexity,
you're only burying your head in the sand and denying that complexity
exists.

> > > of course if you do want a union of double and int64_t then iam not opposed
> > > to approve a patch
> > 
> > What would you need the patch for? Seems like a trivial change.
> 
> Iam not planing to implement your feature request for you, if you want it
> send a patch that passes review.

What would you expect from a patch except the obvious changes (which
should take no longer to write from scratch than review and apply from a
patch)?