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

[burek]

[00:04] <saste> Compn, ?
[00:08] <ubitux> any idea why nicolas didn't switch to the shorthand system for all the other filters?
[00:08] <ubitux> (should i do it?)
[00:09] <saste> ubitux, what's the main difference between what we have and anton-design (TM)
[00:09] <ubitux> shorthand
[00:09] <saste> if i understand correctly anton's code is using the options order to set the "shorthand order"
[00:10] <ubitux> libav will use the avoption order declaration
[00:10] <ubitux> yes
[00:10] <saste> how do they deal with aliases?
[00:10] <ubitux> move it to the end i guess
[00:10] <ubitux> but yeah that's one of the problem :)
[00:10] <ubitux> you could compare the offset though
[00:11] <ubitux> i mean you should be able to detect aliases
[00:11] <saste> that would be annoying with av_bprint_options()
[00:12] <saste> which rely on the (arbitrary) assumption that aliases are next each to other
[00:12] <saste> the main problem i foresee is with filters which rely on special filter
[00:12] <saste> such for example pan
[00:12] <ubitux> yes this is yet another annoying merge incoming
[00:12] <saste> in that case the only solution is to rely on escaping
[00:12] <saste> or extending the syntax to support more escaping-friendly separators
[00:13] <ubitux> what's the problem with pan?
[00:13] <saste> it uses ":" in the single argument
[00:13] <saste> and "="
[00:13] <saste> so escape is needed
[00:13] <saste> also the switch will break compatibility
[00:13] <ubitux> pan just doesn't use the same option system so it's unrelated isn't it?
[00:14] <saste> apart from this, and the annoying merge work, i don't see big problems
[00:14] <ubitux> well the big problem is mainly re-ordering our options
[00:14] <ubitux> and shorthands (if we keep them)
[00:14] <saste> i also thought about the options order thing, but i rejected the idea for the reasons i exposed
[00:14] <saste> yes, and fixing docs and doc conflicts as well
[00:15] <saste> michaelni, let us know if you need help
[00:15] <ubitux> we should start by removing all the remaining av_opt_set_from_string() calls from our filters
[00:16] <saste> ubitux, is anton code checking for priv_class?
[00:16] <ubitux> yes iirc
[00:16] <saste> or is automatically adding it to all filters?
[00:16] <saste> ubitux, would that help with mergework?
[00:16] <ubitux> i guess so
[00:18] <saste> ubitux, do you mean to switch to shorthand, and then to option-order shorthands?
[00:19] <ubitux> yes
[00:19] <ubitux> because merging the init() fixes from anton will merge conflict all the time
[00:20] <ubitux> if we drop our own to replace with shorthand, what's left for the merge is to drop the shorthand and re-order the fileds
[00:20] <ubitux> fields
[00:20] <ubitux> (and change the doc...)
[00:20] <ubitux> (user interface breakage, haters gonna hate)
[00:20] <saste> user interface breakage?
[00:21] <ubitux> i'm pretty sure the shorthand orders won't match the avoption orders from libav
[00:21] <saste> ubitux, shorthand are mostly used for new filters
[00:22] <ubitux> remember that the shorthand feature was actually before we introduce it
[00:22] <ubitux> the shorthand was an helper to keep order compat
[00:22] <ubitux> not the other way around
[00:22] <ubitux> so the shorthand order is not "recent"
[00:22] <saste> shorthand main use was to support named options, while supporting the old positional syntax
[00:23] <saste> so i guess we should check on a case by case basis
[00:23] <saste> silly work but need some care
[00:23] <ubitux> agree
[00:23] <saste> i expect we will break something during the merge
[00:23] <ubitux> of course
[00:23] <beastd> that smells from miles away...
[00:24] <ubitux> we'll make a new monkey merge dance again
[00:24] <ubitux> i guess we're getting used to 
[00:24] <ubitux> so anyway, should we consider fixing the ~25 filter still using av_opt_set_from_string() to start with?
[00:24] <beastd> also breaking UI would be bad (i mean positional stuff)
[00:25] <saste> i suppose positional syntax will still work
[00:25] <ubitux> gonna send a mail to Nicolas to ask if he isn't working on it
[00:26] <beastd> will work after option array reordering?
[00:28] <beastd> anyway. i am leaving...  n8
[00:31] <ubitux> openbsd compiler doesn't seem to like the macro thing from asine
[00:37] <saste> llogan, please comment on my last gsoc mail
[00:37] <saste> i want to apply during the weekend
[00:38] <michaelni> ubitux, "#define INFINITY       av_int2float(0x7f800000)" <-- this is likely the problem
[00:38] <llogan> saste: from 17 march?
[00:38] <saste> from sunday
[00:39] <llogan> ah, there it is. somehow i missed the attachment.
[00:39] <michaelni> ubitux, want to try to fix it or should i ?
[00:41] <ubitux> michaelni: no no go ahead i'm on something else
[00:41] <llogan> saste: i'll try to review it later tonight.
[00:41] <llogan> thanks for the reminder
[00:41] <ubitux> michaelni: can you have a look at the last lavc memleak fix btw? so i can fix a bit valgrind fate
[00:42] <ubitux> Daemon404: btw, would it make sense to have the ivtc + decimate in the same filter?
[00:42] <ubitux> (even if the decimate is optional)
[00:55] <cone-134> ffmpeg.git 03Michael Niedermayer 07master:76fdced10920: asrc_sine: avoid use of INFINITY as it might be a non constant
[01:08] <cone-134> ffmpeg.git 03Clément BSsch 07master:4331484b8d70: lavc/utils: fix metadata audio frame memleak in case of non refcounted frames.
[01:13] <ubitux> also, i still don't get what the extra video clip can be used for
[01:15] <wm4> why not just vsynth support :(
[01:15] <cone-134> ffmpeg.git 03Michael Niedermayer 07release/1.0:eeb8dabd29d3: rmdec: flush audio packet on seeking
[01:15] <cone-134> ffmpeg.git 03ArnoB 07release/1.0:becde6ab1c38: dpxenc: fix data offset
[01:15] <cone-134> ffmpeg.git 03Michael Niedermayer 07release/1.0:e45f0f0f667b: MAINTAINERS: update for 1.2
[01:15] <cone-134> ffmpeg.git 03Michael Niedermayer 07release/1.0:125fe08492dd: MAINTAINERS: mention that people are welcome to pick up and maintain older releases
[01:15] <cone-134> ffmpeg.git 03Michael Niedermayer 07release/1.0:f2310fff5c7b: update the current year
[01:16] <ubitux> wm4: ffs i already said i don't care if vsynth support is added
[01:16] <ubitux> i just won't do it because i don't care about it
[01:16] <ubitux> i want a native ivtc filter, what's wrong with that?
[01:16] <wm4> everything, it's called NIH
[01:17] <ubitux> does that affect you in any relevant manner?
[01:18] <wm4> it's not my wasted effort and maintenance burden, no
[01:18] <ubitux> exactly
[01:19] <ubitux> i want to have fun with this, i learn some stuff, and it will add a feature for something asked a lot
[01:19] <ubitux> without the need for user to install an anime-specific external filtering library
[01:19] <ubitux> which is likely packaged nowhere at the moment
[01:20] <wm4> I guess Daemon404 is right being grumpy and angry all the time
[01:20] <ubitux> if you want a vsynth wrapper, sure ok, just open a trac ticket for it, or write it yourself
[01:20] <ubitux> but that's not relevant to what i'm doing right now
[01:23] <iive> would that wrapper need wine too?
[01:23] <ubitux> no
[01:28] <saste> uhm any way to raise the av_log buffer size?
[01:29] <saste> i have some huge buffers around, which are truncated in the mid when using av_log
[01:29] <Daemon404> i usually end up #undef printf / #include <stdio.h> when i hit that
[01:29] <Daemon404> during debugging
[01:29] <Daemon404> cant be arsed
[01:30] <saste> Daemon404, they're are standard messages i want to show
[01:30] <saste> like sox effects usage string
[01:30] <Daemon404> i somehow doubt it /should/ be shown if its so huge
[01:31] <Daemon404> oh, a la x264?
[01:31] <wm4> why not port sox filters to lavfi
[01:31] <Daemon404> o u
[01:32] <saste> wm4, i'm doing it
[01:32] <saste> no i'm wrapping libsox to tell the truth
[01:32] <saste> so people don't bother and tell we're reinventing the wheel
[01:32] <ubitux> which we'll do anyway
[01:35] <Daemon404> ubitux, btw i never answered:
[01:35] <Daemon404> the extra video clip
[01:35] <Daemon404> it's "take frames from this clip instead of applying pp"
[01:35] <Daemon404> i.e. a pre-pp'd cli to take frames from
[01:35] <Daemon404> using some external pp
[01:35] <Daemon404> i.e. not tivtc's internal pp algos
[01:37] <Daemon404> [19:42] <@ubitux> Daemon404: btw, would it make sense to have the ivtc + decimate in the same filter? <--
[01:37] <Daemon404> 1) decimation is part of ivtc. i suspect you mean feild matching.
[01:37] <ubitux> it's split into 2 filters
[01:37] <Daemon404> 2) decmation can benefit from knowledge of the pulldown pattern (if it's actually used)
[01:37] <ubitux> field matching and decimation
[01:38] <ubitux> (afaict)
[01:38] <Daemon404> mostly i think it's just cause the avs plugin had both in it iirc
[01:38] <Daemon404> because tritical does drugs
[01:38] <Daemon404> if theyre separable, then go4it?
[01:38] <ubitux> i see, a two pass could make sense?
[01:39] <Daemon404> two pass in what context/sense?
[01:39] <ubitux> i mean an intermediate state between the 2 things
[01:39] <Daemon404> oh ait
[01:39] <Daemon404> now i remember why they were joined in one filter
[01:39] <ubitux> they aren't
[01:39] <Daemon404> were.
[01:39] <Daemon404> past tense.
[01:39] <Compn> saste : did you ask anton about his changes ?
[01:39] <Daemon404> tivtc had a "vfr" mode that had 2 passes (metrics collection, then application)
[01:40] <Daemon404> relied on both
[01:40] <Daemon404> i think vivtc dropped it
[01:40] <saste> Compn, why should I?
[01:40] <Daemon404> cause it was worthless
[01:40] <ubitux> ok so why vivtc still has 2 filters?
[01:40] <ubitux> just because of the port "as close as possible"?
[01:40] <Daemon404> it was a straight up port
[01:40] <ubitux> ok
[01:40] <Compn> saste : to see whats coming in the future
[01:40] <ubitux> Daemon404: so the conclusion is that it could make sense to merge the two?
[01:41] <ubitux> or it could still be relevant to keep them separate
[01:41] <ubitux> ?
[01:41] <Daemon404> its preference
[01:41] <Daemon404> Doesn't Matter (TM)
[01:41] <Compn> saste : not important, just BBB-work mentioned we should talk to libav 
[01:41] <Compn> ;P
[01:41] <Compn> instead of complaining in our channel
[01:41] <ubitux> Daemon404: what i'm afraid of is the option for each filter
[01:42] <ubitux> they might diverge, for some reasons
[01:42] <Daemon404> as i said
[01:42] <Daemon404> preference
[01:42] <saste> Compn, what do you suggest?
[01:42] <ubitux> Daemon404: that looks like a technical issue to me, but ok
[01:43] <Daemon404> and
[01:43] <Daemon404> i suspect
[01:43] <Compn> saste : ask anton (elenril) what his todo or plan is for avfilter 
[01:43] <Daemon404> once vivtc is in libavfilter
[01:43] <Daemon404> suddenly we will see scene encoders getting less terrible ivtc
[01:43] <Daemon404> and less combing
[01:43] <Daemon404> <_<
[01:43] <Daemon404> encodes*
[01:43] <ubitux> you're assuming i'm not messing anything in the port ;)
[01:43] <Daemon404> its hard no to beat the current status quo
[01:43] <Daemon404> not*
[01:44] <Daemon404> either way... less coming on my shows^Wlegitimate downloads
[01:44] <ubitux> Daemon404: i still don't get the clip2 thing though; what is the point of picking from an external clip... the actual result you're looking for?..
[01:44] <Daemon404> ubitux, teh ability to use any postprocessing you want
[01:44] <Daemon404> e.g. nnedi
[01:44] <Daemon404> or sangnom
[01:45] <Daemon404> pp is applied to frames vivtc marks as 'bad'
[01:45] <Daemon404> (you can disable this behavior)
[01:45] <ubitux> ok so, something like: '[in] nnedi [pp]; [in][pp] ivtc,decimate [out]' ?
[01:46] <Daemon404> i cant really read that.
[01:46] <Daemon404> prefix notation?
[01:46] <saste> Compn, what do i gain if i know?
[01:46] <Daemon404> ubitux, btw naming the filed matching "ivtc" is wrong
[01:46] <Daemon404> decimation is /part/ of ivtc
[01:46] <ubitux> ok
[01:47] <Daemon404> tricial had it sepaarted into tfm (fm for field match)
[01:47] <Daemon404> and tdecimate
[01:48] <ubitux> Daemon404: the idea is that you improve the quality of the input with nnedi, but seems it breaks the interlacing, you use the untouched source for fieldmatching, and when fields are matching, the filter is actually picking the corresponding pp'ed frames from the second clip?
[01:48] <Compn> saste : work together, adress problems? i dunno.  its fine if you dont want to do it. i certainly dont want to contact elenril.
[01:48] <saste> Compn, that failed in the past
[01:48] <Daemon404> ubitux, the field matcher will flag any frames it feels it has an impossible field match
[01:49] <Daemon404> and it will pull frames from the nnedi'd clip to replacement
[01:49] <ubitux> oh
[01:49] <ubitux> so that's to handle real interlacing mixup in the middle of a telecined source?
[01:50] <Compn> saste : ok, no problem then. BBB-work : it was tried before and failed.
[01:50] <Daemon404> ubitux, or just plain old f-ed up telecined material
[01:50] <Daemon404> plenty of that exists
[01:50] <ubitux> fun
[01:50] <ubitux> so yadif could be used instead of needi? :)
[01:51] <Daemon404> yes
[01:51] <ubitux> that's pretty fun
[01:51] <Daemon404> generally people use deint for the pp clip
[01:51] <Daemon404> a deint filter*
[01:51] <ubitux> though, it looks a bit tricky to pick the accurate corresponding frame
[01:51] <ubitux> or maybe i missed an obvious step
[01:52] <Daemon404> same farme # as input
[01:52] <Daemon404> frame 5 is messed? take frame 5 from clip 2.
[01:52] <Daemon404> (afaik)
[01:52] <ubitux> i don't know if yadif isn't dropping frame or something
[01:52] <Daemon404> thats a requirement
[01:52] <Daemon404> same frame #s
[01:52] <Daemon404> and # of frames
[01:52] <saste> uhm looks like sox filter needs an internal fifo...
[01:52] <Daemon404> deint should not drop frames anyway
[01:54] <ubitux> well at least there is a mode which seems to output 1 frame for each frame
[01:54] <ubitux> so it should be ok
[01:54] <ubitux> Daemon404: you consider nnedi filter more effective than yadif?
[01:54] <Daemon404> yes
[01:54] <Daemon404> nnedi3, specifically
[01:54] <ubitux> for anime again i guess?
[01:54] <Daemon404> no
[01:55] <Daemon404> i use it on plenty of live action
[01:55] <Daemon404> thats what tritical designed it for
[01:55] <Daemon404> iirc
[01:55] <ubitux> the diagonal thing?
[01:55] <Daemon404> what?
[01:55] <ubitux> i may be wrong, but reading the doom9 related post it was about a more effective algo for diagonal motion or something
[01:55] <ubitux> iirc
[01:56] <ubitux> but well ok whatever
[01:56] <ubitux> do you have a sample to show this?
[01:56] <ubitux> replacing the clip2 with a second input will actually make a lot of sense, i like it
[01:56] <Daemon404> im sure you can find many on doom9
[01:57] <ubitux> ok
[01:57] <ubitux> [in] yadif [deint]; [in][deint] fieldmatch,decimate [out] will be somehow nice
[01:58] <Daemon404> [in] yadif [deint]; <-- this part still confused me
[01:58] <ubitux> why?
[01:58] <Daemon404> [in] has an impicit input, and deint takes its prefix?
[01:58] <Daemon404> its not clear.
[01:58] <ubitux> i don't understand your question
[01:58] <ubitux> it's just arbitrary names?
[01:58] <Daemon404> er i mis understood
[01:59] <Daemon404> i see it now
[01:59] <Daemon404> i missed the ;
[01:59] <wm4> is the ffmpeg eval stuff turing complete?
[01:59] <ubitux> anyway, thanks a lot for the explanation
[02:00] <Daemon404> wm4, next step is to implement a lisp variant
[02:00] <ubitux> wm4: i'd say yes
[02:00] <Daemon404> oh boo.
[02:01] <Daemon404> tritical deleted his nnedi example images
[02:01] <ubitux> is tritical still contributing some filters?
[02:01] <Daemon404> no
[02:01] <Daemon404> he's dead
[02:01] <Daemon404> his inline asm ate him.
[02:02] <ubitux> virtually dead, or..>?
[02:02] <BBB-work> Compn, ?
[02:02] <Daemon404> technically it could be either.
[02:02] <BBB-work> what did I do?
[02:02] <Daemon404> i dont know anyone who knows him irl
[02:02] <ubitux> oh.
[02:02] <ubitux> and no activity seen from him since a while?
[02:03] <Daemon404> years
[02:03] <ubitux> i hope he wasn't hosting himself the .zip
[02:03] <Daemon404> http://bengal.missouri.edu/~kes25c/ <-- his site is fine
[02:03] <ubitux> yeah i saw this
[02:03] <Daemon404> but his stuff is all msvc inline asm.
[02:03] <ubitux> :)
[02:04] <Daemon404> http://www.vapoursynth.com/2012/10/open-binary-introducing-a-practical-alternative-to-open-source/
[02:04] <Daemon404> ^ tritivalcode
[02:04] <Daemon404> er triticalcode
[02:04] <ubitux> ok :)
[02:08] <Compn> BBB-work : you suggested the other day to ask #libav about filters...
[02:12] <BBB-work> I think I was being sarcastic back then?
[02:12] <BBB-work> sorry if that wasn't obvious
[02:14] <Compn> [12:34] <BBB-work> asking libav questions in #ffmpeg is about as useful as republicans asking, at the republican convention, why democrats are so uncooperative towards their great goals (or vice versa)
[02:14] <Compn> [12:34] <BBB-work> I bet you someone is currently asking the same type of question about ffmpeg in #libav
[02:14] <Compn> [12:34] <BBB-work> Compn, ^^
[02:14] <cone-134> ffmpeg.git 03Clément BSsch 07fatal: ambiguous argument 'refs/tags/n1.0.6': unknown revision or path not in the working tree.
[02:14] <cone-134> Use '--' to separate paths from revisions
[02:14] <cone-134> refs/tags/n1.0.6:HEAD: lavc/utils: fix metadata audio frame memleak in case of non refcounted frames.
[02:14] <Daemon404> nice.
[02:14] <Daemon404> failbot
[02:15] <michaelni> yep :/
[02:18] <ubitux> i've pm thresh about it already
[02:18] <ubitux> i don't remember receiving a reply, not for that problem at least
[02:19] <Daemon404> offer him beer
[02:21] <llogan> or 10l of RC Cola.
[02:21] <llogan> or "President's Choice"
[02:22] <Daemon404> supermarket brand cola
[02:22] <Daemon404> living the high life
[02:23] <llogan> i just kegged 3 gallons of root beer.
[02:23] <Daemon404> hows your diabetes?
[02:23] <wm4> ffmpeg brand cola (explodes in your mouth if you don't drink correctly)
[02:23] <llogan> Daemon404: ask the leeches at the apartment
[02:24] <llogan> i'm more of a cirrhosis guy
[02:27] <wm4> ubitux: can ffmpeg includes playlist parsers as well? mplayer's are rotten down to every line (this is not a joke, and only a little bit sarcasm)
[02:28] <ubitux> i won't do it
[02:28] <ubitux> i'm pretty sure anton will re-do it as soon as it's in ffmpeg anyway
[02:28] <ubitux> so better motivate him
[02:28] <ubitux> (this is not a joke, and only a little bit sarcasm as well)
[02:31] <wm4> it was worth a try
[02:31] <ubitux> wm4: clearly, anything related to chaptering/playlist is very risky to do in ffmpeg
[02:31] <ubitux> since i'm pretty sure anton will at some point rewrite everything related to lavf/metadata/chaptering/playlist
[02:31] <wm4> I didn't ask for a libavformat/concatdec.c though
[02:32] <wm4> he will rewrite everything
[02:32] <michaelni> no
[02:32] <michaelni> he will try
[02:32] <ubitux> haha, that was mean ;)
[02:33] <ubitux> wm4: he sent a patch a long while ago for chaptering in mkv
[02:33] <ubitux> and he definitely has some interest in that domain
[02:33] <ubitux> and when i see what's happening to lavfi everyday
[02:33] <ubitux> i wouldn't like to do that same for the chaptering and stuff
[02:34] <Daemon404> have it output the metadata to stderr
[02:34] <Daemon404> so we can parse it
[02:34] Action: ubitux hits Daemon404 violently
[03:23] <ubitux> what is the most common between tff and bff?
[03:23] <ubitux> (to know on what to fallback by default)
[03:23] <ubitux> tff i guess?
[04:30] <ubitux> Daemon404: any idea what "MI" stands for in TFM? (combed pixel score per block afaiu)
[04:31] <Daemon404> http://avisynth.org.ru/docs/english/externalfilters/tivtc_tfm.htm
[04:31] <Daemon404> "The # of combed pixels inside any of the blocky by blockx size blocks on the frame for the frame to be detected as combed. While cthresh controls how "visible" the combing must be, this setting controls "how much" combing there must be in any localized area (a window defined by the blockx and blocky settings) on the frame. Min setting = 0, max setting = blocky x blockx (at which point no frames will ever be detected as combed).
[04:32] <ubitux> yes right, i get what it is i have that definition
[04:32] <ubitux> i'm wondering about the letters
[04:32] <ubitux> what they stand for
[04:32] <ubitux> the definition doesn't help me much
[04:32] <Daemon404> i have no diea
[04:33] Action: ubitux is going to annoy Myrsloik now instead
[04:33] <Daemon404> i doube he knows
[04:33] <Daemon404> tritical's special mind came up with it
[04:33] <ubitux> it *might* be "matching inside"
[04:34] <ubitux> or "matching interlacing"
[04:34] <ubitux> but i'm certainly mistaken
[04:35] <ubitux> "maximum interlacing" maybe
[04:35] <ubitux> or "maximum inside"
[04:36] <ubitux> and then he forgot what "MI" standed for and added a 'c' for count at the end, which makes absolutely no sense at all
[04:36] Action: ubitux doesn't get it
[04:37] <ubitux> "metrics inside" maybe?
[04:39] <Daemon404> google for d9 posts only shows tritical using MIC or MI
[04:40] <ubitux> yes, the 'c' i was talking about
[04:40] <ubitux> maybe that's just because "mic" is cute
[04:41] <Daemon404> consider that this was originally written by an EE, and was probably originaly written in matlab
[04:41] <Daemon404> set your expectations there.
[04:46] <cone-134> ffmpeg.git 03Michael Niedermayer 07master:47540c8a68c9: avformat/avs: increase probe score to preempt conflict with avxsynth
[04:46] <cone-134> ffmpeg.git 03d s 07master:b9ad009475f3: AviSynth demuxer rewrite.
[04:46] <cone-134> ffmpeg.git 03Stephen Hutchinson 07master:cedf27651d13: Provide local copies of AviSynth's and AvxSynth's requisite headers in compat/avisynth/.
[04:46] <ubitux> i don't know much about matlab, but thanks for the hint
[05:16] <ubitux> maybe that's "mental illness"
[05:17] <ubitux> haha
[05:17] <ubitux> from tritical:
[05:17] <ubitux> I guess MIC stands for "max (or maximum) interlacing count". Originally, tfm never kept track of the "MIC" value it just checked to see if any of the blocks in the image produced counts over MI. When I decided to start keeping track of the values I just added C onto MI to get MIC for a new variable name. 
[05:17] <ubitux> ok.
[05:17] <ubitux> so even him doesn't really know
[05:18] <ubitux> exactly my guess then
[05:18] <ubitux> he added the 'c' after not knowing anymore what "mi" standed for
[05:18] <ubitux> ok let's be a bit smarter in the port then
[05:18] <Daemon404> ubitux, you emailed him?
[05:19] <ubitux> no, i used this magic: https://duckduckgo.com/?q=%22mic+stands+for%22+tivtc
[05:19] <Daemon404> lo
[05:19] <Daemon404> l
[05:19] <ubitux> yes i was very lucky ;)
[05:19] <ubitux> search engine are incredible sometimes :D
[07:30] <renevolution> Hi all, just a short question to the official devs, hope someone's here: Is it allowed to use the FFmpeg logo in a blog post as header image? Are there any restrictions?
[10:16] <durandal_1707> ubitux: did you saw new gsoc task for quatar?
[10:16] <durandal_1707> *see, damn
[10:27] <cone-939> ffmpeg.git 03Paul B Mahol 07master:c5b484e6162c: lavfi/vf_stereo3d: use standard options parsing
[12:03] <cone-939> ffmpeg.git 03Janne Grunau 07master:a157c7f2b8ac: h264: fix bit depth changes with frame threading
[12:03] <cone-939> ffmpeg.git 03Janne Grunau 07master:1c4073efd241: fate: add tests for h264 decoder reinit
[12:03] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:82f95d7fd7c0: h264: drop special case for 9bit chroma422
[12:03] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:6c8ac2d78230: Merge commit '1c4073efd24164ac6eaa52c544f5cdb0e5f6aee5'
[12:16] <cone-939> ffmpeg.git 03Anton Khirnov 07master:25408b2a0660: h264: make ff_h264_frame_start static.
[12:16] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:bbc0f6f97893: Merge commit '25408b2a0660c1e6c8555559c4ed71dff2ede31e'
[12:40] <cone-939> ffmpeg.git 03Anton Khirnov 07master:48d0fd2d62a4: h264: merge common_init() into ff_h264_decode_init.
[12:40] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:137df692fc28: Merge commit '48d0fd2d62a476e1db9298163f1fc0abae26cc67'
[12:48] <cone-939> ffmpeg.git 03Anton Khirnov 07master:82313eaa34b0: h264: add a parameter to the MB_MBAFF macro.
[12:48] <cone-939> ffmpeg.git 03Anton Khirnov 07master:da6be8fcec16: h264: add a parameter to the MB_FIELD macro.
[12:48] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:e168b508163d: Merge commit 'da6be8fcec16a94d8084bda8bb8a0a411a96bcf7'
[12:57] <cone-939> ffmpeg.git 03Anton Khirnov 07master:7bece9b22f75: h264: add a parameter to the FRAME_MBAFF macro.
[12:57] <cone-939> ffmpeg.git 03Anton Khirnov 07master:7fa00653a550: h264: add a parameter to the FIELD_PICTURE macro.
[12:57] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:bf4d0f8328c8: Merge commit '7fa00653a550c0d24b3951c0f9fed6350ecf5ce4'
[13:02] <cone-939> ffmpeg.git 03Anton Khirnov 07master:a6931d8ecea1: h264: add a parameter to the FIELD_OR_MBAFF_PICTURE macro.
[13:02] <cone-939> ffmpeg.git 03Anton Khirnov 07master:6d2b6f21eb45: h264: add a parameter to the CABAC macro.
[13:02] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:92656787cfea: Merge commit '6d2b6f21eb45ffbda1103c772060303648714832'
[13:11] <cone-939> ffmpeg.git 03Anton Khirnov 07master:e962bd08ee4b: h264: add a parameter to the CHROMA422 macro.
[13:11] <cone-939> ffmpeg.git 03Anton Khirnov 07master:23e85be58fc6: h264: add a parameter to the CHROMA444 macro.
[13:11] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:86d9d349cce5: Merge commit '23e85be58fc64b2e804e68b0034a08a6d257e523'
[13:16] <cone-939> ffmpeg.git 03Anton Khirnov 07master:fcf75022d72e: h264: remove redundant freeing of DPB in h264_decode_end
[13:16] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:881050d22928: Merge remote-tracking branch 'qatar/master'
[13:23] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:de8049d27cc9: h264: add an argument to CHROMA for consistency
[13:24] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:f3980b75f82b: h264: remove unused variable
[13:35] <BBB> Compn: yeah that was sarcasm
[14:40] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:4257b804e235: ffmpeg: Replace -deinterlace (which was broken by the buffer ref stuff) with yadif injection
[14:42] <Compn> renevolution : is it a news post? if so, thats fine under fair use usa copyright laws...
[14:42] <Compn> news/commentary
[14:47] <renevolution> Compn: Yes, it may be a news post or a how to / tutorial
[14:48] <Compn> thats fine
[14:49] <renevolution> could you explain what means fair use usa copyright use? Just need to mention from where the picture comes from?
[14:52] <michaelni> Daemon404, I think libutvideo needs a update for buffe refs
[14:52] <Compn> renevolution : one sec, i'm trying to locate the license on our current logo
[14:52] <Compn> michaelni might also know :)
[14:57] Action: Compn smiles @ http://ffmpeg.org/pipermail/ffmpeg-devel/2009-February/065878.html
[14:59] <Compn> renevolution : Herve Flores is the one who designed our current logo , michaelni also should know what the current copyright license is on that file
[15:01] <Compn> if you are just writing a gpl or creative commons licensed howto , i dont think anyone will bother you about using the logo
[15:01] <renevolution> Compn: Thank you. Missed that in the list. 
[15:02] <renevolution> Yes, that's the point. This was my thought earlier.
[15:02] <Compn> you mean that mailing list post? i wouldnt trust what mans said ...
[15:02] <Compn> since it was back in 2009 :)
[15:03] <Compn> renevolution : here is fair use info, in the usa at least > http://en.wikipedia.org/wiki/Fair_use#Fair_use_under_United_States_law
[15:03] Action: michaelni doesnt understand why people ask about things they already have the rights to from "fair use"
[15:03] <Compn> michaelni : you know all countries dont have it
[15:03] <renevolution> michaelni: Sorry, i'm from germany and doesn't even know anything about the law in the us
[15:07] <michaelni> renevolution, i think you quite independantly of where you are dont need our permission to use the ffmpeg logo to refer to ffmpeg
[15:10] <renevolution> michaelni, ok, sorry for bothering. The whole blog stuff is quite new to me and i didn't want to start wrong. That's why i asked.
[15:11] <renevolution> Thank you for clearing this up for me
[15:11] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:a728a28dac58: v308dec: remove unneeded self assignment
[15:11] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:8251c053209c: g729dec: switch to buffer refs style
[15:14] <michaelni> do we have any person volunteer or developer willing to help with libstagefright ?
[15:14] <michaelni> it probably also needs an update for the buffer ref stuff
[16:13] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:1426291eb84c: sonicdec: check decorrelation
[16:13] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:6ec037c5a9e1: sonicdec: fix frame size
[16:13] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:85d7f546627d: sonicenc: fix mono decorrelation
[16:13] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:4aa8503399d4: sonicdec: update to new buffer API
[16:23] <BBB> yay, so is -deinterlace gone now?
[16:23] <BBB> can we kill all the object files?
[16:23] <BBB> that would be wonderful
[16:23] <nevcairiel> i think the api just got deprecated
[16:23] <BBB> yeah I did that
[16:24] <nevcairiel> which means removing it now would basically surprise people that its suddenly gone with not much of a warning
[16:25] <BBB> hm... fine
[16:25] <BBB> oh right I was going to do libavutil disentangling
[19:57] <cone-939> ffmpeg.git 03Andrew Euell 07master:f8217daa8e77: vda_h264: fix for VDA compile
[19:59] <Megapixar>  How come encoding to .mp4 or to .h264 shows libx264 SEI; if I output to .ts - libx264 SEI is not shown? using ffmpeg 1.2.
[20:01] <michaelni> what do you mean by "shows libx264 SEI" ?
[20:03] <Megapixar> During encoding I can see in ERROUT all of the libx264 encoiding switches, as long as utput format is h264 or mp4. If its .ts, none of SEi id shown.
[20:05] <Megapixar> michaelni: is it supposed to be like that or I'm messing something up for ts output?
[20:12] <michaelni> Megapixar, i see no match for sei on stderr on any encoding to h264, mp4 or ts
[20:59] <llogan> saste: are you aware of any new orgs applying to GSoC this year? I am not.
[20:59] <saste> llogan, how can I know?
[20:59] <saste> but not that i know
[21:00] <llogan> i guess i could trawl #gsoc if they have a log.
[21:01] <saste> llogan, any particular reason for which you want to know?
[21:01] <llogan> the app was well written. thanks for taking the time to write it. i only have a few nits that i'll submit to you today.
[21:01] <saste> ok
[21:01] <llogan> just the last quesiton in the app. more curious than anything
[21:01] <saste> i still have to cross check with the application form of this year
[21:01] <saste> i based the text on last year form
[21:02] <llogan> yes, i was going to do that as well
[21:02] <saste> even if i don't think the new one will contain significant differences
[21:02] <saste> anyone with experience of libsox internal API?
[21:04] <llogan> i've only compiled it so far, but the author is communitive and friendly.
[21:05] Action: llogan can't remember who was planning on comparing it... (probably not a user in #ffmpeg-devel)
[21:11] <llogan> saste: i'd like to get some ffmpeg stickers made. they'd be nice for conventions, give to devs, maybe sell n' mail via website, etc. how would i go about doing this using some funds from donations?
[21:13] <saste> llogan, SPI covers only *expenses*, I don't know if we can consider stickers like expenses
[21:13] <saste> i should probably ask SPI guys
[21:13] <saste> i asked them before SPI application, and no one replied
[21:13] <llogan> hmm... ok. if not maybe i'll just buy them myself.
[21:27] <llogan> saste: oops. i confused libsox with libsoxr...
[22:31] <llogan> ubitux: do you have a backup mentor for subtitles task?
[22:32] <saste> llogan, nicolas
[22:32] <llogan> i'll update that section
[22:32] <saste> but he doesn't have a mm account yet
[22:33] <saste> *hasn't
[22:34] <llogan> that's ok. being listed with no contact info is better than no listed backup mentor.
[22:35] <llogan> since lack of backup mentors was one of the reasons GSoC listed as why were were not accepted
[22:36] <saste> llogan, i'll figure as de nomine backup mentor if we lack official backup mentors
[22:37] <llogan> ok. thanks.
[22:37] <llogan> michaelni: what about your tasks (MVC, postproc)? Do you have an official backup mentor(s)?
[22:39] <michaelni> not that i know
[22:39] <michaelni> but you can add me as backup for "Bayer RGB colorspaces "
[22:40] <saste> llogan, we still lack an introductory blurb for *students*
[22:40] <saste> we had one last year, but was removed for copyright reasons (sic!)
[22:40] <llogan> yeah, that's next on my list. for some reason i've been dreading it...
[22:41] <saste> in case you want to write it, you should not copy the one for libav, or the story will repeat
[22:41] <saste> *for -> from
[22:41] <llogan> agreed. i've been ignoring them.
[22:42] <saste> another thing i want to do is place a link to each dev page
[22:42] <llogan> michaelni: ok, thanks. i'll update bayer section
[22:42] <llogan> dev page == mm acount?
[22:43] <llogan> * mm account user page
[22:45] <saste> llogan, yes
[22:46] <saste> the page should contain a few info like irc nickname and email address
[22:46] <saste> so the student can easily contact the mentor
[22:47] <saste> otoh at least for the email address it should be added by the respective mentor, since there are privacy/spam concerns
[22:50] <michaelni> does webp and vp9 make sense as gsoc tasks ?
[22:51] <michaelni> and would we have mentor volunteers ?
[22:52] <gnafu> While I'm not 100% sure, I don't know that VP9 is in a state where independent implementations should be worked on yet.
[22:52] <JEEB> it seems to be at a rather early stage
[22:53] <gnafu> I think anyone wanting to work on VP9 should work with the WebM team to improve the initial release of the reference VP9 code.
[22:53] <gnafu> xvp8, on the other hand...
[22:53] <gnafu> ;D
[23:37] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:732b2fde1c84: vdpau.h: change vdpau_render_state layout to match fork if AV_HAVE_INCOMPATIBLE_FORK_ABI
[23:37] <cone-939> ffmpeg.git 03Michael Niedermayer 07master:21a5f5ea5d08: error_resilience: fix const correctness, silence warnings
[23:54] Action: Daemon404 wonders if eval even has an "or" operator
[23:58] <Daemon404> guess it's plus
[00:00] --- Fri Mar 22 2013