On 2013-05-27 21:50:23 +0200, Anton Khirnov wrote: > > On Tue, 21 May 2013 10:55:10 +0200, Janne Grunau <[email protected]> > wrote: > > Fixes an assertion when called on uninitialized frame. Spotted after > > seeking in vlc. > > > > CC: [email protected] > > --- > > libavcodec/vaapi.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/libavcodec/vaapi.c b/libavcodec/vaapi.c > > index 0532daf..875d80a 100644 > > --- a/libavcodec/vaapi.c > > +++ b/libavcodec/vaapi.c > > @@ -46,6 +46,9 @@ int ff_vaapi_render_picture(struct vaapi_context *vactx, > > VASurfaceID surface) > > VABufferID va_buffers[3]; > > unsigned int n_va_buffers = 0; > > > > + if (!vactx->pic_param_buf_id) > > + return 0; > > + > > Does VAAPI guarantee that valid ids are nonzero? I failed to find any mention > of > the possible values in the docs.
me neither but alloc_buffer() and destroy_buffers() seem to handle 0 as invalid id. Current va sets te buffer id always to 'FOOL_BUFID_MAGIC | type' > And is the return value of 0 really appropriate? I'd naively expect this to be > an error. Or what are the circumstances of this happening? see Patch 2/2, mpeg12 decoder was calling frame_end even when it didn't called frame_start. The software decoder and the vdpau hw-accel could handle that, so I was trying to handle that for vaapi too. Especially since it triggers an assert in the intel vaapi driver. Janne _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
