[Mplayer-cvslog] CVS: main/libmpcodecs vd_ffmpeg.c,1.108,1.109
Roberto Togni
r_togni at tiscali.it
Mon Nov 10 22:53:22 CET 2003
On 2003.11.10 01:52, Michael Niedermayer wrote:
> Hi
>
> On Monday 10 November 2003 00:56, Roberto Togni CVS wrote:
> [...]
[...]
> this will break if IP(B) style codecs set buffer_hints, which they
> dont
> currently, but they should
My point in this patch was to enable codecs i'm moving to ffmpeg to get
the correct buffer type, while taking all efforts not to break anything
for existing codecs. That's why i coded the patch in this way, so that
codecs that do not set buffer hints have their buffer allocated in the
old way.
I can modify some other codecs (like huffyuv or mjpeg) to take
advantage of the new scheme, but i don't know how to handle IP(B)
codecs. I assume that the person that will modify IPB codecs to use
buffer hints will also take care of updating vd_ffmpeg.
I can do it, but someone have to tell me how to do it. Is it enough to
set preserve and readable for I and P frames (so they get a static
buffer) and nothing for B frames (to get a non readable temp buffer)?
That sounds logic, but does not mimic the current behaviour. Or do we
need some other kind of hints to allocate a MP_IMGTYPE_IPB buffer?
>
> btw, i would prefer if we would add a reget_buffer() function instead
> of
> missuseing get_buffer() for CR buffers
Ok for me. But we have to set for a solution ASAP, because the number
of codecs that have to be modified and tested with every change is
increasing.
> the default reget_buffer() could simply reuse the buffer if its
> FF_BUFFER_TYPE_INTERNAL and call get_buffer(), memcpy(),
> release_buffer() if
> its FF_BUFFER_TYPE_USER
> that would also avoid the cr_available negotiation and emulation in
> every
> codec if cr_available == 0
That's sub-optimal when the codec can easily know which portions of the
picture didn't change, but surely it's simpler that the current
solution.
Anybody against it? Should i implement it or do we have to discuss it
on ffmpeg-dev?
> Michael
Ciao,
Roberto
More information about the MPlayer-cvslog
mailing list