Re: [FFmpeg-devel] [PATCH v4 3/3] avformat/mxfenc: prefer to use the configured metadta
On Thu, Jan 28, 2021 at 02:41:46PM +0100, Tomas Härdin wrote: > tor 2021-01-28 klockan 21:08 +0800 skrev lance.lmw...@gmail.com: > > On Thu, Jan 28, 2021 at 10:26:03AM +0100, emco...@ffastrans.com wrote: > > > Am 2021-01-28 02:21, schrieb lance.lmw...@gmail.com: > > > > I haven't found the s337m freely, so I'm not sure about the Platforma > > > > metadata. > > > > I think we haven't support the field yet, I guess it's 0x3C08 tag, but I > > > > haven't > > > > the document in hand so it's not OK to add it by me. > > > > > > > Yeah the SMPTE are unfortunately not free :-( > > > > > > Maybe this helps: a citate from 377-1-2009c which i believe is the only > > > versoin of SMPTE 377 we should refer to unless we change the "Minor > > > Version" property of the partition pack to another value than "3" (which > > > it > > > currently is): > > > > thanks, I got a copy already. > > > > > > Item Name: Platform > > > > Type: UTF-16 string > > > > Len: var > > > > Local Tag: 3C.08 > > > > Item UL: 06.0E.2B.3401.01.01.0205.20.07.0106.01.00.00 > > > > Req?: Opt > > > > Meaning: Human readable name of the toolkit and operating system used. > > > > Best practice is to use the form “SDK name (OS name)” [RP 210 Specifies > > > > the platform on which the application was run] > > > > I haven't figured out how to get the string of "OS name", maybe I had to > > change configure file to add OS_NAME=$target_os and export the string. > > > > Below is two example for Apple and Linux: > > application_platform: Lavf58.65.101(Darwin) > > application_platform: Lavf58.65.101(Linux) > > > > If it's OK, I'll update the patch. > > You're missing a space before the parentheses. But yeah, something like > that would be fine with me. Maybe someone else has an opinion? Have fixed it and send the updated patch, please help to review them. > > /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-requ...@ffmpeg.org with subject "unsubscribe". -- Thanks, Limin Wang ___ 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".
Re: [FFmpeg-devel] [PATCH v4 3/3] avformat/mxfenc: prefer to use the configured metadta
tor 2021-01-28 klockan 21:08 +0800 skrev lance.lmw...@gmail.com: > On Thu, Jan 28, 2021 at 10:26:03AM +0100, emco...@ffastrans.com wrote: > > Am 2021-01-28 02:21, schrieb lance.lmw...@gmail.com: > > > I haven't found the s337m freely, so I'm not sure about the Platforma > > > metadata. > > > I think we haven't support the field yet, I guess it's 0x3C08 tag, but I > > > haven't > > > the document in hand so it's not OK to add it by me. > > > > > Yeah the SMPTE are unfortunately not free :-( > > > > Maybe this helps: a citate from 377-1-2009c which i believe is the only > > versoin of SMPTE 377 we should refer to unless we change the "Minor > > Version" property of the partition pack to another value than "3" (which it > > currently is): > > thanks, I got a copy already. > > > > Item Name: Platform > > > Type: UTF-16 string > > > Len: var > > > Local Tag: 3C.08 > > > Item UL: 06.0E.2B.3401.01.01.0205.20.07.0106.01.00.00 > > > Req?: Opt > > > Meaning: Human readable name of the toolkit and operating system used. > > > Best practice is to use the form “SDK name (OS name)” [RP 210 Specifies > > > the platform on which the application was run] > > I haven't figured out how to get the string of "OS name", maybe I had to > change configure file to add OS_NAME=$target_os and export the string. > > Below is two example for Apple and Linux: > application_platform: Lavf58.65.101(Darwin) > application_platform: Lavf58.65.101(Linux) > > If it's OK, I'll update the patch. You're missing a space before the parentheses. But yeah, something like that would be fine with me. Maybe someone else has an opinion? /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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 3/3] avformat/mxfenc: prefer to use the configured metadta
On Thu, Jan 28, 2021 at 10:26:03AM +0100, emco...@ffastrans.com wrote: > Am 2021-01-28 02:21, schrieb lance.lmw...@gmail.com: > > I haven't found the s337m freely, so I'm not sure about the Platforma > > metadata. > > I think we haven't support the field yet, I guess it's 0x3C08 tag, but I > > haven't > > the document in hand so it's not OK to add it by me. > > > Yeah the SMPTE are unfortunately not free :-( > > Maybe this helps: a citate from 377-1-2009c which i believe is the only > versoin of SMPTE 377 we should refer to unless we change the "Minor > Version" property of the partition pack to another value than "3" (which it > currently is): thanks, I got a copy already. > > > Item Name: Platform > > Type: UTF-16 string > > Len: var > > Local Tag: 3C.08 > > Item UL: 06.0E.2B.3401.01.01.0205.20.07.0106.01.00.00 > > Req?: Opt > > Meaning: Human readable name of the toolkit and operating system used. > > Best practice is to use the form “SDK name (OS name)” [RP 210 Specifies > > the platform on which the application was run] I haven't figured out how to get the string of "OS name", maybe I had to change configure file to add OS_NAME=$target_os and export the string. Below is two example for Apple and Linux: application_platform: Lavf58.65.101(Darwin) application_platform: Lavf58.65.101(Linux) If it's OK, I'll update the patch. > -- Thanks, Limin Wang ___ 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".
Re: [FFmpeg-devel] [PATCH v4 3/3] avformat/mxfenc: prefer to use the configured metadta
Am 2021-01-28 02:21, schrieb lance.lmw...@gmail.com: I haven't found the s337m freely, so I'm not sure about the Platforma metadata. I think we haven't support the field yet, I guess it's 0x3C08 tag, but I haven't the document in hand so it's not OK to add it by me. Yeah the SMPTE are unfortunately not free :-( Maybe this helps: a citate from 377-1-2009c which i believe is the only versoin of SMPTE 377 we should refer to unless we change the "Minor Version" property of the partition pack to another value than "3" (which it currently is): Item Name: Platform Type: UTF-16 string Len: var Local Tag: 3C.08 Item UL: 06.0E.2B.3401.01.01.0205.20.07.0106.01.00.00 Req?: Opt Meaning: Human readable name of the toolkit and operating system used. Best practice is to use the form “SDK name (OS name)” [RP 210 Specifies the platform on which the application was run] ___ 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".
Re: [FFmpeg-devel] [PATCH v4 3/3] avformat/mxfenc: prefer to use the configured metadta
On Wed, Jan 27, 2021 at 08:42:40AM +0100, Tobias Rapp wrote: > On 26.01.2021 16:39, Tomas Härdin wrote: > > tis 2021-01-26 klockan 00:34 +0100 skrev Marton Balint: > > > 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. > > > > I'll just add that I've read the updated version of S377m from 2007 and > > this sounds like the best solution. In short something like this: > > > > CompanyName: FFmpeg > > Product: OP1a Muxer > > Platform: libavformat x.y.z (Debian GNU/Linux 10 (buster)) > > > > If we delete the metadata in ffmpeg_opt.c like the original patch does > > here, and have Platform be the only hardcoded string, then hopefully > > everyone should be relatively happy. So CompanyName and Product can be > > changed from the command line/API but Platform cannot. > > Sounds reasonable to me. I haven't found the s337m freely, so I'm not sure about the Platforma metadata. I think we haven't support the field yet, I guess it's 0x3C08 tag, but I haven't the document in hand so it's not OK to add it by me. > > 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". -- Thanks, Limin Wang ___ 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".
Re: [FFmpeg-devel] [PATCH v4 3/3] avformat/mxfenc: prefer to use the configured metadta
On 26.01.2021 16:39, Tomas Härdin wrote: tis 2021-01-26 klockan 00:34 +0100 skrev Marton Balint: 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. I'll just add that I've read the updated version of S377m from 2007 and this sounds like the best solution. In short something like this: CompanyName: FFmpeg Product: OP1a Muxer Platform: libavformat x.y.z (Debian GNU/Linux 10 (buster)) If we delete the metadata in ffmpeg_opt.c like the original patch does here, and have Platform be the only hardcoded string, then hopefully everyone should be relatively happy. So CompanyName and Product can be changed from the command line/API but Platform cannot. Sounds reasonable to me. 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".
Re: [FFmpeg-devel] [PATCH v4 3/3] avformat/mxfenc: prefer to use the configured metadta
tis 2021-01-26 klockan 00:34 +0100 skrev Marton Balint: > On Mon, 25 Jan 2021, emco...@ffastrans.com wrote: > > 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. I'll just add that I've read the updated version of S377m from 2007 and this sounds like the best solution. In short something like this: CompanyName: FFmpeg Product: OP1a Muxer Platform: libavformat x.y.z (Debian GNU/Linux 10 (buster)) If we delete the metadata in ffmpeg_opt.c like the original patch does here, and have Platform be the only hardcoded string, then hopefully everyone should be relatively happy. So CompanyName and Product can be changed from the command line/API but Platform cannot. /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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 3/3] avformat/mxfenc: prefer to use the configured metadta
Am 2021-01-26 00:34, schrieb Marton Balint: 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. Sorry, there seems to be some confusion in this thread, the first submission seemed to target the "automatic copy" of the existing metadata but the updated version removes this automatism. Please ignore my comment as it is totally ok to provide input options for company_name, product_name, product_version but not automatically reflect the ones from the input. ___ 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".
Re: [FFmpeg-devel] [PATCH v4 3/3] avformat/mxfenc: prefer to use the configured metadta
On 25.01.2021 20:40, emco...@ffastrans.com wrote: [...] 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. This might work when your whole chain is built on a single container format (MXF). As soon as there is a mix of formats it is easier to store the processing chain information as a separate file. PREMIS is some standard for doing this, but it has quite some overhead: http://www.loc.gov/standards/premis/premis-mets.html Not sure how popular it is. 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".
Re: [FFmpeg-devel] [PATCH v4 3/3] avformat/mxfenc: prefer to use the configured metadta
On Mon, 25 Jan 2021, emco...@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.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. 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 ___ 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".
Re: [FFmpeg-devel] [PATCH v4 3/3] avformat/mxfenc: prefer to use the configured metadta
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.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. 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. 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. ___ 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".
Re: [FFmpeg-devel] [PATCH v4 3/3] avformat/mxfenc: prefer to use the configured metadta
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.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. > > 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)”" Where is this text from? Neither S377m-2004 nor RP210v10-2007 says this. /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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 3/3] avformat/mxfenc: prefer to use the configured metadta
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.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. 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)”" Seems a lot more fitting than the other metadata fields for the purpose of muxer identification. Regards, Marton ___ 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".
Re: [FFmpeg-devel] [PATCH v4 3/3] avformat/mxfenc: prefer to use the configured metadta
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".
Re: [FFmpeg-devel] [PATCH v4 3/3] avformat/mxfenc: prefer to use the configured metadta
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. /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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 3/3] avformat/mxfenc: prefer to use the configured metadta
On Fri, Jan 15, 2021 at 09:43:58PM +0100, Marton Balint wrote:
>
>
> On Fri, 15 Jan 2021, Tomas Härdin wrote:
>
> > lör 2021-01-09 klockan 13:07 +0800 skrev lance.lmw...@gmail.com:
> > > From: Limin Wang
> > >
> > > The metadata company_name, product_name, product_version from input
> > > file will be deleted to avoid overwriting information
> > > Please to test with below command:
> > > ./ffmpeg -i ../fate-suite/mxf/Sony-1.mxf -c:v copy -c:a copy out.mxf
> > > and
> > > ./ffmpeg -i ../fate-suite/mxf/Sony-1.mxf -c:v copy -c:a copy \
> > > -metadata company_name="xxx" \
> > > -metadata product_name="xxx" \
> > > -metadata product_version="xxx" \
> > > out.mxf
> > >
> > > Signed-off-by: Limin Wang
> > > ---
> > > fftools/ffmpeg_opt.c | 3 +++
> > > libavformat/mxfenc.c | 12
> > > 2 files changed, 11 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> > > index c295514..493763b 100644
> > > --- a/fftools/ffmpeg_opt.c
> > > +++ b/fftools/ffmpeg_opt.c
> > > @@ -2650,6 +2650,9 @@ loop_end:
> > > if(o->recording_time != INT64_MAX)
> > > av_dict_set(>metadata, "duration", NULL, 0);
> > > av_dict_set(>metadata, "creation_time", NULL, 0);
> > > +av_dict_set(>metadata, "company_name", NULL, 0);
> > > +av_dict_set(>metadata, "product_name", NULL, 0);
> > > +av_dict_set(>metadata, "product_version", NULL, 0);
> > > }
> > > if (!o->metadata_streams_manual)
> > > for (i = of->ost_index; i < nb_output_streams; i++) {
> > > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > > index d8678c9..5244211 100644
> > > --- a/libavformat/mxfenc.c
> > > +++ b/libavformat/mxfenc.c
> > > @@ -722,16 +722,20 @@ static void
> > > mxf_write_identification(AVFormatContext *s)
> > > {
> > > MXFContext *mxf = s->priv_data;
> > > AVIOContext *pb = s->pb;
> > > -const char *company = "FFmpeg";
> > > -const char *product = s->oformat != _mxf_opatom_muxer ? "OP1a
> > > Muxer" : "OPAtom Muxer";
> > > -const char *version;
> > > +AVDictionaryEntry *com_entry = av_dict_get(s->metadata,
> > > "company_name", NULL, 0);
> > > +AVDictionaryEntry *product_entry = av_dict_get(s->metadata,
> > > "product_name", NULL, 0);
> > > +AVDictionaryEntry *version_entry = av_dict_get(s->metadata,
> > > "product_version", NULL, 0);
> > > +const char *company = com_entry ? com_entry->value : "FFmpeg";
> > > +const char *product = product_entry ? product_entry->value :
> > > s->oformat != _mxf_opatom_muxer ? "OP1a Muxer" : "OPAtom Muxer";
> > > +const char *version = NULL;
> > > +const char *product_version = version_entry ? version_entry->value :
> > > AV_STRINGIFY(LIBAVFORMAT_VERSION);
> > > int length;
> > >
> > > mxf_write_metadata_key(pb, 0x013000);
> > > PRINT_KEY(s, "identification key", pb->buf_ptr - 16);
> > >
> > > version = s->flags & AVFMT_FLAG_BITEXACT ?
> > > -"0.0.0" : AV_STRINGIFY(LIBAVFORMAT_VERSION);
> > > +"0.0.0" : product_version;
> >
> > 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.
>
> Regards,
> Marton
> ___
> 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".
--
Thanks,
Limin Wang
___
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".
Re: [FFmpeg-devel] [PATCH v4 3/3] avformat/mxfenc: prefer to use the configured metadta
On Fri, 15 Jan 2021, Tomas Härdin wrote:
lör 2021-01-09 klockan 13:07 +0800 skrev lance.lmw...@gmail.com:
From: Limin Wang
The metadata company_name, product_name, product_version from input
file will be deleted to avoid overwriting information
Please to test with below command:
./ffmpeg -i ../fate-suite/mxf/Sony-1.mxf -c:v copy -c:a copy out.mxf
and
./ffmpeg -i ../fate-suite/mxf/Sony-1.mxf -c:v copy -c:a copy \
-metadata company_name="xxx" \
-metadata product_name="xxx" \
-metadata product_version="xxx" \
out.mxf
Signed-off-by: Limin Wang
---
fftools/ffmpeg_opt.c | 3 +++
libavformat/mxfenc.c | 12
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index c295514..493763b 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -2650,6 +2650,9 @@ loop_end:
if(o->recording_time != INT64_MAX)
av_dict_set(>metadata, "duration", NULL, 0);
av_dict_set(>metadata, "creation_time", NULL, 0);
+av_dict_set(>metadata, "company_name", NULL, 0);
+av_dict_set(>metadata, "product_name", NULL, 0);
+av_dict_set(>metadata, "product_version", NULL, 0);
}
if (!o->metadata_streams_manual)
for (i = of->ost_index; i < nb_output_streams; i++) {
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index d8678c9..5244211 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -722,16 +722,20 @@ static void mxf_write_identification(AVFormatContext *s)
{
MXFContext *mxf = s->priv_data;
AVIOContext *pb = s->pb;
-const char *company = "FFmpeg";
-const char *product = s->oformat != _mxf_opatom_muxer ? "OP1a Muxer" :
"OPAtom Muxer";
-const char *version;
+AVDictionaryEntry *com_entry = av_dict_get(s->metadata, "company_name",
NULL, 0);
+AVDictionaryEntry *product_entry = av_dict_get(s->metadata,
"product_name", NULL, 0);
+AVDictionaryEntry *version_entry = av_dict_get(s->metadata,
"product_version", NULL, 0);
+const char *company = com_entry ? com_entry->value : "FFmpeg";
+const char *product = product_entry ? product_entry->value : s->oformat !=
_mxf_opatom_muxer ? "OP1a Muxer" : "OPAtom Muxer";
+const char *version = NULL;
+const char *product_version = version_entry ? version_entry->value :
AV_STRINGIFY(LIBAVFORMAT_VERSION);
int length;
mxf_write_metadata_key(pb, 0x013000);
PRINT_KEY(s, "identification key", pb->buf_ptr - 16);
version = s->flags & AVFMT_FLAG_BITEXACT ?
-"0.0.0" : AV_STRINGIFY(LIBAVFORMAT_VERSION);
+"0.0.0" : product_version;
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.
Regards,
Marton
___
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".
Re: [FFmpeg-devel] [PATCH v4 3/3] avformat/mxfenc: prefer to use the configured metadta
lör 2021-01-09 klockan 13:07 +0800 skrev lance.lmw...@gmail.com:
> From: Limin Wang
>
> The metadata company_name, product_name, product_version from input
> file will be deleted to avoid overwriting information
> Please to test with below command:
> ./ffmpeg -i ../fate-suite/mxf/Sony-1.mxf -c:v copy -c:a copy out.mxf
> and
> ./ffmpeg -i ../fate-suite/mxf/Sony-1.mxf -c:v copy -c:a copy \
> -metadata company_name="xxx" \
> -metadata product_name="xxx" \
> -metadata product_version="xxx" \
> out.mxf
>
> Signed-off-by: Limin Wang
> ---
> fftools/ffmpeg_opt.c | 3 +++
> libavformat/mxfenc.c | 12
> 2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index c295514..493763b 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -2650,6 +2650,9 @@ loop_end:
> if(o->recording_time != INT64_MAX)
> av_dict_set(>metadata, "duration", NULL, 0);
> av_dict_set(>metadata, "creation_time", NULL, 0);
> +av_dict_set(>metadata, "company_name", NULL, 0);
> +av_dict_set(>metadata, "product_name", NULL, 0);
> +av_dict_set(>metadata, "product_version", NULL, 0);
> }
> if (!o->metadata_streams_manual)
> for (i = of->ost_index; i < nb_output_streams; i++) {
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index d8678c9..5244211 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -722,16 +722,20 @@ static void mxf_write_identification(AVFormatContext *s)
> {
> MXFContext *mxf = s->priv_data;
> AVIOContext *pb = s->pb;
> -const char *company = "FFmpeg";
> -const char *product = s->oformat != _mxf_opatom_muxer ? "OP1a Muxer"
> : "OPAtom Muxer";
> -const char *version;
> +AVDictionaryEntry *com_entry = av_dict_get(s->metadata, "company_name",
> NULL, 0);
> +AVDictionaryEntry *product_entry = av_dict_get(s->metadata,
> "product_name", NULL, 0);
> +AVDictionaryEntry *version_entry = av_dict_get(s->metadata,
> "product_version", NULL, 0);
> +const char *company = com_entry ? com_entry->value : "FFmpeg";
> +const char *product = product_entry ? product_entry->value : s->oformat
> != _mxf_opatom_muxer ? "OP1a Muxer" : "OPAtom Muxer";
> +const char *version = NULL;
> +const char *product_version = version_entry ? version_entry->value :
> AV_STRINGIFY(LIBAVFORMAT_VERSION);
> int length;
>
> mxf_write_metadata_key(pb, 0x013000);
> PRINT_KEY(s, "identification key", pb->buf_ptr - 16);
>
> version = s->flags & AVFMT_FLAG_BITEXACT ?
> -"0.0.0" : AV_STRINGIFY(LIBAVFORMAT_VERSION);
> +"0.0.0" : product_version;
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.
/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-requ...@ffmpeg.org with subject "unsubscribe".
