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

[burek]

[00:38:44 CEST] <cone-480> ffmpeg 03wm4 07release/2.2:288f52a64aac: avcodec/mp3: fix skipping zeros
[00:38:45 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.2:fd7e170507f4: avcodec/ffv1: seperate slice_count from max_slice_count
[00:38:46 CEST] <cone-480> ffmpeg 03Ronald S. Bultje 07release/2.2:96f52e22f04f: hevc: fix wpp threading deadlock.
[00:38:47 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.2:8daf13a17312: avformat/avidec: Workaround broken initial frame
[00:38:48 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.2:57e284dac649: avformat/oggenc: Check segments_count for headers too
[00:38:49 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.2:3ae3708246ec: avcodec/h264_mp4toannexb_bsf: Reorder operations in nal_size check
[00:41:26 CEST] <BBB> woohoo it works
[00:41:34 CEST] <BBB> ffvp9 10bit is 51% faster than libvpx on my machine
[00:41:52 CEST] <BBB> I get about ~50fps on a single core
[00:42:06 CEST] <BBB> (libvpx gets about 31)
[00:44:10 CEST] <iive> :O
[00:44:31 CEST] <iive> that's massive speed improvement!
[00:50:46 CEST] <BBB> yeah thats pretty good :)
[01:01:36 CEST] <cone-480> ffmpeg 03Ganesh Ajjanagadde 07master:99530387283f: avcodec/xvmc: apply attribute_deprecated correctly
[01:26:34 CEST] <cone-480> ffmpeg 03wm4 07release/1.2:928473a1872c: avcodec/mp3: fix skipping zeros
[01:26:35 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/1.2:0cdeacf41b54: avformat/avidec: Workaround broken initial frame
[01:26:36 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/1.2:30c644afebb9: avformat/oggenc: Check segments_count for headers too
[01:26:37 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/1.2:17788711ac43: avcodec/h264_mp4toannexb_bsf: Reorder operations in nal_size check
[01:26:41 CEST] <cone-480> ffmpeg 03wm4 07release/2.0:7fc8458bebc6: avcodec/mp3: fix skipping zeros
[01:26:42 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.0:b44025a1d031: avcodec/ffv1: seperate slice_count from max_slice_count
[01:26:43 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.0:055c302a11cd: avformat/avidec: Workaround broken initial frame
[01:26:44 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.0:0b0183c5b741: avformat/oggenc: Check segments_count for headers too
[01:26:45 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.0:087561a7dcaa: avcodec/h264_mp4toannexb_bsf: Reorder operations in nal_size check
[01:26:52 CEST] <cone-480> ffmpeg 03wm4 07release/2.1:c83569e5f151: avcodec/mp3: fix skipping zeros
[01:26:53 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.1:b0d9042f9dbe: avcodec/ffv1: seperate slice_count from max_slice_count
[01:26:54 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.1:f3dfb14f6c40: avformat/avidec: Workaround broken initial frame
[01:26:55 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.1:01fa1dc22914: avformat/oggenc: Check segments_count for headers too
[01:26:56 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07release/2.1:50ac23fd7fd9: avcodec/h264_mp4toannexb_bsf: Reorder operations in nal_size check
[01:28:19 CEST] <jamrial> BBB: ffvp9 10bit is faster than ffh264 10bit, it seems
[01:28:36 CEST] <jamrial> so, awesome job
[01:39:35 CEST] <cone-480> ffmpeg 03Michael Niedermayer 07master:3d126ef18863: avcodec/h264_mp4toannexb_bsf: Use av_freep() to free spspps_buf
[01:39:36 CEST] <cone-480> ffmpeg 03uઠ07master:cd847839f33e: h264_mp4toannexb: fix the pps offset when there are more than one sps in avcc
[01:44:58 CEST] <BBB> jamrial: thats not surprising, 8bit is faster also
[01:45:06 CEST] <BBB> jamrial: (if you remember my presentation at VDD)
[01:45:25 CEST] <BBB> iive: why would xvmc not be deprecated?
[01:45:28 CEST] <jamrial> true
[01:45:38 CEST] <BBB> iive: all xvmc parts of the codebase are deprecated and under deprecation macros
[01:46:37 CEST] <iive> BBB: i've updated xvmc to use hwaccel, about a year ago and i've put ff_api_xvmc around the parts that are no longer needed, but break api
[01:46:52 CEST] <BBB> ah, I see
[01:47:10 CEST] <BBB> so the pixfmt still exists and is part of hwaccel but was not undeprecated?
[01:47:15 CEST] <iive> if there are deprecation on the "good" parts, then it is probably mistake from mergers
[01:47:25 CEST] <BBB> right, can you check?
[01:47:36 CEST] <iive> will do, but tomorrow :)
[01:47:49 CEST] <BBB> (configure extra-cflags=-DFF_API_XVMC=0, I think)
[01:47:59 CEST] <BBB> or something like that, you probably know better than me
[01:49:01 CEST] <iive> since the current master is the one that breaks ABI and API, maybe I would just trigger the FF_API_XVMC
[01:58:13 CEST] <iive> n8 ppl
[04:35:24 CEST] <rcombs> michaelni_: should I push the sidx patch, then?
[04:35:56 CEST] <michaelni_> rcombs, yes
[04:36:48 CEST] <cone-480> ffmpeg 03Rodger Combs 07master:4ab566675948: lavf/mov: add support for sidx fragment indexes
[04:37:36 CEST] <rcombs> and should "lavc: move bitstream filter args to the bsf ctx" bump a version somewhere?
[04:38:15 CEST] <rcombs> seems like it should bump lavc minor
[04:44:00 CEST] <BBB> Gramner: ok now I will try to address your comments
[04:44:16 CEST] <BBB> Gramner: (or, well, tomorrow maybe)
[04:53:30 CEST] <cone-480> ffmpeg 03James Almer 07master:dab5f65b25f1: x86/takdsp: use arithmetic shift instructions
[05:08:46 CEST] <michaelni_> rcombs, probably yes
[09:20:11 CEST] <cone-261> ffmpeg 03Vittorio Giovara 07master:3a4d369ea4de: g2m: Relax resolution change constraints
[09:20:11 CEST] <cone-261> ffmpeg 03Hendrik Leppkes 07master:d3952510d21a: Merge commit '3a4d369ea4ded91b1178ae6e2ff0ab9ea470e344'
[09:33:09 CEST] <cone-261> ffmpeg 03Alexandra Khirnova 07master:58b42345b38b: dcadec: reorganise context data
[09:33:10 CEST] <cone-261> ffmpeg 03Hendrik Leppkes 07master:a71fff213d56: Merge commit '58b42345b38b46d11c32e11d9c57517f99d6a601'
[09:41:27 CEST] <cone-261> ffmpeg 03Luca Barbato 07master:d7a5a178c252: configure: When disabling a library disable all the related components
[09:41:28 CEST] <cone-261> ffmpeg 03Hendrik Leppkes 07master:0b28039a44b3: Merge commit 'd7a5a178c252b625537adc046392624ad543dea7'
[09:43:56 CEST] <cone-261> ffmpeg 03Luca Barbato 07master:8b830ee9a26d: avconv: Do not try to configure filter outputs without streams
[09:43:57 CEST] <cone-261> ffmpeg 03Hendrik Leppkes 07master:3e3779cd517e: Merge commit '8b830ee9a26d47b138f12a82085cdb372f407f1e'
[09:45:39 CEST] <cone-261> ffmpeg 03Hendrik Leppkes 07master:b22693b06d1e: w32pthreads: Add pthread_once emulation
[09:45:40 CEST] <cone-261> ffmpeg 03Hendrik Leppkes 07master:89da893c880d: Merge commit 'b22693b06d1e5d73454a65c203b4d31c1ca5b69a'
[09:46:11 CEST] <cone-261> ffmpeg 03Hendrik Leppkes 07master:2830bce47e2e: w32pthreads: Load dynamically loaded functions on demand
[09:46:12 CEST] <cone-261> ffmpeg 03Hendrik Leppkes 07master:9d6873a43d20: Merge commit '2830bce47e2eb29c76202f19017031ddc1f95dd3'
[09:55:31 CEST] <cone-261> ffmpeg 03Derek Buitenhuis 07master:9692fd762296: Revert "cabac: Allow hardcoding CABAC table."
[09:55:32 CEST] <cone-261> ffmpeg 03Anton Khirnov 07master:8a73b8c5b42d: cabac: Make cabac starts hardcoded
[09:56:22 CEST] <cone-261> ffmpeg 03Anton Khirnov 07master:a8956eca1ff3: cabac: Make CABAC states hardcoded
[09:56:23 CEST] <cone-261> ffmpeg 03Hendrik Leppkes 07master:8b1007ead88b: Merge commit 'a8956eca1ff3b5b7f9aadbe6eb46536efeb2f828'
[09:56:37 CEST] <cone-261> ffmpeg 03Alexandra Hájková 07master:00cc10aee380: asfdec: do not skip padding if offset is above packet size - padding
[09:56:38 CEST] <cone-261> ffmpeg 03Hendrik Leppkes 07master:80fd6225907d: Merge commit '00cc10aee380f882507bac994ac469d8358d12e8'
[09:58:50 CEST] <cone-261> ffmpeg 03Mario Gasparoni 07master:c3e5c47bdae2: libopenh264enc: Added max_nal_size option
[09:58:51 CEST] <cone-261> ffmpeg 03Hendrik Leppkes 07master:c4e23ca85377: Merge commit 'c3e5c47bdae2bb8219fea62d91b7455650b22c60'
[15:36:29 CEST] <cone-523> ffmpeg 03Ganesh Ajjanagadde 07master:979572365f21: avcodec/ac3enc: fix undefined negative left shift
[15:37:52 CEST] <rcombs> michaelni_: https://gist.github.com/283badea2fc5d6d09a63 this look good to push, then?
[15:41:24 CEST] <michaelni_> rcombs, i thought more of a wording like used in avcodec.h/AVCodecContext as in "- encoding: Set by decoder."
[15:41:36 CEST] <michaelni_> would be more consistent
[15:42:23 CEST] <rcombs> well, `- encoding: <&>\n- decoding: <&>` doesn't really make sense here, since it's not a single struct used for 2 purposes
[15:42:32 CEST] <michaelni_> "consumer" is rather bad wording IMHO as its not clear if thats a consumer wthin libavformat or the user 
[15:42:37 CEST] <michaelni_> of the lib
[15:42:54 CEST] <michaelni_> yes was just an example from libavcodec
[15:42:54 CEST] <rcombs> "Set by user", then?
[15:43:02 CEST] <michaelni_> yes if thats intended
[15:43:37 CEST] <rcombs> just that change, then?
[15:48:23 CEST] <michaelni_> yes but iam not sure now if its not better to have some init function take the args and set them, this would in a future iteration allow bsfs to validate the args at init time
[15:49:50 CEST] <cone-523> ffmpeg 03Ganesh Ajjanagadde 07master:8881b035d97a: doc/build_system: miscellaneous typo and consistency fixes
[15:52:13 CEST] <rcombs> there's a libav Evil Plan to overhaul bsfs in general
[15:52:18 CEST] <rcombs> move to AVOptions, etc
[15:52:25 CEST] <rcombs> so this is really just a stopgap
[15:54:22 CEST] <rcombs> also, removing the link to an AVCodecContext
[15:55:27 CEST] <michaelni_> allowing&requiring the user to directly set args in the struct will require us to keep all prior fields in the struct until the next major abi bump, so even if some API redesign is done we would have to continue supporting this system
[15:55:40 CEST] <cone-523> ffmpeg 03Ganesh Ajjanagadde 07master:0281ef907519: doc/developer: minor typo and consistency fixes
[15:56:08 CEST] <michaelni_> but i have no real oppinon on this, iam not against it if its preferred
[15:56:12 CEST] <rcombs> so, you'd suggest declaring the field lib-private?
[15:56:31 CEST] <michaelni_> yes
[15:56:37 CEST] <rcombs> sure
[15:58:40 CEST] <rcombs> something like this? https://gist.github.com/54502b14f406bf6737e8
[15:59:31 CEST] <michaelni_> yes
[16:23:43 CEST] <durandal_1707> BBB: what's missing SIMD and its not swscale?
[16:24:03 CEST] <nevcairiel> hevc idct
[16:24:05 CEST] Action: nevcairiel hides
[16:24:26 CEST] <Compn> all h264 stuff been simd ?
[16:24:46 CEST] <ubitux> fft/rdft code :(
[16:24:54 CEST] <ubitux> (av_rdft_*)
[16:25:37 CEST] <ubitux> durandal_1707: still not taking that challenge?
[16:42:24 CEST] <durandal_1707> ubitux: I see only one function
[16:43:31 CEST] <ubitux> not enough to keep you busy for long enough?
[16:45:27 CEST] <ubitux> some related stuff in libavcodec/fft_template.c might be interesting
[17:40:50 CEST] <cone-523> ffmpeg 03Paul B Mahol 07master:5740dc27e1a6: avfilter/vf_w3fdif: add x86 SIMD
[17:41:51 CEST] <cone-523> ffmpeg 03Rodger Combs 07master:0d53a6f5b4f5: lavc: move bitstream filter args to the bsf ctx
[17:49:02 CEST] <ubitux> durandal_1707: you forgot to fix the '.loop:' 
[17:49:32 CEST] <durandal_1707> argh
[17:51:04 CEST] <jamrial> ubitux: do you know why only some of your fate clients are failing the aac_ad6000np_44_ep0 tests (float and fixed)?
[17:51:52 CEST] <ubitux> not at all but that's new
[17:52:02 CEST] <jamrial> yeah
[17:52:43 CEST] <jamrial> the valgrind, 7 and 8 threads clients are failing. the 16 threads one and everything else are fine
[17:52:45 CEST] <jamrial> kinda weird
[17:52:48 CEST] <ubitux> so valgrind says there is no problem
[17:52:53 CEST] <ubitux> but actually there is?
[17:53:07 CEST] <ubitux> stddev:    1.22 PSNR: 94.55 MAXDIFF: 1023 bytes:  1855488/  1855488
[17:53:09 CEST] <ubitux> MAXDIFF: |1023 - 0| >= 2
[17:53:11 CEST] <ubitux> mmh
[17:53:54 CEST] <ubitux> there is a valgrind upgrade
[17:53:58 CEST] <ubitux> let me try that first
[17:56:02 CEST] <cone-523> ffmpeg 03Paul B Mahol 07master:c3d312bb7f39: avfilter/x86/vf_w3fdif: add colons after labels
[17:56:59 CEST] <ubitux> http://sourceforge.net/p/valgrind/mailman/valgrind-announce/
[17:57:02 CEST] <ubitux> some interesting stuff
[18:01:29 CEST] <ubitux> durandal_1707: thx
[18:24:02 CEST] <kurosu_> michaelni_, are you here? on the topic of simple_idct10 - I'm missing information in your replies
[18:24:45 CEST] <kurosu_> ff_simple_idct_10 does not pass the 10 bit test - it can be coerced, but that needs some adaptation for prores
[18:25:37 CEST] <wm4> michaelni_: what's the problem with using swr_set_compensation for large adjustments, such as say 2x speed?
[18:32:12 CEST] <rcombs> >sourceforge
[18:32:30 CEST] <rcombs> I thought they turned evil and everybody left
[18:35:09 CEST] <ubitux> rcombs: only software remains
[18:36:29 CEST] <BBB> durandal_1707: Im not sure
[18:36:42 CEST] <BBB> durandal_1707: I feel a lot of filters could use more simd but this is only hearsay so I dont have specific examples
[18:36:52 CEST] <BBB> durandal_1707: hevc idct is indeed one, if youre up for it - might be a nice practice
[18:37:27 CEST] <BBB> durandal_1707: theres a lot of neon missing if you want to learn something new that few people know how to do
[18:38:11 CEST] <durandal_1707> what uses neon?
[18:38:11 CEST] <ubitux> durandal_1707: vf lut 3d could enjoy some simd if you want to have fun with floats
[18:39:08 CEST] <ubitux> durandal_1707: phones & misc boards
[18:46:56 CEST] <michaelni_> wm4, it would be using a filterbank build for the original resampling frequencies
[18:47:17 CEST] <wm4> michaelni_: what if the context originally had same inout and output frequencies
[18:47:20 CEST] <wm4> *input
[18:50:56 CEST] <michaelni_> that should not make a difference. Do you see some difference / problem with it ?
[18:51:25 CEST] <wm4> I'm just wondering how to use it
[18:53:16 CEST] <wm4> I used to change the sample rate and reinit the swr context when changing playback speed, but now I just use swr_set_compensation
[19:12:02 CEST] <michaelni_> kurosu_, i just replied on the ML, does my reply clarify things ?
[19:13:24 CEST] <michaelni_> wm4, if the actual sample rate changes like when the user switches playback speed from 50 to 100% then reinit is more correct
[19:13:51 CEST] <michaelni_> if the timestamps though drift a bit then reinit is wrong
[19:15:30 CEST] <wm4> so what's the threshold for reinit, and why does swr not do this automatically?
[19:15:40 CEST] <kurosu_> michaelni_, the dct-test changes were wrong: the functions I added need to be tested, but not in the way I expected
[19:15:58 CEST] <kurosu_> it's just weird to test functions that clip to a smaller range and are bound to fail
[19:17:54 CEST] <kurosu_> but ok, I'm going to send another upgraded patchset
[19:18:33 CEST] <michaelni_> where do they clip ?
[19:18:52 CEST] <kurosu_> huh, you're right, they don't
[19:19:09 CEST] <kurosu_> I was thinking of the _put versions, incorrectly
[19:19:43 CEST] <kurosu_> it has more to do with the expected scale of the input coefficients and how you need to scale down after one pass - sometimes, it's going to produce weird results
[19:23:39 CEST] <kurosu_> weird
[19:24:22 CEST] <michaelni_> wm4, theres no threshold, but if the resampler is initialized to resamples 44k to 32k and then used with compensation to upsample 44k-> 48k then theres some loss of quality. The compensation is intended to deal with things like +-1% clock drift
[19:25:39 CEST] <kurosu_> before: IDCT SIMPLE-C10: max_err=1 omse=0.03060703 ome=-0.00010234 syserr=0.00575000 maxout=1027 blockSumErr=10
[19:25:43 CEST] <kurosu_> after: IDCT SIMPLE-C10: max_err=1 omse=0.01663750 ome=0.00007031 syserr=0.00220000 maxout=1028 blockSumErr=6
[19:25:49 CEST] <michaelni_> also there should be no frequent +-50% change in sample rate or i misunderstand something
[19:26:09 CEST] <kurosu_> but that fails the dnxhd test, and seeing the psnr, with probably overflows
[19:26:21 CEST] <kurosu_> I'd though dct-test would notice that
[19:27:25 CEST] <michaelni_> the overflow related tests maybe are 8bit specifically scaled
[19:27:33 CEST] <wm4> michaelni_: ok
[19:30:32 CEST] <michaelni_> kurosu_, maybe the overflow test is not good even for 8bit
[19:31:50 CEST] Action: ubitux is surprised libswscale/rgb2rgb_template.c is not covered by fate
[19:32:21 CEST] <ubitux> swscale_unscaled.c kinda lack coverage too :(
[19:33:19 CEST] <ubitux> maybe that's because fate is ran with cpu flags
[19:33:47 CEST] <ubitux> ah, no, my bad, i run it with CPUFLAGS=none
[19:34:41 CEST] <ubitux> which is likely not honored according to coverage&
[19:46:50 CEST] <kurosu_> michaelni_, it seems the overflow only occurs in the fast dc code of idctRowCondDC
[19:47:02 CEST] <kurosu_> the x86 version which doesn't do it doesn't fail
[19:50:25 CEST] <ubitux> i'm starting to get answers on the survey draft (about 10); if you have suggestion on adjustement, do it this week end since i will restart it on monday
[19:51:13 CEST] <ubitux> btw, according to the answers, one adjustement is probably about the lts; apparently there is a relative opposition to this, and i wonder if there is a misunderstanding with the current number of releases and doing a limited number of official lts
[19:51:17 CEST] <ubitux> maybe it should be more explicit
[19:51:38 CEST] <wm4> who's providing this lts
[19:51:52 CEST] <wm4> (never heard of the idea before)
[19:52:08 CEST] <ubitux> at least j-b was complaining about this, and maybe distro (don't remember)
[19:52:29 CEST] <ubitux> the idea is just to have one LTS
[19:52:46 CEST] <ubitux> to limit maintainance work i suppose
[19:53:01 CEST] <ubitux> or something along these lines?
[19:53:23 CEST] <ubitux> if someone has suggestions about how to clarify that entry, please share
[20:21:53 CEST] <kurosu_> michaelni_, nevermind about the dccond overflow, I hadn't changed DC_SHIFT
[20:27:55 CEST] <cone-523> ffmpeg 03Zhang Rui 07master:7dc42c9e6571: avformat/async: pass internal I/O error
[20:27:56 CEST] <cone-523> ffmpeg 03Zhang Rui 07master:810fbd893303: fate/async: test error code from underlying protocol
[20:27:57 CEST] <cone-523> ffmpeg 03Ganesh Ajjanagadde 07master:3b2000c2bf12: doc/scaler, swscale/options: use proper capitalization
[20:28:33 CEST] <durandal_1707> ubitux: can whole build_diff_map from fieldmatch be simded?
[20:29:00 CEST] <ubitux> yes, you can have fun doing simd in fieldmatch
[20:29:19 CEST] <ubitux> i don't remember what is the most expensive part of the filter
[20:29:57 CEST] <ubitux> same goes for decimate btw
[20:37:59 CEST] <durandal_1707> ubitux: mentioned one takes 43% time
[20:38:21 CEST] <ubitux> ok :)
[20:39:01 CEST] <durandal_1707> but its full of ifs 
[20:43:45 CEST] <ubitux> yes, it's likely annoying; might involve pcmgt* stuff
[20:44:23 CEST] <ubitux> pcmpgt*
[20:45:25 CEST] <Zeranoe_> Does FFmpeg provide a way to be notified of new releases?
[20:46:21 CEST] <thardin> rss?
[20:47:33 CEST] <cone-523> ffmpeg 03Ganesh Ajjanagadde 07master:07c60684a750: gitignore: ignore object file temporaries
[20:48:51 CEST] <Zeranoe_> thardin: Where is the RSS?
[20:50:46 CEST] <thardin> website?
[20:50:58 CEST] <thardin> i assume
[20:51:26 CEST] <thardin> like you would subscribe to any blog
[20:58:39 CEST] <cone-523> ffmpeg 03Ganesh Ajjanagadde 07master:f3fc103c6a8e: doc/resampler, swresample/options: use proper capitalization
[21:23:28 CEST] <ubitux> yay i think i got the selectivecolor formula.
[21:26:07 CEST] <mateo`> \o/
[21:26:21 CEST] <ubitux> with K that is
[21:26:31 CEST] <ubitux> need to figure out a few details but i think i get it
[21:26:45 CEST] <ubitux> something along the line G(a,k)=(-1-a).k-a
[21:27:11 CEST] <ubitux> need to figure out clipping and it's done
[21:50:14 CEST] <jamrial> http://fate.ffmpeg.org/report.cgi?time=20151010052205&slot=x86_64-archlinux-gcc-experimental https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67920
[21:51:16 CEST] <jamrial> not as bad as flac and a bunch of other audio decoders being miscompiled, like it happened with gcc 4.9.0
[00:00:00 CEST] --- Sun Oct 11 2015