I’ve spent the first weekend of September in Paris, as j-b organized the yearly VideoLan Dev Days un-conference. I’m happy to have been there, because it was definitely great to be around all the friends and colleagues, and work on libav and discuss what we also need to work on.
What hasn’t been entirely that great, unsurprisingly, has been being around the Google people — both at VDD and at FOMS. The main problem with them is that they are never there to think that they can learn from the others, or that they can be wrong — the feeling that me and others got is that they came with all the answers and we all have to accept them and their options. This is obviously just a generalization — Andrew and Dale has been very pleasant to speak to, outside of the infamous talk which boiled down to “We can’t, or don’t want to, speak about this, but let us tell you again how nice we are for considering using your software and saying we won’t”.
Honestly, I’m surprised that Chrome works at all with the kind of attitude they have — I guess the answer is that the non-media people are saner or, simply, they know what they are doing, instead of just thinking they know what they are doing.
At any rate at least one good thing is coming out of this is that – also thanks to Hanno who pointed me to harvester – is that we’ll soon have a Planet Multimedia to aggregate blog feeds for people working on open multimedia projects — no matter what the project!
More posts on the various topics might come up depending on how much time I have for blogging over the next few weeks.
Too bad I couldn’t be there this time. But since it looks like this is going to become a regular event I hope I’ll get a few more chances :-)I suspect with a company the size of Google there’s always a lot of stuff they can’t talk about with people outside the company, things that are just hard to change etc., etc. Of course it’s rather impossible to know whether that’s the case or if it’s just an ordinary case of overconfidence 😉
It was the attitude with which they avoided to talk that was disconcerning — and it wasn’t only an impression of mine.Yes too bad you weren’t here, hopefully next year will both make it! (if my line of work is going to stay the same – which I hope – at least VDD is a job-related conference so I don’t have to worry about getting to it!).
Google sent more than 10 engineers to two community organised conferences. This shows that they came to interact with the community, to discuss and learn, not just “tell”. I’m curious if you have any more concrete details – what did you think they should have listened to and learned about? What do you think they’re doing wrong?
Silvia, the problem from my point of view is that with a few exception (Dale and Andrew as I said above), they seem to keep the stance with which they came.You weren’t in the room when Andrew tried to get the Chromium & libav talk — when we asked why Chromium wasn’t using libav, they literal answer was “why should we?”… even when, after a few days, it’s easy to see that we’d be a better fit for the need.A similar thing happened when talking about mobile devices and streaming support — we were presented with a problem and solution, and nothing we could say would sway that.. giving at least three different answers for the same request.For disclosure, I have worked for Google before.
… and full disclosure: He’d like to work for Google again. So can Google please use libav now and hire him in. Thank you.Sorry, Flamey, couldn’t resist :o)
Actually — no. I’ve worked for them and I’m not interested in working again (otherwise I would be working for them still).The reason why I want Chrome to use libav is because I do _not_ like to rely for security on a piece of software that merges in everything and the kitchen sink without testing, which in this case, is FFmpeg.
Touchy subject (and disclaimer for anyone that does not know that I work on FFmpeg), but maybe I could convince you not to make such extreme claims like “merges everything … without testing”? That seems about as helpful as the claims I hear the other way around like “FFmpeg contains 100s of security relevant fixes libav lacks!”.And no, I have not made any real effort to check either claim, though if anyone cares I suspect neither comes completely from thin air.And apologies for not just staying quiet.
Well, I think the problem is that we’re taking extremely different approaches — I’ve seen quite a few totally mindless things being added to ffmpeg — and that includes part of those “100s of security bugs”.I guess the main problem is that from my point of view, Michael is relying on the testing of the submitter, which might be very good, like in your case, but it also might be superficial. We try to do more than just that on libav.That’s also why we refrain on committing “security fixes” for things that are provable not to happen — or for things that only fix one sample but will fail later on. and yes, that means that at some points in time we’re missing fixes, but a few more days and it’ll be more reliable..
Actually I am rather bad at testing myself, which is why I have refused to do much on the subtitle code because we don’t have proper FATE tests for it.I think I don’t disagree in principle with you if you say it like that, though I have two points:1) refusing the fixes that “fix one sample but will fail later on” is a good idea in principle, but for my tastes it also too often ended up blocking fixes for real issues that nobody was going to fix “properly”. No idea how much that still is a problem.2) on the “provable not to happen” side I think the more consequent use of av_assert* can be a huge help, it serves to document that fact and helps to see in case you messed up the proving part. At least IMHO that is an area both projects have a lot where it could be improved, just as well as in the regression testing (even though there were great improvements, there are still big holes as well).
@Flameeyes I actually was in the room for that discussion. I even raised the question whether if libav had better security, whether that might be a good reason to move.The statement was that if moving to libav gave them a substantial advantage, they would. However, as it stands, the security issues between the two are not substantially different, Google’s requests for fixes are quicker acted upon by ffmpeg, and moving to libav implies a substantial amount of effort that they can’t see an advantage for. All of these sound like sensible reasons to me – not like “they were not listening”.Chromium is open source, so it is always possible for you to counter the arguments by creating a Chromium branch that runs on libav and show off the advantages that would create. I know that’s non-substantial effort, in particular if you’re not being paid for it, but if you are expecting change, sometimes it’s important to put the effort forward yourself.
Silvia, the problem is that the way they discounted it really didn’t make much sense. Changing from ffmpeg to libav shouldn’t be that dramatic because for quite a long time Gentoo did it anyway, and it worked fine (nowadays we don’t do that anymore simply because it was kept a moving target and Chromium is released way too often to try to keep the patch updated). But the fact we don’t want to patch it every time doesn’t mean it would be difficult to patch it once and have it use libav.On the other hand, we’ve been doing quite a bit of work in libav to suit the needs for Chrome, specifically the Microsoft compiler (MSVC) support. This is a feature that Derek, Måns, Martin and the other Diego have been working on a lot, and none of them cared that much to begin with — it was done almost entirely because Ronald had to work on it, and that was because Chrome on Windows wants to be built with MSVC. So we’re certainly open to developing with and for Chromium, and we’re just asking the acknowledgement that they are using our code, instead of the hairball we feel FFmpeg to be (furthermore they have to _patch_ FFmpeg to apply one change that Michael reverted and to revert a change that he made…).The other problem is a bit of a self-fulfilling prophecy and regards what I was discussing with Reimar above: too many times the Chrome security guys identify some kind of security problem, and create a patch that special case a condition that is the direct lead to said security problem — then they send the patch (usually to FFmpeg mailinglist alone). In some cases the patch is okay as it is, but more often we’re scratching our heads with “okay but how did you get there?”.This usually comes out fuzzed samples, but the problem is that they don’t send or link the fuzzed sample, not even in the private security list, so we have no way to identify exactly what went wrong that lead to that code to be vulnerable, and we’re not happy with just patching some random piece of code in if we don’t know why that’s needed, as it might open other issues (decoding issues for instance).Now as I said, working with Dale is a pleasure, as he provided me and Luca with the samples that we need, and Luca’s been busy with fixing the actual problems. What we’d really like is for that to happen as routine, and not have to happen only after a confrontation on the problems at VDD/FOMS, as that serves nobody.
To give my point of view.Google sent 10 Crome people to VDD, all of them were involved on some kind of multimedia but not all of them interested in the same specific aspects, Dale was focused on the specific parts I focus on so was normal for him to interact with me, people interested in accessibility obviously just focused in interacting with Silvia since they had not much to tell me nor I would have much to tell them.I know that few Google people, like Ami, in the end of the two conferences were exhausted and probably less pleasant and pleased to interact with/to, yet they made quite an effort to help with the remaining sessions.Regarding the whole Libav vs FFmpeg thing, it is quite political and the Chrome people are sort of between an hammer and an anvil. The bulk of FFmpeg is Libav, so for them one or the other is pretty much the same, they still need to tail it better for their needs.Picking one over the other is just a huge amount of bad pr since FFmpeg people are quite vocal and quite good in shovelling a quantity of manure over people they perceive as enemy.I can understand them and I do agree it had been an awkward situation.Overall I liked interacting with the Google people, and thanks to the samples provided I managed to eventually figured out which were the issues and probably provide hopefully a more general solution when the specific fixes for that specific sample were a bit off target in the big picture. (all the samples are fixed now btw)PS: Monty had been quite helpful while I messed on the ogg demuxer.
Oh, that’s great to hear. Obviously it was good to get FOMS and VDD people in one room and some good results have come from it. Collaboration between projects is not easy, so I am glad libav and Google Chrome developers got to talk and resolve some issues!
I’ll admit I keep contributing to FFmpeg, mostly because that’s where the dshow patches landed originally (also their mailing list seems…better supported). Could I request that you guys cherry pick the dshow stuff? It seems odd to me not to…