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

[burek]

[00:16] <Daemon404> this damn unicode problem is driving me nuts
[00:16] <Daemon404> :<
[00:16] <ohsix> what is it
[00:17] <Daemon404> ohsix, somewhere in our codebase, where we assume utf8
[00:17] <Daemon404> windows is using utf16
[00:17] <Daemon404> i merely dont know where.
[00:17] <Daemon404> its somewhere where we read metadata
[00:18] <ohsix> ahh
[00:18] <ohsix> hack the string routines to include a type marker at (*)str-1 :D
[00:18] <ohsix> or some other sort of taint
[00:19] <ohsix> this is with msvcrt right?
[00:19] <ohsix> stuff houldn't be promoted to utf16 or whatever if you don't use _wcs versions of stuff
[00:19] <Daemon404> ohsix, msvc-specific
[00:19] <Daemon404> mingw doesnt suffer from it.. but it probably has its own func
[00:20] <ohsix> it's going to be in the c runtime tho
[00:21] <Daemon404> we use a _vcs function
[00:21] <Daemon404> no _wvs
[00:21] <Daemon404> er, _wcs
[00:21] <Daemon404> afaik
[00:21] <Daemon404> grep says none
[00:22] <ohsix> http://msdn.microsoft.com/en-us/library/78zh94ax%28v=vs.80%29.aspx under remarks show what the different junk does
[00:22] <ohsix> that they call it "UNICODE" in windows when it's just one encoding is and has been dumb, but so are TCHAR's and all the other shit
[00:23] <Daemon404> i hate unicode on windows
[00:23] <Daemon404> i always have
[00:23] <Daemon404> especially filenames
[00:24] <ohsix> yea, it sucks, stuff like rsync sucks for it
[00:25] <ohsix> basically means file io and stuff need windows specific versions, and wrappers
[15:52] <burek> gstreamer apparently implemented a way to configure logitech c920 webcam (with internal h264 encoder) and to receive a h264 stream directly from the webcam :) now, i need to figure out how to use gstreamer to test that.. it would be a cool thing though if ffmpeg could implement such thing too one day
[15:56] <burek> if someone is interested though: http://kakaroto.homelinux.net/2012/09/uvc-h264-encoding-cameras-support-in-gstreamer/
[15:57] <ubitux> kakaroto mmh, it's the guy from amsn; didn't someone send a patch for a decoder using his lib?
[15:57] <ubitux> Peter maybe
[18:06] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * rbad953bc2d 10ffmpeg/ffmpeg_opt.c: 
[18:06] <CIA-56> ffmpeg: ffmpeg: fix overriding codecs with the new syntax
[18:06] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:11] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r3db4c88ac1 10ffmpeg/ffmpeg_opt.c: 
[19:11] <CIA-56> ffmpeg: ffmpeg/opt_preset: update to new option API for reading codec names.
[19:11] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:11] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r8ccb56abee 10ffmpeg/ffmpeg_opt.c: 
[19:11] <CIA-56> ffmpeg: ffmpeg/opt_output_file: extract subtitle codec name through new API
[19:11] <CIA-56> ffmpeg: This should fix specifying subtitle codecs with the new syntax in some cases.
[19:11] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:12] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * ra4271f3d4e 10ffmpeg/ffmpeg_opt.c: 
[19:12] <CIA-56> ffmpeg: ffmpeg: dont match unspecified media types in MATCH_PER_TYPE_OPT
[19:12] <CIA-56> ffmpeg: This would change existing behavior, and should if done, done seperately.
[19:12] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:12] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * r374033ee93 10ffmpeg/ffmpeg_opt.c: 
[19:12] <CIA-56> ffmpeg: ffmpeg: remove now unneeded old *_codec_name code
[19:12] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:54] <Daemon404> burek, stop telling people to remove system packages
[21:54] <Daemon404> its a fucking bad idea
[21:55] <burek> let them blame their packagers
[21:55] <burek> who introduced all that shit
[21:55] <Daemon404> politics isnt a reason to tell people to break their systems
[21:55] <Daemon404> grow up.
[21:55] <burek> why would they break?
[21:56] <ubitux> because of what JEEB said
[21:56] <ubitux> apps dependencies
[21:56] <Daemon404> if you remove deps and replace them with your own versions
[21:56] <Daemon404> its one giant crapshoot
[21:56] <ubitux> burek: really, writing a page redirecting the different solutions is IMO the best thing to do
[21:58] <JEEB> burek, since you think I'm so darn biased I just had to get someone with commit rights to the ffmpeg repo to herp a derp at you :P
[21:58] <ubitux> basically: 1) quick start: try s/ffmpeg/avconv/ 2) not working, try the static build || build it yourself 3) see deb-multimedia/ppa 4) complains to the distro packagers or the fork
[21:58] <Daemon404> ubitux, all of those i can live with
[21:58] <Daemon404> telling people to purge packages i cannot.
[21:59] <burek> ok, i made a mistake
[21:59] <ubitux> sure
[21:59] <burek> ill just shut up and thats it
[21:59] <ubitux> i was proposing a template for the page
[21:59] <ubitux> burek: you could try writing that page if you care for the users, i'm willing to review it
[22:00] <ubitux> if you don't i'll just do it, but you know better the needs of the users than me
[22:00] <ubitux> and i must admit i have some more interesting stuff to do :)
[22:01] Action: Daemon404 goes to stab swscale some more
[22:01] <ubitux> it's not called stabbing Daemon404 
[22:01] <ubitux> it's called cooking!
[22:01] <ubitux> please call things by their names
[22:01] <Daemon404> ubitux, i dont want to call it cooking
[22:01] <ubitux> :(
[22:01] <Daemon404> ill get arrested for runnign a meth lab
[22:02] <Daemon404> swscale code is veyr similar to meth
[22:02] <Daemon404> under the law
[22:02] <ubitux> :)
[22:03] <Daemon404> btw -enable-small is exploding i think
[22:03] <Daemon404> last i checked
[22:03] <ubitux> that's not what fate says
[22:03] <Daemon404> maybe it got fixed
[22:03] <Daemon404> also:
[22:03] <Daemon404> read swscale code when suddenly:
[22:03] <Daemon404>         case PIX_FMT_RGB32_1:
[22:03] <Daemon404>         case PIX_FMT_BGR32_1:
[22:03] <Daemon404> double case statement
[22:04] <Daemon404> owait im just dyslexic
[22:04] <Daemon404> move along.
[22:04] <ubitux> :)
[22:04] <Daemon404> i wonder what the _1 is though
[22:05] <ubitux> looks like about alpha
[22:06] <Daemon404> RGB32 has alpha anyway
[22:06] <ubitux> yes but not at the same position
[22:06] <ubitux> afaict.
[22:06] <ubitux> #define PIX_FMT_RGB32   PIX_FMT_NE(ARGB, BGRA)
[22:06] <Daemon404> its a stupid way of saying ARGB i guess
[22:06] <ubitux> #define PIX_FMT_RGB32_1 PIX_FMT_NE(RGBA, ABGR)
[22:07] Action: Daemon404 tries to discern what the difference between yuv2rgb24_1_c & yuv2rgb24_2_c & yuv2rgb24_X_c is
[22:13] <CIA-56> ffmpeg: 03Michael Niedermayer 07master * reb949544ca 10ffmpeg/ffmpeg_opt.c: 
[22:13] <CIA-56> ffmpeg: ffmpeg: fix 10l (use of uninitilaized variable)
[22:13] <CIA-56> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:15] <michaelni> Daemon404, ARGB means A,R,G,B bytes in that order in memory, RGB32 refers to the order if read by a native endian 32bit read
[22:16] <Daemon404> i see that from his paste
[22:16] <michaelni> the 1 /2 /X is about scaling (unscaled, bilnear with 2 taps and X taps)
[22:17] <Daemon404> i can see
[22:17] <michaelni> that is mostly, theres some exception for chroma somewhere in the "1" case 
[22:17] <Daemon404> i killed all my motivation though to fix up that patch now
[22:17] <Daemon404> it looks super annoying to implement yuv->gbr
[22:17] <Daemon404> p
[22:17] <Daemon404> and i dont even want it
[22:18] <Daemon404> [16:17] <@BBB> if you want something simpler, implement it without the macros
[22:18] <Daemon404> [16:18] <@BBB> just write a custom yuv2gbrp_X_c
[22:18] <Daemon404> ^ unless youre ok with that
[22:18] <Daemon404> [16:18] <@BBB> that doesn't use the macros
[22:18] <Daemon404> [16:18] <@BBB> done
[22:34] <michaelni> iam not sure what macros you would want to use ...
[22:35] <Daemon404> there's some template macros for yuv2rgb
[22:35] <Daemon404> but theyre not feasible to use for planar rgb
[22:35] <michaelni> yes so why do you want to use them ?
[22:36] <michaelni> when we have 7 yuv->planar rgb functions we can factorize them with macors
[22:36] <Daemon404> yeah well im shit outta luck
[22:36] <Daemon404> i see what i have to do
[22:44] <Daemon404> ^ probably my fault
[22:49] <ubitux> and you have no shame?!
[22:49] <Daemon404> ofc not
[22:49] <ubitux> :(
[22:51] <ubitux> btw, anyone to review the faststart option patchset in lavf/movenc, the webvtt, or ebur128?
[22:51] <ubitux> i'm gonna push webvtt tomorrow so...
[22:51] <Daemon404> im not touching that abominationg with a 10-foot pole
[22:51] <ubitux> and i'd like to have fastsart for next week if possible
[22:51] <Daemon404> webvtt being said abomination
[22:51] <ubitux> :)
[22:51] <ubitux> i didn't do a muxer & encoder
[22:52] <ubitux> i'm just allowing users to purify their webvtt files into something saner
[23:08] <ubitux> so libav is working on rewriting swscale? erm.
[23:08] <Daemon404> i dont think you are aware how much people hate swscale
[23:08] <Daemon404> users and devs alike
[23:08] <ubitux> i had to use it a while ago, it was kinda nice
[23:09] <ubitux> and if by devs you means the libav folks, oh yeah i'm aware of it.
[23:09] <Daemon404> no
[23:09] <Daemon404> take a look in that rizon channel
[23:09] <ubitux> trizom channel
[23:10] <ubitux> Daemon404: it's always easy to find trolls :)
[23:10] <Daemon404> i persoanlly hate it too
[23:10] <ubitux> and you think that's a reason valid enough to rewrite it?
[23:10] <Daemon404> its code is horrible.
[23:11] <Daemon404> look how much trouble im having just doing this
[23:11] <ubitux> you should read http://www.joelonsoftware.com/articles/fog0000000069.html when you have some time
[23:11] <Daemon404> giant mess of macros and inline asm and i think it even has runtime generated code
[23:11] <ubitux> take it like a game
[23:11] <Daemon404> no
[23:11] <Daemon404> fuck you.
[23:11] <ubitux> :))
[23:11] <Daemon404> rewriting, on occasional, is COMPLETELY necessary
[23:12] <Daemon404> libavresampel wasnt
[23:12] <Daemon404> this is
[23:12] <ubitux> libavr was written exactly for the same reason
[23:12] <ubitux> "we don't like existing code from michael"
[23:12] <Daemon404> no it wasnt
[23:12] <Daemon404> its not even in the same ballpark as swscale
[23:13] <ubitux> i think it is, and i'd say it would be even worse with sws
[23:13] <ubitux> because the code is even more mature
[23:13] <Daemon404> lets just agree to disagree
[23:13] <Daemon404> i will burn effigies of swscale in my spare time. it doesnt harm anyone.
[23:14] <ubitux> it will harm users to port their code to a different api, with a more buggy code, with less features
[23:14] <ubitux> and yes, it might be more beautiful, for a while.
[23:14] <Daemon404> ive heard these same arguments before
[23:14] <Daemon404> same oens for saving postproc
[23:15] <Daemon404> which is a heaping pile of shit
[23:15] <ubitux> oh so you are aware you are wrong then ;)
[23:15] <ubitux> pp is a different story
[23:15] <ubitux> the debate was about trashing it completely and replace it with nothing
[23:15] <Daemon404> it has no value.
[23:15] <Daemon404> theres nothing to replace.
[23:15] <Daemon404> no useful functionalit.y
[23:16] <ubitux> whatever, the point is, it's not the same situation as sws
[23:16] <Daemon404> lets put it this way:
[23:16] <Daemon404> currently, we use ffmpeg at work, and im an adament abotu keeping ffmpeg usage
[23:16] <Daemon404> but if libav were to get libavscale as a replacement, and ffmepg didnt adopt it
[23:16] <Daemon404> i would switch
[23:17] Action: ubitux wonders if libav isn't rewritting it just to change the "sw" prefix into something more consistent
[23:17] <ubitux> the sws api usage is kind of nice impo
[23:18] <ubitux> -p
[23:18] <Daemon404> its api may be nice
[23:18] <Daemon404> but how it works internally is fucking horrible
[23:18] <ubitux> if it works well and is widely used, then it is beautiful
[23:18] <Daemon404> thats a load of shit
[23:19] <ubitux> your intestines are full or crap, still they work well and you don't want to replace them :x
[23:19] <Daemon404> and thats not even a valid analogy
[23:20] <ubitux> please don't thank me for this great comparison
[23:20] <Daemon404> the point of that system is to expell waste
[23:20] <ubitux> anyway, you'll introduce new bugs by rewriting it
[23:20] <ubitux> you'll likely do the same mistake as sws soon or later
[23:20] <ubitux> and you'll have a long road until it is mature enough to be a replacement
[23:21] <ubitux> and when that happens, it will be as crappy as sws now
[23:21] <ubitux> (the same mistakes, ’ and obvious more)
[23:21] <ubitux> +ly
[23:21] <Daemon404> you sound like someone who believs in creationism over darwinism
[23:22] <michaelni> its no big problem to cleanup sws properly ...
[23:22] <ubitux> i'd like to believe i sound like an engineer and not a whining kid not happy with something he doesn't understand :p
[23:22] <Daemon404> you sound liek someone i wouldnt hire
[23:23] <Daemon404> unless i was maintaining an ie6 activex control
[23:23] <michaelni> the macros you disliked are btw libavs cleanup they wherent there originally unless iam misremembering
[23:23] <ubitux> fortunately i don't want to work for your american company :))
[23:23] <Daemon404> michaelni, its design is somewhat crazy
[23:24] <Daemon404> there is no way to support anything without a yuv path, or to signal what patsh are supported
[23:24] <Daemon404> just generally "supported input"
[23:24] <Daemon404> or output
[23:24] <Daemon404> filenames are non-useful
[23:24] <Daemon404> the macro+asm is madness
[23:24] <michaelni> it was libav who put a random pile of code in "swscale_unscaled.c" ...
[23:25] <michaelni> that is code quite unrelated to "unscaled"
[23:25] <Daemon404> input.c and output.c come to mind
[23:25] <michaelni> they are libav cleanup
[23:25] <michaelni> neither input nor output.c existed before
[23:25] <Daemon404> still better than a giant file i guess
[23:26] <michaelni> better if you walk up the wrong mountain still is not very good
[23:27] <michaelni> and i can assure you i hate the macros as much as you
[23:27] <Daemon404> for example
[23:27] <Daemon404> i tried to make it simply say yuv->gbrp was unsupported
[23:27] <Daemon404> and it doesnt seem very possible without changing a bucnh of thigns
[23:29] <michaelni> assume you could mark a specific case as unsupported ... i dont think this would be very pleasant to use
[23:29] <Daemon404> or if i want to add yub->gbrp, i need to add a new type SwsContext
[23:29] <michaelni> nor could libavfilter handle it very well if random convertions would fail
[23:29] <Daemon404> since yuv2packed and yuv2planar both arent feasible
[23:30] <Daemon404> and add it to some massive-ass checking function
[23:30] <Daemon404> and so forth
[23:31] <michaelni> so lets refactor the code one step at a time properly
[23:33] <Daemon404> i wouldnt even know where to start
[23:33] <Daemon404> its all so intertwined
[23:33] <Compnn> Daemon404 : michaelni can show you the way! :)
[23:34] <Compnn> i agree with ubitux. i'm guessing ~2 year job to rewrite swscale. :P
[23:35] <Compnn> and it will be 50% slower :P
[23:35] Action: Compnn trolls now
[23:35] <ubitux> it's always simpler to write code than read it
[23:35] <ubitux> the dark side is always more tempting
[23:38] <michaelni> Daemon404, what would you prefer instead of for example these yuv2rgbpacked template macros ? 
[23:39] <michaelni> i mean how should in your oppinion the planar yuv -> packed rgb case be done if you started from scratch
[23:39] <Daemon404> the template macros dont bother me as much as the tempates thesemlves
[23:39] <michaelni> please explain
[23:40] <Daemon404> the colorspace conversion and packing are too coupled
[23:40] <Daemon404> im sure its in the name of speed
[23:40] <Daemon404> but it makes it very rigid
[23:41] <Compnn> i wonder if there are any examples of colorspace conversion libs that you do like to look at ? not trolling, i just havent seen gimp's or imagemagicks etc
[23:41] <Daemon404> swscale really is teh de-facto standard
[23:41] <michaelni> its actually quite easy to seperate the yuv/rgb stuff out if you wanted
[23:42] <Daemon404> i wont mention avisynth's colorspace conversions
[23:42] <Compnn> wonder what vdub uses
[23:42] <michaelni> I mean its just a matter of doing the rgb/yuv in the internal buffer
[23:42] <Daemon404> vdub has its own internal ones
[23:43] <Daemon404> michaelni, if that was the case, then e.g. grbp could simply have its colorspace converted
[23:43] <Daemon404> instead of doing it in this roundabout away
[23:43] <Daemon404> it really looks liek swscale was designed to think only packed rgb exists
[23:45] <Compnn> Daemon404 : maybe if you showed michael what you want to convert, he could find the simple solution to fix it :P
[23:46] Action: Compnn asks dumb questions
[23:46] <Daemon404> i sent a patch for what i wanted to convert last night
[23:46] <ohsix> gegl FTW !!!11;]
[23:46] <ohsix> there are a few pixel pull libraries that are cute
[23:46] <ohsix> slow, but neat
[23:46] <Daemon404> ohsix, did gimp finally switch to gegl?
[23:47] <Daemon404> i remember they said they 'couldnt'
[23:47] <ohsix> i don't know, they've had partial gegl filters and stuff in there for a very long time
[23:48] <ohsix> i just like the idea that the filter stack is only resolved if the pixels are used, probably not a useful model if you touch them all :D
[23:48] <Daemon404> oh well
[23:48] <Daemon404> not like id ever willingly use gimp
[23:48] Action: Daemon404 is very attached to photoshop
[23:48] <michaelni> its very very long since i used photoshop
[23:49] <michaelni> but i also found it more easy to use / intuitiv than gimp 
[23:49] <ubitux> gimp switched to the single window mode users were always complaining about
[23:49] <ubitux> and last time i saw a video with photoshop, it was a floating windows system, just like gimp
[23:50] <ubitux> i found that quite funny
[23:50] <Daemon404> gimp lacks many basic features
[23:50] <Daemon404> liek layerstyles that dont need rasterization
[23:50] <Daemon404> nad not using guile
[23:51] <ohsix> hur, i tried to explain that to someone like 8 years ago, it wasn't gimp and photoshop though
[23:51] <ohsix> and procedural layers was the big thing
[23:51] <ohsix> or parametric, i forget
[23:52] <Daemon404> i use a lot of adobe products a lot, im sad to say
[23:52] <Daemon404> theyre actually quite good
[23:52] <ohsix> it didn't really matter, i just wanted to explain in one of the ways paint shop pro sucked
[23:52] <Daemon404> lol paint shop pro
[23:52] <Compnn> burek : btw, instead of ffmpeg writing the same wheel to access the h264 camera, why not just make a gstreamer input to ffmpeg ? then we can use whatever features they get :P
[23:52] <Daemon404> i had to open an old .psp file a while back
[23:53] <ohsix> i've not wanted for much that gimp didn't have, though the gpu acceleration in new photoshop stuff makes navigation super awesome
[23:53] <Daemon404> it was a massive pain
[23:53] Action: ubitux used paint shop pro a lot a loooong time ago
[23:53] <ubitux> psp7!
[23:53] <Daemon404> yes so did i
[23:53] <ubitux> with animation shop for doing .gif!
[23:53] <Daemon404> nowadays i use photoshop and after effects a lot
[23:54] <Daemon404> the latter of which i coudlnt live without
[23:54] <ubitux> i stopped using windows around 10 yrs ago so since then...
[23:54] <Daemon404> i use every os
[23:54] <Daemon404> stop the hate!
[23:54] <Daemon404> etc
[23:56] <ubitux> where do you see hate?
[23:56] <Daemon404> not right now
[23:56] <Daemon404> but in general i see a lot of (unjustified) MS hae
[23:56] <Daemon404> hate*
[23:56] <ohsix> windows 8
[23:57] <ubitux> looks like ohsix wants to start a war
[23:57] <ohsix> i haven't seen "hate" ever, just irrational rambling and people sabotaging themselves
[23:57] <ohsix> like fanboy
[23:57] <ohsix> sss
[23:58] <Daemon404> ohsix, i had someone come close to punching me once
[23:58] <Daemon404> over FREEDOM
[23:58] <ubitux> welcome to the usa
[23:58] <Daemon404> FREEDOM as in FSF "freedom"
[00:00] --- Sun Sep 23 2012