[Ffmpeg-devel-irc] ffmpeg-devel.log.20140824

[burek]

[00:00] <iive> Case: yeh, that's common thing among dictators ;)
[00:00] <ubitux> kierank: i fucking hate chatty talks in real life because it's always a waste of time
[00:00] <iive> people are too easily manipulated in real life talks.
[00:00] <ubitux> kierank: and unless it's a very technical one, i will just avoid it alltogether
[00:00] <kierank> ubitux: you can come to the chatty talk to discuss the shared mailing list, the libav people can agree (and/or compromise)
[00:01] <ubitux> yes but i don't care
[00:01] <ubitux> i'm fine & neutral with that
[00:01] <kierank> ubitux: you just said that you don't like it when you comment and libav says you are saying ffmpeg is better
[00:01] <ubitux> i don't need to go to a meeting to ear ppl talk about such trivial thing
[00:01] <kierank> ubitux: again, will you be contacting everyone to make sure it will be ok
[00:01] <kierank> this is what i don't understand
[00:02] <kierank> you complain about libav but then when i suggest a way to improve the situation you say it's too hard
[00:02] <ubitux> you will never have everyone in real life
[00:02] <ubitux> but you will reach everyone through the 2 ml
[00:02] <ubitux> why the hell would you want to ever choose the 1st solution?
[00:02] <kierank> because look at where we are now
[00:03] <kierank> the second solution has just been potshots for the last 3.5 years
[00:03] <ubitux> it's an excuse
[00:04] <kierank> anyway clearly you don't give a shit either about users and think for some reasons that getting ffmpeg into debian will solve everything
[00:04] <kierank> even though libav controls the ffmpeg api
[00:04] <Case> so debian is responsible for this mess
[00:04] <kierank> lol
[00:05] <kierank> it's a misguided belief that debian having ffmpeg will solve everything
[00:05] <ubitux> having ffmpeg in debian will solve a lot of problems for the users kierank 
[00:05] <iive> agree!
[00:05] <ubitux> kierank: everything, maybe not, but it will definitely appease our users
[00:05] <Case> libav only has users because something lied that ffmpeg is depracated and libav is the new version
[00:06] <ubitux> kierank: we will probably still be limited with the api evolutions
[00:06] <ubitux> kierank: but first, we need to make sure our users can access our improvements
[00:06] <ubitux> because currently, our 3 years of developement are void
[00:07] <ubitux> then maybe, we can go discuss about what to do with the api evolutions
[00:07] <ubitux> and i don't mind discussing those in a common ml between libav & ffmpeg
[00:07] <ubitux> i'm not a sysadmin so i won't take the responsibility of such setup
[00:08] <ubitux> but we can definitely send a suggestion x-posted to both ml
[00:08] <kierank> ubitux: what about users who just want to decode a video and see half the web talking about ffmpeg and half the web talking about libav
[00:08] <kierank> and don't understand which to use
[00:08] <ubitux> they will look at what's available in their target OS
[00:08] <iive> kierank: you use the one that comes with your distro. Debian and Ubuntu comes wtih libav
[00:09] <jamrial> what case said is true to some extent. i've found quite a few cases where people assumed libav replaced ffmpeg because of the bogus "deprecated" ffmpeg package that used to be in debian
[00:09] <kierank> jamrial: i won't disagree
[00:09] <ubitux> "a few"? lol
[00:09] <kierank> and had a big argument with libav people about that
[00:09] <ubitux> go join #ffmpeg
[00:09] <jamrial> then there's gentoo now that changed the priority of the "ffmpeg" virtual package from libav to ffmpeg
[00:09] <jamrial> the ffmpeg virtual package by default install libav. IMO that's hella shaddy
[00:10] <jamrial> My bad
[00:10] <jamrial> the other way around
[00:10] <jamrial> changed it from ffmpeg to libav
[00:10] <ubitux> kierank: do you know a sysadmin willing to setup such ml?
[00:11] <ubitux> like, a ml dedicated to any API changes for both projects
[00:11] <kierank> ubitux: probably but that's not the point
[00:11] <kierank> the point is social
[00:11] <iive> jamrial:  is it possible to find out who did that? I've heard about it before
[00:11] <kierank> getting epople to agree to use it
[00:11] <ubitux> kierank: then send a mail to both ml
[00:12] <ubitux> kierank: no one ever suggested this on the ml afaik
[00:12] <jamrial> well, Luca is a gentoo dev, so i assume he was an influence in the decision
[00:12] <iive> jamrial: but can he do it himself?
[00:12] <ubitux> kierank: i don't think that's a bad idea at all to have a common ground for api evolutions
[00:13] <ubitux> kierank: the idea that both projects must send their proposition to that ml sounds ok to me
[00:13] <kierank> yes but it needs to be agreed
[00:13] <jamrial> no single person can make a change like that. but a person can influence the decision a group makes
[00:13] <ubitux> i expect it will not work but well
[00:13] <ubitux> (i expect ppl from one project trying to block the other one)
[00:13] <kierank> ubitux: i wouldn't say discussions are fianl
[00:13] <ubitux> but yeah sure we can give it a try
[00:13] <kierank> but just to have discussions
[00:13] <kierank> ubitux: yes so my point is your discuss it first and then do it
[00:14] <kierank> not just do it, nothing happens and then say libav aren't palying ball
[00:14] <ubitux> sure
[00:14] <iive> jamrial: the ffmpeg gentoo packager have not been... invited to such discussion. I had his blog post somewhere...
[00:14] <kierank> which is basically what michael does
[00:14] <ubitux> kierank: i really don't think any ff dev (or maybe CE but i'm not even sure) would disagree with such ml
[00:14] <kierank> and?
[00:15] <kierank> the point is not about ffmpeg agreeing
[00:15] <ubitux> well then just find a sysadmin to setup it
[00:15] <kierank> the point is about both sides
[00:15] <kierank> sigh
[00:15] <ubitux> well, go ask libav?
[00:15] <ubitux> i can do it if you want but that won't really work
[00:15] <ubitux> as i'm not a neutral folk
[00:16] <kierank> libav want to discuss this in person
[00:16] <kierank> but you don't 
[00:16] <kierank> and therefore they can say they tried and ffmpeg didn't respond
[00:16] <ubitux> well, if c & asm developers can't use e-mails then i can't do anything about that
[00:16] <kierank> it's not they can't
[00:16] <kierank> they are just fed up of the potshots for the last 3.5  years
[00:16] <ubitux> they don't want to right, but they have no reason
[00:16] <ubitux> it's just an excuse
[00:17] <kierank> it's not
[00:17] <ubitux> they know michael won't come
[00:17] <kierank> who wants tot hear the same shit again and again
[00:17] <ubitux> and use that as an excuse to not communicate
[00:17] <kierank> cf debian-devel
[00:17] <ubitux> same shit will happen irl
[00:17] <kierank> it doesn't
[00:17] <ubitux> then it's twisted
[00:17] <kierank> who would have thought people behave differently in different environments
[00:18] <ubitux> there is no reason to talk about that when setuping a common ml
[00:18] <ubitux> yes, irl they behave in the most hypocritical way
[00:18] <kierank> it is not hypocritical to behave differently depending on environment
[00:19] <kierank> people post things to ML that they wouldn't sat to people's face
[00:19] <kierank> look at all the internet trolls
[00:19] <ubitux> yes, because they are intimidated
[00:19] <kierank> in general
[00:19] <ubitux> or just don't want to express their thoughts
[00:19] <kierank> or because they are being polite
[00:19] <ubitux> because they don't have time to form them
[00:19] <kierank> (who would have thought...)
[00:19] <ubitux> yes, so they are hypocritical
[00:20] <kierank> so being cordial for the sake of progress is hypocritical
[00:20] <kierank> right
[00:20] <ubitux> (aka they try to appear nice)
[00:20] <kierank> compromise is hypocritical too
[00:20] <ubitux> no, it's a deal
[00:20] <kierank> let's stick to our 100% staunch views
[00:20] <kierank> otherwise we'll be hypocrites
[00:20] <kierank> mans is an author of swresample you know
[00:20] <kierank> ffmpeg steals libav's work
[00:20] <kierank> all these moronic views
[00:20] <kierank> let's repeat them all because we'd be hypocrites
[00:21] <kierank> let's not acknowledge mistakes
[00:21] <kierank> we'd be hypocrites
[00:22] <kierank> totally bizzare way of interacting with people
[00:23] <iive> kierank: what do you want?
[00:23] <kierank> both sides to act like adults
[00:23] <kierank> so as not to screw the users
[00:23] <kierank> otherwise go and join gpac
[00:23] <kierank> and be a research project with no users
[00:24] <kierank> also btw people don't use ffmpeg/libav based on their distro
[00:25] <iive> define what do you mean by that.
[00:25] <kierank> they use it based on whether it works
[00:25] <kierank> or if they can get it to work
[00:25] <iive> they first try the tool they can reach easily, then they look for another tool that does what they need.
[00:25] <kierank> iive: stop posting misleading stats/facts on the ml. talk about making some co-operative work
[00:25] <kierank> iive: not tool
[00:26] <kierank> i am talking about api usage
[00:26] <kierank> anyway these days people use github
[00:26] <iive> well, the libav take-over/fork happened because they wanted to change api and do thing differently.
[00:27] <ubitux> kierank: mail sent
[00:27] <ubitux> oups
[00:27] <ubitux> wrong dest
[00:27] <iive> by definition this is bad for the api users.
[00:27] <kierank> ubitux: congratulations, you'll get the response from libav you wanted
[00:27] <kierank> you're baiting them and they'll take the bait
[00:27] <kierank> and then you can say they didn't want to work with you
[00:27] <ubitux> i messed up the mail dest
[00:28] <iive> ubitux: where did you sent it? debian?
[00:28] <ubitux> ffmpeg.org :p
[00:28] <iive> ok, not big deal...
[00:29] <ubitux> kierank ??
[00:30] <ubitux> kierank: sorry but... what's wrong with my suggestion?
[00:30] <iive> kierank: libav simply have different priorities. they prefer cleaner code and api. this would remain even if all people who were at the fork leave the project.
[00:30] <kierank> it's the wrong environment to make it
[00:30] <kierank> nothing is wrong with the suggestion itself
[00:30] <ubitux> michaelni: oh shit, it actually compiles? :)
[00:30] <kierank> both mailing lists are full of smears so they are  going to assume this is another smear
[00:30] <ubitux> kierank: real life isn't any better
[00:31] <kierank> like all the quotes about being friendly with libav
[00:31] <kierank> ...
[00:31] <kierank> you were literally at each others throats IRL
[00:31] <kierank> yup
[00:31] <ubitux> i don't want to talk to libav in real life
[00:32] <kierank> no shit
[00:32] <iive> well, we can keep on hating each other, but at least point each-others bugs?
[00:32] <ubitux> because i don't want to play the game with the one making the rules
[00:32] <kierank> nobody will make rules
[00:32] <kierank> i don't want to talk to neither ffmpeg nor libav
[00:32] <kierank> but i have to
[00:32] <ubitux> real life is not a neutral ground
[00:32] <kierank> vlc is
[00:32] <kierank> as j-b said it's much bigger than the petty fighting
[00:32] <ubitux> anyway, i believe the ml thing is a good idea
[00:33] <kierank> yes but it will get shot down
[00:33] <ubitux> if libav agrees then be it
[00:33] <ubitux> +dis
[00:33] <kierank> and then you prove your point
[00:33] <ubitux> kierank: not sure
[00:33] <kierank> and you score a 9999:9998 in the libav/ffmpeg cold war
[00:33] <ubitux> where did they score 9998?
[00:33] <ubitux> :o
[00:34] <kierank> 9 998 then
[00:34] <kierank> since they like cosmetics
[00:34] <ubitux> i like 9999:9.998
[00:34] <kierank> yes but the dot could be a decimal point
[00:34] <kierank> ...
[00:34] <ubitux> that's the point
[00:34] <ubitux> ;)
[00:34] <kierank> nice cosmetic argument
[00:34] <iive> kierank: do you know what would be interesting. A maillist, where all identity is hidden. so nobody could guess who is who and from what project he is.
[00:35] <michaelni> ubitux, yes, also i think thilo has a ppc IIRC
[00:35] <ubitux> michaelni: ah, ok cool
[00:35] <ubitux> i'll wait for a proper
[00:35] <ubitux> i'm happy it compiles :p
[00:36] <ubitux> kierank: really i don't see how they can shot down this
[00:36] <ubitux> i'm actually starting to like the idea
[00:36] <kierank> they'll shoot it down because it came from you
[00:36] <kierank> because this problem is not technical but socail
[00:36] <ubitux> you didn't want to write the mail&
[00:37] <kierank> because i want to solve social problems properly (if painful for some, myself included)
[00:37] <ubitux> i told you it wouldn't be easy if i started such comminication
[00:37] <ubitux> it's not a "social" problem
[00:37] <ubitux> it's a braindead one
[00:37] <ubitux> there is nothing social about that
[00:37] <iive> kierank: how do you want to solve it?
[00:37] <ubitux> iive: he wants michael to go to VDD
[00:38] <iive> by real life meeting?
[00:38] <ubitux> so all problems magically solve themselves
[00:38] <ubitux> yes
[00:38] <kierank> whether you like it or not michael going to vdd is a blocking factor
[00:38] <ubitux> no
[00:38] <kierank> it was even said in the ffmpeg meeting last year
[00:38] <kierank> by myself and thierry
[00:38] <ubitux> the blocking factor is libav willing michael in real life at vdd
[00:38] <kierank> what are they  going to do?
[00:38] <kierank> murder him
[00:39] <ubitux> they can just get over it
[00:39] <ubitux> it's like a little switch in your brain
[00:39] <ubitux> i'm sure they can achieve that
[00:39] <iive> kierank: I think they hate him enough for that one too.
[00:40] <ubitux> i wouldn't actually be confident about michael not being murdered there
[00:40] <iive> but most likely they would like to shame him 
[00:41] <ubitux> yes, like harassing him to make him admit whatever they fancy, or public excuses or whatever
[00:41] <kierank> and a good moderator will stop that
[00:41] <ubitux> waste of time
[00:41] <ubitux> let's just keep trying to get them replying to mails
[00:42] <iive> kierank: imho, libav should be left to sink on its own weight.
[00:43] <kierank> lol
[00:43] <kierank> because all the things libav are experts on will suddenly just move to ffmpeg
[00:43] <iive> k&r and alphabetical ordering?
[00:44] <kierank> arm asm, rtsp, etc
[00:46] <ubitux> kierank: let's try to fill that gap
[00:46] <ubitux> actually, we are indeed in need of arm expert
[00:47] <kierank> you can't any more so than they can with swscale
[00:47] <kierank> they wrote the code
[00:47] <kierank> they understand it
[00:47] <iive> kierank: ?
[00:47] <ubitux> i don't think it's insurmountable 
[00:48] <iive> afair mans wrote most of the arm asm, and he rewrote most of that he didn't wrote. And he left libav quite long ago.
[00:48] <kierank> anyway i didn't post on debian-devel but that fact that one person understands most of ffmpeg isn't a selling point against libav
[00:48] <ubitux> iive: at least jannau is writing some asm
[00:48] <ubitux> iive: some *arm* asm
[00:48] <kierank> it's a euphemism for ffmpeg parts are unmaintainable
[00:49] <ubitux> it's the same for libav, really
[00:49] <iive> actually worse. because nobody there understands it as a whole.
[00:49] <iive> so they "clean it up" bit by bit.
[00:50] <ubitux> they solve the problem by ditching parts they don't understand, breaking some stuff in the process
[00:50] <ubitux> they might end up with a codebase they masterize, but at what cost?
[00:51] <kierank> better than a codebase only one person understands imo
[00:51] <ubitux> tell that to the users
[00:51] <kierank> yeah the users report a bug and only one person is able to fix it and if that person is busy they are fucked
[00:52] <ubitux> yes, better drop the feature
[00:52] <kierank> if it's a security related issue perhaps yes
[00:52] <kierank> or postproc
[00:52] <ubitux> it's better to drop the feature than asking michael
[00:53] <kierank> sometimes better to start again than build on a base of fragile
[00:53] <iive> kierank: even libav are not that stupid.
[00:53] <ubitux> except for users
[00:54] <kierank> iive: they've done it many times
[00:54] <kierank> lowres
[00:54] <kierank> postproc
[00:54] <kierank> et
[00:54] <ubitux> yes
[00:54] <ubitux> and lowres is useful for users
[00:54] <ubitux> postproc as well
[00:54] <kierank> yes but it used to crash randomly
[00:54] <iive> kierank: i mean, not stupid enough to start from clean slate.
[00:54] <ubitux> and now it's fixed in ffmpeg?
[00:54] <kierank> just like if there was an arm asm crash
[00:54] <kierank> who would fix it in ffmepg
[00:56] <ubitux> someone willing to learn arm asm i guess
[00:57] <ubitux> we'll probably get such maintainer at some point in the future
[00:58] <ubitux> we already have some people ± friendly with arm here, and i believe we have mind flexible enough to look into such thing
[00:58] <ubitux> the answer will definitely not be to ditch the arm asm
[00:59] <jamrial> if the crash is in ffmpeg, then it's also in libav, since all the arm code is the same between the two projects
[00:59] <kierank> you know well that isn't possible for parts of swscale or postproc or whatever
[00:59] <kierank> it's so complex nobody understands it
[01:02] <kierank> well one person
[01:09] <BBB> kierank: youre generally clever, but now youre utterly short-sighted
[01:10] <BBB> kierank: you know theres some people in a community that dont particularly need any prescient knowledge of any kind to fix bugs in a product, right?
[01:10] <BBB> kierank: like, me?
[01:10] <BBB> I can fix any bug in any product - wanna argue over that? Id love to
[01:10] <kierank> BBB: sure but by your own admission in the beginning of swscale it took a long time for you to understand it
[01:12] <kierank> but one of the "arguments" for debian to use ffmpeg on the list was that only one person really understands all of it
[01:12] <kierank> so users are better using ffmpeg
[01:12] <kierank> which is kinda true
[01:12] <kierank> but it mostly says some of the code is unmaintainable
[01:12] <BBB> I wasnt fixing bugs
[01:12] <BBB> I was trying to redesign the whole thing
[01:12] <BBB> thats utterly different
[01:13] <BBB> I do think some senior committers in libav are utterly clueless
[01:14] <BBB> but thats a different thing again
[01:14] <BBB> (then again, I believe it was a ffmpeg dude that started using commit count as a metric, so I guess were even there)
[01:32] <iive> BBB: i'm quite sure that was Diego too
[01:50] <Timothy__Gu> ubitux, BBB: Libav's lack of Michael reminds me of one of Michael's random quotes
[01:50] <Timothy__Gu> Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better.
[01:59] <BBB> Timothy__Gu: sorta& I do think you can learn a lot from rewriting something, that is, you will understand it better as you rewrite it, as long as you rewrite it functionality-complete
[01:59] <BBB> Timothy__Gu: but yeah, a full rm -fr followed by a rewrite from scratch is silly
[02:06] <Timothy__Gu> Hm you have a point
[02:06] <Timothy__Gu> Gotta go
[02:12] <Daemon404> BBB, rm -rf and no rewrite would suffice for some code out there
[02:12] <cone-41> ffmpeg.git 03James Almer 07master:b140b51ebbc2: lavc/tiff: add support for LZMA compression
[02:12] <cone-41> ffmpeg.git 03Michael Niedermayer 07master:ab1e4312887d: avcodec/tiff: Make pixel format checks tighter
[02:31] <Compnn> whoa kierank angry
[02:32] <kierank> no not really
[02:35] <Compnn> i'd kinda like to see michael go to vdd now just to prove that in real life talks wont change a thing
[02:35] <Compnn> :P
[02:40] <Compnn> j-b can setup a neutral ml for us :P
[02:44] <pross-au> Dumb question about FFmpeg Debian package: What's hold this up?
[02:45] <pross-au> There appears to be endless discussion on the ML by non-influential people. That is okay, its great to vent sometimes. But as an irregular contributor its hard to appreciate the issues and important stakeholders.
[02:45] <Compnn> pross-au : i think andreas knows more than we do about debian internals
[02:45] <Compnn> i think?
[02:46] <Compnn> last i heard the ftp masters havent reviewed it
[02:46] <Compnn> and security made some mentions about not wanting to have both
[02:46] <Compnn> so ... stalemate
[02:47] <pross-au> ok. that helps a bit.
[02:47] <Compnn> its across several bugs in debian bugzilla and on multiple mailinglists i think?
[02:47] <Compnn> if you follow all of andreas's mails , i think the links to all of the bugs are in there
[02:49] <Compnn> kierank : i was told point blank by libav devels that some of them didnt want to work with michael (and carl). you think thats changed in one year?
[02:49] <Compnn> at vdd13 that is
[02:49] <kierank> dunno
[02:49] <Compnn> (in person)
[02:50] <Compnn> ok , i was just curious if you had news about it
[02:50] <Compnn> because i havent had much communication with them 
[02:51] <kierank> generally speaking they have said they would at least have a discussion
[02:51] <kierank> i won't speak for anyone in particular
[02:51] <Compnn> no problem, i also am not remembering any names...
[02:53] <pross-au> Compnn: what will be the name of the FFmpeg+LibAV unification project
[02:54] <Compnn> you mean the unification ml or the name of the projects when combined?
[02:55] <pross-au> either
[02:55] <kierank> doubt there will be a reunification
[02:55] <kierank> a mutual respect at best
[02:55] <pross-au> What! Stop being negative.
[02:55] Action: Compnn has serious doubts too
[02:57] <Daemon404> Compnn, even sme ffmpeg devels dont want to work with carl
[02:57] Action: Daemon404 runs
[02:58] <Compnn> guys need to stop hating on each other
[02:58] <Compnn> just send author mails to spam if they bother you that much
[02:58] <Compnn> review on -cvslog
[02:58] <Daemon404> it makes a bug tracker essentially useless if the guy running it hates you
[02:58] <Daemon404> just fyi ;)
[02:59] <Daemon404> anyway kierank is correct
[02:59] <pross-au> Daemon404: i was once told, always treat the janitors kindly. They can make your life hell.
[02:59] <Daemon404> pross-au, in this case the janitor started it
[02:59] <Compnn> i've made suggestions how to fix the bug trac problem , maybe i should try to make my suggestions into policy
[03:00] <Compnn> Daemon404 : imo you should just send your bug reports direct to the maintainer of said code
[03:00] <Compnn> if the bug tracker isnt working for you 
[03:00] <Compnn> ;)
[03:00] <Compnn> i know others have had problems with the tracker
[03:00] <Compnn> i know
[03:00] <Daemon404> lol maintainers
[03:01] <Compnn> yes we have a MAINTAINERS file
[03:01] <Daemon404> as if most of the codebase has real maintainers
[03:01] <Compnn> pick the file.c and send it to that person
[03:01] <Compnn> an email
[03:01] <Daemon404> or even ones listed still exist
[03:01] <Compnn> you just want to argue :P
[03:02] <Compnn> if you dont want my suggestions, fine
[03:02] <Compnn> i still like ya
[03:02] <Daemon404> im a realist
[03:03] <kierank> Daemon404: we should co-maintain avresample
[03:03] <kierank> wm4 should join
[03:06] Action: Daemon404 sleeps .. 2am
[03:07] <Compnn> kierank saw ffmpeg and libav devs at vdd13. those two groups rarely stayed in the same room even
[03:08] <BBB> kierank: avresample is significantly slower for the code that I looked at
[03:08] <BBB> kierank: so I find your opinion impractical - yes, speed matters
[03:08] <kierank> that was a joke
[03:08] <Compnn> i liked the "libavcodec problems" meeting though. that was fun
[03:09] <kierank> BBB: because michael was/is angry that myself, Daemon404 and wm4 use avresample
[03:09] <BBB> ?
[03:09] <BBB> sorry I actually failed to parse that
[03:10] <kierank> it's 2am sorry
[03:10] <kierank> michael is angry that wm4, Daemon404 and me use avresample
[03:10] <kierank> instead of swresample
[03:10] <BBB> hm...
[03:10] <kierank> so i said us three should be maintainers
[03:10] <BBB> well, its a free world
[03:10] <BBB> lots of democrats are unhappy with republicans, and vice versa
[03:10] <kierank> to be fair the inline asm is gone
[03:10] <BBB> I dont see any issue
[03:11] <BBB> yeah I think I killed it all right?
[03:11] <kierank> yes
[03:11] <BBB> \o/
[03:11] <BBB> hurray
[03:11] <kierank> but i think the main reason from my side (and probably others) is inertia
[03:11] <Daemon404> [02:10] <@BBB> lots of democrats are unhappy with republicans, and vice versa <-- the proper view is that everyone and everything is shit
[03:11] <kierank> (read: laziness)
[03:12] <BBB> Daemon404: thats somewhat overly negative
[03:12] <BBB> if only everyone agreedw tih me, all would be good
[03:12] <Daemon404> seems pretty realistic for US politicians
[03:12] <BBB> agreed *with
[03:13] <Daemon404> why would my views be better
[03:13] <Daemon404> is said everything
[03:13] <Daemon404> i*
[03:14] <Daemon404> anyway what i was getting at, re: forks, the only way to stay sane for the unaffiliated is to give 0 fucks
[03:15] <Daemon404> and that is my stance, and why im not involved in any of the troll threads
[03:16] <jamrial> the inline asm made people not use swr?
[03:17] <kierank> the fact that it looked like swscale did as well
[03:18] <pross-au> jamrial: yes, don't we all read the source code before we use something?
[03:54] <cone-41> ffmpeg.git 03ThomasVolkert 07master:50a4d5cfc674: Add support for H.261 RTP payload format (RFC 4587)
[04:06] <cone-41> ffmpeg.git 03Carl Eugen Hoyos 07master:0744daa887ca: Do not print a useless error number if mov header reading fails.
[04:06] <cone-41> ffmpeg.git 03Carl Eugen Hoyos 07master:6f78c7032479: doc/ffmpeg: Try to clarify that the input option -r is not the same as -framerate.
[04:07] <cone-41> ffmpeg.git 03Carl Eugen Hoyos 07master:7c0c97cc05af: fate: Fix ffprobe tests with --target-path set.
[04:07] <cone-41> ffmpeg.git 03Michael Niedermayer 07master:1aa153d64479: Merge remote-tracking branch 'cehoyos/master'
[11:39] <cone-753> ffmpeg.git 03Michael Niedermayer 07master:2f0f93757735: Changelog: add "H.261 RTP payload format (RFC 4587)"
[11:39] <cone-753> ffmpeg.git 03Christophe Gisquet 07master:1506ea947d3c: pnmenc: use bits_per_raw_sample
[11:52] <cone-753> ffmpeg.git 03Christophe Gisquet 07master:38e2aa3759c6: x86: hevc_mc: correct unneeded use of SSE4 code
[12:10] <cone-753> ffmpeg.git 03Christophe Gisquet 07master:3e892b2bcdb6: x86: hevc_mc: split differently calls
[13:20] <cone-753> ffmpeg.git 03Paul B Mahol 07master:b73b36bfa5ed: avcodec/xan: fix style issue
[13:20] <cone-753> ffmpeg.git 03Paul B Mahol 07master:6dfa70f272d7: Correct few "ffmpeg" typos
[13:41] <ubitux> durandal_1707: 22:24:01 <@Daemon404> someone should have told him it was a trained neural network
[13:41] <ubitux> about the 13M of floats
[13:41] <durandal_1707> i read it from archive
[13:47] <ubitux> ok :)
[13:49] <wm4> 13MB of floats? wut
[13:49] <wm4> is this some insane proprietary codec?
[13:50] <ubitux> a deinterlacing filter
[13:51] <ubitux> wm4: https://github.com/dubhater/vapoursynth-nnedi3 "src/binary1_0.9.4.bin"
[13:51] <wm4> oh, avisynth shit? D:
[13:51] <wm4> ah
[13:51] <wm4> yeah.
[13:51] <ubitux> your favorite filtering project ;)
[13:51] <wm4> apparently that filter is the best shit ever
[13:51] <wm4> just don't look at its source
[13:52] <wm4> the vapoursynth port is probably a lot cleaner
[13:52] <ubitux> "yasm is currently not optional."
[14:04] <ubitux> J_Darnley: no progress on the beat detect? i would love to have that in ffmpeg&
[14:05] <wm4> ubitux: btw. does the server for the proposed API ML really have a significance?
[14:05] <wm4> maybe j-b could host it :)
[14:05] <ubitux> wm4: yeah sure
[14:06] <ubitux> we can give it a try anyway, it wouldn't engage anyone
[14:06] <ubitux> it can be seen as an experiment
[14:09] <ubitux> wm4: does my mail sound like a joke or something?
[14:09] <wm4> no
[14:10] <wm4> I'm glad that a ffmpeg person makes a move towards cooperation
[14:10] <ubitux> wm4: unfortunately, as kierank said, it's probably not a good idea that it comes from one side instead of a neutral party
[14:11] <ubitux> because they might oppose to it just because it comes from a ffmpeg folk
[14:11] <ubitux> we'll see
[14:13] <ubitux> michaelni: 
[14:13] <ubitux> remote: -Deny-          Tabs found in tests/fate/filter-video.mak.
[14:14] <ubitux> i didn't add any, but there are some tabs there
[14:14] <ubitux> since 706208ef47bffd525c982975d2756f7b2b220b8d i suppose
[14:15] <kurosu> ubitux, out of curiosity, what would be the git few-liner you used to find this ?
[14:15] <ubitux> find out?
[14:16] <ubitux> the tabs?
[14:16] <ubitux> i just tried to push something, the server hook denied me
[14:16] <wm4> gitk is pretty neat for git blaming
[14:17] <ubitux> i generally avoid git blame all together and use git log -p and / in the pager
[14:17] <kurosu> ubitux, no, the offending commit
[14:17] <ubitux> grep '<inserted tab here>' tests/fate/filter-video.mak
[14:17] <ubitux> git log -p tests/fate/filter-video.mak
[14:17] <ubitux> /printf
[14:17] <ubitux> :p
[14:18] <ubitux> git blame would have been more appropriate but well&
[14:19] <michaelni> ubitux, can the tabs be removed ? if not the git hook is under videolans control, that is if we need an additional exception for another fille type
[14:19] <ubitux> not sure
[14:19] <ubitux> Makefiles need tabs
[14:20] <ubitux> maybe the given rule can be moved in a real makefile
[14:20] <ubitux> (not an included .mak)
[14:24] <michaelni> j-b, on the git server, is the exception that allows tabs covering tests/fate/filter-video.mak ? ubitux seems to have had a problem with tabs in that file (see above) (also it seems other .mak files dont cause the problem we have library.mak with tabs)
[14:25] <ubitux> michaelni: the hash i'm mentioning is relatively recent
[14:25] <ubitux> how did you push taht in the merge?
[14:25] <michaelni> just like any other merge or commit
[14:25] <ubitux> maybe the hook is broken and doesn't check merge?
[14:26] <michaelni> it should check the actual changes that a merge introdueces but must not check individual merged commits
[14:27] <michaelni> so that one can remove tabs in the merge commit but they are allowed in individual commits otherwise merging could fail
[14:28] <michaelni> i thought it did that correctly
[14:30] <michaelni> anyway i prefer the lack of a check over one that blocks a good push
[14:34] <michaelni> ubitux, if you tell me what you wanted to push, i could merge it, if that works better
[14:34] <ubitux> ok, just a moment
[14:36] <ubitux> michaelni: https://github.com/ubitux/FFmpeg/compare/codecview
[14:51] <kierank> wm4: you should express your approval
[14:52] <wm4> hm right... you also should
[14:59] <cone-753> ffmpeg.git 03Clément BSsch 07master:f888331769d6: avfilter: add codecview filter
[14:59] <cone-753> ffmpeg.git 03Michael Niedermayer 07master:f155e01ab066: Merge remote-tracking branch 'ubitux/codecview'
[14:59] <ubitux> michaelni: heh, thanks
[15:00] <michaelni> np
[15:07] Action: Daemon404 wonders if ubitux is enjoying the deafening silence wrt his ML thread
[15:08] <ubitux> :)
[15:34] <cone-753> ffmpeg.git 03Carl Eugen Hoyos 07master:cc0acdbd6841: lavc/h264_slice: Add a missing newline to an error message.
[16:08] <durandal_1707> what happened with that yadif patches
[16:15] <nevcairiel> What yadif patches
[16:20] <durandal_1707> from michael
[16:21] <nevcairiel> Because he writes so little patches that I remember every single one of them
[16:24] <durandal_1707> avfilter/yadif experiment #2
[16:28] <nevcairiel> Guess nothing happened
[16:43] <Compnn> were they lost during the lgpl yadif shuffle ?
[18:47] <jamrial> ubitux: your propossal doesn't seem to be popular, judging by Anton's huge API change rfc sent to libav-devel a day after your email
[18:48] <ubitux> well, it's probably it's too soon 
[18:48] <ubitux> Anton wasn't going to wait for the mailing-list, that's understandable
[18:57] <wm4> yes, he prepared this stuff a long time ago
[19:13] <jamrial> well, if he's been cooking this for so long then it's not like he couldn't have waited a week if he actually found ubitux's proposal interesting
[19:14] <ubitux> it's not really important :)
[19:14] <ubitux> let's wait a week or two
[19:22] <Compnn> codec > codecpar ? what a bunch of crap. why not just redefine codec in the start of the file once ?
[19:23] <ubitux> huh?
[19:23] <ubitux> Compnn: you can't do that
[19:23] <Compnn> are you sure ?
[19:24] <Compnn> i thought i saw it in another file
[19:24] <ubitux> you're too vague
[19:24] <ubitux> please be specific
[19:24] <Compnn> http://lists.libav.org/pipermail/libav-devel/2014-August/062605.html
[19:24] <wm4> Compnn is clueless as usual
[19:25] <Compnn> changes codec to codecpar
[19:25] <Compnn> isnt it possible to define that at the start of the file instead of changing all of those lines ?
[19:25] <nevcairiel> Leave the code to the coders
[19:25] <nevcairiel> :d
[19:26] <nevcairiel> Although I'm not a fan of the name codecpar
[19:26] <wm4> the name is a bit weird
[19:27] <ubitux> Compnn: it could be possible if codec wasn't accessed from st
[19:27] <ubitux> but here you have no choice
[19:27] <Compnn> ah
[19:27] <ubitux> you can't do st->codecpar = st->codec :p
[19:29] <ubitux> nevcairiel: let's suggest "cp" so it's twisted in several ways
[19:38] <ubitux> lol michael's mail not reaching libav-devel
[19:40] <ubitux> JEEB: :D
[19:40] <JEEB> ;)
[19:41] <ubitux> great minds think alike
[19:41] <wm4> well this is a "who behaves better" game now
[19:42] <wm4> ffmpeg made a step forward
[19:42] <wm4> if Libav doesn't, we can all call Libav stupid
[19:42] <nevcairiel> But we won't, since we're the nice guys now!
[19:45] <ubitux> michaelni: were you able to test it?
[19:46] <ubitux> real hw or qemu?
[19:48] <michaelni> qemu, yes
[19:48] <michaelni> aarch64 swr that is
[19:48] <ubitux> yup ok
[19:49] <michaelni> theres also some resample code left that should be ported, if you or BBB want to do it
[19:54] <jamrial> the most important thing to be ported imo is x86 asm remixing of >2ch
[19:59] <michaelni> jamrial, do you want to work on it / have time ?
[20:00] <michaelni> and about resampling code, i meant aarch64 resampling code
[20:02] <jamrial> not really
[20:04] <michaelni> jamrial, ok, which functions exactly would need porting ?
[20:07] <ubitux> the mix 3..8 to 1..2?
[20:09] <jamrial> yeah
[20:09] <ubitux> 2f096bb10e0584397a08b418fdfa7ecc862ebfa0 ?
[20:11] <jamrial> yes, that one
[20:12] <jamrial> seems to be downmix only, but still really important since 5.1 or 7.1 to stereo is the most common downmix case for users
[20:39] <cone-989> ffmpeg.git 03Michael Niedermayer 07master:c2c4cee86692: avformat/matroskaenc: Check alpha_mode
[21:35] <cone-989> ffmpeg.git 03Luca Barbato 07master:424b929b5cb9: pulse: Add a wallclock option to be compatible with other other captures
[21:35] <cone-989> ffmpeg.git 03Michael Niedermayer 07master:511398031cc9: Merge commit '424b929b5cb9ca4094099f25179829260d4b0fa3'
[21:36] <BBB> resample aarch64 code?
[21:36] <BBB> Im unlikely to care, sadly
[22:17] <ubitux> mmh the altivec code for 8x8 actually does read 16x8
[22:17] <ubitux> that can be problematic
[23:41] <cone-989> ffmpeg.git 03Michael Niedermayer 07master:3fe9e7be4c70: avcodec/utils: add GBRP16 to avcodec_align_dimensions2()
[00:00] --- Mon Aug 25 2014