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

[burek]

[00:22] <cone-41> ffmpeg.git 03Thomas Volkert 07master:00d7555f3468: wavdec: RIFX file format support
[00:39] <koda> Compn: carl is on libav bugzilla
[00:39] <koda> Compn: https://bugzilla.libav.org/show_bug.cgi?id=742#c5
[00:39] <koda> but apparently replying in a thread is considered bad karma
[00:40] <koda> better to make sure that libav has a bug that ffmpeg has not so they can claim its so much better
[00:40] <koda> #opensourcegonebad
[00:44] <kierank> koda: "I may ask you why did you wait for 1.5 years before letting Libav know of this problem,"
[00:44] <kierank> ???
[00:45] <koda> kierank: what about it
[00:45] <kierank> i don't get it
[00:46] <koda> that was a message for timothy_gu that patrolled the bugzilla and rather than letting us know that we could push this patch he preferred to wait until i noticed, worrying that there might an attribution problem"
[00:46] <koda> i dont get this behaviour as well :/
[00:48] <timothy_gu> koda: oh wait I forgot about that
[00:48] <kierank> I had a dream about libav and ffmpeg the other day
[00:48] <Compn> kierank : was i in it ?
[00:48] Action: timothy_gu needs to apologize
[00:48] <kierank> I think ffmpeg decided to stop merging libav and I had to do a daily merge
[00:48] <timothy_gu> lol
[00:48] <koda> lolol
[00:48] <koda> i mean usa and cuba are able to make peace and ffmpeg and libav cannot?
[00:48] <koda> it_s_just_crazy
[00:48] <kierank> took 50 years though
[00:49] <Compn> obama cant shut down guantanimo, but he can be friends with cuba ... crazyness :D
[00:49] <koda> kierank: 50 years in international politics is 5 months in foss mailing list ;)
[00:50] <koda> Compn: well i am not saying that michaelni should stop merging (even though it would be beneficial) just that the ffmpeg community could be more gentle towards libav
[00:51] <Daemon404> beneficial my ass
[00:51] Action: Compn focuses on getting baptiste and ffmbc merged
[00:51] <timothy_gu> is anyone still using ffmbc?
[00:51] <kierank> yes
[00:51] <iive> it have always been a niche player
[00:51] <kierank> anyone who needs dvcpro hd to work
[00:52] <Daemon404> maybe if niche means things like "the entirety of the bbc"
[00:52] <koda> Daemon404: i am not joking, look at openoffice and libreoffice, their fork (and not merging) made wonders :)
[00:52] <Compn> it has active ts developer...
[00:52] <koda> same with xfree and xorg
[00:52] <Compn> i think
[00:52] <koda> and any other normal fork
[00:52] Action: Compn doesnt follow much
[00:52] <timothy_gu> koda: I disagree
[00:52] <koda> competition = improvement for everyone
[00:52] <Daemon404> works wonders?
[00:52] <Daemon404> openoffice is dead
[00:52] <Daemon404> xfree is dead
[00:52] <iive> nah... xfree86 died in the moment of the fork. it had 1 developer left.
[00:52] <Compn> openoffice sucks so hard :\
[00:52] <timothy_gu> They are both as bad as heck
[00:53] <koda> Daemon404: well it didnt work because all capable developers left, but that was not the case with ffmpeg no?
[00:53] Action: Daemon404 thinks koda is the sole person interested in continuing endless fork politics years later
[00:53] <Compn> Daemon404 the enabler
[00:53] <koda> Daemon404: no, but i am the only one who is suffering from 5 year old drama
[00:53] <kierank> you're the only one!!!!!oneone
[00:53] <kierank> ???
[00:53] <koda> that led at least 2 people walk away
[00:54] <Compn> >oh boy here we go
[00:54] <Daemon404> >4chan
[00:54] <koda> that was more emo than necessary :p
[00:54] <koda> one of the many :)
[00:54] <iive> koda: imho, far more than 2
[00:54] <kierank> they would have walked away for other reasons as well
[00:55] <koda> perhaps...
[00:55] <koda> but my point that having two groups competing rather than one group merging still stand
[00:55] <kierank> competing to do what
[00:56] <kierank> making things annoying for api users?
[00:56] <koda> mplayer and mpv, another example
[00:56] <Daemon404> not really
[00:56] <Daemon404> mplayer is beyond dead
[00:56] <Compn> youtube still likes us :P
[00:56] <koda> Daemon404: youre in presence of several mplayer devs, please be respectful :p
[00:56] <Daemon404> Compn, iirc theyre movign entirely away from mplayer
[00:56] <Compn> us = mplayer i mean
[00:56] <Daemon404> binary loader is ded bro
[00:56] <koda> kierank: oh right, right now it is so much better
[00:57] <Daemon404> koda, they dont deserve respect
[00:57] <Daemon404> they wrote mplaye.r
[00:57] <kierank> koda: basically yes
[00:57] <j-b> vlc ftw
[00:57] <Compn> mplayer doesnt have too many active devs (because it works without them!)
[00:57] Action: j-b starts vlc-ng
[00:57] <Daemon404> j-b always lurking to troll mplayer
[00:57] <Compn> unlike vlc that keeps breaking simple features
[00:57] <Daemon404> i approve
[00:57] <iive> unfortunately mplayer is still better than vlc :|
[00:57] <j-b> Daemon404: always.
[00:57] <Daemon404> iive, in what dimension?
[00:58] <Compn> so hows the debian ffmpeg+mplayer fight going ?
[00:58] <j-b> badly
[00:58] <Compn> we lost lena.pnm 
[00:58] <ubitux> if it can avoid digging into ff/av politic history again, maybe that's a good thing we flame about mplayer vs vlc
[00:58] <Compn> to the war...
[00:58] <Daemon404> ubitux, mplayer devs vs world?
[00:58] <Daemon404> i thibk thats what you meant.
[00:58] <j-b> that was stupid, to remove lena
[00:58] <Compn> hahaha
[00:58] <j-b> ubitux: sorry, but that war was lost years ago
[00:58] <Daemon404> well
[00:59] <j-b> ubitux: go in your street tomorrow, and ask a random dude about VLC
[00:59] Action: koda is not discussing politics, just expressing his opinion
[00:59] <Daemon404> if there's a group i dislike more than mplayer.. it's debian
[00:59] <j-b> do the same, about mplayer
[00:59] <Daemon404> despite myself using debian
[00:59] <j-b> Daemon404: systemd?
[00:59] <Compn> Daemon404 : wow i didnt know you disliked mplayer so bad :P
[00:59] <iive> Daemon404: is ffmpeg 3'd or 4'th?
[00:59] <Daemon404> j-b, i dont give 2 shits about systemd
[00:59] <Daemon404> as a user it affects me in precisely 0 ways
[00:59] <koda> ffmpeg integrated in systemd, that could be a nice backdoor to land in debian :D
[01:00] <ubitux> we are already in debian, just like systemmd
[01:00] <j-b> Daemon404: except /var/log, but yes
[01:00] <iive> ffmpeg is already in debian.
[01:00] <Daemon404> iive, ffmpeg is a distant Nth place
[01:00] <Compn> iive : who was that debian guy who always reviewed mplayer and wrote badly about it ? think he will do a new article about mplayer ? :D
[01:00] <Daemon404> there are far more terrible things in fossland
[01:01] <j-b> the lack of open source porn
[01:01] <j-b> I agree
[01:01] <Daemon404> j-b, wrong
[01:01] <Daemon404> there are several FOSS VNs
[01:01] <j-b> oh, oh
[01:01] <Compn> theres r34 too
[01:02] <Daemon404> j-b, there's even one VN that was closed source, but linked to xvid.dll to decode its intro, so they opened it up when facing GPL violations
[01:02] <koda> j-b: fossporn++
[01:02] <Daemon404> now that's trollin'.
[01:03] <j-b> VN?
[01:03] <koda> 3D?
[01:03] <Daemon404> visual novel
[01:03] <Daemon404> in the west: hentai games
[01:03] <Compn> Daemon404 thinks we all know his animu porn code names 
[01:03] <Compn> :P
[01:04] <Daemon404> foss multimedia is pretty inbred with japanophiles
[01:04] <Daemon404> so probably.
[01:14] <iive> that awkward silence... I think somebody went too far...
[01:15] Action: timothy_gu hides
[01:15] Action: Compn hides behind timothy_gu
[01:19] <BBB> Compn: from where do you get the information that youtube still likes you?
[01:19] <BBB> (both the likes without the still, as well as the still part of the liking, if there was any ever at all)
[01:20] <Daemon404> he meant that youtube used to use mplayer's binary loader probably
[01:20] <BBB> the still and used to are counterintuitive
[01:21] <aetas> what in the world are you people talking about
[01:21] <Daemon404> ignore it
[01:21] <Daemon404> its all trolls
[01:21] <aetas> lol
[01:23] Action: Daemon404 does just that, goes to get a cream ale and watch a movie
[01:23] <aetas> what exactly caused the ff/av split anyway?
[01:24] <koda> i was not around at that time, but from what i can gather there was disagreement in the project management
[01:24] <koda> THEN A LOT OF DRAMA
[01:24] <koda> and two communities were born
[01:24] <aetas> well drama is usually assured in any fork
[01:25] <koda> yes, what is not assured is that a fork merges from another project with completely different design goal and purpose
[01:25] <ubitux> and here we go again...
[01:26] <timothy_gu> aetas: https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav#ffmpeg-and-libav-history https://libav.org/about.html  http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
[01:26] <timothy_gu> yep, here we go
[01:26] <iive> aetas: the usual cause of drama is big ego's...
[01:26] <koda> timothy_gu: ubitux: i am just expressing my view, feel free to share yours
[01:27] <kierank> koda: sigh
[01:27] <koda> timothy_gu: aetas read also another point view https://libav.org/about.html
[01:27] <koda> history paragraph
[01:27] <koda> kierank: sup
[01:27] <ubitux> timothy_gu just gave that link
[01:27] <koda> ah lol
[01:27] <ubitux> it's the page where it says libav is a fork
[01:28] <timothy_gu> koda: lol
[01:28] <koda> ubitux: and your point being..?
[01:28] <aetas> I never understood why debian would choose a side in any of this
[01:28] <iive> it took them a lot of time to admit that they are a fork. Diego still disputed that claim.
[01:29] <iive> aetas: debian as any organization is vulnerable to the people. The packager was one of the fork sides.
[01:29] <jamrial> aetas: afaik, guy that maintained the ffmpeg package ended up in the libav side of this after the split, so he made debian move to it
[01:30] <iive> he just did it. there is nobody to ask or to hold him accountable.
[01:30] <aetas> imo a software distribution should not be taking sides in a disagreement between unrelated parties as long as including both is justified
[01:30] <aetas> they already have a ton of packages for software that does the exact same thing
[01:31] <koda> aetas that was because at that time the majority of devs switches sides, so debian was dealing witht the choise of going either with the group he knew and trusted, or go with a group that, despite talented, did not know
[01:31] <koda> just that
[01:31] <ubitux> not really
[01:31] <aetas> why would it be necessary to choose one over the other anyway?
[01:31] <iive> koda: actually no, this is what they said.
[01:32] <ubitux> the packager was on libav side and just decided to package the fork
[01:32] <koda> not really
[01:32] <iive> koda: the packager signed the takeover notice
[01:32] <koda> iive: ffmpeg without people it;s just a name without meaning, its the people behind it that make it great
[01:32] <ubitux> ffs are you really going to make your propaganda here?
[01:32] <iive> koda: there were plenty of ffmpeg developers after the fork.
[01:33] <ubitux> not even ffmpeg devs are doing that on your channel
[01:33] <koda> iive: sure, they were just not known to the debian community
[01:33] <koda> ubitux: i dont see what you are talking about
[01:34] <aetas> sounds like something a distribution should've never gotten involved
[01:34] <koda> aetas: i think they tried, hoping that the drama would resolve itself
[01:34] <iive> koda: I'm telling you, the debian community was not involved. If I am wrong, I'd like to see the discussion
[01:34] <aetas> they involved themselves by not allowing both of them
[01:35] <koda> aetas: but that did not happen unfortunately, and any attempt as been dubbed as trolling
[01:35] <ubitux> "they" didn't try anything, they ignore it and trusted the packager which was on libav side
[01:35] <koda> not really
[01:35] <iive> YES, they trusted the packager.
[01:35] <iive> they trust their own people
[01:35] <iive> as does any other organization.
[01:36] <timothy_gu> See https://lists.ubuntu.com/archives/technical-board/2011-May/000894.html Mark Shuttleworth didn't even reply to Michael's email in the thread
[01:36] <aetas> that doesn't mean there should just be 1 packager picking one over another.  if its a problem with packaging, have someone else do ffmpeg
[01:36] <timothy_gu> That's ubuntu of course but they are the same
[01:36] <timothy_gu> aetas: Yes and that's what gentoo is doing
[01:37] <timothy_gu> (and what Debian is doing now.)
[01:37] <ubitux> aetas: ppl were annoyed and too lazy to read the torrent of mails
[01:37] <ubitux> aetas: so they waited for things to get more peaceful and trusted the person in power
[01:37] <ubitux> at that time, the libav packager
[01:37] <iive> aetas: you should have seen for yourself how hard is getting a new package in debian.
[01:37] <koda> aetas: its not so simple, there is a ton of work in packaging, having a library such as lavc and lavf, a lot of security work is involved and just having two difficult libraries is not going to fly in most orgs
[01:38] <aetas> if a project forks with 2 different groups of developers, there's no reason not to consider them 2 packages really....just seems strange that for something like open-source, they would disclude software for that reason
[01:38] <timothy_gu> koda: oh come on
[01:38] <ubitux> the problem is solved anyway nowadays
[01:38] <iive> aetas: it is not fair, but it happens.
[01:38] <timothy_gu> koda: see the three mysql-compatible libs in debian
[01:38] <ubitux> it took years to get back in, because the technical arguments was not enough
[01:38] <aetas> meh.  I love debian, I guess I just expected more from them
[01:39] <koda> i expected more from ffmpeg ^^
[01:39] <iive> aetas: they make mistakes, sometimes huge. e.g. systemd one
[01:39] <ubitux> yes please move to another stupid troll so i can go to sleep
[01:39] <ubitux> let's all go back to sysv
[01:39] <aetas> lol
[01:39] <koda> ubitux: i dont know why you think i am trolling, i am camly expressing my view
[01:40] <koda> its not that when someone expresses a different opinoin is trolling
[01:40] <ubitux> i wasn't talking about you
[01:40] <koda> ah, i thought you did, given the propaganda message before
[01:41] <timothy_gu> what does "camly" mean? Did you mean "candidly"?
[01:41] <ubitux> koda: right now i was just talking about the topic
[01:41] <aetas> as for me, I just asked for informative reasons
[01:41] <ubitux> koda: and a troll (the person) is funny, you are not
[01:41] <koda> ubitux: why did you have to add this last phrase?
[01:41] <iive> ubitux: that hurts...
[01:42] <koda> didnt your mom teach you that its better not to say something if its needlessly bad
[01:42] <ubitux> i thought you were going to make a funny mom joke but it seems not
[01:42] <ubitux> too bad
[01:42] <ubitux> :(
[01:42] <aetas> south park kind of annihilated that
[01:43] <koda> ubitux: maybe i would have, but then youd use that quote out of context somewhere and my reputation would be screwed :D
[01:43] <iive> it did?
[01:43] <ubitux> koda: it's already screwed for different reasons, don't worry about it
[01:43] <aetas> we're in the age of "get over it" :p
[01:43] <koda> ubitux: why do you say that?
[01:44] <ubitux> koda: you don't need me to act like a fool
[01:44] <iive> PewDiePie come to rescue!
[01:44] <koda> ubitux: i feel like youre just insulting me for no reason
[01:44] <koda> ubitux: i am trying to understand why
[01:45] <koda> so i can either improve myslef or change your mind
[01:45] <ubitux> i'm not going to play your stupid game tonight, and i'm going to sleep
[01:45] <ubitux> 'night all
[01:45] <aetas> night
[01:46] <koda> ubitux: oh well maybe you think that because my propaganda is in public rather than by PMs?
[01:46] <koda> i am just guessing now :(
[01:46] <aetas> you just admitted it was propaganda!
[01:47] <aetas> *gasp*
[01:47] <koda> lol
[01:47] <koda> its propaganda
[01:47] <iive> nah...
[01:47] <iive> too late to cover it up.
[01:47] <aetas> yeap, its in everyones logs
[01:47] <koda> again, if expressing a point of view is propaganda so be it
[01:48] <koda> aetas: going back on topic, my biased view is that all those keystrokes to write those emails trying to convice people to anyone to switch
[01:48] <koda> would be better spend trying to backport what is really needed and asked by the community
[01:48] <koda> cherry picking the necessary patches
[01:48] <iive> propaganda is usually point of view that is not entirely correct, intentionally biased and misrepresented.
[01:50] <aetas> I just don't consider ffmpeg/libav to be on-part with a system-level package so choosing one over the other seems silly
[01:50] <aetas> on-par*
[01:51] <aetas> its not like the Xorg split or anything after-all
[01:51] <iive> well, usually it is the fork that tries to avoid conflict with the original. not changing api was also one of the tug-of-war aspects.
[01:51] <aetas> yeah it does seem to be fairly identical albeit with less features
[01:51] <iive> and ffmpeg tried to remain abi/api drop-in replacement of libav.
[01:52] <iive> even when libav was not compatible with itself.
[01:52] <aetas> I found this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203#787  which has most of my views on it
[01:53] <aetas> people get so wrapped up in things
[01:53] <iive> andreas is great.
[01:55] <aetas> yeah he seems more logical and less emotional about his views
[01:56] <koda> iive: when was libav not compatible with itself?
[01:56] <koda> aetas: thats only one side of the problem, the other is the library stability and api design
[01:56] <aetas> not compatible with itself?  what does that even mean?
[01:57] <iive> koda: i don't remember what it was exactly... they broke the abi and didn't notice it. ffmpeg had some really ugly hack to workaround it. maybe about year ago?
[01:57] <timothy_gu> yeah the lls stuff
[01:58] <aetas> is there even really that huge of a difference between the two at this point to have justified the fork?
[01:58] <timothy_gu> aetas: so libav added some SIMD optimization to a part of libavutil that broke the API without noticing it and bumping the SONAME version, making programs compiled for older libavutil segfault on new libavutils
[01:58] <aetas> ah
[01:59] <koda> aetas: not so much difference, the problem i see is that most of bugfixes are not upstreamed
[01:59] <koda> sorry ubitux is offended if say upstream
[01:59] <koda> bugfixes are not notified to the author
[01:59] <timothy_gu> aetas: I guess? See Sexy Libav section of http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
[02:00] <iive> aetas: imho, libav would die in about a year.
[02:00] <aetas> if they were going to fork the project, it seems like they would bother changing the naming schemes for libraries and such
[02:00] <aetas> yeah I dont know anyone actually using it for the most part
[02:00] <timothy_gu> koda: well bug fixes to the godly mpeg code are not notified to michael
[02:01] <koda> timothy_gu: no, because they are merged every day anyway
[02:01] <koda> aetas: why? libjpeg and libjpeg-turbo forked and didnot change api
[02:01] <koda> and lived happily ever after
[02:01] <koda> iive: this has been going for over 4 years and it has not happened yet
[02:02] <aetas> sure, but they're also compatible are they not?
[02:02] <iive> koda: oh, it already happened.
[02:02] <timothy_gu> koda: but im pretty sure libav devs like you and maybe wbs read ffmpeg logs every week
[02:02] <iive> koda: but open source software could show activity long after their death.
[02:02] <timothy_gu> koda, aetas: http://libjpeg-turbo.org/About/Jpeg-9
[02:02] <aetas> oh koda is a libav guy?  you let them sneak a spy into here? :p
[02:03] <timothy_gu> aetas: unlike libav we don't ban anyone
[02:03] <cbsrobot_> can we please move on ?
[02:03] <aetas> lol Im just plaing anyway
[02:03] <koda> aetas: sure exactly like ffmpeg and libav could, but are not for silly political reasons
[02:03] <koda> timothy_gu: who are you talking about
[02:04] <timothy_gu> koda: wbs?
[02:04] <koda> timothy_gu: who got banned?
[02:04] <kierank> omg
[02:04] <kierank> you are still going
[02:04] <timothy_gu> omg
[02:04] <kierank> fuck me
[02:04] <cbsrobot_> can we please move on ?
[02:04] <koda> iive: meh there is nothing to gain for ffmpeg if libav dies
[02:04] <timothy_gu> ok EOT
[02:04] <timothy_gu> *EOD
[02:04] <koda> we were having such a nice pacific discussion :(
[02:05] <kierank> nobody gives a shit about the stupid story any more
[02:05] <koda> aetas: anyway i guess you can count me as ffmpeg developer too, given how high is my shortlog rank :P
[02:05] <koda> kierank: timothy_gu apparently does
[02:05] <aetas> I do, I was the one that asked for clarification
[02:05] <kierank> he said she said
[02:06] <aetas> its important to know the differences and reasons for how things are, imo
[02:06] <kierank> then read the article
[02:06] <iive> koda: we could hope to gain few more developers. if they are not hell bent of destroying ffmpeg and taking down the evil dictator.
[02:06] <aetas> articles can be as biased as anything else can
[02:07] <kierank> "FFmpeg development channel "
[02:08] <kierank> emphasis on development
[02:08] <kierank> not rehashing the past
[02:08] <aetas> we're discussing ABI and compatiblity so it seems pretty relevant
[02:08] <iive> koda: don't get me wrong. It's not that we want to kill libav... but that is what is happening.
[02:08] <aetas> although has gotten somewhat side tracked I admit ;)
[02:09] <iive> koda: in a sense, libav could either evolve or go into obscurity. and i don't see it evolving.
[02:09] <koda> iive: how can it evolve if everything is merged back though :/
[02:10] <koda> aetas: i feel like i had a good discussion until i started getting insulted for no apparent reason :(
[02:10] <aetas> I'd support just bringing back everything in.  It doesn't seem like there are enough non-political differences to justify a fork
[02:10] <iive> i'm talking mostly about development. libav have stuck with outdated and inefficient model.
[02:11] <iive> it places more burden on developers for no additional gain.
[02:11] <koda> you do realize its the development model chosen by the linux kernel =P
[02:11] <iive> also, merge it too. don't waste time to rewrite patches.
[02:12] <iive> koda: definitely not.
[02:12] <aetas> frankly the only reason I had ever heard of libav was because one day it popped up on my debian install and i just assumed it was a name for the ffmpeg libraries
[02:12] <koda> iive: why not? no patch lands in the kernel tree if it was not reviewed
[02:13] <koda> not even linus's
[02:13] <koda> -s
[02:13] <aetas> seems a little insane to compare the linux kernel which is like the holy bible of the community to ffmpeg
[02:13] <iive> aetas: it is the biggest and most successful project.
[02:14] <koda> dunno, i was just talking about the development model
[02:14] <aetas> which, the kernel or ffmpeg?
[02:14] <iive> koda: linus merges into its tree, without review :)
[02:14] <koda> lolwaht
[02:14] <aetas> iive: I just meant the kernel as system-breaking capability
[02:15] <iive> koda: he trust the people who maintain the major systems. all the review is going on there.
[02:15] <timothy_gu> koda: everything lands on Linus' tree without review
[02:16] <iive> and that also means that each system could have slightly different methods of working.
[02:17] <iive> but the main lesson you have to learn about linux development is that it is decentralized. and git with its horrible non-linear history is perfect illustration for that.
[02:18] <koda> iive: umh, libav has a pretty linear tree, and this is in part thanks to the review policy
[02:19] <koda> its merging something daily that destroys any repo
[02:19] <iive> ffmpeg does daily merging... it's still alive :)
[02:20] <koda> sure, because libav is alive too
[02:21] <iive> it still walks. i wouldn't say it is alive.
[02:21] <aetas> who else other than vlc is using it anyway?
[02:22] <koda> well, ffmpeg =P
[02:22] <aetas> that in itself doesn't sound like a reason to keep a fork going
[02:23] <koda> aetas: well how i got insulted before pretty much shows how some people cant work together
[02:24] <aetas> honestly thats to be somewhat expected after forking off from a project, Im just asking about actual technical differences, not emoitonal ones
[02:24] <aetas> politics and feelings don't really interest me
[02:25] <iive> the forking is not the reason for the bad blood. the hostile takeover 2 months before that is the real reason.
[02:25] <koda> iive: wait we said not reashing the past :p
[02:25] <iive> basically, ffmpeg and libav were together during that time and it wasn't petty.
[02:26] <iive> pretty.
[02:26] <aetas> still, for things to exist because of bad blood and not for technical differences usually just drags down development
[02:26] <koda> aetas: my point is that there cannot be technical differences if one project merges from the other
[02:27] <koda> except api and abi stability
[02:27] <koda> across versions i mean
[02:27] <aetas> that sounds like the project doing the merging is likely the one that hasn't lost sight of its development
[02:28] <koda> aetas: or that it just gave up its sight of development, blindly following what the other does
[02:28] <iive> aetas: what i find most amusing is that there are new developers that are equally passionate about the split, without actually seeing it for themselves.
[02:28] <koda> which is sad, in my opinion
[02:28] <aetas> there's no way one project is going to continue development if its only merging code into itself and not have original development
[02:29] <aetas> it sounds like the other team is just ignoring anything they produce instead
[02:29] <cone-41> ffmpeg.git 03Michael Niedermayer 07master:99f8c9e4d177: avcodec/hevc: move qp_block_mask to where its used
[02:29] <cone-41> ffmpeg.git 03Michael Niedermayer 07master:3281fa892599: avcodec/hevc_ps: Check diff_cu_qp_delta_depth
[02:29] <koda> yes, because its normal in forks, two teams do not want to deal with each other again
[02:30] <koda> however this has been prevented with the daily merge :/
[02:30] <iive> that's the linux model, merge from many sources.
[02:30] <aetas> like I said, emotional issues drag down development.  if one team is willing to accept code from the other then they're the one in the right as far as I'm concerned
[02:32] <koda> aetas: sure they are in the right to do so, its just less right not to inform the patch author of a problem
[02:32] <koda> tbh i am fine with the merges, its just this lets not inform the author of a bug he introduced so that our software is better'
[02:32] <aetas> as opposed to the other team who isn't willing to cooperate?
[02:33] <koda> aetas: if they did not want to cooperate, they would have just hidden the repo, switched licenses and released tarballs like ffmbc does
[02:34] <aetas> that doesn't sound very open-sourcey or even maintainable
[02:34] <koda> sure but its what ffmbc does and lo
[02:34] <aetas> you can't really attract devs that way
[02:34] <koda> no merges
[02:34] <koda> one happy fork
[02:34] <aetas> I haven't a clue what that is
[02:34] <timothy_gu> and 0 happy users
[02:34] <aetas> lol tim, thats my point
[02:35] <aetas> you cant attract people that way
[02:35] <koda> sure, but you can develop happily on your own
[02:35] <koda> and being non collaborativie
[02:35] <iive> well... a lot of libav decisions are taken that way.
[02:35] <aetas> then its a personal project and isn't comparable to an actual open-source one
[02:36] <timothy_gu> are you saying it's good?
[02:36] <koda> iive: not really
[02:36] <timothy_gu> cuz it's kinda ambiguous from your comment of "one happy fork"
[02:36] <koda> timothy_gu: if he wants to do his own little thing why not
[02:36] <aetas> the single dev and user probably is ;)
[02:37] <koda> aetas i quoted ffmbc just to point out an example of non collaborative team, libav team has been pretty collaborative afaict
[02:37] <timothy_gu> aetas: thing is people actually use ffmbc according to kierank
[02:37] <aetas> how can we compare one guys personal project to a community project
[02:37] <koda> aetas: ffmbc has a vivid community
[02:37] <iive> koda: really. e.g. a lot of things are discussed on irc. but unlike ffmpeg there is no irc log. so if somebody wants to know why something is done this way and not the other... though luck.
[02:38] <koda> iive: umh no, most discussions are done on the ML
[02:38] <aetas> anything without a wikipedia page doesn't exist in my world :p
[02:38] <koda> lol
[02:38] <koda> guys id like to continue but i need to catch some sleep
[02:38] Action: timothy_gu shouts "I have one!"
[02:38] <iive> me too.
[02:38] <aetas> lol do you?
[02:38] <timothy_gu> yeah it's a user page
[02:39] <timothy_gu> User:Timothy Gu
[02:39] <koda> thanks for discussing this calmly and without lowering to insulting people
[02:39] <aetas> as in a contributor page?
[02:39] <timothy_gu> yeah, but in wikipedia, "User page"
[02:39] <aetas> I don't see why the other guys were fussing.  You can discuss something without dragging emotions into it
[02:39] <timothy_gu> koda, iive: good night
[02:40] <koda> good night
[02:40] <iive> have fun.
[02:40] <aetas> hey tim, is there a technical reason why there are no timeline-based filters?
[02:41] <timothy_gu> aetas: huh?
[02:41] <aetas> like adjusting presentation times or what-not
[02:41] <timothy_gu> http://ffmpeg.org/ffmpeg-filters.html#Timeline-editing ?
[02:41] <aetas> right but all those require decoding and reencoding video frames
[02:41] <timothy_gu> or do you mean cutting and piecing parts together?
[02:42] <aetas> that would be one example but mainly to do that without having to decode and re-encode things when not necessary
[02:42] <timothy_gu> yeah that's true, but again P/B frames are weird when filtering
[02:42] <aetas> like copying frames over while adjusting timestamps
[02:42] <aetas> shouldnt they be fine as long as you keep them in order?
[02:42] <timothy_gu> we do have some bitstream filters that can be applied without reencoding
[02:42] <timothy_gu> http://ffmpeg.org/ffmpeg-bitstream-filters.html
[02:43] <timothy_gu> but again it's just a matter of developers' will
[02:44] <aetas> one thing I've been trying to do is adjust flash video which can have a video/audio stream which has maybe a few seconds between video frames and readjusting their ptses so that there isn't such a huge gap between them
[02:44] <aetas> realtime-recorded video often has gaps like that
[02:46] <timothy_gu> I'm not really the right person to ask on these technical subjects, but IIRC there isn't any way to do that in FFmpeg itself. Again the most likely reason for this is a lack of developers who would like to add this feature
[02:46] <timothy_gu> or companies who would like to sponsor someone to do things like this in FFmpeg
[02:47] <aetas> I had been looking into it.  I can understand having to decode packets to get frame information but I didn't see a reason why they couldn't just decode the frame for the pts information and then toss it out and adjust the timing on the packets instead
[02:48] <aetas> still, you gave me more information than I had on it
[02:49] <aetas> would be nice to be able to transcode information dealing with timing but in a loss-less way
[02:49] <timothy_gu> actually bitstream filters just filter the bitstream, without any metadata like pts/dts, so it might not help you
[02:50] <aetas> I was looking at how ffprobe works mainly since it can pull that information down
[02:51] <aetas> it seems able to access all of that information easily so combining that with how to adjust timing on frames was my hope
[02:56] <Compn> BBB : that youtube still uses mencoder for some codecs? from google person at vdd hosted in google docks at dublin 2014 2 months ago
[02:58] <Compn> "like" maybe a strong word, but google cannot rely on reverse engineering for all codecs, of course you can understand
[02:58] <aetas> Compn: wbs said he didn't know much about rtmpdump ;)
[02:59] <Compn> aetas : then /q hyc  , the rtmpdump developer
[02:59] <Compn> main devel*
[02:59] <Compn> aetas : also sorry to send you to wbs, i wasnt sure who was active...
[03:00] <aetas> I know.  I think the main problem is no one really does it seems like so I wouldn't blame you for not knowing either.
[03:01] <Compn> well its complicated :P
[03:01] <aetas> Im still surprised it has such a small developer base despite being used in quite a few projects
[03:01] <Compn> since there are basically 3 different groups working on rtmpdump and not communicating with each other
[03:01] <aetas> 3 groups?
[03:01] <Compn> the two groups are linked in the forum links on http://rtmpdump.mplayerhq.hu
[03:03] <aetas> Im familiar with the zeranoe one but all of these groups still seem to pull source down from the git repository
[03:03] <aetas> so I could never figure out exactly who is running the thing
[03:03] <Compn> svnpenn and ksv have their own patches 
[03:04] <aetas> gross
[03:04] <Compn> https://github.com/K-S-V/Scripts/releases
[03:04] <Compn> is ksv's repo
[03:04] <Compn> hes on the stream-recorder forums
[03:04] <Compn> we just cant have nice things
[03:05] <Compn> so each downstream rtmpdump-using project just picks whatever works and goes from there
[03:05] <aetas> this seems like a nightmare for bugfixes
[03:06] <Compn> not sure anyone is watching bugfixes on debian or distros etc
[03:06] <timothy_gu> Compn: that repo doesn't have any patches
[03:06] <timothy_gu> the real patches are in http://stream-recorder.com/forum/customized-rtmpdump-binaries-patch-file-t16103.html 
[03:07] <timothy_gu> My guess is that you have to register to download the attachments, otherwise they are not shown
[03:11] <Compn> timothy_gu : https://github.com/K-S-V/Scripts/releases , click on rtmpdump-2.4.zip green button
[03:11] <Compn> in the zip is patch.diff
[03:11] <Compn> created 11-3-2014
[03:11] <Compn> (ignore githubs' created date)
[03:11] <Compn> and this, this gentlemen, is why i asked for some devs to help rtmpdump project :P
[03:12] <Compn> otherwise we have one big patch.diff .
[03:12] <aetas> this is a huge mess
[03:12] <Compn> meh, its working
[03:13] <Compn> "working" . dont try to fix it, you may scare or harm developer ego
[03:13] <aetas> to have a project in such wide use yet no one really knowing whats going on is insane
[03:13] <aetas> lol
[03:13] <Compn> fixes get fixed pretty quick, some developers are getting paid to work on it and fix certain sites...
[03:13] <Compn> the perfect open source project :P
[03:13] <Compn> ehe
[03:14] <aetas> yeah but how does any of that make it into upstream is the question
[03:14] <Compn> it doesnt, unless patches are sent to list, and anyone commits it
[03:14] <timothy_gu> Compn: ah
[03:14] <Compn> of which i havent been able to lure any new devs to the project 
[03:14] <timothy_gu> missed it
[03:14] <aetas> I sent one in, nothing ever happened to it though
[03:14] <Compn> do you want to be a committer aetas ? :P
[03:15] <timothy_gu> I mean, I can "maintain" it but I lack the expertise to fix any bugs present
[03:15] <Compn> i'm not even a programmer and i have commit rights :P
[03:15] <Compn> ehe
[03:16] <Compn> so yeah, same problem if no one reviews the patches you dont really know if the fix is right or not 
[03:16] <aetas> I think the main problem is there's no information on how to get patches in at this point and the project's website looks from pre-AOL era
[03:16] <Compn> of course if it fixes a url...
[03:16] <Compn> aetas : patches to update the site are welcome
[03:16] <Compn> vlc should take over rtmpdump project
[03:17] <Compn> hey j-b , does vlc use librtmp ?
[03:17] <Compn> or did you reinvent that wheel ?
[03:17] <aetas> no I believe they do
[03:17] <Compn> ffmpeg/libav also has reinvented rtmp ...
[03:18] <Compn> so ffmpeg can be built against librtmp or native rtmp
[03:19] <aetas> I had thought vlc used libav to do it although I do see a librtp_plugin library in here
[03:19] <Compn> rtp isnt rtmp
[03:19] <Compn> not sure if typo or not , but theres rtmp, rtsp, rtp
[03:20] <Compn> too many network protocols
[03:20] <Compn> aetas : anyways, i'm open to suggestions. i'm just not good at organizing a project.
[03:21] <aetas> here we go
[03:21] <aetas> VLC supports RTMP and rtmp:// URLs as of version 1.1, through the avio module via the libavformat library. In past versions, use of rtmpdump was required in conjunction with VLC, but that is no longer needed after VLC 1.1.x.
[03:21] <Compn> especially when i'm not getting paid for it, and rtmpdump has had huge drama in the past...
[03:21] <Compn> ok then
[03:22] <aetas> and since they pull from librtmp...
[03:25] <aetas> heh, saw your email btw, hidden in a mix of a bunch of spam happy bday messages
[03:26] <Compn> all my mail goes to spam it seems :\
[03:26] <Compn> must be my lack of punctuation
[03:26] <aetas> I wish these would.  I don't need a bunch of websites auto-congratulating me on my birthday
[03:27] <Compn> one reason why i never give out any accurate info when registering an account 
[03:27] <Compn> :)
[03:27] <Compn> instead of spam on my birthday, its birthday spam on random days (or jan 1st)
[03:27] <aetas> they're bound to email you at some point in the year though ;)
[03:27] <aetas> lol
[03:27] <Compn> haha right
[03:28] <Compn> aetas : to answer your question about changing pts with a filter of flash video... there are some pts tricks in ffmpeg, but i dont think theres a filter for that
[03:28] <Compn> what kind of programs do you use now to modify the pts ?
[03:28] <Compn> i'm just wondering what the pts interface should look like ?
[03:29] <aetas> I generally use ffprobe to output all the pts info and then parse it as needed into a complex filter with a chain of trims and concats
[03:29] <aetas> this works up to a certain point although if there are too many gaps then ffmpeg complains and bails out
[03:32] <Compn> i mean, you dont use any pro software like fcp or avid / blackmagic etc
[03:32] <Compn> you've looked at -genpts and the other -vf fixpts stuff in ffmpeg ?
[03:33] <Compn> probably wont help... but always worth a shot
[03:34] <Compn> er i guess -vf fixpts is mplayer filter, not ffmpeg.
[03:34] <aetas> the problem mainly is that there can be a delay in just the video stream for instance while the audio stream may have packets containing pts' that exist within that gap so you can't really just edit one stream without breaking sync
[03:35] <aetas> with ffmpeg, you can't generally "share" information in filters between streams you are editing so there isn't a way to edit in realtime
[03:36] <Compn> i'm curious what the problem video looks like ?
[03:36] <Compn> i mean, is it jumpy or something? why is the pts even an issue? just reencoding ?
[03:36] <Compn> "if the video and audio are in sync, why is the pts an issue" i guess is what i'm trying to ask
[03:37] <aetas> the video is variable framerate so there'll be gaps with no frames in between and it just looks like the video froze during that time until it receives a new frame although it could be playing audio while the video is frozen just fine
[03:37] <Compn> do you have example flv file that shows this problem you can share ?
[03:38] <aetas> Im sure I can dig something up
[03:38] <Compn> theres also -vf decimate ;)
[03:39] <Compn> which just drops duplicate frames
[03:39] <aetas> I think thats where the confusion is coming from
[03:40] <aetas> there aren't duplicated frames, there are just frames with big gaps in the pts
[03:40] <aetas> so one frame may be 1.526s, the one after it may be 4.871s for instance
[03:40] <Compn> ah
[03:40] <Compn> so one frame will have fps of 5 , the rest of the frame fps are 30
[03:40] <Compn> i see
[03:41] <aetas> and unless you want to sit there for 25seconds, its good to just drop the gap in between ;)
[03:41] <Compn> i want to see a sample. i'm curious about it now haha
[03:42] <aetas> now you can do this on a per-stream basis by trimming a piece and then concating the pieces back together but it can't keep sync with audio because you're changing the timestamps on a per-stream basis
[03:42] <aetas> so audio frames for instance could be 5s and maybe the next one be like 27s
[03:43] <aetas> using your example above, you would then create a desync problem
[03:43] <Compn> right
[03:43] <Compn> it just sounds like your stream is broken
[03:43] <Compn> horribly
[03:44] <Compn> what streaming software creates such nonsense ? 
[03:44] <aetas> its actually introduced by any hiccups in bandwidth or connection speed delays
[03:44] <aetas> its hard to avoid those all the time with realtime recording
[03:44] <Compn> instead of buffering .... you mess with pts
[03:45] <aetas> well if you record with like rtmp, then buffering won't necessarily help since its not getting frames from the server
[03:45] <aetas> err rtmpdump
[03:46] <Compn> i have no idea then :)
[03:46] <cone-41> ffmpeg.git 03Michael Niedermayer 07master:61296d41e2de: avcodec/h264: Check *log2_weight_denom
[03:46] <aetas> Ill have to find a video but lemme show you a small clip of ffprobe dump
[03:46] <Compn> i knew a guy that took live recorded rtmp h264 and had to hand copy frames over because the flash server or rtmpdump dropped a few seconds out of every few minutes :D
[03:47] <Compn> in a NLE like sony vegas
[03:47] <Compn> but each recording would drop a different section. he set up a few different recordings of the same stream. insanity
[03:49] <aetas> all the commercial software that records streams like that generally have an option named "fix pts" which modifies the pts for each although they basically assume a constant framerate so while it does fix the gaps, it usually introduces desync also
[03:50] <Compn> so how are you fixing it again ? by duplicating frames or ? 
[03:50] <Compn> if you drop the 25 second gap... wouldnt that mean desync ?
[03:50] <Compn> or its 25 seconds of blank ? 
[03:51] <aetas> I use video as a reference so if I find a gap of like above 1-2 seconds or whatever amount, then it writes a trim that ends when the gap starts and a second trim that starts where the gap ends and then concats the two as if the gap never existed
[03:51] <aetas> oh, no but I dont get desync only because I am also dropping the audio gap as well
[03:51] <Compn> ok so its a blank gap you are recording
[03:51] <Compn> and you are trying to drop all of that blank audio/video
[03:51] <Compn> i gotcha
[03:52] <aetas> basically you don't see any freezes in the video but the audio will jump if there are any video jumps as well
[03:52] <aetas> which should be expected
[03:53] <Compn> imo the streaming software is broken
[03:53] <Compn> or rtmpdump
[03:53] <Compn> somewhere :P
[03:55] <aetas> what would you expect rtmpdump to do?
[03:55] <aetas> I mean its recording the correct timestamps of when things happen, just that theres a gap between what it receives
[03:55] <Compn> well i dont know if its rtmpdump making the pts or the streaming server
[03:55] <Compn> i dont record live streams much :)
[03:57] <aetas> the server does
[03:57] <aetas> and if you play back what rtmpdump recorded, it plays it exactly as what you would see if you watched it in flash
[03:57] <aetas> which includes the 30 second gap ;)
[03:58] <Compn> dont mind me, sometimes i'm retarded.
[03:59] <aetas> right now afaik, all of those timeline editing filters require decoding and reencoding which becomes an expensive process
[03:59] <aetas> I mean if you're just adjusting timestamps somewhat, you're incurring the encoding speed as well as quality loss
[04:00] <Compn> right, you'd need a purely pts demuxer/muxer filter  , not a video filter
[04:02] <aetas> basically, yeah.  Im guessing there just hasn't been a huge need for it
[04:04] <aetas> here ya go http://pastebin.com/RrBkgYsr
[04:05] <aetas> this is an excessive case of it, not usually typical
[04:09] <aetas> there's also some really unusual behavior where the video stream's I frames all have PTS starting from 0 while the P frames start at some number like 300 seconds in advance and both types of frames' PTS increase as they normally should but with a huge gap between.  I have no fricking idea what causes that :p
[04:11] <Compn> well if you upload a sample and make a bugreport asking for a filter to fix it, maybe the devs can look into a new pts filter :)
[04:13] <aetas> thats one of the reasons I was asking about it because I wanted to know if there was a technical reason that had prevented ffmpeg from creating one at this point before looking to get my hands dirty
[04:15] <aetas> I don't mind looking into it myself, I just wanted to know I wasn't wasting my time first ;)
[08:36] <ubitux> saste: you replied to the wrong mail
[08:36] <ubitux> this is not the last version of the patch
[08:48] <saste> ubitux, it *is* the last in my inbox
[08:49] <ubitux> strange
[08:58] <saste> ubitux, can dctdnoiz used as a generic fft filter?
[08:58] <saste> *be used
[08:58] <saste> I meant something like http://david.li/filtering/
[08:58] <saste> *I mean
[08:59] <saste> I proposed to implement that to arwa
[09:03] <ubitux> no it's not generic
[09:03] <ubitux> it will probably be kind of slow if you make it generic
[09:03] <ubitux> i mean, you have an eval system though
[09:03] <ubitux> you can actually try to do something like that
[09:04] <ubitux> actually yeah that might be possible
[09:04] <ubitux> just filter the freq differently
[09:05] <saste> ^ arwa
[09:05] <ubitux> i mean it already has the eval system in plac
[09:05] <ubitux> place*
[09:05] <ubitux> just find a cool eval expression ;)
[09:05] <arwa> what is meant by filtering the freq differently?
[09:06] <ubitux> arwa: http://ffmpeg.org/ffmpeg-filters.html#dctdnoiz see "expr" option
[09:06] <saste> ubitux, any reason you're not using libavcodec routines for DCT/FFT?
[09:08] <ubitux> float
[09:08] <ubitux> i needed a float dct 8x8 and dct 16x16
[09:08] <ubitux> and idct
[09:08] <ubitux> i didn't find anything in libavcodec that has: dct and idct for both sizes in float
[09:09] <ubitux> there aren't much 16x16 dct btw, the only i know are vp9 and hevc
[09:10] <ubitux> but we don't have a forward dct for those, nor float versions (which is not mandatory thought but would need adjustements in the rest of the code)
[09:12] <ubitux> saste: what would be really cool is a way to add test for filters using floats.
[09:12] <ubitux> that could be something we can ask to arwa
[09:12] <ubitux> because contrary to codecs, we have tons of filters working with floats
[09:12] <ubitux> which are hard to make tests for
[09:13] <ubitux> we probably need a test with thresholding on the result or so
[09:13] <ubitux> blend filter might help
[09:13] <ubitux> not sure what we can do, but that could really help a lot libavfilter
[09:13] <ubitux> anyway, gtg, afk for about an hour
[14:41] <ubitux> rhaaa
[14:41] <ubitux> who thought it was a good idea to enable automatically qtkit?
[14:41] <ubitux> it breaks compilation on OSX by default apparently
[14:43] <wm4> heh
[14:43] <wm4> just like when I updated my GPU drivers, and system ffmpeg libavutil wanted opencl references
[14:44] <wm4> because opencl is so useful for ffmpeg
[14:44] <wm4> (this is why ffmpeg should be not so monolithic)
[14:46] <ubitux> opencl doesn't need to be explicit?
[14:46] <ubitux> mmh actually it doesn't seem to be the problem, but it's compiled anyway, not a good idea
[14:55] <Elirips> Anyone an idea whats wrong with my 'tee' ? This line works: 'ffmpeg -i rtsp://webcam -c:v libx264 -x264opts keyint=15 -an -r 5 -f flv rtmp://localhost:1935/hls/axis5fps' but, not if I try the same using tee: 'ffmpeg -i rtsp://webcam -c:v libx264 -x264opts keyint=15 -an -r 5 -f tee -map 0:v "[f=flv]rtmp://localhost:1935/hls/axis5fps"' - fails with 'av_interleaved_write_frame(): Broken pipe'
[15:06] <akira4> ubitux, could you have a look at this diff? http://pastebin.com/UEXppeQW 
[15:06] <akira4> I'm getting a seg fault in the read_close function.Everything seems fine to me though.
[15:07] <nevcairiel> Elirips: tee wants to output to stdout so you can pipe it somewhere else, but if stdout is not connected to anything it'll fail. your command makes no use of that, so why even use tee?
[15:07] <nevcairiel> or at least thats how i understand tee
[15:08] <Elirips> nevcairiel: hm, maybe I get this all wrong. Currently I run two ffmpeg instances, with exactly the same params, except the last part is 'rtmp://hls/stream' for one and 'rtmp://flash/stream' for the second one. I thought with tee I could avoid running two instances wasting memory
[15:08] <nevcairiel> in any case, shouldnt you be having two outputs for tee to make sense
[15:10] <Elirips> What I would like to have would be this: 'ffmpeg -i rtsp://webcam -c:v libx264 -x264opts keyint=15 -an -r 5 -f tee "[f=flv]rtmp://localhost:1935/hls/axis5fps|[f=flv]rtmp://localhost:1935/flash/axis5fps'"
[15:10] <Elirips> I guess something like that ^^^ should be more efficient than starting two ffmpeg instances 
[15:10] <Elirips> but maybe tee cannot do that?
[15:10] <nevcairiel> i think it should
[15:11] <nevcairiel> but maybe it doesnt handle some situation properly that ffmpeg itself handles when outputting to one output
[15:12] <Elirips> maybe the rtmp
[15:13] <Elirips> I'll just try to let nginx-rtmp duplicate things
[15:14] <BtbN> You are streaming twice to it? Just configure two outputs for your source oO
[15:14] <BtbN> One hls, and one rtmp
[15:15] <Elirips> BtbN: yes, I am streaming to it twice and I feel thats kinda stupid :P
[15:16] <Elirips> but at least I finally have a page that works on the i- and android-stuff and using flash for the rest of the world - :)
[15:16] <BtbN> I'm quite sure it has an example how to configure hls and rtmp output for a single stream
[15:16] <Elirips> Yes there are, but I did not get them working
[15:17] <Elirips> I was stuck because of I need an 'application flash' section and an 'application hls' section in the config-file, and these 'application names' then show up in the rtmp urls, and I did not get it
[15:18] <BtbN> Just put the hls and rtmp output stuff into the same source section?
[15:19] <BtbN> shouldn't be more than live on; hls on; and hls_path in one application
[15:19] <Elirips> ah, I thought if I specify the hls stuff in an 'application' this application will only work with hls, 
[15:20] <Elirips> I did not know that it is kind of 'or'
[15:20] <Elirips> I'll try that thx
[15:23] <Elirips> and its working perfectly :)
[15:25] <Elirips> See you next year and thx for the great tools 
[15:26] <Elirips> shutdown -h now
[16:22] <cone-762> ffmpeg.git 03Michael Niedermayer 07master:e59c28b16660: avcodec/adpcm: Check idelta
[17:28] <ubitux> akira4: do not free the private context
[17:29] <ubitux> and make sure you can close dvd->nav_data with it being NULL
[17:29] <ubitux> akira4: do not allocate the context yourself.
[17:29] <ubitux> +    if (!(dvd = av_mallocz(sizeof(DVDContext))))
[17:29] <ubitux> +        return AVERROR(ENOMEM);
[17:29] <ubitux> this is done automatically, don't do that
[17:30] <akira4> I see. Okay
[17:31] <ubitux> that should help with your crash
[17:32] <akira4> ah. It worked. Thanks :)
[17:38] <cone-762> ffmpeg.git 03Michael Niedermayer 07master:3ff8ef62bbb9: avfilter/vf_spp: Fix pointer type warning
[18:02] <cone-762> ffmpeg.git 03Michael Niedermayer 07master:4a06215c1aab: avfilter/vf_spp: add gray8 support
[18:02] <cone-762> ffmpeg.git 03Michael Niedermayer 07master:19ecd675c591: avfilter/vf_spp: add gbrp support
[19:10] <cone-762> ffmpeg.git 03Michael Niedermayer 07master:368642361f3a: avcodec/indeo3: ensure offsets are non negative
[19:21] <cone-762> ffmpeg.git 03Michael Niedermayer 07release/1.2:0da0d7754e74: avcodec/vmdvideo: Check len before using it in method 3
[19:21] <cone-762> ffmpeg.git 03Michael Niedermayer 07release/1.2:ece0c9c4b042: avcodec/utvideodec: Fix handling of slice_height=0
[19:21] <cone-762> ffmpeg.git 03Michael Niedermayer 07release/1.2:3aa99bed5df3: avformat/mov: check atom nesting depth
[19:21] <cone-762> ffmpeg.git 03Michael Niedermayer 07release/1.2:ec0f77fbff90: swscale: increase yuv2rgb table headroom
[19:21] <cone-762> ffmpeg.git 03Michael Niedermayer 07release/1.2:45bb57e009e4: avcodec/h264: make the first field of H264Context an AVClass
[19:21] <cone-762> ffmpeg.git 03Michael Niedermayer 07release/1.2:42b7d224bc59: avcodec/indeo3: use signed variables to avoid underflow
[19:21] <cone-762> ffmpeg.git 03Michael Niedermayer 07release/1.2:a9c0f905aa3b: avcodec/h264: Clear delayed_pic on deallocation
[19:21] <cone-762> ffmpeg.git 03Michael Niedermayer 07release/1.2:96e2a4ba7402: avcodec/h264: Check *log2_weight_denom
[19:21] <cone-762> ffmpeg.git 03Michael Niedermayer 07release/1.2:c60caa5769b8: avcodec/indeo3: ensure offsets are non negative
[20:21] <cone-762> ffmpeg.git 03Tristan Matthews 07master:f2c614e8c4a9: srtpproto: fix option flag type
[20:21] <cone-762> ffmpeg.git 03Michael Niedermayer 07master:4d5ca069c775: Merge commit 'f2c614e8c4a935b52bbf86819128d9e797230c20'
[20:30] <cone-762> ffmpeg.git 03Martin Storsjö 07master:01f251c44d83: rtpenc: Set the timestamp properly when sending mpegts data, too
[20:30] <cone-762> ffmpeg.git 03Michael Niedermayer 07master:c0586b257d9c: Merge commit '01f251c44d83eedc819625d2caac9ff9697a085d'
[20:38] <cone-762> ffmpeg.git 03Martin Storsjö 07master:42181740a397: rtpenc: Set the AVFMT_TS_NONSTRICT flag
[20:38] <cone-762> ffmpeg.git 03Michael Niedermayer 07master:7c0ab0a3b8e4: Merge commit '42181740a3972e17d0097d28fabc9a1a60322d47'
[20:54] <cone-762> ffmpeg.git 03Martin Storsjö 07master:df07c07b3de0: rtpdec_h263_rfc2190: Clear the stored bits if discarding buffered data
[20:54] <cone-762> ffmpeg.git 03Michael Niedermayer 07master:5d97af0cb2a6: Merge commit 'df07c07b3de0a5e8890078944de1eb5cb8372ef8'
[21:05] <aetas> any one of you guys around?
[21:11] <iive> when you ask this kind of question, people assume you want to discuss some very hard problem... so nobody would volunteer ;)
[21:12] <Compn> aetas: no one but us chickens
[21:13] <cone-762> ffmpeg.git 03Martin Storsjö 07master:91bfac759dfd: h261enc: Disallow sliced encoding
[21:13] <cone-762> ffmpeg.git 03Michael Niedermayer 07master:3d8bedef45a3: Merge commit '91bfac759dfd536e439ad3e35964705012c6a5a7'
[21:15] <aetas> sweet. I am quite hungry
[21:15] <aetas> and nah, I didn't need anything.  I just feel lonely when people aren't around
[21:15] <aetas> ;)
[21:16] <aetas> I was going to ask how you all got into dev for a large project like this, with its long history and such
[21:22] <wm4> aetas: start by writing patches
[21:22] <wm4> that's all
[21:22] <wm4> or maybe, you start with using it (?)
[21:25] <Daemon404> tl;dr user -> shit's broken -> dev
[21:26] <aetas> usually most projects have particular ways and histories behind them as to why things are as they are so I've always taken it to be a large undertaking
[21:26] <Daemon404> you really shouldnt here
[21:26] <Daemon404> it's ugly, and everyone is biased
[21:26] <kierank> people want their files to play
[21:26] <aetas> lol
[21:27] <aetas> well thats refreshing ;)
[21:33] <iive> aetas: imho, most developers came from projects that use ffmpeg, e.g. video players. that's why codecs are the most polished part
[21:35] <aetas> aren't those projects likely to be similarly mired in history and scale too? :p
[21:35] <iive> while ffmpeg participated in google summer of code, some of the successful students also stayed in active development long after their initial task.
[21:35] <Daemon404> most of them utterly failed though.
[21:36] <wm4> but yeah, there are only 2 reason you become a dev: 1. you get paid (doesn't usually happen), 2. you want to get something to work you care about
[21:36] <Daemon404> 3. anime
[21:36] <iive> isn't 3 part of 2.
[21:37] <Daemon404> its not so much getting something to work, as making it better
[21:37] <Daemon404> e.g. x264, to encode anime better.
[21:37] <wm4> lol
[21:37] <aetas> whats #4?  porn?
[21:37] <JEEB> nobody really cares about quality with porn
[21:37] <wm4> well there is some porn in the samples repo
[21:37] <aetas> lol
[21:37] <Daemon404> JEEB, that's a lie
[21:37] <Daemon404> anime people do
[21:37] <wm4> oooh
[21:37] <wm4> right
[21:37] <wm4> anime porn
[21:37] <iive> so, hentai?
[21:37] <JEEB> :D
[21:38] <aetas> isnt google summer of code for college kids?
[21:38] <Daemon404> yes
[21:39] <Daemon404> and we're banned from it for life now anyway
[21:39] <aetas> way behind that point then
[21:39] <Daemon404> for reasons.
[21:39] <wm4> remind me, what was the reason again
[21:39] <aetas> molest some of em?
[21:39] <Daemon404> i just told you.
[21:39] <Daemon404> reasons.
[21:39] <Daemon404> and also stuff.
[21:39] <Daemon404> maybe junk.
[21:39] <wm4> I know there's no official reason
[21:39] <jamrial> you forgot things
[21:40] <aetas> thanks for clarifying
[21:40] <wm4> and the ffmpeg vs. libav drama is apparently also not the reason
[21:40] <wm4> or is it?
[21:40] <wm4> I'm confused
[21:40] <wm4> also there was something with hitler
[21:40] <Daemon404> not hitler no
[21:40] <iive> yes, most foss project are done by students. once they get job they abandon them. unless they can find job working on them.
[21:40] <wm4> some dev used a bad word and google didn't like it
[21:40] <Daemon404> and it's all of videolan which is banned
[21:40] <wm4> for PC reasons
[21:40] <wm4> oh
[21:40] <wm4> well whatever the fuck
[21:40] <Daemon404> [20:40] <+wm4> some dev used a bad word and google didn't like it <-- no
[21:40] <iive> so a project need a constant inflow of students.
[21:41] <aetas> I program just for the hell of it, I just happen to have a job aligned with my interests.  Thought most people were the same.
[21:41] <Daemon404> i dont know many people who got involved due to their job
[21:41] <Daemon404> usually its the other way around
[21:42] <wm4> haha
[21:42] <wm4> j-b: why is videolan banned from gsoc?
[21:43] <kierank> why do bad thinks happen to good people
[21:43] <kierank> discuss
[21:43] <wm4> oh so the answer is "google is evil"
[21:43] <JEEB> life is derp, let's go shopping for hats
[21:43] <aetas> shush, they tried to hire me :/
[21:43] <aetas> I'd work there
[21:43] <kierank> having visited their offices I wouldn't
[21:43] <wm4> but?
[21:44] <kierank> it's a bit cultish
[21:44] <Daemon404> kierank, only a bit?
[21:44] Action: Daemon404 sends the stasi after kierank 
[21:44] <kierank> the google cushions, neon lights, stickers etc annoyed me
[21:44] <iive> aetas: BBB worked there.
[21:44] <aetas> once you drink the koolaid though, you're not conscious of it
[21:44] <wm4> stasi were the good guys (I mean compare them to modern cops)
[21:45] <iive> wm4: they fount lizzard aliens! ;)
[21:45] <iive> fought
[21:45] <Daemon404> i didnt know icke was stasi
[21:46] <aetas> what in gods name are you bunch talking about
[21:46] <iive> whatever sells more.
[21:46] <j-b> wm4: not only VideoLAN
[21:46] <j-b> wm4: all of us.
[21:47] <jamrial> "all of us"?
[21:48] <wm4> that sounds so grave
[21:48] <timothy_gu> "all of the multimedia community"/
[21:48] <timothy_gu> ?
[21:48] <aetas> no, all you individually.  you're now on a list somewhere forever
[21:49] <koda> ban all the devs!!!
[21:51] <iive> aetas: never heard of the lizzard aliens that look human and that are ruling the world, as secret cabal of Vatican, royal families, masons, Illuminati and Rockefeller? check out David Icke.
[21:51] <wm4> koda: developers developers developers developers developers 
[21:51] <koda> I LOVE THIS COMPANYYYYY
[21:51] <iive> hey, who let Ballmer in?
[21:52] <aetas> that doesnt seem like a productive use of my time :p
[21:52] <iive> aetas: it like second hand retelling of X-Files.
[21:53] <aetas> I've gotten my fill of that ever since watching the History channel's special on the history of zombies and ways to fight them off in the coming zombie apocalypse
[21:55] <iive> history channel... i have forgotten how crazy they are.
[21:56] <aetas> they have some occasionally good specials but they are dead to me now.  It feels ridiculous even describing what the program was about
[21:56] <aetas> like Im somehow exaggerating
[21:56] <iive> btw, I could really recommend you to watch "Ancient Alines - Debunked". 
[21:57] <iive> it's 3 hours, but the good stuff is in the first hour.
[21:58] <aetas> I'm more intereted in like Derren Brown's stuff, Through the Wormhole, etc
[21:58] <aetas> Mind Games in hulu is good
[21:58] <iive> watch the debunk, it actually have some interesting stuff.
[21:59] <ubitux> are you guys talking about animes or i can idle again?
[21:59] <aetas> I didn't really ever consider it needing debunking since none of it was based on actual fact
[21:59] <wm4> no they are talking about something much worse
[21:59] <aetas> anime has aliens
[21:59] <wm4> (never thought it'd be possible)
[21:59] <iive> e.g. I've learned from it about the internal ramp theory, that was used to build the great piramid. or the real purpose of the grand gallery in it.
[22:00] <aetas> and an obnoxious amount of robots
[22:00] <iive> yeh, anime at least is believable... with all these tentacles and aliens...
[22:01] <aetas> and their obsession with probing female bodies
[22:01] <jamrial> if the first thing you think about when you hear anime is tentacles, you need to watch other kind of anime :P
[22:01] <aetas> we were just trying to get ubitux involved in the conversation....you know....so it can relate to him
[22:02] Action: ubitux has absolutely no idea what's going on here.
[22:03] <aetas> no one does either so I wouldnt worry
[22:03] <j-b> timothy_gu: yes.
[22:05] <aetas> I usually get my anime talks out in my private torrent tracker's channel anyway
[22:07] <iive> well, saying you like anime is like saying you like hollywood movies. there are many genres.
[22:08] <aetas> hollywood movies are the reason I turn to anime
[22:09] <ubitux> hollywood movies could turn you into happy shit eaters quite easily
[22:10] <iive> don't worry, you'll eventually figure out the cliches that run in anime too. but at least they are not afraid to experiment with stuff.
[22:10] <wm4> of course aetas was an anime person
[22:10] <wm4> they are everywhere
[22:10] Action: kierank has never watch an anime
[22:10] <kierank> -ed
[22:11] <Compn> aetas : i had to give up on hollywood movies and animes, now i'm stuck watching foriegn cinema
[22:11] <aetas> lol eventually.  it doesnt take any amount of time.  robots, ridiculous use of coincidences, and clumsiness resulting in tripping into a girl's cleavage
[22:11] <iive> kierank: do you want to try it? It could be highly addictive!
[22:11] <kierank> no
[22:11] <Compn> kierank : never? no pokemons? wow
[22:11] <ubitux> iive: ofc animes are full of stereotypes crap, no question about that; but they're still as good as the best hollywood movies
[22:11] <kierank> oh that's true when i was 9 i watched pokemon
[22:12] <aetas> Reason I watch anime is because they touch storylines that we manage to screw up constantly.  Take the Dungeons and Dragons movies and anything scifi puts out
[22:12] <ubitux> damn where is the ffmpeg fortune thing
[22:13] <neXyon> when I want to encode a wav file does the sample format have to be planar?
[22:13] <neXyon> because right now avcodec_fill_audio_frame returns an error with AV_SAMPLE_FMT_S16
[22:14] <iive> aetas: anime is great for scifi, because the special effects don't const more.
[22:14] <cone-762> ffmpeg.git 03Yayoi 07master:0463df6f4241: avfilter/lut: reduce dereference in the inner loop
[22:14] <aetas> yeah, provided they don't toss robots into every single damn thing
[22:14] <jamrial> iive: not really. even for animation most studios resort to CG
[22:15] <aetas> I can't deal with any more mechs
[22:17] <Compn> votoms (the orginial version) is pretty good mech anime, because its not about the mechs :)
[22:17] <iive> aetas: everybody knows tanks and planes need legs and arms to fight!
[22:17] <iive> how else are they going to shoot their guns?!
[22:18] <aetas> except they'll put mechs into a fantasy show about swords and sorcery
[22:19] <iive> giant armors?
[22:19] <wm4> neXyon: it's better not to use avcodec_fill_audio_frame
[22:19] <aetas> yeap
[22:20] <wm4> neXyon: instead, set the AVFrame params, and then use av_frame_get_buffer to allocate an AVFrame
[22:20] <wm4> well, to allocate the frame data
[22:20] <aetas> I watch a fair amount, its just the over-use of robots in everything that gets annoying
[22:21] <iive> even the legend or korra did it.
[22:21] <neXyon> wm4: ok is there any tutorial or sample code that I could follow?
[22:21] <iive> of
[22:21] <aetas> yeah but they had technology in there so I can *somewhat* see that.  there's fantasy stuff like dungeons and dragons style that they've tossed them into and simply called them golems
[22:21] <wm4> neXyon: not that I know of
[22:24] <iive> aetas: maybe you pick up animes that have mechas ...
[22:24] <aetas> no, I purposely skip those
[22:25] <neXyon> wm4: ok thanks for the tipp anyway, I'll look into it
[22:25] <aetas> even that Count of Monte Cristo one despite it being set in the future they used swords the entire way through until they randomly just start dueling in mechs that had never even made an appearance before that point or afterwards
[22:26] <iive> i can't watch that anime.. i've heard it is good, but that flat texturing style ... 
[22:27] <aetas> I skipped it the first couple times initially too for that reason
[22:27] <wm4> neXyon: just allocate the AVFrame struct with av_frame_alloc, then set some parameters (at least format and sample count), then av_frame_get_buffer
[22:29] <neXyon> wm4: thanks
[23:02] <irsssssssssi> what the heck
[23:52] <cone-387> ffmpeg.git 03Reimar Döffinger 07master:de6d44829c43: aacps.c: Move large arrays to context to reduce stack usage.
[23:52] <cone-387> ffmpeg.git 03Reimar Döffinger 07master:70d80ed40fa3: qdm2: Allow hard-coding VLC tables.
[00:00] --- Fri Dec 19 2014