On Tue, Mar 21, 2017 at 3:06 PM, wm4 <[email protected]> wrote: > On Tue, 21 Mar 2017 14:50:59 +0100 > Steve Lhomme <[email protected]> wrote: > >> Hi, >> >> We have this bug in VLC with an MPEG2 file that decodes with green >> bars at the top. After investigation it's because we allocate a >> 1920x1080 texture when it should actually need 1920x1088. >> https://trac.videolan.org/vlc/ticket/17856 >> >> In software decoding it works because we adjust the >> `ctx->coded_height` with avcodec_align_dimensions2(). But we do not >> call it for hardware decoding. And looking at the code it seems it's >> not meant to happen anyway (the DXVA pixel formats have no size >> constraint). >> >> So my question is: is it the job of libavcodec hardware decoders to >> set the proper coded_width/coded_height, in which case there's a bug, >> or it should be done outside of libavcodec ? And if so, how ? > > avconv_dxva2.c does this: > > /* decoding MPEG-2 requires additional alignment on some Intel GPUs, > but it causes issues for H.264 on certain AMD GPUs..... */ > if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO) > surface_alignment = 32;
Actually we have the same code. But it's called after we have our surfaces (doh!) I think I need to refactor this. > It aligns width and height accordingly, which gives you your 1088. No > idea how this should be handled, especially with the new hwaccel API. Yes, it would probably be nice to factorize this code so anyone can benefit from it without reinventing the wheel each time. > _______________________________________________ > libav-devel mailing list > [email protected] > https://lists.libav.org/mailman/listinfo/libav-devel _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
