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

["\"zhilizhao(赵志立)\"" <quinkblack@foxmail.com>]

> On Apr 10, 2023, at 01:20, Michael Niedermayer <michael@niedermayer.cc> 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 ?
> maybe iam missing something

The workaround can be a positive feedback to create more broken files:

1. Once FFmpeg demuxer supports it, other demuxers may be required to
do the same workaround, because FFmpeg is (kind of) the standard software.

2. Someone write a new muxer can make the same mistake and doesn’t notice,
since FFmpeg don’t complain on the broken files.

3. Old muxers which create those files don’t fix the bug, because FFmpeg
doesn't complain.

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.

> 
> thx
> 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Does the universe only have a finite lifespan? No, its going to go on
> forever, its just that you wont like living in it. -- Hiranya Peiri
> _______________________________________________
> 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".

_______________________________________________
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".