Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: only check index_edit_rate when calculating the index tables

From: "Tomas Härdin" <git@haerdin.se>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: only check index_edit_rate when calculating the index tables
Date: Fri, 03 May 2024 16:50:59 +0200
Message-ID: <a8668ceca1fd8110a83ce7c42cfae1509e74e872.camel@haerdin.se> (raw)
In-Reply-To: <5b6858e2-fb18-a497-3367-11af5d28ca96@passwd.hu>

tor 2024-05-02 klockan 23:01 +0200 skrev Marton Balint:
> 
> 
> On Mon, 29 Apr 2024, Tomas Härdin wrote:
> 
> > mån 2024-04-15 klockan 21:34 +0200 skrev Marton Balint:
> > > Commit ed49391961999f028e0bc55767d0eef6eeb15e49 started rejecting
> > > negative
> > > index segment edit rates to avoid negative av_rescale parameters.
> > > There are two
> > > problems with this:
> > > 
> > > 1) there is already a validation for zero (uninitialized) rates
> > > later
> > > on
> > > 2) it rejects files with 0/0 index edit rates which do exist and
> > > we
> > > should
> > > continue to support those
> > 
> > There are no such files in FATE last time I checked. At the very
> > least
> > we need to know which vendor is producing such broken files.
> > 
> > Without tests covering the workflows we want to support, we have no
> > confidence in refactoriing. This leads to cargo culting. And to be
> > sure, every workflow we support means a non-trivial amount of work,
> > especially when it comes to MXF.
> 
> I can add a comment to the code or the commit message, we did this
> plenty 
> of times in the past. The broken software is Marquise Technologies MT
> Mediabase 4.7.2 by the way. I can also rework the patch to keep
> rejecting 
> negative values and only allow zero, as that is the only thing I
> *know* to 
> exist.

We could also tell Marquise Technologies to fix their software. MXF is
a living ecosystem

> If we add a new FATE file for every fixed file or workflow, the
> amount of 
> FATE samples (and the time fate will run) will increase
> significantly, I 
> am not sure that is intended.

"Support any old workflow but don't add tests for them" is a ridiculous
position. It also prevents refactoring. There are real costs to
supporting workflows that no one uses. Hence why I mention SLAs. The
only people interested in MXF are professionals.

> In this case, I could only craft an MXF
> file, because I don't have access to the software.

Yes we can craft arbitrarily broken files. That doesn't help anyone.
It's just cargo culting.

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