From patchwork Sat Mar 9 20:30:29 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Peter F X-Patchwork-Id: 12277 Return-Path: X-Original-To: patchwork@ffaux-bg.ffmpeg.org Delivered-To: patchwork@ffaux-bg.ffmpeg.org Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by ffaux.localdomain (Postfix) with ESMTP id 77D80441544 for ; Sat, 9 Mar 2019 22:30:48 +0200 (EET) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 61E8F68A7CA; Sat, 9 Mar 2019 22:30:48 +0200 (EET) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mail-it1-f172.google.com (mail-it1-f172.google.com [209.85.166.172]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 2CE7B689C61 for ; Sat, 9 Mar 2019 22:30:42 +0200 (EET) Received: by mail-it1-f172.google.com with SMTP id v2so1514015ith.3 for ; Sat, 09 Mar 2019 12:30:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=2XqpApIXpc9t/0gMWx09tgizuXNA1bDgWQCkrcpq6ow=; b=cqMqkeDAaq5cmlabsGKnVPeulgirtGkhswLBDicisYauQjJXz7tR+bBekSRopD5yjz xJbb5Dh9B6faEN7JEGNGbIHVXMgQYomncZXtHYCeRF+wuPJJ9KQEMNYXFJbcon1lpKAB zUpZ62w1Rk27tMycwnvXEFaAYRUOdUATzBVOuFJzbGunDM6/wNNmJARLBbPpL9Zr8pd1 vXsRmLql9AWGVT6th/vmlr4UiAdVpOdap69gqTFu+1GI/ilgu+NAQzYOlm22y0d0q/Xa KVT0yfx7OVk5VkSI2aC49DazuZAiAcP0y+pvaisCklSpZ7foJJHZlbI/BU3EYtyhhDK5 Lg1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=2XqpApIXpc9t/0gMWx09tgizuXNA1bDgWQCkrcpq6ow=; b=IYrzMbUnCHJxNuuvC5jClpzuwDVglTAzXik8e5Nu/q54L7f7VUJvPGxhBqGUPkhpnj ZMkw4Pv8N9BvVLuofOZFk+aaFWrIiIN4Hdx/PYurFSoOeGXdo9z1EONaORxIaUuQCfwl 0pzLLjgZO9wqhzjkf04LL+w7j90Mpn18Ka5MAL4gMnp1YeVChjJP32PRR9f2CCWvYL4O 5N2/RfeBmRaUyhyZI4TeuBZJekJuD9fkjNyS+MXcRBDb940miAvcv4ZIUoEkR5S2Mk7F 9RZvPe7WduUh2cnyNsGScTk+CEiYCXJ38KImPQyviJHxR4spqY0PRKRfvWHF6xa5R6fX /l2w== X-Gm-Message-State: APjAAAVlQlTn0yWsMTOIE0ODJM/zw56P2qFeNuJqy+6/W2B/rnF3wF1l ofEod/x6KntA/iau9yphbR1ixoDpR0FYuHJ9R4pZDMjs X-Google-Smtp-Source: APXvYqxbBa5ctnKzTQbh7pdmBmQFIg24iAUN7pO0UXYMZobUOu6jtYKUHMo5PWhjj9avEt+1vsqyZzPXhUh4glfFlz4= X-Received: by 2002:a24:ac9:: with SMTP id 192mr12752097itw.15.1552163440461; Sat, 09 Mar 2019 12:30:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Peter F Date: Sat, 9 Mar 2019 21:30:29 +0100 Message-ID: To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] avcodec/vaapi_h264: skip decode if pic has no slices X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Thank you very much for your reply. Am Sa., 9. März 2019 um 21:09 Uhr schrieb Jan Ekström : > > From 386c94489a86bb747b6531f727843cf259a24f5d Mon Sep 17 00:00:00 2001 > > From: xbmc > Is this author field meant to not have an actual name in it? Just verifying. It can stay as is. The original author sometimes uses fernetmenta / xbmc depending on his local git configuration. The email is unique though. I just transported it upstream and fixed the minors. > > > Date: Sat, 26 Jan 2019 19:48:35 +0100 > > Subject: [PATCH] avcodec/vaapi_h264: skip decode if pic has no slices > > Something along the lines of "avcodec/vaapi_h264: skip decoding if no > slices were provided"? > > Also I would prefer if the reasoning for skipping decode on our layer > would be explained in further lines of the commit message, like you > have nicely explained it in the initial e-mail (to work-around a mesa > vaapi driver bug). > I don't remember the specifics of AVC, but are there valid VCL NAL > units without slices (and would such end up in this code path to begin > with)? I would guess that there would be no such valid VCL NAL units > (or if there were, they wouldn't get to this point in the decode > chain) - mostly just noting that this might be something we would like > to check to verify if this should be an error or a "normal" state. > > The general idea I'm OK with since if we already know that there's no > slices to decode, we might as well skip decoding as long as that > doesn't cause issues with the state of the underlying > libraries/drivers. Thus, I would mostly just wait for a reply from one > of the VAAPI wrapper maintainers regarding if this skip should happen > here or earlier in the decode process (where the buffers are being > allocated). > Yes I would also like to hear a statement from these guys. Especially as we (and most likely everyone else) just uses the ffmpeg send / receive API without feeling the need to introduce VAAPI workarounds in this generic application code Thanks again, please find attached the updated version Peter From 3c4885579e86f6c002e614c4082a3bdb02d8426e Mon Sep 17 00:00:00 2001 From: xbmc Date: Sat, 26 Jan 2019 19:48:35 +0100 Subject: [PATCH] avcodec/vaapi_h264: skip decode if pic has no slices This fixes / workarounds https://bugs.freedesktop.org/show_bug.cgi?id=105368. It was hit frequently when watching h264 channels received via DVB-X. Corresponding kodi bug: https://github.com/xbmc/xbmc/issues/15704 --- libavcodec/vaapi_h264.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c index 5854587a25..f12fdc457a 100644 --- a/libavcodec/vaapi_h264.c +++ b/libavcodec/vaapi_h264.c @@ -317,6 +317,11 @@ static int vaapi_h264_end_frame(AVCodecContext *avctx) H264SliceContext *sl = &h->slice_ctx[0]; int ret; + if (pic->nb_slices == 0) { + ret = AVERROR_INVALIDDATA; + goto finish; + } + ret = ff_vaapi_decode_issue(avctx, pic); if (ret < 0) goto finish; -- 2.20.1