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; > > It aligns width and height accordingly, which gives you your 1088. No > idea how this should be handled, especially with the new hwaccel API.
Finding that alignment case was a lot of fun a couple years back, incidentally it was on a DVD resolution clip (720x480), not even HD. Hardware is full of such surprises, surfaces should always *at least* be aligned to 16 (which would cover 1080->1088 already), and in those funny cases to 32 for mpeg2 and 64 or even 128 for HEVC .. the things one has to know (although the HEVC case is actually documented in the DXVA HEVC spec). Definitely would be useful if hwcontext can somehow handle this, or whatever component makes sense. - Hendrik _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
