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 CEAA742117 for ; Mon, 28 Mar 2022 21:59:28 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id BA69C68B2BB; Tue, 29 Mar 2022 00:59:25 +0300 (EEST) Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 4869168B2A4 for ; Tue, 29 Mar 2022 00:59:19 +0300 (EEST) Received: by mail-io1-f41.google.com with SMTP id q11so18819713iod.6 for ; Mon, 28 Mar 2022 14:59:19 -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=0QgbX1PCupxdn8+Lo7jaBlf5g06stAyEovyyfOIo/RE=; b=XNHay5uf1WVMgnPjcm3kW6mw0fjE4S4iLJCPn70TkuclMwYrMmX943F+4RrnHgADqe WFdIgcV5eKtsd/my+DPvamunH9yMWyMwyH3NoeOxz7omRiKsgJAB9p73IkAA1V9dOdCl 6i48hgoWE7hAHCkfiEUzriPBZHV1ip46hwu564q+juuQmXEAima8uPrxZ7Rbo5QSI19F /MOqMzqlcxr7d91LCeXhKrItZ1UynGfPUb2CW12kgdOoQMpu1Q0x52RnWc0JIi0r9YRd 8xeGfwXRes50lEw0/QMoK1fUEc087D+upUtc5kFuy+OyFfpUHZgzFIbgxNa4vt17b9fr TscA== 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=0QgbX1PCupxdn8+Lo7jaBlf5g06stAyEovyyfOIo/RE=; b=LD5OEaLExfow0ryXoUb9RPQdstucX4QQUY4hiUw0Pclg2+4j/jBs9ZADj/EJKsZpbw nQEOqVmRY39DMAMO/5pvWF1035j5AKHhysbO+rVruPlas+xM1EwJdczi8f9hyG7w1kN3 VBQ2/c5SHVFoCc7VsKTijT+4IRR++ovSAGh6s6F+QWYZ1AWpWelema0skPp79XcLsSg2 2GggCWi16mjcz1bo+GSfGJlZaIyRIycyR4hF1mNeiBG5pfBzzq3vXGZHn1U6KyE6YV1Q JG0Us1JdqyO3SDxaLs4xdwsTkJYAL8tMF6RtaLpOoTenqF5OJjL4oVLE7i1PQkElYt/G ySIw== X-Gm-Message-State: AOAM530C9g9FH1Fvo+AhFtpKQ2pxnNa8OCSZv+10at+8mtTbegxFKIjZ UQQ8uEvbsqlwnCHhHHbeSKfPzNtdVPI= X-Google-Smtp-Source: ABdhPJx5lqWHgpeTRkTXNJ4Lu/7IFq5cZb13lPYapwKKKnLKoWd+RMpYwpWdLdpAGwxVwbRsgi9fBg== X-Received: by 2002:a05:6638:1685:b0:321:4904:c9b5 with SMTP id f5-20020a056638168500b003214904c9b5mr14702423jat.40.1648504757552; Mon, 28 Mar 2022 14:59:17 -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 g5-20020a92dd85000000b002c65941015bsm7854062iln.38.2022.03.28.14.59.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Mar 2022 14:59:17 -0700 (PDT) Message-ID: <3e72ca48-d310-be08-cb43-4e9677a356c2@gmail.com> Date: Mon, 28 Mar 2022 17:59:16 -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-devel@ffmpeg.org References: <20220323110325.5499-1-leo.izen@gmail.com> From: Leo Izen In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH v9 1/5] avcodec/jpegxl: add Jpeg XL image codec and parser 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 3/23/22 10:45, Andreas Rheinhardt wrote: > Leo Izen: > + /* any other box is skipped at this point */ >> + AV_WB32(tag_str, tag); >> + av_log(avctx, AV_LOG_VERBOSE, "skipping jxl container box: %s\n", tag_str); > 1. tag_str is potentially not-zero terminated. > 2. If tag_str contains a \0, it might get truncated; it would be better > to just report it as hex with %X or so. > 3. And actually I don't think that this should be reported at all. If I change the report level to AV_LOG_DEBUG and report it as hex, does this work? >> +static uint64_t jpegxl_get_bits(void *avctx, JpegXLParseContext *jxlr, int bits) >> +{ >> + if (jxlr->box_size) { >> + if (bits > jxlr->box_size) { >> + int remaining = jxlr->box_size; >> + uint64_t ret = jpegxl_get_bits(avctx, jxlr, remaining); >> + /* go to the next box */ >> + int status = jpegxl_skip_boxes(avctx, jxlr); >> + if (status) >> + return 0; >> + ret |= jpegxl_get_bits(avctx, jxlr, bits - remaining) << remaining; > What guarantees that there is not a sequence of boxes with a payload of > 1 byte, so that a single read can span more than two boxes? > > And does the file format really allow to split the payload into > different boxes at arbitrary positions? > Nothing guarantees it. If it does, the second call to jpegxl_get_bits will recurse. Since you can only request 64 bits at once and all jxlp boxes are at least one byte of payload, this has worst-case-scenario of 8 calls for a 64 bits request. And unfortunately, it does allow the payload to be split at arbitrary positions. >> + *width = w, *height = h; >> + return 0; >Why does this pretend to be able to fail when it just can't? I was going to move the size validity check to these, but I forgot. I will do that next revision of the patch. >> + *poutbuf = buf + i; >> + *poutbuf_size = buf_size - i; > Seems like the parser is discarding some data here (if i != 0). That's the idea. It discards data that precedes the start of the frame. Is it not supposed to do this? Leo Izen (thebombzen) _______________________________________________ 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".