[FFmpeg-devel] [PATCH v4 3/3] avformat/mxfenc: prefer to use the configured metadta

[Marton Balint]

On Mon, 25 Jan 2021, emcodem at ffastrans.com wrote:

> Am 2021-01-20 16:41, schrieb Tomas Härdin:
>> ons 2021-01-20 klockan 00:27 +0100 skrev Marton Balint:
>>> 
>>> On Tue, 19 Jan 2021, Tobias Rapp wrote:
>>> 
>>> > On 18.01.2021 23:53, Tomas Härdin wrote:
>>> > > lör 2021-01-16 klockan 08:43 +0800 skrev lance.lmwang at gmail.com:
>>> > > > On Fri, Jan 15, 2021 at 09:43:58PM +0100, Marton Balint wrote:
>>> > > > > On Fri, 15 Jan 2021, Tomas Härdin wrote:
>>> > > > > > Again, why? If you have a company that maintains a fork of 
> FFmpeg then
>>> > > > > > compile that info in here instead. Compare with FFmbc which 
> always puts
>>> > > > > > "FFmbc" as CompanyName.
>>> > > > >
>>> > > > > And how can a product based on libavformat set the company name, 
> product
>>> > > > > name and product version? It seems a valid use case for me that 
> these are
>>> > > > > overridable. Also note that this product version is only the "user
>>> > friendly"
>>> > > > > version string, for the numeric version still LIBAVFORMAT_VERSION 
> values
>>> > are
>>> > > > > used.
>>> > > >
>>> > > > Yes, my use case is the product is using libavformat as library, so 
> it's
>>> > > > prefer to have way to override these information as requirements.
>>> > >
>>> > > What I'm worried about here is that we're going to get files which
>>> > > claim to have been written by something other than libavformat. I've
>>> > > had situations like this before, and it is a source of headache. For
>>> > > example, if mxfenc writes some field incorrectly then this might cause
>>> > > us to hack mxfdec to accept that field instead of fixing mxfenc.
>>> >
>>> > I agree that especially for the MXF format with its flexible structure
>>> > it is more relevant to know the muxing library rather than the hosting
>>> > application. Have seen MXF output files of other commercial products
>>> > that also contain library identifiers like "libMXF" or "MXFtk" here.
>>> >
>>> > Other formats in FFmpeg use the "encoder" metadata key for embedding
>>> > library information in the output file. A quick test with AVI output
>>> > shows that this metadata is generated internally and cannot be
>>> > overridden on the command-line.
>>> 
>>> If your concern is being able to identify our mxf muxer, then why not 
>>> use
>>> the Platform metadata item for this?
>>> 
>>> "Human readable name of the toolkit and operating system used. Best
>>> practice is to use the form “SDK name (OS name)”"
>
> Uhm guys, it is very bad practice: if you just insert a different 
> manufacturer name then you just cheat. SMPTE 377 has a clear statement 
> about what goes to the identification, you cannot just write the infos 
> from a different program there.

Libavformat is a library/SDK, not an application. For most identification 
fields SMPTE 377 talks about the application which created the file, which 
can be anything using libavformat libraries. Feel free to quote if you 
have a more exact specification.

>
> What you can do instead is to push both identifications, the old one and 
> the one from the current program into the identification array, this way 
> the processing chain can be reconstructed. Unforutnately i have never 
> seen anyone doing this besides Opencube.
>
> Also, note that broadcasters currently are using the identification 
> string, looking for "ffmpeg" in order to sort out non compatible XDCAMHD
> mxf: ffmpeg does not write some mandatory metadata fields as mentioned 
> here: https://trac.ffmpeg.org/ticket/5097 this leads to sony devices not 
> accepting the ffmpeg mxf container - which again leads to ffmpeg mxf 
> wrapper for XDCAMHD not being accepted by our public broadcaster.

Maybe they should post patches instead of having workarounds? And I 
explained, libavformat MXF muxer will still be identifiable, but the 
proper field will be used for identifying the SDK used, not 
Company/Product but Toolkit/Platform.

Regards,
Marton