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 B9F9445DB5 for ; Mon, 10 Apr 2023 22:34:59 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id DFC9768BBF7; Tue, 11 Apr 2023 01:34:54 +0300 (EEST) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id E12E668093C for ; Tue, 11 Apr 2023 01:34:47 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id EC78BFF804 for ; Mon, 10 Apr 2023 22:34:46 +0000 (UTC) Date: Tue, 11 Apr 2023 00:34:45 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230410223445.GK1164690@pb2> References: <20230408183724.12479-1-cus@passwd.hu> <20230408211411.GC4538@pb2> <9258ec2c-6635-1edc-f695-1cc2629c6ac8@passwd.hu> <20230409172004.GD1164690@pb2> <20230409212748.GF1164690@pb2> <4a309d1d-7974-23c9-c3e1-e62ab94ce686@passwd.hu> MIME-Version: 1.0 In-Reply-To: <4a309d1d-7974-23c9-c3e1-e62ab94ce686@passwd.hu> 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="===============2296077818451355031==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============2296077818451355031== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="n0t7pLec3q0yZKtb" Content-Disposition: inline --n0t7pLec3q0yZKtb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 10, 2023 at 09:11:04PM +0200, Marton Balint wrote: >=20 >=20 > On Sun, 9 Apr 2023, Michael Niedermayer wrote: >=20 > > 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 support invalid > > > > > > > files where the creation date was encoded as a classic unix t= imestamp. This > > > > > > > broke however valid files having creation dates before the un= ix epoch. > > > > > > >=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 201= 2 ? > > > > >=20 > > > > > If you are referring to the file in ticket #1471, yes, 1946 is co= nsistent > > > > > with what mediainfo shows for creation time. Obviously 1946 was n= ot the > > > > > intended creation time, but that does not warrant us to break fil= es where > > > > > 1946 is the *intended* creation time. Proper way to fix the origi= nal 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 t= hat is > > > > > doable here, the file does not seem to contain any device or soft= ware > > > > > information. > > > >=20 > > > > what do you mean by intended creation time? > > > > the file format did not exist in 1946. and all the codecs also didn= t exist > > > > so when you encounter a file that says its from that time it must b= e crafted > > > > 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 = explain > > > > 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 > >=20 > > > 2) doing strict compliant parsing only if mdat version is 1 so creati= on time > > > is 64bit. And change our muxer to write mdat version 1 by default, so= ffmpeg > > > will be able to read back what it has written... > >=20 > > What do we know about the buggy files that need this correction ? >=20 > Not much. Samsung Galaxy Nexus phone and Samsung HMX-S16BP camcorder seems > affected at least. But not exclusively. I found these files among the > samples: >=20 > Samsung HMX-S16BP: > samples/ffmpeg-bugs/roundup/issue2517/HDV_0112.MP4 > samples/ffmpeg-bugs/roundup/issue2517_HDV_0113.MP4 >=20 > Galaxy Nexus: > Sample in ticket 1471. >=20 > Unknown: > samples/ffmpeg-bugs/trac/ticket2095_385 Deadlist Form 2-7-13.mp4 > samples/ffmpeg-bugs/trac/ticket3399_VID_20130619_161750_449.mp4 > user/aac-input-buffer-exhausted-up_1434137794_VID_20120604_172442.mp4 >=20 > > Is there any hint/metadata that identifies the muxer/encoder/version ? >=20 > In case of HMX-S16BP yes, in other cases no. >=20 > >=20 > > Limiting the correction to the cases that need it is a good idea >=20 > I guess I will start with limiting workaround for version 1 as a start. >=20 > > Iam not sure i feel positive about changing the muxer >=20 > Eventually we have to bump the mdhd version, because after 2040 creation > time will overflow. We should not wait until 2040 to do that, neither we > should start writing version 1 only after 2040, that would be Y2K problem > waiting to happen. yes sure, if theres a problem with the muxer then thats perfectly fine to change the muxer. I just meant that if the only reason is a buggy=20 3rd party muxer then changing our muxer felt like something to rethink and sleep over first. Iam not against bumping the mdhd version in master at some point (not immed= eatly before a release). thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. --n0t7pLec3q0yZKtb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZDSPAQAKCRBhHseHBAsP q+TbAJ9lE0Dj4QlDhTMDktg+NaooPCTHlgCfTgjn3UUVuRZK0fvXfw4FuJgG3Ps= =WHqQ -----END PGP SIGNATURE----- --n0t7pLec3q0yZKtb-- --===============2296077818451355031== 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". --===============2296077818451355031==--