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

[burek]

[00:11] <saste> michaelni, do you have comments about opencl design?
[00:13] <michaelni> saste, what part in particular ?
[00:14] <saste> michaelni, you had some remarks, i don't know if they have been addressed or discussed
[00:14] <saste> especially with regards to thread-safeness and threading API usage
[00:18] <michaelni> i was looking at opencl 1.0 which explicitly said half the functions are NOT thread safe, 1.2 says they are all thread safe
[00:20] <saste> michaelni, another concern was that all the kernels are concatenated and compiled together
[00:23] <michaelni> yeah, doesnt make me happy either but the author prefers it that way, also libavfilter itself is also a big blob and not loading the filters one by one
[00:23] <saste> michaelni, are you ok with the global context?
[00:24] <saste> also I'd prefer to leave review to the thread locking to someone else, they seem weird to me and i'm not familiar with that API
[00:29] <llogan> jommy: i'm ogg ignorant, but did you trawl the bug tracker? https://ffmpeg.org/trac/ffmpeg
[00:32] <michaelni> saste, ill look at the thread locking
[00:34] <jommy> llogan, yes I searched through there but didn't find anything yet
[00:36] <llogan> jommy: if you think it is a bug (I'm not sure) you can report it.
[01:13] <michaelni> saste, about the global context, i have no real oppinion, if it works no objections from me
[01:14] <saste> michaelni, same for me
[01:14] <saste> it might work if i'm not too confused
[01:17] <jojva> why wasn't ffmpeg/libav accepted in gsoc 2012, is it because of the friction with libav ? 
[01:18] <Plorkyeran> they didn't want to pick a fork iirc
[01:18] <jojva> what about this year then ?
[01:19] <j-b> This year is gonna be fun
[01:19] <j-b> I will bet it will depend on BBB
[01:20] <jojva> j-b, why ?
[01:22] <j-b> You'll see :)
[01:24] <ubitux> < Plorkyeran> they didn't want to pick a fork iirc // they actually picked the fork
[01:24] <ubitux> j-b: he said he was out of the gsoc this year
[01:24] <Plorkyeran> oh, they did end up accepting libav?
[01:25] <ubitux> they pick libav and not ffmpeg last year
[01:25] <Plorkyeran> I guess I stopped paying attention at some point
[01:25] <ubitux> so we did a better page this year
[01:25] <Plorkyeran> I just remember them initially saying they wouldn't take either to avoid picking sides or something
[01:25] <ubitux> hopefully we will be selected this time
[01:26] <j-b> what is your page?
[01:26] <saste> ffmpeg was not accepted for various reasons, not necessarily related to the forking status
[01:26] <saste> some of the reasons were explained and documented, so we should stick with the official reasons given by google
[01:27] <jojva> I couldn't find them, which is why i asked directly here
[01:27] <ubitux> j-b: http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2013
[01:28] <saste> also they should make room for new orgs from time to time, so was just in their right that they decided to favor other orgs in place of ffmpeg
[01:28] <saste> jojva, official reasons were that we had a weak mentoring backup plan, which was true
[01:29] <saste> and we hadn't "fleshed out" enough ideas
[01:29] <saste> we are trying to do better this year
[01:30] <iive> saste: the official reason was PR bulshit 
[01:30] <ubitux> :D
[01:30] <iive> but I can say that because i'm not ffmpeg developer atm.
[01:30] <saste> the real reasons, nobody knows but gsoc admins
[01:31] <saste> also, who cares anyway?
[01:31] <iive> afair they didn't wanted to fund 2 forks... so they picked libav, and BBB was belong the people who decided that.
[01:31] <ubitux> saste: intro is nice btw
[01:31] <jojva> saste, ok thx, I hope it works I'll definitely take my chance as a student. We'll know in a few days...
[01:36] <ubitux> jojva: so you want to do the the mvc thing as student? :)
[01:39] <jojva> ubitux: I've thought about it yes, and since the project is interesting (and there's a 5Gs reward :p), I'll apply. With the reward I can even make it a full-time job so, definitely yes.
[01:41] <ubitux> ok :)
[02:01] <ubitux> saste: can you come up with a new name for the decimate filter?
[02:02] <ubitux> !
[02:02] <ubitux> :(
[02:02] <ubitux> always the same :(
[02:02] <ubitux> well, whatever
[02:04] <michaelni> saste and the ping timeouts ...
[02:08] <cone-184> ffmpeg.git 03Clément BSsch 07master:0fb9f77a39d3: LICENSE: add libutvideo in the GPL libraries list.
[02:15] <cone-184> ffmpeg.git 03Michael Niedermayer 07master:6ae03353de66: mpegvideo: Make the table reallocation more robust.
[02:15] <cone-184> ffmpeg.git 03Michael Niedermayer 07master:551f683861bb: yop: Do not keep a copy of parts of the returned packet
[02:23] <iive> ubitux: dedup ?
[02:23] <ubitux> it's not really a dedup
[02:23] <ubitux> the main goal is to reach a certain framerate
[02:23] <ubitux> so regularly drop a frame
[02:24] <ubitux> it just happens to drop the dup
[02:24] <iive> then fixed_fps or constant_fps
[02:24] <iive> can it repeat frames, if needed?
[02:25] <Daemon404> these are literally the dumbest names for a decimation filter ever
[02:25] <Daemon404> it's decimation. that's what it is defined as.
[02:25] <Daemon404> anything else is literally the wrong term.
[02:25] <iive> so, it removes every 10th frame?
[02:26] <Daemon404> >3:2 pattern
[02:26] <Daemon404> yeah, no.
[02:29] <Daemon404> ubitux, vdecimate / tdecimate / <something>decimate is pretty much what you want
[02:30] <ubitux> fdecimate?
[02:30] <Daemon404> thats actuall a different avs filter
[02:30] <Daemon404> <.<
[02:30] <ubitux> :(
[02:30] <Daemon404> im not up to speed at why we want to keep the mp decimate as decimate (perhaps so poor poor souls will end up doing fm,decimate and getting terrible results?)
[02:30] <Daemon404> i think not having fm and this decimate be obviously related somehow wildly violates teh principal of least astonishment
[02:31] <ubitux> i defended that point
[02:32] <ubitux> that was the reason motivating using the decimate name and moving current decimate to mpdecimate
[02:32] <Daemon404> i can only see leading mpdecimate as decimate leading to Bad Things
[02:32] Action: Daemon404 shrugs
[02:32] <Daemon404> s/leading/leaving/
[02:33] <Daemon404> if you cant rename mpdecimate
[02:33] <iive> Daemon404: so basically, you insist the filter to be called decimate, because avs calls it like this?
[02:33] <Daemon404> actually its not caleld that n avs
[02:33] <Daemon404> ubitux renamed them
[02:33] <ubitux> fieldmatch, decimate
[02:34] <ubitux> i renamed a few other things too
[02:34] <ubitux> like the "MI" making no sense
[02:34] <iive> you renamed avisynth filters? :O
[02:34] <Daemon404> ubitux, if you cant rename mpdecimate, prefixing both of them would be the only otehr idea i have
[02:35] <iive> Daemon404: i'm sorry, but what i hear and see is uter bulshit.
[02:35] <ubitux> iive :)
[02:35] <Daemon404> iive, in what way
[02:35] <Daemon404> ?
[02:35] <ubitux> https://github.com/ubitux/FFmpeg/commits/ivtc
[02:35] <ubitux> fyi this is the current state 
[02:35] <Daemon404> mp decimate is a piece of shit
[02:36] <iive> the filter name should make it obvious what the filter does and not be confusing in any way.
[02:36] <Daemon404> ........
[02:36] <Daemon404> thats my fucking point
[02:36] <Daemon404> [21:22] <@iive> ubitux: dedup ?
[02:36] <Daemon404> aka this ^
[02:36] <Daemon404> is 100% wrong
[02:36] <Daemon404> and does not represent what it does
[02:36] <ubitux> iive: it's likely the current decimate filter will never be used after this anyway
[02:37] <iive> I asked you, does the filter remove ever 10th frame, because this is what the word decimate means.
[02:37] <ubitux> one solution is to add the current decimate options to the new one
[02:37] <ubitux> to not break compat
[02:37] <Daemon404> iive, that is NOT what decimate means
[02:37] <ubitux> but i don't want to do that
[02:37] <Daemon404> fucking look it up
[02:37] <Daemon404> "10th frame" came from nowhere
[02:37] <ubitux> iive: every N frames, the filter will drop one; it happens to be a dupped one often
[02:38] <iive> deci means te
[02:38] <Daemon404> http://en.wikipedia.org/wiki/Decimation_(signal_processing)
[02:38] <iive> ten
[02:38] <Daemon404> ................
[02:38] <Daemon404> are you retarded?
[02:39] <iive> i'm referring to the first meaning http://en.wikipedia.org/wiki/Decimation_(Roman_army) , as this is the origin of the word.
[02:39] <Daemon404> you realize decimation is a whitespread and well-defined word in he world if DSP?
[02:39] <Daemon404> widespread*
[02:39] <Daemon404> you are going to see it in any texts related to it
[02:40] <Daemon404> and specifications
[02:40] <Daemon404> lavfi happens to be a DSP library.
[02:40] <iive> even the wiki article that you point gives better word, downsampling.
[02:40] <Daemon404> ierally every resource you fin relating to IVTC and telecine
[02:41] <Daemon404> will use the word decimation
[02:41] <iive> and the article talks mostly about audio processing.
[02:41] <Daemon404> literally*
[02:41] <Daemon404> ... why am i wasting my time talkign to someone who clearly ha no goddamn clue
[02:41] <iive> I don't care. The filter names should be explicit without having nerd dictionary.
[02:44] <iive> ubitux: so, once again, what does the filter do exactly, what parameters does it get?
[02:44] <ubitux> iive: see 02:35:37 <@ubitux> https://github.com/ubitux/FFmpeg/commits/ivtc
[02:47] <iive> so, the filter collects a "cycle"  number of frames and drops one of them, likely the duplicated one?
[02:48] <ubitux> yes
[02:48] <ubitux> 02:37:56 <@ubitux> iive: every N frames, the filter will drop one; it happens to be a dupped one often
[02:49] <ubitux> iive: note that current decimate filter is likely unused
[02:49] <ubitux> and if used, likely with no specific option, or without scripting
[02:49] <ubitux> so i doubt the rename to mpdecimate will change anything
[02:49] <ubitux> of course this will be done alone a minor bump of lavfi
[02:49] <iive> i would guess that each frame in lavfi have its own pts, are these recalculated?
[02:50] <ubitux> yess
[02:50] <ubitux> at least in my filter
[02:50] <ubitux> not sure about the mp one
[02:50] <iive> the mp one is not supposed to. it just removes duplications.
[02:51] <ubitux> the goal of the mp one was actually the same purpose
[02:51] <ubitux> a post field matching filter
[02:51] <ubitux> it was for ivtc as well
[02:51] <ubitux> the original goal was likely lost at some point
[02:52] <ubitux> and likely no one really care anyway
[02:52] <iive> not really, most ivtc in mplayer don't produce duplicated frames.
[02:52] <ubitux> i won't check the 5 ivtc filters in mplayer to prove you wrong :p
[02:53] <iive> filmdint been the monster that does everything. ivtc, deinterlace and fps.
[02:54] <ubitux> so monster it's disabled by the mp wrapper ;)
[02:55] <iive> ndecimate may be a good name. it removes every N-th frame.
[02:56] <ubitux> possibly, but as Derek pointed out, it will cause trouble for people wanting an obvious ivtc workflow
[02:56] <iive> or one of every n-th frames. but to have the logic of the name revealed you should use this explanation somewhere.
[02:56] <ubitux> "fieldmatch, then the decimate filter... let's use 'decimate'"
[02:58] <iive> then rename mp decimate into deduplicate / dedup or something that does explain what it does.
[02:58] <ubitux> current decimate filter is a bad name, and essentially an inappropriate filter in most of the cases, especially with this new filter incoming
[02:58] <ubitux> also, i belive the rename won't hurt anything, and actually prevent harmful problems
[02:59] <iive> well, both filters do remove samples, so both do "decimation" in DSP sense.
[02:59] <ubitux> outside an ivtc workflow i failed to see any real cases for the current decimate filter
[03:00] <ubitux> iive: are you so against renaming the current filter?
[03:00] <ubitux> is that really a problem?
[03:00] <iive> i'm happy when what the filter does is obvious by looking at its name.
[03:01] <ubitux> decimate is really the name used everywhere when talking about ivtc
[03:01] <iive> If I were to request something from the new filter, it would be to set the output framerate as number
[03:02] <ubitux> you have thousands of xxxdecimatexxx filters
[03:02] <BBB> iive: conspiracy theory 101?
[03:03] <iive> no real conspiracy... just bad practices propagating because they are common.
[03:03] <iive> oh, you talk about gsoc.
[03:03] <BBB> yes
[03:03] <BBB> my last highlight was from you
[03:06] <iive> so?
[03:06] <BBB> like I said, nice conspiracy 101, but I don't think that's quite reflective of reality
[03:06] <BBB> but what do I know
[03:07] <ubitux> BBB: btw, what is the status of the un-dsputil thing and related?
[03:07] <ubitux> still some split to do to reduce size for chromium?
[03:07] <BBB> no, chrome is done, afaik
[03:08] <ubitux> oh, ok cool
[03:08] <BBB> I can still do it for other codecs, but it's slightly lower-priority
[03:08] <BBB> so I'll probably not do anything before vp9 is done
[03:08] <iive> Well, maybe you can say it straight. Not just dance around the issue.
[03:08] <ubitux> what's the current todo list then?
[03:08] <BBB> iive: I'm not part of opensource labs, so I have no more information than you do
[03:08] <BBB> ubitux: well, dsputil still exists
[03:08] <BBB> ubitux: as long as it exists, it needs to die
[03:09] Action: ubitux would like to use dsputils properly in lavfi :(
[03:09] <BBB> not dsputil; dsp utilities
[03:09] <ubitux> right
[03:09] <BBB> that's a great idea
[03:09] <ubitux> we currently use some deprecated interface, that sucks a bit
[03:09] <ubitux> (see vf select and the scene detection for instance, or delogo iirc)
[03:09] <BBB> do it like h264, vp8 etc. do it: make a new dsp context which either shares stuff between different components, or is specific for the one thing that needs dsp
[03:09] <iive> BBB: so you have never ever given any advices to your colleagues about any projects in gsoc? and you have not been affiliated in any way with gsoc?
[03:10] <BBB> iive: I've mentored for libav
[03:10] <BBB> and I've mentored for ffmpeg before that
[03:10] <BBB> I was admin for libav 2 yrs ago
[03:10] <BBB> so it's hard to make a case that I was unaffiliated with gsoc
[03:10] <iive> and that's all?
[03:11] <bcoudurier> what time is it in europe ?
[03:11] <iive> 2 am GMT
[03:12] <BBB> I have colleagues in the opensource labs who organize gsoc and are fully responsible and make their own adult decisions about it. they are colleagues, so we may certainly have informal discussion on all kind of stuff related to opensource software in general
[03:12] <BBB> but I don't advise them on what project to accept or not
[03:12] <BBB> nor should I
[03:13] <ubitux> so video dsp only has a edge mc utility?
[03:14] <iive> oh, never underestimate the power of right words told to the right person.
[03:14] <iive> people are influenced by their peers, by other people whom they trust.
[03:15] <iive> anyway, other than that, I wanted to ask you if you have been involved in gsoc from the google side.
[03:16] <ubitux> BBB: i'm not sure to get what would be the difference between dsp utilities and dsp util
[03:16] <ubitux> BBB: i guess removing from dsputil the code specific functions?
[03:17] <BBB> iive: well of course people are influenced by peers, I'm not denying that
[03:17] <ubitux> i see huffyuv, h263 and h261 specific code
[03:17] <BBB> ubitux: exactly
[03:18] <BBB> huffyuv is an easy one
[03:18] <ubitux> is there more?
[03:18] <BBB> a few
[03:18] <BBB> dnxhd I believe uses dsputil also
[03:18] <BBB> all mpegvideo ones, as you said, huffyuv and some other similar lossless ones (they use the same functions, actually)
[03:18] <BBB> snow
[03:18] <BBB> I guess that's it?
[03:19] <BBB> iive: I have not been involved in gsoc from either the google side or from the ffmpeg/libav side
[03:19] <BBB> (this year)
[03:19] <iive> i'm talking about the previous year (2012)
[03:19] <ubitux> BBB: i didn't follow how the split was done; some were put in codec specific code, and since video codecs were mostly using dsputil for edge mc thing it was moved to a dedicated one?
[03:20] <iive> You've already said (on multiple occasions) that you are not involved this year.
[03:20] <ubitux> iive: can we discuss gsoc later, when we will be accepted/rejected instead? :)
[03:21] <ubitux> no point really in living in what happened last year
[03:21] <iive> (And if my conspiracy is true, this is quite unfortunate for ffmpeg ;)
[03:21] <ubitux> that failure actually forced us to make a better gsoc page, i believe it's a good thing in one sense
[03:21] <ubitux> whatever the reason we got rejected, something came out of it i believe, so let's stick on this :p
[03:22] <BBB> ubitux: right
[03:22] <ubitux> something *good*
[03:22] <BBB> iive: like I said, conspiracy 101
[03:22] <BBB> let's not go there
[03:22] <funman> ubitux: btw i got feedback from Kevin about the windows / sdl discussion this morning
[03:22] <ubitux> funman: yeah he told me
[03:22] <ubitux> i was trying to troll him
[03:23] <ubitux> of course he reacted just as expected
[03:23] <funman> well he told me 'it is not windows fault' so troll was succesful :P
[03:23] <ubitux> :)
[03:23] <iive> BBB: in every myth, there is one kernel of truth....  (e.g. mythbusters)
[03:24] <funman> unfortunately i still don't know how to have console output AND not have a console window spawn each time you run the .exe from the desktop/explorer
[03:24] <ubitux> don't ask me :p
[03:25] <BBB> ubitux: http://pastebin.com/S8vVrgpC complete list of everything using DSPContext
[03:26] <BBB> dirac seems like a mistake, the dsp functions for that were very recently added to dspcontext
[03:26] <BBB> that should not have been done imo
[03:26] <BBB> many of them look trivial and can probably be converted relatively easily
[03:26] <ubitux> ok
[03:26] <ubitux> btw, any idea why dsputil_init is deprecated?
[03:27] <ubitux> shouldn't we have a avpriv_dsputil_init() or something?
[03:27] <ubitux> (assuming dsputil is considered dsp utilities)
[03:27] <ubitux> (which seems to be its transformation afaiu)
[03:30] <ubitux> well i guess that's a lavfi specific issue anyway
[03:31] <ubitux> that's the only library outside lavc which needs access to it
[03:31] <ubitux> but i'm surprised sws or swr aren't using it
[03:34] Action: ubitux wonders why mp=spp builds fine using ff_dsputil_init
[03:35] <ubitux> anyone to port it btw? :(
[03:38] <iive> BBB: I've been asking you if you have been involved in gsoc on google side for 2012, and so far you have dodged the question at least 2 times. I would like a straight answer.
[03:39] <BBB> ubitux: dsputil != dsp utilities
[03:39] <BBB> ubitux: dsputil needs to die
[03:40] <BBB> ubitux: it can be split in small, manageable and well-designed dsp utilities, some of which may need a avpriv prefix
[03:40] <ubitux> BBB: well, when codec specific code will be out of dsputil, won't it become a dsp utilities? :p
[03:40] <BBB> also ff_ is fine except on shared library builds with symbol elimination
[03:40] <BBB> if codec specific code goes out of dsputil, it no longer exists
[03:40] <BBB> there is no single bit that can be shared across 100s of codecs
[03:41] <BBB> some of it can maybe be shared between 10 or so?
[03:41] <BBB> like emulated_edge_mc
[03:41] <BBB> which is why we moved it to a more generically named videodsp
[03:41] <ubitux> so you would split every "utility" in a different context?
[03:41] <BBB> no, just group them together more logically
[03:42] <BBB> I'm quite sure we both agree there's no need for huffyuv median prediction and h263 loopfilter to be in the same dsp utility context
[03:42] <ubitux> i consider this codec specific
[03:42] <BBB> it's highly unlikely that all codecs that require a h263 loopfilter also require huffyuv
[03:42] <ubitux> but as i said, when you purge these things out of dsputil
[03:43] <BBB> in fact it's highly unlikely that _any_ codec that uses h263 lf needs huffyuv code
[03:43] <ubitux> it's likely dsputil will only contain generic dsp utilities, no?
[03:43] <BBB> maybe
[03:43] <BBB> I don't know
[03:43] <ubitux> typically in lavfi we use sad, diff_pixel, etc
[03:43] <BBB> I don't expect that to ever finish tbh
[03:43] <BBB> I see DSPContext as something that can eventually be renamed to MpegEncDSPContext or so
[03:44] <BBB> but maybe not, I don't know
[03:44] <ubitux> looks like dsp utilities with various codec specific bits that need to be out of it to me
[03:44] <ubitux> at least in the current state
[03:44] <BBB> if you feel that sad can be shared between lavfi and lavc, either use dsputil, or split it out in a new context and use that
[03:45] <BBB> it can be done both ways
[03:45] <ubitux> so using dsputil as dsp utilities looks legit to me, at least in the context that i'm interested in: lavfi
[03:45] <ubitux> BBB: we already use dsputil in 3 filters
[03:45] <BBB> just be sure to know that you're incurring the cost of _all_ functions in it if you do that
[03:45] <BBB> I know
[03:45] <BBB> and I'm sad that we do
[03:45] <BBB> I feel this whole thing could be deisgned better
[03:45] <BBB> but I'm 100% realistic that many people dont care
[03:45] <BBB> brb baby
[03:47] <BBB> look, my point is that if you look at ffmpeg as a whole, right, all that code is already in there, so it makes no difference
[03:47] <BBB> if you look at it as a collection of individual components, where you can pick and choose (like chrome does), I feel it's a bad idea
[03:47] <BBB> but do what you feel is bad, I don't try to hold a decisive vote here
[03:47] <BBB> just please don't reintroduce a dspcontext or mpegvideo dependency in h264 or vp8 or vp3 or aac or mp3 or vorbis
[03:48] <ubitux> haha my goal was more lowly
[03:48] <ubitux> just wondering about the dsputil warning :p
[03:48] <BBB> oops, I said "bad"
[03:48] <BBB> I meant "right"
[03:49] <BBB> sorry, that was honest mistake
[03:49] <BBB> do what you feel is right
[03:49] <iive> The trick here is not the context on its own, but how it is filled with function pointers. because it have common init, all functions must be present, thus compiled and linked.
[03:54] <BBB> ubitux: e.g. if you feel sad is useful, why not split that and some other related and similarly used functions out in a new context called DistortionDSPContext?
[03:55] <ubitux> it's likely i will end up moving every lavfi function needed in it
[03:55] <BBB> that sounds ok
[03:55] <BBB> you could move that to lavutil
[03:55] <BBB> and then lavfi would stop depending on all of lavc
[03:55] <BBB> which is kind of nice
[03:56] <BBB> like I said, some people care about tht sort of stuff, others don't. I don't really care (given that chrome doesn't use lavfi)
[03:56] <ubitux> that will certainly make saste happy
[03:56] <ubitux> BBB: note that lavfi doesn't depend on lavc
[03:56] <BBB> you just told me it uses dsputil
[03:56] <ubitux> having it against lavc enables some feature
[03:57] <ubitux> yes, but it's not a hard dep
[03:57] <ubitux> select has scene detection only if lavc is enabled
[03:57] <ubitux> and filters using dsputil are conditionally enabled as well
[03:57] <BBB> if you feel that's the best design, then by all means, go for it
[03:58] <ubitux> i've no real opinion on it tbh :)
[04:03] <ubitux> mmh i'm tempted to add a aperms before the volume in fate
[04:05] <ubitux> does anyone know where fate stores some hard dep?
[04:06] <ubitux> ok, found..
[04:09] <iive> ubitux: in case i didn't get to finish the point. about the new decimate filter. usually you want to get from 30 to 24 fps (ivtc). The problem with the "cycle" parameter is that you need to know the input and desired output framerate and
[04:09] <iive> (most importantly) do some math outside of ffmpeg.
[04:12] <iive> well, i'm off.
[05:09] <cone-184> ffmpeg.git 03Michael Niedermayer 07master:aa28c4253438: mjpegdec: check buffer before using it
[05:09] <cone-184> ffmpeg.git 03Michael Niedermayer 07master:24cfe91a2202: id3v2: allocate large enough buffer
[11:02] <cone-819> ffmpeg.git 03Justin Ruggles 07master:c3d015775388: flvdec: use the correct audio codec id when parsing metadata
[11:02] <cone-819> ffmpeg.git 03Michael Niedermayer 07master:8ed9d34aa7f0: Merge commit 'c3d015775388882b8a122afc337ea35108f652be'
[11:13] <cone-819> ffmpeg.git 03Justin Ruggles 07master:e46a2a7309d8: flvdec: read audio sample size and channels metadata
[11:13] <cone-819> ffmpeg.git 03Michael Niedermayer 07master:774a2684973e: Merge remote-tracking branch 'qatar/master'
[11:59] <ubitux> isn't av_frame_copy_props() supposed to copy audio props as well?
[11:59] <ubitux> i don't see the channels being copied
[11:59] <ubitux> also, af volume seems not to use it
[12:00] <nevcairiel> av_frame_copy_props only copies properties which are optional for the format, any code working with buffers is supposed to set the properties that are mandatory to describe the buffer itself
[12:00] <nevcairiel> thats w/h/format for video, and nb_samples/channels/channel_layout for audio
[12:00] <nevcairiel> oh and format too
[12:01] <ubitux>  so i spotted 2 bugs?
[12:02] <ubitux> nb_samples, channels and channel_layout are not copied in av_frame_copy_props
[12:02] <nevcairiel> intentionally so
[12:02] <ubitux> oh misread what you said
[12:02] <ubitux> ok
[12:03] <nevcairiel> but yes there is a bug that af_volume doesnt call it when allocating a new buffer
[12:03] <nevcairiel> ff_get_audio_buffer sets all the important properties
[12:03] <ubitux> note that this part of the code is not covered by fate
[12:03] <ubitux> i'll add aperms in front of the fate test
[12:04] <ubitux> so this code path can be tested
[12:05] <nevcairiel> not sure how many of the optional properties apply to audio, so it may not do anything
[13:03] <saste> kierank, ping?
[13:03] <kierank> pong
[13:04] <saste> kierank, willing to mentor a gsoc task?
[13:04] <saste> maybe something related to VC-1?
[13:04] <kierank> i don't know much about vc-1
[13:04] <kierank> and i thought vc-1 was compliant now
[13:04] <kierank> ??
[13:05] <saste> or something else
[13:05] <saste> as for VC-1 I'm not the person to ask, but there are still some outstanding bugs as far as i know
[13:05] <saste> just let me know in case
[13:06] <saste> we have still ~1 week to fill the gsoc page
[13:20] <michaelni> Ive seen several VC1 videos that show artifacts so theres definitly work left tp be done
[13:20] <Compn> was vc1 interlacing finished ?
[13:21] <michaelni> there where patches that implemented more of it which where applied i havnt checked if anything is left
[13:22] <nevcairiel> the major features are in now, but there is still stuff missing to make it 100% idential to the reference decoder
[13:23] <nevcairiel> like, loop filtering for interlaced
[13:23] <nevcairiel> and some bugs
[13:23] <Compn> k :)
[13:23] <michaelni> nevcairiel, do you want to mentor a vc1 task that implements the missing things and fixes the bugs ?
[13:23] <nevcairiel> i have no clue about video coding
[13:24] <michaelni> Its not really about video coding its about comparing spec/reference against our code and fixing differences
[13:25] <michaelni> boring work so maybe its not so bad idea as gsoc
[13:29] <nevcairiel> i imagine fixing those 
[13:29] <nevcairiel> ugs also requires knowledge abouit video decoding
[13:29] <nevcairiel> bugs*
[13:31] <michaelni> it could be done simply by putting printf() in a reference decoder and av_log() in ours and running diff
[13:31] <michaelni> IMHO this doesnt need much knowledge about video coding
[13:32] <michaelni> of course its more work than it sounds when writing it that way
[13:33] <michaelni> but i dont think it requires deep knowledge of the code ...
[13:33] <ubitux> speaking of av_log, it would be nice to have a "printf" mode
[13:33] <michaelni> printf mode ?
[13:33] <ubitux> basically, no "last message repeated"
[13:34] <ubitux> and eventually ignore ctx to not print any prefix
[13:34] <ubitux> that's handy to make some stdout diff
[13:36] <michaelni> indeed
[13:38] <michaelni> should be rather simple to add such mode, iam a bit busy with other ffmpeg work ATM though 
[13:39] Action: ubitux not working on it either
[13:53] <ubitux> btw, on GSOC page, "Qualification Task: TBD" on bayer rgb
[13:53] <ubitux> might be relevant to set one
[13:59] <michaelni> ubitux, fixed
[14:00] <ubitux> thanks :)
[14:28] <jojva> not to seem greedy but, does that happen often that students receive bad evaluations and aren't paid during gsoc ?
[14:30] <Compn> not much
[14:31] <Compn> only if a student does no work , missing, etc
[14:31] <Compn> which has happened. students sign up then are unreachable
[14:31] <Compn> unfinished projects still get paid iirc
[14:31] <Compn> some students keep working after gsoc to finish it too... :)
[14:39] <jojva> ok it's better than I expected
[14:39] <jojva> Dissapearing is weird, it's a contract... It's like leaving a company without telling
[14:42] <Compn> some people want to go on vacation :P
[14:42] <Compn> or maybe got a job
[14:43] <jojva> I guess vacation is possible, as long as the work is done and it's not "going to brazil for a roadtrip"^^^
[15:04] <iive> gsoc is kind of a job. You do the task you get money.
[15:24] <nevcairiel> while the project doesnt necessarily need to be 100% finished, there at least have to be signs of good progress =p
[15:28] <ubitux> that's certainly a great learning experience and give you recognition
[15:29] <ubitux> who cares about money
[15:29] <iive> this should not not be a problem if the student is working continuously and the mentor guides him.
[15:29] <ubitux> ;)
[15:46] <jojva> ubitux: students who can't pay their food for example ;)
[15:47] <jojva> But I do agree with you, it's a very nice experience to do
[15:48] <ubitux> :)
[17:40] <ubitux> michaelni: i believe the help should show up with -help filters
[17:41] <ubitux> and -help filter=mandelbrot
[17:41] <ubitux> filter help already appears with -help full
[17:42] <ubitux> (and on a side note, devices don't seem to appear with -help full)
[17:42] <michaelni> ubitux, how does the user know of  -help filter=mandelbrot ?
[17:43] <michaelni> -vf crop=help is a quite natural way to ask the crop filter for help
[17:43] <ubitux> Getting help: -h      -- print basic options -h long -- print more options -h full -- print all options (including all format and codec specific options, very long)
[17:43] <ubitux> i'd suggest to extend this text ^
[17:43] <durandal_1707> -acodec mp3=help
[17:43] <michaelni> durandal_1707, yes, would be nice too
[17:44] <ubitux> and maybe display it by default when calling ./ffmpeg
[17:44] <durandal_1707> noo!
[17:44] <ubitux> we already have a help display system
[17:44] <ubitux> this is what we should improve
[17:44] <durandal_1707> michaelni: i really dislike what that user proposed
[17:45] <ubitux> ffmpeg -help {long,full,filters,formats,codecs,...}
[17:45] <durandal_1707> and having flag in filter context for it is poor 
[17:45] <ubitux> ffmpeg -help codec=libmp3lame
[17:45] <ubitux> ffmpeg -help filter=mandelbrot
[17:45] <michaelni> Its a question if you want ffmpeg  to be useable and intuitiv for non geeks
[17:45] <ubitux> sounds relatively trivial as soon as the "Getting help" message is improved
[17:46] <durandal_1707> michaelni: nonsense, non geeks dont use console tools, they use GUI
[17:47] <durandal_1707> speaking of that what about some official gui for ffmpeg
[17:47] <michaelni> durandal_1707, thats a great idea
[17:47] <ubitux> a gui for constructing filtergraph too
[17:48] <durandal_1707> pick gtk/qt/?
[17:48] <microchip_> qt!
[17:48] <ubitux> gtk
[17:52] <durandal_1707> there are no "Prerequisites" for  bayer gsoc task
[17:54] <cone-819> ffmpeg.git 03Xidorn Quan 07master:c81d2fa96ddc: avutil/buffer: add get_opaque
[17:54] <cone-819> ffmpeg.git 03Michael Niedermayer 07master:ef7b6b489ab3: ffmpeg/avformat: factor av_guess_frame_rate() out
[17:57] <durandal_1707> what is prefered way to handle several sample formats in filter?
[17:58] <durandal_1707> use single function to get samples inside for loops or macros - which is faster
[18:01] <wm4> macros containing inline asm for max supper speed
[18:03] <michaelni> durandal_1707, fixed prereq
[18:03] <durandal_1707> ?
[18:04] <michaelni> Prerequisites for bayer gsoc task
[18:04] <durandal_1707> ah, don't write cripticy shorts
[18:04] <ubitux> fxd prq
[18:04] <durandal_1707> i wld spk lik ths
[18:04] <michaelni> k
[18:04] Action: ubitux undrsd wll
[18:05] <michaelni> bcoudurier, IIRC you said you would be happy to mentor anything ?
[18:06] <michaelni> any preferrance ?
[18:07] <michaelni> for example something from: http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2013#Unmentored_Projects
[18:07] <michaelni> ?
[18:13] <durandal_1707> ubitux: i gonna split filter into: (stereo)vectorscope, phasescope (with optional? history like showspectrum ([-1, 1] meter); balance(meter/scope/gram/???) same as phasescope with histogram; [cross?]correlation[scope?] ditto with history (eg, cross correlation calculated with FFT)
[18:14] <ubitux> whatever you prefer :p
[18:15] Action: ubitux wants some fft 2d utils :(
[18:15] <durandal_1707> ubitux: elaborate
[18:16] <ubitux> elaborate on 2d fft?
[18:16] <ubitux> afaict ff rdft etc utils are 1d only
[18:16] <durandal_1707> for what you will use it?
[18:17] <cone-819> ffmpeg.git 03Xidorn Quan 07master:c7269e3a2697: vda_h264_dec: fit the new API
[18:17] <ubitux> video filtering
[18:17] <ubitux> a lot of algorithm depends on dft 2d run on mb
[18:18] <durandal_1707> aw. i'm currenly in audio filtering waters
[18:18] <ubitux> yes, 1d :)
[20:05] <durandal_1707> it is ok to have memcmp in probe ?
[20:17] <cone-819> ffmpeg.git 03Paul B Mahol 07master:8263726c69cf: lavc: fix typo
[20:17] <cone-819> ffmpeg.git 03Paul B Mahol 07master:67f9bbbb3f62: noise_bsf: check if allocation failed
[20:51] <cone-819> ffmpeg.git 03Paul B Mahol 07master:a345b7f906de: vmdav: use more unchecked bytestream2 variants where it makes sense
[20:56] <durandal_1707> michaelni: fixing other sizeof(AVFrame) in lavc?
[21:03] <durandal_1707> icoenc actually fails to write PAL8 bmps on big-endian
[21:09] <michaelni> sizeof(AVFrame) use should be fixed unless we declare the libs to be ABI "linked"
[21:11] <cone-819> ffmpeg.git 03Michael Niedermayer 07master:66e9716a3610: aacps: correct opdipd code to match spec
[21:11] <durandal_1707> michaelni: i know that already, but question was/is: are you going/working to fix it at this moment/future?
[21:13] <michaelni> at the moment no, i have other ffmpeg related work to do
[21:19] <cone-819> ffmpeg.git 03Paul B Mahol 07master:1c11ab82d650: paf_video: make code independent of sizeof(AVFrame)
[21:33] <wm4> <michaelni> sizeof(AVFrame) use should be fixed unless we declare the libs to be ABI "linked" <- I think the idea that the libraries are independent is an illusion, and causes more maintenance work and confusion for both developers and users
[21:35] <durandal_1707> they currently are linked, but in future may not need to be, (once rewrite everything at last sunday of month on full moon stops)
[21:41] <cone-819> ffmpeg.git 03Matt Wolenetz 07master:65340c976c66: Fix pthread_cond and pthread_mutex leaks in vp8
[22:03] <durandal_1707> for ffloger failed compile is same as failed test
[00:00] --- Sat Mar 30 2013