On Fri, 9 Nov 2018, Lou Logan wrote:
On Fri, Nov 9, 2018, at 8:01 AM, Carl Eugen Hoyos wrote:
(Continuing a discussion I had with several people who archive.)
I wonder if this is all intentional (seriously!), you have a
specification that from all I know is unclear, multiple different
and incompatible implementations and several commercial
applications that tell you what's wrong in the files - but
nobody seems to be very interested in fixing these "issues".
This reminds me of a few conversations I've had with those seeking
alternatives in the seemingly locked-in world of the legacy cable
broadcast stream conformation cycle. Luckily I'm not involved in
broadcast but the situation (a few years ago at least) seemed to be:
"Buy our $4000 (USD) analyzer to see what we say is 'wrong' with your
input. Buy our $6000 muxer to make it pass our analyzer."
Heh :)
Well, MXF is complicated, and based on what do you want to be compatible
with there are many flavours. Some issues reported by the analyzers can be
fixed, some can't be, because of the limited architecture of ffmpeg.
I guess there is no huge interest to improve the mxf muxer because BMXlib
tools like raw2bmx already do pretty good mxf wrapping (much better than
ffmpeg) and they support many flavours. I suggest using that for creating
standards compliant MXF.
On the other hand offering a bounty for fixing issues in the ffmpeg MXF
muxer might be an option, as far as I remember Baptiste and Michael did
work lately on mxfenc.
Regards,
Marton
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
[email protected] with subject "unsubscribe".
