[Mplayer-cvslog] CVS: main/libmpcodecs vd_ffmpeg.c,1.108,1.109

Michael Niedermayer michaelni at gmx.at
Tue Nov 11 00:06:32 CET 2003


Hi

On Monday 10 November 2003 22:53, Roberto Togni wrote:
> 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?
hmm, mplayers image types suck, sorry for complaining, it seems not cleanly 
solveable
IMHO leave the IP(B) stuff with buffer_hints=0 for now

[...]
>
> > 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.
its sub-optimal only if the player supports direct rendering but doesnt 
support CR style buffers, but that case is already suboptimal, so we dont 
loose much IMHO

>
> Anybody against it? Should i implement it or do we have to discuss it
> on ffmpeg-dev?
hmm, i CC this to ffmpeg-dev, its off-topic here anyway

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en



More information about the MPlayer-cvslog mailing list