From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <ffmpeg-devel-bounces@ffmpeg.org>
Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100])
by master.gitmailbox.com (Postfix) with ESMTPS id 4BDA54AE73
for <ffmpegdev@gitmailbox.com>; Thu, 24 Apr 2025 12:09:03 +0000 (UTC)
Received: from [127.0.1.1] (localhost [127.0.0.1])
by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E7FF7687BEB;
Thu, 24 Apr 2025 15:08:58 +0300 (EEST)
Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com
[210.118.77.11])
by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 04D2168834E
for <ffmpeg-devel@ffmpeg.org>; Thu, 24 Apr 2025 15:08:51 +0300 (EEST)
Received: from eucas1p1.samsung.com (unknown [182.198.249.206])
by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id
20250424120850euoutp01a839351782e6a5ec90bd56ce032f52cb~5P9icIreq0909809098euoutp01O
for <ffmpeg-devel@ffmpeg.org>; Thu, 24 Apr 2025 12:08:50 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com
20250424120850euoutp01a839351782e6a5ec90bd56ce032f52cb~5P9icIreq0909809098euoutp01O
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com;
s=mail20170921; t=1745496530;
bh=Dt5/j/4GqnMpAA370DjIJ5BkM1kbjdnGC5Dgm9hTEsY=;
h=From:To:In-Reply-To:Subject:Date:References:From;
b=gIkQnFwqAW2U8E/Pvk0xuLxCq4Lo5glm7zBeCQ4yOQRS6lElFTBLnRh5l3WX49LKk
JEyyCN0tLmX6tsZ3mYmEOA0Qrcz1wi9btccmzgvdvf1hTRBKFvf1M8U3W0N30sjIxR
BRFIBZpTO2cuxwvsPk5z5TyMBHXoteo35ZMwi25Y=
Received: from eusmges1new.samsung.com (unknown [203.254.199.242]) by
eucas1p2.samsung.com (KnoxPortal) with ESMTP id
20250424120850eucas1p29a34e924eb1010a15f0566aa18937b17~5P9iVX_B23224732247eucas1p2s
for <ffmpeg-devel@ffmpeg.org>; Thu, 24 Apr 2025 12:08:50 +0000 (GMT)
Received: from eucas1p2.samsung.com ( [182.198.249.207]) by
eusmges1new.samsung.com (EUCPMTA) with SMTP id 5B.92.00837.1D92A086; Thu, 24
Apr 2025 13:08:49 +0100 (BST)
Received: from eusmtrp2.samsung.com (unknown [182.198.249.139]) by
eucas1p1.samsung.com (KnoxPortal) with ESMTPA id
20250424120849eucas1p1a7a70913f65b336b1b0a93fa82108b70~5P9iBD58G1714217142eucas1p1O
for <ffmpeg-devel@ffmpeg.org>; Thu, 24 Apr 2025 12:08:49 +0000 (GMT)
Received: from eusmgms2.samsung.com (unknown [182.198.249.180]) by
eusmtrp2.samsung.com (KnoxPortal) with ESMTP id
20250424120849eusmtrp28d380e39a0e9426d06ed97fb6d195b4b~5P9iAf2fJ2715027150eusmtrp2V
for <ffmpeg-devel@ffmpeg.org>; Thu, 24 Apr 2025 12:08:49 +0000 (GMT)
X-AuditID: cbfec7f2-32fff70000000345-43-680a29d1351d
Received: from eusmtip2.samsung.com ( [203.254.199.222]) by
eusmgms2.samsung.com (EUCPMTA) with SMTP id 14.54.19654.1D92A086; Thu, 24
Apr 2025 13:08:49 +0100 (BST)
Received: from AMDN5164 (unknown [106.210.132.171]) by eusmtip2.samsung.com
(KnoxPortal) with ESMTPA id
20250424120849eusmtip21fba06b80f2c930c769b5f1f6832afe8~5P9hy2q1d0543505435eusmtip2J
for <ffmpeg-devel@ffmpeg.org>; Thu, 24 Apr 2025 12:08:49 +0000 (GMT)
From: "Dawid Kozinski/Multimedia \(PLT\) /SRPOL/Staff Engineer/Samsung
Electronics" <d.kozinski@samsung.com>
To: "'FFmpeg development discussions and patches'" <ffmpeg-devel@ffmpeg.org>
In-Reply-To: <2034e60d-6140-4d18-90b0-b2736c3f2f84@jkqxz.net>
Date: Thu, 24 Apr 2025 14:08:49 +0200
Message-ID: <003201dbb511$a33606e0$e9a214a0$@samsung.com>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIeiw43OxpgnU+PFcTC0/DVSYq79wGw/nKsAfLAoTGzD+3iMA==
Content-Language: pl
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsWy7djP87oXNbkyDGZesbT49ukMswOjx59F
m1kCGKO4bFJSczLLUov07RK4Ms6ePcla8MWh4vjUfawNjH32XYycHBICJhLnF79lA7GFBFYw
Sjx5otLFyAVkT2KSONR6lR3CmcgkcfXYElaYjt8nJzBCJJYzSmy4844Jwmljkmhd+o8dpIpN
IE/i8ee1zCC2iICPRPf69WDdnAK2Ekt3toPZwgL5Egv//2YCsVkEVCUeNnSD1fMKWEr8eLad
EcIWlDg58wkLiM0soCfx7NQsKFtbYtnC18wQFylI/Hy6jBVil5NE16/z7BA1IhI3HrWAXSoh
MJFDom3+CqgXXCQuLFjCDmELS7w6vgXKlpH4v3M+0EEcQHaxxKF+BwizRuLQj3SICmuJt43H
GSHCjhIT19tDmHwSN94KQizlk5i0bTozRJhXoqNNCMJUkejrFIOYISXxdNkc5gmMSrOQfDgL
yYezkHw4C8knCxhZVjGKp5YW56anFhvmpZbrFSfmFpfmpesl5+duYgSmhtP/jn/awTj31Ue9
Q4xMHIyHGCU4mJVEeH+5sWcI8aYkVlalFuXHF5XmpBYfYpTmYFES5120vzVdSCA9sSQ1OzW1
ILUIJsvEwSnVwDTrydKW/vPWisfWiDf6Z3c8s2Xw27P/Xr1hE/eVM8dP75zy8OgRpm1LdzO/
nJwopaK0T9dWRSot+Szjn5fHOvfEHT6rfkb74YcSq6hJeW5q79yZ36wKL+N+33Tj3eG9KZuP
pEb3nDwsE6WaUrmqvOjLmo2LP1mE/4qfWrC24enX6HsqkrzvttnMLDetWR99RLpS9BP3Exer
/a+m/WX8VbDjo+Bse4GHBrKpV+pidf7cWGv9dq1N6L/d8d9Yw6Iu2k28PGHP2wfhB36YuFy0
/9rwtn/aD8tw6/WnBBdrvIr/mfVC8sv56bV6C74H9dkJSoTF2czQ/NKjuNZzTtdCo/udtum9
7W6q37ed8RUUn3RLiaU4I9FQi7moOBEAASbjNHwDAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42I5/e/4Pd2LmlwZBo+nqll8+3SG2YHR48+i
zSwBjFF6NkX5pSWpChn5xSW2StGGFkZ6hpYWekYmlnqGxuaxVkamSvp2NimpOZllqUX6dgl6
GYs2NzEVfNeq6NvcytTA+Eqhi5GTQ0LAROL3yQmMXYxcHEICSxklNj+bwgyRkJJYunQRI4Qt
LPHnWhcbRFELk8SNpS/YQBJsAjkSa2dPZAKxRQR8JLrXr2eFKDrAKNG2/zlYEaeArcTSne2s
ILawQK7EuduPwKayCKhKPGzoBtvGK2Ap8ePZdkYIW1Di5MwnLCA2s4CBxJKFv5ggbG2JZQtf
Q12nIPHz6TJWiMVOEl2/zrND1IhI3HjUwjiBUWgWklGzkIyahWTULCQtCxhZVjGKpJYW56bn
FhvpFSfmFpfmpesl5+duYgRGxbZjP7fsYFz56qPeIUYmDsZDjBIczEoivL/c2DOEeFMSK6tS
i/Lji0pzUosPMZoC/TaRWUo0OR8Yl3kl8YZmBqaGJmaWBqaWZsZK4rxsV86nCQmkJ5akZqem
FqQWwfQxcXBKNTAp7Lt71MXrX4t8rZzDlZcxR774Rid4lCuIVk/Jn3Yvk7ekfOdMLdNnq3LK
lKq2xqd1G+/fF/hbYqro/U/dfNOc4/5J/zO9HZRmwVyZ9oFTPqRn8qXi0FUFcnLXmX3uM/Ne
nuHgEDDh3u+dbF9X78tb1bYs+ftivZXOK3IP6rE2fHqzSvRVj83pm98FVxcrNTzd1hEt6b7X
4SdrrAaLbuzq6vizPzNSJVe0TRJPZz8l/W9teN2zntcVwoFsmc1zVq/8tur/+uijkzxsgz2L
NlhdOfywb84xycSv9mW/XoqolXzO0TygEjip9XXDvHrtroUWDtve3z7Pdt6SY+EeTu9pF6sN
LH22p8vLRUyQvqXEUpyRaKjFXFScCACdm2zXEwMAAA==
X-CMS-MailID: 20250424120849eucas1p1a7a70913f65b336b1b0a93fa82108b70
X-Msg-Generator: CA
X-RootMTR: 20250423141306eucas1p229fa078339a2a993c609464e101c9c6d
X-EPHeader: CA
CMS-TYPE: 201P
X-CMS-RootMailID: 20250423141306eucas1p229fa078339a2a993c609464e101c9c6d
References: <CGME20250423141306eucas1p229fa078339a2a993c609464e101c9c6d@eucas1p2.samsung.com>
<20250423141303.1858090-1-d.kozinski@samsung.com>
<2034e60d-6140-4d18-90b0-b2736c3f2f84@jkqxz.net>
Subject: Re: [FFmpeg-devel] [PATCH v1 5/8] avformat/mov_muxer: Extended MOV
muxer to handle APV video content
X-BeenThere: ffmpeg-devel@ffmpeg.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: FFmpeg development discussions and patches <ffmpeg-devel.ffmpeg.org>
List-Unsubscribe: <https://ffmpeg.org/mailman/options/ffmpeg-devel>,
<mailto:ffmpeg-devel-request@ffmpeg.org?subject=unsubscribe>
List-Archive: <https://ffmpeg.org/pipermail/ffmpeg-devel>
List-Post: <mailto:ffmpeg-devel@ffmpeg.org>
List-Help: <mailto:ffmpeg-devel-request@ffmpeg.org?subject=help>
List-Subscribe: <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>,
<mailto:ffmpeg-devel-request@ffmpeg.org?subject=subscribe>
Reply-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Errors-To: ffmpeg-devel-bounces@ffmpeg.org
Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org>
Archived-At: <https://master.gitmailbox.com/ffmpegdev/003201dbb511$a33606e0$e9a214a0$@samsung.com/>
List-Archive: <https://master.gitmailbox.com/ffmpegdev/>
List-Post: <mailto:ffmpegdev@gitmailbox.com>
> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Mark
> Thompson
> Sent: =B6roda, 23 kwietnia 2025 23:08
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v1 5/8] avformat/mov_muxer: Extended
> MOV muxer to handle APV video content
> =
> On 23/04/2025 15:13, Dawid Kozinski wrote:
> > - Changes in mov_write_video_tag function to handle APV elementary
> > stream
> > - Provided structure APVDecoderConfigurationRecord that specifies the
> > decoder configuration information for APV video content
> >
> > Signed-off-by: Dawid Kozinski <d.kozinski@samsung.com>
> > ---
> > libavformat/Makefile | 2 +-
> > libavformat/apv.c | 827 ++++++++++++++++++++++++++++++++++++++++
> > libavformat/apv.h | 94 +++++
> > libavformat/isom_tags.c | 2 +
> > libavformat/movenc.c | 47 +++
> > 5 files changed, 971 insertions(+), 1 deletion(-)
> =
> Hi,
> =
> Two thoughts here:
> =
> First, your AVPackets contain a raw_bitstream_access_unit(). I don't
think this is
> the right approach - the packets should contain the codec data only, not
the
> additional encapsulation. (This is the method I followed.)
> =
> For this patch in particular, I think it results in writing the files
incorrectly: the
> specification says "each sample shall contain one and only one access unit
of
> APV coded data", which I interpret to mean one access_unit() syntax
structure.
> =
> This also results in the size effectively appearing multiple times in the
file for no
> good reason:
> =
> 00000020 66 72 65 65 00 01 15 db 6d 64 61 74 00 01 15 cf
|free....mdat....|
> =
> ^ mdat size ^ au_size
> =
> 00000030 61 50 76 31 00 01 15 c7 01 00 01 00 21 21 40 00
|aPv1........!!@.|
> ^ signature ^ pbu_size ^ pbu_type followed by header
> =
> The separate pbu_size makes sense if there is also metadata, but having
the
> mdat box with a size immediately followed by the same size (well, minus
twelve
> for mdat size + mdat + au size) again inside the box does not seem
helpful.
> =
Hi Mark,
Indeed. AVPackets contains raw_bitstream_access_unit()
raw_bitstream_access_unit() { =
au_size | u(32)
access_unit(au_size) |
} =
Such data comes out from the APV encoder.
Data from the encoder can go to the movmuxer, but it can also go to another
muxer like apvmuxer.
const FFOutputFormat ff_apv_muxer =3D {
.p.name =3D "apv",
.p.long_name =3D NULL_IF_CONFIG_SMALL("raw APV video"),
.p.extensions =3D "apv",
.p.audio_codec =3D AV_CODEC_ID_NONE,
.p.video_codec =3D AV_CODEC_ID_APV,
.flags_internal =3D FF_OFMT_FLAG_MAX_ONE_OF_EACH |
FF_OFMT_FLAG_ONLY_DEFAULT_CODECS,
.write_packet =3D ff_raw_write_packet,
.p.flags =3D AVFMT_NOTIMESTAMPS,
};
Thanks to the fact that the APV muxer receives such data packed in AVPacket,
I was able to use the default function ff_raw_write_packet() from rawenc.c
as FFOutputFormat::write_packet for ff_apv_muxer.
The APV muxer uses ff_raw_write_packet, which takes the data that came from
the encoder packed in AVPacket and writes the data to a file.
In the case of saving the elementary APV stream to a file, the data should
have the format [au_size (4Bytes)][access_unit][au_size
(4Bytes)][access_unit]...[au_size(4Bytes)][access_unit].
Regarding APV in movmuxer, we can eliminate the additional AU size in two
ways:
1.
We can change the output data format from the encoder so that the AVPacket
contains access_unit() without the 4-byte prefix containing information
about the length of the AU. However, this will require using a custom
.write_packet function in ff_apv_muxer that will add a prefix specifying the
size of the AU in the output stream before each access unit.
2. =
We will make changes in the mov muxer (movenc.c). We will not write the data
using the call avio_write(pb, pkt->data, size); but will implement custom
handling for APV (an additional if() in ff_mov_write_packet()):
if (par->codec_id =3D=3D AV_CODEC_ID_APV) {
avio_write(pb, pkt->data + 4, size - 4);
}
Please share your opinion.
BR
Dawid
> Second, I think we need a consistent decision on what the extradata should
be
> doing. The APVDecoderConfigurationRecord makes sense as a thing for it to
> contain, but it's not clear to me that it needs to exist at all as it has
no effect on
> anything inside ffmpeg (a decoder will always ignore it).
> =
> You currently make extradata from one of your demuxers but not other one
or
> the encoder, and nothing requires it when consuming. Why is it useful to
have
> ever?
> =
> Thanks,
> =
> - Mark
> =
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://protect2.fireeye.com/v1/url?k=3Dfe563622-a1cdf846-fe57bd6d-
> 000babda0201-8b2ed12312438c45&q=3D1&e=3D8a63da42-a031-4561-b197-
> 0dcaaf458058&u=3Dhttps%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmp
> eg-devel
> =
> To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org
> with subject "unsubscribe".
_______________________________________________
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".