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

[burek]

[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/c1ea59f7273db604e6f5270f999da2a5e1315170
[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