From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id E07CE4289A for ; Tue, 5 Apr 2022 14:06:31 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 394BE68B160; Tue, 5 Apr 2022 17:06:29 +0300 (EEST) Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id EEFC968B137 for ; Tue, 5 Apr 2022 17:06:21 +0300 (EEST) Received: by mail-qv1-f43.google.com with SMTP id f3so10064339qvz.10 for ; Tue, 05 Apr 2022 07:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=7AQOHVbnpierYF/pBLv4dnZ0q+wAaO6Tl9cq3i/3hm4=; b=P3UKuSlETwpr1ccwH3odnoRPDvAOcBDXgNA/73EtWs8TA4pMQhFPSw6GHi/jTNfz0J qyfJm6oiSxPrAEPMpHlgfHalteoqiOUuiGcbDg2vo/td+E76/4/2SnA1XcwQZCV/z7rY qYhmG+1KY6AdidriKcsv4/Hkv6qQ5CMy6ZKirc3oOQ4fGqMXvOPz5DUsd9SblPdmzp4m r223BvTCodWb7rf4IBq4/MBOoGb+Iov1ptb53Xf/suJEBpikn1VwxxB5vsi2mb36Lg44 fWFqzlmf+SGfUQFsgRh9JoiCChcsIkSf5VNAWip+xqq69IT6ZVy9NOJ3Z+BdCjG4nmgM gSbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=7AQOHVbnpierYF/pBLv4dnZ0q+wAaO6Tl9cq3i/3hm4=; b=Nd5PpGLgSarpcZcOuzusqquakBirbbP6rW5No9NoaTcNGlqedErfXmTTcboUbG2r93 EjMplSjIYgSasNcwzWV8w8hFP3jd6SwALfud8ncQlEpG4ajfi8LCFU2YhA9Sf6V2OQih AVCcfIHDjFaXzfqCI/tybH/wjcnsz0SubtUiLQsAhaU6IfParMktWBzSzMLDcQ81bbdE nSWYj2dtIvwXoird6rO8gdMOEBjUk5s9YEigwntYJALitN8jYdKgvrCmBsy/8E70FwO1 yOaJfiPpLCCa0FR02kUxBlHPY6nyncdbMX6PK07OqcT0dbsqbOiPkRDJiAxICEX0NEQN aezA== X-Gm-Message-State: AOAM531o0HHSLL15sDe2Cg2AUrwoDPhrLi8a0wCfvB11iifYBOekfpbW dasZyR9MZOW/BQzH2yxC1wFELx3Mm/M= X-Google-Smtp-Source: ABdhPJxameI4Mi9LRNu2F2E7O/uuDwpvSL4bzHDxVDbWZR/CisVkfctmN+7v2Y1jg4xpCCedW8jHyg== X-Received: by 2002:a05:6214:c64:b0:443:a483:3451 with SMTP id t4-20020a0562140c6400b00443a4833451mr3101729qvj.30.1649167580097; Tue, 05 Apr 2022 07:06:20 -0700 (PDT) Received: from [192.168.1.35] (c-68-41-54-207.hsd1.mi.comcast.net. [68.41.54.207]) by smtp.gmail.com with ESMTPSA id q8-20020a05622a030800b002e1c9304db8sm10968616qtw.38.2022.04.05.07.06.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Apr 2022 07:06:19 -0700 (PDT) Message-ID: <763ffeeb-81b6-8f4f-9583-353a1c8f2c8f@gmail.com> Date: Tue, 5 Apr 2022 10:06:18 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US-large To: FFmpeg development discussions and patches References: <20220402201210.86308-1-leo.izen@gmail.com> <20220402201210.86308-3-leo.izen@gmail.com> <164915580478.21047.15063529421341494996@lain.red.khirnov.net> From: Leo Izen In-Reply-To: <164915580478.21047.15063529421341494996@lain.red.khirnov.net> Subject: Re: [FFmpeg-devel] [PATCH v12 2/4] avcodec/libjxl: add Jpeg XL decoding via libjxl X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 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 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 4/5/22 06:50, Anton Khirnov wrote: > Quoting Leo Izen (2022-04-02 22:12:08) >> + case JXL_DEC_COLOR_ENCODING: >> + av_log(avctx, AV_LOG_DEBUG, "COLOR_ENCODING event emitted\n"); >> + jret = JxlDecoderGetICCProfileSize(ctx->decoder, &ctx->jxl_pixfmt, JXL_COLOR_PROFILE_TARGET_ORIGINAL, &ctx->iccp_len); > Does iccp_len need to be a context variable? Seems to me it's only used > in this block. Probably not, given that ctx->iccp is an AvBufferRef. >> + } >> + continue; >> + case JXL_DEC_FRAME: >> + case JXL_DEC_NEED_IMAGE_OUT_BUFFER: >> + /* >> + * We don't do this at basic info time >> + * because it will happen again when we >> + * rewind anyway >> + */ >> + av_log(avctx, AV_LOG_DEBUG, "%s event emitted\n", jret == JXL_DEC_FRAME ? "FRAME" : "NEED_IMAGE_OUT_BUFFER"); >> + ret = ff_get_buffer(avctx, frame, 0); > Is it absolutely guaranteed that this will always happen before > JXL_DEC_FULL_IMAGE in the same libjxl_decode_frame() invocation? > > Can it happen that you get JXL_DEC_NEED_IMAGE_OUT_BUFFER/JXL_DEC_FRAME, > then JXL_DEC_NEED_MORE_INPUT, which causes you to return, then > JXL_DEC_FULL_IMAGE on the next libjxl_decode_frame() call? I don't see why it couldn't, but what I don't understand is why this is necessarily a problem. >> + case JXL_DEC_SUCCESS: >> + av_log(avctx, AV_LOG_DEBUG, "SUCCESS event emitted\n"); >> + /* >> + * The file has finished decoding >> + * reset the decoder to let us >> + * reuse it again for the next image >> + */ >> + JxlDecoderReset(ctx->decoder); >> + libjxl_init_jxl_decoder(avctx); >> + buf = avpkt->data; >> + remaining = avpkt->size; > Why reset buf? The same data is not going to be decoded again, is it? Decoding a single image will never fire the JXL_DEC_SUCCESS call since we return before then. If you decode an image2 sequence (e.g. input-%d.jxl), JXL_DEC_SUCCESS is fired before the start of the next frame. When this event is fired, the contents of avpkt->data and avpkt->size are the already the next frame's data, so this is indeed necessary. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".