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

[burek]

[01:05:22 CEST] <cone-989> ffmpeg 03Christophe Gisquet 07master:f94af8d32ae3: fate: add chroma position scale test
[04:31:36 CEST] <cone-109> ffmpeg 03Ganesh Ajjanagadde 07master:07cd8d5676a7: avcodec/x86/cavsdsp: silence -Wunused-variable on --disable-mmx
[05:00:29 CEST] <cone-109> ffmpeg 03Ganesh Ajjanagadde 07master:7179add427f3: avcodec/ac3enc: use long long after switch to 64 bit bitrate
[09:11:59 CEST] <durandal_1707> too much private talk in underground
[10:00:00 CEST] <mateo`> hello there o/ I'm looking at implementing a decoder based on mediacodec (for hw accel) on the android platform. I'm wondering what is the state of the libstagefright decoder.
[10:01:26 CEST] <mateo`> or is there any ongoing worsk toward supporting hw accel decoders on android before i start
[10:03:38 CEST] <JEEB> the things I've heard of the libstagefright decoder...
[10:05:36 CEST] <nevcairiel> the author himself once said it should've never been commited, iirc :d
[10:09:19 CEST] <fritsch> we remove it from kodi completely ...
[10:09:30 CEST] <fritsch> and only keep mediacodec
[10:10:02 CEST] <wbs> mateo`: don't even bother looking at libstagefright, just go for mediacodec
[10:10:06 CEST] <mateo`> and i'm also still a bit undecided which kind of outputs i will support from mediacodec, main memory buffers / gl surface (meaning api >= 18, gl and hwaccel api i guess), both (would be best but i'm afraid of dealing again with all kind of  pixel formats and in particular nv12 variants and buggy stride alignement ... as opposed to the gl output where you don't have to deal with that crap and keep it
[10:10:08 CEST] <mateo`> simple) 
[10:10:36 CEST] <wbs> it is available on all modern devices from the last few years anyway, while libstagefright will give you ABI issues (different ABI for every android release etc)
[10:13:42 CEST] <fritsch> mateo`: https://github.com/xbmc/xbmc/blob/master/xbmc/cores/dvdplayer/DVDCodecs/Video/DVDVideoCodecAndroidMediaCodec.cpp
[10:13:43 CEST] <mateo`> supporting gl surface outputs would also means that the application will have to provive a java class implementing the OnFrameAvailableListener interface
[10:13:56 CEST] <fritsch> if you want to look for known workarounds see above
[10:14:19 CEST] <fritsch> rendering is a major thing as for 4k stuff one cannot simply do a lot of copying
[10:14:34 CEST] <mateo`> fritsch: thanks (i already looked at that code, i'm also familair with the mediacodec supports from gstreamer as i've worked quite a bit on it)
[10:14:52 CEST] <fritsch> ah okay
[10:15:03 CEST] <wbs> mateo`: in any case, just pretend like the libstagefright decoder doesn't exist
[10:15:10 CEST] <mateo`> ok :)
[10:15:16 CEST] <fritsch> we have some other pending patches which solve the the zero-copy rendering things
[10:15:45 CEST] <fritsch> mateo`: if there are further detailed questions I can give you contacts to davilla and koying which have implemented this mediacodec stuff for kodi
[10:16:10 CEST] <mateo`> i've also a pending patch for gstreamer which enables the zero copy path
[10:16:24 CEST] <fritsch> okay
[10:17:03 CEST] <fritsch> same persistent window / surface render "hack"?
[10:18:25 CEST] <mateo`> well it's not a true zero copy, it renders the oes texture from the surface to a proper gl texture that can be used later for display or any transformations
[10:18:45 CEST] <fritsch> jep
[10:19:11 CEST] <fritsch> would be nice to have such a hwaccel directly in ffmpeg
[10:19:21 CEST] <fritsch> so good luck with your work
[10:19:42 CEST] <mateo`> the oes texture to 2d texture conversion is done via a framebuffer + the proper sampling shader
[10:21:19 CEST] <mateo`> i'm wondering if it reasonnable to only supports surface output (involving external depending on a external java class)?
[10:21:53 CEST] <mateo`> meaning it will only work on device >= 4.3
[10:22:19 CEST] <wbs> surface output is available since 4.1, isn't it?
[10:24:18 CEST] <wbs> surface input came in 4.3, and being able to rely on the output yuv formats
[10:24:33 CEST] <fritsch> i think that's okay - really
[10:24:42 CEST] <wbs> (but perhaps some of the glsurfacetexture things also were added then?)
[10:24:48 CEST] <wbs> in any case it shouldn't really matter IMO
[10:24:48 CEST] <fritsch> in regard to multimedia >= 5.0 would also be fine
[10:25:25 CEST] <mateo`> wbs: my bad, it's available in 4.1
[10:25:33 CEST] <wm4> doesn't mediacodec have an async API? (I don't know)
[10:26:09 CEST] <mateo`> wm4: since 5.0 you can provide a callback
[10:26:14 CEST] <mateo`> but it's already kind of async
[10:27:50 CEST] <mateo`> you feed input buffers, you poll output buffers, if you get an output buffer, you render it, the surface will tell you through a callback when the frame (texture) is available
[10:29:08 CEST] <wm4> I wonder if this will have similar problems like mmal
[10:29:24 CEST] <mateo`> wm4: mmal ?
[10:30:04 CEST] <wm4> that's the API the RPI uses
[10:30:37 CEST] <wm4> it's fully async, and made me almost cry once every while (because connecting the async API to lavc's sync one is hard)
[10:31:20 CEST] <mateo`> is mmal a layer above omx ?
[10:32:50 CEST] <wm4> good question
[10:33:04 CEST] <wm4> not really, but they're similar, and the underlying code handles both
[10:33:27 CEST] <ubitux> need async for vtb as well :(
[11:15:29 CEST] <kierank> saste: do you know what the status of outreachy is
[11:16:05 CEST] <saste> kierank, we're still asking for money
[11:16:19 CEST] <saste> otherwise we will use the SPI money (at least in part), that's to be decided
[11:16:44 CEST] <kierank> Ok
[12:45:08 CEST] <cone-687> ffmpeg 03Paul B Mahol 07master:964a9badcc03: avfilter/af_tremolo: make it bit-exact with sox effect of same name
[13:39:31 CEST] <fritsch> mateo`: ping
[13:39:38 CEST] <fritsch> mateo`: https://github.com/xbmc/xbmc/pull/7689 <- this is what I talked about before
[13:40:12 CEST] <fritsch> basically: rather than passing a surface texture to mediacodec (i.e. android pseudo-surface backed by an EGL texture), you can pass a SurfaceView.
[13:40:43 CEST] <fritsch> issue with that: the surface must be handeld by android itself (SurfaceFlinger)
[13:40:58 CEST] <fritsch> and from there it needs to be passed in our case kodi in your case to ffmpeg via java code
[13:41:03 CEST] <fritsch> :-) not sure if one likes that
[13:41:47 CEST] <fritsch> mateo`: if you want / need futher infos, koying at kodi.tv is available for discussion
[13:41:53 CEST] <wm4> that doesn't sound ideal
[13:42:11 CEST] <wm4> if I had mediacodec support, I'd definitely want to involve the opengl renderer
[13:42:47 CEST] <fritsch> if you want to copy your surfaces arround :-)
[13:42:50 CEST] <fritsch> then that's your way to go
[13:42:56 CEST] <fritsch> but think of 4k at 60p content
[13:43:11 CEST] <fritsch> here even VAAPI - to speak of the glxCopySurface which is used everywhere is too slow
[13:44:30 CEST] <wm4> yeah, but VAAPI has EGL support now
[13:44:35 CEST] <fritsch> yeah now
[13:44:44 CEST] <fritsch> and only kodi and you(?) implement it?
[13:44:51 CEST] <fritsch> as it's only in mesa 11
[13:44:53 CEST] <fritsch> which is 10 days old?
[13:44:59 CEST] <wm4> I don't (still waiting for arch or so to add mesa 11)
[13:45:28 CEST] <fritsch> on android we don't have such a thing yet
[13:45:31 CEST] <iive> they haven't?
[13:45:41 CEST] <fritsch> though the faked EGL texture sounds a bit similar
[13:46:13 CEST] <fritsch> it is in testing
[13:46:16 CEST] <fritsch> https://www.archlinux.org/packages/testing/i686/mesa/
[13:46:22 CEST] <fritsch> wm4: so - go go go :-)
[14:16:13 CEST] <mateo`> fritsch: thanks
[14:26:37 CEST] <kierank> BBB: ping
[14:26:39 CEST] <kierank> atomnuker: ping
[14:26:46 CEST] <kierank> and others who were on obe2
[14:29:20 CEST] <durandal_1707> what was on obe2
[14:29:51 CEST] <kierank> it was a machine for doing dev work
[14:30:31 CEST] <BBB> kierank: pong
[14:30:40 CEST] <kierank> BBB: can you send me your public key
[14:30:46 CEST] <kierank> and username you want to use
[14:30:48 CEST] <BBB> obe2 was like magic, its like walking into a candy store, except that its free
[14:30:52 CEST] <BBB> ok
[14:31:01 CEST] <BBB> ty
[14:31:53 CEST] <atomnuker> kierank: pong? still no idea what obe2 is
[14:31:59 CEST] <kierank> atomnuker: it's a development machine
[14:32:40 CEST] <atomnuker> go on...
[14:33:56 CEST] <BBB> atomnuker: its a beefy server that we can sometimes use for performance experiments or otherwise stuff that is cpu-intensive and needs a low-noise machine (i.e. one w/o irc and web browsing)
[14:34:40 CEST] <BBB> plus it had avx, which most of us didnt have, so we could use it to test avx code
[14:35:27 CEST] <atomnuker> nice, so you want my public key?
[14:38:04 CEST] <kierank> yes send me an email (kierank[at]obe.tv
[14:38:43 CEST] <atomnuker> ssh or gpg?
[14:39:08 CEST] <atomnuker> that's a stupid question, sorry
[14:39:35 CEST] <kierank> ssh
[14:46:49 CEST] <durandal_1707> kierank: how much GHz and cores?
[14:46:56 CEST] <kierank> 3.4ghz 4 cores haswell
[14:47:17 CEST] Action: kierank gets lunch then adds keys
[14:48:36 CEST] <BBB> haswell \o/
[14:48:37 CEST] <BBB> yay
[14:55:39 CEST] <Compn> can i put mingw build system on there for building some mplayer/ffmpeg kierank ? :P
[14:55:50 CEST] <Compn> (also means i need an account)
[15:04:06 CEST] <kierank> dunno
[15:04:11 CEST] <kierank> mumble mumble patents etc
[15:09:00 CEST] <durandal_1707> no mplayer involved
[15:10:28 CEST] <kurosu> I think michaelni and nevcairiel have 6-cores machines (haswell-E?)
[15:10:53 CEST] <nevcairiel> i do, but its not a build box, its my desktop system :d
[15:11:02 CEST] <kurosu> I'm hesitating between this (they are usually older archs though) and a new skylake one
[15:11:05 CEST] <kurosu> same
[15:11:22 CEST] <kurosu> but it'll end up being used to muck around ffmpeg
[15:12:05 CEST] <kurosu> I bet I could get so much more mileage^W faster compilation by running a virtualized linux system
[15:12:37 CEST] <kurosu> the 6 cores only make sense for compilation and compression (and the later I don't really do)
[15:14:20 CEST] <michaelni> my haswell is running fate clients under various VMs not really development either
[15:16:12 CEST] <BBB> michaelni: you really should consider coming to vdd or some event like that one day ...
[15:16:16 CEST] <Gramner> I've been running a dedicated machine with a 4core/8thread haswell for more than 1.5 years for compilation/benchmarking and stuff, so no external noise
[15:16:32 CEST] <BBB> michaelni: you were missed
[16:15:29 CEST] <BtbN> So... GPU-OpenCL on Intel is aparently bad.
[16:15:48 CEST] <BtbN> It doesn't support doubles, and after downgrading to floats it's much slower than the CPU variant with doubles.
[16:17:01 CEST] <nevcairiel> are you sure its actually running on the GPU
[16:17:08 CEST] <nevcairiel> they used to have CPU emulation for that as well
[16:17:11 CEST] <nevcairiel> well probably still do
[16:17:28 CEST] <BtbN> They have two independend OpenCL drivers
[16:17:44 CEST] <BtbN> the CPU one actualy does make it run faster than the normal implementation.
[16:18:02 CEST] <BtbN> The GPU one only does half the fps than the normal one.
[16:18:10 CEST] <nevcairiel> What kind of GPU are you testing one? Some low-end NUC again?
[16:18:16 CEST] <BtbN> My HSW laptop
[16:18:41 CEST] <BtbN> It should definitely have the capabilities to run that stuff on the GPU
[16:24:39 CEST] <BtbN> Hm, I should fixing all those warnings in libavutil/opencl.c
[16:25:30 CEST] <__gb__> BtbN, and your OCL-GPU runtime is beignet or the MSDK supplied one?
[16:26:09 CEST] <BtbN> beignet
[16:26:19 CEST] <BtbN> latest master + llvm 3.7 compat patch
[16:26:44 CEST] <BtbN> There is a second one for linux?
[16:29:14 CEST] <Daemon404> g 31
[16:30:11 CEST] <__gb__> hmm, forget about it, should have objdump first :)
[16:32:17 CEST] <kurosu> honey, please grab some bread on the way back
[16:32:25 CEST] <__gb__> https://software.intel.com/en-us/articles/opencl-drivers#lingpu -- I am safe :)
[16:32:50 CEST] <kurosu> oh, so that wasn't a wrong window input :D
[16:41:45 CEST] <kierank> kurosu: ping
[16:42:52 CEST] <kurosu> kierank, pong ?
[16:43:20 CEST] <kierank> do you want an account on the new obe2
[16:44:40 CEST] <kurosu> oh, right. not really sure, as I don't plan to do too much heavy dev nowadays
[16:44:53 CEST] <kurosu> and I'm planning an upgrade w/ an avx2 cpu
[16:45:25 CEST] <kierank> ok, it has avx2
[16:45:25 CEST] <kurosu> thanks for proposing, but like a git write account, I have some weird lazyness
[16:45:30 CEST] <kierank> :)
[16:47:45 CEST] <kurosu> last time, I let such a proposal die because I presumably sent in the wrong sha key and couldn't be arsed to fix it
[16:48:11 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/opencl.c;hb=HEAD#l40 this volatile seems strange. Why is it there? If at all, shouldn't it be moved further to the right, so it makes the pointer volatile, and not the unterlying struct?
[16:48:20 CEST] <BtbN> It causes a whole bunch of warnings.
[16:49:48 CEST] <wm4> lol volatile pointers to mutexes
[16:49:52 CEST] <wm4> now if that doesn't look fishy
[16:50:09 CEST] <nevcairiel> its the opencl code
[16:50:13 CEST] <nevcairiel> is  born out of dead fish guts
[16:50:21 CEST] <Daemon404> so much code for so little... useuflness
[16:50:25 CEST] <Daemon404> oh well.
[16:50:32 CEST] <Daemon404> just pretend it isnt there
[16:50:33 CEST] <wm4> ah it simulates static initialized mutexes by CASing a mutex ptr
[16:50:45 CEST] <wm4> (because Windows)
[16:50:47 CEST] <BtbN> So... why doesn't it just
[16:50:47 CEST] <nevcairiel> anyway yes, the volatile should probably move
[16:50:48 CEST] <BtbN> oh
[16:50:50 CEST] <BtbN> great...
[16:51:16 CEST] <nevcairiel> pthread_mutex_t is opaque, and you really want the pointer to be volatile
[16:51:22 CEST] <nevcairiel> not the value it pooints to
[16:51:24 CEST] <nevcairiel> right?
[16:51:40 CEST] <kurosu> I'd suggest some attribute to that pointer just for the combo factor
[16:51:44 CEST] <BtbN> Definitely, looking at the warnings it procudes
[16:51:46 CEST] <wm4> the avpriv_atomic API wants volatile pointers
[16:51:50 CEST] <wm4> (for no reason)
[16:52:06 CEST] <BtbN> It warns about it no matter where i move the volatile
[16:52:18 CEST] <BtbN> But moving it to the right fixes the warning every time the mutex is used.
[16:52:32 CEST] <BtbN> static pthread_mutex_t * volatile atomic_opencl_lock = NULL; is what seems most reasonable to me.
[16:52:45 CEST] <nevcairiel> definitely
[16:53:08 CEST] <BtbN> Still leaves one warnings, at the atomic swap
[16:53:20 CEST] <BtbN> libavutil/atomic_gcc.h:61:21: note: expected 'void * volatile*' but argument is of type 'union pthread_mutex_t * volatile*'
[16:53:36 CEST] <wm4> yes
[16:53:47 CEST] <wm4> a pointer to a pointer to a different type is incomaptible
[16:53:54 CEST] <BtbN> So a cast it is
[16:53:57 CEST] <nevcairiel> thats just C being C, add a cast
[16:54:01 CEST] <nevcairiel> thats how its done ev erywhere
[16:54:05 CEST] <wm4> a cast is in theory also invalid
[16:54:10 CEST] <wm4> but the compiler will stop printing a warning
[16:54:21 CEST] <BtbN> That would make it impossible to use that function in a valid way
[16:54:21 CEST] <nevcairiel> every call to avpriv_atomic_ptr_cas uses this cast
[16:54:30 CEST] <wm4> blergh
[16:54:45 CEST] <nevcairiel> and yes, you wouldnt be able to use it at all without it
[16:54:57 CEST] <nevcairiel> its meant to exchange generic pointers
[16:55:49 CEST] <BtbN> Ok, warnings gone.
[16:55:58 CEST] <BtbN> Will send the patch in a moment, with a bunch of other OpenCL stuff.
[16:56:12 CEST] <BtbN> Making it a bit more usefull.
[17:27:02 CEST] <cone-687> ffmpeg 03Kyle Swanson 07master:435d000eb59a: avfilter/generate_wave_table: clean up extra newlines
[18:17:51 CEST] <BBB> michaelni: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=bddcf758d3a68ac0bcc3bc4fc4aa7156e05245d4 break the test
[18:18:02 CEST] <BBB> michaelni: can you revert the top part? the () is missing on purpose
[18:18:32 CEST] <BBB> michaelni: youre basically setting p0 to q0 and after that writing a delta q0-range+range*2*rnd() into p0 memory
[18:19:01 CEST] <BBB> michaelni: and since the two are desynced fromt hat point onwards, the test never tests flat loopfilter function
[18:19:24 CEST] <BBB> michaelni: the idea is to calculate a value from q0-range+range*2*rnd() and assign that to p0 as well as to memory in p0s place
[19:05:46 CEST] <cone-687> ffmpeg 03Michael Niedermayer 07master:5ba40c3c712f: tests/checkasm/vp9dsp: Revert first hunk of bddcf758d3a68ac0bcc3bc4fc4aa7156e05245d4
[19:23:24 CEST] <BBB> michaelni: ty
[19:36:22 CEST] <michaelni> np, it was my mistake i should have noticed this
[20:35:35 CEST] <Daemon404> j-b, will there be a homework reminder mail coming?
[21:37:30 CEST] <durandal_1707> michaelni: is midstream change of slice count in ffv1 supported at all?
[22:18:05 CEST] <BBB> Gramner: ty for review ;)
[22:18:53 CEST] <BBB> Gramner: and I think here you see the fundamental problem with review, you cant expect everyone to understand everything, so some things are just incredibly hard to review (imagine reviewing that opencl patch...)
[22:19:05 CEST] <BBB> Gramner: or mips assembly :-p
[22:25:26 CEST] <Gramner> BBB: indeed, having every line reveiwed is probabily not feasible in this type of project, but on the other hand we're not writing code for a space shuttle control system or a life-supporting medical apparatus here so that's probably fine
[22:25:41 CEST] <BBB> "oh crap we killed kenny
[22:25:43 CEST] <BBB> "ohwell"
[23:22:59 CEST] <BBB> almost done with 16bpp loopfilter code also
[23:23:03 CEST] <BBB> thatd be nice to get finished
[23:35:44 CEST] <cone-643> ffmpeg 03Michael Bradshaw 07master:244184217c3e: Return EOF for ICO when the end is reached
[23:40:11 CEST] <rcombs> so, there's currently no mechanism a decoder can use to expose arbitrary data to the application, right?
[23:40:11 CEST] <rcombs> like AVStream::side_data
[23:41:09 CEST] <nevcairiel> AVStream::side_data exists
[23:41:20 CEST] <nevcairiel> oh decoder
[23:41:24 CEST] <kierank> there is side data
[23:42:41 CEST] <rcombs> you could stick it on frames, I suppose, but that doesn't make a lot of sense for global stuff
[23:42:48 CEST] <rcombs> like the AC3 dialnorm thing
[23:44:21 CEST] <kierank> ac3 dialnorm is not globa
[23:44:24 CEST] <kierank> l
[00:00:00 CEST] --- Fri Sep 25 2015