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 6366841282 for ; Sun, 9 Apr 2023 21:27:59 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 4E77E68BCFB; Mon, 10 Apr 2023 00:27:56 +0300 (EEST) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id DA7F468ADF2 for ; Mon, 10 Apr 2023 00:27:49 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id 2A67B20002 for ; Sun, 9 Apr 2023 21:27:48 +0000 (UTC) Date: Sun, 9 Apr 2023 23:27:48 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230409212748.GF1164690@pb2> References: <20230408183724.12479-1-cus@passwd.hu> <20230408211411.GC4538@pb2> <9258ec2c-6635-1edc-f695-1cc2629c6ac8@passwd.hu> <20230409172004.GD1164690@pb2> MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH] avformat/mov: remove hack breaking creation time parsing 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-Type: multipart/mixed; boundary="===============3428499368843031749==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============3428499368843031749== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rWTGJt96jR0TCFDW" Content-Disposition: inline --rWTGJt96jR0TCFDW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 09, 2023 at 07:52:12PM +0200, Marton Balint wrote: >=20 >=20 > On Sun, 9 Apr 2023, Michael Niedermayer wrote: >=20 > > On Sun, Apr 09, 2023 at 03:49:33PM +0200, Marton Balint wrote: > > >=20 > > >=20 > > > On Sat, 8 Apr 2023, Michael Niedermayer wrote: > > >=20 > > > > On Sat, Apr 08, 2023 at 08:37:24PM +0200, Marton Balint wrote: > > > > > Commit 23eeffcd48a15e73fb2649b712870b6d101c5471 added a hack to s= upport invalid > > > > > files where the creation date was encoded as a classic unix times= tamp. This > > > > > broke however valid files having creation dates before the unix e= poch. > > > > >=20 > > > > > Signed-off-by: Marton Balint > > > > > --- > > > > > libavformat/mov.c | 3 +-- > > > > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > >=20 > > > > This results in: > > > > @@ -1,11 +1,11 @@ > > > > - creation_time : 2012-06-20T20:58:31.000000Z > > > > - creation_time : 2012-06-20T20:58:31.000000Z > > > > - creation_time : 2012-06-20T20:58:31.000000Z > > > > + creation_time : 1946-06-20T20:58:31.000000Z > > > > + creation_time : 1946-06-20T20:58:31.000000Z > > > > + creation_time : 1946-06-20T20:58:31.000000Z > > > >=20 > > > > Are you sure that 1946 is the correct creation date and not 2012 ? > > >=20 > > > If you are referring to the file in ticket #1471, yes, 1946 is consis= tent > > > with what mediainfo shows for creation time. Obviously 1946 was not t= he > > > intended creation time, but that does not warrant us to break files w= here > > > 1946 is the *intended* creation time. Proper way to fix the original = issue > > > would be to detect the device and software version which produces the > > > invalid files, and only apply the hack there. But I don't think that = is > > > doable here, the file does not seem to contain any device or software > > > information. > >=20 > > what do you mean by intended creation time? > > the file format did not exist in 1946. and all the codecs also didnt ex= ist > > so when you encounter a file that says its from that time it must be cr= afted > > later and backdated or that bug. > > we know the bug is a real thing > > do you want to support crafted and backdatred files? if so can you expl= ain > > the usecase for that ? >=20 > http://ffmpeg.org/pipermail/ffmpeg-user/2023-April/056265.html >=20 > Alternatives I can think of: >=20 > 1) A -unix_time switch what Anton proposed > 2) doing strict compliant parsing only if mdat version is 1 so creation t= ime > is 64bit. And change our muxer to write mdat version 1 by default, so ffm= peg > will be able to read back what it has written... What do we know about the buggy files that need this correction ? Is there any hint/metadata that identifies the muxer/encoder/version ? Limiting the correction to the cases that need it is a good idea Iam not sure i feel positive about changing the muxer thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope --rWTGJt96jR0TCFDW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZDMtzwAKCRBhHseHBAsP q2iUAJwPppGRda4p3JliClcgKm7wfO/+dgCeMhMw1BrAs9hI4Av6/OA/qpJktzo= =UyZk -----END PGP SIGNATURE----- --rWTGJt96jR0TCFDW-- --===============3428499368843031749== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============3428499368843031749==--