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 23EE345DA5 for ; Mon, 10 Apr 2023 14:31:25 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 511C668BDEE; Mon, 10 Apr 2023 17:31:22 +0300 (EEST) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id A3FF668BAEC for ; Mon, 10 Apr 2023 17:31:15 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id B818540003 for ; Mon, 10 Apr 2023 14:31:14 +0000 (UTC) Date: Mon, 10 Apr 2023 16:31:13 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230410143113.GI1164690@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="===============4376537427977420967==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============4376537427977420967== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mlxBsilMljZ1v4XL" Content-Disposition: inline --mlxBsilMljZ1v4XL Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 10, 2023 at 10:44:32AM +0800, "zhilizhao(=E8=B5=B5=E5=BF=97=E7= =AB=8B)" wrote: >=20 >=20 > > On Apr 10, 2023, at 01:20, 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 supp= ort invalid > >>>> files where the creation date was encoded as a classic unix timestam= p. This > >>>> broke however valid files having creation dates before the unix epoc= h. > >>>>=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 consist= ent > >> with what mediainfo shows for creation time. Obviously 1946 was not the > >> intended creation time, but that does not warrant us to break files wh= ere > >> 1946 is the *intended* creation time. Proper way to fix the original i= ssue > >> 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 ? > > maybe iam missing something >=20 > The workaround can be a positive feedback to create more broken files: >=20 > 1. Once FFmpeg demuxer supports it, other demuxers may be required to > do the same workaround, because FFmpeg is (kind of) the standard software. In this case iam not sure, its just a fairly irrelevant piece of metadata Also why would we care that a feature causes work to the competition=20 >=20 > 2. Someone write a new muxer can make the same mistake and doesn=E2=80=99= t notice, > since FFmpeg don=E2=80=99t complain on the broken files. >=20 > 3. Old muxers which create those files don=E2=80=99t fix the bug, because= FFmpeg > doesn't complain. >=20 > We need to workaround bugs which break the process of demux or decoding. > Metadata with invalid values doesn't has the same priority. Make a big > noise at least to reduce the positive feedback effect, so user can report > bugs to the right place. I agree we should be more noisy about it when we encounter broken files. About causing more broken files with bug workarounds, we have worked around bugs alot so one would expect that there have to be many stories of that causing new bugs and unfixed bugs not just hypothethial cases. Still every time i read about it its a hypothethial case not a real example that somewhere a bug was caused by a workaround. So maybe that direction is relatively rare thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus --mlxBsilMljZ1v4XL Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZDQdqgAKCRBhHseHBAsP qyCfAJ9kZfSaUmP2ZnovyyO19U1JLjSGEgCff63oVgpFxbyVkU5OsDClehq6avU= =sfHF -----END PGP SIGNATURE----- --mlxBsilMljZ1v4XL-- --===============4376537427977420967== 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". --===============4376537427977420967==--