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

[burek]

[00:10] <aetasx> just because we're always right, doesn't make us snobs :p
[00:17] <ubitux> yay, palette selection is starting to work
[00:17] <aetasx> palette selection?
[00:18] <ubitux> yeah, color quantization
[00:18] <ubitux> to create pretty gif
[00:18] <aetasx> ah
[00:19] <ubitux> (or improve png compression, that sort of stuff)
[00:28] <aetasx> you wouldnt happen to know about those runtime predictor tables generated for some of the codecs within like libavcodec/x86/h264_intrapred_init.c would ya?
[00:37] <ubitux> maybe i'll know tomorrow
[00:37] <ubitux> but right now i'm happy with http://b.pkh.me/old.gif ’ http://b.pkh.me/new.gif
[00:38] <ubitux> (yes size is twice as big but that will be fixed, the point is that the palette is not braindead anymore)
[00:39] <ubitux> anyway, good night
[00:40] <aetasx> lol
[00:40] <aetasx> alright, gnight man
[04:44] <cone-703> ffmpeg.git 03Carl Eugen Hoyos 07master:c6a36f693153: lavc/pngenc: Support encoding ya16be.
[04:44] <cone-703> ffmpeg.git 03Carl Eugen Hoyos 07master:c2e36e07cdeb: lavc/tiffenc: Support encoding ya16le.
[04:44] <cone-703> ffmpeg.git 03Carl Eugen Hoyos 07master:196dd72bcfe0: lavc/pamenc: Support encoding ya16be.
[04:44] <cone-703> ffmpeg.git 03Carl Eugen Hoyos 07master:6c559a0a9d3e: lavc/pnm: Support decoding ya16.
[04:49] <compn> ya16 eh?
[04:49] <compn> so many colorspaces or pixfmts now
[04:50] <bryno> for real. as if all of those are important
[04:50] <compn> well, that question goes back to what ffmpeg goal is, and what the developers goals for ffmpeg are.
[04:51] <compn> cant really complain about what devs work on, just be happy they work on it :)
[04:51] <compn> you can complain, but cant force devs to do anything :P
[04:53] <compn> and working on things which may not be important to you, but to other people? 
[04:53] <compn> or may let the devs learn
[06:02] <aetasx> can always try to guilt-trip them ;)
[08:42] <filterAKY> where returns the function static int filter_frame(AVFilterLink *inlink, AVFrame *in) ?
[10:02] <wm4> bryno, compn: there are much more useless colorspaces than ya16...
[10:03] <j-b> oh yeah
[10:08] <wm4> also, all of my hate towards swapped-endian formats
[10:08] <j-b> stupid
[10:09] <wm4> the few decoders which need this (png apparently) could just do this themselves
[10:09] <j-b> clearly
[10:10] <j-b> Not to mention that everyone is now little-endian, except the dying PPC
[10:10] <j-b> (dead?)
[10:10] <wm4> think of the aging ppc macs
[10:11] <j-b> dead.
[10:11] <wm4> also I'm confused how the png 16 bit filters work
[10:11] <ubitux> j-b: what's the endianness of POWER8?
[10:11] <wm4> e.g. deloco_rgb16() seems to use uint16_t, but in big endian??
[10:11] <j-b> ubitux: who gives a shit?
[10:11] <j-b> ubitux: seriously.
[10:11] <j-b> optimizing for dead architectures is not a good idea
[10:11] <wm4> maybe it's broken... how do I create pngs with fancy features?
[10:12] <ubitux> j-b: it was produced in 2013
[10:12] <j-b> ubitux: and it has 0 acceleration for Ffmpeg
[10:12] <j-b> wm4: the last g5 mac was out in 2005
[10:12] <ubitux> you mean ffmpeg has not much acceleration
[10:12] <wm4> all modern CPUs that have big endian actually seem to have little endian modes too
[10:12] <ubitux> for ppc
[10:12] <nevcairiel> actually there have been quite a few patches to support power8 in ffmpeg
[10:12] <nevcairiel> but its little endian
[10:12] <j-b> ubitux: PPC, it has. but not Power8
[10:12] <nevcairiel> (which is the reason it needs patches)
[10:13] <wm4> <nevcairiel> (which is the reason it needs patches) <- lol
[10:13] <j-b> wm4: PIX_*_LE :D
[10:13] <nevcairiel> mostly for the altivec code, which assumed it was big endian
[10:13] <ubitux> j-b: well, we use altivec, so...
[10:17] <wm4> ok, codecs which obviously "need" BE variants of pixel formats: raw, xwd, pngdec, dpx, sgi, tiff, pam, pnm, brenderpix, qtrle, LE variants: raw, targa, ptx, zmbv, libvpxdec (?), sgi, xwd, tiff, dpx, cscd, aasc, targa
[10:18] <nevcairiel> with need you mean they can output them even on a LE system?
[10:19] <wm4> haven't checked them in detail; I assume most of these just memcpy image data from packet to output frame
[10:20] <wm4> libvpx is quite "special" here, it seems to use LE output on big endian? or it's just broken
[10:40] <ubitux> when was swscale included in the FFmpeg repository? not 2006 right? (73435f006b)
[10:41] <ubitux> it was split out originally didn't it?
[10:45] <kierank> 2011 I think it joined
[10:45] <kierank> Around fork time
[10:45] <ubitux> i see, thank you
[10:45] <nevcairiel> must've been before the fork, or libav wouldnt have it : p
[10:46] <wm4> wow, that late
[10:46] <wm4> it sure was a "nice" addition
[10:49] <wbs> trolling aside, it was originally in mplayer, hooked in into ffmpeg via svn:externals at some point. so at that point you'd have to sync the checkout of both ffmpeg and libswscale to matching dates to have something that built successfully. in the git conversion, janne did a huge effort to get the history from both repos interleaved into one in git
[10:50] <ubitux> i suppose this is refering to http://ffmpeg.org/archive.html#svn_to_git
[10:50] <ubitux> which confirms the date
[10:50] <wm4> ah, so it was well used earlier
[10:50] <wbs> yes, it was used for a long time before that, but vcs wise it was very awkward
[10:55] <wm4> I wonder how mplayer handled the recursion
[10:55] <wbs> (it was gpl-only though up until 2008 or something, when kostya rewrote the last gpl-only pieces)
[10:56] <ubitux> aah that's why it was split and not all the time included
[10:56] <ubitux> thanks :)
[12:06] <cone-702> ffmpeg.git 03Rodger Combs 07master:1d8aa23794cc: dashenc: Fix format string generation
[12:06] <cone-702> ffmpeg.git 03Rodger Combs 07master:89684883af44: avformat/dashenc: fix format string generation
[12:06] <cone-702> ffmpeg.git 03Michael Niedermayer 07master:526f7ef21108: Merge commit '1d8aa23794cc63e9517d5055a2d48040b843b1cf'
[12:16] <cone-702> ffmpeg.git 03Martin Storsjö 07master:3a724a7f3ba7: dashenc: Use inttypes.h macros for format strings instead of %lld
[12:16] <cone-702> ffmpeg.git 03Michael Niedermayer 07master:b7f8e6dd8c26: Merge commit '3a724a7f3ba7fa766c6a6f0924a15cc742031b8d'
[12:50] <cone-702> ffmpeg.git 03Michael Niedermayer 07master:146a2c4e7fb6: avcodec/mpegvideo: also export 0,0 motion vectors
[13:23] <cone-702> ffmpeg.git 03Michael Niedermayer 07master:bbdd940f3666: doc/APIchanges: Fill in some more missing hash values
[13:32] <cone-702> ffmpeg.git 03Michael Niedermayer 07master:b942a71eaa09: avformat/flvenc: accept AVMEDIA_TYPE_SUBTITLE instead of DATA for subtitles
[14:08] <ubitux> kurosu, michaelni, btw, iirc this "subtitles into flv" is something luca invented and is not standardized
[14:09] <ubitux> but maybe i'm remember it wrong
[14:10] <ubitux> maybe it's unrelated and i'm mistaken with one of his past plan
[14:17] <ubitux> https://lists.libav.org/pipermail/libav-devel/2012-May/027732.html seems this is the related chunk
[14:17] <j-b> nevcairiel: did you have dxva/hevc code?
[14:18] <ubitux> haven't look at the code itself
[14:29] <ubitux> akira4: how is the webvtt thing going? did you see other stuff to extract?
[14:32] <akira4> ah, I've added the alignment thing
[14:32] <akira4> but there wasn't much to add apart from that.
[14:32] <akira4> also the font color thing, I'm not sure how to check the color.
[14:34] <ubitux> browsers don't have implementation for these?
[14:35] <ubitux> you can't just mux the webvtt into webm and see how it looks in your browser?
[14:38] <akira4> I was embedding a video and checking the vtt file. I'll try this.
[14:48] <ubitux> akira4: did you see the patch on the ml btw?
[14:49] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167775.html
[14:50] <nevcairiel> j-b: i do
[14:50] <ubitux> it's kind of related to the CC though here
[14:50] <j-b> nevcairiel: for libavcodec too?
[14:51] <nevcairiel> j-b: yes thats what i build it on, but it needs a bit of refactoring to be ready for upstreaming
[14:52] <j-b> ok
[14:53] <nevcairiel> ideally someone that knows the hevc decoder internals properly to assist in figuring out how to do some things more cleaner.. :d
[14:56] <akira4> ubitux: I'm checking it out. 
[14:56] <j-b> nevcairiel: can I help?
[14:57] <wm4> so there's hw already that works with dxva?
[14:58] <nevcairiel> strictly speaking no, but there are drivers that work with dxva and do a sort of hybrid decoding, using GPGPU and/or shaders to accelerate the process
[14:58] <nevcairiel> both NVIDIA and Intel offer that
[14:58] <compn> ubitux : theres the closed captions in flv sample we found in the wild (on adultswim.com website)
[14:59] <nevcairiel> latest rumors suggest the new NVIDIA GTX960 which may or may not be released today may have a full HEVC hardware decoder, including 10-bit
[14:59] <compn> whoa
[14:59] <nevcairiel> nvidia announced the 10-bit hardware decoder for their next mobile platform, so it will get into the next desktop part as well, it is however unknown if the 960 has the refreshed decoder block, or not
[15:01] <ubitux> compn: is it on samples.ffmpeg.org?
[15:01] <nevcairiel> anandtechs initial preview of the GPU suggests that the 960 has in fact the full hardware decoder block
[15:01] <nevcairiel> I'll probably need to buy one to confirm and see if i can make 10bit work
[15:05] <compn> ubitux : yes, in one of the ffmpeg-bug dirs
[15:05] <compn> let me find
[15:05] <compn> ./ffmpeg-bugs/trac/ticket3172/rickandmorty_cc_001_pt1_t3LEd_AS_HD_large.flv
[15:05] <compn> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket3172/
[15:06] <nevcairiel> anyway j-b, i'll probably get the new nvidia card as soon as shops are willing to give me one, and then see about adding 10-bit (which may require quite a bit of refactoring), and then see about upstreaming it somehow
[15:06] <compn> cc608 encoded closed captions :)
[15:06] <ubitux> now that we have a decoder, i guess akira4 could add support for this into our demuxer
[15:07] <compn> i dont know if theres any kind of spec for it in flv though
[15:07] <compn> but they have closed captioned a bunch of the other videos as well
[15:18] <akira4> ubitux, this is the current diff : http://pastebin.com/frpCp6ir. I haven't tested it yet.
[15:19] <ubitux> don't forget to keep credit to the guy you took part of the code (use --signoff)
[15:20] <ubitux> what are these magic values btw?
[15:20] <ubitux> x=35,y=70;
[15:20] <akira4> I have no clue. 
[15:20] <ubitux> else if (x1 > 320) x=65;
[15:20] <ubitux> if(y1 < 280) y=5;
[15:20] <ubitux> wtf is that?
[15:20] <ubitux> please contact the guy and ask for information if you don't understand
[15:20] <ubitux> because i definitely do not
[15:21] <akira4> okay. I'll do that.
[15:21] <ubitux> btw, please fix your editor, you're mixing tab & spaces, and whole style is broken
[15:22] <akira4> yes.
[15:22] <ubitux> i'd like to have an answer on the styles though
[15:23] <ubitux> i would guess the most obvious way to store the CSS thing would be into the extradata, and maybe add an option or whatever to export to a separate file if it absolutely needs to be in a separate file
[15:23] <ubitux> otherwise printed somehow in the vtt file
[15:23] <ubitux> i don't remember the specs, check the webvtt specifications
[15:29] <akira4> I checked the webvtt specs and the classname tag is used for the style formatting using cues (in css files).http://dev.w3.org/html5/webvtt/#dfn-webvtt-class-object
[15:30] <cone-702> ffmpeg.git 03Michael Niedermayer 07master:c90069c6ba04: avfilter/drawutils: Use av_malloc_array()
[15:30] <cone-702> ffmpeg.git 03Michael Niedermayer 07master:f77571f6bb5a: avfilter/drawutils: Check for av_malloc* failures
[15:30] <cone-702> ffmpeg.git 03Michael Niedermayer 07master:a30fd828abf4: avfilter/avf_showcqt: use av_malloc_array()
[15:35] <ubitux> dammit i forgot it but gif supports... interlacing
[15:36] <nevcairiel> evil gif is evil
[15:37] <wm4> I never got why image formats support interlacing
[15:38] <wm4> it's so annoying when they load
[15:40] <nevcairiel> it makes no sense for individual images, because its a temporal thing, which implies you have more than one image, in fact any competent deinterlacer needs more than one image to do its job properly
[15:40] <nevcairiel> of course gif is animated and could be multiple images, but still
[15:41] <wm4> sure, the term refers to a slightly different concept
[15:42] <ubitux> mmh, i wonder if i can update a palette midstream without rewriting it everytime (if i don't it fallbacks on the global one, and i would want it to re-use the last one)
[15:51] <ubitux> i guess i'll need to make a 2 pass mode
[15:51] <ubitux> :(
[16:06] <iive> ubitux: is that 2 fields interlace, or something more sinister?
[16:07] <ubitux> iive: http://www.w3.org/Graphics/GIF/spec-gif89a.txt 
[16:07] <ubitux> look for "E. Interlaced Images"
[16:08] <iive> Appendix E
[16:09] <iive> it's more like wavelet thing, where you load low res image and then add details to it.
[16:10] <iive> allowing to have somehow recognizable image while still loading the data for the rest.
[16:29] <Daemon404> https://chromium.googlesource.com/chromium/src.git/+/4e30d62669c312dd6788ba23376b1e8181be0a0c
[16:29] <Daemon404> and hell froze over
[16:30] <compn> they didnt have 709?
[16:30] <ubitux> can i use the pass mechanism in ffmpeg for something else than rate control?
[16:31] <ubitux> oh mmh i have an insane idea
[16:38] <Daemon404> compn, only they hw accel'd paths did
[16:38] <Daemon404> so it was inconsistent
[16:38] <Daemon404> tons of lovelt bug reports
[16:44] <ubitux> do we have something to specify a (global) palette to an encoder?
[16:45] <ubitux> (cli wise i mean)
[16:45] <nevcairiel> extradata holds palette in decoders, i would assume encoders use the same scheme?
[16:45] <nevcairiel> oh
[16:45] <nevcairiel> who the f' wants to input a palette on cli
[16:45] <ubitux> well, i have the code here to generate a palette
[16:45] <ubitux> a few adjustments and i'm able to make it work on N frames
[16:46] <ubitux> for gif, only the global palette is actually relevant
[16:46] <ubitux> so i somehow need a 2 pass
[16:46] <ubitux> 1 pass to generate a palette (maybe a filter that will output only one frame/image at EOF with the palette)
[16:47] <ubitux> and a 2nd pass to feed it to the encoder & muxer
[16:47] <ubitux> (muxer holds the global palette, encoder also needs it to map the source colors to this palette)
[16:47] <Daemon404> will it beat libimagequant? ;)
[16:48] <ubitux> probably not the first version, but that's the same basis
[16:48] <ubitux> a few tweaking and it should be competitive with it
[16:48] <ubitux> anyway, it's decent right now
[16:48] <ubitux> 00:37:48 < ubitux> but right now i'm happy with http://b.pkh.me/old.gif ’ http://b.pkh.me/new.gif
[16:49] <ubitux> (still 1 palette per frame, which sucks and creates kind of stupid blinking effect)
[16:49] <ubitux> (and makes the file HUGE - no transparency nor cropping is used since palette changes)
[16:49] <ubitux> still the colors are just way better, even though the implementation is not that crazy
[16:50] <ubitux> (basic median cut / heckbert 1982, which i need to improve for color resolution and back color map)
[16:50] <gnafu> Wow, that is a huge improvement.
[16:50] <ubitux> (and eventually replace the median cutting itself with a variance split instead, which is mentioned in the paper)
[16:50] <ubitux> anyway
[16:51] <ubitux> so my question really is... how would i transmit this palette?
[16:52] <ubitux> i don't like the idea of keeping in memory the whole frames, so it will really be a 2 pass mode
[16:52] <ubitux> first one being just the computing of the histograms
[16:52] <ubitux> and/or the palette
[16:54] <ubitux> i might add a -palette pal.png option to ffmpeg.
[16:55] <ubitux> unless you stop me
[17:01] <ubitux> the 2 pass mode could be really cool if it wasn't for rc purpose
[17:10] <ubitux> Hi master saste 
[17:20] <saste> ubitux, master of laziness
[17:20] <ubitux> :)
[17:30] <cone-702> ffmpeg.git 03Derek Buitenhuis 07master:41e983f1a639: libx265: Pass through user-set frame type
[18:01] <ubitux> http://ubitux.fr/pub/pics/_vax11.png :D
[18:03] <ubitux> same speed as libvpx
[18:03] <ubitux> on a modern i7
[19:59] <cone-702> ffmpeg.git 03Michael Niedermayer 07master:e32b07aea498: avformat/mov: Stricter sanity checks on the display_matrix
[20:26] <wm4> 26.014s with asm and
[20:26] <wm4> 26.129 without asm.
[20:26] <wm4> haha
[20:34] <jamrial> there are tons of asm functions that have similar effect on overall speed
[20:36] <jamrial> lots of audio dsp functions, for example
[20:37] <ubitux> i wonder what will happen when we will remove -fno-tree-vectorize
[20:37] <ubitux> since it probably prevents auto vectorization of similar loops
[20:43] <wm4> ubitux: I tested the same thing in mpv (just normal optimization settings), and got the same results
[20:43] <wm4> don't know if that includes autovectorization
[20:46] <ubitux> seems to be -O3 only
[20:46] <ubitux> (which we do in FFmpeg iirc, but disabling this specific one)
[20:47] <wm4> why? codegen bugs?
[20:48] <ubitux> 973859f5230e77beea7bb59dc081870689d6d191
[20:48] <ubitux> > 2009
[20:48] <wm4> haha
[20:48] <ubitux> might or might not be relevant
[20:48] <wm4> gcc 4.3
[20:48] <wm4> well, with those BSD users around...
[20:51] <wm4> 4.3 was old even in 2009
[20:51] <wm4> they released 9.4.0 in spring 2009
[20:51] <wm4> *4.4.0
[20:55] <ubitux> http://b.pkh.me/eq-novec.txt http://b.pkh.me/eq-vec.txt
[20:55] <ubitux> -O3 -fno-tree-vectorize vs -O3 
[20:56] <ubitux> i'm really curious how better it performs, but i think for next benchmarks over C versions, it would be interesting to enable such option.
[20:56] <ubitux> ...or maybe do it all the time
[20:58] <wm4> ubitux: well, suggest it to her?
[20:59] <ubitux> it's more about the overall, in various places
[20:59] <ubitux> we have many C code with ASM versions were such options would probably make sense
[20:59] <ubitux> filters, and maybe some part of sws
[20:59] <ubitux> without* ASM
[21:00] <ubitux> ... and for code with only a home made mmx code version which would be set instead of the C version (which would be optimized with a better optimization level by gcc), it could be interesting to compare...
[21:02] <wm4> is it possible to run SSE asm, but not MMX asm? (I'd expect lots of code expects that one implies the other...)
[21:02] <ubitux> (for the record, this is the MMX version: http://b.pkh.me/eq-mmx.txt)
[21:02] <jamrial> the -cpuflags option lets you do that
[21:04] <wm4> michaelni: didn't you want to drop the 2.3 or 2.4 release? (not sure which)
[21:05] <jamrial> both are still in use by some distros, so not a good idea
[21:12] <wm4> also, wow: "Red Hat EL 5*2    pre-0.5 master    2017-03-31 (End of production phase 3)"
[21:15] <JEEB> nobody uses the packaged ffmpeg there I'm pretty sure :P
[21:15] <JEEB> also even if they do they can't expect *you* to support it
[21:16] <JEEB> usually they poke Red Hat because they are supporting it for a fee
[21:18] <wm4> yet the 0.5 and 0.10 branches seem to get maintenance
[21:22] <kurosu> wm4: have you run the filter with the proper parameter/made sure process_MMX was actually run?
[21:23] <kurosu> "param->contrast != 1.0 && param->brightness != 0.0 && param->gamma == 1.0" is the condition for it to run
[21:23] <wm4> kurosu: yes, though I haven't tested the ffmpeg one
[21:23] <wm4> nor do I know how Arwa tested
[21:23] <kurosu> do you have an example of a command-line to run it ?
[21:23] <kurosu> (the old filter)
[21:24] <wm4> " I used this command: ffmpeg -benchmark -i  matrixbench_mpeg2.mpg -vf  mp=eq2 -f null -"
[21:24] <wm4> that's probably wrong
[21:24] <Daemon404> [19:48] < wm4> well, with those BSD users around... <-- bro bsd is 4.2
[21:24] <Daemon404> dont get ahead of yourself
[21:25] Action: Daemon404 runs
[21:35] <JEEB> 4.2 aka "we miscompile shit" (x264 in VLC was utterly broken at around 0.9.x for that)
[21:52] <jamrial> wm4: for eq, you need to use something like -vf mp=eq=1:1 to run the "process" function, be it mmx or c
[21:52] <jamrial> probably the same for eq2
[21:53] <jamrial> mmx: frame= 4690 fps=450 bench: utime=12.527s
[21:53] <jamrial> c: frame= 4690 fps=349 bench: utime=15.850s
[21:53] <jamrial> On a dual core k10
[21:54] <ubitux> and c with tree vectorize?
[21:54] <ubitux> (i suppose the k10 supports sse?)
[21:54] <jamrial> let me check
[21:54] <jamrial> up to sse3
[21:59] <jamrial> frame= 4690 fps=375 bench: utime=14.820s
[21:59] <ubitux> interesting
[21:59] <ubitux> does it generates sse* code?
[21:59] <jamrial> yeah, the disass is similar to the one you posted above
[22:00] <ubitux> i see
[22:00] <ubitux> cool :)
[22:00] <ubitux> please share in the thread
[22:01] <kurosu> the &768 test is funky because the MMX code does it only for the remainder of the loop not processed by mmx
[22:02] <kurosu> the compare insn generated look like that, and the mmx code seems to say: "useless"
[22:14] <kurosu> I also suspect in arwa's patch the init of the function pointer should occur *after* the dsp has been setup, otherwise...
[22:35] <kurosu> and indeed the MMX and C versions have different outputs
[22:35] <kurosu> though I'm not even sure the code is correctly assigning stuff at this point
[22:56] <kurosu> ubitux, btw, regarding that strange subtitle stuff in flv:
[22:56] <kurosu> http://help.adobe.com/en_US/as3/dev/WSD30FA424-950E-43ba-96C8-99B926943FE7.html#WS879C49CD-49C4-4557-BEFC-6C1DA76E3897
[22:56] <kurosu> I actually know nothing about flv, just noticed the warning
[22:56] <ubitux> yeah, i pasted the libav-devel thread with that link
[22:56] <kurosu> oh
[22:58] <kurosu> I gave that link to michael yesterday, but the ticket referred by compn seems to indicate some people embed other stuff in it
[23:03] <kurosu> ubitux, btw, with -msse2 (which should generate something equivalent to yours), I get on eq: 8998521 decicycles in eq, 2046 runs, 2 skips
[23:03] <kurosu> so -msse4.2 does generate somewhat better code, but I don't explain the discrepancy with jamrial's results and yours
[23:06] <ubitux> what discrepancy?
[23:06] <kurosu> mmx faster than the vectorized version
[23:07] <kurosu> oh actually not
[23:07] <cone-727> ffmpeg.git 03Derek Buitenhuis 07master:6341ab0ad3fd: libx265: Pass through user-set frame type
[23:07] <cone-727> ffmpeg.git 03Michael Niedermayer 07master:9353ed9e94a5: Merge commit '6341ab0ad3fde9583138e121f518e21cde15258e'
[23:07] <kurosu> jamrial's are slower like me
[23:07] <kurosu> but the C code does more (cf. the &768)
[23:07] <ubitux> so far i only see mmx > c-vec > c-novec
[23:08] <ubitux> (from a perf PoV)
[23:08] <kurosu> I thought I had read results from you, and they said c-vec > mmx
[23:08] <ubitux> (aka > is better)
[23:08] <kurosu> I was mistaken
[23:08] <kurosu> yeah
[23:08] <ubitux> yeah it was just an hypothesis
[23:08] <ubitux> i was asking for benchmarks :)
[23:09] <ubitux> because i'm a lazy bum
[23:10] <michaelni> that rickandmorty file is not a flv but a mp4/mov
[23:10] <kurosu> ok
[23:12] <michaelni> "major_brand     : f4v" to be precise
[23:12] <michaelni> "compatible_brands: mp42iso2isomavc1"
[23:16] <kurosu> even when removing the &768 part that may slow down the function, the SSE4 code is slower (6.4M vs mmx' 5.9M)
[23:19] <ubitux> fun :)
[23:22] <cone-727> ffmpeg.git 03Werner Robitza 07master:4b46ce8e91bd: avformat: allow .264 as extension for raw H.264 stream
[00:00] --- Fri Jan 23 2015