Microsoft opens a "high priority" bug ticket in ffmpeg, attempting to leech the free labour of the maintainers
Microsoft opens a "high priority" bug ticket in ffmpeg, attempting to leech the free labour of the maintainers
Microsoft employee:
Hi, This is a high priority ticket and the FFmpeg version is currently used in a highly visible product in Microsoft. We have customers experience issues with Caption during Teams Live Event. Please help
Maintainer's comment on twitter:
After politely requesting a support contract from Microsoft for long term maintenance, they offered a one-time payment of a few thousand dollars instead.
This is unacceptable.
And further:
The lesson from the xz fiasco is that investments in maintenance and sustainability are unsexy and probably won't get a middle manager their promotion but pay off a thousandfold over many years.
But try selling that to a bean counter
the FFmpeg version is currently used in a highly visible product in Microsoft. We have customers experience issues with Caption during Teams Live Event.
This seems like a "you" problem, Microsoft, and since you employ thousands of programmers with the experience to solve your problem and commit the change back to the FOSS project, I think this is also very easily a "you" solution as well.
It's so ridiculous that this isn't even brought up:
The Command you provided worked fine. Thank you so much for the help! Really appreciated! We are going to proceed to make a release today and test with customers. Will post the updates here.
Gotta love being a forced beta tester... I mean customer.
Hi, This is a high priority ticket and the FFmpeg version is currently used in a highly visible product in Microsoft. We have customers experience issues with Caption during Teams Live Event. Please help,
Use -data_field first as decoder option in CLI. Default value was changed from first to auto in latest FFmpeg version. Or modify AVOption of same name in API for this decoder.
Thanks @Elon for the reply, This is the command we are currently using: ffmpeg.exe -f lavfi -i movie=flvdecoder_input223.flv[out+subcc] -y -map 0:1 ./output_p.srt
I will be looking to see any updates in the FFmpeg documentation. Can you please elaborate and provide pointers the right decoding options or the right FF command er can use. Thank you!
ffmpeg.exe -data_field first -f lavfi -i movie=flvdecoder_input223.flv[out+subcc] -y -map 0:1 ./output_p.srt
Got that's fucking brutal. This isn't even asking them to fix a bug, it's just basic help-desk shit.
I'm sure Microsoft has some good devs that are a net benefit to the open source projects they use, but this is not one of them.
Good, tell leech corporations and specially Microsoft to fuck right off. Pay for it or do it yourselves.
Fucking suits. They don't even care about the bottom-line, they just care about their own salary and benefits.
Pay for support or get fucked M$
Alternative answer: "We understand your issue and will fix it as time and priorities allow. Please note that customers paying for support always get higher priority. Given MS contributions to the project, this ticket was ranked 42nd in our priority list.
Have a pleasant day! FFMPEG support team"
This is gold.
@Sibbo I propose a xz style subversion of the code or a dependency, to ensure ffmpeg runs poorly on Windows and Azure.
after looking at the ticket myself i think the relevant things IMHO are:
- a person filed a bug report due to not seeing what changes in the new version caused a different behaviour
- that person seemed pushy, first telling the dev where patches should be sent to (is this normal? i guess not, better let the dev decide where patches go or -in this case- if patches are needed at all), then coming up with ceo style wordings (highly visible, customer experience of untested but nevertheless released to live product is bad due to this (implicitly "your") bug)
- pushiness is counterparted by "please help"
- free-of-charge consulting was given by the one pointing to changes likely beeing visible in changelog (i did not look though) but nevertheless it was pointed out to the parameter which assumes RTFM (if docs were indeed updated) that a default value had changed and its behavior could be adjusted by using that given parameter.
up to there that person -belonging to M$ or not (don't know and don't care) - behaved IMHO rather correctly, submitting a bug report for something that looked like it, beeing a bit pushy, wanting priority, trying to command, but still formally at least "asking" for help. but at that point the "bug" seemed to have been resolved to me, it looks like the person was either not reading the manual and changelog, or maybe manual or changelog lacks that information, but that was not stated later so i guess that person just did not read neither changelog nor manual.
instead - so it seems to me - that person demanded immediate and free-of-charge consulting of how exactly the switch should be used to work in that specific use case which would imply the dev looks into the example files, maybe try and error for himself just so that that person does not need to neither invest the time to learn use the software the company depends on, nor hire a consultant to do the work.
i think (intentional or not) abusing a bug tracker for demanding free-of-charge enduser consulting by a dev is a bad idea unless one wants(!) to actively waste the precious time of the dev (that high priority ticket for the highly visible already live released product relies on) or has even worse intentions like:
- uploading example files with exploits in them, pointing to the exact versions that include the RCE vulnerability that sample file would abuse and the "bug" was just reported cause it fits the version needed for exploitation and pressure was made by naming big companies to maybe make the dev run a vulnerable version on it on his workstation before someone finds out, so that an upstream attack could take place directly on the devs workstation. but thats just creating a fictive worst case scenario.
to me this clearly looks like a "different culture" problem. in companies where all are paid from basically the same employer, abusing an internal bug tracker for quick internal consulting would probably be seen as just normal and best practice because the dev who knows and is actually working on the code is likely to have the solution right at hand without thinking much while the other person, who is in charge of quick fixing an untested but already live to customers released product, does not have sufficient knowledge of how the thing works and neither is given the time to learn or at least read changelogs and manual nor the time to learn the basics of general upstream software culture.
in companies the https://en.m.wikipedia.org/wiki/Peter_principle could be a problem that imho likely leads to such situations, but this is a guess as i know nobody working there and i am not convinced that that person is in fact working for the named company, instead in that ticket shows up a name that i would assume to be a reason to not rely too much about names in the tickes system always be realnames.
the behaviour that causes the bad postings here in this lemmy thread is to me likely "just" a culture problem and that person would be advised well if told to learn to know the open source culture, netiquette etc and learn to behave differently depending on to who, where and how they communicate with, what to expect and how to interact productively to the benefit of their upstream too, which is the "real price" all so often in open source. it could be that in the company that rolled out the untested product it is seen to be best practice to immediately grab the dev who knows a software and let him help you with whatever you can't on your own (for whatever reason) whenever you manage to encounter one =]
i assume the pushyness could likely come from their hierarchy. it is not uncommon that so called leaders just create pressure to below because they maybe have no clue of the thing and not want to gain that clue, but that i cannot know, its just a picture in my head. but in a company that seems to put pressure on releasing an untested product to customers i guess i am not too wrong with the direction of that assumption. what the company maybe should learn is that releasing untested and/or unfinished products to live is a bad habit. but i also assume that if they wanted to learn that, they maybe would have started to learn it like roundabout 2 decades ago. again, i do not know for what company that person works -or worked- for, could be just a subcontractor of the named one too. and also could be that the pushyness (telling its for m$, that its live, has impact to customers etc) was really decided by someone up the latter who would have literally no experience at all on how to handle upstream in such situations. hierarchies can be very dysfunctional sometimes and in companies saying "impact to customers" sometimes is likely the same as saying "boss says asap".
what i would suggest their customers (those who were given a beta version as production ready) should learn is that when someone (maybe) continously delivers differently than advertised, that after some few times of experiencing this, the customer would be insane when assuming that that bad behaviour would vanish by pure hope + throwing money into hands where money maybe already didn't help improving their habits for assumingly decades. And when feeding everhungry with money does not resolve the problems, that maybe looking towards those who do have a non-money-dependant grown-up culture could actually provide more really usable products. Evaluation of new solutions (which one would really be best for a specific usecase i.e.) or testing new versions before really rolling them out to live might be costly especially when done throughout, but can provide a lot of really high valueable stability otherwise unreachable by those who only throw money at shareholders of brands and maybe rely on pure hope for all of the rest. Especially when that brand maybe even officially anounced to remove their testing department ;+) what should a sane and educated customer expect then ? but again to note, i do not know which companies really are involved and how exactly. from the ticket i do not see which company that person directly works for, nor if the claim that m$ is involved is a fact or just a false claim in hope for quicker help (companies already too desperate to test products before live could be desperate again in need for even more help when their bad habits piled up too long and begin falling on their heads)