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

[burek]

[01:51] <cone-795> ffmpeg.git 03Michael Niedermayer 07master:0545ef7116db: avcodec/mjpegdec: Improve intel jpeg flip heuristic
[03:21] <jamrial> avf_showcqt.c broke msvc 2012
[03:22] <jamrial> seems fminf() is not a thing on it
[05:47] <cone-795> ffmpeg.git 03James Almer 07master:ec98f80af47d: x86/dsputil: move some mmx init code inside dsputil_init_mmx()
[07:10] <UtUser> JEEB I want you to remember the talk we had
[07:11] <UtUser> that UtVideo decoder is the last thing that should be broken
[07:11] <UtUser> right up there with any other lossless codec
[07:11] <UtUser> because now it's not lossless, is it?
[09:21] <ubitux> so this is an example of showaqt http://lucy.pkh.me/showaqt.webm
[09:21] <ubitux> that's pretty nice
[09:24] <ubitux> (yes the encode is not complete because :slow:)
[09:30] <J_Darnley> Is that due to the filter or the encoder?
[09:30] <ubitux> the encoder (libvpx)
[09:31] <ubitux> i had something like 3-4 fps, got tired of waiting
[09:47] <ubitux> ohai durandal_1707 :)
[09:48] <ubitux> long time no see
[09:53] <durandal_1707> i like showcqt
[09:56] <ubitux> yeah showcqt*, wonder why i wrote "aqt"...
[09:56] <J_Darnley> Wow, that's pretty nice
[09:57] <ubitux> these subtitles traumatized me more than i would have expected
[09:57] <J_Darnley> I really should get off my arse, take the plunge, and see if I can get AVS implemented
[10:04] <plepere> ubitux, do you have any feedback on the idct patch I submitted ? The only remark I had on it was to change INIT_MMX mmx to INIT_MMX mmxext.
[10:06] <ubitux> you shouldn't do the mov/add/sar/... at the beginning
[10:06] <ubitux> it should be one single step
[10:07] <ubitux> instr*
[10:07] <ubitux> and actually... since the loop count is kind of hard, you could probably unroll it
[10:08] <ubitux> with a %rep
[10:08] <plepere> ok for the rep
[10:08] <ubitux> kind of hard*coded*
[10:08] <ubitux> (it's always the same loop count depending on the function afaiu)
[10:09] <ubitux> ah, no sorry
[10:09] <ubitux> mmh give me a moment to set up my brain.
[10:10] <plepere> well the loop is %1
[10:10] <plepere> but what instruction could replace mov,add,sar ?
[10:10] <ubitux> yeah you reuse the temp, i was confused
[10:10] <ubitux> plepere: no forget that part
[10:10] <plepere> ok ok
[10:12] <fionag> Can 406-409 be combined into a single add/sar pair, or am I missing something?
[10:12] <fionag> (tempw + ((1<<13-%2)<<1) + 1) >> (14+1-%2) or such
[10:13] <ubitux> having that in the caller won't help btw?
[10:13] <fionag> also I guess is there some reason not to use the paddusb/psubusb trick to avoid having to unpack?
[10:13] <fionag> or some reason it doesn't work
[10:13] <fionag> that would probably be faster for 8-bit, at the least.
[10:15] <plepere> oh, shiny !
[10:16] <plepere> didn't know about that instruction
[10:16] <plepere> but the coeffs are in int16
[10:17] <fionag> I suggest looking at the tricksiness that the h264 idct_dc uses
[10:17] <fionag> I *think* it should be identical for h265.
[10:17] <plepere> so we still need to pass the source from 8 to 16 bit
[10:17] <plepere> I'll look into h264
[10:17] <fionag> look for DC_ADD_MMXEXT_OP
[10:18] <fionag> and DC_ADD_MMXEXT_INIT
[10:18] <plepere> ok ok
[11:10] <plepere> welp,
[11:11] <plepere> fionag, I can use h264_idct_dc_add_8 in HEVC. I just have to change DC_ADD_MMXEXT_INIT add and sar values
[11:13] <fionag> yup, that's what I figured.  dc_add functions are usually pretty close to identical between formats except for the setup.
[11:14] <plepere> so how do I stand on a "legal" standpoint ?
[11:15] <plepere> should I mention x264 project in the top commentaries ?
[11:20] <fionag> I think the dc_add stuff from h264 is from ffmpeg, not x264?
[11:21] <wm4> ubitux: apropos subtitles, was anyone ever interested in a CC "decoder"?
[11:21] Action: fionag sleeps
[11:21] <ubitux> wm4: probably kierank and his broadcaster friends
[11:22] <plepere> fionag, I'll ask michaelni. Thanks a bunch
[11:22] <wm4> vlc seems to have working code for this (although there's one weird difference), and maybe it could be integrated into libavcodec and be made to spit out ASS
[11:23] <wm4> and of course it doesn't work out of the box, because it breaks the usual demuxer->decoder dataflow
[11:24] <ubitux> i have no idea how they work honestly
[11:24] <wm4> the video decoder returns raw CC data as side data
[11:24] <ubitux> ok
[11:24] <wm4> which then has to be fed to the CC decoder
[11:24] <ubitux> nice design
[11:25] <wm4> it's because CC data needs to be reordered like the video frames
[11:25] <wm4> according to kierank, anyway
[11:25] <wm4> though the vlc cc decoder has some weird reordering code on its own
[11:26] <wm4> (plus a comment that it won't work for h264)
[11:26] <ubitux> well
[11:26] <ubitux> what about making a video filter?
[11:26] <ubitux> it can split a video stream into 2 video stream :-°
[11:26] <wm4> that would involve a renderer too
[11:27] <wm4> and then output an alpha video or what?
[11:27] <ubitux> so you feed the filter with the AVFrame and their side data, and that would output 2 streams
[11:27] <ubitux> wm4: yeah for instance
[11:27] <ubitux> ideally... you would have AVSubtitle in avutil
[11:27] <ubitux> add subtitles support in lavfi (here we go again)
[11:27] <ubitux> and could output 1 V 1 S
[11:27] <wm4> anyway, my own hack was creating a dummy stream in the demuxer, and then feeding back the side data to the demuxer
[11:27] <wm4> which in turn returns the CC data as "normal" packet
[11:28] <wm4> this keeps the overall impact on the architecture relatively low
[11:28] <ubitux> would something in ffmpeg help you in that regard?
[11:28] <wm4> hm
[11:29] <wm4> it would be nice if the demuxer could report presence of CC data
[11:29] <wm4> and maybe add dummy sub streams
[11:29] <wm4> and maybe even provide an API function to "feed back" the data
[11:29] <wm4> then the rest could work like with all other subtitle codecs
[11:32] <ubitux> mmh..
[11:34] <wm4> another thing that has to be investigated is whether recreating the CC character grid layout (like teletext) works well enough in ASS
[11:35] <wm4> anyway, whether I'd do that depends if there's interest in this (I only made a proof of concept because a user complained about the removal of the mplayer closed caption code from mpv)
[11:35] <ubitux> btw, is libass ever going to support advanced markups?
[11:35] <wm4> "advanced markups"?
[11:35] <ubitux> so we could rely on it for other subs such as webvtt
[11:35] <wm4> like what
[11:35] <ubitux> yeah like, let's say ruby characters
[11:36] <wm4> what was ruby characters again
[11:36] <ubitux> https://en.wikipedia.org/wiki/Ruby_characters
[11:36] <ubitux> hiragana/katakana above kanji typically
[11:36] <wm4> ah
[11:36] <wm4> you'd have to request it
[11:36] <ubitux> webvtt might support other markup
[11:36] <wm4> and then see if someone feels like implement it
[11:37] <wm4> generally, libass is open to such extensions, I think
[11:37] <ubitux> yeah, the idea is that it would be nice if libass could support such extensions so we could use that extended markup as our internal sub representation
[11:37] <wm4> but also, most works concentrates on performance and vsfilter compat (i.e. 100% insanity)
[11:38] <wm4> well, that feature does sound useful for weeaboo crap
[11:38] <ubitux> it's useful for webvtt :)
[11:38] <wm4> so maybe there'll even be someone to implement this (or not)
[11:38] <ubitux> actually it's more like a design idea
[11:38] <ubitux> libass should be renamed into a libsubrendering or something :p
[11:39] <wm4> libinsane
[11:39] <wm4> currently libass is being multithreaded (lol)
[11:39] <ubitux> heh
[11:40] <wm4> oh, and ffmpeg still uses non-standard ASS
[11:41] <ubitux> yes but no one wants to work on subtitles :(
[11:42] <ubitux> wm4: you know, ffmpeg still doesn't demux the proper ASS markup in mkv
[11:42] <ubitux> (because i'm afraid to break all our api users)
[11:43] <ubitux> it will be at next lavf major bump but i'm pretty sure no one noticed even though it's in APIChanges & Changelog
[11:55] <saste> how can I check the internal properties of H.264 frames, for example if they're using slices or not?
[12:34] <nevcairiel> saste: there are various analyzers for h264, otherwise, debug into the decoder, possibly some av_dlogs might tell you if you enable them
[12:39] <saste> nevcairiel, thanks
[13:32] <cone-901> ffmpeg.git 03Martin Storsjö 07master:e7d6d0bf3c5c: mov: Export geotag metadata fields
[13:32] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:a083543da03e: Merge commit 'e7d6d0bf3c5cc1bc048b0ddbc169a91862568e0c'
[13:41] <cone-901> ffmpeg.git 03Martin Storsjö 07master:2f7065190ad4: libfdk-aac: Relicense the library wrappers to the ISC license
[13:41] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:c2e2b29b73aa: Merge commit '2f7065190ad48744014a02288799d03adfa613e0'
[14:01] <cone-901> ffmpeg.git 03Christophe Gisquet 07master:adf4ee40e737: wma lossless: reuse scalarproduct_and_madd_int16
[14:27] <cone-901> ffmpeg.git 03Carl Eugen Hoyos 07master:d58bcc1921f9: Allow >2G for skip_initial_bytes.
[14:27] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:a80342fe5633: Merge remote-tracking branch 'cehoyos/master'
[15:04] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:97508af274f8: build: add fminf() emulation
[15:14] <BtbN> Do i realy need to wrap ffmpeg headers in extern "C" when using them with C++, or am i doing something wrong?
[15:15] <nevcairiel> you need to, since they are C headers
[15:18] <BtbN> Well, most C headers already have ifdef cplusplus with extern C included
[15:34] <thardin> this is a C shop
[15:42] <ubitux> michaelni: define fminf to... fminf? huh?
[15:47] <wm4> since extern "C" can apparently be nested, there's no reason not to add them to the public headers
[15:47] Action: Daemon404 must be missing context here
[15:48] <nevcairiel> you just joined, what do you expect
[15:48] <Daemon404> blame openssl CVEs
[15:50] <wm4> <BtbN> Do i realy need to wrap ffmpeg headers in extern "C" when using them with C++, or am i doing something wrong?
[15:54] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:2c1bf3fc964b: avutil/libm: fix fminf typo
[15:54] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:27b893b231ed: avformat/mov: fix "warning: variable altitude set but not used" warning
[15:55] Action: michaelni hopes msvc knows fmin()
[15:56] <Daemon404> wm4, i would expect any C++ program including c headers to do it itself
[15:57] <ubitux> michaelni: using FFMIN would have been fine in the case of showcqt btw
[15:57] <michaelni> yes, question would be which is faster for msvc
[15:58] <michaelni> ive no way to test ...
[15:58] <Daemon404> fwiw it runs fine under WINE
[15:58] <Daemon404> cl.exe i mean
[15:58] <nevcairiel> msvc 2013 knows fminf
[15:58] <nevcairiel> earlier versions dont
[15:58] <michaelni> btw if fmin() fails too someone pleease ping me
[15:58] <nevcairiel> no idea about fmin
[15:58] <michaelni> then ill use FFMIN
[15:59] <Daemon404> 2012 is the first with fmin
[15:59] <Daemon404> you know this is all documented on MSDN right?
[15:59] <nevcairiel> all i could find on msdn was the  stupid AMP functions
[15:59] <Daemon404> http://msdn.microsoft.com/en-us/library/hh308346.aspx
[15:59] <Daemon404> first result in google
[15:59] <Daemon404> oh amp
[15:59] <nevcairiel> yeah thats AMP
[15:59] <nevcairiel> not actual C library
[16:00] <Daemon404> ok fmin was added in 2013
[16:00] <Daemon404> according to their PR/blog
[16:00] <Daemon404> so 2012 and 2010 will not work
[16:00] <nevcairiel> I found it referenced in the c99 support blog
[16:01] <Daemon404> me to
[16:01] <Daemon404> too
[16:01] <nevcairiel> but they didnt add it to the msdn apparently
[16:01] <Daemon404> C is a 2nd class citizen
[16:01] <michaelni> Daemon404,  if build is broken i try to fix it ASAP not start searching, which for msvc maybe doesnt work because one really must search for the one option that does work ...
[16:02] <Daemon404> its not useful to fix it immediately and push if it doesnt fix it
[16:02] <nevcairiel> why even use a function and not the usual macro, anyway? is there some advantage i'm missing?
[16:02] <Daemon404> yeah
[16:02] <Daemon404> i thought we always used FFMIN
[16:03] <Daemon404> michaelni, i had an unrelated question for you: did you finish fixing all the swscale asm so that i can change the FILTER_SIZE define?
[16:03] <Daemon404> i remember you doing some
[16:04] Action: Daemon404 will go ahead and add configure support if os
[16:04] <Daemon404> so*
[16:08] <michaelni> Daemon404, if trial and error takes you 1min to fix an issue at average and 10min in worst case and searching takes you between 5min and 1h then trial and error is better
[16:09] <Daemon404> i disagree
[16:10] <Daemon404> the difference is inconsequential, and you pollute a the tree with a bunch of 'maybe this will fix it commits"
[16:10] <Daemon404> it is sloppy.
[16:11] <Daemon404> especially if the relevant fate instances only run 2-3 tiems a day
[16:11] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:3133e7fd4475: avutil/libm: use FFMIN instead of fmin()
[16:14] <michaelni> Daemon404, its still better than not fixing it and complaining when someone else does in 2 instead of 1 commit IM(H)O ;)
[16:14] <ubitux> i don't want to be pedantic, but using a macro might be problematic
[16:15] <ubitux> like if some code is using fminf(x++, y--) or something
[16:15] <ubitux> or even calling a function 
[16:15] <alpa_astero> michaelni: I tend to think the thinking is better, because trial and error leads to missing all sorts of edge cases, in general
[16:16] <ubitux> alpa_astero: trial and error is the basis of engineering
[16:16] <Daemon404> michaelni, i cant fix what i dont know is broken
[16:16] <Daemon404> two people with workign msvc knowledge and envs were around
[16:16] <nevcairiel> maybe we should just ban fminf from the code and use the macro in the calling code instead
[16:16] <Daemon404> coulda poked us
[16:16] <ubitux> nevcairiel: i agree with that
[16:17] <Daemon404> ubitux, not necessarily *good* engineering ;)
[16:17] Action: Daemon404 trial and errors building a bridge
[16:17] <michaelni> Daemon404, i thought people knew as someone pointed it out on irc many hours ago
[16:17] <ubitux> Daemon404: there is no point in overthinking something without test
[16:17] <Daemon404> i wasnt hilighted, and i dotn reall all irc backlog
[16:17] <ubitux> you won't be able to anticipate everything
[16:18] <ubitux> trying and then incrementing really is the basis
[16:18] <Daemon404> ubitux, my point was tehre were two people aorund who *could* test
[16:18] <Daemon404> pushing blindly is pretty silly then.
[16:18] <alpa_astero> ubitux: I'm fully in favor of -using- trial and error, but not just using it while not thinking to save a couple of minutes while trying to fix bugs
[16:18] <Daemon404> that too.
[16:19] <ubitux> it was already broken for msvc, it was just an increment to "try", it's cheap and would have provide results without effort, and in the current patch with limited risk for the other plateforms
[16:19] <ubitux> in the worst case nothing would have changed
[16:19] <Daemon404> i can only call that sloppy
[16:19] <ubitux> in the best, it would have fixed the issue
[16:19] <Daemon404> for little to no gain
[16:20] <Daemon404> that is the Carl Eugen coding method
[16:20] <Daemon404> hack shit till ti works
[16:20] <Daemon404> it*
[16:20] <michaelni> alpa_astero, well i think that build issues should be fixed ASAP because it prevents users from building  the code
[16:20] <alpa_astero> michaelni: sure, fsvo asap; if it's 1 minutes vs 10, I can't say it's a major factor for me
[16:21] <Daemon404> it took me literally two minutes to google the answer
[16:21] <ubitux> vs 10 "maybe" + effort
[16:21] <Daemon404> which is not exactly slower.
[16:24] <ubitux> so much bikeshed for nothing :p
[16:25] <Daemon404> re: FFMIN(i++, j++)
[16:25] <Daemon404> i tend to think incrementing like that is evil :P
[16:25] <nevcairiel> especially on floats :D
[16:25] Action: michaelni agrees with ubitux, Daemon404 and alpa_astero :)
[16:25] <Daemon404> nevcairiel, haha yes
[16:25] <ubitux> Daemon404: what about fminf(foo(x), bar(y)) ?
[16:26] <ubitux> (with fminf being the FFMIN workaround)
[16:26] <Daemon404> ubitux, if foo and bar have side effects
[16:26] <Daemon404> still evil
[16:26] <Daemon404> and misleading
[16:26] <nevcairiel> well you might think its a function and no problems could arrise, but yeah
[16:27] <ubitux> probably, but that's harder to prevent than #define fminf please_do_not_use_fminf_its_not_portable_thx_obama
[16:28] <Daemon404> ubitux, i tend to think that if foo or bar had siedeffects
[16:28] <Daemon404> it probablt wasnt intended to begin with
[16:28] <Daemon404> unless it was trying to be "clever"
[16:29] <ubitux> what if it's a really slow function and gcc doesn't realize it can reuse the result?
[16:29] <nevcairiel> even if they dont have side effects, they could just be slow
[16:29] <nevcairiel> that ^
[16:29] <ubitux> :)
[16:29] <Daemon404> right
[16:29] <ubitux> or well gcc.. i should say msvc
[16:30] <Daemon404> msvc's optimization is actually pretty good
[16:30] <Daemon404> ive had just as many "Special" problems with gcc as msvc
[16:30] <Daemon404> :D
[16:30] <nevcairiel> if the function is complex enough, it would be unlikely to figure it out
[16:31] <ubitux> or just external
[16:31] <ubitux> like, between 2 libav*
[16:33] <ubitux> Daemon404: i was mentioning msvc because that would probably be the only one having the function replaced with a macro
[16:33] <nevcairiel> and only old msvc at that
[16:34] <nevcairiel> i dont even use that anymore for day-to-day work, so any problems may be undiscovered for longer
[16:35] <nevcairiel> hm, i still wonder why msvc has exactly one fate test less than a mingw build on the same host
[16:35] <nevcairiel> wonder which that is
[16:35] <nevcairiel> (and nother 3 more on a linux host)
[16:36] <Daemon404> diff -ur
[16:40] <nevcairiel> apparently TEST    xvid-idctmmx doesnt run on msvc, i guess it depends on inline asm to be meaningful
[16:41] <Daemon404> makes sense
[16:42] <michaelni> posted 2  (sort of alternative) patches  to improve the fminf/FFMIN issues
[16:44] <Daemon404> the function seems reasonable to me
[16:45] <nevcairiel> oh, the other 3 tests seem to depend in iconv
[16:45] <nevcairiel> which my windows env doesnt have
[16:45] <Daemon404> nevcairiel, barf
[16:45] <Daemon404> iconv is literally hitler
[16:46] <Daemon404> .. ok not as bad a gettext
[16:46] <ubitux> gettext doesn't help much with charset
[16:46] <Daemon404> i know
[16:46] <Daemon404> i generally prefer ICU
[16:46] <Daemon404> but its lolhueg
[17:31] <cone-901> ffmpeg.git 03Martin Storsjö 07master:a32765c4252e: adpcm: Fix trellis encoding of IMA QT
[17:31] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:fb7646d92cba: fate: enable adpcm-ima_qt-trellis
[17:31] <cone-901> ffmpeg.git 03Martin Storsjö 07master:fa8f060b75bf: adpcm: Write the proper predictor in trellis mode in IMA QT
[17:31] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:afce83484324: avutil/libm: Replace macro based fminf() by function
[17:31] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:867c02acd241: avfilter/avf_showcqt: avoid using fminf()
[18:11] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:1aa60980d20b: fate: enable fate-seek-acodec-adpcm-ima_qt-trellis
[18:11] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:049b20b28739: avcodec/adpcmenc: fix integer overflow / undefined behavior in STORE_NODE()
[20:21] <michaelni> Daemon404, ubitux, et al which way do you prefer to fix the latest fminf problem ? revert, include common.h, s/FFMIN/((a) > (b) ? (b) : (a))/
[20:21] <ubitux>  s/FFMIN/((a) > (b) ? (b) : (a))/
[20:22] <ubitux> without parenthesis because it's not necessary
[20:26] <ubitux> funman: chrome going to switch to ffvp9 then? ;)
[20:34] <funman> ubitux: I wish!
[20:34] <funman> just checking that it uses libvpx actually
[20:34] <ubitux> haha
[20:34] <funman> btw I just sent https://lists.libav.org/pipermail/libav-devel/2014-June/060222.html
[20:34] <funman> it's needed in FFmpeg as well because there are 2 options controlling the same variable, and they don't use the same default
[20:35] <funman> "cpu-used" is INT_MIN and "speed" (legacy option) is 1
[20:35] <ubitux> "needed in FFmpeg as well"? isn't this from FFmpeg?
[20:35] <funman> nope
[20:35] <funman> I mentioned the FFmpeg for the actual value (1), but only "speed" was changed in that commit
[20:37] <funman> http://git.chromium.org/gitweb/?p=chromium/deps/ffmpeg/source.git;a=blob;f=config/Chromium/linux/ia32/config.h;h=5d86bd4a245568ef1601efb2ea18b5ee84c22d53;hb=HEAD
[20:37] <funman> --enable-decoder='theora,vorbis,vp8'
[20:37] <ubitux> add ",vp9" then ;)
[20:37] <Daemon404> this wouldnt even be useful to crhome
[20:37] <Daemon404> which is 32bit in most cases
[20:37] <ubitux> ah... indeed for 32bit you're doomed
[20:38] <ubitux> funman: do you actually have 4k vp9 material?
[20:38] <ubitux> did they start encoding them last year?
[20:39] <funman> I do
[20:40] <funman> http://www.youtube.com/watch?v=ZONhkk9NIsQ
[20:40] <funman> I had to modify youtube-dl to add an entry for '272' format 
[20:40] <funman> an Intel guy just gave me a usb key with Stress_VP9_3840x2160_210_extra_stress_1.0.vp9
[20:41] <funman> I'll have to upload that
[20:44] <funman> The following materials are defined as "Developer Tools" and are subject
[20:44] <funman> to the terms and conditions of the End User License Agreement
[20:44] <jamrial> funman: that's a two years old repository. this one seems to be more current http://git.chromium.org/gitweb/?p=chromium/deps/ffmpeg.git;a=blob;f=chromium/config/Chromium/linux/ia32/config.h;h=7326d0fc9fc5930ba9fd8c810cbce6cf6dae9978;hb=HEAD
[20:45] <jamrial> still no vp9, though
[20:45] <funman> ah good catch
[20:46] <michaelni> ubitux, Daemon404, et al which do you prefer, x>y?y:x or x > y ? y : (isnan(x) ? y : x)
[20:46] <funman> YOU MAY NOT DISTRIBUTE ANY PORTION OF THE MATERIALS
[20:47] <ubitux> michaelni: no opinion :)
[20:48] <jamrial> isn't isnan c99?
[20:48] <michaelni> i guess i can write it without isnan
[20:48] <jamrial> because for msvc 2012 that would mean back to square one
[20:48] <michaelni> but the first option is strictly not correct if you take c99 litterally
[20:50] <Daemon404> ditto
[20:50] <michaelni> so that would then make it x > y ? y : (x==x ? x : y)
[20:52] <funman> jamrial: https://plus.google.com/+DaleCurtis I should talk to that guy if I can find him
[20:53] <jamrial> he writes to the ml
[20:56] <Daemon404> funman, are you joining felix in mountain view?
[20:57] <funman> which felix
[20:57] <Daemon404> wait
[20:57] <Daemon404> i mixed you and felix up in my head
[20:57] <Daemon404> i thought he was going for some reason
[20:58] <Daemon404> nv
[20:58] <Daemon404> nvm
[21:10] <kierank> funman: he came to vdd
[21:11] <kierank> In 2012
[21:13] <Daemon404> you mean when the chrome talk was entirely "we cannot answer that" ?
[21:13] <Daemon404> aka a giant pile of useless
[21:14] Action: funman has some nice stickers
[21:15] <funman> "the fastest x86-32 vp9 decoder in the world"
[21:23] <Daemon404> eh? its only fast in x86_64
[21:23] <nevcairiel> i think he refers to libvpx instead =p
[21:23] <Daemon404> o
[21:23] <Daemon404> lo
[21:23] <Daemon404> l
[21:29] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:e374e7729284: avutil/libm: fix fminf() emulation build failure due to undefined FFMIN
[21:41] <cone-901> ffmpeg.git 03Vignesh Venkatasubramanian 07master:c80181352c17: lavf/matroskaenc: Fix Cues on Audio for WebM DASH
[22:17] <funman> http://chui-pas.net/~fun/VideoTestBitstreams_Beta_1.zip
[22:17] <cone-901> ffmpeg.git 03Christophe Gisquet 07master:7eb5b20a87c1: huffyuvdec: trick for plane decoding <= 14bits
[22:59] <cone-901> ffmpeg.git 03Marc-Antoine Arnaud 07master:8a06794112d0: mpeg2: add sequence display extension information
[22:59] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:5163fb9446f3: Merge commit '8a06794112d02a5707f766b8b38a5d50dfd03898'
[22:59] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:3b42a8e43924: avcodec/mpeg12enc: store sequence display extension only if we have something to store in it
[23:09] <cone-901> ffmpeg.git 03Marc-Antoine Arnaud 07master:bd71c300f9ba: avcodec options: add enum option for color_primaries
[23:09] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:58e501b1e9c4: Merge commit 'bd71c300f9ba7f9875bb5df17ce522e9128bae10'
[23:19] <cone-901> ffmpeg.git 03Marc-Antoine Arnaud 07master:efc2dfe6a023: avcodec options: add enum option for color_trc
[23:19] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:9e1d97aa0669: Merge commit 'efc2dfe6a0238ec08769626db899ea910be24407'
[23:29] <cone-901> ffmpeg.git 03Marc-Antoine Arnaud 07master:7c29b7229bed: avcodec options: add enum option for colorspace
[23:29] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:00acf5c42ae2: Merge commit '7c29b7229bedf0c37d09bd02dab88e563adffd3c'
[23:34] <cone-901> ffmpeg.git 03Marc-Antoine Arnaud 07master:f558f0d2da94: avcodec options: add enum option for color_range
[23:35] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:cd016db4256d: Merge commit 'f558f0d2da9426c7f5ba346b5b8e6eb720148362'
[23:42] <cone-901> ffmpeg.git 03Martin Storsjö 07master:103243ca649c: oggenc: Set the right AVOption size for the pref_duration option
[23:42] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:faabef3d3d85: Merge commit '103243ca649cc305129ed0352bf4d97e5ddf4d80'
[23:43] <cone-901> ffmpeg.git 03Martin Storsjö 07master:3d79d0c93e5b: adpcm: Avoid reading out of bounds in the IMA QT trellis encoder
[23:43] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:37cf695af0ae: Merge commit '3d79d0c93e5b37a35b1b22d6c18699c233aad1ba'
[23:59] <cone-901> ffmpeg.git 03Rafaël Carré 07master:5265e3e40fd2: avcodec/libvpxenc: Update the "cpu-used" options default to match the "speed" alias
[23:59] <cone-901> ffmpeg.git 03Michael Niedermayer 07master:71da91e887d5: avcodec/libvpxenc: update the ranges for "cpu_used" so it matches the "speed" alias
[00:00] --- Sat Jun  7 2014