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

[burek]

[00:10:28 CET] <cone-127> ffmpeg 03Lukasz Marek 07master:df34b700981d: ffplay: remove redundant silence buffer
[00:30:17 CET] <sumirekousa> Hey all. I'm interested in contributing to ffmpeg for GSOC, namely the subtitle task. I was just wondering how I would go about this?
[00:37:12 CET] <wm4> sumirekousa: contact the listed mentor
[00:40:01 CET] <sumirekousa> The thing is that the subtitle task currently has no mentor with only Nicolas George listed as a possible mentor. Should I try to contact him?
[00:43:54 CET] <Compn> ask ubitux , he may know about it
[00:44:07 CET] <Compn> but yes contacting nicolas might work
[00:45:48 CET] <sumirekousa> I'll try both
[00:45:58 CET] <sumirekousa> Thank for the help
[00:51:32 CET] <cone-127> ffmpeg 03Thomas Volkert 07master:b4f32c42ab09: rtpdec: support for VC-2 HQ RTP payload format (draft v1)
[00:58:14 CET] Action: Daemon404 slaps atomnuker with optimfrog
[01:23:15 CET] <atomnuker> it's a matter of time before you lose your wavpack allegiance, mark my words!
[01:23:51 CET] <atomnuker> maybe not, dunno
[01:24:19 CET] <kierank> atomnuker: such a nightmare to build afl-clang-fast
[01:30:48 CET] <michaelni> atomnuker, theres a overflow in fate-gaplessenc-pcm-to-mov-aac
[01:31:50 CET] <michaelni> int coef = av_clip_uintp2(quant(fabsf(in[i+j]), Q, ROUNDING), 13); <-- quant()  ==  -2147483648 <-- i guess float is out of int range
[01:32:11 CET] <cone-127> ffmpeg 03Carl Eugen Hoyos 07master:30d1213ecd59: configure: Remove (b)zlib and iconv dependencies for videoltoolbox encoder.
[01:33:46 CET] <atomnuker> michaelni: odd, will take a look at it tommorow
[01:35:10 CET] <michaelni> atomnuker, thx,  Q seems 67108864.000000, this is likely why it overflows
[01:36:27 CET] <atomnuker> ok, might be the q_idx messing up (since Q is coming from a table)
[01:43:47 CET] <michaelni> ubitux, your icc segfaults in on2avc http://fatebeta.ffmpeg.org/report/x86_64-archlinux-icc-2013/20160321171253#failed_tests
[02:08:47 CET] <michaelni> ubitux, also there are some seemingly random zerocodec failures like: (seems Z_DATA_ERROR) http://fatebeta.ffmpeg.org/report/x86_64-archlinux-gcc-threads-8/20160321175452#failed_tests
[02:13:19 CET] <rcombs> anybody have any issue with me pushing the audiotoolbox codecs?
[02:14:16 CET] <rcombs> they've been pretty stable in my testing here (which admittedly is not particularly extensive), and since they're after their internal counterparts in allcodecs, they shouldn't break anything just by being present
[05:18:00 CET] <Timothy_Gu> does anybody have a IEEE Xplore subscription?
[09:37:57 CET] <Shiz> Timothy_Gu: yeah
[09:42:53 CET] <cone-118> ffmpeg 03Michael Niedermayer 07master:14478b6c3820: fate: add audiomatch
[10:23:28 CET] <ubitux> http://infocenter.arm.com/help/topic/com.arm.doc.dui0802a/ADDP_advsimd_vec_vector.html
[10:23:34 CET] <ubitux> $1M question: what does this do?
[10:24:50 CET] <wm4> enter a support contract with ARM
[10:25:10 CET] <wm4> (that's the only explanation I have for this crap)
[10:25:40 CET] <nevcairiel> thats also a way to make money
[10:25:48 CET] <nevcairiel> make your shit hard to use and dont publish docs 0p
[10:26:01 CET] <ubitux> i can't believe they're describing an instruction with 2 fucking words
[10:34:00 CET] <jkqxz> That's horizontal add, right?  The documentation for NEON has always been atrocious; writing test programs is best way to find out what instructions do (especially all the strange scatter-gather ones, which are completely impenetrable otherwise).
[10:36:26 CET] <ubitux> yeah, so apparenty, when you have Vn.8H={A,B,C,D,E,F,G,H} and Vm.8H={I,J,K,L,M,N,O,P}, you get Vd.8H={A+B,C+D,E+F,G+H,I+J,K+L,M+N,O+P}
[11:14:30 CET] <cone-118> ffmpeg 03Carl Eugen Hoyos 07master:ef888de1c1d2: lavf/img2dec: Skip COM when auto-detecting jpeg.
[11:46:46 CET] <wm4> ubitux: for the new encode/decode API, I also think I'd like to have AVSubtitle-in-AVFrame...
[11:47:53 CET] <ubitux> yes i can understand
[11:47:55 CET] <ubitux> :)
[11:48:14 CET] <ubitux> it's not that trivial though
[12:44:42 CET] <kierank> I wonder if J_Darnley is ok
[13:00:24 CET] <kierank> J_Darnley: ah you are alive
[13:00:29 CET] <kierank> good to hear
[13:00:43 CET] <JEEB> always good to know people are fine :)
[13:00:57 CET] <J_Darnley> Yeah, unfortunately
[13:02:22 CET] <kierank> really shocking to see that terminal that we use every year for fosdem in pieces
[13:02:30 CET] <J_Darnley> Huh?
[13:02:44 CET] <J_Darnley> Oh
[13:03:00 CET] <J_Darnley> I missed getting killed by terrorists again
[13:04:20 CET] <wm4> again?
[13:04:30 CET] <ismail> J_Darnley: well done.
[13:08:52 CET] <kierank> michaelni: how does an in-place dwt/idwt work with buffer referencing?
[13:09:29 CET] Action: ubitux wonders if it's better to reuse the same register for source and destination or use different registers, on aarch64
[13:13:55 CET] <ubitux> same question on x86 and arm actually
[13:56:05 CET] <wm4> michaelni: can you explain this code in libswresample: if(   av_get_planar_sample_fmt(s-> in_sample_fmt) <= AV_SAMPLE_FMT_S16P
[13:56:33 CET] <wm4> why does it do a numerical comparison where it makes no sense
[13:57:26 CET] <wm4> my actual problem is that it downmixes using s16
[13:57:29 CET] <wm4> which causes clipping
[13:57:47 CET] <wm4> and I always wondered why users reported clipping in some cases...
[13:57:57 CET] <wm4> and it's this impenetrable shit code
[13:57:58 CET] <wm4> sigh
[14:08:12 CET] <michaelni> wm4, it compares planar <= AV_SAMPLE_FMT_S16P as the formats are sorted by bits
[14:09:44 CET] <wm4> nothing says they're sorted
[14:09:59 CET] <wm4> and a hypothetical new format would be added at the end of the enum anyway
[14:10:39 CET] <michaelni> i didnt say that i consider that code to be great 
[14:15:50 CET] <ubitux> weren't the samples format done such that we could toggle a bit to switch from planar to packed at one point? (and then it changed later)
[14:21:25 CET] <cone-871> ffmpeg 03Michael Niedermayer 07master:914ad90eddce: swresample/swresample: Remove "less than" comparissions of enums
[14:50:31 CET] <gerion> hi, i'm currently try to implement the binary output. is there somewhere in the framework a (predefined) function to write bitwise to a buffer or file or do i have to shift myself?
[14:51:29 CET] <gerion> i mean some kind of put_bit(buf, 0), put_byte(buf, some_char), etc
[14:51:42 CET] <jkqxz> libavcodec/put_bits.h ?
[14:53:26 CET] <gerion> hmm thx, looks good, why it is in libavcodec?
[14:58:13 CET] <jkqxz> It's used for writing coded bitstreams.  What else would you want to do with it, that might justify it being outside libavcodec?
[15:00:30 CET] <gerion> I want to use it for the signature filter that could write binary files. beside that, I thought, that some muxer needs such functions.
[15:04:27 CET] <jkqxz> libavformat explicitly depends on libavcodec.  Some things in libavfilter depend on libavcodec too, though that's on a per-filter basis.
[15:06:55 CET] <gerion> ok, don't know the first one (actually searched libavutil for such a function)
[15:07:19 CET] <gerion> but make sense now
[15:08:53 CET] <cone-871> ffmpeg 03Rostislav Pehlivanov 07master:2aebdfb451bb: vc2enc: add non-experimental support for all video formats from spec
[15:10:13 CET] <jkqxz> $(grep 'filter_deps.*avcodec' configure) - adding another one with that dependency wouldn't exactly be a disaster.
[15:11:46 CET] <Daemon404> atomnuker, it would be cool if you could test ffa1 against the proprietary formats too. also decoding speed.
[15:25:07 CET] <atomnuker> plenty of time for that, still having fun with the entropy encoding system
[15:25:17 CET] <Daemon404> ;p
[15:25:17 CET] <atomnuker> also still need a dct
[15:25:39 CET] <Daemon404> for a lossless codec?
[15:26:35 CET] <atomnuker> myeah, want to see how big the errors would be
[15:26:49 CET] <Daemon404> er?
[15:27:13 CET] <atomnuker> oh, wait, perfect integer reversible dcts exist
[15:30:09 CET] <Daemon404> you could design your own dct
[15:30:34 CET] <atomnuker> it's fine, I know just where to borrow one
[15:30:46 CET] <Daemon404> (but really this is an excuse so i can mention the great series of blog posts about designign a dct by ryg)
[15:31:06 CET] <atomnuker> was it the guy from rad video game tools?
[15:31:18 CET] <Daemon404> yes that is ryg
[15:31:51 CET] <atomnuker> yeah, that blog post was nice
[15:32:02 CET] <Daemon404> posts =p
[15:32:45 CET] <atomnuker> oh, I've only read part 1
[15:32:49 CET] <Daemon404> theres 2
[16:43:44 CET] <rcombs> last call for comments on the AudioToolbox code, else I'll push in a couple hours
[17:10:03 CET] <durandal_1707> rcombs: why?
[17:10:25 CET] <rcombs> durandal_1707: why what?
[17:11:01 CET] <wm4> maybe asking for the meaning of life
[17:11:21 CET] <durandal_1707> this is about decoders wrapper?
[17:11:37 CET] <rcombs> and encoders, yeah
[17:12:05 CET] <rcombs> been sitting on the ML for 3 weeks with no substantial comments (one bit that I should bump minor instead of micro and mention a trac issue in the commit message)
[17:12:28 CET] <rcombs> and since they're after the internal implementations in allcodecs.c, they won't break anything by being present
[17:12:29 CET] <durandal_1707> wm4: why you still haven't done multi vo window feature in mpv?
[17:12:42 CET] <wm4> why would I
[17:12:42 CET] <nevcairiel> i find the whole idea silly, but people prefer having features over sanity, so shrug
[17:14:18 CET] <durandal_1707> wm4: because I need it
[17:14:32 CET] <wm4> busy with other stuff
[17:26:36 CET] <cone-871> ffmpeg 03Petru Rares Sincraian 07master:124526ba1aee: Added a selftest to libavutil/display.c
[18:21:01 CET] <cone-871> ffmpeg 03Ganesh Ajjanagadde 07master:db1a642cd213: all: move ff_exp10, ff_exp10f, ff_fast_powf to lavu/ffmath.h
[18:48:25 CET] <Daemon404> /g/g 42
[18:51:42 CET] <cone-871> ffmpeg 03Rodger Combs 07master:d5d328059e51: lavc: add AudioToolbox decoders
[18:51:43 CET] <cone-871> ffmpeg 03Rodger Combs 07master:65cff814534c: lavc: add AudioToolbox encoders
[18:52:23 CET] <wm4> whooh
[18:58:46 CET] <durandal_1707> now just add dshow wrapper
[19:39:23 CET] <atomnuker> what the hell is ganesh's problem?
[19:49:26 CET] <nevcairiel> he must like being annoying
[20:52:51 CET] <wm4> why do the fate-lavf tests start a bunch of ffmpegs for each test
[20:52:58 CET] <wm4> Libav doesn't even have this stuff
[20:53:06 CET] <wm4> I can't see where or why what is failing
[20:54:57 CET] <jamrial> one to encode/mux a file, another to demux/decode the result, afaik
[20:55:16 CET] <wm4> how can I run just one of them
[20:57:12 CET] <Daemon404> V=1, copypase commands
[20:57:16 CET] <Daemon404> its tedious but its how i did it
[20:57:22 CET] <Daemon404> for the codecpar branch testing
[21:05:25 CET] <Zeranoe> Does FFmpeg have x86 assembly specific components?
[21:05:45 CET] <J_Darnley> Yes.
[21:05:54 CET] <J_Darnley> All SIMD opts
[21:06:05 CET] <J_Darnley> (well almost all, some is still inline)
[21:06:10 CET] <Shiz> depends if you mean 'functionality specific to x86' or 'code specific to x86'
[21:06:41 CET] <Zeranoe> code specific to x86
[21:06:50 CET] <Shiz> yes
[21:07:37 CET] <Zeranoe> Anything other than SIMD opts?
[21:08:06 CET] <J_Darnley> I think there is branchless cabac for the h264 decoder
[21:08:13 CET] <J_Darnley> and probably other places
[21:09:02 CET] <J_Darnley> Most of it is assembly of one type or another for speed
[21:09:02 CET] <Shiz> https://github.com/FFmpeg/FFmpeg/search?utf8=%E2%9C%93&q=language%3AAssembly
[21:09:24 CET] <J_Darnley> I don't believe any features are tied to x86
[21:09:52 CET] <J_Darnley> Only to x86 operating systems: x11 capture, gd1 capture, dshow input, etc.
[21:10:23 CET] <Shiz> x11 ain't x86 only
[21:27:28 CET] <wm4> I still don't know what this test is complaining about
[21:27:34 CET] <rcombs> does vaapi count
[21:28:27 CET] <TD-Linux> no, the talos power8 board can use radeon graphics with vdpau and there is a vaapi->vdpau bridge
[21:29:38 CET] <fritsch> there is no nicely working bridge anywhere
[21:29:57 CET] <fritsch> on linux you still need to implement both if you want to use them correctly
[22:19:20 CET] <wm4>  0,        264,        264,        1, 13368960, 0xebe37433
[22:19:21 CET] <wm4> -0,        265,        265,        1, 13368960, 0xa1b5c8e1
[22:19:21 CET] <wm4> +0,        264,        264,        1, 13368960, 0xa1b5c8e1
[22:19:31 CET] <wm4> wonder if I should "fix" this...
[22:19:43 CET] <wm4> ah nevermind
[22:19:53 CET] <wm4> that's completely legitimate
[22:50:44 CET] <wizonesolutions> Hi  I've been trying the patch at https://trac.ffmpeg.org/ticket/4437#comment:21. What I am seeing is that things are better when recording and ffmpeg is the only thing recording, but if I try to record the screen when another application is also using the microphone, then the audio comes out poorly. Is it some sort of contention issue? It's Chrome that
[22:50:44 CET] <wizonesolutions> is using the microphone over WebRTC.
[00:00:00 CET] --- Wed Mar 23 2016