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

[burek]

[01:23:21 CET] Action: michaelni gets a new kind of IRC spam: http://pastebin.com/yGkwmf1g
[01:25:27 CET] <BtbN> I have disabled incoming queries entirely because of way too much spam
[01:25:50 CET] <nevcairiel> i dont get s uch spam at all on freenode
[01:26:00 CET] <nevcairiel> but i'm not in big public channels
[01:26:12 CET] <BtbN> I'm in way too many channels I guess
[01:30:14 CET] <michaelni> i get very little spam via IRC (Freenode/OFTC/GIMPNet) i maybe on the order of one per week or so
[01:32:43 CET] <kierank> I get even less
[01:32:49 CET] <kierank> usually highlight spam
[01:35:55 CET] <BtbN> Looking through my ZNC logs, it blocked 23 incoming queries in the last 14 days, and on a quick look, only 2 of them are not spam.
[02:02:35 CET] <atomnuker> dirac has some really primitive quantization which can make some cool effects: https://0x0.st/owK.jpg
[02:03:01 CET] <atomnuker> all it does is it divides the coefficients for every slice by a value which gets transmitted beforehand
[02:03:25 CET] <atomnuker> then it just golomb encodes in to the bitstream
[02:04:55 CET] <atomnuker> I don't think I actually mentioned I have a working Dirac HQ encoder in libavcodec
[02:06:11 CET] <atomnuker> the cool thing is you can have separate quantization values per slice
[02:06:50 CET] <atomnuker> so you can just scan the highest level HH orientation and decide what quantizer to use based on the total energy in that block/slice
[02:07:40 CET] <atomnuker> though if it's completely empty and the image is soft you'd have to go down to a lower HH level to pick out details
[02:32:39 CET] <atomnuker> though the default quantization matrix defined by the standard gets it wrong and allocates too many bits for the higher levels IMO
[02:34:07 CET] <atomnuker> thankfully the format does allow you to transmit a custom quantization matrix to define per level per orientation quantization (the slice quantization level just tweaks the values in the matrix)
[04:49:11 CET] <BBB> atomnuker: omg the banding is real :D
[06:13:01 CET] <cone-870> ffmpeg 03James Almer 07master:35b0c7efda52: x86/vf_stereo3d: remove a few unnecessary movas
[06:33:32 CET] <prelude2004c> hey guys. having trouble with vdpau... someone told me to decode using " vc ffh264vdpau   " . not sure where to put that.. i am using ffmpeg
[06:33:53 CET] <prelude2004c> mpeg2video sources seem to decode ok and then i can transcode it to something else.. but h264 sources don't seem to decode at all
[06:33:59 CET] <prelude2004c> i am using M4000 card
[06:34:07 CET] <prelude2004c> running latest 258.16 version
[07:33:58 CET] <prelude2004c> anyone ?
[09:35:29 CET] <j-b> 'morning
[10:19:11 CET] <ubitux> https://fgiesen.wordpress.com/2016/01/02/end-of-buffer-checks-in-decompressors/
[12:20:23 CET] <Franciman> Hi
[12:21:40 CET] <Franciman> Does the AVPacket used for flushing in audio decoding need to be initiated with av_init_packet
[12:21:58 CET] <Franciman> or is it enough to just set packet.data = NULL; and packet.size = 0; ?
[12:24:18 CET] <nevcairiel> you should always init a packet
[12:24:44 CET] <Franciman> ok, thank you
[12:53:49 CET] <ubitux> so, if i understand well, closed captions and teletext can typically output multiple subtitles for 1 packet 
[12:54:16 CET] <ubitux> question is: will they always have the same ts and duration?
[12:54:36 CET] <ubitux> or do we need to have some time offseting mechanism in the rectangle itself?
[12:56:22 CET] <ubitux> at least for ccaption it seems the pts is constant (no idea why it's passed all around for no apparent reason)
[12:57:01 CET] <ubitux> i'm interested in random ccaption samples if anyone has some btw
[13:08:06 CET] <ubitux> tmm1: lol indeed wtf is this pktbuf
[13:11:22 CET] <wm4> ubitux: if they need different timing for different parts of the rectangle, you can just use the minimum duration of all rectangles for the whole AVSubtitle
[13:11:34 CET] <wm4> instead of introducing per-rectangle durations (which would be very fucked up)
[13:16:34 CET] <wm4> actually that's what happens with PGS too (I'm not sure though if PGS can actually time separate rectangles independently)
[13:37:58 CET] <Compn> ubitux : https://trac.ffmpeg.org/ticket/2933 
[13:38:30 CET] <Compn> ubitux : https://trac.ffmpeg.org/ticket/3172
[13:39:35 CET] <Compn> ehe
[13:40:32 CET] <wm4>  "They're essentially just base64'ing the raw cc608/cc708 data wrapped in some transport stream-type packets."
[13:40:35 CET] <wm4> holy fuck what
[13:41:26 CET] <Compn> ubitux : or if you want to make a demuxer for mxf smpte captions, https://trac.ffmpeg.org/ticket/726
[13:41:40 CET] <Compn> wm4 : its flv, they can do whatever they want :P
[13:41:57 CET] <wm4> Compn: we're talking about proper closed captions, not ridiculous non-stabdard hacks employed by a single streaming site
[13:42:02 CET] <Compn> oh bah :P
[13:42:23 CET] <wm4> standard even (though stab-art would fit too)
[13:44:48 CET] <Compn> we have a lot of samples of cc in odd formats, wtv for example, https://trac.ffmpeg.org/ticket/1482
[13:49:29 CET] <Compn> youtube has an interesting page on closed captions
[13:49:30 CET] <Compn> https://support.google.com/youtube/answer/2734698?hl=en
[13:50:01 CET] <Compn> says they support all of these external cc formats .scc .stl .tds .cin .asc .cap 
[13:50:12 CET] <wm4> and how is that related to anything
[13:50:22 CET] <Compn> ubitux : can use kierank's google filesearch util to grab those filetypes ?
[13:51:11 CET] <Compn> we also have .scc in trac
[13:51:19 CET] <Compn> dont remember seeing the rest of those though
[13:51:41 CET] <Compn> wm4 : you are too quick for me this morning :)
[13:53:06 CET] <Compn> heres that google filesearch util https://github.com/subho007/python-downloader
[13:53:17 CET] <Compn> it does bing too 
[13:54:12 CET] <Compn> guess i should install that and add to our sample repo...
[13:54:54 CET] <JEEB> hmm, I like how people generally don't tend to first read stuff into a buffer, and then parse that
[13:55:21 CET] <JEEB> makes looking at possible file formats simpler when you can see exactly what kind of reads are being made to which offsets
[13:56:41 CET] <Compn> instead of probing the first xx kb of a file and then parsing, they do little offsets first... yes that would make reverse engineering easier 
[13:57:04 CET] <JEEB> yup
[13:57:26 CET] <Compn> should put that into a howto RE guide :P
[13:57:39 CET] Action: Compn runs before wm4 calls it "utterly obvious"
[13:58:08 CET] <JEEB> yeah, I kind of decided to look at my issue with this DRM thing from another side
[13:58:24 CET] <JEEB> esp. since I somehow got around its  rootkit and got the license files
[13:58:36 CET] <Compn> what drm format ?
[13:58:42 CET] <JEEB> cypherguard for movie
[13:58:49 CET] <JEEB> used by some Japanese vendors
[13:58:51 CET] <Compn> oh, not wmv then
[13:58:55 CET] <Compn> something new, i see.
[13:58:59 CET] <JEEB> it can be whatever
[13:59:14 CET] <JEEB> it's basically a crypted file and they use Media Foundation through WMP.dll
[13:59:23 CET] <JEEB> in their crappy, crappy player
[13:59:29 CET] <Compn> haha
[13:59:33 CET] <JEEB> while their rootkit burns your machine alive
[13:59:48 CET] <Compn> thats why drm fails, the rootkits and crappy player annoys some hacker into breaking it :D
[14:00:04 CET] <Compn> if only they gave you a good player, it wouldnt offend so many people :P
[14:00:28 CET] <JEEB> also I'm pretty sure this shit is worse than the DVD
[14:00:32 CET] <JEEB> which has much less DRM in it
[14:01:38 CET] <JEEB> now I just have to find the spots where it touches these license files in the binaries I dumped (because of course they used off-the-shelf obfuscation)
[14:01:49 CET] <JEEB> (asprotect)
[14:04:07 CET] <durandal_1707> what it does?
[14:04:44 CET] <Compn> rot13 obfuscation! :P
[14:06:19 CET] <JEEB> nah, it does employ some things that require script to get around
[14:06:25 CET] <JEEB> (or dumping the binaries from memory)
[14:06:36 CET] <JEEB> *scripting
[15:54:42 CET] <cone-807> ffmpeg 03Nicolas George 07master:962727acb4e3: lavfi/vf_decimate: do not compare the first frame to itself.
[16:05:46 CET] <nevcairiel> michaelni: do you want to push the h264 ref list revert? or waiting for more comments?
[16:07:38 CET] <michaelni> wanted to wait a bit, yes
[16:08:01 CET] <nevcairiel> ok
[16:10:02 CET] <cone-807> ffmpeg 03Michael Niedermayer 07master:97c162add7f3: avformat/ffmdec: Add {} to nested if/else
[16:10:22 CET] <jiggunjer> so what forums do ffmpeg devels frequent? they ever visit doom9 and such?
[16:10:34 CET] <nevcairiel> some do
[16:10:50 CET] <michaelni> ill probably push it later today though if i dont forget and noone commented and i dont run into a reason to wait more
[16:45:21 CET] <durandal_1707> jiggunjer: what's there?
[16:46:52 CET] <kierank> nevcairiel's club of fanbois is there :)
[16:47:22 CET] <durandal_1707> something recently?
[17:19:11 CET] <jiggunjer> durandal_1707: nah just curious
[17:22:46 CET] <wm4> durandal_1707: there are people who use avisynth
[17:22:59 CET] <wm4> and other windows-only legacy fun
[17:23:14 CET] <wm4> (the "legacy" bit is a troll, don't mind)
[17:27:27 CET] <jiggunjer> wm4:  I think vapoursynth seems pretty cool. I just can't install it :p
[17:33:45 CET] <Daemon404> why not?
[17:34:26 CET] <Daemon404> also doom9 is also full of "special" people
[17:34:34 CET] <Daemon404> on some forums
[17:34:41 CET] <Daemon404> one guy wrote a webserver in avisynth
[17:43:16 CET] <durandal_1707> It sucks
[18:05:25 CET] <durandal_1707> atomnuker: do time and frequency axis legends needs to go in power of 10 or any number may be used?
[18:10:19 CET] <atomnuker> linear for the time legend (0 secs, 10 sec, 20 sec, etc.) and -inf to 0 dB for the amplitude
[18:12:22 CET] <atomnuker> sorry, I mean linear for the frequency as well (the amplitude is the color)
[18:27:32 CET] Action: Compn finally installs that google downloader and realizes its kind of crap. bunch of html files downloaded, how useful...
[18:34:56 CET] <ubitux> Compn: i'm interested in decoding working samples, not stuff isn't supported yet, but thx
[18:35:11 CET] <ubitux> wm4: yeah i'm just wondering about stuff that needs different timing for rectangles
[18:35:26 CET] <ubitux> but i guess the decoder could just consume part of the packet and out multiple sub
[18:35:30 CET] <ubitux> juste like the other codecs
[18:35:37 CET] <wm4> yeah
[18:35:48 CET] <wm4> so even if the need for it arises, we'll be fine
[18:36:02 CET] <ubitux> alright, well i think i can submit sth soon then
[18:36:11 CET] <ubitux> i'm just a bit annoyed by the zvbi stuff
[18:36:27 CET] <wm4> what does zvbi do?
[18:36:32 CET] <Daemon404> nothing of value
[18:36:35 CET] <wm4> well, teletext
[18:36:53 CET] <wm4> (why does it still exist)
[18:37:22 CET] <Daemon404> purely to make kierank's life more fun
[18:42:50 CET] <kierank> People use teletext
[18:43:01 CET] <kierank> In Nordic countries it is more popular than the web
[18:43:32 CET] <JEEB> well, used to be
[18:43:42 CET] <JEEB> heck, you could even get ASCII art boobs from there
[18:43:54 CET] <JEEB> (all those adult phone nr ads)
[18:45:23 CET] <Daemon404> JEEB, i thought nordic countries were supposed to be livign in the future
[18:45:25 CET] <Daemon404> not the past
[18:45:38 CET] <JEEB> well as I said, used to be
[18:45:44 CET] <JEEB> until internets became prevalent
[18:45:57 CET] <JEEB> I think I last used them in the very early 2000s
[18:46:18 CET] <JEEB> because I still had a  56,600bps modem and thus going online cost every second
[18:46:36 CET] <atomnuker> teletext can be considered retr-ofuturistic
[18:46:56 CET] <Daemon404> like bbs and green-on-black vecotr maps?
[18:47:00 CET] <Daemon404> vector*
[18:47:45 CET] <atomnuker> yeah, like those and MIDI music
[18:47:59 CET] <JEEB> kierank: in finland at least the official thing was DVB subs, as there was no requirement for them to be text-to-speech'able. of course, in 2001 the capabilities of DVB subtitle renderers were... not exactly perfect
[18:48:07 CET] <JEEB> so in the end a lot of the channels just hardcoded the subs
[18:48:12 CET] <JEEB> except the public broadcaster
[18:48:19 CET] <JEEB> which stayed with its DVB subtitles
[18:50:03 CET] <BtbN> Text-To-Speechable Subtitles?
[18:50:13 CET] <BtbN> Aren't they Speech-To-Text anyway?
[18:50:45 CET] <JEEB> well the US requires the captions to be in text
[18:51:03 CET] <JEEB> for text-to-speech reasons
[18:51:38 CET] <Daemon404> [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.
[18:51:41 CET] <Daemon404> drama taimu
[18:53:00 CET] <JEEB> cool
[18:53:20 CET] <jamrial> Alexandra had already ported the needed bits to get bitexact xll decoding working
[18:54:50 CET] <JEEB> yeah, now it's time to discuss which way is the one people want to go with.
[18:55:11 CET] <j-b> Can we stop this madness?
[18:55:17 CET] <Daemon404> $5 says ffmpeg ends up with 2 decodrs again
[18:55:21 CET] <atomnuker> 7000 lines for an audio decoder
[18:55:29 CET] <JEEB> Daemon404: hopefully not :P
[18:55:36 CET] <JEEB> we only need one working one :D
[18:56:05 CET] <Daemon404> j-b, might not be too bad
[18:56:12 CET] <Daemon404> foo86 is an exceedingly reaosnable person.
[18:56:23 CET] <JEEB> yeah, that's the image I've gotten of him
[18:56:30 CET] <nevcairiel> libdcadec is far  more feature complete with a knowledgeable maintainer, so if thats any consideration
[18:56:53 CET] <jamrial> yeah, i'd replace the current dca decoder for this port foo86 wrote of libdcadec
[18:56:56 CET] <atomnuker> then why did it take them so long to make a stable release
[18:57:11 CET] <JEEB> atomnuker: x264 never made any stable releases vOv
[18:57:15 CET] <jamrial> he was awol for months for some reason
[18:57:17 CET] <Daemon404> jamrial, ditto, but it's not going to be Politically COrrect
[18:57:42 CET] <nevcairiel> screw that
[18:57:46 CET] Action: BBB winks @ j-b
[18:57:50 CET] <BBB> j-b: can you fix us please?
[18:58:15 CET] <Daemon404> BBB, i dont knwo if j-b owns a shotgun
[18:58:17 CET] <j-b> Full rewrites are never a good idea, IMHO
[18:58:26 CET] <Daemon404> j-b, have you seen avidec? ;)
[18:58:27 CET] Action: Daemon404 runs
[18:58:37 CET] <BBB> Daemon404: I hear shotguns are easy to buy in the US
[18:58:45 CET] <j-b> and then people ask why we have our own demuxers.
[18:58:47 CET] <jamrial> "Performance wise, this decoder used to be around 10% slower than pure floating point version of existing native DCA decoder."
[18:58:49 CET] <jamrial> "However, after native DCA decoder has been partially converted to fixed point, this decoder became 5% faster than native one"
[18:59:03 CET] <jamrial> well, that's a point in foo86's favor
[18:59:18 CET] <nevcairiel> thats mostly because there used to be float simd which was deleted
[18:59:18 CET] <nevcairiel> :D
[18:59:47 CET] Action: BBB begs j-b to fix us
[18:59:58 CET] <nevcairiel> the recent dca patches are practically copying parts of libdcadec
[19:00:11 CET] <nevcairiel> so instead of doing that, why not just use the entire thing which is feature complete
[19:00:23 CET] <jamrial> ^
[19:00:36 CET] <wm4> <Daemon404> $5 says ffmpeg ends up with 2 decodrs again <- 3
[19:00:48 CET] <Daemon404> i thiught the otehr guy vanished
[19:00:52 CET] <Daemon404> loltypos.
[19:01:07 CET] <nevcairiel> there is no reason to keep the old one if this one goes in, it has zero arguments for keeping it
[19:01:09 CET] <wm4> the libdcadec wrapper will remain, even if foo86's patches are included
[19:01:34 CET] <nevcairiel> that depends if he plans to continue it or abandons it if it goes in
[19:01:55 CET] <Daemon404> wm4, why
[19:02:02 CET] <nevcairiel> but the wrapper is tiny in comparison to a real decoder
[19:02:05 CET] <wm4> Daemon404: because madness
[19:02:10 CET] <Daemon404> nevcairiel, abadoning it makes no difference
[19:02:11 CET] <jamrial> we still have wrappers for libnut and other seemingly dead libraries, though
[19:02:12 CET] <Daemon404> libutvideo
[19:02:17 CET] <Daemon404>  doesnt even BUILD on linux anymore
[19:02:20 CET] <Daemon404> you have to use a random fork
[19:02:22 CET] <Daemon404> to use it with ffmpeg
[19:02:23 CET] <BBB> libnut
[19:02:26 CET] <Daemon404> and yet it remains
[19:02:26 CET] <BBB> muhahahahahhahahhahaha
[19:02:29 CET] <BBB> omg
[19:02:30 CET] <BBB> nut
[19:02:38 CET] <Daemon404> BBB, nut is not bad for specific usecases
[19:02:44 CET] <Daemon404> specifically, piping rawvideo with real timestamps.
[19:02:53 CET] <wm4> but the libnut wrapper has no reason to exist anyway
[19:02:58 CET] <Daemon404> of course
[19:03:05 CET] <wm4> you can't even make up reasons
[19:03:08 CET] <wm4> yet it will remain
[19:03:19 CET] <wm4> (I want out if here)
[19:03:33 CET] <Daemon404> i could probably remove libutvideo*.cpp if i was so inclined tbh
[19:03:39 CET] <Daemon404> if i added 10bit support to the native decoder
[19:03:42 CET] <Daemon404> but i just dont care.
[19:04:24 CET] <j-b> performance point is debatable, if you discuss SIMD'd versions vs non-SIMD'd ones
[19:04:37 CET] <nevcairiel> both are non-simd now
[19:05:02 CET] <atomnuker> I keep telling people to stop whining about <X> being useless anymore, submit a damned patch and complain if it's not accepted damnit
[19:05:24 CET] <Daemon404> atomnuker, eh ive submitted 2-3 patches to remove libutvideo
[19:05:26 CET] <j-b> "uses assembly optimized version of synth_filter"
[19:05:28 CET] <Daemon404> rejected every time
[19:05:36 CET] <wm4> my patches to remove stuff just cause drama
[19:05:38 CET] <wm4> nothing else
[19:05:44 CET] <j-b> resubmitting rejected patches is rude.
[19:05:56 CET] <atomnuker> no it's not, it's necessary
[19:06:08 CET] <nevcairiel> j-b: lets just say they use the same amount of simd
[19:06:16 CET] <Daemon404> 'rejected' by carl, because "it's a feature"
[19:06:20 CET] <wm4> and "why u remove it doesn't harm" type of replies
[19:06:42 CET] <atomnuker> I haven't seen a single patch to remove a feature in the last 5 months
[19:06:52 CET] <Daemon404> atomnuker, because we all gave uo
[19:06:53 CET] <Daemon404> long ago
[19:06:59 CET] <atomnuker> times change
[19:07:05 CET] <Daemon404> carl doesnt change
[19:07:08 CET] <wm4> the vdpau decoder is still in
[19:07:17 CET] <atomnuker> he learns to understand however
[19:07:18 CET] <j-b> +1
[19:07:21 CET] <Daemon404> atomnuker, ok you have inspired me
[19:07:22 CET] <j-b> vdpau...
[19:07:29 CET] <Daemon404> i will send a patch to remove libstagefright
[19:07:31 CET] <Daemon404> wish me luck
[19:07:33 CET] <j-b> lol
[19:07:39 CET] <j-b> stagefright is useful
[19:07:44 CET] <wm4> (and for the log, I mean the deprecated legacy vdpau wrapper, not the proper hwaccel)
[19:07:49 CET] <atomnuker> Daemon404: not stagefright, doon't fuck with android/embedded people
[19:07:59 CET] <Daemon404> j-b, inside ffmpeg? where you cnat even build it without special incantations the only one man knows? and specific versions?
[19:08:10 CET] <j-b> Daemon404: it's a JOKE, man
[19:08:24 CET] <j-b> Daemon404: I've asked for xvmc, vdpau, and stagefright to go away
[19:08:24 CET] <Daemon404> j-b, poe's law is strong in this community
[19:08:25 CET] <Daemon404> ffs
[19:08:27 CET] <wm4> atomnuker: well we should have mediacodec support instead, but unfortunately that got killed with drama/bikeshed by myself
[19:08:34 CET] <wm4> (java etc.)
[19:08:37 CET] <j-b> and everyone, mostly Carl and ubitux jump on my throat
[19:08:52 CET] <ubitux> ?
[19:08:55 CET] <j-b> mediacodec has a JNI API
[19:09:07 CET] <atomnuker> wm4: doesn't mediacodec actually depend on libavcodec?
[19:09:17 CET] <Daemon404> atomnuker, stagefright also does
[19:09:20 CET] <nevcairiel> mediacodec is just an API
[19:09:25 CET] <j-b> atomnuker: why would it depend on libavcodec?
[19:09:27 CET] <wm4> I suppose many multimedia frameworks do
[19:09:30 CET] <nevcairiel> what comes behind that is of no consequence for us
[19:09:35 CET] <wm4> (in form of plugins)
[19:09:44 CET] <j-b> most mediacodec versions don't use libavcodec
[19:09:59 CET] <ubitux> j-b: i never said xvmc,vdpau and stagefright should stay; the only thing i probably said was that it needs to be discussed
[19:10:24 CET] <iive> do you mean the whole vdpau?
[19:10:31 CET] <ubitux> probably the old implementation
[19:10:58 CET] <atomnuker> what's wrong with VDPAU anyway, it's just another hardware decoder anyway
[19:11:39 CET] <iive> I don't mind triggering the FF_API_XVMC, have in mind this won't remove xvmc, it would just remove some backward compatibility.
[19:12:01 CET] <iive> i might even send patches for that.
[19:12:25 CET] <Daemon404> btw you guys forgot teh best thing thaty wasnt removed
[19:12:26 CET] <Daemon404> sonic.
[19:12:32 CET] <Daemon404> the lossless audio codec which makes files bigger.
[19:13:34 CET] <j-b> Daemon404: you can't do that! Because that' would mean that libav was right.
[19:14:01 CET] <wm4> Daemon404: encoder?
[19:14:08 CET] <Daemon404> indeed
[19:14:14 CET] <Daemon404> ... holy what...
[19:14:15 CET] <Daemon404> tools/build_libstagefright
[19:14:20 CET] <Daemon404> the fact this exists is just sad
[19:15:14 CET] <wm4> Daemon404: the fact that nobody ever updated it is also telling
[19:15:18 CET] <JEEB> lol
[19:15:29 CET] <atomnuker> just let the embedded people live in their own little isolated unhappy depressing world
[19:16:10 CET] <kierank> or perhaps let them fix it
[19:16:18 CET] <kierank> instead of just leaving crap in our codebase
[19:16:36 CET] <j-b> there is a lot of crap already
[19:16:38 CET] <Daemon404> ... the file started as build.sh in /
[19:16:39 CET] <Daemon404> wtf?
[19:16:47 CET] <Daemon404> how was that ever accepted
[19:17:08 CET] <j-b> because feature-competition-with-libav
[19:17:23 CET] <j-b> but, once again, I'm going to be attacked by ubitux, on this.
[19:17:42 CET] <ubitux> you're such a martyr
[19:17:50 CET] <j-b> not really
[19:18:25 CET] <ubitux> i never opposed to the drop of stagefright
[19:18:27 CET] <j-b> but you attacked me quite strongly, not long ago, on just this part.
[19:19:09 CET] <j-b> and explained again how useful it must be, if people still sent patches.
[19:19:09 CET] Action: wm4 orders 10 kilotons of popcorn
[19:19:30 CET] <ubitux> again, i never said stagefright must be kept
[19:19:40 CET] <ubitux> nor did i for xvmc, vdpau etc
[19:21:00 CET] <wm4> j-b: I disagree with you though, ubitux was never someone who actually blocked cleanups, but rather someone who stressed the need for discussion
[19:21:38 CET] <j-b> wm4: sorry, that's not what my emails/IRC logs say.
[19:23:15 CET] <ubitux> maybe read them again then
[19:23:25 CET] <j-b> In fact, I just did.
[19:23:49 CET] <ubitux> and so i said stagefright must be kept?
[19:25:26 CET] <Daemon404> [master 030c77b] avcodec: Remove libstagefright 7 files changed, 1 insertion(+), 659 deletions(-)
[19:25:32 CET] <Daemon404> RFC coming
[19:26:02 CET] <jamrial> don't send a patch with ~700 lines being removed. crop it please :p
[19:26:06 CET] <iive> may i ask something.
[19:26:13 CET] <Daemon404> j-b, there is -M or whatever
[19:26:15 CET] <iive> do you have good reason to remove the code?
[19:26:16 CET] <Daemon404> er, jamrial 
[19:26:25 CET] <Daemon404> iive, yes i have included my reasonin
[19:26:30 CET] <Daemon404> it is an RFC
[19:26:34 CET] <j-b> Daemon404: 5.0, 5.1 and 6.0, yes.
[19:26:34 CET] <Daemon404> thats the point. to discuss.
[19:26:37 CET] <jamrial> I thought -M detects renames, not removals
[19:27:37 CET] <Daemon404> jamrial, yes reading man git right now
[19:28:03 CET] <atomnuker> Daemon404: don't send it as RFC, but please list reasons for those of us unaware
[19:28:26 CET] <Gramner> JEEB: oh but x264 does releases - one for each commit ;)
[19:28:29 CET] <atomnuker> just a normal PATCH to avoid discussions to discuss stuff
[19:28:36 CET] <JEEB> Gramner: lol
[19:29:06 CET] <iive> Daemon404: i don't see the mail yet. could you summarize ?
[19:29:58 CET] <Daemon404> jamrial, -D
[19:30:03 CET] <Daemon404> iive, i am sending now
[19:30:07 CET] <jamrial> cool
[19:30:27 CET] <Daemon404> i am also CCing it's 'maintainer'
[19:30:42 CET] <atomnuker> Daemon404: make sure to include reasons and drop the RFC
[19:30:46 CET] <Daemon404> yes.
[19:31:01 CET] <nevcairiel> -D is not actually applyable though, but not that this matters
[19:32:56 CET] <iive> well, I just hope that the reasons are better than "it's ugly, I don't like it, it is maintenance burden(tm), nobody uses it"
[19:34:28 CET] <atomnuker> don't forget the whole stagefright font security fisco too
[19:35:28 CET] <iive> tbh, i have no idea what stagefright is. And I don't think i've heard of the font security fiasco either.
[19:36:13 CET] <nevcairiel> maybe you should refrain from commenting then :D
[19:37:49 CET] <Daemon404> sent.
[19:44:36 CET] <Daemon404> urg, if mails are sent to both mailing lists by someone, gmail deduplicates it
[19:44:43 CET] <Daemon404> and the filters just put it in a random folder
[19:44:51 CET] <Daemon404> depending on the order of the emails in To:
[19:45:51 CET] <iive> the first paragraph sound quite convincing to me.
[19:46:52 CET] <Daemon404> aside from my usual typos
[19:47:51 CET] <philipl> Daemon404: so what's our recommended way to use mediacodec?
[19:48:49 CET] <Daemon404> via its JNI api, i'd assume
[19:49:16 CET] <ubitux> you have a c api but for 5+ only, so covering a small subset
[19:49:31 CET] <philipl> Sorry, I mean - we're saying that you shouldn't try and use mediacodec through libavcodec.
[19:49:43 CET] <Daemon404> philipl, you use avcodec through mediacodec
[19:49:52 CET] <philipl> Ok.
[19:50:10 CET] <philipl> As opposed to an hwaccel on top of mediacodec existing, which someone could, theoretically, write.
[19:50:27 CET] <Daemon404> j-b probably has opinions on that
[19:50:32 CET] <Daemon404> i dont
[19:50:36 CET] <ubitux> mediacodec buffering is a bit annoying though, mateo might want to talk about it (iirc he's working on it)
[19:50:49 CET] <philipl> Anyway. I'm fine with removing stagefright regardless of the answer to that question.
[19:50:55 CET] <wbs> Daemon404: "use avcodec through mediacodec", no, that's completely unrelated
[19:51:07 CET] <Daemon404> is it?
[19:51:11 CET] <wbs> yes
[19:51:15 CET] <Daemon404> in pratcical effect how does it differ
[19:51:17 CET] <Daemon404> ok
[19:51:24 CET] <wbs> and your list of reasons is partially kinda confused
[19:51:35 CET] <Daemon404> tbh i was hoping you would show up
[19:51:37 CET] <wbs> (but I wholeheartedly agree that it should be remoed and purged with fire)
[19:52:03 CET] <Daemon404> im a resident troll/annoying guy, youre the android knowledge here
[19:52:27 CET] <Daemon404> im fine with being a bullet sponge.
[19:52:28 CET] <wbs> first, definitions of some names: "stagefright" is the name of the android media framework; MediaCodec is the only supported public API to this framework
[19:52:44 CET] <wbs> the current "libstagefright" decoder uses the C++ OMXCodec class interface to stagefright
[19:53:16 CET] <wbs> atomnuker also said "due to the recent stagefright vulnerabilities, this should be removed" - this is a completely unrelated argument; there were vulns in stagefright's mp4 demuxer iirc
[19:53:37 CET] <wbs> but whether those exist or not is kinda unrelated to whether avcodec should use android hwaccels for decoding
[19:53:44 CET] <atomnuker> doesn't matter, still discredits stagefright
[19:53:51 CET] <Daemon404> everybody has sec vulns
[19:54:05 CET] <atomnuker> those were major because +billion devices
[19:54:07 CET] <Daemon404> i know youre not exactly an ffmpeg guy, but a reply from a knowledgable person could certain clarify stuff
[19:54:13 CET] <Daemon404> @ wbs
[19:54:15 CET] <wbs> yes, but if you want to have hw accel decoding on android, you _have_ to go through stagefright
[19:54:34 CET] <wbs> Daemon404: sure, I'll just rehash it here first :P
[19:54:39 CET] <nevcairiel> but its better to do that indirectly through another favored API, isnt it
[19:54:44 CET] <Daemon404> wbs, lol ok
[19:54:46 CET] <j-b> or through Mediacodec 
[19:54:48 CET] <wbs> nevcairiel: yep
[19:54:54 CET] <philipl> The main reason to drop it is that it's not the supported public API and if someone wanted to do an hwaccel implementation on top of mediacodec they could, and our stagefright code is so limited that removing it shouldn't depend on mediacodec support existing.
[19:54:54 CET] <Daemon404> j-b probably knows a bunch too
[19:54:59 CET] <wm4> the situation on android seems to be complicated...
[19:55:03 CET] <wbs> it still goes through "stagefright" as general framework though
[19:55:06 CET] <wbs> philipl: exactly
[19:55:13 CET] <Daemon404> philipl, i should have listed that, yes
[19:55:35 CET] <wbs> Daemon404: also you said "Both stagefright and mediacodec have avcodec backends and this is the correct way to use it" - no
[19:55:50 CET] <Daemon404> that became clear a few paragraphs up
[19:56:09 CET] <wbs> some vendors, like some third party firmwares, have avcodec as stagefright backend
[19:56:26 CET] <wbs> so you can decode whatever codec in the stock system player that uses stagefright/mediacodec
[19:56:26 CET] <j-b> well, omx backends :)
[19:56:29 CET] <Daemon404> maybe i should use this as an example of misinformation / cargo culting / whatever spreading
[19:56:32 CET] Action: Daemon404 hides
[19:56:57 CET] <j-b> stagefright uses mediacodec, that uses OMX, which can have a libavcodec backend.
[19:57:10 CET] <wbs> so think of stagefright/mediacodec as gstreamer, it can have any plugin, the real decoder plugin backend could be avcodec, or could be the real hw
[19:57:37 CET] <Daemon404> apps cnat ship their own plugins, unlike gst
[19:57:39 CET] <Daemon404> afaict
[19:57:49 CET] <wbs> correct
[19:57:59 CET] <j-b> which is great, because we can have avcodec using stagefright, using mediacodec and OMX, which can use avcodec
[19:58:06 CET] <wbs> and using stagefright/mediacodec is the only way of accessing hw decoders
[19:58:54 CET] <Daemon404> gotcha; get it now
[19:59:03 CET] <j-b> only "standard" way :)
[19:59:06 CET] <wm4> so I'm confused, is using libstagefright actually a proper approach?
[19:59:15 CET] <Daemon404> wm4, it's not public api
[19:59:23 CET] <Daemon404> mediacodec is
[19:59:24 CET] <wbs> now the only limitation is that to access hw codecs, it has to go through the mediaserver process, which requires you to use some part of the stagefright apis - either two of the old private, abi unstable APIs (IOMX or OMXCodec)
[19:59:38 CET] <wbs> wm4: no, it uses private APIs
[19:59:56 CET] <wm4> wait, so you have to use stagefright _and_ omx?
[20:00:01 CET] <wbs> the current code reequires you to build a separate libavcodec.so for each major android versions you want to target, if you'd use the libstagefright code
[20:00:13 CET] <wbs> wm4: no
[20:00:24 CET] <wbs> wm4: you'd have to use "stagefright as in the framework, in some form"
[20:00:52 CET] <wbs> wm4: the _real_ limit is that the only process that is allowed to talk to the hw codecs (say /dev/qdsp* on qualcomm) is the mediaserver process
[20:01:11 CET] <wbs> wm4: now you need to talk to the mediaserver to ask it to do the decoding for you, via one form of IPC API or another
[20:01:35 CET] <wbs> wm4: before there were any public API, I (and others) figured out which internal APIs one could use, which were kinda-stable-ish enough to use
[20:01:48 CET] <wbs> these still were ABI unstable, so you'd have to build a separate .so for each targeted android version
[20:02:09 CET] <wbs> so at runtime, check which android version you're running on, load the right .so, and hope things go well
[20:02:37 CET] <wbs> (we implemented this pretty neatly, with only a very small, a few KB .so that is target dependent, within VLC, but in a generic thing like avcodec, it's be hell)
[20:03:09 CET] <wbs> now currently there's (at least) three APIs in use, IOMX, OMXCodec and MediaCodec
[20:03:09 CET] <wm4> ok
[20:03:38 CET] <wm4> what's the difference between the two OMX things? I thought OMX is a standardized thing by khronos
[20:03:47 CET] <wbs> all three technically are "stagefright", they all access the stagefright framework, and all talk to the mediaserver process to let you do hw decoding
[20:03:56 CET] <j-b> wm4: the difference is how you speak to the mediaserver
[20:03:59 CET] <rcombs> wbs: yeah, what blocks direct use of OMX?
[20:04:13 CET] <wbs> IOMX is a C++ IPC version of plain OMX, pretty straightforward
[20:04:24 CET] <j-b> rcombs: only one process has access to it, the mediaserver
[20:04:38 CET] <wm4> wbs: sounds disgusting
[20:04:41 CET] <rcombs> joy
[20:04:48 CET] <j-b> lol
[20:04:58 CET] <j-b> disgusting? like this was the worse thing of Android.
[20:05:01 CET] <BtbN> Also nice if there is some flaw in that process. You get free root access, aparently.
[20:05:06 CET] <wbs> on top of IOMX you either have OMXCodec, which is their own legacy API, which also is C++
[20:05:19 CET] <wbs> OMXCodec is pretty highlevel, or really highlevel
[20:05:20 CET] <rcombs> wbs: j-b: last I heard, the media server couldn't be accessed from a plain C/++ program because it requires some Java "Binder" IPC to be running in the calling process
[20:05:34 CET] <wbs> this is what the "libstagefright" code uses
[20:05:37 CET] <wm4> and for mediacodec, isn't there both a java and c++ API?
[20:05:39 CET] <rcombs> have you seen the NDK C API for all this?
[20:05:44 CET] <wbs> the "new" stuff internally in stagefright uses a class called ACodec
[20:05:54 CET] <rcombs> (it's a thin public wrapper around the MediaCodec C++)
[20:06:08 CET] <wbs> ACodec isn't public API either
[20:06:23 CET] <wbs> but MediaCodec is on top of ACodec, and that's public API
[20:06:26 CET] <rcombs> something about needing to be spawned from zygote
[20:06:30 CET] <j-b> wm4: yes, there are.
[20:06:43 CET] <wbs> rcombs: yes, I've seen it
[20:07:03 CET] <wbs> it probably doesn't work in a purely plain native app (like commandline stuff)
[20:07:24 CET] <rcombs> `NdkMediaCodec.h`
[20:07:30 CET] <rcombs> wbs: yeah, apparently requires spawning from zygote
[20:07:32 CET] <wbs> rcombs: iirc there's a oneline call you can do within your code to make it start up the necessary stuff
[20:07:33 CET] <rcombs> which is some bullshit
[20:07:39 CET] <rcombs> oh?
[20:07:53 CET] <wm4> rcombs: what does that even mean
[20:07:53 CET] <rcombs> also, there doesn't seem to be a way to get it to return opaque buffers
[20:07:57 CET] <rcombs> so have fun doing memcpy
[20:08:15 CET] <rcombs> wm4: Android apps are spawned by fork()ing from a single parent process and then _not_ doing execve()
[20:08:27 CET] <rcombs> that parent being "zygote"
[20:08:54 CET] <j-b> rcombs: well, yes, you can get an opaque buffer, and then display it.
[20:08:54 CET] <wbs> rcombs: in practice this is a non-issue though, all real apps will be launched that way anyway, it's only an issue if you want to do debugging on plain commandline binaries
[20:08:54 CET] <wm4> and exec "destroys" it?
[20:09:08 CET] <wbs> rcombs: hmm, I don't remember if the NDK interface to mediacodec is complete or not in this regard
[20:09:24 CET] <wbs> rcombs: android::ProcessState::self()->startThreadPool();
[20:09:50 CET] <wbs> rcombs: that was enough for me to have working binder/IPC
[20:09:55 CET] <rcombs> j-b: is it possible to get an opaque buffer from the decoder, then _encode_ it?
[20:10:05 CET] <rcombs> wbs: hmm, interesting
[20:10:14 CET] <j-b> rcombs: yes.
[20:10:25 CET] <rcombs> j-b: which API? OMXCodec directly?
[20:10:40 CET] <prelude2004c2> hey guys. having trouble with vdpau... someone told me to decode using " vc ffh264vdpau   " . not sure where to put that.. i am using ffmpeg
[20:10:43 CET] <prelude2004c2> mpeg2video sources seem to decode ok and then i can transcode it to something else.. but h264 sources don't seem to decode at all
[20:10:45 CET] <prelude2004c2> i am using M4000 card
[20:10:52 CET] <prelude2004c2> running latest 258.16 version
[20:10:54 CET] <wbs> rcombs: no, forget OMXCodec
[20:10:57 CET] <j-b> rcombs: MC.
[20:11:08 CET] <j-b> rcombs: I mean, everything now can have MC
[20:11:13 CET] <wbs> OMXCodec is a dead end, their own old internal API which they haven't used since 2010 or so
[20:11:26 CET] <rcombs> isn't MediaCodec on top of OMXCodec?
[20:11:31 CET] <wm4> how are android drivers implemented?
[20:11:35 CET] <wm4> I thought they used OMX
[20:11:46 CET] <j-b> in 6.0, supposedly, MediaCodec can be totally decorelated from OMX
[20:11:49 CET] <wbs> no
[20:11:59 CET] <j-b> but I've not seen that yet.
[20:12:04 CET] <wbs> everything is on top of IOMX
[20:12:18 CET] <wbs> wm4: yes
[20:12:33 CET] <wbs> you have IOMX <- OMXCodec - this chain is EOL and only for old codepaths
[20:12:53 CET] <wbs> then separately there's IOMX <- ACodec <- MediaCodec
[20:12:53 CET] <wbs> MediaCodec is public
[20:13:08 CET] <wbs> but much of the stagefright framework's high level player classes use ACodec directly
[20:13:14 CET] <Daemon404> this sounds liek such epic pain compared to avfoundation on ios
[20:13:23 CET] <wbs> wm4: yes, the drivers are OMX
[20:13:26 CET] <rcombs> public, but with the headers in AOSP instead of NDK, yeah?
[20:13:37 CET] <wbs> wm4: but the "OMXCodec" API is a wart one shouldn't be touching
[20:13:40 CET] <j-b> wbs: didn't they say that starting from 6.0 they allowed drivers that were not OMX based?
[20:13:44 CET] <rcombs> (which is mildly inconvenient but not a huge deal)
[20:13:48 CET] <j-b> especially for TV?
[20:13:50 CET] <wm4> ok, so conclusion: OMX is interesting only for android driver devs
[20:14:01 CET] <wbs> Daemon404: not really
[20:14:07 CET] <wbs> Daemon404: the thing is, with android, one can poke into these things already before the public API existed
[20:14:16 CET] <wbs> Daemon404: which people impatiently did, like me
[20:14:26 CET] <Daemon404> wbs, well also the fact that for ios you only usually worry about a few versions at most
[20:14:28 CET] <wm4> so what does VLC use these days?
[20:14:29 CET] <Daemon404> not 900
[20:14:35 CET] <wbs> Daemon404: publicly, there only exists one thing, MediaCodec, with Java and C interfaces
[20:14:53 CET] <wbs> Daemon404: sure, that helps
[20:15:01 CET] <j-b> wm4: we use Mediacodec-C, MediaCodec-Java and IOMX, depending on the version.
[20:15:51 CET] <wbs> wm4: yes, the OMX layer should only be touched if you're implementing a driver, more or less. and as j-b says, one might not need to do it then either
[20:16:06 CET] <wbs> rcombs: no, MediaCodec's headers exist in the public NDK
[20:16:29 CET] <wm4> IOMX only for older versions?
[20:16:35 CET] <wbs> rcombs: the subset you're supposed to use that is, the public C frontend functions. the internal C++ implementation of the MediaCodec class is only in AOSP of course, and that's also private/ABI unstable
[20:16:35 CET] <rcombs> wbs: where?
[20:16:39 CET] <wm4> and meciacodec-c for the newest?
[20:16:43 CET] <j-b> wm4: yes
[20:16:47 CET] <rcombs> ah, NdkMediaCodec.h
[20:16:56 CET] <wbs> yes
[20:17:03 CET] <rcombs> wbs: so is it possible to get that to throw around opaque buffers instead of lots-o'-memcpy?
[20:17:11 CET] <j-b> Seriously, the solution is Mediacodec-C and if you want, do a wrapper to mimick it, for older versions.
[20:17:16 CET] <wbs> wm4: yes
[20:17:22 CET] <j-b> rcombs: yes, that's what we do in VLC.
[20:17:28 CET] <rcombs> how?
[20:17:48 CET] <wm4> <j-b> Seriously, the solution is Mediacodec-C and if you want, do a wrapper to mimick it, for older versions. <- so why has nobody copied google's mediacodec-c and ported it back to older androids for application use?
[20:17:52 CET] <rcombs> or, just point me at the relevant source?
[20:17:58 CET] <j-b> wm4: don't ask me.
[20:18:14 CET] <Daemon404> wm4, because j-b doesnt need mroe libraries to personally maintain ;)
[20:18:23 CET] <wm4> ok, so hopefully there's no deeper reason why this would be impossible
[20:18:24 CET] <j-b> wm4: not that I haven't seen proprietary code that does it...
[20:18:54 CET] <j-b> wm4: the reason is mostly because of the management of JNIEnv* and JavaVM* pointers
[20:19:06 CET] <wm4> rcombs: the VLC source tree is easy to navigate, just keep in mind most is under modules/
[20:19:24 CET] <wm4> j-b: urgh, forgot about this
[20:19:29 CET] <wbs> wm4: the mediacodec C API is a plain C frontend on top of the internal native MediaCodec class
[20:19:38 CET] <j-b> rcombs: in some cases, with specific hardware, we can even use tuneled-playback
[20:19:40 CET] <rcombs> https://github.com/videolan/vlc/blob/master/modules/codec/omxil/mediacodec_ndk.c looks like this
[20:19:44 CET] <j-b> been there, done that.
[20:20:04 CET] <wbs> wm4: but if you want compat with the older versions where mediacodec was only in java, you need a few extra API hooks for the java env stuff
[20:20:16 CET] <rcombs> j-b: is this actually documented anywhere? (or should I just use the VLC code as reference)
[20:20:29 CET] <j-b> rcombs: depends, why do you need that? :D
[20:20:33 CET] <j-b> rcombs: just use libvlc :)
[20:20:49 CET] <rcombs> j-b: I'd like to do full-hardware transcoding on Android in ffmpeg
[20:20:59 CET] <wm4> libavcodec/libvlc.c
[20:21:12 CET] <j-b> rcombs: clean ffmpeg first :)
[20:21:21 CET] <rcombs> lolrecursion
[20:21:50 CET] <j-b> rcombs: it is doable, jokes asides, but it's a bit hard.
[20:21:54 CET] <wbs> rcombs: doing zerocopy-transcoding with mediacodec is possible but a bit hard-ish; in general, first look at the java API of MediaCodec
[20:22:04 CET] <j-b> rcombs: we're going to work on this on VLC soon.
[20:22:09 CET] <wbs> rcombs: the java version is more complete and has got way more docs and explanations
[20:22:17 CET] <j-b> rcombs: IIRC, there were some part useful, that were missing in the C code.
[20:22:23 CET] <rcombs> wbs: and everything there does map to the C version?
[20:22:36 CET] <rcombs> wbs: I looked at this a while ago and didn't see a clear way to do it
[20:22:58 CET] <wbs> rcombs: well as long as there is a C version
[20:22:59 CET] <rcombs> but it could just be because it's in e.g. `setInt32` flags that I couldn't find docs for
[20:23:08 CET] <wbs> rcombs: in general, just think of the C version as a convenience
[20:24:06 CET] <wbs> rcombs: but basically, you need to request a Surface from the encoder, then pass this surface to the decoder as output during configure
[20:24:23 CET] <wbs> rcombs: I don't remember exactly if this setup is possible or not but I'd think it
[20:24:38 CET] <wbs> rcombs: the more complete version is to set up a GL ES rendering context on the encoder input surface
[20:25:14 CET] <wbs> rcombs: then "render" the decoded output surfaces into GL textures within this same context, and "blit" them to the encoder surface context in order to feed them to be encoded
[20:25:32 CET] <wm4> wtf
[20:26:26 CET] <wbs> well the thing is, in general, buffers are tied to a specific codec, so you can't take a decoder output buffer and pass it to the encoder
[20:26:36 CET] <wbs> the encoder can only take input in buffers owned by the encoder
[20:27:06 CET] <wbs> and the decoder can only output into the decoder's own output buffers, or onto an opaque surface that is configured during the decoder setup
[20:27:41 CET] <wbs> the opaque output surface can be a GL texture, and the encoder input surface can be a GL rendering context
[20:28:08 CET] <wbs> so the "copying" from decoder to encoder shouldn't really hit the CPU
[20:29:41 CET] <wbs> now all of this is possible to do. but the examples are java, and some of the surface management for decoding into gl textures and all that might be java-only
[20:29:45 CET] <j-b> wbs: that's what tguillem tried, IIRC
[20:29:57 CET] <wbs> so the correct way of learning it is to first figure out how it actually works in the platform's own real apis, i.e. java
[20:30:08 CET] <j-b> wbs: and I'll need him to look at this more, because of ChromeCast :)
[20:30:17 CET] <wbs> then once you understand it, you can try to reduce it back down to C
[20:30:50 CET] <wbs> j-b: yep :-)
[20:31:11 CET] <wbs> j-b: I haven't touched this much at all myself, only tried decode->glrender->encode once, to do transcoding with GL effects inbetween :P
[20:31:24 CET] <j-b> wbs: GL effects? neat.
[20:31:55 CET] <rcombs> scaling and deinterlacing would be useful to do there
[20:32:15 CET] <rcombs> maybe overlay (e.g. subtitle) rendering
[20:32:46 CET] <wbs> yep
[20:33:47 CET] Action: rcombs shudders at the thought of fitting OpenGL into libavfilter
[20:34:01 CET] <wbs> j-b: http://martin.st/temp/gl-video.mp4 (one effect at 10 to 20 secs, another from 20 to 30 secs in the file)
[20:34:12 CET] <rcombs> (though it's something I've thought of before, but the context sharing, amongst other things, is ~complicated~)
[20:34:48 CET] <wbs> rcombs: http://bigflake.com/mediacodec/ - in case you want to learn it in general
[20:36:46 CET] <rcombs> wbs: much appreciated
[20:36:47 CET] <j-b> wbs: neat. You're a genius.
[20:38:01 CET] <wbs> rcombs: ah sorry btw, the android::ProcessState::self()->startThreadPool(); line I posted is private internal API btw (back from when I meddled with the private APIs for this); dunno if there is any public API for it. for real app code it doesn't matter of course, only if you'd want to do this in a commandline './ffmpeg' binary on android
[20:38:30 CET] <rcombs> wbs: I do, but in this case using private APIs might not be out of the question
[20:38:39 CET] <cehoyos> Hi! Is the libdcadec author around?
[20:38:53 CET] <Daemon404> i dont think he is on irc
[20:39:08 CET] <rcombs> cehoyos: that guy's hard enough to get ahold of _off_ IRC
[20:39:18 CET] <cehoyos> Does anybody know how the decoder was written?
[20:39:22 CET] <cehoyos> Is there a specification?
[20:39:40 CET] <cehoyos> Or in other words: Why does it not have any copyright at all?
[20:40:27 CET] <wbs> Daemon404: actually, the only thing I want commented on your post is that the "... have avcodec backends already and is the correct way to use it", just remove this from the commit message and the rest should be kinda fine-ish
[20:40:34 CET] <rcombs> you mean copyright headers?
[20:40:43 CET] <cehoyos> I mean copyright notices
[20:40:50 CET] <Daemon404> wbs, eh ok
[20:40:59 CET] <cehoyos> I don't think the files can be committed without...
[20:41:02 CET] <rcombs> probably neglected to do so
[20:41:07 CET] <j-b> cehoyos: why not?
[20:41:33 CET] <Daemon404> as opposed to all the other fake/missing copyright we have?
[20:41:38 CET] <wm4> rcombs: context sharing for just one platform (android) might not be so hard
[20:41:41 CET] <cehoyos> Who gives you the right to use, modify etc. the file?
[20:41:44 CET] <rcombs> wm4: yeah
[20:41:53 CET] <j-b> cehoyos: the author.
[20:41:56 CET] <cehoyos> But again: How was it written?
[20:42:01 CET] <j-b> not the copyright notice.
[20:42:11 CET] <cehoyos> But who is the author that gives you the right?
[20:42:29 CET] <j-b> Usually, the one who is on the author line
[20:42:37 CET] <Daemon404> cehoyos, by that logic we should remove all code from wm4, and "elvis", etc. ;)
[20:42:45 CET] <Daemon404> just sayin'.
[20:42:45 CET] <j-b> Daemon404: no.
[20:42:46 CET] <wm4> D:
[20:42:48 CET] <cehoyos> That is definitely wrong°!
[20:42:49 CET] <cehoyos> !
[20:42:57 CET] <j-b> Daemon404: because we really know who wm4 and 'elvis' are.
[20:43:00 CET] <cehoyos> j-b: Could you point me to the author line?
[20:43:14 CET] <rcombs> author of the commits?
[20:43:16 CET] <j-b> From: foo86 <foobaz86 at gmail.com>
[20:43:21 CET] <Daemon404> j-b, there's plenty of mplayer-era code by anonymous people too
[20:43:24 CET] <Daemon404> thats still around
[20:43:37 CET] <Daemon404> or random <fakename.ffmpeg at gmail.com>
[20:43:40 CET] <j-b> wm4 and "elvis" are pseudonyms
[20:43:40 CET] <Daemon404> that oens popular.
[20:43:45 CET] <cehoyos> But he himself claims that he is not the author of the decoder or am I wrong?
[20:43:53 CET] <rcombs> huh?
[20:43:58 CET] <jamrial> cehoyos: foo86 is the author
[20:43:59 CET] <cehoyos> pseudonyms are of course no problem.
[20:44:03 CET] <Daemon404> cehoyos, libdcadec is foo86. he is the author.
[20:44:13 CET] <cehoyos> Then why does he not claim copyright?
[20:44:20 CET] <Daemon404> ceause he doesnt care?
[20:44:23 CET] <j-b> Daemon404: of course, why do you think I complain ALL the time, when you guys let people commit anonymously?
[20:44:27 CET] <Daemon404> :P
[20:44:29 CET] <rcombs> because he didn't think to do so?
[20:44:34 CET] <j-b> cehoyos: you don't claim copyright.
[20:44:36 CET] <rcombs> because nobody told him to
[20:44:45 CET] <cehoyos> If he doesn't care how can he give us the right to do something with the code?
[20:44:46 CET] <jamrial> probably because foo86 is a pseudonym and he didn't want it in the copyright headers
[20:44:48 CET] <rcombs> (and yeah copyright is automatic in the US at least)
[20:44:59 CET] <j-b> cehoyos: it does not work like that.
[20:45:04 CET] <cehoyos> Pseudonyms are of course ok (many books use it).
[20:45:05 CET] <j-b> cehoyos: he has rights.
[20:45:11 CET] <j-b> and you cannot remove them.
[20:45:17 CET] <rcombs> cehoyos: he owns the copyright on his own works automatically, and explicitly grants a license in the header of each file
[20:45:28 CET] <cehoyos> So  stop this and allow me to repeat: How was this decoder written?
[20:45:35 CET] <kierank> how do you think
[20:45:40 CET] <rcombs> probably with a text editor
[20:45:48 CET] <rcombs> *rimshot*
[20:45:50 CET] <kierank> the ceo of dts called him up and explained the codec to him
[20:45:53 CET] <j-b> exactly what rcombs said, except that he gave rights, not copyright.
[20:46:01 CET] <cehoyos> rcombs: He can only grants rights (and licenses) if he actually claims the copyright, I am not saying his code is (anywhere) in the public domain.
[20:46:05 CET] <jamrial> cehoyos: foo86 wrote libdcadec, a standalone library to decode dca
[20:46:16 CET] <j-b> cehoyos: no.
[20:46:17 CET] <jamrial> he then ported it to a native libavcodec decoder
[20:46:23 CET] <rcombs> cehoyos: he can only grant rights if he _owns_ the copyright, regardless of any "claims"
[20:46:27 CET] <j-b> cehoyos: one doesn't claim copyright.
[20:46:36 CET] <j-b> it's by default.
[20:46:37 CET] <cehoyos> But he does not claim he owns the copyright...
[20:46:43 CET] <j-b> he does.
[20:46:48 CET] <j-b> he claims the author rights.
[20:46:55 CET] <j-b> Which is the correct thing to do.
[20:47:01 CET] <cehoyos> So why is there no copyright notice? Without it, the license below is of course void.
[20:47:06 CET] <j-b> cehoyos: of course not.
[20:47:10 CET] <Daemon404> ... thats not how the law works
[20:47:12 CET] <rcombs> says who
[20:47:13 CET] <durandal_1707> ubitux: I think the showspectrum should use fft instead, because it doesn't have enough dynamic range for log scaler
[20:47:21 CET] <jamrial> there's plenty of files with no copyright notice in the tree, cehoyos
[20:47:31 CET] <cehoyos> And that is bad, so don't add more!
[20:47:43 CET] <j-b> cehoyos: the ONLY correct way to know the author on a line is to use git blame
[20:48:11 CET] <cehoyos> Why can nobody explain how the decoder was written? This is the more important question imo and will likely answer my other question.
[20:48:18 CET] <jamrial> i said it above
[20:48:19 CET] <rcombs> copyright notice hasn't been required since March 1, 1989
[20:48:28 CET] <j-b> rcombs: of course.
[20:48:39 CET] <durandal_1707> ubitux: even with flattop window I see leakage which isn't actually there with sine wave 
[20:48:41 CET] <cehoyos> j-b: You know very well that git blame can be fooled and cannot be used to the author of code.
[20:48:47 CET] <jamrial> he wrote it first as libdcadec: https://github.com/foo86/dcadec
[20:48:59 CET] <j-b> cehoyos: sorry, but no, you are incorrect.
[20:49:02 CET] <durandal_1707> stealers
[20:49:10 CET] <j-b> cehoyos: git blame will give you the author line.
[20:49:24 CET] <j-b> which is more important than the BS the copyright line of the file say.
[20:49:34 CET] <cehoyos> There is not copyrigh line...
[20:49:38 CET] <j-b> especially in authorship countries.
[20:49:59 CET] <cehoyos> j-b: atm we are not talking about the thieves...
[20:50:08 CET] <rcombs> affect all copyright notice does for you is inform the public of the copyright owner and year, which prevents an innocent-infringement defense
[20:50:09 CET] <jamrial> because he didn't want to add one. how are we still discussing this absurdity?
[20:50:16 CET] <jamrial> It's his code. he wrote it, he submitted it
[20:50:20 CET] <cehoyos> So how was it written?
[20:50:28 CET] <j-b> he wrote a library over 3 years
[20:50:36 CET] <jamrial> how about you follow the above link?
[20:50:37 CET] <wm4> cehoyos: with a text editor and a brain
[20:50:40 CET] <rcombs> (with a text editor)
[20:50:44 CET] <wm4> hands were probably also involved
[20:50:45 CET] <rcombs> oh yeah that too
[20:50:47 CET] <cehoyos> sorry, I hadn't realized this, let me see.
[20:51:00 CET] <wm4> j-b: 3 years?
[20:51:01 CET] <rcombs> probably some amount of reverse-engineering and reading of existing code and documentation
[20:51:08 CET] <j-b> wm4: maybe less, who cares?
[20:51:14 CET] <jamrial> the guy wrote a standalone decoder, ported it to libavcodec and now submitted it in a patch
[20:51:16 CET] <wm4> the original code was in D
[20:51:17 CET] <j-b> but seriously, copyright lines are useless.
[20:51:19 CET] <rcombs> the library is 7 years hand drawn
[20:51:23 CET] <jamrial> he didn't want to add a "copyright me" because he didn't want to
[20:51:26 CET] <jamrial> end of the discussion
[20:51:31 CET] <wm4> then he converted it to C after I told him how much D sucks
[20:51:37 CET] <j-b> what is important is authorship
[20:51:37 CET] <cehoyos> The first commit I see was in March, how do you know it was three years?
[20:51:45 CET] <j-b> cehoyos: it was in D, before.
[20:51:56 CET] <cehoyos> Can you point me to the repo?
[20:52:12 CET] <jamrial> he deleted it
[20:52:27 CET] <jamrial> it was also in that github account, but removed it once he ported it to c and renamed it to dcadec
[20:52:35 CET] <wm4> maybe you still can find it on github as a fork
[20:52:52 CET] <wm4> or, you know, just ask him
[20:53:49 CET] <jamrial> it was called xlldec when it was written in D i think
[20:54:04 CET] <cehoyos> Has anybody seen the reference decoder? Kieran?
[20:54:18 CET] <j-b> https://github.com/foo86/xlldec
[20:54:25 CET] <j-b> Kieran and Kostya
[20:54:41 CET] <cehoyos> kierank?
[20:55:04 CET] <cehoyos> j-b: Do you still have the repo?
[20:55:06 CET] <j-b> cehoyos: you're afraid that there are copyright infringement in this decoder?
[20:55:18 CET] <cehoyos> Afraid is the wrong word.
[20:55:28 CET] <j-b> very afraid?
[20:55:31 CET] <jamrial> this is absurd
[20:55:32 CET] <cehoyos> But I want to avoid FFmpeg becoming avconv
[20:55:38 CET] <wm4> wat
[20:55:39 CET] <jamrial> this is beyond absurd
[20:55:52 CET] <cehoyos> You forgot all the copyright violations already?
[20:56:22 CET] <kierank> cehoyos: I have not seen the reference decoder
[20:56:24 CET] <kierank> meuuh has probably
[20:56:29 CET] <jamrial> cehoyos, the guy wrote the decoder long ago, made it public on his github repo, and now ported it as a native libavcodec decoder
[20:56:32 CET] <jamrial> you're paranoid
[20:56:46 CET] <j-b> Seriously, Carl, one day, I must explain you what is the copyright violation.
[20:57:03 CET] <cehoyos> That's really good to hear, I am just surprised that I had never heard about the decoder before March.
[20:57:19 CET] <j-b> and notably about Urheberrecht
[20:57:26 CET] <jamrial> because that's when he ported it to C and created the libdcadec repo
[20:57:36 CET] <cehoyos> j-b: That is exactly the issue with you: You believe what a bunch of liars tell you!
[20:57:54 CET] <jamrial> ....
[20:57:57 CET] <j-b> cehoyos: no. A contrarion from you, I did studies of IP law.
[20:58:02 CET] <cehoyos> jamrial: Where can I see that it was written long ago?
[20:58:11 CET] <j-b> A contrario from you, I worked with lawyers, many times.
[20:58:30 CET] <j-b> and gave talks about copyrights, licensing and patents
[20:58:33 CET] <jamrial> google xlldec. maybe it was forked
[20:58:38 CET] <j-b> it was not
[20:58:47 CET] <cehoyos> I am not talking about the law (that I also studied) but about known copyright violators you still support after years, which I consider a pity
[20:58:51 CET] <jamrial> or as wm4 said, just ask the guy for it
[20:58:59 CET] <j-b> cehoyos: show me one copyright violation.
[20:59:02 CET] <j-b> cehoyos: show me one.
[20:59:06 CET] <durandal_1707> atomnuker: postimage.org/image/xaqqq1ji7
[20:59:06 CET] <cehoyos> I am curious how you knew about it.
[20:59:09 CET] <rcombs> if copyright notices would make you feel better I'm sure he'll add them
[20:59:39 CET] <j-b> copyright notices are useless.
[21:01:47 CET] <rcombs> I wonder how many of the files in ffmpeg have copyright that actually matches their notices
[21:01:53 CET] <rcombs> very few, I'd expect
[21:02:41 CET] <j-b> of course
[21:02:41 CET] <rcombs> since most are collaborative works with authors who aren't listed, amongst other discrepancies
[21:02:47 CET] <j-b> exactly.
[21:02:51 CET] <jamrial> tons of files still mention fabrice bellard
[21:03:09 CET] <j-b> FFmpeg is a collaborative work, based on Author-rights. (not copyright)
[21:03:22 CET] <wm4> I keep wondering what's the point of names in copyright headers, but I'd also be afraid to remove them
[21:03:26 CET] <rcombs> I wonder if any credit people who didn't actually contribute because of copypaste
[21:03:29 CET] <rcombs> in new files
[21:03:44 CET] <cehoyos> 4f979418c723652ad4e43115118c57a44bd46b52 comes to mind...
[21:03:56 CET] <atomnuker> durandal_1707: looks nice (if you swap the time and frequency axis)
[21:04:01 CET] <j-b> wm4: it's to make people afraid when they take one file.
[21:04:35 CET] <j-b> in all files, you should put "Copyright the FFmpeg project"
[21:04:44 CET] <durandal_1707> atomnuker: that's with horizontal orientation like baudline
[21:06:20 CET] <cehoyos> j-b: There is no "FFmpeg project"
[21:06:28 CET] <atomnuker> btw if the width and height of avctx can change during decoding could the pixel format change as well?
[21:06:38 CET] <cehoyos> It can.
[21:06:40 CET] <j-b> cehoyos: write "FFmpeg authors" then
[21:06:56 CET] <wm4> atomnuker: yes
[21:07:08 CET] <atomnuker> thanks
[21:13:45 CET] <wm4> j-b: can I ask a random copyright question? I want to relicense mpv to LGPL, but being MPlayer based maybe this is too hard... what if I write a new player from scratch (potentially copy some lines of code I've written for mpv), and add back some bits of LGPL (re-)licensed mplayer code, is that a copyright violation?
[21:14:12 CET] <j-b> wm4: of course it's not.
[21:14:49 CET] <wm4> copyright is strange
[21:14:53 CET] <j-b> It is not.
[21:14:57 CET] <j-b> wm4: it's very simple.
[21:15:23 CET] <j-b> it just goes against what we, coders, think of it.
[21:15:23 CET] <cone-301> ffmpeg 03Andreas Cadhalpun 07master:713654d9d3a6: get_bits: add get_bitsz for reading 0-25 bits
[21:15:23 CET] <cone-301> ffmpeg 03Andreas Cadhalpun 07master:43ff4aed26cb: lavc: use get_bitsz to simplify the code
[21:15:23 CET] <cone-301> ffmpeg 03Andreas Cadhalpun 07master:40eb2531b279: ffmdec: reset packet_end in case of failure
[21:15:27 CET] <rcombs> collaborative works are complicated!
[21:15:38 CET] <wm4> (they say the same about differential equations)
[21:15:45 CET] <j-b> wm4: first, in FFmpeg and MPlayer, copyright is of NO MATTER.
[21:16:03 CET] <cehoyos> wm4: If mpv is based on MPlayer (I don't know if it is), I don't think relicensing will be possible: There were too many authors and you will not be able to reach them all.
[21:16:10 CET] <rcombs> and international differences in copyright/author's rights law is weird!
[21:16:19 CET] <j-b> Because France, Austria, Switzerland and Germany are Authorship-countries.
[21:16:25 CET] <cehoyos> Nico is an example of an author who in the past was against relicensing.
[21:16:46 CET] <wm4> cehoyos: I know, but I guess there's only 20% of mplayer code left in mpv (although I'd prefer relicensing mplayer itself)
[21:16:48 CET] <rcombs> so rewrite all his code?
[21:17:05 CET] <j-b> And some rights are untransferable.
[21:17:17 CET] <Compn> i like all of those countries that deny the ability to transfer a copyright
[21:17:24 CET] <cehoyos> wm4: This is the "usual" misconception (I don't think anybody of the dark side really believes this, but this is how they argue):
[21:17:24 CET] <Compn> which means 'public domain' cannot exist
[21:17:31 CET] <wm4> cehoyos: the most significant part seems to be that mpv still follows some basic structure/architecture of mplayer
[21:17:34 CET] <cehoyos> It doesn't matter how many percent were rewritten;-(
[21:17:56 CET] <wm4> cehoyos: it matters for relicensing effort
[21:18:00 CET] <j-b> wm4: if you base your code from another one, _even_ if you rewrite everything, it's not enough.
[21:18:15 CET] <wm4> j-b: so ffmpeg is european?
[21:18:18 CET] <j-b> wm4: yes.
[21:18:42 CET] <rcombs> cleanroom!
[21:18:50 CET] <cehoyos> No: If code is based on MPlayer author, the original authors would have to be asked.
[21:18:57 CET] <cehoyos> And I doubt you can reach them all.
[21:19:04 CET] <j-b> cehoyos is correct here.
[21:19:11 CET] <cehoyos> Remember what happened when they wanted to relicense x11grep:
[21:19:16 CET] <rcombs> so how'd it work for VLC?
[21:19:22 CET] <j-b> rcombs: read my blog.
[21:19:29 CET] Action: rcombs re-reads
[21:19:34 CET] <wm4> well my approach would have been: write a new code base until the most basic things work (but I'd cheat and reuse some code _I_'ve written within mpv), and then copy back larger LGPL based parts (this would for example be the opengl renderer, which is already LGPL)
[21:19:40 CET] <jamrial> i remember a similar issue relicensing yadif
[21:19:50 CET] <j-b> wm4: yes, that would work.
[21:20:15 CET] <j-b> but I'd suggest be really clear about splitting the parts you import.
[21:20:26 CET] <cehoyos> They asked everybody including Goofy, Waldorf and Statler and me but not the original authors...
[21:20:45 CET] <cehoyos> It was different with yadif though: *Everybody* was asked and answered.
[21:20:47 CET] <wm4> cehoyos: michael?
[21:20:53 CET] <j-b> because original authors can claim you took some ideas.
[21:21:03 CET] <cehoyos> What about him?
[21:21:08 CET] <wm4> j-b: yes, that's the part that worries me
[21:21:16 CET] <wm4> that such abstract things are copyrightable
[21:21:18 CET] <j-b> wm4: also remember something: "there is no trivial contribution"
[21:21:36 CET] <cehoyos> This is what happened for libswscale and delayed it for more than a year iirc.
[21:21:38 CET] <j-b> a one-liner can be protected.
[21:21:49 CET] <wm4> j-b: doesn't it depend on the legislature?
[21:21:54 CET] <j-b> wm4: no.
[21:21:56 CET] <cehoyos> The dark side disagrees (heavily)
[21:22:08 CET] <wm4> the US knows fair-use and such
[21:22:16 CET] <rcombs> >And then, I deleted some code, reverted some commits, rewrote some and or isolated code from them in a separate files to reduce the future impact.
[21:22:42 CET] <cehoyos> wm4: What about Michael?
[21:22:49 CET] <j-b> wm4: fair-use does not apply in software code, except education and such.
[21:23:08 CET] <j-b> wm4: still, a rewrite would be better. And then you import very defined parts.
[21:23:11 CET] <wm4> cehoyos: I thought you talked about yadif, of which he's the author
[21:23:18 CET] <cehoyos> No, x11grep
[21:23:53 CET] <wm4> j-b: ok... what about Mozilla, who said only 95% of all contributors matter?
[21:24:02 CET] <wm4> (other projects used this too)
[21:25:14 CET] <ubitux> even for a bug fix a one liner can be protected? what if it's a necessary rename of symbol use because of api changes for example?
[21:25:18 CET] <wm4> "UPDATE 2007-02-04: Someone who works with many lawyers on free software copyright issues later told me that it is not necessary to get permission from 100% of the copyright holders. It would suffice if there was permission from the copyright holders of 95% of the source code and no objections from the holders of the other 5%."
[21:25:55 CET] <Compn>  <jamrial> tons of files still mention fabrice bellard <~~~ whats your problem with fabrice? :P
[21:26:05 CET] <wm4> j-b: also, the interesting question is: what if the one-liner is later removed? what if it's rewritten by 50%? what if it got rewritten step by step so that nothing is left?
[21:26:11 CET] <Compn> tons of files still have his commits (or did before cosmetics)
[21:26:20 CET] <wm4> Compn: nothing, it's just that he did nothing since over a decade or so
[21:26:22 CET] <wm4> *for
[21:26:38 CET] <Compn> wm4 : copyright does not expire (at least in usa) until 90 years after author death lol
[21:26:42 CET] <wm4> but I admit sometimes when git blaming, I still end up at one of his commits
[21:27:14 CET] <rcombs> the Copyright Ship of Theseus
[21:27:55 CET] <Compn> i studied many copyright cases over the years, from SCO v linux to napster to google books v publishers to riaa vs everyone...
[21:28:06 CET] Action: rcombs replaces the right side of an assignment statement, then replaces the left side of the statement, then retypes the = sign
[21:28:07 CET] <Compn> i'm no expert :P
[21:28:21 CET] <rcombs> >riaa vs everyone
[21:28:24 CET] <rcombs> not even an exaggeration
[21:28:42 CET] <rcombs> Petition for Class Action against All You Fuckers
[21:29:11 CET] <wm4> if I commit something non-trivial, and it reappears somewhere else without credit to me, is that a copyright violation?
[21:29:23 CET] <wm4> probably yes, but the same with something more trivial? like a single word?
[21:29:27 CET] <rcombs> Notice to Fuck this Court and everything It stands for
[21:29:30 CET] <Compn> they have sued a magnitude of people.
[21:29:35 CET] <wm4> what about a single character?
[21:29:46 CET] <wm4> I can only conclude copyright has nothing to do with text/pattern matching
[21:29:51 CET] <durandal_1707> ubitux: so fine to switch to fft?
[21:29:55 CET] <rcombs> wm4: in the former case it depends on the license
[21:30:01 CET] <wm4> rather, it's up to the judge's mood
[21:30:03 CET] <ubitux> durandal_1707: no opinion, probably
[21:30:10 CET] <ubitux> durandal_1707: iirc i just ported code from ffplay
[21:30:15 CET] <rcombs> ~everything's a remix~
[21:30:30 CET] <rcombs> ~fair use is poorly-defined~
[21:30:30 CET] <jamrial> Compn: none, just saying that the copyright line has in a lot of cases no meaning regarding the contents of each file
[21:30:32 CET] <ubitux> durandal_1707: yeah code is initially from ffplay rdft code
[21:30:35 CET] <wm4> spam? https://trac.ffmpeg.org/wiki/MaintainingFFmpeg?action=diff&version=6
[21:30:35 CET] <Compn> wm4 : someone said once that equasions could not be copyrighted. likewise tables (only the number tables we are talking about) or machine generated tables... something like that. but yes up to a judge haha
[21:30:40 CET] <j-b> wm4: yes, that's why it's hard.
[21:31:22 CET] <j-b> wm4: Mozilla is a different case, because they have an entity, and thus a collaborative work
[21:31:42 CET] <jamrial> wm4: yeah, looks like spam
[21:31:48 CET] <Compn> jamrial : sure. i'm guessing those are left in for "historical purposes"
[21:32:04 CET] <Compn> like naming a hospital after someone. 
[21:32:06 CET] <j-b> wm4: but yes, the 95% rules is BS, and is easily attackable.
[21:32:23 CET] <wm4> it's often cited
[21:32:31 CET] <j-b> It does not make it right.
[21:32:37 CET] <smarter> j-b: didn't you only get approval from 99% of of the authors or something for VLC ?
[21:32:47 CET] <j-b> smarter: nope. 100%.
[21:32:52 CET] <smarter> wow
[21:33:01 CET] <j-b> smarter: which is why some parts are not LGPL
[21:33:02 CET] <Compn> j-b had to rewrite parts of vlc that did not get authors permission.
[21:33:07 CET] <Compn> iirc
[21:33:11 CET] <j-b> like the BDA module
[21:33:20 CET] <j-b> and as Compn says, I did stuff like that.
[21:33:27 CET] <smarter> okay
[21:33:35 CET] <Compn> and by 'rewrite' i mean 'write from scratch' not just mess about with the old code :P
[21:33:37 CET] <smarter> so what about dead people? Do you have to rewrite their code?
[21:33:40 CET] <rcombs> ^CLEANROOM^
[21:33:42 CET] <j-b> Like: clean room reimplementation of a function, with witnesses, and with 3 people coding.
[21:33:55 CET] <j-b> and them, not having internet access.
[21:33:59 CET] <Compn> smarter : yes.
[21:34:12 CET] <smarter> copyright sucks
[21:34:15 CET] <j-b> smarter: I had to go to see one dad, who had lost his child
[21:34:17 CET] <Compn> their code is their property, estate, goes to probate court (in usa)
[21:34:24 CET] <j-b> to ask him to relicensiate.
[21:34:29 CET] <j-b> it was horrible.
[21:34:29 CET] <smarter> damn
[21:34:38 CET] <Compn> wow.
[21:34:48 CET] <j-b> the guys thought I was going to make millions out of his son's code.
[21:35:13 CET] <Compn> j-b : you have nt made millions off vlc yet? :P
[21:35:13 CET] <j-b> that was sad.
[21:35:23 CET] <j-b> Compn: if I wanted to make money, I would have.
[21:35:33 CET] <Compn> youtube is making money off mencoder :D
[21:35:37 CET] <j-b> it's more fun to be poor and troll with you guys.
[21:35:44 CET] <smarter> j-b: <3
[21:36:09 CET] <j-b> Compn: seriously. Imagine installing Chrome or the Ask toolbar when you install VLC.
[21:36:17 CET] <j-b> opt-out.
[21:36:30 CET] <rcombs> I really should go to VDD this year
[21:36:38 CET] <Compn> its fun, go
[21:36:40 CET] <smarter> j-b: and opt-out everytime you upgrade VLC!
[21:37:08 CET] <Compn> j-b : i dont know how much the opt-out stuff nets a person. it must be a lot though. mozilla does it, flash player does it
[21:37:25 CET] <smarter> mozilla does it?
[21:37:28 CET] Action: rcombs opts out of flash player
[21:37:34 CET] <wm4> ads during video playback, yummy
[21:37:37 CET] <Compn>  mozilla does it with the default search engine, yes
[21:37:55 CET] <smarter> okay, that's a bit different
[21:38:01 CET] <Compn> is it really ?
[21:38:13 CET] <rcombs> that's a setting, not a piece of crapware
[21:38:19 CET] <j-b> Compn: it was 1$/install.
[21:38:21 CET] <cehoyos> 6c1df1f2 is the example I searched for, sorry for the delay.
[21:38:23 CET] <Compn> yahoo search is pretty crap :P
[21:38:25 CET] <cehoyos> But that makes two;-)
[21:38:27 CET] <rcombs> and you can change it once and it doesn't get reset on reinstall
[21:38:46 CET] <rcombs> erm, on upgrade
[21:38:58 CET] <wm4> cehoyos: "sgi: encode images with 4 channels at 8 and 16 bits"
[21:38:59 CET] <wm4> ?
[21:39:26 CET] <cehoyos> Yes, the other one is better because it was an intentional copyright violation, this one is more "avconv has no reviews"
[21:39:35 CET] <Gramner> you should add opt-out with double-negative phrasing of a dozen dubious programs/toolbars. on page 7 after 6 legit "i agree" pages
[21:39:53 CET] <wm4> cehoyos: well we don't care about your hate-obsession with Libav 
[21:40:00 CET] <j-b> Gramner: yes.
[21:41:38 CET] <cehoyos> Sorry, j-b asked...
[21:41:49 CET] <j-b> wm4: you should fork from VLC, it'd be easier :)
[21:42:10 CET] <cehoyos> But at least it is based on reciprocity;-)
[21:45:01 CET] <wm4> j-b: actually, before I forked mplayer2, I considered using/improving vlc, but it somehow didn't work out
[21:53:07 CET] <prelude2004c> hey guys.. this make any sense "  [h264 @ 0x26bcd20] Hardware accelerated decoding with frame threading is not supported "
[21:53:09 CET] <prelude2004c> what does that mean ?
[21:53:39 CET] <wm4> prelude2004c: set the thread count to 1
[21:53:52 CET] <wm4> -threads 1 on ffmpeg CLI maybe
[21:57:42 CET] <J_Darnley> Someone with a trac account: I think some spam just added here https://trac.ffmpeg.org/wiki/MaintainingFFmpeg?action=diff&version=6
[21:59:28 CET] <rcombs> I'll get it
[22:03:25 CET] <rcombs> though I don't think I can ban the user
[22:07:59 CET] <cehoyos> I removed the user
[22:16:26 CET] <J_Darnley> Yeah!  Justice!
[22:21:49 CET] <cehoyos> I wonder why the change can't be undone instead of reverted...
[22:23:54 CET] <prelude2004c> hey guys. having trouble with vdpau... someone told me to decode using " vc ffh264vdpau   " . not sure where to put that.. i am using ffmpeg mpeg2video sources seem to decode ok and then i can transcode it to something else.. but h264 sources don't seem to decode at all i am using M4000 card running latest 258.16 version . anyone have any ideas ?
[22:24:57 CET] <cehoyos> Should be undone now;-)
[22:25:29 CET] <J_Darnley> prelude2004c: is that supposed to be -vcodec on the command line?
[22:28:10 CET] <prelude2004c> yes i run that in a script
[22:28:19 CET] <prelude2004c> my source is a UDP:// source
[22:28:58 CET] <J_Darnley> then you put it before the "file" you want to use it with
[22:31:40 CET] <prelude2004c> what -vcodec do i put ?
[22:32:08 CET] <J_Darnley> Are we going in circles?  What did you just say?
[22:38:13 CET] <prelude2004c> ahh i get what you said .. but i tried to use " Unknown decoder 'ffh264vdpau' "
[22:38:25 CET] <prelude2004c> its used in ffmpeg ?
[22:43:03 CET] <philipl> That's the mplayer codec name.
[22:54:06 CET] <prelude2004c> yup correct.. so i dont know why darnley thought i should use it
[22:54:15 CET] <prelude2004c> anyways, i am super super stuck
[22:54:26 CET] <prelude2004c> i don't know what to do :(
[22:58:18 CET] <cone-301> ffmpeg 03Carl Eugen Hoyos 07master:ae9f2e6f2813: lavfi/drawtext: Fix microsecond display.
[23:12:22 CET] <cone-301> ffmpeg 03Paul B Mahol 07master:14caf9667e3f: avfilter/avf_showspectrum: switch to FFT
[23:12:23 CET] <cone-301> ffmpeg 03Paul B Mahol 07master:0a451082c774: avfilter/avf_showspectrum: finally fix log scaler
[23:19:16 CET] <Compn> prelude2004c : upgrade all vdpau libs
[23:19:31 CET] <Compn> and u pgrade your distro, because i'm assuming you are on an old ubuntu version 
[23:19:42 CET] <Compn> and update your nvidia binary driver
[23:21:10 CET] <fritsch> Compn: i told him > 10 days ago ...
[23:26:34 CET] <Compn> prelude2004c : are you listening ?
[23:41:45 CET] <durandal_170> cehoyos: what are you talking about, what dark side?
[23:46:05 CET] <cone-301> ffmpeg 03Andreas Cadhalpun 07master:b4b13848dec5: vorbisdec: reject channel mapping with less than two channels
[00:00:00 CET] --- Mon Jan  4 2016