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

[burek]

[01:20] <michaelni> Daemon404, about fateserver, any patches that can be applied ?
[01:25] <michaelni> more specifically patch 2 (and possibly 3) 
[01:26] <Daemon404> [FFmpeg-devel] [PATCH 2/5] [FATESERVER] index: move $paramsdeclaration to lsort()
[01:26] <Daemon404> can
[01:26] <Daemon404> 3 isnt OK as-is
[01:27] <Daemon404> it has stray changes
[01:28] <michaelni> i can drop them when applying
[01:28] <michaelni> if thats the only thing
[01:28] <Daemon404> it might be ok
[01:28] <Daemon404> i am not terribly familiar with perl html stuff
[01:28] <Daemon404> perl cgi dev is before my time...
[01:41] <michaelni> put on fate.ffmpeg.org, seems working, thanks
[01:42] <Daemon404> i hope you remembered the extra cpan modules
[01:45] <michaelni> extra cpan modules ? i tested the code on the server before pushing to the main repo
[01:47] <Daemon404> heh k
[01:47] <Daemon404> patch 3 had two more use statements added
[02:22] <jamrial> http://fate.ffmpeg.org/log.cgi?time=20140607225141&log=compile&slot=x86_64-archlinux-gcc-random
[02:22] <jamrial> configure needs a line with wmalossless_decoder_select="llauddsp"
[02:36] <BBB> j-b: question I read somewhere and Im kinda intruiged; hows the video editor proejct going?
[03:01] <cone-486> ffmpeg.git 03Michael Niedermayer 07master:5183fac92fc5: avcodec/hevc_sei: fix invalid get_bits() in a comment
[03:01] <cone-486> ffmpeg.git 03James Almer 07master:fc8db12a73f1: x86/vp9: inital AVX2 intra_pred
[03:17] <cone-486> ffmpeg.git 03Michael Niedermayer 07master:d4be3a8d6312: configure: add llauddsp dependancy for wmalossless_decoder
[03:17] <michaelni> jamrial, added, thx
[03:55] <jamrial> and with that avx2 made its debut
[04:27] <unlord> hi
[04:27] <unlord> what is the valid range of -q:v for -f h263 ?
[08:45] <funman> michaelni: I looked at the 'Technology demos' on https://www.xiph.org/daala/
[09:25] <funman> https://people.xiph.org/~xiphmont/demo/daala/daala-vp9summit-20140606.pdf
[09:38] <UtUser> yo JEEB
[10:27] <thardin> ooh daala news
[10:53] <j-b> BBB: a bit further, why?
[13:15] <BBB> j-b: is there a status page or website with some screenshots or so?
[13:15] <BBB> j-b: like I said, asked on a website, would be nice to respond with some actual useful info
[13:32] <cone-834> ffmpeg.git 03James Almer 07master:dcaf9660b610: x86/float_dsp: port vector_fmul_window to yasm
[14:04] <Daemon404> man that thread just wont stay dead
[14:04] <wm4> they're using ffmpeg? wtf
[14:05] <Daemon404> who is?
[14:05] <wm4> in the hevc in flv thread
[14:05] <wm4> "There have a lot of customers play flv using outside of Adobe FlashPlayer; For example: Porting FFmpeg into Android."
[14:06] <nevcairiel> that doesnt explain why you would want flv to be the format of choice
[14:06] <Daemon404> indeed
[14:07] <wm4> yes that's the wtf
[14:07] <wm4> normally you'd pick flv only for compatibility, right
[14:08] <Daemon404> well -> china
[14:08] <Daemon404> you expect logic?
[14:08] Action: Daemon404 runs
[14:14] <ubitux> http://tiny.cc/wmx4gx
[14:15] <Daemon404> ubitux, definitely
[14:15] <Daemon404> but not wrong.
[14:15] Action: Daemon404 points at realmedia
[14:16] <nevcairiel> hey hey, we're not doing that based on their race, just their country
[14:16] <nevcairiel> find a new word!
[14:17] <Daemon404> lol
[14:44] <Daemon404> hah
[14:44] <Daemon404> "A real spec is *not optional*"
[14:44] Action: Daemon404 applauds monty
[14:45] <Daemon404> the pitfalls to avoid slide could also be named "A History of VPX"
[14:46] <ubitux> American History VPX
[14:47] <BBB> Daemon404: where?
[14:47] <BBB> (where did you get the slides?)
[14:47] <Daemon404> [08:25] < funman> https://people.xiph.org/~xiphmont/demo/daala/daala-vp9summit-20140606.pdf
[14:47] <Daemon404> BBB ^
[14:48] <Daemon404> that said, i dont think daal is being gone about in a 'good' way ;)
[14:54] <BBB> daala is exactly the same as libvpx, just a different team
[14:54] <BBB> locked up in their own private space (mozilla office and #daala instead of google office)
[14:54] <BBB> no outside participation
[14:55] <BBB> weve seen this with that audio codec they did, what was it called again?
[14:55] <ubitux> opus
[14:55] <BBB> right, opus
[14:55] <ubitux> they look more open though
[14:55] <BBB> my mouth looks more open
[14:55] <ubitux> like, every research step is documented
[14:55] <Daemon404> opus wasnt xiph
[14:55] <Daemon404> half of it was SILK, from skype/ms
[14:56] <ubitux> i'm refering to daala here
[14:56] <Daemon404> i know
[14:57] <Daemon404> also: derfcode.
[14:57] <Daemon404> whitespace be damned
[15:14] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:6e6bd5481cf4: avcodec/alsdec: Clear MPEG4AudioConfig so that no use of uninitialized memory is possible
[15:14] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:ee5145c05d4c: avcodec/aacpsy:  Use av_mallocz_array()
[15:17] <kierank> Daemon404: I thought I killed that thread
[15:17] <Daemon404> everyone and their grandma has to comment
[15:17] <Daemon404> this time it raised mile melanson from the dead
[15:17] <Daemon404> mike*
[15:19] <kierank> I was going to ask him for an hevc in avi patch
[15:20] <Daemon404> lol
[15:20] <kierank> But I think he would do it
[15:20] <Daemon404> yes
[15:32] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:7c3af60016e6: avformat/movenc: use av_malloc(z)_array()
[15:32] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:007547b2820f: avcodec: fix () in TRANSPOSE macro
[16:19] <ubitux> yay got a working a ffhq2x :)
[16:30] <J_Darnley> *applause*
[16:32] <ubitux> the switch is essentially translated in 30 lines of code&
[16:32] <ubitux> i'm going through some macro magic to avoid having them duplicated 4x
[16:33] <ubitux> it will probably be a bit larger for hq3x and hq4x
[16:33] <ubitux> but i think the whole hq[234]x filter will stick in about 1k lines of code
[16:39] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:ab1e1917209c: avcodec/pthread_frame: Use av_mallocz_array()
[16:39] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:4959c4a79331: avcodec/pthread_slice: Use av_malloc(z)_array()
[17:54] <BBB> Daemon404: I read that and Im reminded of the libav vs. ffmpeg flamewars, somehow
[17:55] <BBB> ohwell
[17:57] <Daemon404> BBB, which?
[17:57] <Daemon404> the pdf?
[18:02] <BBB> Daemon404: yes
[20:14] <BtbN> Is there simply no accelerated transform from yuv to rgb in libswscale, or is something wrong with my build of it?
[20:15] <BtbN> yuv420p to rgb24 to be exact
[20:22] <jamrial> there seems to be in x86/yuv2rgb.c
[20:22] <cone-834> ffmpeg.git 03James Almer 07master:85065d2a7ce3: x86/float_dsp: add missing femms
[20:23] <BtbN> strange
[20:24] <BtbN> cause it tells me on the console: [swscaler @ 00000086F6D6D640] No accelerated colorspace conversion found from yuv420p to rgb24.
[20:27] <nevcairiel> are you on something crazy as not-x86? :p
[20:28] <BtbN> nope
[20:28] <BtbN> it's a windows msvc build though
[20:28] <jamrial> the asm is inline
[20:28] <jamrial> so that's why
[20:29] <nevcairiel> yeah msvc wont have those
[20:29] <BtbN> hm, that's extremely annoying
[20:29] <nevcairiel> patches welcome
[20:29] <nevcairiel> note that the "accelerated" yuv->rgb conversion is extremely low quality anyway
[20:29] <nevcairiel> feels like chroma point scaling from looking at it
[20:30] <BtbN> in the end i just want an OpenGL texture, but implementing hw acceleration with all the possible APIs is a little too much
[20:42] <wm4> it's pretty easy to write a shader that does the conversion
[20:43] <BtbN> there already is another shader in place that does some other stuff with the images
[20:45] <wm4> use a framebuffer
[20:45] <BtbN> it's already barely managing to keep 24 fps without additional work on the gpu
[20:46] <wm4> then either the gpu is extremely weak, or the other shader is extremely inefficient
[20:46] <BtbN> it's just a lot of work
[20:57] <nevcairiel> a simple yuv->rgb shader should be very light load on the gpu
[20:58] <nevcairiel> they are really good at that
[21:04] <BtbN> but it would require another conversion so the data is in some format that cen be uploaded into a texture
[21:05] <BtbN> *a
[21:11] <BBB> BtbN: its easy to convert inline asm to yasm (if youre a developer; this is #ffmpeg-devel, after all)
[21:12] <BBB> its one of those things that has to be done at some point
[21:12] <BtbN> would propably be easier to just build it with gcc and generate an msvc compatible .lib file though
[21:12] <nevcairiel> its not like ffmpeg build system doesn't do that for you
[21:12] <kierank> w i
[21:13] <BtbN> nevcairiel, it already generates a def/lib when building with mingw?
[21:13] <nevcairiel> of course
[21:14] <nevcairiel> at least for shared builds, but thats really when you need them, otherwise you just link with the .a file :p
[21:14] <nevcairiel> (static linking with mingw builds against msvc apps is also rather painful)
[21:14] <BtbN> linking .a files from gcc into msvc wouldn't work anyway
[21:14] <nevcairiel> it does work, but its painful, needs some special kinds of evil
[21:15] <Daemon404> it doesnt work
[21:15] <Daemon404> it "works"
[21:16] <nevcairiel> for shared builds, its beneficial to have the msvc tools in path, so that it can use the msvc library generator instead of the mingw one, it just works better
[21:16] <nevcairiel> lib.exe, i mean
[21:17] <BtbN> i'll just re-generate the .lib file manualy later from the def
[21:20] <BBB> its much nicer if someone does actual effort and converts the inline to yasm
[21:20] <BBB> but why do the right thing if we can get away with a massive ugly trollhack just for this one little time, right?
[21:21] <nevcairiel> its swscale, i wouldn't want to try to start converting all its macro'ed hacks into yasm =p
[21:22] <BBB> I converted some of the actual scaling routines in yasm
[21:22] <BBB> I didnt touch the direct conversion routines, but ohwell
[21:22] <BBB> I did some stuff
[21:48] <llogan> "Subject: Hope add HEVC video format support to flv container"
[21:48] <llogan> approved. heh. more.
[21:48] <llogan> (as in it was in mail queue)
[21:50] <ValdikSS> Hello. Sorry for the question on the dev channel, but is there any way to disable transcoding in ffserver?
[21:53] <wm4> " I always think flv is the best container, because it is so simple, and so easy to extend. "
[22:09] <nevcairiel> Wait. Another guy sent a patch now?
[22:11] <llogan> yes, but i didn't see if there were any differences, or if it is the same patch floating around the Chinese guys.
[22:12] <Daemon404> what the shit
[22:12] <ubitux> lol
[22:12] <ubitux> can't stop them
[22:12] <ubitux> :D
[22:14] <llogan> they will brute force it in
[22:14] <Daemon404> i dont see it
[22:15] <llogan> it was delayed due to queue. look for "Hope add"
[22:15] <jamrial> why do they need it in the official repo? why not just hack that thing in their own builds like they have probably been doing until now?
[22:15] <Daemon404> 0 results llogan 
[22:16] <Daemon404> oh
[22:16] <Daemon404> its in my spam folder
[22:16] <Daemon404> probably should leave it tther
[22:16] <llogan> it should be
[22:16] <Daemon404> e
[22:16] <Daemon404> there*
[22:17] <Daemon404> wut
[22:17] <Daemon404> i read that email address as the "weng chang gang"
[22:17] <Daemon404> rivals to wu tang perhaps
[22:18] <Daemon404> And many containers can hold this void format, for 
[22:18] <Daemon404> example, mp4/TS/MKV/AVI.
[22:18] <Daemon404> >AVI
[22:18] <Daemon404> :(
[23:02] <cone-834> ffmpeg.git 03Michael Niedermayer 07master:7d8a60a44298: avcodec/options_table: improve max/min rate help text
[23:04] <ubitux> before : http://b.pkh.me/hq2x.c
[23:04] <ubitux>  after : http://b.pkh.me/vf_hqx.c
[23:06] <Daemon404> still terrifying
[23:06] <Daemon404> but less so
[23:06] <ubitux> well, 2800 lines to 300
[23:06] <ubitux> that sounds reasonable
[23:06] <ubitux> but yeah, that's a bit tricky
[23:06] <ubitux> need to do hq3x and hq4x now
[23:07] Action: michaelni puts http://b.pkh.me/hq2x.c in avi
[23:07] <ubitux> MKTAG('h','q','2','x')
[23:09] <ubitux> anyway, the insanity in hq2x_interp() is basically generated by parsing hq2x.c
[23:09] <ubitux> i just copy pasted the result from my python scripts (https://github.com/ubitux/hqx / "make code")
[23:21] <iive> ubitux: what are these hq<n>x supposed to do?
[23:22] <iive> yff, scale
[23:22] <ubitux> pixel-art zoom x2 x3 x4
[23:22] <ubitux> (http://en.wikipedia.org/wiki/Hqx)
[23:23] <iive> so, enhance , enhance... got the face of the killer
[23:24] <ubitux> yeaaah ~
[23:25] <iive> and the killer is.... smiley face :)
[23:26] <jamrial> SNES emulation wouldn't have been the same without hqx and similar filters
[23:27] <J_Darnley> Did the algorithm get a quality improvement at some point?  The image on Wikipedia looks much better than any I remember seeing when I was playing SNES games many years ago.
[23:27] <ubitux> i don't think so
[23:27] <ubitux> it's pretty stable...
[23:28] <J_Darnley> I guess it is just the test image then.  Simple shapes should look good
[23:36] <ubitux> i wonder if i should add the threading ;)
[23:37] <ubitux> but well... with 300x200 inputs most of the time
[23:37] <ubitux> :/
[23:44] <J_Darnley> Add a TODO or FIXME of "add threading"?
[23:44] <J_Darnley> Someone will say it is too slow at some point.
[23:51] <Daemon404> jamrial, hmmm nah
[23:51] <Daemon404> i always liked the crt emulation
[23:51] <Daemon404> reminds me of playing a snes/nes in the early 90s
[00:00] --- Mon Jun  9 2014