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 3B27947BE9 for ; Wed, 4 Oct 2023 02:35:34 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 15CFE68CBAF; Wed, 4 Oct 2023 05:35:32 +0300 (EEST) Received: from mail-qv1-f44.google.com (mail-qv1-f44.google.com [209.85.219.44]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id AC67668CAE1 for ; Wed, 4 Oct 2023 05:35:25 +0300 (EEST) Received: by mail-qv1-f44.google.com with SMTP id 6a1803df08f44-65d03071a07so1673376d6.0 for ; Tue, 03 Oct 2023 19:35:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696386924; x=1696991724; darn=ffmpeg.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=wRvClFCxeXmyKMmH9U0zBg6A8gjxz6HTlPzxB2WT4ks=; b=KxKbdDL3NUQeF8lU+dIzpuDjX0IQWNhxuJQ2a7YDqXYjLqkhCDYZcdFMubga+/IufO in9SPIlk7QR4MskV0hg+inBscRQkdpBkiHi2BsBF3HOhNtIyOuLN78vdnzin+RoSGhmL b6njeiny7naxP12NwRXx5+gvJjkXBqRYlDqrc6VIEj/qHNFAoZF/42vE5aUFVcua0w3Q i3uwiL2PEHlVLYGxeutwj9X0rYOYNGLDPtiUV2qn0dLpF8EXvmXBa7eeKU7TN3iZvF1Q M7nt9Z/VXqnUxqVJR24L+eXW5tB18m/xYRVun/Tu3GXc4OhqW2RimjKa8005gHIrCvYz rLJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696386924; x=1696991724; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wRvClFCxeXmyKMmH9U0zBg6A8gjxz6HTlPzxB2WT4ks=; b=WYiAg7XEkZkXj8cW3o8DsLCnW+gGvMM4/aMKoli5HoA4fvPfE8WPinayDEQgRlgmJp CmVgdOsGK5horgZRuvuVTNbR/sZqGrfZ2VZ+ZZyTysqwBk2TAqv5Wx0CKVyVyuBooQ1c EzDsjsVf0Dfz6x5uSho1BaEfKer4W8X0IuZwCga/Sc9410bhR30YAtANYD18ajf9mwxL hoF+FdbVUJIe3aMXXL1OXinwS/62JtC8pZ0FWIoEidhuavi0LlP+xBKrgKl/JIAMaQm+ IHNZcrSoP76b41ZolIxgsjV7ejo/kF2tS7A7Fo6HtGxn7V74drb/bnTVaZaNll1v3I6i MAQg== X-Gm-Message-State: AOJu0YxSbuNWNBD+78JvVpafKH6J5G3NsSkbi/eoaSjJe7vC5Ex7IOiA fTA60rWBDt9rg12DpIrxTGpHNC5jtrYv2Q== X-Google-Smtp-Source: AGHT+IFV66XSF/l5DaRzm/VZGVoksi+EPR4xWhXoM2uQhx3od1LCjnmq88InsUT2aO/SqOkt97UVHw== X-Received: by 2002:a05:6214:3018:b0:656:2e07:94cf with SMTP id ke24-20020a056214301800b006562e0794cfmr1110120qvb.3.1696386923763; Tue, 03 Oct 2023 19:35:23 -0700 (PDT) Received: from [192.168.1.35] (c-68-56-149-176.hsd1.mi.comcast.net. [68.56.149.176]) by smtp.gmail.com with ESMTPSA id y25-20020a0c9a99000000b0065afcc82d28sm982842qvd.88.2023.10.03.19.35.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Oct 2023 19:35:23 -0700 (PDT) Message-ID: <77f19b1e-dd65-4c87-a822-7150189d6823@gmail.com> Date: Tue, 3 Oct 2023 22:35:22 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US-large To: ffmpeg-devel@ffmpeg.org References: <20230926173742.2623244-1-vigneshv@google.com> From: Leo Izen In-Reply-To: <20230926173742.2623244-1-vigneshv@google.com> Subject: Re: [FFmpeg-devel] [PATCH] avformat/mov: Add support for demuxing still HEIC images 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 9/26/23 13:37, Vignesh Venkatasubramanian via ffmpeg-devel wrote: > They are similar to AVIF images (both use the HEIF container). > The only additional work needed is to parse the hvcC box and put > it in the extradata. > > With this patch applied, ffmpeg (when built with an HEVC decoder) > is able to decode the files in > https://github.com/nokiatech/heif/tree/gh-pages/content/images > > Partially fixes trac ticket #6521. > > Signed-off-by: Vignesh Venkatasubramanian > --- > libavformat/isom.h | 2 ++ > libavformat/mov.c | 38 +++++++++++++++++++++++++++++++++++++- > 2 files changed, 39 insertions(+), 1 deletion(-) > > diff --git a/libavformat/isom.h b/libavformat/isom.h > index 3d375d7a46..b30b9da65e 100644 > --- a/libavformat/isom.h > +++ b/libavformat/isom.h > @@ -327,6 +327,8 @@ typedef struct MOVContext { > int64_t extent_offset; > } *avif_info; > int avif_info_size; > + int64_t hvcC_offset; > + int hvcC_size; > int interleaved_read; > } MOVContext; > > diff --git a/libavformat/mov.c b/libavformat/mov.c > index 1996e0028c..cec9cb5fe1 100644 > --- a/libavformat/mov.c > +++ b/libavformat/mov.c > @@ -1218,7 +1218,8 @@ static int mov_read_ftyp(MOVContext *c, AVIOContext *pb, MOVAtom atom) > c->isom = 1; > av_log(c->fc, AV_LOG_DEBUG, "ISO: File Type Major Brand: %.4s\n",(char *)&type); > av_dict_set(&c->fc->metadata, "major_brand", type, 0); > - c->is_still_picture_avif = !strncmp(type, "avif", 4); > + c->is_still_picture_avif = !strncmp(type, "avif", 4) || > + !strncmp(type, "mif1", 4); This appears to be an unrelated change. Is it? > minor_ver = avio_rb32(pb); /* minor version */ > av_dict_set_int(&c->fc->metadata, "minor_version", minor_ver, 0); > > @@ -4911,6 +4912,16 @@ static int avif_add_stream(MOVContext *c, int item_id) > st->priv_data = sc; > st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO; > st->codecpar->codec_id = AV_CODEC_ID_AV1; > + if (c->hvcC_offset >= 0) { > + int ret; > + int64_t pos = avio_tell(c->fc->pb); > + st->codecpar->codec_id = AV_CODEC_ID_HEVC; > + avio_seek(c->fc->pb, c->hvcC_offset, SEEK_SET); > + ret = ff_get_extradata(c->fc, st->codecpar, c->fc->pb, c->hvcC_size); > + if (ret < 0) > + return ret; > + avio_seek(c->fc->pb, pos, SEEK_SET); > + } Will this fail on non-seekable input? If it does, do we care? > sc->ffindex = st->index; > c->trak_index = st->index; > st->avg_frame_rate.num = st->avg_frame_rate.den = 1; > @@ -4953,6 +4964,8 @@ static int avif_add_stream(MOVContext *c, int item_id) > > static int mov_read_meta(MOVContext *c, AVIOContext *pb, MOVAtom atom) > { > + c->hvcC_offset = -1; > + c->hvcC_size = 0; > while (atom.size > 8) { > uint32_t tag; > if (avio_feof(pb)) > @@ -7826,6 +7839,28 @@ static int mov_read_iloc(MOVContext *c, AVIOContext *pb, MOVAtom atom) > return atom.size; > } > > +static int mov_read_iprp(MOVContext *c, AVIOContext *pb, MOVAtom atom) > +{ > + int size = avio_rb32(pb); > + if (avio_rl32(pb) != MKTAG('i','p','c','o')) > + return AVERROR_INVALIDDATA; Is there a reason you use ipco here instead of iprp? I'm not saying this is wrong, but I am confused while you're doing it this way. > + size -= 8; > + while (size > 0) { > + int sub_size, sub_type; > + sub_size = avio_rb32(pb); > + sub_type = avio_rl32(pb); > + sub_size -= 8; > + size -= sub_size + 8; > + if (sub_type == MKTAG('h','v','c','C')) { > + c->hvcC_offset = avio_tell(pb); > + c->hvcC_size = sub_size; > + break; > + } Are these permitted to use extended-size tags? i.e. size = 1, followed by a big-endian 64-bit size, then followed by the tag? > + avio_skip(pb, sub_size); > + } > + return atom.size; > +} > + > static const MOVParseTableEntry mov_default_parse_table[] = { > { MKTAG('A','C','L','R'), mov_read_aclr }, > { MKTAG('A','P','R','G'), mov_read_avid }, > @@ -7933,6 +7968,7 @@ static const MOVParseTableEntry mov_default_parse_table[] = { > { MKTAG('p','c','m','C'), mov_read_pcmc }, /* PCM configuration box */ > { MKTAG('p','i','t','m'), mov_read_pitm }, > { MKTAG('e','v','c','C'), mov_read_glbl }, > +{ MKTAG('i','p','r','p'), mov_read_iprp }, > { 0, NULL } > }; > - Leo Izen _______________________________________________ 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".