[FFmpeg-user] HD MXF SMPTE ST377 Standard Compliance Problem with multiple IndexTableSegments carring Unique ID twins (maybe a bug)
cus at passwd.hu
Sat Nov 10 01:49:44 EET 2018
On Sat, 10 Nov 2018, Carl Eugen Hoyos wrote:
> 2018-11-10 0:19 GMT+01:00, Marton Balint <cus at passwd.hu>:
>> 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.
> We improved many part of FFmpeg although other software existed...
Mostly because we wanted to create a superior solution and because the
task was challenging. In this case I see little chance of reaching a
superior solution, and the task is not even challenging. If somebody pays
good money, maybe.
>> 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.
> I thought you did too, no?
I did mostly mxfdec.
More information about the ffmpeg-user