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

[burek]

[00:16] <cone-434> ffmpeg.git 03Clément BSsch 07master:a95a38793c75: lavfi/thumbnail: support flushing.
[00:18] <michaelni> wm4, j-b patch that exports qptable on ffmpeg-dev, ill apply it soon to fix this regression 
[00:19] <wm4> eh, didn't j-b want to drop postproc
[00:25] <ubitux> michaelni: how does that affect qp table usages in vf pp?
[00:25] <burek> saste, i think online docs are missing -b and -bt options described
[00:26] <michaelni> ubitux, it works as is but it needs a 1 line change for ABI compatibility
[00:26] <michaelni> that is avoid direct access
[00:26] <ubitux> ok
[00:29] <saste> burek: "b" and "bt" are codec options, and documented in ffmpeg-codecs.1
[00:29] <saste> but docs are still missing an explanation of how options are looked up in the various contexts
[00:29] <saste> which is indeed tricky
[00:29] <burek> saste, can you please give me an url
[00:29] <burek> to check it
[00:30] <saste> burek, to check what?
[00:30] <burek> online docs, of course
[00:30] <saste> ffmpeg-codecs.html
[00:30] <burek> http://ffmpeg.org/ffmpeg-codecs.html
[00:30] <burek> ?
[00:30] <burek> i dont see them there..
[00:30] <burek> try yourself please
[00:31] <saste> burek: http://ffmpeg.org/ffmpeg-codecs.html#Codec-Options
[00:31] <burek> oh..
[00:31] <burek> why is it quoted as 'b' and not as '-b'
[00:31] <burek> like all the other options?
[00:32] <burek> ok, i officially wont submit any more bugs from our forum, since cehoyos is really acting like a child
[00:32] <burek> and i dont have time for such thing
[00:33] <saste> burek, "-" is a prefix used by commandline, if you set an option programmatically (or through any other means, even with commandline as in vlc), the "-" is misleading
[00:34] <saste> OTOH, the docs say: Options may be set by specifying -option value in the FFmpeg tools
[00:34] <burek> well, ok.. but it is just so confusing that way
[00:34] <burek> i was just talking to some people who commented on changed docs layout and complaining they cant find options any more
[00:34] <burek> so i guess they were all searching for -b just like me..
[00:35] <burek> personally, i think this way it's more confusing to people..
[00:36] <saste> burek, the alternative is a huge monolithic page
[00:36] <saste> split docs has their pros and their cons
[00:36] <wm4> Please add the complete, uncut console output of your failing command.
[00:36] <wm4> hahaha
[00:36] <saste> for an expert user split docs are better (if you know where to look for)
[00:38] <burek> i know you guys try to make ffmpeg better, but sometimes it is ffmpeg's users that should judge about some things which concerns them the most, like the documentation for example
[00:38] <burek> i believe docs should be easy to read both for experts and newbees
[00:39] <Compn> saste : i'm fine with split docs if there is also a way to put all docs in one easy to read file :)
[00:39] <Compn> e.g. mplayer's single page vs split page docs
[00:39] <burek> and of course, there is no definitive answer to which layout of docs is better (either one huge or several split pages), otherwise everybody would follow that answer and we wouldn't be discussing it
[00:40] <ubitux> not that a full doc was never available in the first place
[00:40] <burek> php for example offers 2 variants of help docs, one huge html page and multiple split pages
[00:40] <ubitux> there were just huge monolithic duplicated parts in them
[00:40] <ubitux> which was completely unusable
[00:41] <ubitux> the split is definitely useful if you are able to choose between very few large categories
[00:41] <ubitux> which are all listed in the documentation page
[00:41] <burek> I would suggest that we create partial pages, like it is now, merging common options in the same files, and provide 2 variants also, one that is one huge page (simply includes all the page-chunks in one html page) and another is like multiple page layout, which also just includes all those page-chunks (texi files)
[00:42] <ubitux> merging the doc causes problem
[00:42] <ubitux> because you start documentating option not available in some tools
[00:42] <ubitux> unless you concat all the doc very carefully
[00:43] <j-b> wm4: no, I dont
[00:43] <ubitux> saste: do you think we can have a ffmpeg-all with all big documentation sections?
[00:43] <wm4> ok... I'm a bit sad
[00:43] <burek> i dont know, i think it would be easier to sort out docs once and then in the future just follow some kind of rules where do each options go and all we be satisfied
[00:43] <burek> after all, it would only be a matter of @include-ing texi files
[00:43] <ubitux> burek: "sort out docs"
[00:44] <ubitux> do you realize the amount of work it represents to work on the doc?
[00:44] <burek> an example?
[00:44] <saste> ubitux, i think so, but it could be tricky
[00:44] <ubitux> burek: there are 20k lines of documentation
[00:44] <j-b> wm4: ?
[00:44] <saste> burek, doc work is easily underrated, but sometimes i had to spend ~1h for 20 lines of docs
[00:44] <burek> ubitux, they are already grouped so it wouldnt be that difficult
[00:44] <wm4> j-b: that libpostproc will live forth
[00:44] <saste> multiplicate that for the number of patches i sent, and you get an idea
[00:45] <ubitux> burek: there are grouped into sections because merging them makes no sense
[00:45] <saste> consider also that my english sucks, so i need often to double check the spelling and the wording
[00:45] <ubitux> and creates confusion
[00:45] <j-b> wm4: you don't like it?
[00:45] <wm4> j-b: no, do you?
[00:45] <ubitux> burek: it is not an easy thing to do, despite what you seem/want to believe
[00:46] <burek> i'm just saying it would be easier for the future to group common options and per-tool options and organize such text in appropriate texi files, which would later be @included into final docs (either as one big help page or multiple split pages)
[00:46] <ubitux> burek: saste has been working a lot on documentation, and some other developers (me included) as well
[00:46] <ubitux> i think we give a fairly decent amount of our time working on improving it
[00:46] <saste> burek, that said it's not impossible, but it would be tricky
[00:46] <j-b> wm4: I don't have an opinion.
[00:46] <saste> also i'd like to migrate to a better toolchain soon or later
[00:46] <saste> as long as i'll have more time to do it (never?)
[00:47] <burek> it's interesting how people here (without any intent to insult anyone) always first go for an answer like "oh that's wrong/difficult" rather than for "if it would help make things better, what do you suggest, how it should be done"
[00:47] <saste> burek, read it like: "patches are welcome"
[00:48] <burek> i never said i underestimate time already involved, but i just say it could be made better, that's all
[00:48] <burek> saste, well, i know, but that kind of an attitude doesn't get community involved at all
[00:48] <ubitux> burek: improvements are welcome and can be discussed, but please don't say it's simple and we sucks at documentation all the time, because it's wrong
[00:48] <saste> burek, we're aware of the problems, but there is no easy solution
[00:48] <burek> and we are always stressing out how we lack developers, human resources and what not
[00:49] <burek> ok
[00:49] <ubitux> maintaining 20k lines of technical documentation in a meaningful way is *not* easy
[00:49] <ubitux> and every week several patches improve the documentation along with the code
[00:50] <burek> ok, i understand
[00:50] <ubitux> that is, we are happy to improve it, but it's not a priority for us, so... patch welcome
[00:50] <ubitux> but better discuss it before doing anything stupid such as merging everything, because a naive solution won't be accepted
[00:54] <bcoudurier> what's the latest release with frame threaded encoding ?
[00:54] <llogan> bcoudurier: finally getting tired of the ffmbc users asking for a new version?
[00:55] <j-b> Hello Baptiste!
[00:55] <bcoudurier> haha not really
[00:55] <bcoudurier> hey j-b, wassup ?
[00:55] <bcoudurier> I actually think frame threaded encoding is best thing that has happened since years :)
[00:55] <j-b> bcoudurier: the usual. With a bit more Android and Windows than usual
[00:55] <bcoudurier> and I want it
[00:55] <bcoudurier> but it depends on many other things
[00:55] <bcoudurier> so I might as well sync that shit ;)
[00:56] <j-b> and merging ffmbc features in ffmpeg.
[00:56] <j-b> ?
[00:56] <Compn> something something merge ffmbc and ffmpeg once and for all
[00:56] <bcoudurier> android ? pretty cool
[00:57] <bcoudurier> well, yes I should merge back too
[00:57] <j-b> bcoudurier: and don't ask me why, but we have hundreds of people asking us for more MXF and IMF in VLC.
[00:57] <j-b> bcoudurier: those people complain that supposedly QT Pro is now dead
[00:57] <j-b> as with FCP.
[00:57] <j-b> So they moved to Windows or need a better QT
[00:58] <bcoudurier> guys, about the FATE stuff, it's pretty important that all client make sure to use fate.ffmpeg.org, otherwise shit's gonna break :)
[00:58] <bcoudurier> ah well good for VLC
[00:59] <bcoudurier> FCP is far from dead though from my end
[00:59] <bcoudurier> anyway gotta go, we'll talk more later 
[01:00] <ubitux> bcoudurier: did you see my message about the fate upgrade?
[01:00] <ubitux> (publicly, here)
[01:10] <j-b> michaelni: would you consider coming to Paris, for VDD, this year?
[01:15] <Compn> there, burek , making me reproduce the bug myself , lol
[01:15] <burek> :) sorry about that :)
[01:16] <Compn> at least its easy with links to win32 versions and such
[01:16] <Compn> you're just lucky i run super low res on my monitors :D
[01:17] <ubitux> saste: i need some hints about the format negociation in lavfi
[01:17] <burek> Compn :beer: :)
[01:18] <ubitux> saste: if i configure only the input links, what is assumed for the output link?
[01:18] <ubitux> the same as what goes in? (basically assume the filter is not going to do any convert)
[01:19] <Compn> burek : btw i think the problem is carl couldnt reproduce, if he closed bug 'works4me' would that have been ok ?
[01:19] <Compn> he closed bug 'needsmoreinfo' because it 'works4me' ...
[01:19] <wm4> shouldn't ideally the person knowing the ffplay SDL code best reproduce this?
[01:19] <Compn> burek : so please continue reporting bugs... just sometimes devs cant reproduce you know? :)
[01:20] <Compn> wm4 : whos ffplay sdl maintainer ?
[01:20] <wm4> dunno
[01:20] <Compn> heh
[01:20] <Compn> probably michael, and he ... cant reproduce it
[01:20] <burek> :)
[01:20] <burek> ok :)
[01:21] <Compn> at least we know BBB can reproduce :D
[01:21] <Compn> wont stop braggin about his kid
[01:21] Action: Compn funny guy
[01:22] <wm4> Compn: looking at the git log, I'd say Marton Balint
[01:22] <saste> ubitux, it depends
[01:22] <saste> iirc lavfi assumes the same values for the output
[01:22] <saste> this is done at the framework level (avfilter.c or audio/video.c)
[01:25] <cone-434> ffmpeg.git 03Clément BSsch 07master:9efcfbed9dd6: lavfi/ebur128: fix format negociation for output.
[01:26] <ubitux> saste: yep, thanks :)
[01:27] <ubitux> saste: gonna take a look at the examples in a moment
[01:27] <ubitux> will you be up for the next hour?
[01:42] <Compn> ugh thats an annoying fullscreen bug 
[01:45] <ubitux> BBB: about _deps/_select:
[01:45] <ubitux> 14:41 <@michaelni> ubitux, AFAIK/IIRC deps disable "it" when the dependancies arent there, "select" enable the dependancies when "it" is there, suggest enables dependancies when they are not disabled but does not disable "it" when they are disabled
[01:45] <ubitux> 14:42 <@michaelni> again above is from memory so maybe not 100% correct
[01:45] <ubitux> 14:42 <@michaelni> either way its bad design as you have to brute force rename between dep and select when changing defaults
[01:46] <michaelni> ubitux, btw if that above is correct then it should be put in some docs
[01:47] <michaelni> trac wiki might be best so everyone can contribute and improve not just devels
[01:51] <ubitux> or just in the configure :P
[01:51] <ubitux> as a comment on top of the lists
[01:52] Action: michaelni wonders if people will find it there
[01:52] <michaelni> but its alot better there than nowhere
[01:52] <ubitux> developers should
[01:59] <wm4> why is there no AVBufferSrcParams? currently you have to use printf() to build an option string for it...
[02:01] <wm4> ah nevermind, l. doesn't do this anyway
[02:02] <ubitux> we have an option builder iirc
[02:03] <wm4> doesn't help me with l. anyway
[02:03] <ubitux> but i'm not sure what you are talking about
[02:03] <wm4> they still use sscanf for option parsing
[02:03] <wm4> I'm talking about configuring buffersink/src
[02:04] <ubitux> mmh
[02:04] <ubitux> at one point we had an opaque initializer along with the string args
[02:04] <ubitux> to allow such config
[02:04] <ubitux> they decided to remove it for some reason
[02:05] <saste> ubitux, it's still there
[02:06] <saste> as for options, you still need to provide a string encoding the options
[02:06] <saste> at some point we may have an AVDictionary interface
[02:06] <ubitux> saste: afaik it's not transmitted anymore to the init function
[02:06] <ubitux> so we can't do that
[02:06] <saste> init2
[02:06] <ubitux> oh?
[02:06] <ubitux> nice
[02:06] <saste> i reintroduced it because i needed it
[02:06] <wm4> AVDictionary can't handle lists or pointers
[02:07] <saste> wm4, opaque
[02:07] <saste> ugly maybe, but there
[02:07] <ubitux> buffersrc doesn't use the opaque field anyway
[02:07] <ubitux> that won't help much
[02:07] <ubitux> saste: i don't see any init2
[02:08] <ubitux> init_opaque, ok
[02:08] <saste> buffersink
[02:08] <saste> the same technique could be used for buffersrc
[02:08] <saste> in case of need
[02:08] Action: saste goes to sleep...
[02:08] <ubitux> btw we can remove the sscanf in buffersrc
[02:09] <wm4> without breaking anything?
[02:09] <ubitux> yes sure
[02:09] <wm4> btw. my dream is forcing l. and f. developers to support avplay.c and ffplay.c respectively
[02:10] <ubitux> i meant with our magic function to support named args and short hands
[02:10] <ubitux> what do you mean?
[02:11] <wm4> compile ffplay.c with Libav, and avplay.c with FFmpeg
[02:11] <wm4> it fails -> developer is punished with fixing it
[02:12] <ubitux> Nicolas and Michael were working on making avconv build with the ff libs
[02:12] <ubitux> and check if it was passing their fate
[02:13] <ubitux> wm4: about the named arguments, see http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=ae732640ab3415a661a88b7c9cbd9691a07a67ca for example
[02:13] <ubitux> av_opt_set_from_string() is e
[02:14] <ubitux> you can mixed anonymous form ("a:b:c") and named one ("x=a:z=c:y=b") : "a:z=c:y=b"
[02:14] <ubitux> so it's very handy to remove the old sscanf
[02:15] <wm4> why does that remind me so much of the mplayer syntax (which I deemed a bad idea, and which I'll remove as soon as I untangle all the code)
[02:17] <wm4> I'd still recommend adding Lua or so to build the filters instead
[02:17] <wm4> especially if you target complex usage (e.g. building a real graph), this will make things simpler for everyone
[02:18] <ubitux> Lua is on the GSoC page
[02:19] <ubitux> having a string representation of the parameters is relatively nice
[02:19] <ubitux> and since it's now independant from the way options are set
[02:19] <ubitux> this syntax can be changed very easily
[02:20] <wm4> yeah, that's isn't really a problem in this context, and in fact the option parser is a bit better than sscanf for eventual Lua support
[02:22] <wm4> and as a reminder: you can look at vapoursynth how these things should be done (other than using cython, this thing has a good design IMO)
[02:24] <wm4> also I observe decoded AVFrames are still not correctly marked as writeable if they're not ref-frames
[02:25] <ubitux> the option parsing in VS sucks
[02:25] <ubitux> they don't have a generic option parser for filters yet
[02:25] <wm4> how so?
[02:25] <ubitux> so they need to manually get every single option
[02:25] <ubitux> lot of code duplication all around
[02:25] <wm4> huh
[02:25] <wm4> the scripting frontend does this
[02:26] <ubitux> http://code.google.com/p/vapoursynth/source/browse/trunk/src/filters/vivtc/vivtc.c#759
[02:26] <ubitux> explain me this then
[02:26] <wm4> and they need to know the individual options and types to map them to parameters
[02:26] <wm4> well they don't parse options to structs
[02:26] <wm4> instead they have getters
[02:26] <wm4> that's not worse
[02:27] <ubitux> yes, and manual defaults settings
[02:27] <wm4> options can be optional
[02:27] <wm4> that's how it's handled
[02:27] <ubitux> all options are optionnal
[02:27] <ubitux> in ffmpeg as well
[02:27] <wm4> AFAIK no
[02:27] <ubitux> manual check is required for mandatory options
[02:28] <ubitux> which doesn't appear often
[02:28] <wm4> from what I remember, options can be marked as mandatory
[02:28] <ubitux> i was talking about ffmpeg sorry
[02:29] <ubitux> anyway, i believe the option parsing in ffmpeg is actually quite nice
[02:30] <wm4> while ffmpeg's option parser does more validation, it means you're stuck as soon as you have an option that doesn't map cleanly to what ffmpeg provides
[02:30] <ubitux> not really
[02:30] <ubitux> do you have any example in mind?
[02:30] <wm4> vsynth just tries to reduce coupling and complexity by making the filters do it
[02:30] <wm4> it's a tradeoff, and I guess vsynth's goal of very-long time compatibility is a reason
[02:31] <ubitux> i think it's done that way in VS because the project is just young
[02:31] <wm4> well, what if an option is a list of strings, of which each item is from a set of allowed strings (and this set is known at runtime only)
[02:32] <wm4> VS also exports all allowed options and types as metadata (think reflection)
[02:32] <wm4> this would have to cover allowed value ranges too etc.
[02:32] <ubitux> but the whole option in a string parameter, parse manually that parameter in the init()
[02:32] <wm4> lots of complexity to be found here
[02:32] <ubitux> s/but/put/
[02:32] <wm4> ubitux: so how is this better than VS ;)
[02:32] <ubitux> in the case of the exception it's the same
[02:32] <ubitux> in 99% of the other case it's better
[02:32] <wm4> uh
[02:33] <wm4> you could create a helper that maps the VS options to a ffmpeg-style parser
[02:33] <ubitux> i can't think of much manual settings in most of the filter
[02:33] <wm4> trivial
[02:33] <wm4> but if you get to the scripting side of things etc.
[02:33] <wm4> VS wins
[02:33] <wm4> due to lower complexity overall
[02:33] <wm4> I don't know if the VS option API was intentionally kept simple, but that sure would be a very good reason
[02:33] <ubitux> we're just changing subject here
[02:34] <ubitux> or maybe just not talking about the same thing
[02:34] <wm4> anyway: VS exports options, lavfi doesn't, VS wins
[02:34] <ubitux> i was just saying it was a pain to extract and manually control every single option in the filter scope
[02:34] <ubitux> this complexity doesn't exist in FFmpeg
[02:35] <wm4> again: you could create a helper that parses VS options ffmpeg-style
[02:35] <wm4> it's really simple
[02:35] <ubitux> about the options representation parameter, which is another problem, yes i know you don't like it
[02:35] <wm4> because the VS API allows this kind of generic access to options
[02:35] <ubitux> a helper where?
[02:35] <ubitux> i don't understand what you say
[02:35] <wm4> doesn't matter, the point is: it doesn't have to be part of the stable filter API
[02:35] <wm4> it could be provided by the VS SDK
[02:36] <ubitux> okay
[02:36] <wm4> or just be put into the filter's source directly (and again: wrt. long term stability, this is better)
[02:36] <wm4> I know ffmpeg and specially lavfi doesn't care about long term ABIs and such
[02:36] <wm4> but VS does
[02:37] <ubitux> i'm pretty sure a lua-like syntax parser would be very easy to do on top of the options
[02:37] <ubitux> at least for that part, not the integration itself
[02:37] <wm4> could be
[02:38] <ubitux> mapping blafilter(123, "foo", x = 3132.12) into a "a=123:s=foo:x=3132.12" should be very difficult
[02:38] <ubitux> (internally speaking)
[02:38] <wm4> you forgot a "not"?
[02:38] <ubitux> yes
[02:39] <ubitux> just need to deal with escaping properly, but we just added an escaping api recently (or we're going to?)
[02:39] <wm4> if you're really going to use Lua, I'd say pass tables instead of arguments
[02:39] <wm4> blafilter {123, "foo", x = 31}
[02:39] <ubitux> lavu: add escape API
[02:39] <ubitux> we have it.
[02:39] <ubitux> whatever the syntax
[02:39] <michaelni> wm4, I do care about long term ABI but its impossible with merges from libav ...
[02:39] <wm4> uh so the Lua thing is supposed to build a string? at least add a AVDictionary API then
[02:40] <wm4> michaelni: it's also impossible with dozens of public fields everywhere
[02:40] <Daemon404> ah good old lavfi
[02:40] <ubitux> wm4: yes the lua interface will likely do this to communicate with filters
[02:40] <Daemon404> so much complexity everywhere
[02:40] <wm4> michaelni: breaking ABI is kind of inherent to ffmpeg's overall API
[02:40] <Daemon404> forever and for always.
[02:40] <michaelni> about listing options per filter, AVOptions support it, see ./ffmpeg -h full as example
[02:40] <ubitux> wm4: doesn't matter the AVDictionnary, it's only exposed publicly anyway; and yes we can build the options with an av_dict already.
[02:40] <ubitux> that function is already available afaik
[02:41] <ubitux> again it's a gsoc
[02:41] <ubitux> wanna be the student?
[02:41] <ubitux> Daemon404: you're mistaken
[02:41] <Daemon404> i think youre the one who is mistaken~
[02:41] <ubitux> there is not much complexity
[02:42] <ubitux> there are currently limitations on the way they are exposed, true
[02:42] <ubitux> but i'd say most of the internals is pretty well done
[02:42] <Daemon404> then why is it i was able to pick up and write a VS filtr in an hour
[02:42] <Daemon404> and i STILL dot understand lavfi
[02:42] <Daemon404> after weeks of looking at it
[02:42] <Daemon404> dont*
[02:42] <ubitux> Daemon404: a trivial filter is very easy to do nowadays
[02:42] <wm4> as someone who has added lavfi support to his project, I agree with Daemon404 
[02:43] <wm4> and that's from _outside_ with the "simple" API
[02:43] <ubitux> wm4: limitations on the exposition, as i said
[02:44] <ubitux> anyway, i'm back working on ffmpeg
[02:44] <wm4> btw. I suppose currently lvfi options are not exposed? i.e. string-only
[02:44] <ubitux> 'got some stuff to get done, instead of fooling around with whinny users :)
[02:44] <Daemon404> wm4, https://groups.google.com/forum/?fromgroups=#!topic/rvideo/ZIiMmWHUXB4
[02:44] <Daemon404> i like to quote the last sentence of the first paragraph
[02:44] <Daemon404> quite often
[02:45] <michaelni> "<wm4> michaelni: breaking ABI is kind of inherent to ffmpeg's overall API" <-- this is not the case, there are just some basic rules that have to be followed, like not removing or reordering fields in structures and such
[02:45] <wm4> "ffmpeg does what ffmpeg is gonna do, the world be damned."? haha
[02:45] <Daemon404> ye
[02:45] <Daemon404> s
[02:45] <Daemon404> this reminds me
[02:45] <Daemon404> i shuld try rebuilding my code with the latest merges
[02:45] <wm4> michaelni: I'm familiar with how C ABI stability works
[02:45] <Daemon404> (evil plan)
[02:46] <Daemon404> inb4 massive breakage...
[02:48] <michaelni> besides, improvments are welcome, ABI, lavfi, anything ... /me goes back to do usefull work
[02:48] <Daemon404> for my own sanity, i just follow master
[02:48] <Daemon404> and keep compatability with that
[02:48] <Daemon404> end of story (tm)
[02:49] <wm4> oh yeah, I had quite fun making my code work with all the latest releases (and that's just the latest releases...)
[02:49] <Daemon404> ffmpeg doesnt have releases
[02:49] <Daemon404> just unmaintained snapshots
[02:49] <Daemon404> that randomly get backports
[02:49] <wm4> the most annoying thing is actually removed deprecated functionality, while the old releases don't support the replacements yet...
[02:49] <wm4> yeah I noticed
[02:49] Action: ubitux wonders what his whiteboard marker is doing in the dried fruit box
[02:50] <Daemon404> wm4, integrated a git clone into your configure script and hijack ffmpeg's configure
[02:50] <Daemon404> duh
[02:51] <michaelni> <Daemon404> ffmpeg doesnt have releases <-- me sees a volunteer who wants to take over maintaince of a release :)
[02:51] <wm4> I'm working on a mplayer fork, not mplayer itself
[02:51] <Daemon404> no
[02:51] <Daemon404> because your release model is INSANE
[02:51] <ubitux> ?
[02:51] <Daemon404> like a billin concurrent releases
[02:52] <Daemon404> that may or may not get updated
[02:52] <Daemon404> DROP SOME
[02:52] <ubitux> i see fixes getting backported
[02:52] <Daemon404> to SOME.
[02:52] <ubitux> Daemon404: who cares?
[02:52] <ubitux> just don't use it if you don't like it
[02:52] <ubitux> what's the problem?
[02:52] <Daemon404> i dont thin you really grok teh idea of a stable release
[02:52] Action: Daemon404 sigh
[02:52] <ubitux> you're not doing that work
[02:52] <Daemon404> think*
[02:52] <michaelni> Daemon404, you must hate linux
[02:52] <michaelni> they make many releases too
[02:53] <wm4> <ubitux> just don't use it if you don't like it
[02:53] <wm4> <ubitux> what's the problem?
[02:53] <Daemon404> they actually maintain them
[02:53] <wm4> I... what.
[02:53] <Daemon404> and track fixes
[02:53] <wm4> that's a really strange attitude
[02:53] <Daemon404> and have this thing called a long term release
[02:53] <ubitux> wm4: i meant just don't use the old stable branch if you don't need them
[02:53] <michaelni> Daemon404, like i said you are welcome to pick any subset or 1 release and maintain it
[02:53] <ubitux> wm4: what's the problem since it doesn't affect master and other branches?
[02:53] <ubitux> wm4: sorry for the very bad wording
[02:54] <Daemon404> michaelni, the point is to actually have a process to maintain ALL stable release
[02:54] <ubitux> (btw, on a side note, i found funny that one of the very little stable branch or libav doesn't even build)
[02:54] <Daemon404> otherwise there is no flipping point
[02:54] <Daemon404> to having so many
[02:54] <ubitux> (i wonder how that's possible)
[02:54] <j-b> Daemon404: not to mention that the release numbers make 0 sense, compared to libav* numbers...
[02:54] <Daemon404> j-b, no version of either project makes any sense
[02:54] <Daemon404> also theyre 100% useless version #s
[02:54] <j-b> release 1.2 with libavc 55.0
[02:54] <j-b> sooooo logical
[02:54] <Daemon404> since all libs have sep version #s
[02:55] <Daemon404> which are entirely different
[02:55] <j-b> but still depend on each other :)
[02:55] <Daemon404> yes
[02:55] <Daemon404> and may or may or noverlap with master at some point
[02:55] <Daemon404> or not overlap*
[02:55] <j-b> and growing 0.8 release number of libavc can overlap with versions from 0.9 or 1.0 release...
[02:55] <wm4> I'm just glad I can drop libav 0.8
[02:56] <Daemon404> yes because i get yelled at when i say "dont backport features"
[02:56] <wm4> because it's over a year old in terms of code...
[02:56] <Daemon404> wm4, sane things ike vlc just choose a git hash and say "we use this"
[02:56] <j-b> Daemon404: choosing the right one is still black magic guess :)
[02:56] <Daemon404> :P
[02:56] <ubitux> wow seems we have 3 guys bitching about ffmpeg in the same place; don't you guys want to use all that energy to help us instead? :)
[02:57] <j-b> ubitux: you really think I don't have enough craziness to manage?
[02:57] <michaelni> j-b, i dont think we messed up lavc nums in the release branch, you flame ffmpeg for some forks acts ?
[02:57] <Daemon404> notice how we're all downstream users, ubitux 
[02:57] Action: Daemon404 runs
[02:57] <wm4> j-b: do you maintain some sort of stable snapshot for VLC?
[02:57] <ubitux> Daemon404 :)
[02:57] <j-b> wm4: of course.
[02:57] <ubitux> Daemon404: you should complain on #ffmpeg then
[02:57] <wm4> j-b: i.e. you merge fixes into your snapshot?
[02:57] <j-b> michaelni: no, your versionning has ALWAYS sucked, fork or not.
[02:58] <j-b> You do a great job, but I don't think you understand what releases are.
[02:58] <j-b> and yes, I think the current version of FFmpeg should be named 55.x, not 1.2
[02:58] <j-b> wm4: yes.
[02:58] <wm4> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhhhhhhhhh yeeeeeeeessssssssssssssss
[02:58] <j-b> wm4: trunk branch and a stable branch
[02:59] <wm4> I really hate how pkg-config doesn't match release numbers
[02:59] <j-b> wm4: and backport on the stable branch with release.
[02:59] <wm4> ah
[02:59] <Daemon404> wm4, https://code.google.com/p/ffmpegsource/source/diff?spec=svn743&r=736&format=side&path=/trunk/include/ffmscompat.h&old_path=/trunk/include/ffmscompat.h&old=723 <-- dropping everything under 0.8 did this
[03:00] <wm4> Daemon404: it was kind of similar for me
[03:00] <j-b> wm4: when trunk becomes the new stable, we maintain oldstable for one minor release of new release, and drop oldstable. We have a new trunk and a new stable.
[03:00] <wm4> j-b: oh, is that about VLC itself? I was talking about your ffmpeg snapshot
[03:00] <j-b> wm4: so now we manage 2.0.x and 2.1.0-git.
[03:01] <j-b> wm4: in 2.0, we have a FFmpeg sha1
[03:01] Action: ubitux would be happy to have a ffmpeg debian maintainer, who also deal with the ffmpeg release process
[03:01] <j-b> and we update it from time to time
[03:01] <wm4> I see
[03:01] <ubitux> unfortunately we don't have such person
[03:01] <Daemon404> debian is a distro
[03:01] <wm4> j-b: please convince michaelni to use the VLC release model
[03:01] <Daemon404> distro != project
[03:01] <j-b> for example, a long time we where to commit-planar^
[03:01] <j-b> and now we are moving to lavc55^
[03:02] <ubitux> Daemon404: yes but it helps understanding some issues, and we need such packager anyway
[03:02] <Daemon404> wont be me
[03:02] <Daemon404> writing .deb = pain
[03:02] <ubitux> the pain won't be to write the .deb
[03:02] <wm4> haha
[03:02] <Daemon404> nobody sane can handle keeping lavc "stable"
[03:02] <ubitux> the war isn't in the technical part
[03:03] <ubitux> if you see what i mean
[03:03] <j-b> ubitux: but, I don't complain, you see. I am happy.
[03:03] <Daemon404> debian is no longer going to provide a util named "ffmpeg" after this generation
[03:03] <j-b> ubitux: I follow mailing lists.
[03:03] <Daemon404> so you can stop being butthurt
[03:04] <ubitux> j-b: please add some ":)" so i can be convinced
[03:04] <j-b> ubitux: but, I don't complain, you see. I am happy. :D
[03:04] <ubitux> thank you
[03:04] <j-b> ubitux: even more, the more it is the mess, the best it is for me :)
[03:04] <ubitux> i'm sure you even already feel better by adding some smileys
[03:04] <Daemon404> j-b needs to earn his keep, you see
[03:04] <ubitux> even if you don't want to admit it
[03:04] <Daemon404> he doesnt "earn" it unless he deals with insanity
[03:05] <j-b> I feel good, I got my cat on my knees
[03:05] <ubitux> Daemon404: a debian generation is... very long
[03:05] <j-b> Daemon404: yep, exactly :)
[03:05] <wm4> there would be nice problem if distros have up on dynamic linking for libav*
[03:05] <wm4> s/nice/no/
[03:06] <michaelni> j-b, if you have suggestions about how to improve the ffmpeg release process and a list of problems we have currently please post a mail to ffmpeg devel, i dont think iam able to decipher much out of this "dicsussion" here, also keep in mind no extra work can be done without more volunteers
[03:06] <wm4> s/have/gave/
[03:06] <Daemon404> michaelni, sec i have a link for you
[03:06] <Daemon404> from libav-devel
[03:06] <Daemon404> but applicable here too
[03:06] <Daemon404> or anywhere really
[03:06] <Daemon404> http://lists.libav.org/pipermail/libav-devel/2013-January/041313.html
[03:07] <j-b> michaelni: simple: maintain less releases in // (1 or 2 + trunk) and link the release numbers to the main libraries numbers.
[03:08] <michaelni> Daemon404, thanks  will read when ive time, iave too much random things to do at the same time atm
[03:08] <j-b> wm4: good luck convincing them that :)
[03:09] <michaelni> j-b, the libs all have different numbers, would they match id very happily use that for ffmpeg releases
[03:10] <michaelni> making them match also means we would have to bump all when one is bumped
[03:10] <michaelni> distros might dislike the extra bumps (dunno)
[03:10] <Daemon404> i think the idea is
[03:11] <Daemon404> one major bump = one release
[03:11] <Daemon404> hard to fuck that up
[03:11] <michaelni> Daemon404, honestly id like to never or very rarely major bump
[03:11] <Daemon404> abi change = major bump
[03:12] <michaelni> yes
[03:12] <Daemon404> and given the amount of abi changes weekly...
[03:12] <michaelni> yes
[03:12] <wm4> getting quite bumpy
[03:12] <michaelni> yes
[03:12] <Compn> Daemon404 : the problem is your idea is good, but distros wont go for it
[03:12] <Daemon404> Compn, distros would LOVE it
[03:12] <Compn> Daemon404 : convince reinherd
[03:12] <Daemon404> ffmpeg wont go for it
[03:13] <Daemon404> he is not relevant
[03:13] <Daemon404> since his distro does nto use ffmpeg
[03:13] <Daemon404> and is thus not relevant to ffmpeg.
[03:14] Action: Compn goes to derp by himself
[03:14] <ubitux> it's absolutely incredible that a distro with that much users and packagers can't be able to provide a single packager for ffmpeg
[03:14] <wm4> maybe because it's so insane
[03:14] <Daemon404> they made their choices for which project prives the libav* libs
[03:15] <ubitux> wm4: all the work is already done
[03:15] <Daemon404> i think you need to get over it
[03:15] <Daemon404> and stop being butthurt
[03:15] <Daemon404> provides*
[03:15] <Compn> you guys arent supposed to butthurt around Daemon404
[03:15] <wm4> ubitux: you have to keep packages up-to-date
[03:15] <Compn> or else he will leave
[03:15] <wm4> ubitux: and that must be a major pain
[03:15] <ubitux> Daemon404: they had 3 choices, they made the only wrong one
[03:15] <ubitux> they still have 3 choices
[03:15] <ubitux> they can package both
[03:15] <ubitux> and the other 2 solutions
[03:16] <Daemon404> sorry, i cant hear you over butthurt
[03:16] <Daemon404> the*
[03:16] <ubitux> Daemon404: you don't understand all the problems it causes
[03:17] <Daemon404> many of the problems i see are caused by you guys in #ffmpeg
[03:17] <Daemon404> telling peope to shun system packages
[03:17] <Daemon404> and compie their own
[03:17] <Daemon404> because thats a GREAT idea.
[03:17] <ubitux> and btw, the only reason all the downstream projects are fucked between this libav/ffmpeg choice is because debian is packaging libav exclusively.
[03:17] <Daemon404> so is gentoo now
[03:17] <ubitux> no
[03:17] <Daemon404> iirc
[03:17] <ubitux> gentoo is packaging both
[03:17] <relaxed> ubuntu as well
[03:18] <ubitux> by debian i mean all the cancer around
[03:18] <relaxed> agreed
[03:18] <Daemon404> ah right
[03:18] <Daemon404> gentoo just has libav set as default
[03:18] <ubitux> if i need to mention all the debian forks every time i talk about debian that's never going to end
[03:18] <michaelni> debian ehm deb multimedia packages ffmpeg 
[03:18] <wm4> debian has the dmo repo...
[03:19] <ubitux> this causes problem afaik
[03:20] Action: ubitux back to work
[03:34] <ubitux> arg i'm too lazy to finish the eval in af volume
[03:35] <ubitux> i think i'm going to add a temporary hack and let saste remove it when adding the eval support
[03:37] <wm4> I _especially_ don't like how the filters eval expressions themselves
[03:37] <wm4> that's really bad design
[03:37] <wm4> you force everyone to use your little expression language
[03:40] <ubitux> what's the problem again?
[03:41] <ubitux> you're free not to use the eval thing yourself (you can just put a constant); of course there is currently no alternative, but that could be changed
[03:41] <ubitux> (GSoC, lua, etc.)
[03:41] <ubitux> (please not again that discussion)
[03:42] <ubitux> (and the eval system is actually not a bad design from a functionnal PoV)
[03:42] <ubitux> both could be done, and this is the issue
[03:43] <wm4> ubitux: why isn't the eval thing done by the graph parser?
[03:43] <ubitux> wm4: how are you supposed to change filter settings with another system? reconfigure/reset the filter every time?
[03:43] <wm4> uhhhhhh
[03:44] <ubitux> because the graph parser has no loop system
[03:44] <ubitux> wm4: ok let's work with an example
[03:44] <wm4> so I guess libavfilter is really just intended for ffmpeg.c
[03:44] <wm4> and ffplay.c
[03:44] <ubitux> aevalsrc="sin(440*2*PI*t)"
[03:44] <wm4> and you do whatever is most "practical" in that use-case
[03:44] <ubitux> let's start with this
[03:45] <ubitux> what would you want instead?
[03:45] <wm4> evalsrc doesn't count
[03:45] <ubitux> ok
[03:45] <ubitux> let's take another
[03:45] <wm4> I'm talkign about vf_scale args and such
[03:45] <ubitux> hue=H=2*PI*t
[03:45] <ubitux> what would you want instead?
[03:45] <Daemon404> wm4, http://ffmpeg.org/pipermail/ffmpeg-devel/2012-October/132031.html <-- feel free to link this as often as you wish
[03:45] Action: Daemon404 goes to make tea
[03:46] <ubitux> Daemon404: we've worked on some of the issues
[03:46] <Daemon404> i know
[03:46] <Daemon404> i still dont know what lavfi's intended use case is though.
[03:46] <ubitux> metadata is in, lua gsoc is proposed, the api changes regularly, etc
[03:46] <wm4> solution: port all useful vapoursynth filters to lavfi
[03:46] <ubitux> basically, we can't do everything
[03:46] <wm4> trollol
[03:47] <ubitux> come on guys please don't start this again
[03:47] <ubitux> wm4: so what's the matter with vf scale?
[03:47] <wm4> Daemon404: I see one use-case: an abstraction to make ffmpeg command line handling simpler
[03:47] <ubitux> oh fuck
[03:47] <Daemon404> wat
[03:47] Action: ubitux not helping anymore
[03:47] <wm4> Daemon404: e.g. user wants to crop off some pixels -> crop filter as abstraction (and of course cropping is entirely trivial)
[03:48] <wm4> but obviously you still need it
[03:48] <Daemon404> thats a bit of a stretch
[03:48] <Daemon404> anyway, internet = trolls
[03:48] <Daemon404> the end.
[03:48] Action: Daemon404 tea &
[03:48] <wm4> not really... basically it allows you to do composition of such primitives
[03:50] <wm4> Daemon404: consider vapoursynth without filters: it's still useful because it provides you basic primitives for video manipulation, such as cropping
[03:50] <wm4> and the fact that vf_scale etc. accept expressions just confirms this idea
[03:50] <Daemon404> it has 'core' filters
[03:51] <wm4> imagine vapoursynth filters would accept expressions for basic values (such as scale width)
[03:52] <wm4> it would turn everything into a mess
[03:52] <wm4> because you'd have two levels of scripting languages
[03:52] <wm4> though VS has something like the evalsrc filter too
[03:52] <Daemon404> it has a JIT'd lut filter iirc
[03:53] <wm4> yes, and some weird separate expression language for that
[03:54] <Daemon404> from what i understand
[03:54] <Daemon404> it was requested by former avs users
[03:54] <Daemon404> and we know how perverted they are.
[03:55] <Daemon404> http://chromashift.org/RemoveGrain.cpp <-- this perverted
[03:55] <Daemon404> for anyone wondering
[03:55] <wm4> wow
[03:56] <Daemon404> most avs plugins make swscale look like a masterpiece
[03:57] <wm4> except these plugins are isolated, while swscale is everywhere
[04:02] <BBB> lol @ swscale masterpiece
[04:02] <BBB> that is so friggin' hilarious
[04:02] <BBB> I actually lol'ed
[04:03] <wm4> did you see the code he linked
[04:07] <ubitux> i don't think this code can not be at least half generated
[04:07] <Daemon404> its is all done by hand
[04:07] <ubitux> i don't believe it
[04:08] <Daemon404> most avs plugins are giant walls of hand written asm
[04:08] <Daemon404> including tivtc
[04:08] <Daemon404> which had to be RE'd to vivtc
[04:08] <Daemon404> more or less
[04:11] <ubitux> i had a quick look to tivtc a few month ago
[04:12] <ubitux> it was complex and messy yes
[04:12] <ubitux> the code you're pasting here is not of that kind
[04:12] <ubitux> it's completely insane
[04:12] <ubitux> and it makes absolutely no sense at all
[04:13] <ubitux> (wtf @ all the __asm prefixes?)
[04:13] <wm4> probably how msvc lets you do inline asm
[04:14] <ubitux> afaik you don't need to prefix every single line
[04:14] <Daemon404> wm4, no...
[04:14] <Daemon404> you can block asm 
[04:14] <Daemon404> like __asm {
[04:14] <Daemon404> mov eax, eax
[04:14] <Daemon404> }
[04:15] <ubitux> don't tell the guy this, he's going to do a block... for each line
[04:15] <ubitux> also, don't you loose some context doing so?
[04:16] <Daemon404> ?
[04:16] <ubitux> __asm(A); __asm(B); doesn't necessarly produce the same output as __asm(A B); iirc
[04:17] <ubitux> but i've written very little asm in my life so i can be wrong here
[04:17] <ubitux> inline x86 at least
[04:17] <Daemon404> i dont know anything about msvc's inline asm from 1998
[04:17] <ubitux> oh right
[04:18] <wm4> AFAIK msvc doesn't use constraints, and instead tries to do what you want
[04:20] <ubitux> given msvc still doesn't support c in 2013, i wouldn't be so sure about 98 indeed
[04:20] <ubitux> i forgot that detail :p
[04:21] <wm4> they support C89
[04:21] <ubitux> yeah right
[04:21] <ubitux> they support C from before 1990
[04:21] <wm4> they don't care about C99 because it's used by linux crap only
[04:22] <wm4> not sure why MS wants you to prefer mingw over msvc though
[04:23] <ubitux> there are a bunch of MS guys all around to explain that to you
[04:24] <cone-434> ffmpeg.git 03Reinhard Tartler 07release/1.1:4852b3aabd4b: Prepare for 9.4 Release
[04:24] <cone-434> ffmpeg.git 03Luca Barbato 07release/1.1:146eac0a0c5f: h264: check for luma and chroma bit dept being equal
[04:24] <cone-434> ffmpeg.git 03Anton Khirnov 07release/1.1:77cf052e395b: vmdaudio: fix invalid reads when packet size is not a multiple of chunk size
[04:24] <cone-434> ffmpeg.git 03Anton Khirnov 07release/1.1:60dd8b5733f9: wmaprodec: return an error, not 0, when the input is too small.
[04:24] <cone-434> ffmpeg.git 03Alexander Kojevnikov 07release/1.1:d3b40af01f88: mp3dec: Fix VBR bit rate parsing
[04:24] <cone-434> ffmpeg.git 03Anton Khirnov 07release/1.1:747fbe0c212b: roqvideodec: fix a potential infinite loop in roqvideo_decode_frame().
[04:24] <cone-434> ffmpeg.git 03Michael Niedermayer 07release/1.1:6086a4d74d09: Merge commit '747fbe0c212b81952bb27ec7b99fa709081e2d63' into release/1.1
[04:24] <ubitux> anyway, when i see you guys fooling around about "filters from 2000", it makes me sad not to see that much energy into trolling those guys, especially since there are more msvc users than lavfi (which no one knows what it is about)
[04:25] <Daemon404> you cant troll them
[04:25] <Daemon404> because theyre not even around
[04:25] <ubitux> /j #microsoft
[04:25] <ubitux> vomit hate
[04:25] <ubitux> /leave
[04:25] <Daemon404> i persoanlyl think most things added in c99 are either cosmetic, or actively encourage bad coding practices.
[04:26] <Daemon404> with a few exceptions.
[04:26] <ubitux> and those exceptions are a fucking pain in the ass
[04:26] <ubitux> but well, that problem is relatively solved
[04:27] <ubitux> thanks to you, but that was too nice 
[04:27] <Daemon404> me?
[04:27] <Daemon404> i think you mean bbb and wbs
[04:27] Action: Daemon404 only prorposed the idea and wrote the initial (bad) code
[04:27] <ubitux> multiple you
[04:29] <wm4> Daemon404: what bad practices?
[04:29] <ubitux> here you go anonymous struct and stuff
[04:29] <Daemon404> ^
[04:29] <Daemon404> also mixed code and var decls
[04:29] Action: ubitux doesn't agree with this one
[04:30] <ubitux> no opinion for mixed code & var
[04:30] <wm4> I <3 declaring vars at use and initialization
[04:30] <Daemon404> it makes reading much harder
[04:30] <ubitux> i like the split, but most likely because i'm used to it
[04:30] <wm4> just look at those libav* functions which have "int n;" and stuff like this on top of 200 line functions
[04:31] <Daemon404> wm4, you dont to per-function vars
[04:31] <Daemon404> you do per block.
[04:31] <ubitux> wm4: you can move declaration into the scope
[04:31] <ubitux> brainhacked
[04:31] <wm4> it also makes it harder to reason when a var is initialized, and when it's not needed anymore
[04:31] <ubitux> wm4: OTOH it lighten the "algorithmic" part from the technical details
[04:32] <ubitux> code reading is "classified"
[04:32] <ubitux> it really is a taste issue imo
[04:32] <ubitux> just like coding style
[04:32] <wm4> no, you are Wrong
[04:32] <ubitux> ok
[04:32] <wm4> morally wrong
[04:32] <Daemon404> code? morals?
[04:32] <Daemon404> wat
[04:33] <wm4> I'm joking
[04:33] <Daemon404> its hard to tell anymore.
[04:40] <BBB> well at least people are now comfortable with msvc support
[04:40] <BBB> it's funny, but back when I started that, people were actively attacking me for entertaining the thought
[04:45] <wm4> BBB: why?
[04:47] <BBB> also, if we go by the graph of http://techcrunch.com/2012/06/28/google-chrome-now-has-310-million-active-users-most-popular-browser-in-the-world/, chrome would have like 400-500M users at this point, and assuming OS distribution is 90% win, it means c89ified-ffmpeg (through chrome) has 360-450M users
[04:47] <BBB> (pure guesswork)
[04:47] <cone-434> ffmpeg.git 03Anton Khirnov 07release/1.1:74880e78d830: ivi_common: do not call MC for intra frames when dc_transform is unset
[04:47] <cone-434> ffmpeg.git 03Anton Khirnov 07release/1.1:c1f479e8df24: wmadec: require block_align to be set.
[04:47] <cone-434> ffmpeg.git 03Anton Khirnov 07release/1.1:62a657de168c: xxan: fix invalid memory access in xan_decode_frame_type0()
[04:47] <cone-434> ffmpeg.git 03Anton Khirnov 07release/1.1:d48da9137333: ffv1: fix calculating slice dimensions for version 2
[04:47] <cone-434> ffmpeg.git 03Anton Khirnov 07release/1.1:20373a66ec68: wmaprodec: require block_align to be set.
[04:47] <cone-434> ffmpeg.git 03Justin Ruggles 07release/1.1:905f5c8a1e94: png: use av_mallocz_array() for the zlib zalloc function
[04:47] <cone-434> ffmpeg.git 03Justin Ruggles 07release/1.1:b77d9cbbd505: libmp3lame: use the correct remaining buffer size when flushing
[04:47] <cone-434> ffmpeg.git 03Anton Khirnov 07release/1.1:0cb3cab34312: eamad: allocate a dummy reference frame when the real one is missing
[04:47] <cone-434> ffmpeg.git 03Michael Niedermayer 07release/1.1:685f50b37441: Merge remote-tracking branch 'qatar/release/9' into release/1.1
[04:47] <cone-434> ffmpeg.git 03Michael Niedermayer 07release/1.1:f156dc54f8c2: mpegaudio_parser: fix off by 1 error
[04:49] <Daemon404> BBB, depends if steam moves over to msvc ffmpeg too
[04:49] <Daemon404> iirc they use chrome's webkit even.
[04:50] <BBB> well ffmpeg isn't in webkit's layer right?
[04:50] <BBB> but sure, if steam uses msvc-ffmpeg, that's another lot of users
[04:50] <BBB> sounds nice
[04:50] <BBB> I think lavfi has some catching up to do
[06:38] <cone-434> ffmpeg.git 03Clément BSsch 07master:fe898a037d99: Revert "lavfi/ebur128: fix format negociation for output."
[10:25] <durandal_1707> have ffplay leaks with lavfi/showwaves been fixed?
[10:28] <durandal_1707> ubitux: what about patch for ebu/asetnsamples to use some number instead of using internal fifo?
[10:31] <durandal_1707> there is bunch of filters that do not check return value of ff_get_audio_buffer, one even assert on it
[10:31] <nevcairiel> are you using the movie source in lavfi through lavd? because it does leak like mad right now
[10:32] <nevcairiel> a fix is on the ML from nicolas
[10:32] <durandal_1707> yes
[10:35] <durandal_1707> hmm, he did not post new patch
[10:36] <durandal_1707> what next is comming from lab?
[10:51] <durandal_1707> what reference is AVFrame was used for?
[10:52] <soho> hi 
[10:52] <soho> can I post my problem here?
[10:52] <cone-732> ffmpeg.git 03Paul B Mahol 07master:4853b5538f41: lavc: do not set coded_frame->reference
[10:52] <soho> because I use ffmpeg and got some trouble
[10:53] <durandal_1707> #ffmpeg
[10:56] <durandal_1707> it looks like bug
[10:56] <soho> is it possible to generate stream if webcam support mpegts format?
[10:56] <soho> by ffserver + ffmpeg?
[10:58] <durandal_1707> soho: join #ffmpeg
[10:59] <durandal_1707> actually you already did that
[11:56] <cone-732> ffmpeg.git 03Janne Grunau 07master:91d4823f70ba: avpacket: copy side data type and size in av_dup_packet
[11:56] <cone-732> ffmpeg.git 03Martin Storsjö 07master:f05e9beb4ab5: ismindex: Rename structs and fields from "file" to "track"
[11:56] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:33ecf7ab5980: Merge commit 'f05e9beb4ab5fb8b9d5ba81405e9fca901832591'
[12:03] <cone-732> ffmpeg.git 03Martin Storsjö 07master:7c147900b86c: ismindex: Factorize code for printing chunk duration lists
[12:03] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:360d71707f7d: Merge commit '7c147900b86c0f1cf030b7b844c670649c80c191'
[12:23] <cone-732> ffmpeg.git 03Martin Storsjö 07master:4abf6fa095f8: ismindex: Check the return value of allocations
[12:24] <michaelni> remote:     (commit.author, commit.logmsg) = metainfo.split("|")
[12:24] <michaelni> remote: ValueError: too many values to unpack
[12:39] <cone-732> ffmpeg.git 03Diego Biurrun 07master:63d744e2be39: av_log_missing_feature() ---> avpriv_report_missing_feature()
[12:39] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:fa92ee821bba: Merge commit '63d744e2be39466e3a734c2987cd713e0bac101e'
[12:45] <cone-732> ffmpeg.git 03Diego Biurrun 07master:1ecdf8912b9c: avformat: av_log_ask_for_sample() ---> avpriv_request_sample()
[12:45] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:a9ddb624890d: Merge commit '1ecdf8912b9ced51b3267cdcdce5e394d0a3bf8e'
[13:03] <cone-732> ffmpeg.git 03Diego Biurrun 07master:1ae07959ab39: rsodec: Use avpriv_report_missing_feature() where appropriate
[13:03] <cone-732> ffmpeg.git 03Diego Biurrun 07master:6d97484d72e3: avcodec: av_log_ask_for_sample() ---> avpriv_request_sample()
[13:03] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:13795dbb642c: Merge commit '6d97484d72e33f7dde9493a9ead1a72e2f029605'
[13:20] <cone-732> ffmpeg.git 03Diego Biurrun 07master:12e25ed28459: avcodec: av_log_missing_feature(1) ---> avpriv_request_sample()
[13:20] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:cacbf64a76ac: Merge remote-tracking branch 'qatar/master'
[14:00] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:2ffa9e611e5c: avdevice: bump major
[14:47] <michaelni> j-b, while i cant easily make ffmpeg and lib versions match i can list em, i hope this helps a tiny bit even if not solving the issue fully: http://ffmpeg.org/pipermail/ffmpeg-devel/2013-March/140544.html
[14:50] <michaelni> about "maintain less releases" i really only maintain 1.2 1.1 and 1.0, see MAINTAINERS, the others get updated if someone else backports something in their release branches
[14:59] <ubitux> yay i finally made the fmt negociation working
[15:06] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:7e1efeb5707e: MAINTAINERS: mention that people are welcome to pick up and maintain older releases
[15:06] <cone-732> ffmpeg.git 03Hendrik Leppkes 07master:49a514c13e14: dsputil: unbreak compilation on sparc after 6802c70
[15:06] <cone-732> ffmpeg.git 03Ronald S. Bultje 07master:4a88d81c9e37: dsputil: remove duplicate or unused functions.
[17:36] <cone-732> ffmpeg.git 03Ronald S. Bultje 07master:b76d853697a8: lavc: make compilation of frame_thread_encoder.o optional.
[17:36] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:3c24fbbf651d: jpegdec: be less picky on padding
[17:36] <cone-732> ffmpeg.git 03Michael Niedermayer 07master:870e625108dd: mjpegdec: fix indention
[17:46] <BBB-work> is snow 8bit only?
[17:47] <av500> 256 shades of white
[17:47] <av500> ansd some yellow
[17:48] <cone-732> ffmpeg.git 03Michael Niedermayer 07release/1.1:e586e4d93bfb: msrledec: move output pointer test up
[17:48] <cone-732> ffmpeg.git 03Michael Niedermayer 07release/1.1:e44f89371c3a: msrledec: move loop into switch
[17:48] <cone-732> ffmpeg.git 03Michael Niedermayer 07release/1.1:3ee967c1d875: msrledec: merge switches
[17:48] <cone-732> ffmpeg.git 03Michael Niedermayer 07release/1.1:b9a1efa6f4d4: msrledec: fix output_end checks
[17:48] <cone-732> ffmpeg.git 03Michael Niedermayer 07release/1.1:f719e6566c08: iff: fix integer overflow
[17:48] <cone-732> ffmpeg.git 03Michael Niedermayer 07release/1.1:c8557235fdc9: jpegdec: be less picky on padding
[17:48] <cone-732> ffmpeg.git 03Michael Niedermayer 07release/1.1:4fb6fa477e47: update for 1.1.4
[17:51] <michaelni> BBB-work, yes but it should be relatively easy to extend it to higher bit depths 
[17:56] <BBB-work> well that's not my goal :)
[17:56] <BBB-work> the point is that draw_edge is only called by 8bpp codecs
[17:57] <BBB-work> so the 16bpp draw_edge can die
[17:57] <BBB-work> really only 3 functions are ever called for non 8bpp codecs: get_pixels, idct_put and fdct
[17:58] <BBB-work> afaics at elast
[19:03] <cone-732> ffmpeg.git 03Clément BSsch 07master:9ace0dbe41c6: lavfi/ebur128: use same ref for inputs and outputs.
[19:11] <burek> saste, regarding those options, documented in onlince docs, but without the minus prefix: "The first time before posting this thread I was looking for the word “-channel_layout” in the official ffmpeg manual but there is no such option."
[19:11] <burek> just so to show that it's not just me that noticed it
[19:12] <ubitux> is a 42MB sample too big for FATE?
[19:17] <burek> saste, also 'channel_layout' and 'request_channel_layout' options are not completely documented, or not at all, as much as i can see here http://www.ffmpeg.org/ffmpeg-codecs.html
[19:22] <ubitux> burek: saste is not online.
[19:22] <burek> im writting this so he can read it from logs
[19:23] <ubitux> i don't think he doe
[19:23] <ubitux> does
[19:23] <burek> well, not my problem :)
[19:23] <burek> when i create a ticket, i get bounced
[19:23] <burek> when i say it here, i get referenced to ask saste
[19:23] <burek> so what am i supposed to do?
[19:23] <burek> hunt people around just to report missing things?
[19:24] <ubitux> i'm just saying you're likely wasting your time talking to no one since saste is not here
[19:24] <ubitux> anyway, the reason those options don't have the '-' is because they don't necessarily use the '-'
[19:25] <ubitux> the only place where the '-' is used is with the ffmpeg tool
[19:25] <ubitux> with the api, you don't
[19:25] <burek> i'm having a feeling that i'm really wasting my time a lot lately, in general
[19:25] <michaelni> ubitux, 42mb wont work as fate attchment but ftp will work ...
[19:26] Action: michaelni reads above again and realizes he cant read nor write
[19:26] <ubitux> michaelni: it wasn't really a technical question
[19:26] <ubitux> just a wonder, because it's somehow big
[19:26] <michaelni> i know i thoughtg you ask about trac ^^;;
[19:27] <burek> btw, the minus sign issue could have been solved in a better way, leaving it in front of the options, so that people can do ctrl+F like they did so far, and stating one sentence above those options that if they are used from the code itself, they don't need it
[19:27] <michaelni> as fate sample 42mb is a bit big imho
[19:27] <ubitux> burek: i've just explained the problem with the '-'
[19:27] <burek> never mind :)
[19:29] <ubitux> michaelni: it's a test reference sample; it's actually a 24-bit .wav of about 60M
[19:29] <ubitux> a naive flac encode gives something of about 40M
[19:29] <ubitux> now i wonder if the test will still be relevant if i start trashing some info
[19:30] <ubitux> michaelni: what should i aim for? 5M max?
[19:31] <michaelni> 5m sounds more reasonable
[19:31] <michaelni> yes
[19:32] <ubitux> ok
[19:36] <BBB-work> can't you cut the first 100 samples or so?
[19:36] <BBB-work> that should be enough for fate
[19:36] <ubitux> BBB-work: it's in order to test an analysis filter
[19:36] <ubitux> and the whole duration is an important parameter
[19:38] <ubitux> but well, there is another sample, smaller, that might be enough
[19:43] <cone-732> ffmpeg.git 03Nicolas George 07master:da397173dfc7: ffmpeg: add OPT_OUTPUT to -to option.
[19:43] <cone-732> ffmpeg.git 03Nicolas George 07master:0eb56a085d84: ffmpeg: add OPT_INPUT to -guess_layout_max.
[19:57] <ubitux> burek: with '-', it would exclusively mean it is a tool specific option; without it, it shows it works with both tools and api, as you are supposed to prefix options with a '-' with tools
[19:57] <ubitux> so we prefer the generic version
[19:57] <burek> you rock
[19:58] <ubitux> burek: and look at one of the very little sentences on top of the option list
[19:58] <ubitux> "Options may be set by specifying -option value in the FFmpeg tools"
[19:59] <burek> as long as you developers understand it and can navigate it easily, things are just fine and don't need any improvement
[19:59] <ubitux> the fact that what you are proposing is not an improvement was my only point
[19:59] <ubitux> we're not against improvements
[19:59] <burek> of course :)
[20:00] <ubitux> and i don't have any better suggestion to propose
[20:03] <ubitux> burek: if you have an improvement suggestion that doesn't cause more harm than problems it solves, i'm all hear...
[20:04] Action: ubitux wonders if a documentation task in GSoC could achieve anything...
[20:04] <ubitux> i don't think any student would pick it though
[20:09] <michaelni> ubitux, burek you can write it both ways, this would make it clear that its valid as command line option and for the API
[20:09] <burek> guys... ok..
[20:09] <burek> if you say it's not an improvement, it's not
[20:09] <burek> no big deal
[20:10] <ubitux> michaelni: that might be a solution... not sure if that's really sexy but why not
[20:16] <burek> btw, i'm sceptical of students doing documentation in gsoc, because i really doubt they are going to install all the things like git, texi parsers, web server and others, just to be able to suggest a couple of improvements to the documentation.. :/
[20:17] <ubitux> they need git and that's all
[20:17] <burek> maybe im just too sceptical, but last time i was involved in it, it was mostly an answer like "can i do it in a text editor and you merge it into the docs"
[20:18] <burek> in translation, they need to learn/do a lot only to prepare the environment in which they will be able to properly fix things creating proper patches and stuff
[20:18] <ubitux> that's kind of the purpose of the gsoc
[20:19] <burek> ok, let's wait and see then
[20:19] <ubitux> the problem is that the documentation in itself is not very interesting and gratifying
[20:19] <ubitux> and since gsoc students are, afaik, mostly future engineers
[20:20] <ubitux> they want to learn sciences and stuff
[20:20] <ubitux> not do boring secretary work
[20:20] <ubitux> if such documentation task fail, that will be because of this, and not because they are unable to type a few git commands in a shell
[20:20] <burek> are you engaging in the project to help them in their scientific work or are they supposed to help us and learn something about real projects in action instead?
[20:21] <ubitux> that is a too limited question
[20:21] <burek> im just saying how it was the last time i saw it.. none of them were too interested in git/texi work, only in spelling corrections and writing actions
[20:21] <burek> i mean, could you blame them?
[20:22] <burek> if wikipedia was created this way, like our docs system, would it ever be no1 in the world by the community contribution magnitude?
[20:23] <ubitux> we've already answered all these concerns
[20:23] <burek> but anyway, im just repeating myself and i know this leads nowhere
[20:23] <ubitux> please don't ask me to repeat myself for like the 10th time
[20:23] <burek> exactly :)
[20:23] <burek> what is important in ffmpeg project is that all questions have been answered and all tickets have been closed :)
[20:23] <burek> that's i guess the measure of succes..
[20:24] <ubitux> that sounds like a pretty good thing indeed
[20:24] <ubitux> unfortunately that's not the case
[20:24] <michaelni> ubitux, read this: http://www.google-melange.com/document/show/gsoc_program/google/gsoc2012/faqs#documentation
[20:24] <ubitux> michaelni: ah, that solves the problem, ok :)
[20:25] <burek> yay :) another ticket closed :D
[20:52] <michaelni> is there anything that should be mentioned in the FFmpeg 1.2 release notes ?
[20:52] <ubitux> LTS? :p
[20:52] <michaelni> you volunteer ? :p
[20:53] <ubitux> not really, but it's likely to be used as a reference for a while
[20:53] <ubitux> since it's just before TEP
[20:54] <michaelni> true but it still needs a maintainer for LTS to be real
[20:55] <cone-732> ffmpeg.git 03Nicolas George 07master:7a71544f9d0c: lavfi/graphdump: fix output for unknown layouts.
[20:55] <michaelni> so do we have a volunteer for that ?
[20:56] <michaelni> it would be primarely backporting security fixes probably
[20:56] Action: ubitux going away slowly
[20:57] <michaelni> this backporting would become harder as the release gets older ...
[21:01] <michaelni> so nothing for the release notes and the change log is complete ? (with next replaced by 1.2) ?
[21:04] <ubitux> nothing in particular i can think of
[21:04] <ubitux> except the motivation of such "small" release
[21:32] <durandal_1707> ubitux: APERMS_FILTER is not sorted in Makefile
[21:35] <ubitux> durandal_1707: fixed locally, thx
[21:40] <cone-732> ffmpeg.git 03Stefano Sabatini 07master:f0da370a523d: examples/filtering_video: update to new API
[21:40] <cone-732> ffmpeg.git 03Stefano Sabatini 07master:9076a6a943f7: examples/filtering_audio: update to new API
[21:40] <cone-732> ffmpeg.git 03Stefano Sabatini 07master:9bb25dbd13e0: examples/filtering_*: constify AVFrame * for print_frame() and display_frame() functions
[21:48] <saste> ubitux, did you push all the raise filter_frame() error patches?
[21:49] <ubitux> i think so
[21:50] <ubitux> yeah sorry i was too lazy to say "pushed" in every single one
[21:50] <ubitux> so i said i pushed the patchset in the first one
[21:51] <ubitux> heh, there was a bug in perms filter
[21:51] <ubitux> now i have gradfun and hqdn3d fate tests testing both path
[21:51] <ubitux> yepee
[21:52] <saste> ubitux, do you mind updating docs for delogo?
[21:52] <ubitux> saste: ah right sorry i saw your message
[21:52] <ubitux> and totally forgot about it
[21:52] <ubitux> give me a few minutes, i need to finish something
[21:54] <saste> ubitux, no patch needed, just copy&paste&edit from some other filter
[21:54] <ubitux> ok
[21:54] Action: ubitux wants a template to include or something :(
[21:56] <saste> i use drawbox
[21:56] <Daemon404> is there no vf_invert
[21:56] <Daemon404> thats usually the exampel filte in everything
[21:57] <durandal_1707> there is invert filter, but no vf_invert file
[21:58] <durandal_1707> i mean negate
[21:58] <durandal_1707> isn't that same?
[21:59] <ubitux> that's not very *synth compliant durandal_1707 
[21:59] <ubitux> you gotta rename that
[21:59] <Daemon404> well
[22:00] <durandal_1707> lav* does not provide _real_ aliases
[22:00] <Daemon404> the entire world calls it invert
[22:00] <Daemon404> or photo negative
[22:00] <Daemon404> only you gusy call it "negate"
[22:01] <ubitux> so?
[22:02] <durandal_1707> hmm, if i change name from negate to negate,invert would it work as expected?
[22:03] <ubitux> you're going to get accused of various other sins if you do that
[22:04] <durandal_1707> there is already matroska,webm
[22:04] <Daemon404> go look at mov.c
[22:04] <Daemon404> it has like 9 commas
[22:04] <ubitux> you don't like commas either?
[22:05] <durandal_1707> its just internal
[22:05] <durandal_1707> output can be changed to be less confusing for noobs
[22:09] <ubitux> saste: it doesn't look like the delogo documentation needs any change
[22:16] <saste> ubitux, uh seems so
[22:16] <ubitux> :)
[22:16] <durandal_1707> ubitux: i forgot about sort issue in allfilters.c
[22:16] <ubitux> durandal_1707: !
[22:16] <ubitux> will fix
[22:17] <cone-732> ffmpeg.git 03Michael Niedermayer 07release/1.2:7c6c5767eb6f: jpegdec: be less picky on padding
[22:22] <ubitux> now some cool options for perms would be to make some (possibly random) persistence for the rw output
[22:22] <saste> ubitux, i'm reviewing the patch
[22:22] <ubitux> i'm not touching it anymore
[22:23] <ubitux> i mean, not adding anything on my own
[22:23] Action: ubitux back to add some more fate coverage elsewhere
[22:25] <durandal_1707> michaelni: when you gonna remove old_codec_ids.h ?
[22:30] <michaelni> is there a reason to do it quickly/soon ?
[22:31] <saste> michaelni, purification
[22:32] <ubitux> let's do the avbufferref purification instead then
[22:33] <ubitux> and libmpcodecs
[22:33] <ubitux> avfilterbufferref*
[22:35] <saste> ubitux, a frame is RO when created, right?
[22:37] <ubitux> no
[22:37] <ubitux> it gets RO when there are multiple references to it
[22:37] <ubitux> by default you alloc, and you can write on it
[22:37] <ubitux> the RO is not actually to prevent writing on it
[22:38] <ubitux> it's to protect from having write from multiple places
[22:38] <ubitux> AFAIU
[22:38] <ubitux> :p
[22:38] <saste> ffmpeg: the project where you have to relearn the API every day
[22:38] <ubitux> :)
[22:39] <nevcairiel> RO is to protect from writing into frames which may still be references in a decoder
[22:39] <ubitux> nevcairiel: i had a hard time finding your sentence in your mangled reply :p
[22:39] <saste> the funny thing is that not only users, but especially devs have to do that
[22:39] <nevcairiel> ubitux: I was afraid that would happen from my phone
[22:40] <ubitux> you (actually we) got punished instantly
[22:44] <nevcairiel> we did?
[22:44] <ubitux> maybe only me
[22:53] <ubitux> amovie + min/max samples still seems to be somehow problematic :(
[23:05] <ubitux> saste: i didn't realize the problem quick because it was actually working with gradfun for some reason
[23:05] <ubitux> (the direct var was switching all around in the filter)
[23:05] <ubitux> but not in hqdn3d
[23:05] <ubitux> :(
[23:08] <ubitux> ffprobe -show_entries frame=metadata
[23:08] <ubitux> i e you saste :)
[23:08] <ubitux> that makes me realize we could simplify some metadata tests
[23:09] <peper03> Hi, just curious about the state of my DVD NAV patch.  Not heard anything more since my last patch submission.
[23:28] <michaelni> peper03, ill look at it asap
[23:28] <peper03> michaelni: Thanks!
[23:32] <fatpony> there's a typo in that warning http://bit.ly/16vwaqv "extreemly"
[23:33] <nevcairiel> extra e for emphasis
[23:33] <ubitux> i thought it was fixed
[23:33] <ubitux> i confirm it's fixed
[23:33] <fatpony> ok sorry, i should have checked
[23:33] <ubitux> thought, there is another place where the typo appears
[23:34] Action: ubitux wonders what the "Oring" verb means
[23:36] <fatpony> oh that's a very recent fix, i didn't update my repo since
[23:36] <fatpony> sorry for the bother
[23:36] <cone-732> ffmpeg.git 03Clément BSsch 07master:1f68bac50be0: lavf/avio: fix two extreemly unreasonble typos.
[23:36] <ubitux> if anyone can make any sense of the "Oring" in that sentence, please tell me
[23:37] <saste> ubitux, which sentence?
[23:37] <Daemon404> was 'extreemly' a joke
[23:37] Action: Daemon404 wonders
[23:38] <ubitux> Daemon404: check by yourself the diff
[23:38] <saste> also or-ing means computing OR of operands
[23:38] <fatpony> or'ing?
[23:38] <ubitux> saste: http://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;a=commitdiff;h=1f68bac50be01fb9a463b0d6ef953ee85fb61e9b
[23:38] <fatpony> yeah that's what i thought saste
[23:38] <ubitux> makes sense for a flag indeed
[23:38] <ubitux> thx
[23:38] <Daemon404> right.
[23:38] <ubitux> Daemon404: you don't find these typo funny? :(
[23:39] <Daemon404> ;p
[23:39] <Daemon404> also
[23:39] <Daemon404> if it refers to binary or
[23:39] <Daemon404> i usually find it helps to type them in ALL CAPS
[23:39] <Daemon404> ORing
[23:39] <ubitux> |ring
[23:39] <Daemon404> but thats just me.
[23:39] <ubitux> |ing sorry
[23:39] <fatpony> what would be the proper way to request a new filter to convert dts hd-ma to dts? maybe opening a ticket for a new feature?
[23:39] <Daemon404> thats ambiguous
[23:39] <Daemon404> that could also be read as piping, ubitux 
[23:39] <ubitux> fatpony: yes, an enhancement ticket
[23:40] <ubitux> Daemon404: that's very unfortunate
[23:40] <Daemon404> fflogger, 'covert'? hd-ma has a dts core
[23:40] <Daemon404> er, fatpony 
[23:40] <Daemon404> theres nothing to convert
[23:40] <fatpony> Daemon404: extract
[23:40] <Daemon404> o ok
[23:40] <fatpony> that was what i meant, sorry, i wasn't thinking
[23:47] <nevcairiel> sounds like something for a bitstream filter, but feature requests should go on trac, i guess
[23:59] <fatpony> nevcairiel: actually, i realised it's already been requested, i guess i'll just bump the feature request https://ffmpeg.org/trac/ffmpeg/ticket/1920
[23:59] <ubitux> you can use the +1 button
[00:00] --- Fri Mar 15 2013