[FFmpeg-devel] [PATCH] avformat/mov: remove hack breaking creation time parsing

[Marton Balint]

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 at 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...

Regards,
Marton