[00:21] <J_Darnley> Oh my god! gcc doesn't warn you if you stupidly do this: [00:21] <J_Darnley> for (int i; ...; ...;) [00:30] <nevcairiel> What happens if you do this? [00:34] <BtbN> random stuff. But it should warn about the uninitialized var [00:46] <J_Darnley> nevcairiel: BtbN is right. Without initialising i can be any value [00:47] <J_Darnley> I happened to get a large negative number [00:47] <J_Darnley> which wasn't very useful for use as an index in an array. [00:47] <J_Darnley> It caused a segfault but it was fairly easy to trace back in this case. [00:48] <J_Darnley> Perhaps this is an argument to not use this C99 convenience [00:49] <BtbN> if it realy does not generate a warning, you should propably report a bug to gcc [00:50] <J_Darnley> ugh. I guess I should [00:50] <J_Darnley> First I better confirm it with a test case. [00:51] <nevcairiel> Did you enable the warnings for uninitialized stuff? Not sure which level includes those [00:52] <J_Darnley> Wall and Wextra [00:54] <J_Darnley> I will check that before I attempt to report [00:54] <nevcairiel> For kicks try again with Wuninitialized, no idea if its included [00:55] <J_Darnley> hmm doesn't look like it. [01:01] <cone-53> ffmpeg.git 03Michael Niedermayer 07master:525a165d9985: avfilter/vf_pullup: workaround bug in gcc 4.4.3 on ARM [01:08] <J_Darnley> Oh it already exists: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467 [01:09] <J_Darnley> With a dubious closed status [01:13] <J_Darnley> I'll post it again because it didn't warn me in a very real case. [01:30] <BBB> jamrial: if you care, new patch on github to convert int16 functions also (needs testing on win64, and some benching) [01:30] <BBB> jamrial: Im probably gonna leave it as-is (maybe convert double) and focus on more useful things again, so if you want to do fma4/xop, thatd be cool [01:30] <BBB> (over-optimizing a function like this is kinda silly) [01:32] <J_Darnley> Actually I'm not going to post. It looks like this might be the 7th most reported bug. [01:37] <jamrial> yeah, i'll do fma/xop [01:38] <jamrial> btw, benched float on win64 this morning and got 65->63 common, 110->92 linear [01:39] <jamrial> maybe J_Darnley can bench as well to double check, because i found it unusual. quite the boost for linear and a really small change for common [01:47] <BBB> gcc did a really good job on common [01:48] <BBB> like, a really good job [01:48] <BBB> so Im not totally surprised it only goes down by a bit [01:48] <Daemon404> obligatory "which gcc" [01:48] <BBB> I was surprised how good code it generated [01:48] <BBB> that too [01:50] <jamrial> btw, you should add your name to resample.asm. probably replacing mine for that matter [01:51] <jamrial> you pretty much rewrote the entire thing after all [01:51] <BBB> jamrial: .. maybe - wanna convert the double sse2 function for me? [01:51] <BBB> Im feeling lazy [01:51] <BBB> kids arent helping productivity much [01:53] <BBB> and updated patch on github to add me as co-author of that file [01:53] <jamrial> i'll give it a try [01:54] <BBB> shouldnt be terribly hard, but who knows [01:55] <BBB> hopefully the float can serve as most-of-the-template (and multi-format support already exists with int16) [02:23] <J_Darnley> BBB jamrial: can I bench it tomorrow or would you like me to do it now? [02:24] <jamrial> do it whenever you can, no hurry [02:24] <jamrial> it's just to cross check results. the code is already commited and confirmed faster [02:34] <BBB> J_Darnley: tomorrow is fine, no hurry [02:57] <jamrial> BBB: win64 and 32bits int16 (sse2 and mmxext) all work [03:00] <cone-358> ffmpeg.git 03Michael Niedermayer 07master:f02a4408149c: ffmpeg_opt: route -ab to -b:a [03:25] <jamrial> BBB: got double working. on top of the int16 patch [03:26] <cone-358> ffmpeg.git 03Michael Niedermayer 07release/0.10:6a968073daa7: avutil/lzo: Fix integer overflow [03:26] <cone-358> ffmpeg.git 03Luca Barbato 07release/0.10:e7f5dacd55de: lzo: Handle integer overflow [03:26] <cone-358> ffmpeg.git 03Reinhard Tartler 07release/0.10:359383c98308: Prepare for 0.8.13 Release [03:26] <cone-358> ffmpeg.git 03Reinhard Tartler 07release/0.10:e122fb594a5f: Update Changelog for 0.8.13 [03:26] <cone-358> ffmpeg.git 03Michael Niedermayer 07release/0.10:d77ad6ec2d14: Merge commit 'e7f5dacd55deeee8a866020b8463f829b2c5971f' into release/0.10 [03:26] <cone-358> ffmpeg.git 03Michael Niedermayer 07release/0.10:a907fc0b21fa: Merge commit 'e122fb594a5feb6729cce86a70aafd93d10202d8' into release/0.10 [03:31] <cone-358> ffmpeg.git 03Michael Niedermayer 07release/0.10:9153b33a742c: update for FFmpeg 0.10.14 [03:33] <Timothy_Gu> michaelni: tickets 3748-3751 are spams. Can you add the IP of the offender to BadIP? [03:41] <michaelni> Timothy_Gu, added [03:43] <Timothy_Gu> BTW, i WHOIS'd the IP http://myip.ms/view/ip_addresses/3423563264/204.15.110.0_204.15.110.255 [03:43] <Timothy_Gu> And the ISP seems to be called "Hoyos Consulting" [03:52] <Timothy_Gu> michaelni: another one [04:09] <cone-358> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n0.10.14': unknown revision or path not in the working tree. [04:09] <cone-358> Use '--' to separate paths from revisions [04:09] <cone-358> refs/tags/n0.10.14:HEAD: ffmpeg_opt: route -ab to -b:a [10:35] <iamtakin1iteasy> hello, i am trying to generify FreeType2/fontconfig handling in ffmpeg, since after introduction of aalib video filter, this part starts to be common with drawtext video filter, but i am not sure what to do with public API and ABI. i think better to explain this starting from the public header of freetypeutils component of libavfilter: http://paste.eientei.org/show/238/ -- here i am trying to [10:35] <iamtakin1iteasy> offer a generic interface to both freetype and fontconfig at once, but each of them may be unavailable at compilation time, depending on ./configure options, so if in my structure FFFreetypeContext i can't simply use FT_Library and FcConfig structures, but rather have to either guard them with #ifdef <lib> (which will be changing structure size) or using void* pointers (which is not type-safe), [10:36] <iamtakin1iteasy> so my question would be: what is preferable - type-safety or constant struct size? or maybe sacrifice clarity of code and use #ifdef <lib> FT_Library *ft_library #else void * ft_library #endif construction? [10:39] <ubitux> while the fontconfig can be considered optional, is it really the case for FT? [10:40] <ubitux> like, let's take drawtext for instance: it has a hard dep on FT [10:40] <ubitux> so you're wrapper won't be necessary if FT is not available [10:41] <ubitux> it looks like to me the question only stands for FC [10:41] <iamtakin1iteasy> vf_drawtext is hard dependent on FT, but as far as i understood vf_drawtext itself is optional depending on FT selection [10:42] <iamtakin1iteasy> but this is video filter [10:42] <ubitux> that doesn't change the fact that this wrapper -in the case of drawtext at least- won't be build unless FT is available [10:43] <ubitux> what is this aalib filter you're talking about? [10:44] <wm4> meh [10:44] <iamtakin1iteasy> hm, got it, it is more a matter of buildsystem rather than code. [10:44] <wm4> why not just use libass [10:45] <iamtakin1iteasy> aalib filter didn't passed review yet [10:45] <ubitux> ah it was submitted? [10:45] <wm4> also, for aalib the hardcoded tty font would be better [10:45] <ubitux> missed that [10:45] <wm4> probably [10:45] <iamtakin1iteasy> basically, it uses aalib to render frames as ascii-art and rastarizes them back with FT [10:45] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2014-June/159169.html ah, mmh ok. [10:46] <iamtakin1iteasy> current version on review is outdated a bit, so don't look hard on it [10:46] <iamtakin1iteasy> i have santized it's code a lot during this time [10:46] <wm4> iamtakin1iteasy: see libavutil/xga_font_data.h and libavcodec/ansi.c [10:47] <ubitux> yeah that sounds like you could use some vga fixed width char [10:47] <ubitux> and you wouldn't need FT/FC [10:48] <iamtakin1iteasy> but it is a point of aalib filter i want :/ i wish to select font sizes and faces to fine-tune the ascii-art effect [10:48] <iamtakin1iteasy> for instance, Terminus is not anything like Liberation Mono [10:49] <ubitux> ok [10:50] <iamtakin1iteasy> but still, FC is being optional and pretty nice feature to have [10:50] <iamtakin1iteasy> should i have it's handle as void* or guareded with #if LIBFONTCONFIG ? [10:50] <wm4> never use void* for opaque things [10:50] <ubitux> wm4: why? [10:51] <wm4> ubitux: because it sucks [10:51] <iamtakin1iteasy> well, C sucks at type-safety when it comes to any type of pointer anyways :/ [10:51] <wm4> opaque structs are better because they give you a minimum of type-safety [10:51] <wm4> C doesn't suck, people who think they know C but don't suck [10:52] <wm4> and that's why ever shitty API does typedef void *something_t; [10:52] <iamtakin1iteasy> well, FcInitLoadConfigAndFonts() returns pointer anyways [10:53] <iamtakin1iteasy> so even in FC API it would be FcConfig* [10:53] <ubitux> #if CONFIG_LIBFONTCONFIG #include ... #define FCTYPE FcConfig #else #define FCTYPE void #endif [10:53] <ubitux> :-° [10:54] <ubitux> but well, you could just add some idefery inside the struct [10:55] <wm4> iamtakin1iteasy: you could provide something to generate and load bitmap fonts in a custom format [10:55] <wm4> still sounds better than letting fontconfig/freetype use spread [10:56] <iamtakin1iteasy> well, maybe it is for a developer, but isn't a bit too much inconvinient for end-user? [10:56] <wm4> what enduser wants an aa filter [10:56] <iamtakin1iteasy> using FT/FC you can easily tweak sizes and faces [10:56] <iamtakin1iteasy> me! [10:56] <iamtakin1iteasy> :) [10:56] <wm4> a single person? [10:57] <iamtakin1iteasy> well, i hope not only me [10:57] <iamtakin1iteasy> but i wish to stream films/animation in ascii-art [10:57] <wm4> also there are already things like libcaca which do this [10:57] <iamtakin1iteasy> no! [10:57] <wm4> I think aalib also has a X backend [10:57] <iamtakin1iteasy> libcaca is different thing [10:57] <iamtakin1iteasy> it doesn't produces neat aa-like output [10:57] <wm4> and oh joy, libavdevice indeed has a caca output [10:58] <iamtakin1iteasy> but it's output, which simply displays the result on a screen [10:58] <iamtakin1iteasy> not rastarizing it back to frames [10:58] <wm4> so? [10:58] <ubitux> wm4: the point is to have a customed ascii-like rendered video [10:59] <wm4> so useful [10:59] <ubitux> so what [10:59] <iamtakin1iteasy> it deosn't fit my use-case. i want to take a regular movie, process it with aafilter and stream it over RTMP [10:59] <iamtakin1iteasy> preferably in real-time [10:59] <wm4> are you running some sort of joke video streaming site? [10:59] <iamtakin1iteasy> yes [11:00] <iamtakin1iteasy> and there are titles that *must* be watched in aa [11:00] <iamtakin1iteasy> SE:Lain for instance [11:02] <wm4> anyway, fontconfig is a big problem and is foreign to all major platforms (except Linux, if you want to call that major) [11:05] <ubitux> wm4: do you think !linux user will care about aa output? ;) [11:05] <wm4> I think nobody will care about it [11:05] <ubitux> (do you have an alternative?) [11:06] <wm4> alternative to what? [11:06] <ubitux> FC [11:06] <wm4> if there was, libass would already use it [11:06] <ubitux> then there is no reason not to use it [11:07] <wm4> libass will probably be free of FC on windows and osx in the near future [11:07] <wm4> with great effort [11:07] <iamtakin1iteasy> isn't OSX has it's version of FC? [11:08] <wm4> all platforms have their own font lookup APIs [11:08] <ubitux> wm4: replaced with what? [11:08] <iamtakin1iteasy> looks like, if not using FC, FFmpeg will have to invent it's own :/ [11:08] <wm4> ubitux: coretext on osc [11:09] <wm4> *osx [11:09] <ubitux> why isn't that part of FT btw? [11:09] <wm4> outside of the scope of FT [11:10] <ubitux> and FC is not able to use coretext on OSX? [11:10] <wm4> apparently not [11:11] <wm4> they don't care about other platforms anyway [12:00] <wm4> DVD is so fucked up [12:01] <wm4> I wonder whether it would make sense to provide a libavformat dvd demuxer [12:01] <wm4> but since dvd requires dealing with menus and user interaction, probably not [12:05] <ubitux> same as bluray [12:05] <ubitux> and it would definitely help [12:08] <wm4> both dvd and bluray allow title switching [12:08] <wm4> which doesn't fit into the lavf api at all [12:08] <wm4> since audio/subtitle streams and stream languages will change [12:09] <wm4> changing the title is basically like loading a different file [12:09] <wm4> and what would you do about user interaction (menus)? [12:09] <ubitux> i'd say it can be ignored [12:10] <wm4> ignored? [12:10] <ubitux> we have support for bluray, and it's more than useful [12:10] <ubitux> yes, the dvdnav [12:10] <wm4> haha [12:10] <wm4> no [12:10] <wm4> I don't want a shitty half-assed solution (I already have that in my own code) [12:11] <ubitux> well, in the ffmpeg scope it has its usage [12:11] <wm4> and excluding menus (btw. bluray also has menus) belongs to that [12:11] <ubitux> (i don't need menu to transcode a bd) [12:11] <wm4> yeah right I forgot lav* is for transcoding only [12:11] <ubitux> that's not what i'm saying [12:12] <ubitux> i'm saying even with no menu it covers a large use-case [12:13] <ubitux> now if you want interaction, that probably requires a different lavd [12:13] <wm4> "different lavd" ?? [12:14] <ubitux> improved* lavd [12:14] <ubitux> different api [12:15] <wm4> that doesn't change anything about the title switching problems [12:15] <ubitux> what's this title switching thing? [12:15] <wm4> I explaine dit above [12:15] <ubitux> well [12:15] <ubitux> lavf could raise packets of every stream/file [12:16] <ubitux> in parallel [12:16] <wm4> not sure I understand [12:16] <ubitux> not very optimal but it would fit in the current design [12:16] <ubitux> wm4: every title would be opened [12:17] <wm4> the API doesn't allow that [12:17] <wm4> libdvdnav API I mean [12:18] <ubitux> should we use an AVOption hack just like the ogg thing to control the demuxing? [12:18] <wm4> what ogg thing? [12:19] <ubitux> the tags [12:19] <ubitux> already forgot what it was doing actually [12:19] <wm4> updating tags via side-data [12:20] <ubitux> ok [13:30] <cone-161> ffmpeg.git 03Clément BSsch 07master:b18d1b094e90: avfilter/buffersrc: reindent [13:30] <cone-161> ffmpeg.git 03Clément BSsch 07master:d5f817793e29: avfilter/overlay: reindent [13:35] <BBB> jamrial: cool, thanks, I guess I can send the int16 one out [13:35] <BBB> michaelni: btw, about swr int16/32, Im pretty 100% sure that the int32 codepath routinely overflows? if input is 32 bits and filter is 30 and src_incr is another up to 20 or so, that never fits in 64 bit [13:36] <BBB> michaelni: I mean this line: val += (v2 - val) * (FELEML) frac / c->src_incr; [13:37] <BBB> jamrial: or you can send the int16 one out as part of your patchset if you like [13:48] <J_Darnley> Oh yeah! (As the koolaid guy might say) I've got the superscope working. [14:24] <michaelni> BBB, fixed, ill post a patch soon [14:29] <Daemon404> [11:01] <+wm4> I wonder whether it would make sense to provide a libavformat dvd demuxer <-- pls no [14:30] <wm4> Daemon404: what would you have against it? [14:30] <Daemon404> "demuxer" [14:30] <Daemon404> menus and stuff [14:30] <Daemon404> etc [14:30] <wm4> I know [14:31] <Daemon404> im sure j-b has strong feelings here ;) [14:31] <wm4> IMO, actually libdvdnav should contain a mpeg demuxer [14:32] <Daemon404> as in ps? [14:32] <wm4> yes [14:32] <Daemon404> wouldnt be a terrible idea [14:33] <Daemon404> but nobody is going to do that [14:33] Action: Daemon404 looks at libdvdnav;s code [14:33] <wm4> yeah, parts of it look like copy&pasted mplayer code [14:33] <BBB> michaelni: itd be cool if the division in that statement became a multiplication, esp. for bitexact int math matching (for float, I already changed it to a multiply) [14:35] <BBB> michaelni: since div requires me to go outside simd which is kinda silly [14:35] <BBB> (for int) [14:37] <Daemon404> wasnt there some big text file of equivalent mul/shr for divs [14:40] <Daemon404> heh... facebook ads are showing me HEVC books [14:40] <Daemon404> ~stalking~ [14:56] <michaelni> BBB, patches posted, just saw your comment now, feel free to change the int C side to what is matches and is convenient for SIMD [14:57] <michaelni> what matches [14:59] <BBB> ok [14:59] <BBB> can I also change src_incr to be max 16 bits for int16? [14:59] <BBB> that makes a lot of things simpler [14:59] <BBB> 15bits is even nicer (pmulhrsw) [15:01] <michaelni> for the linear interpol, 15bits should be fine, but the state variables that are used in resampling need more than 15bit i think. Even "48khz" wont fit in 15bit [15:01] <Daemon404> grmbl, i cant find said list, which was posted on reddit of all places [15:02] Action: Daemon404 rememberes massimo's thing [16:31] <cone-414> ffmpeg.git 03Michael Niedermayer 07master:cddbf95c5f0d: doc/examples/resampling_audio: use av_freep() for saftey [16:31] <cone-414> ffmpeg.git 03Michael Niedermayer 07master:3f42434600f2: avcodec/huffyuvencdsp: try to fix misaligned access [17:28] <cone-414> ffmpeg.git 03Michael Niedermayer 07master:7f5d75f95b65: cmdutils: ignore sws_flags if swscale is not enabled [20:31] <jamrial> BBB: https://github.com/jamrial/FFmpeg/commits/swr [20:36] <BBB> will check in 1 hr or so, ok? [20:37] <jamrial> ok [21:12] <BBB> Ill probably make some small changes to the int16 patch over time, but perhaps after committing the original one [21:12] <BBB> so all inline is gone now right? [21:13] <BBB> also, sugestion for float/double [21:13] <BBB> mostly, the difference is just a s/d diff in instruction [21:13] <BBB> so [21:14] <BBB> can we make s/d a optional 4th macro argument, and merge the code for them? so itd be mulp%4, addp%4, etc. [21:16] Action: Daemon404 wonders what posessed BBB to hack on swr [21:16] <BBB> ... [21:16] <BBB> :) [21:24] <nevcairiel> The inline asm bugged him [21:30] <Daemon404> perhaps you mean offended [21:33] <jamrial> BBB: double has a couple instructions less in the horizontal add [21:34] <jamrial> but aside from that yeah, it's mostly s/d diff [21:46] <BBB> ok, I guess partial merge with a few %ifidn %1, float & do the extra step in the hadd & %endif [21:46] <BBB> but that would still look nice [21:51] <BBB> cpuflag)avx) still works right? (re: fma patch) [21:51] <BBB> since fma means cpuflag(avx) returns true, right? [21:51] <jamrial> yeah [21:53] <jamrial> i changed the cpuflag(avx) check with mmsize == 32 since i added both an xmm fma4 and ymm fma3 versions, and both imply avx [21:54] <BBB> hm& I see, right [21:54] <BBB> ok thats fine then [21:54] <BBB> I dont understand the last bit of the xop patch [21:54] <BBB> line 507-514 [21:54] <BBB> https://github.com/jamrial/FFmpeg/commit/c1ea59f7273db604e6f5270f999da2a5e13... [21:55] <jamrial> that's basically the HADDD macro [21:55] <BBB> it may just be me misparsing it, but it looks like the pshufd was removed? [21:55] <jamrial> yes, i replaced with PSHUFLW [21:55] <BBB> so pshuflw == pshufd? [21:56] <BBB> weird macro [21:56] <BBB> anyway if its the same code I dont mind [21:56] <BBB> odd macro name perhaps [21:56] <jamrial> no, it's pshuflw for mmsize == 16, and pshufw for mmsize == 8 [21:56] <BBB> hm& oh I see [21:56] <BBB> right [21:56] <BBB> doh [21:56] <BBB> ok thats ok then [21:56] <BBB> that took me forever to parse [21:56] <BBB> ok rest is good [21:57] <BBB> so I guess at your option merge a little of the pd/ps code if you think it makes sense (since later you remove that again for the fma3/4 code), and otherwise its ok [21:57] <BBB> do you have benchies? [21:58] <jamrial> i could instead just use the HADDD macro like in common which will be cleaner, but i decided to interleave the instructions instead [21:58] <jamrial> should do the former? out of order execution should in theory take care of it [21:59] <jamrial> i benched fma3 on ubitux's rig and it was faster than avx. especially for linear [21:59] <BBB> cool [21:59] <jamrial> didn't bench any of the int16 [21:59] <BBB> (neither did I) [21:59] <BBB> :-p [22:00] <jamrial> hehe [22:05] <jamrial> i suppose resampling of double precision is rarely used, right? [22:09] <BBB> I guess so [22:10] <BBB> I mean, Im by no means an expert [22:10] <BBB> but the audio I worked on was typically float, or int16 or the lower-end stuff [22:11] <jamrial> yeah. probably not worth adding an avx/fma version for it then [22:29] <cone-376> ffmpeg.git 03Michael Niedermayer 07master:c5a405c4f070: swresample/resample_template: flip order of operations in swri_resample_linear() for 32bit [22:33] <jamrial> ok, pushed new version with the ps/pd changes [22:49] <cone-634> ffmpeg.git 03Matthew Oliver 07master:09adb1dd364f: configure: enable lto for icl compiler. [22:49] <cone-634> ffmpeg.git 03Michael Niedermayer 07master:86576129bd22: Merge remote-tracking branch 'cehoyos/master' [23:05] <BBB> jamrial: ok I had no other comment, so feel free to merge it all (or submit it all) [23:11] <jamrial> ok, i'll send it later today [23:12] <jamrial> BBB: btw, you're still checking for HAVE_SSE2_INLINE for the yasm port in your int16 patch [23:15] <kierank> "If i understood well google with vp9 while working on 10/12 bit wants to switch everything to 16 bit internally and other decoders already do this." [23:15] <kierank> wtf [23:15] <kierank> are they nuts [23:15] <kierank> unattributed quote however [23:45] <nevcairiel> Those people usually don't understand anything correctly [23:58] <BBB> jamrial: just change it :) [23:58] <jamrial> alright [00:00] --- Mon Jun 30 2014