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

[burek]

[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