On Sun, Apr 09, 2023 at 07:52:12PM +0200, Marton Balint wrote:
> 
> 
> On Sun, 9 Apr 2023, Michael Niedermayer wrote:
> 
> > On Sun, Apr 09, 2023 at 03:49:33PM +0200, Marton Balint wrote:
> > > 
> > > 
> > > On Sat, 8 Apr 2023, Michael Niedermayer wrote:
> > > 
> > > > 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 timestamp. This
> > > > > broke however valid files having creation dates before the unix epoch.
> > > > > 
> > > > > Signed-off-by: Marton Balint <cus@passwd.hu>
> > > > > ---
> > > > >  libavformat/mov.c | 3 +--
> > > > >  1 file changed, 1 insertion(+), 2 deletions(-)
> > > > 
> > > > 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
> > > > 
> > > > Are you sure that 1946 is the correct creation date and not 2012 ?
> > > 
> > > If you are referring to the file in ticket #1471, yes, 1946 is consistent
> > > with what mediainfo shows for creation time. Obviously 1946 was not the
> > > intended creation time, but that does not warrant us to break files where
> > > 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.
> > 
> > what do you mean by intended creation time?
> > the file format did not exist in 1946. and all the codecs also didnt exist
> > so when you encounter a file that says its from that time it must be 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 ?
> 
> http://ffmpeg.org/pipermail/ffmpeg-user/2023-April/056265.html
> 
> Alternatives I can think of:
> 
> 1) A -unix_time switch what Anton proposed

> 2) doing strict compliant parsing only if mdat version is 1 so creation 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...

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


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope