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

[burek]

[00:36:01 CEST] <durandal_1707> what this graph do: format=yuvj444p,split=2[a][b],[a]boxblur=20:1[a],[b][a]lut2=255*(pow((x)/255\,pow(2\,(abs(y)-127.5)/127.5))):x:x
[00:37:35 CEST] <llogan> where is that from?
[00:37:51 CEST] <durandal_1707> magic
[00:38:36 CEST] <durandal_1707> this should be local color correction, assuming boxblur does gaussian filter
[02:30:34 CEST] <durandal_1707> michaelni: does boxblur behaves as gausian blur?
[02:48:17 CEST] <michaelni> if its applied multiple times it should approuch gausian
[11:11:13 CEST] <nennenja> How is FFmpeg different from CCCP?
[11:12:42 CEST] <cone-282> ffmpeg 03Timo Rothenpieler 07master:20f09020108e: configure: fix nvenc detection logic
[11:12:43 CEST] <cone-282> ffmpeg 03Timo Rothenpieler 07master:2b1d316ff68a: configure: fix ldl dependency for new nvenc encoder names
[11:24:04 CEST] <Shiz> ok
[11:30:19 CEST] <ubitux> durandal_1707: re:xbr ; it's from hqx to be bitexact; it makes less sense in hqx, although that's probably faster that computing
[11:30:36 CEST] <ubitux> (bitexact with reference)
[11:58:21 CEST] <cone-282> ffmpeg 03Lucas Cooper 07master:aabe12eba375: avfilter/vf_psnr: Add max value output option to psnr stats log.
[14:20:13 CEST] <Gramner> so many people heading to IFA on my flight to berlin
[15:29:59 CEST] <cone-290> ffmpeg 03Erkki Seppälä 07master:499e8b0952b2: avformat/movenc: added ability to use original stream ids as track ids instead of regenerating them
[15:32:54 CEST] <BtbN> Is there a better way to get yuv420p10 test-data than opening /dev/zero as rawvideo with the desired parameters?
[15:35:12 CEST] <durandal_1707> yuvtestsrc,format=yuv420p10 ?
[15:35:35 CEST] <BtbN> there is a yuvtestsrc?
[15:35:52 CEST] <durandal_1707> yes
[15:36:05 CEST] <BtbN> is that new or did I miss it for way too long?
[15:36:13 CEST] <durandal_1707> you also have testsrc2
[15:36:42 CEST] <durandal_1707> ffmpeg -f lavfi -i testsrc2,format=yuv420p10 ...
[15:37:18 CEST] <durandal_1707> yuvtestsrc is 3 gradients like rgbtestsrc
[15:42:50 CEST] <BtbN> ./ffmpeg -f lavfi -i "yuvtestsrc=size=3840x2160:rate=120,format=yuv420p10le" -c copy -f null -y /dev/null
[15:42:54 CEST] <BtbN> results in ~30 fps
[15:43:40 CEST] <BtbN> testsrc2 is at like 40
[15:45:19 CEST] <durandal_1707> BtbN: that is yuv444p10 to yuv420p10 conversion in swscale
[15:45:46 CEST] <BtbN> I want to benchmark yuv420p10le to p010le onversion
[15:45:57 CEST] <BtbN> So "./ffmpeg -f rawvideo -s 3840x2160 -pix_fmt yuv420p10le -i /dev/zero" it is
[15:46:17 CEST] <durandal_1707> no, proper way is this:
[15:47:09 CEST] <durandal_1707> ./ffmpeg -f lavfi -i testsrc2,format=yuv420p10 -vf bench=start,format=p010le,bench=stop -f null -
[15:47:57 CEST] <BtbN> but it's already bottlenecked before that
[15:48:58 CEST] <durandal_1707> than use nullsrc, same thing as /dev/zero
[15:51:54 CEST] <BtbN> ./ffmpeg -f lavfi -i "nullsrc=size=3840x2160,format=yuv420p10le" is still only like 100 fps, while reading from /dev/zero yields 400
[16:03:07 CEST] <durandal_1707> BtbN: reading from zero is not really useful anyway
[16:03:26 CEST] <BtbN> I need something that's faster than the conversion
[16:10:41 CEST] <kierank> BtbN: /dev/shm
[16:22:37 CEST] <BtbN> is it safe to assume that the dst/src strides are a multiple of two?
[16:24:38 CEST] <durandal_1707> they should be for >8 bit depth
[16:25:17 CEST] <BtbN> that would make the entire could a whole lot simpler, as I can just divide them by two and work with uint16_t
[16:27:27 CEST] <kierank> use bytes
[16:27:49 CEST] <kierank> it's SO confusing when people mix and match
[16:27:58 CEST] Action: kierank looks at x264
[16:28:17 CEST] <BtbN> I have to left-shift an uint16_t by 6 bits. Using bytes would make that whole function a mess.
[16:28:59 CEST] <kierank> do stride /2
[16:29:07 CEST] <kierank> when you add
[16:29:41 CEST] <BtbN> and when reading as well, blowing up the whole code a ton, and all the casts everywhere
[16:32:41 CEST] <kierank> i mean use bytes for the stride
[16:32:46 CEST] <kierank> sure use uint16_t for pointers
[16:38:32 CEST] <mateo`_> I'm looking for the hevc equivalent of ff_h264_decode_extradata (in order to add support for mediacodec hevc decoding) but there is none. Is it OK that I start working on implementing such function based on hevc_decode_extradata (hevc.c) but without the AVCodecContext/HEVCContext dependency ?
[16:43:26 CEST] <JEEB> hmm, there was such a function?
[16:43:36 CEST] <JEEB> does it expose stuff like profile/level?
[16:45:38 CEST] <mateo`_> the h264 one only extracts the pps and sps from the extradata
[16:45:51 CEST] <JEEB> so it doesn't parse them I guess?
[16:46:08 CEST] <mateo`_> nope
[16:46:11 CEST] <JEEB> alrighty
[16:47:02 CEST] <mateo`_> but you can then use ff_h264_get_profile on the sps returned by ff_h264_decode_extradata
[16:47:10 CEST] <JEEB> ah
[16:47:18 CEST] <JEEB> that sounds much better
[16:47:27 CEST] <JEEB> the mediacoded decoder still lacks a profile/level check right?
[16:47:30 CEST] <JEEB> *mediacodec
[16:47:34 CEST] <JEEB> I could try adding it after work
[16:47:43 CEST] <JEEB> at least the profile one
[16:48:02 CEST] <JEEB> because I was afraid I would have had to write the parameter set parsing stuff again
[16:49:37 CEST] <JEEB> mateo`_: btw have you done any perf comparisons between the gcc 4.9 and clang 3.8 in NDK?
[16:49:44 CEST] <JEEB> with relation to FFmpeg
[16:50:04 CEST] <mateo`_> the profile/level check is already there see mediacodecdec.c in ff_mediacodec_dec_init
[16:53:49 CEST] <ubitux> in 6f69f7a8b
[16:53:50 CEST] <mateo`_> JEEB: I haven't done a proper perf comparison between the two compilers, but the only thing I can say is that I haven't seen any regressions in performance on armv7 on the jpeg/png/h264/aac software decoders.
[16:53:57 CEST] <ubitux> in function write_frame()
[16:54:09 CEST] <ubitux> a "if (!ost->st->codecpar->extradata && avctx->extradata) {" chunk was added
[16:54:24 CEST] <ubitux> this chunk is very similar to the one previously added in ab84effde
[16:54:28 CEST] <ubitux> except that it uses codecpar
[16:54:45 CEST] <ubitux> any reason why the chunk on top of the function wasn't used instead?
[16:54:51 CEST] <ubitux> it looks like they're doing the same thing
[16:55:47 CEST] <BtbN> kierank, https://github.com/BtbN/FFmpeg/commit/f546ebd6db6f47934cde69eedb619dd57bb89d7c
[16:56:09 CEST] <ubitux> sth like http://sprunge.us/PKJN
[16:56:46 CEST] <BtbN> minus the debug log...
[16:56:54 CEST] <kierank> looks sane i guess
[16:57:08 CEST] <BtbN> it does not break fate and a quick visual comparison looks fine to me
[16:57:32 CEST] <BtbN> Any sane compiler should optimize the %2 to & 1 i guess?
[16:59:18 CEST] <BtbN> This whole << 6 thing makes this incredibly annoying and hard to optimize
[17:05:40 CEST] <ubitux> BtbN: if you !! or put in a condition yes (%2 vs &1)
[17:05:56 CEST] <BtbN> if (y % 2 == 0) {
[17:05:59 CEST] <BtbN> is the whole condition
[17:06:07 CEST] <ubitux> yes it should be fine
[17:06:44 CEST] <ubitux> http://sprunge.us/aQBb
[17:07:39 CEST] <ubitux> f2 is equivalent to the condition
[17:08:04 CEST] <BtbN> and it should also optimize /2 to >>1
[17:08:11 CEST] <ubitux> no
[17:08:25 CEST] <ubitux> not with ints
[17:08:30 CEST] <BtbN> hm
[17:08:36 CEST] <BtbN> so that might still be worthwhile
[17:09:16 CEST] <ubitux> http://sprunge.us/bRhj
[17:10:11 CEST] <ubitux> if it's unsigned it doesn't matter, but unsigned can be disabling more optimisation and can be a pain for bound safety
[17:10:55 CEST] <BtbN> it should be perfectly safe to use >>1 here, those are widths/strides. If they ever are negative or something like that, there's a much bigger problem.
[17:13:56 CEST] <durandal_1707> linesize can be negative
[17:15:17 CEST] <BtbN> how would that even work?
[17:15:24 CEST] <BtbN> going backwards in the array?
[17:16:03 CEST] <durandal_1707> see libavfilter/vf_vlip.c
[17:16:07 CEST] <durandal_1707> see libavfilter/vf_vflip.c
[17:16:46 CEST] <kierank> durandal_1707: y u no go to vdd
[17:28:16 CEST] <durandal_1707> i don't want to meet compn and carl
[17:43:58 CEST] <BBB> durandal_1707: & dude & 
[17:44:18 CEST] <BBB> durandal_1707: you can disagree with people, but you need to be able to sit in a room with them even if you fundamentally disagree with them
[17:44:50 CEST] <BBB> durandal_1707: isnt that the whole principle of being a good citizen?
[17:45:14 CEST] <BBB> durandal_1707: and btw Ill be there too and Im traveling from far away
[17:50:41 CEST] <durandal_1707> is there really good code example of using wavelets for audio processing?
[18:51:34 CEST] <cone-290> ffmpeg 03James Almer 07master:f66abefefecf: configure: add missing check for LoadLibrary
[20:35:11 CEST] <cone-290> ffmpeg 03Michael Graczyk 07master:5d054a1ac452: libavcodec/opus: Fix spelling in error message
[21:02:36 CEST] <cone-290> ffmpeg 03Mark Thompson 07master:a2c912c3b6b8: lavu/timestamp: Avoid C++-unfriendly code in user header
[22:04:18 CEST] <durandal_1707> are wavelets that hard, or are they useless for audio denoising?
[22:04:38 CEST] <fritsch> was that an exclusive or in your sentence?
[22:05:34 CEST] <durandal_1707> what? both are true?
[22:06:10 CEST] <fritsch> they are quite hard to get at the beginning
[22:06:22 CEST] <fritsch> and there also exist quite nice wavelet denoising filters
[22:06:29 CEST] <fritsch> basically your get the basic ones for free
[22:07:07 CEST] <fritsch> though I mainly used them on image processing
[22:08:55 CEST] <fritsch> while doing a short google to see if someone uses them with audio I found: https://www.ceremade.dauphine.fr/~peyre/teaching/wavelets/tp4.html
[22:09:01 CEST] <fritsch> which is perhaps interesting for you
[22:09:36 CEST] <fritsch> the idea presented there "seems" to me like foruier coefficients
[22:10:06 CEST] <fritsch> where you generalize the shape of something, by only using "some" of the coefficients
[22:11:03 CEST] <fritsch> i think that analogy matches, as when interpreting wavelets as high and low pass parts, removing some of the higher parts will generalize the signal
[22:11:11 CEST] <fritsch> which they do here with thresholding
[22:17:00 CEST] <durandal_1707> fritsch: i'm more interested in program that actually use it, and is sold, otherwise this is all just research
[23:57:18 CEST] <cone-290> ffmpeg 03Michael Graczyk 07master:be07c25896bb: libavcodec/opus: Add channel mapping 2 to extradata parser
[00:00:00 CEST] --- Fri Sep  2 2016