On 18.01.2021 23:53, Tomas Härdin wrote:
lör 2021-01-16 klockan 08:43 +0800 skrev lance.lmw...@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.
Regards,
Tobias
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
