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

[burek]

[00:04] <CIA-108> ffmpeg: 03Carl Eugen Hoyos 07master * rea604de91e 10ffmpeg/libavcodec/pngdec.c: Simplify "deloco" and support decoding of 48bit loco png.
[00:14] <CIA-108> ffmpeg: 03Carl Eugen Hoyos 07master * r97da38c99b 10ffmpeg/libavcodec/pngdec.c: 
[00:14] <CIA-108> ffmpeg: Allow decoding of 64bit png images.
[00:14] <CIA-108> ffmpeg: Fixes a part of ticket #639.
[00:23] <CIA-108> ffmpeg: 03Michael Niedermayer 07master * rb8c1655882 10ffmpeg/libavformat/avidec.c: 
[00:23] <CIA-108> ffmpeg: avidec: print informative error messages if seeking fails.
[00:23] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:46] <ubitux> Daemon404: what's wrong with lpostproc?
[00:46] <ubitux> why libav ppl want to get rid of it?
[00:46] <Daemon404> it's deprecated and not maintained, and noone wants to touch its code
[00:46] <kierank> unmaintainable
[00:47] <ubitux> isn't just a 1k line .c?
[00:47] <Daemon404> go look at its code
[00:47] <Daemon404> :)
[00:47] <kierank> 3500 lines of inline asm
[00:47] <Daemon404> and macros
[00:47] <bcoudurier> let's remove vsfilter
[00:48] <Daemon404> ^ i wish
[00:48] <ubitux> :/
[00:48] <bcoudurier> let's remove avisynth
[00:48] <Daemon404> libass forever!
[00:48] <Daemon404> avisynth is idneed balls but it has nothing to replac it
[00:48] <ubitux> is there a replacement for postproc?
[00:48] <Plorkyeran> vsfilter > fontconfig~
[00:49] <bcoudurier> what's replacing postproc ?
[00:49] <Plorkyeran> just not using it?
[00:49] <Plorkyeran> it's not very useful in the first place
[00:49] <bcoudurier> :)
[00:49] <ubitux> i'm not anyone is very well suited to  decide of the needs of ppl like that
[00:49] <ubitux> +sure
[00:50] <Daemon404> ubitux, how is moving it to its own repo damaging btw
[00:50] <Daemon404> it;s literally no different
[00:50] <ubitux> the maintainer of postproc is the maintainer of the ffmpeg project afaik
[00:50] <Daemon404> [18:48] < Plorkyeran> vsfilter > fontconfig~ <-- i have hopes!
[00:50] <ubitux> why moving it outside?
[00:51] <Daemon404> ubitux, this is libav
[00:51] <ubitux> are you planing to nuke every code of the ffmpeg maintainer then? :)
[00:51] <Daemon404> no
[00:51] <ubitux> why?
[00:51] <ubitux> it's not "maintained" anymore
[00:52] <Daemon404> but it's pretty much consensus that postproc should die, among more than just libav developers
[00:52] <Daemon404> i guess not here
[00:52] <ubitux> yes, i understood that, but couldn't get the reasons
[00:52] <bcoudurier> I like that, names please ?
[00:52] <Daemon404> say hi to ffms2 devs
[00:52] <Daemon404> ubitux, because it is not very useful and its code is unmaintainable
[00:52] <Daemon404> i dont actually know ANYTHING using it
[00:52] <ubitux> mplayer?
[00:53] <bcoudurier> vlc
[00:53] <ubitux> :)
[00:53] <Daemon404> oh really?
[00:53] <kierank> yeah
[00:53] <ubitux> yes&
[00:53] <Daemon404> anyway, we could bikeshed this all day and you can flame me all you want
[00:53] <ubitux> not very useful ’ you don't know, unmaintainable: just improve it; is it broken?
[00:53] <Daemon404> but nothing will change
[00:54] <ubitux> it's not bikeshed, and we're not flaming you
[00:54] <bcoudurier> there is a recrudescence of nih in some part of the sphere
[00:54] <Daemon404> i just did it cause others wanted it and it was an interesting script to write to import teh git history
[00:54] <durandal_1707> the problem is it is not used by ffmpeg/libav at all
[00:54] <ubitux> the reasons are just obscure
[00:54] <Daemon404> so what is the problem with having libpostproc be external?
[00:54] <ubitux> libav* are a/v libs
[00:54] <ubitux> postproc is an a/v lib
[00:55] <ubitux> no?
[00:55] <Daemon404> thats some pretty bad reasoning...
[00:55] <ubitux> :/
[00:55] <ubitux> ffmpeg/libav* are supposed to provide API for processing a/v
[00:55] <durandal_1707> ubitux: make ffplay use libpostproc and I'm with you
[00:55] <ubitux> why doesn't it belong there?
[00:55] <Daemon404> so let me ask
[00:55] <ubitux> durandal_1707: ffmpeg doesn't only provides programs, but also libs
[00:55] <Daemon404> given we have libavfilter
[00:56] <Daemon404> what is the poitn of postproc?
[00:56] <ubitux> why not move it to lavfi ?
[00:56] <ubitux> instead of *removing* features? :/
[00:56] <TheFluff> I thought you lunix people were supposed to be against bloat
[00:56] <Daemon404> because i, liek everyone else am not fuckign touchign the wall of brainfuck that is postproc
[00:56] <ubitux> it just looks like another try of purification without caring about users
[00:56] <Daemon404> and porting it
[00:56] <TheFluff> oh wait hahahahahaha gnome and kde 
[00:57] <Daemon404> for teh nth time
[00:57] <Daemon404> NOTHING IS BEIGN REMOVED
[00:57] <Daemon404> it is being MOVED
[00:57] <ubitux> it's the same
[00:57] <Daemon404> no it isn;t.
[00:57] <ubitux> since no one will ever maintain the "working state"
[00:57] <TheFluff> wait why would it be the same
[00:57] <ubitux> it's just a "let it die"
[00:58] <Daemon404> [18:57] <@ubitux> since no one will ever maintain the "working state"
[00:58] <Daemon404> no
[00:58] <TheFluff> nobody maintains it now either so I don't see your point?
[00:58] <Daemon404> thats a fuckign assumption
[00:58] <Daemon404> you make
[00:58] <bcoudurier> TheFluff, scratch vsfilter ;)
[00:58] <Daemon404> [18:58] < TheFluff> nobody maintains it now either so I don't see your point? <-- tell you what, ill backport any changes that get made to postproc
[00:58] <ubitux> TheFluff: it's maintain at least to "keep builtin"
[00:58] <Daemon404> all one every 2 years
[00:58] <TheFluff> there are actually several maintained forks of vsfilters that add new functionality and fix old bugs
[00:58] <TheFluff> just sayin'
[00:59] <ubitux> Daemon404: you should have move it to lavfi instead of moving it outside the project
[00:59] <bcoudurier> wow, so it is maintainable after all ? 
[00:59] <durandal_1707> what is vsfilter?
[00:59] <TheFluff> ubitux: how is it builtin
[00:59] <TheFluff> durandal_1707: a subtitle renderer
[00:59] <Daemon404> ubitux, [18:56] <+Daemon404> because i, liek everyone else am not fuckign touchign the wall of brainfuck that is postproc
[00:59] <Daemon404> feel free too
[00:59] <ubitux> TheFluff: i meant "building" sorry
[00:59] <Daemon404> but im nto touching a giant mess of inline asm and macros.
[00:59] <TheFluff> it's not integrated with any other lav* libraries at all except for the fact that you can pass it a table of quantizers directly from a lavc codeccontext
[01:00] <TheFluff> and god help you if you ever change the structure of that particular table
[01:01] <bcoudurier> Daemon404, thankfully people didn't remove libswscale because of that reason
[01:01] <TheFluff> in fact I do not see any arguments whatsoever in favor of keeping it in the libav repository other than historical reasons, because really it has absolutely nothing to do with the rest of the libav stuff except using its version defines
[01:02] <Daemon404> bcoudurier, swscale actually does important and useful things
[01:02] <Daemon404> that cant be replaced
[01:02] <ubitux> TheFluff: we could port the vf pp from mplayer into lavfi pretty "easily"
[01:02] <ubitux> that would create a dependency
[01:02] <ubitux> would that be enough for you as a reason to keep it? :)
[01:03] <Daemon404> ubitux, by that logic you should keep libass in the same repo because vf_ass needs it.
[01:03] <TheFluff> hm yes a circular argument
[01:03] <TheFluff> I am very convinced
[01:03] <ubitux> the author isn't a ffmpeg developers
[01:03] <ubitux> it's an independent project
[01:04] <Daemon404> i fail to see how that matters
[01:04] <TheFluff> does that mean everything fabrice bellard ever writes should be in ffmpeg too
[01:04] <Daemon404> and nobody "develops" postproc
[01:04] <ubitux> what's the point if it works?
[01:04] <TheFluff> seriously where do you keep coming up with these arguments
[01:05] <bcoudurier> at least fork it from ffmpeg
[01:05] <bcoudurier> Daemon404, 
[01:05] <Daemon404> ?
[01:05] <bcoudurier> nobody from libav did anything to it
[01:06] <Daemon404> the code is the same in both repos
[01:06] <ubitux> TheFluff: libass is somehow related to image processing afaik& i wouldn't mind having it distributed with ffmpeg if the author did it in ffmpeg tree at first, that was my point
[01:06] <bcoudurier> headers and stuff
[01:06] <Daemon404> i merely chose to to import the history from for its files
[01:06] <Daemon404> oh the headers
[01:06] <bcoudurier> seems only fair to me
[01:06] <TheFluff> libpostproc has exactly one "killer feature" that isn't easily available elsewhere and that's the quantizer-based deblocking, just move that to libavfilter if you are so incredibly sensitive to "losing features"
[01:07] <ubitux> i don't care very much how much the libav is being purified of features
[01:07] <Daemon404> bcoudurier, id rather jusr s/Libav/FFmpeg/\Libav/g;
[01:07] <ubitux> i was just quite surprised
[01:07] <bcoudurier> from the great evil
[01:07] <durandal_1707> dump libpostproc, that obfsucated code and rewrite new one in lavfi from scratch
[01:07] <Daemon404> and keep everyone less butthurt
[01:08] <TheFluff> (keep in mind though that said feature works in the killer way with maybe two or three of the lavc codecs; with the rest it's just a very dumb deblocking filter)
[01:08] <durandal_1707> just forget about
[01:08] <durandal_1707> it
[01:08] <TheFluff> it's also really buggy and completely undocumented
[01:08] <ubitux> durandal_1707: rewriting "from scratch" is rarely a good idea
[01:08] <Daemon404> ubitux, for postproc it is.
[01:09] <Compn> i must say, your reasoning for moving postproc is fine :P
[01:09] Action: Compn not flaming, just strange logic going on in here
[01:09] <Compn> and i have no opinion one way or the other. aside from not making it more difficult for mplayer to use the library... which moving it out of repo would do
[01:09] <Daemon404> the whole idea is that is isnt really maintained, nothing in libav or ffmpeg uses is, and it may be useful outside of libav/ffmpeg
[01:09] <Compn> if mplayer does use it
[01:09] <Daemon404> so make it standalone.
[01:10] <ubitux> it may be useful inside too&
[01:10] <Compn> yeah but mplayer and vlc wont maintain it either, so making it standalone wont make it maintained
[01:10] <ubitux> having it in the repo reminds us that "hey there is something to do there" :)
[01:10] <Compn> what does making it standalone do to improve it ?
[01:10] <Compn> just curious
[01:10] <ubitux> the point is to purify the holy project Compn ;)
[01:10] <Daemon404> it doesnt "lose" anything by moving
[01:11] <Compn> PURITY OF ESSENCE
[01:11] <Compn> ubitux : tap water.
[01:11] <durandal_1707> whatever you do with it, it is going to be really slow death
[01:11] <Compn> should just start a rewrite
[01:11] <Daemon404> durandal_1707, i figured people would get butthurt when i sent that emai :/
[01:11] <TheFluff> I dunno about you guys but I don't really like having broken undocumented shit sitting around in my libraries that other people are expected to use
[01:11] <durandal_1707> except if you write better one
[01:11] <TheFluff> if you do it, do it right
[01:11] <Compn> TheFluff : send patch....
[01:12] <Compn> ehhe
[01:12] Action: Compn wins one for the cliche
[01:12] <Daemon404> [19:11] < Compn> should just start a rewrite <-- implying anyone can actually comprehend postprocs code....
[01:12] <durandal_1707> that it will die very fast
[01:12] <Compn> Daemon404 : i meant a rewrite of ffmpeg
[01:12] <Daemon404> wat?
[01:12] <ubitux> TheFluff: asking the users would have been wise instead of just avoid the problem
[01:12] <TheFluff> I am a postproc user
[01:12] <Compn> if you are going to whittle it down, one directory, one codec, one format at a time
[01:12] <Daemon404> ubitux, TheFluff is ffms2 developer
[01:12] <TheFluff> or well, "user", my library uses postproc and my library's users use it through mine
[01:13] Action: Compn should probably stay out of this, since he knows nothing about the topic
[01:13] <TheFluff> I think it's a terrible crock of shit and people ask me questions about why it doesn't work all the time
[01:13] <ubitux> then why didn't you work on exporting the API properly and make a simple lavfi filter?
[01:13] <TheFluff> that I can't answer because you don't maintain it and it's not documented
[01:13] <Daemon404> and you cant even follow the code
[01:13] <ubitux> where will you do bug reports if it's not in the project anymore?
[01:13] <Daemon404> cause its a buttlaod of inline asm,
[01:14] <TheFluff> nowhere, I'm going to deprecate it
[01:14] <Daemon404> ubitux, same bugtracker different heading/topic?
[01:14] <ubitux> with what replacement TheFluff?
[01:14] <TheFluff> actually I already did deprecate it with the excuse "libav is going to remove it"
[01:14] <Daemon404> it's merely a different repo
[01:14] <TheFluff> none
[01:14] <Daemon404> nobody misses it.
[01:14] <TheFluff> as I said it's not very useful
[01:14] <TheFluff> I accidentally posted a build with it disabled a while ago
[01:14] <TheFluff> it took weeks before someone even mentioned it wasn't there
[01:14] <ubitux> how come there is so much code if it isn't useful?
[01:15] <Daemon404> that is  a good question.
[01:15] <TheFluff> are you seriously implying
[01:15] <TheFluff> that all code is useful
[01:15] <Compn> libass in ffmpeg would be useful. +1
[01:15] <TheFluff> inherently useful, even
[01:15] <ubitux> Compn: :)
[01:15] <Compn> but probably too many bloats
[01:15] <Daemon404> Compn, remember how ffmpeg was talking about its own subttile filter?
[01:15] <Daemon404> <_<
[01:15] <bcoudurier> TheFluff, there is shitload of useless code here
[01:16] <ubitux> Daemon404: we are still talking about it, and i'm working on it
[01:16] <bcoudurier> that people rarely used
[01:16] <durandal_1707> bcoudurier: what is shit?
[01:16] <Daemon404> ubitux, is it libass based at least?
[01:16] <Compn> Daemon404 : i remember a lot of talk and no coding. 
[01:16] <TheFluff> also, people really liked their quantizer-based deblocking back in 2003 when you sorta had to watch divx 3 movies all the time
[01:16] <TheFluff> it was kinda useful in mplayer then, I guess
[01:16] <ubitux> Daemon404: will be for overlay yes, just like it is now
[01:16] <Daemon404> ok
[01:16] <Daemon404> it would be foolish not to
[01:16] <TheFluff> incidentally the last major functional changes in postproc were probably made sometime around that time
[01:17] <ubitux> Daemon404: there is something problematic with this
[01:17] <Compn> can i ask one more dumb question. which developer new to the project has looked at libpostproc and tried to work with it , without knowing it was depreciated ?
[01:17] <ubitux> Daemon404: you can't really have a hard dep on it since it's an external project
[01:17] <Compn> or 'deprecated' as some people would have you say
[01:17] <ubitux> we need to just make the overlay depends on it
[01:17] <Compn> freakin grammar nazis around here
[01:17] <durandal_1707> Compn: i never entered that directory -> that says it all
[01:17] <Daemon404> ubitux, it seems like youre redoign things libass has already accomplished
[01:17] <Daemon404> for naught
[01:17] <ubitux> ?
[01:17] <ubitux> what am i redoing?
[01:18] <bcoudurier> Compn, the nazis have left ;)
[01:18] <Compn> bcoudurier : yes, i was in the other channel for a bit :P
[01:18] <Daemon404> if you dont use libass, i mean, how do you expect to use it's functionality without redoing soem of its  code?
[01:18] <Daemon404> (i.e. dont make it a hard dep)
[01:18] <Compn> ubitux : Daemon404 is wondering if it would be better if you just made a vf_ass and didnt work on subtitles, passed it all to libass, etc
[01:18] <Daemon404> font handling etc
[01:18] <ubitux> Daemon404: i was thinking of having it in the repo ;)
[01:18] <Daemon404> is that a joke?
[01:18] <ubitux> Daemon404: but of course that won't happen :)
[01:19] <ubitux> Daemon404: the point is, it wouldn't have been an issue if libass was part of ffmpeg project
[01:19] <Daemon404> i dont see a reason nto to require it for building the subtitle filter
[01:19] <Compn> does ffmpeg have any external libs ?
[01:19] <Daemon404> ubitux, because NIH?
[01:19] <Daemon404> and external deps are satan?
[01:19] <durandal_1707> Compn: libc
[01:19] <TheFluff> what is the problem with having the subtitle filter being an optional component that depends on an external library
[01:19] <ubitux> Daemon404: because it's harder to deal with the dep
[01:19] <Daemon404> this soudns fucking dumb.
[01:19] <TheFluff> I mean it's not like you don't have other such optional components
[01:19] <Daemon404> what TheFluff said.
[01:19] <bcoudurier> libass need not be in the repo
[01:19] <TheFluff> oh wait, it was Not Invented Here, clearly you cannot use it
[01:19] <bcoudurier> although libass dependencies are hell
[01:20] <ubitux> as far as libass is limited to ass overlay it's fine
[01:20] <bcoudurier> and I mean _hell_
[01:20] <TheFluff> yes
[01:20] <TheFluff> yes they are
[01:20] <Daemon404> you should render most things with libass really
[01:20] <TheFluff> but that's Somebody Else's Problem
[01:20] <Daemon404> s/most/all/
[01:20] <bcoudurier> mostly harfbuzz to be fair though
[01:20] <ubitux> that's the intention Daemon404 
[01:20] <Daemon404> harfbuzz fork you mean, bcoudurier 
[01:20] <Daemon404> ;)
[01:20] <Compn> when did anime pirates dictate which subtitle renderers we must use ?
[01:20] <bcoudurier> the fork has issues
[01:20] <Compn> thats what i want to know.
[01:20] <bcoudurier> I told greg already
[01:20] <ubitux> Compn: :D
[01:21] <Daemon404> Compn, since always
[01:21] <durandal_1707> everything is going 3D lets deprecate ffmpeg/libav
[01:21] <bcoudurier> ligatures are fucked in some situations
[01:21] <Plorkyeran> shockingly enough people who do things with subtitles are the ones that care about subtitle renderers
[01:21] <Compn> there was talk about switching to libass in mplayer
[01:21] <bcoudurier> well x264 is the future anyway ;)
[01:21] <Compn> but libass was so much slower than mplayer's optimized sub renderer
[01:22] <Plorkyeran> uh
[01:22] <Plorkyeran> what
[01:22] <Compn> just different things for different people
[01:22] <TheFluff> 00:47:41 <+kierank> 3500 lines of inline asm <-- wow, you sure weren't kidding, I just took a look at postprocess_template.c
[01:22] <durandal_1707> bcoudurier: hevc
[01:22] <Daemon404> bcoudurier, guess where lorren came from? :P anime pirate.
[01:22] <Plorkyeran> libass is mplayer's sub render
[01:22] <ubitux> isn't the internal osd just dealing with gray levels Compn?
[01:22] <ubitux> Plorkyeran: not the default
[01:22] <Plorkyeran> it wasn't even spun off into its own repo until a few years ago
[01:22] <Compn> ubitux : its color in -vo gl, using gl extras
[01:22] <Compn> but yes, otherwise gray
[01:23] <Plorkyeran> yes, it also has its hilariously broken one that isn't actually usable
[01:23] <Plorkyeran> that mostly just serves to confuse users
[01:23] <ubitux> -noass isn't the default for various reasons
[01:23] <Compn> mplayer likes to confuse, mplayer doesnt want dumb users ;P
[01:23] <Compn> send them to vlc... :P
[01:23] <bcoudurier> poeple reimplemting libass are stupid 
[01:23] <durandal_1707> mplayer uses own version of libass
[01:23] <Compn> durandal_1707 : no, its synced to svn now
[01:24] <Compn> manually, anyways
[01:24] <TheFluff> vlc uses libass too so idgi
[01:24] <Compn> its cool that libass went on to its own project. means more players can use it
[01:25] <Daemon404> Compn, i hope it gets its windows backend working well soon enough
[01:25] <Daemon404> so a dshow filter can be written, and vsfilter brough out behind the barn and shot
[01:25] <Compn> Daemon404 : isnt that in ffdshow... 
[01:25] <Daemon404> no?
[01:25] <Daemon404> and ffdshow is on its way out
[01:25] <Daemon404> its code is so bad everyone is ditching it
[01:25] <Compn> whats it being replaced with ?
[01:25] <Daemon404> for lav filters
[01:26] <Compn> heh
[01:26] <Compn> ffdshow is a bunch of different things at once 
[01:26] <Compn> its lavf + mp vf system + lavc
[01:26] <ubitux> erh with all the flames i started i didn't had time to finish my lavfi/libswr work :(
[01:26] <ubitux> 'night ppl :)
[01:26] <Daemon404> night.
[01:26] <Compn> ubitux : dont flame, only code , gnight
[01:27] <Compn> so what else can we argue about
[01:27] <Compn> what tasks are we coming up with in GSOC this year ?
[01:28] <ubitux> oh, forgot something
[01:28] <Compn> the great libav conspiracy > spend hours fixing every grammar , spelling and cosmetic problem in the code. if come across a file without any of those (all inline asm) just rm it .
[01:29] Action: durandal_1707 kicks Compn
[01:29] <Compn> lol
[01:29] <ubitux> Daemon404: sorry, that will make you certainly angry but& why no leave the libpostproc maintainance to ffmpeg (and ask user to build postproc from independant ffmpeg repo?)
[01:30] <Compn> ubitux : because they want to move it to a diff repo
[01:30] <ubitux> it is still available though ffmpeg
[01:30] <Daemon404> not my call (tm)
[01:30] <TheFluff> postprocess_template.c is hilarious, there's inline asm, "templating" of function using the c preprocessor, inline asm "functions" generated dynamically with the preprocessor, bitwise operation tango with magic numbers picked seemingly at random, reference in the comments to optimizing for the P4, and probably several hundred lines of commented-out debug code
[01:30] <Compn> Daemon404 : anyways, did you ask michaelni ?
[01:30] <ubitux> Compn: it is a different repo
[01:30] <Daemon404> Compn, i did this at teh request of libav.
[01:30] <ubitux> ffmpeg is a different repo as libav afaik
[01:30] <Compn> Daemon404 : yeah, but you better ask michael, since hes maintainer iirc
[01:30] <Compn> its just me and ubitux complaining in here, we arent maintainers :p
[01:31] <ubitux> i'm not complaining
[01:31] <ubitux> trying to understand, somehow
[01:31] <Compn> discussing
[01:31] <Daemon404> Compn, he is not listed as having touched it since 2008...
[01:31] <Compn> michaelni : Daemon404 wants to know if libav can move postproc to another repo
[01:31] <ubitux> i see little point in letting libpostproc rotting in an abandonned repository since it's still available in ffmpeg
[01:31] <Daemon404> Compn, no
[01:31] <Daemon404> it's getting moved regardless
[01:32] <Compn> yes we know that
[01:32] <TheFluff> it's rotting in ffmpeg too so what's the difference
[01:32] <Daemon404> ^
[01:32] <ubitux> TheFluff: less work?
[01:32] <Daemon404> wat?
[01:32] <Compn> ubitux : stop biting and go code/sleep :P
[01:32] <ubitux> TheFluff: i mean, just drop it and redirect libpostproc/ffmpeg repo
[01:32] <durandal_1707> faster git co?
[01:32] <Daemon404> it's not like this affects ffmpeg at all
[01:32] <Daemon404> so i dont see why you give a  crap?
[01:32] <ubitux> TheFluff: what is a point of the burden of the export?
[01:33] <TheFluff> having a broken feature is worse than not having it at all
[01:33] <ubitux> don't be so aggressive Daemon404, i'm just trying to understand why you are trying to do that
[01:33] <Daemon404> ubitux, look for the "nuke libpostproc" thread on libav-devel
[01:33] <Daemon404> by adam
[01:33] <Daemon404> perhaps you will find your answer there
[01:33] <ubitux> i read it
[01:33] <ubitux> i'm on the mailing list
[01:34] <Compn> ubitux : are you looking for the reason why they want to move it ?
[01:34] <Compn> the reason why it must be moved ?
[01:34] <ubitux> i just see little point in the standalone libpostproc if you don't feel like maintaining it
[01:34] <Daemon404> [19:32] < durandal_1707> faster git co? <-- no not really at all
[01:34] <Daemon404> not the way git works.
[01:34] <ubitux> and you KNOW no one except the ffmpeg maintainer will ever maintain it
[01:34] <Daemon404> ubitux, i said i WOULD maintain it
[01:34] <Daemon404> with any fixes needed
[01:34] <ubitux> so why do you care about the export?
[01:34] <Daemon404> jeez
[01:34] <ubitux> Daemon404: why would you do that?
[01:35] <Daemon404> it will get the exact amount of "maintaining" that it gets in ffmpeg/libav
[01:35] <Daemon404> period.
[01:35] <ubitux> what's the point of keeping it in sync with ffmpeg?
[01:35] <ubitux> if you don't plan to add a plu-value
[01:35] <Compn> ubitux is wondering why not just rm it
[01:35] <Compn> ?
[01:35] <ubitux> Compn: yes
[01:35] <Compn> if no one uses it
[01:35] <TheFluff> I can't even find the last time someone made an actual functional change to libpostproc
[01:35] <ubitux> the point is, there is still a copy available
[01:35] <Compn> let mplayer/vlc fork it
[01:35] <ubitux> even if libav drop it
[01:35] <Daemon404> Compn, hey i wanted to rm -rf it
[01:35] <TheFluff> it was before 2006 at least
[01:36] <TheFluff> i.e. 6 (six) years ago
[01:36] <Compn> its an old bikeshed, i'm sure postproc has come up in the list before
[01:36] <Daemon404> ANYWAY, i did what people wanted, and other peopel jumped down my throat
[01:36] <Daemon404> so /care
[01:36] <Daemon404> crew y'all
[01:36] <Daemon404> im going to get drunk
[01:36] <Daemon404> screw*
[01:36] <ubitux> :/
[01:36] <TheFluff> all of the "maintenance" in the last six years has basically consisted of keeping up with changes in various libavutil macros
[01:36] <Compn> i'm not jumping
[01:36] <Compn> just like to talk 
[01:37] <ubitux> i wonder if my question was even understood
[01:37] <Compn> TheFluff : sorry, i'm talking about the generic 'anything with no maintainer is maintained by michael' rule. not that that file is maintained or not, he is 'maintainer' of it
[01:37] <ubitux> well whatever, seems it's hot enough in there
[01:38] <TheFluff> I don't understand why you are talking about the importance of maintaining libpostproc in the first place
[01:38] <Compn> i'm not
[01:38] <TheFluff> you act like it is being maintained now
[01:38] <Compn> i just said ask michael 
[01:38] <Compn> what he wants to do with it
[01:38] <TheFluff> when in fact it has not been for over six years
[01:39] <TheFluff> I think if he wanted to do something he has more than enough time to do it now
[01:39] <Compn> lol
[01:39] <Compn> then dont ask michael
[01:39] <ubitux> :)
[01:39] <Compn> you are being contradictory
[01:39] <TheFluff> judging by the comments in the postproc source files the last time someone actually fixed or changed something in it was sometime in 2004
[01:39] <TheFluff> contradictory how
[01:40] <Compn> someone comes here and asks if its ok to move, but its being moved already, so whats the point in asking, and you say its not important to ask?
[01:40] <TheFluff> 01:39:06 < TheFluff> I think if he wanted to do something he has more than enough time to do it now <--- s/he has more/he has had more/
[01:40] <Compn> so i'm confuseeeeeeeeeeeeed
[01:40] <TheFluff> I thought the entire debate was about how it was not going to be moved because you didn't want to lose features/make it unmaintained/whatever I don't even know
[01:41] <Compn> i thought the debate was 1. does anyone use postproc and 2. does michael care about moving it
[01:41] <TheFluff> that was mostly ubitux saying that and not you though
[01:41] <Compn> heeh
[01:42] <Compn> ubitux 's question was , whats the point in moving it 
[01:42] <ubitux> TheFluff: that was my first point, but i guess i have an answer for this
[01:42] <ubitux> the second point is still unanswered though
[01:42] <TheFluff> what was the second poin
[01:42] <TheFluff> t
[01:42] <ubitux> the second point is: why do you care about moving it outside libav if it is still available for third-party usage in ffmpeg?
[01:43] <Compn> ubitux : 'because its ugly' apparently
[01:43] <ubitux> libpostproc users can still build it independtly, and libav don't have to maintain it
[01:44] <ubitux> and can just drop it
[01:44] <TheFluff> I think I missed that part of the discussion entirely because I have no idea what you mean by "third-party usage in ffmpeg"
[01:44] <ubitux> Compn: i meant, libav could just drop it and let ffmpeg maintains it, not worth forking a dead project
[01:44] Action: Compn spent too much time on this bikeshed
[01:44] <ubitux> TheFluff: mplayer/vlc users
[01:44] <ubitux> for example
[01:44] <Compn> ubitux : yes, but i think libav wanted some kind of cooperation 
[01:44] <ubitux> or anyone using it independently of ffmpeg
[01:44] <Compn> i'm not sure what cooperation, Daemon404 was mum on that
[01:44] <TheFluff> oh you meant libav as in the libav project, not as in libav*
[01:44] <ubitux> yes
[01:44] <ubitux> the name is confusing.
[01:45] <TheFluff> I agree
[01:45] <TheFluff> I don't know, I don't know what d404 was trying to do nor who he was (mis)representing, I just think you should get rid of that piece of shit
[01:45] <TheFluff> hope this helps!
[01:46] <ubitux> i can understand you just want to get rid of it (first point), the second was about "why so much trouble exporting it if you don't plan to do anything particulary constructive with it"?
[01:46] <ubitux> (and since it's still available in another "maintained" repo
[01:47] <TheFluff> because I happen to maintain a library that has the great misfortune of being able to use it and I need a good excuse for dropping it
[01:47] <ubitux> you still have it
[01:47] <Compn> lol
[01:47] <Compn> that is a hilarious reason.
[01:47] <ubitux> "libav is dropping libpostproc"
[01:47] <ubitux> with or without proper export
[01:47] <TheFluff> unfortunately we have gone to great lengths to be compatible with both ffmpeg and libav
[01:48] <ubitux> you can still use libpostproc from ffmpeg and use libav for the rest
[01:48] <Compn> TheFluff : so have lots of other projects
[01:48] <Compn> :(
[01:48] <ubitux> (also, ffmpeg is compatible with libav)
[01:48] <TheFluff> only almost, but that's a discussion for another time
[01:48] <ubitux> yes
[01:48] <Daemon404> ubitux, i wanted to rm -rf postproc. not my decision
[01:48] <TheFluff> personally I think you should just rm -rf libpostproc though
[01:48] <Daemon404> now, booze yime.
[01:49] <ubitux> Daemon404: if you're doing work i was naively thinking you knew why
[01:49] <TheFluff> I don't think you should spend a second more of effort on it than absolutely necessary
[01:49] <Daemon404> ubitux, because it was interesting to write teh import script
[01:49] <Daemon404> basically.
[01:49] <ubitux> hehe ok :)
[01:49] <ubitux> but exporting it as no point by itself?
[01:50] <ubitux> expect the learning point, which is a good one
[01:50] <Daemon404> ask libav folks, i dont know.
[01:50] <Daemon404> now srsly, booze.
[01:50] Action: Daemon404 gone
[01:50] <ubitux> 'night :)
[01:50] <ubitux> i won't ask libav folks
[01:50] <ubitux> i'm fed up being ignored ;)
[01:50] <Compn> TheFluff : sorry for calling you contradictory, i was mixing your and Daemon404's discussion into one opinion
[01:51] <Compn> two people with two opinions ;)
[01:51] <TheFluff> no problems 
[01:51] <TheFluff> if you're going to be that way I guess I'll have to pretend to be sorry for being an confrontational asshole, but I'm not, really, it's just how I roll
[01:53] <iive> TheFluff: I guess you can save a lot of headache by supporting just FFmpeg :P
[01:54] <TheFluff> summary: I think libpostproc is a (buggy) misfeature at best and that alone should be reason enough for considering getting rid of it; the facts that it hasn't been touched in any significant way since 2004 and is extremely unlikely to be fixed due to its extremely hairy codebase do not help its case
[01:54] <iive> TheFluff: what bugs?
[01:56] <TheFluff> image corruption with certain resolutions, filter string parsing has a number of funny issues (you need to add a comma to the end of the filter string or it'll corrupt the heap iirc), other silly stuff
[01:57] <Compn> bugs that TheFluff does not feel like reporting to bug tracker :P
[01:57] Action: Compn trolls hard
[01:57] <TheFluff> I can probably dig up a few more in excruciating detail if you really want to know
[01:57] Action: Compn rolls his troll die
[01:57] <TheFluff> Compn: hurpa durpa
[01:57] Action: Compn should get a troll die
[01:57] <TheFluff> >implying they'd get fixed 
[01:57] <TheFluff> etc
[01:57] <Compn> >implying they will be fixed if you dont report them
[01:57] <Compn> >implying someone will fix it
[01:58] <TheFluff> they've been there for at the very least six years, if nobody else has reported them then clearly nobody actually uses postproc and that too is an argument speaking in favor of its deletion
[01:58] <iive> I want you to dig the bugs up and unload them on the bugtracker
[01:59] <TheFluff> :effort:
[01:59] <TheFluff> actually hum maybe I should do it
[01:59] <Plorkyeran> the heap corruption without a comma at the end bug had a patch sent to the mailing list at some point
[01:59] <Plorkyeran> I don't think it ever got applied
[01:59] <Compn> a forgotten patch!
[01:59] <Compn> :P
[02:04] <durandal_1707> there are myriad of them...
[02:06] <iive> durandal_1707: do you have a list?
[02:07] Action: durandal_1707 shame, i coded nothing today
[02:07] <durandal_1707> iive: yes i have, gmane
[02:07] <iive> durandal_1707: that's full of committed patches, too hard to find the good one that were left out.
[02:08] <durandal_1707> iive: not really, just google for random feature missing in ffmpeg
[02:09] Action: iive googles "random feature"
[02:09] Action: durandal_1707 looool
[02:11] <Compn> hehe
[02:14] <durandal_1707> iive: cyuv encoder, rpza encoder, sanm decoder, mthp demuxer
[02:14] <michaelni> the heap corruption was IIRC fixed in 84fb4e9df737c856cca7767016110fc74bee56cb
[02:14] <michaelni> If someone knows of open bugs in libpostproc, please report them
[02:15] <michaelni> iam happy to fix them
[02:24] <Compn> michaelni : libav is going to move postproc out of tree
[02:24] <Compn> you going to keep it in tree ?
[02:24] <Compn> repo i mean
[02:26] <funman> move it on videolan.org ?
[02:27] <funman> it would stay not too far and on neutral lands
[02:27] <Compn> i dont actually know what Daemon404 is asking, if libav already made up its mind
[02:27] <Compn> they want michael to take it out of tree?
[02:27] <Compn> Daemon404 was not clear
[02:28] <Compn> i'll ask in #libav-devel
[02:28] <michaelni> ill try to do what is least painfull for its users and myself. Dunno yet what that is
[02:29] <Compn> alrighty
[02:29] <michaelni> It would be nice if there was just one libpostproc btw
[02:30] <Compn> yes, i'm guessing they just want you to move it , so its not forked
[02:30] <Compn> they can ignore it, and ffmpeg can use it as external
[02:30] <Compn> but this is only my guess
[02:30] <Compn> and its quiet in libav channel
[02:31] <Compn> probably should ask j-b and reimar before changing things
[02:31] <iive> i really don't get, what's the problem with libpostprocess remaining in ffmpeg.
[02:32] <Compn> did you read the thread on libav-devel ?
[02:33] <iive> i guess i've missed it.
[02:41] <funman> i've always wondered what it did
[02:42] <funman> enabling it in vlc always resulted in absolutely no visible changes to my eyes
[02:45] <j-b> funman: it is not like it was completly borken in 1.1 :)
[02:45] <j-b> and of course, no issue to host it
[02:47] <funman> still can't see the slightiest effect
[02:47] <durandal_1707> funman: you are using too high bitrate
[02:48] <funman> should i use shitty video to notice it?
[02:49] <durandal_1707> postproc helps with poor youtoube clips last time i watched poor youtube clips (last year or two)
[02:49] <durandal_1707> i think i also used 2xsai
[02:49] <iive> funman: that's the idea. to smooth a little these huge macroblocks.
[02:51] <funman> ah perhaps because i don't build postproc
[02:52] <funman> j-b: i didn't eat your placebo pill with that dummy postproc menu!
[02:53] <j-b> :)
[03:00] <Compn> [20:56] <Kovensky> Compn: Daemon404 ported it to build outside of the libav tree in https://github.com/dwbuiten/postproc
[03:00] <funman> hm i could ask which irc bot the mingw-w64 people use
[03:01] <funman> if you talk to it on freenode it repeats what you said on oftc and vice versa
[03:01] <Compn> lol
[03:01] <Compn> i've seen those irc relays
[03:01] <Compn> on a few diff channels/servers
[03:20] <durandal_1707> add 96bpp and 128bpp pixel format?
[03:21] <iive> durandal_1707: let's round it to 256
[03:22] <durandal_1707> iive: http://wiki.multimedia.cx/index.php?title=WDP
[03:26] <durandal_1707> 96bpp would be needed to support rgbe
[03:36] <CIA-108> ffmpeg: 03Ronald S. Bultje 07master * r59f474b49d 10ffmpeg/libavcodec/x86/ (Makefile pngdsp-init.c pngdsp.asm): png: convert DSP functions to yasm.
[03:36] <CIA-108> ffmpeg: 03Mans Rullgard 07master * r3715d841a6 10ffmpeg/ (avconv.c libavcodec/aacenc.c): 
[03:36] <CIA-108> ffmpeg: Fix non-C89 declarations in for loops
[03:36] <CIA-108> ffmpeg: Some compilers still do not support this syntax.
[03:36] <CIA-108> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[03:36] <CIA-108> ffmpeg: 03Ronald S. Bultje 07master * rf91c4b7824 10ffmpeg/libavcodec/x86/ (pngdsp-init.c pngdsp.asm): png: add SSE2 version for add_bytes_l2.
[03:36] <CIA-108> ffmpeg: 03Mike Melanson 07master * rcc09dc7863 10ffmpeg/libavformat/mpegtsenc.c: 
[03:36] <CIA-108> ffmpeg: s/vbsf/bsf/
[03:36] <CIA-108> ffmpeg: -vbsf doesn't exist anymore. It got renamed to -bsf somewhere along the
[03:36] <CIA-108> ffmpeg: line. Update print statement accordingly.
[03:36] <CIA-108> ffmpeg: Signed-off-by: Anton Khirnov <anton at khirnov.net>
[03:36] <CIA-108> ffmpeg: 03Mike Melanson 07master * rb864b38397 10ffmpeg/libavformat/yuv4mpeg.c: (log message trimmed)
[03:36] <CIA-108> ffmpeg: yuv4mpeg: allow YUV4MPEG2 demuxer to recognize 'C420' colorspace.
[03:36] <CIA-108> ffmpeg: Current demuxer recognizes several colorspace formats that begin with 'C420'
[03:36] <CIA-108> ffmpeg: but does not yet recognize plain 'C420'. GStreamer's y4menc component
[03:36] <CIA-108> ffmpeg: generates .y4m files with a 'C420' colorspace. This new comparison is
[03:36] <CIA-108> ffmpeg: placed after the other 'C420' checks so that it doesn't interfere with
[03:36] <CIA-108> ffmpeg: them.
[03:36] <CIA-108> ffmpeg: 03Rafaël Carré 07master * r420df8b7c4 10ffmpeg/libavformat/utils.c: 
[03:36] <CIA-108> ffmpeg: avformat_write_header(): detail error message
[03:36] <CIA-108> ffmpeg: Give the exact aspect ratios when there is a mismatch between encoder
[03:36] <CIA-108> ffmpeg: and muxer.
[03:36] <CIA-108> ffmpeg: Signed-off-by: Anton Khirnov <anton at khirnov.net>
[03:36] <CIA-108> ffmpeg: 03Diego Biurrun 07master * ra846202343 10ffmpeg/libavformat/rtsp.c: rtsp: Remove some unused variables from ff_rtsp_connect().
[03:36] <CIA-108> ffmpeg: 03Paul B Mahol 07master * r8b933129b9 10ffmpeg/ (doc/APIchanges libavutil/Makefile libavutil/avutil.h): 
[03:36] <CIA-108> ffmpeg: avutil: make intfloat api public
[03:36] <CIA-108> ffmpeg: The functions are already av_ prefixed and intfloat header is already provided.
[03:36] <CIA-108> ffmpeg: Install libavutil/intfloat.h
[03:36] <CIA-108> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[03:36] <CIA-108> ffmpeg: Signed-off-by: Anton Khirnov <anton at khirnov.net>
[03:36] <CIA-108> (82 lines omitted)
[04:17] <NapHtaKeRoSene> hii
[04:17] <NapHtaKeRoSene> what do you use for BSR BSF in C ?
[05:18] <michaelni> NapHtaKeRoSene, in ffmpeg you can use av_log2() for one direction
[05:19] <michaelni> there are no portable standard functions to do this, gcc has buildins though
[05:21] <funman> propose them for next C standard! oh wait you need to wait ten years now
[05:22] <canbal> Hi, is there anyone who can answer a few questions of mine about CABAC? Thanks...
[06:11] <bizzybody> Does this project still need the iFinish transcoder to implement support for that codec?
[06:11] <Compn> bizzybody : we need samples of a lot of things
[06:11] <Compn> which one was ifinish?
[06:11] Action: Compn looks
[06:11] <bizzybody> Media 100
[06:12] <Compn> yeah, i dont think we have samples for that
[06:12] <Compn> sample video with that codec
[06:12] <Compn> any weird codecs we dont support, we need samples for :)
[06:13] <bizzybody> I wonder if there's something useful on the tutorial disc with the Media 100 2.6.1 software?
[06:13] <Compn> possibly, but usually they have raw sample videos, not encoded sample videos
[06:13] <bizzybody> I do have the transcoder for Windows, which does support realtime playback in spite of what Media 100 claimed on their website.
[06:15] <Compn> i dont know what kind of codec it is really
[06:15] <Compn> i just picked some random ones we didnt have samples for
[06:16] <Compn> anyways, upload some samples if you can, to our bug tracker or any file host
[06:16] Action: Compn goes afk
[06:19] <bizzybody> OK, copying stuff off tutorial CD with TransMac, probably have to flatten the MOV files.
[07:08] <bizzybody> I've a 2.2 meg rar file with a couple of small MOV videos, their resource forks, the iFinish transcoder for windows and a little flattener utility. Where do you need it uploaded?
[07:17] <bizzybody> I've uploaded the Media 100 stuff to http://partsbyemc.com/pub/ Hopefully you can use that to add support to FFMPEG
[11:23] <ubitux> michaelni: we have two presets directories: ffpresets/ and presets/ (i guess because of 8096fdf0b6886305ea1a8cb2c869ab2732cd8e11); should we move all the ffpresets to the new presets directory?
[13:51] <ubitux> what's the gain of having do_avconv_crc in addition of do_avconv?
[13:52] <ubitux> do_avconv seems to run a md5 while do_avconv_crc seems to be the same with crc; but is it really summing the same thing?
[17:42] <durandal_1707> michaelni: how to test unscaled conversion stuff with ffplay/ffmpeg?
[17:43] <durandal_1707> i'm asking because unscaled yuv2rgb in case of yuva444p is never going to be called
[17:44] <durandal_1707> and i can't get message "using unscaled %s -> %s special converter"
[17:45] <CIA-108> ffmpeg: 03Clément BSsch 07master * rc673671333 10ffmpeg/ffmpeg.c: ffmpeg: fix -map_channel being ignored when resampling is not needed.
[18:18] <michaelni> durandal_1707, i thought it would be used by default when possible
[18:18] <durandal11707> michaelni: what?
[18:18] <michaelni> youd have to add a av_log or 2 to find out why not
[18:22] <michaelni> durandal_1707, rereading what you wrote and thinking, i dont think 444 is supported in the yuv->rgb unscaled code
[18:25] <durandal11707> michaelni: of course it is not (only yuva420p is checked in code), but cant get msg even with yuva420p too
[18:43] <j-b> http://git.videolan.org/?p=ffmpeg.git;a=summary has switched HTTP server engine.
[18:51] <durandal_1707> what "get_buffer() cannot be called after ff_thread_finish_setup()" means?
[19:11] <beastd> hi
[19:16] <ubitux> hi beastd :)
[19:21] Action: beastd goes AFK now
[19:21] <beastd> bbl
[20:04] <ubitux> :)
[22:00] <CIA-108> ffmpeg: 03Michael Niedermayer 07master * r146ef3f37c 10ffmpeg/libavcodec/pngdec.c: 
[22:00] <CIA-108> ffmpeg: pngdec: fix warning about pointer types
[22:00] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:00] <CIA-108> ffmpeg: 03Michael Niedermayer 07master * re4a714f65a 10ffmpeg/libavcodec/h264.c: 
[22:00] <CIA-108> ffmpeg: h264: Return the correct number of bytes for mid strea, extradata.
[22:00] <CIA-108> ffmpeg: Fixes the hang with Ticket952
[22:00] <CIA-108> ffmpeg: Tested-by: Nicolas George <nicolas.george at normalesup.org>
[22:00] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:00] <CIA-108> ffmpeg: 03Michael Niedermayer 07master * r05ebe51e00 10ffmpeg/libavcodec/ (h264.c mpegvideo.c): 
[22:00] <CIA-108> ffmpeg: mpeg/h264: update thread context even if it is not initialized.
[22:00] <CIA-108> ffmpeg: Fixes decoding of Ticket952
[22:00] <CIA-108> ffmpeg: Tested-by: Nicolas George <nicolas.george at normalesup.org>
[22:00] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:01] <CIA-108> ffmpeg: 03Paul B Mahol 07master * rb0a30ea7c8 10ffmpeg/libavcodec/ffv1.c: 
[22:01] <CIA-108> ffmpeg: ffv1enc: PIX_FMT_YUVA444P support
[22:01] <CIA-108> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[22:01] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:01] <CIA-108> ffmpeg: 03Paul B Mahol 07master * r7054629f04 10ffmpeg/libavcodec/ffv1.c: 
[22:01] <CIA-108> ffmpeg: ffv1enc: PIX_FMT_YUVA420P support
[22:01] <CIA-108> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[22:01] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:01] <CIA-108> ffmpeg: 03Paul B Mahol 07master * rc8eba9f9d5 10ffmpeg/libavcodec/ffv1.c: 
[22:01] <CIA-108> ffmpeg: ffv1dec: PIX_FMT_YUVA444P support
[22:01] <CIA-108> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[22:01] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:01] <CIA-108> ffmpeg: 03Paul B Mahol 07master * rab7da16ea4 10ffmpeg/libavcodec/ffv1.c: 
[22:01] <CIA-108> ffmpeg: ffv1dec: PIX_FMT_YUVA420P support
[22:01] <CIA-108> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[22:01] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:21] <CIA-108> ffmpeg: 03Mashiat Sarker Shakkhar 07master * r6ca1016b3a 10ffmpeg/libavcodec/wmalosslessdec.c: Use correct variable type for 32-bit samples buffer
[23:21] <CIA-108> ffmpeg: 03Mashiat Sarker Shakkhar 07master * rbfbd22f9f0 10ffmpeg/libavcodec/wmalosslessdec.c: Cosmetics: Fix some whitespace errors and indentation
[23:22] <CIA-108> ffmpeg: 03Michael Niedermayer 07master * r0d17477e2c 10ffmpeg/: 
[23:22] <CIA-108> ffmpeg: Merge remote-tracking branch 'shariman/wmall'
[23:22] <CIA-108> ffmpeg: * shariman/wmall:
[23:22] <CIA-108> ffmpeg:  Cosmetics: Fix some whitespace errors and indentation
[23:22] <CIA-108> ffmpeg:  Use correct variable type for 32-bit samples buffer
[23:22] <CIA-108> ffmpeg: Merged-by: Michael Niedermayer <michaelni at gmx.at>
[23:40] <CIA-108> ffmpeg: 03Paul B Mahol 07master * r0a3a69e8d7 10ffmpeg/libavcodec/ffv1.c: 
[23:40] <CIA-108> ffmpeg: ffv1dec: use correct linesize
[23:40] <CIA-108> ffmpeg: Apparently this did not break anything.
[23:40] <CIA-108> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[23:40] <CIA-108> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:57] <durandal_1707> michaelni: h264 decoder support both frame and slice threads - can they be used at same time?
[23:57] <durandal_1707> michaelni: could ffv1 benefit from frame threads?
[23:59] <kierank> no they can't be used at the same time afaik
[00:00] --- Wed Feb  1 2012