[00:29] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:f95b5d2a114e: cmdutils: cosmetics [00:29] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:05493c6e724a: avcodec/avpacket: correctly set the number of side data elements in av_copy_packet_side_data() [00:29] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:df87cfd798d1: ffmpeg: fix do_streamcopy() so it copies side data too [00:46] <michaelni_> wm4, 1120 0:42 To FFmpeg devel (1.9K) [FFmpeg-devel] [PATCH] [RFC] avformat/options_table: do not merge sidedata by default [02:37] <BBB> ubitux: I'm not sure my patch is actually a good idea, I'm considering retracting it [02:37] <BBB> ubitux: it doesn't play well with frame-mt [03:25] <cone-128> ffmpeg.git 03Michael Niedermayer 07release/2.1:9422cd85a081: update for 2.1.1 [04:08] <cone-128> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.1.1': unknown revision or path not in the working tree. [04:08] <cone-128> Use '--' to separate paths from revisions [04:08] <cone-128> refs/tags/n2.1.1:HEAD: ffmpeg: fix do_streamcopy() so it copies side data too [04:22] <cone-128> ffmpeg.git 03Tim Walker 07master:ffb0af7f17eb: ac3dec: simplify an expression [04:22] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:61f40fbb528d: Merge commit 'ffb0af7f17eb0da86e9b140e86a1404d3c6c9e79' [04:45] <cone-128> ffmpeg.git 03Derek Buitenhuis 07master:03f6d4e0f168: win{32,64}: Hard disable symbol versioning [04:45] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:bb7f3ddd4254: Merge remote-tracking branch 'qatar/master' [09:23] <ubitux> BBB: ok [09:23] <ubitux> BBB: you're working on mt? [09:56] <ubitux> BBB: there is indeed quite some time spent in idct 16 and 32 [09:57] <ubitux> also strangely in the memset of decode_b [09:58] <ubitux> heh, and loop filters [10:01] <ubitux> http://b.pkh.me/vp9cg.png [10:07] <saste> llogan, you there? [10:07] <ubitux> i'd like to know too [10:09] <saste> i'm reading the ubuntu compilation guide, and it is confusing, especially for new users [10:09] <saste> with lot of non-working path magik [11:02] <ubitux> michaelni: "also converting between sample rates needs a delay" (swr) [11:03] <ubitux> what is this delay used for? [11:03] <ubitux> i'm doing a 48k to 44.1k, there is a delay of 16, except at the first call [11:03] <ubitux> i'm wondering why [11:04] <ubitux> also, the rescale rounding formula used to estimate the output buffer size is over estimated by a large margin [11:14] <plepere> hmmmm [11:15] <plepere> I'm trying to use a table declared in a .h when I'm in asm [11:15] <plepere> did a cextern hevc_epel_filters [11:15] <plepere> with ff_hevc_epel_filters being the table called in C [11:15] <plepere> relocation R_X86_64_32 against `ff_hevc_epel_filters' can not be used when making a shared object; [11:15] <plepere> I get this error when compiling [11:17] <plepere> it's telling me to recompile with -fPIC, but I'm already compiling with that [11:49] <highgod> Hi, I want ask a question about hevc decoder, does ffmpeg write it or using OpenHEVC? Thanks [11:51] <JEEB> it's smarter's decoder. OpenHEVC project uses it as well. OpenHEVC has also developed some features and optimizations in smarter's decoder [11:51] <nevcairiel> openhevc was a fork from smarters work, who wrote it for libav [11:51] <nevcairiel> so basically, it was a collaboration between the two [11:52] <highgod> JEEB: what is smarter's decoder? Thanks [11:52] <JEEB> basically the "OpenHEVC" part as such is just the C++ API they made around a hacked-up libavcodec [11:53] <JEEB> highgod, it is what smarter wrote as libav's summer of code project last year, and has been more or less looking at how the development has continued since [11:58] <ubitux> plepere: i think you need to duplicate it [11:59] <nevcairiel> how do other things do that? i saw the h263 loop filter has a table, for example [12:00] <ubitux> plepere: mmh maybe using cextern [12:00] <ubitux> ah my bad. [12:00] Action: ubitux gets a brain [12:01] <nevcairiel> h263_loop_filter_strength is used in h263 asm, the table is defined in some other C file [12:01] <nevcairiel> so somehow it works [12:01] <michaelni> ubitux, you can do it without a delay, its then called nearest neighghbor resampling [12:02] <ubitux> michaelni: where is the code doing that? [12:02] <nevcairiel> it loads the address of the table into a register and then uses that register to calculate stuff, it doesnt use the table directly in address calculatons [12:02] <nevcairiel> not sure if that matters [12:02] <michaelni> ubitux, it was a joke [12:02] <ubitux> :( [12:03] <michaelni> you need a delay if you want it to sound in a way a human will be wiling to listen to [12:03] <nevcairiel> ubitux: in short, any quality resampling has a dealy ;) [12:03] <ubitux> mmh [12:04] <ubitux> so i was willing to avoid resampling all my data but i guess i'd better not do it [12:04] <ubitux> how/where is the delay estimated? [12:04] <ubitux> also, why is the delay estimate so high with the given formula? [12:05] <michaelni> the delay is half the filter length (within rounding more or less) [12:06] <ubitux> ok [12:06] <Compn> let me check the copyright [12:06] <Compn> oops [12:06] <michaelni> it can differ from that though when compensating inaccurate sample rates (that is what -async did) [12:06] Action: Compn lagged [12:16] <michaelni> but i guess if it differs with "async" actually depends on how you define delay [12:21] <ubitux> michaelni: is it safe to flush with swr_convert() and then start again a convert like nothing happened? [12:28] <michaelni> flushed would have to be reset and the buffer contents would have to be cleared otherwise there would be extra samples output from the flushing i think [12:30] <michaelni> see resample_flush() for the cod that adds the samples [12:30] <ubitux> yes sure i'm clearing my output buffer after the flushing, and the input buffer is somehow reset [12:30] <ubitux> unless you mean sth else? [12:30] <michaelni> SwrContext.flushed [12:32] <ubitux> (would it be safer to re-call swr_init()?) [12:32] <michaelni> its the simple solution [12:32] <ubitux> it's leak safe? [12:33] <michaelni> you have many questions :) [12:33] <ubitux> :D [12:33] <michaelni> it should be i think [12:33] <michaelni> but anything can be buggy [12:34] <michaelni> also if someone write a testcase that compares continuing after flush with and without init then iam happy to fix it so both produce the same output [12:35] <ubitux> i might write a test case [12:35] <ubitux> i'm assuming it's useful in case of seeking [12:35] <michaelni> hmm, yes could be [12:36] <ubitux> speaking of seeking am i the only one to expect some kind of laggy a/v sync catch up after seeking with ffplay? [12:36] <ubitux> i thought i opened a ticket for this but i can't find it anymore [12:36] <ubitux> maybe i just complained on irc actually. [13:05] <BBB> ubitux: yeah, I noticed that too [13:06] <BBB> I'm almost considering doing 32x32 and 16x16 partially in intrinsics, it's just such a pain to do it in plain asm [13:06] <BBB> but I'm not sure yet [13:06] <BBB> I needed something else for the little time I have, and 32x32 is just too much ATM :( [13:06] <BBB> so mt seemed useful [13:09] <plepere> is it not OK to use intrinsics in ffmpeg ? [13:12] <ubitux> BBB: we don't have any intrinsics, i'd say it's not a good idea [13:12] <ubitux> and well, i can try to do it if you don't want anymore [13:13] <ubitux> BBB: do intrinsics, objdump, copy paste, optimize :p [13:15] <ubitux> BBB: did you start 16x16? [13:26] <BBB> ubitux: no [13:26] <ubitux> should i? [13:26] <BBB> ubitux: I basically haven't touched any code for at least 4 weeks now, except for an odd patch [13:26] <BBB> yeah please do [13:26] <BBB> you know the logic from the 8x8 [13:26] <ubitux> 16x16 so? [13:27] <ubitux> yeah well i cheated with 8x8 [13:27] <BBB> the only thing to keep in mind is to do the 16x16 in 2 8x16 passes [13:27] <BBB> and store the result on the stack between the two passes [13:27] <ubitux> on the stack, ok [13:27] <BBB> for an example, see e.g. h264 mmx 8x8 or so [13:27] <ubitux> ok [13:27] <BBB> like the C code does [13:28] <ubitux> what about the transpose? [13:28] <BBB> so pass 1, transpose, store, pass1, transpose, store, pass 2, add_and_store, pass2, add_and_store [13:28] <BBB> for the full one [13:28] <ubitux> oh mmh [13:28] <BBB> and then the 8x8/4x4/2x2/1x1 become just trivial simplifications thereof [13:29] <ubitux> ok [13:41] <ubitux> BBB: the 16x8 will require to play with the stack though [13:41] <BBB> yes likely [13:41] <ubitux> i probably need to do a 2x8x8 [13:41] <BBB> well you can't really do that right [13:41] <BBB> all parts of the 16x8 interact with each other [13:42] <ubitux> yeah right [13:42] <BBB> you can't easily separate the 16x8 in anything smaller that is not 16xsomething [13:42] <ubitux> but i mean i can't process 16 at once [13:42] <BBB> you can do 16x4, but that doesn't help at all except when on mmx ;) [13:42] <BBB> right, yes [13:42] <BBB> so you need to swap stuff to/from stack when needed, just like a regular compiler would do with c functions [13:42] <BBB> and the trick is to do that "optimally" [13:43] <BBB> that's why I was thinking intrinsics for 16x16/32x32 (still written in the 16x8 per pass method, ofc) [13:46] <ubitux> you think the compiler will deal well playing with the stack? [13:47] <nevcairiel> just do what ubitux suggested, look at what the compiler did and clean the code :p [13:51] <nevcairiel> and while i personally like intrinsics for some quick inline optimizations, they seem to be frowned upon [13:57] <BBB> ubitux: it did ok in libvpx, but very version/brand-specific [13:57] <BBB> ubitux: e.g. you'll run into clang and gcc and msvc doing different things [13:57] <BBB> ubitux: it'll work, but it'll perform differently [13:57] <BBB> and that may not be what you want [13:58] <BBB> ubitux: but it'll work ok yes, that's what compilers are optimized for, finding dependency paths and minimizing the amount of "stuff" they have to do to a binary to give the same output as your code [13:58] <BBB> I'm not sure though [14:20] <saste> llogan, ping [15:47] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:cccdaa406a29: avcodec/h261enc: avoid use of current/previous_mba [15:47] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:6c04c5f733d3: avcodec/h261enc: dont use current_mv_x/y [15:48] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:ec312c1fd0d8: fate: test -mbd rd for h261 [15:59] <Daemon404> hey Compn do you know if you have a sample of 24-bit wma lossless? [15:59] <Daemon404> i can only find 16 bit in the archive [16:23] <cone-814> ffmpeg.git 03Clément BSsch 07master:3e69f7c22106: avfilter/showspectrum: add win_func option. [16:23] <Daemon404> Compn, nvm found one [16:23] <ubitux> no window is really bad [16:24] <ubitux> and hamming is definitely worse than hann [16:24] <ubitux> any win func suggestion welcome [16:25] <merbanan> blackmann is the best [16:25] <ubitux> ok [16:25] <merbanan> with my definition of best [16:30] <wm4> so, can Ben Boeckel's ogg mid-stream tag update patches be merged? [16:37] <merbanan> yes coz of his name [16:37] <merbanan> good name [16:38] <cone-814> ffmpeg.git 03Clément BSsch 07master:9c8b24080638: avfilter/showspectrum: add blackman window. [16:38] <cone-814> ffmpeg.git 03Clément BSsch 07master:9343fc30e28c: avfilter/showspectrum: reindent const options. [16:38] <cone-814> ffmpeg.git 03Clément BSsch 07master:ddaf543aa663: avfilter/showspectrum: use 0 dummies for range in const. [16:39] <ubitux> merbanan: thx [16:43] <merbanan> was it nicer ? [16:43] <ubitux> i can't really tell [16:43] <ubitux> it looks too similar to hann [16:44] <ubitux> merbanan: you can try with ./ffplay -f lavfi amovie=bla.mp3,showspectrum=mode=separate:color=intensity:slide=1:scale=cbrt:win_func=blackman [16:56] <ubitux> merbanan: http://lucy.pkh.me/winfunc/ [16:57] <merbanan> do you do any overlap ? [16:57] <ubitux> what do you mean? [16:57] <ubitux> (this was generated with for f in none hann hamming blackman; do ./ffmpeg -i ~/music/heart.flac -filter_complex showspectrum=mode=separate:color=intensity:slide=1:scale=cbrt:win_func=$f -ss 10 -frames:v 1 -y showspectrum_$f.png; done) [16:58] <merbanan> you should overlap the spectrum rendering to get rid of the block artifacts [17:00] <merbanan> ie do more fft's then needed [17:02] <ubitux> mmh yeah that could be nice to add [17:03] <merbanan> the output will look much better [17:41] <cone-814> ffmpeg.git 03Ben Boeckel 07master:1e506a2cc586: avcodec: add side_data type for updated metadata [17:41] <cone-814> ffmpeg.git 03Ben Boeckel 07master:51a84a6bca61: avpacket: add pack/unpack functions for AVDictionary [17:41] <cone-814> ffmpeg.git 03Ben Boeckel 07master:c28b61caf0e3: Document new APIs for av_packet_{un, }pack_dictionary() [17:41] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:fcb1b0078d38: avcodec/avpacket: use size_t, fix potential integer overflow [18:47] <cone-814> ffmpeg.git 03Ben Boeckel 07master:34b7c82dd3d7: avcodec/utils: use the unpack_dictionary function [19:34] <wm4> michaelni: your recent size_t commit would leak data if allocation of a more than 2GB sized metadata side data element succeeded [19:34] <wm4> maybe that's pedantic, OTOH I don't know why to limit side data at 2GB, and not, say 100 MB or SIZE_MAX [19:47] <michaelni> 100mb could be done >int_max cannot as the size is returned in a int [19:47] <michaelni> ill fix the leak in a moment [19:50] <michaelni> one could of course also switch to size_t, though iam not sure if that woudnt just move the need of the check to the callers [19:51] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:e50278348a31: avcodec/avpacket: fix order of operations in case of too large allocation [21:41] <kwizart> hello, [21:41] <kwizart> shall we enable thumb on ARM (armv7hl) by default ? [21:42] <kwizart> for a 'general purpose' distro binary built ? [21:43] <kwizart> specially current libavcodec/arm/dca.h has: [21:43] <Compn> no idea [21:43] <kwizart> #if HAVE_ARMV6_INLINE && AV_GCC_VERSION_AT_LEAST(4,4) && !CONFIG_THUMB [21:43] <Compn> if an arm device doesnt have thumb support, does it crash ? [21:43] <kwizart> and the alternative is neon (which cannot be assumed because of tegra2) [21:44] <Compn> i'd just try with/without thumb on a bunch of devices and report speed benchs to find out if yay or nay :P [21:44] <Compn> instead of aks first, just benchmark first :) [21:44] <kwizart> I think all armv7 has thumb, but I undertand thumb as a reduced instruction set [21:44] <Compn> or wait for arm master to awaken [21:46] Action: Compn afk [21:47] <kwizart> ok thx [00:00] --- Thu Nov 21 2013