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

[burek]

[00:40] <cone-616> ffmpeg.git 03Michael Niedermayer 07master:fd52d2d3d1ee: avcodec/mpegvideo_motion: Fix gmc chroma dimensions
[00:40] <cone-616> ffmpeg.git 03Michael Niedermayer 07master:692b22626ec9: swscale/utils: Limit filter shifting so as not to read from prior the array
[00:41] <Timothy_Gu> aetasx: it's not practical with projs like FFmpeg
[00:44] <Timothy_Gu> aetasx: who knows which codecs or filters the user will use?
[00:45] <Timothy_Gu> aetasx: plus well-tested formats like H.264 will be better-optimized than not well-tested formats, simply because it is run for more times
[01:18] <aetasx> Timothy_Gu: thats true, but they're given the choice to pick which ones to use or not to use right now so I didn't think of it as being an issue.  Mainly something more for power users like the LTO option which I don't think I've seen anyone actually use in their builds (of the ones I've looked at anyway)
[01:19] <Timothy_Gu> aetasx: the LTO option  which I don't think I've seen anyone actually use in  their builds
[01:20] <Timothy_Gu>  ^ true because LTO is a beast
[01:20] <aetasx> yeah but how you guys have it setup works perfectly ;)
[01:20] <Timothy_Gu> aetasx: not when you have literally 15 deps
[01:21] <Timothy_Gu> each of them has at least 1 other dep
[01:21] <Timothy_Gu> and sometimes circular deps too
[01:21] <aetasx> those would only fall under LTO if they're compiled with support for it though
[01:22] <Timothy_Gu> aetasx: but IIRC don't you need to have all of the libs compiled with LTO to have one resulting LTO program?
[01:22] <Timothy_Gu> i.e. you cant mix LTO and non-LTO
[01:22] <aetasx> sure ya can
[01:23] <Timothy_Gu> or maybe im missing something?
[01:23] <aetasx> if it doesnt have LTO information, it links in it just as it normally would
[01:23] <aetasx> just doesnt do anything special with it
[01:24] <aetasx> that problem often comes up on a number of libraries that you try to compile with LTO support and then link into ffmpeg like you said but if you compile them without LTO support, the issue goes away
[01:25] <Timothy_Gu> aetasx: or well i played around with LTO with ICC a long time ago (they called it "IPO" interprocedural optimization). Maybe GCC is different I dunno
[01:25] <aetasx> if you have ffmpeg link in just a bunch of normal libraries with no LTO, then you can enable the LTO configureation option and it'll just handle ffmpeg's code alone without worrying about the rest which works well
[01:26] <aetasx> I think I saw that in their docs actually, one sec since I have the page opened anyway
[01:27] <aetasx> https://gcc.gnu.org/wiki/LightweightIpo this?
[01:29] <aetasx> I have no idea what -fripa is, my guess is its dated
[01:29] <Timothy_Gu> aetasx: not really the page is about profile-guided optimization, which thye call lipo
[01:31] <aetasx> no thats the FDO stuff, theres some other -fripa flag
[01:31] <aetasx> never seen it before
[01:33] <aetasx> heres the note that they have on LTO in the optimization area "When producing the final binary, GCC only applies link-time optimizations to those files that contain bytecode. Therefore, you can mix and match object files and libraries with GIMPLE bytecodes and final object code. "
[01:34] <aetasx> it just skips stuff that wasn't compiled with -flto on so any of those unresolved symbol errors you typically get sometimes simply go away since it treats it as a normal build
[01:35] <aetasx> honestly if you were to do an ffmpeg build right now and just turned the flag on, most likely it will just work perfectly like mine unless you're using LTO elsewhere
[01:35] <Timothy_Gu> aetasx: OK
[01:36] <aetasx> Im not sure who put the feature in but it was done pretty successfully
[01:36] <Timothy_Gu> aetasx: in gcc or ffmpeg?
[01:36] <aetasx> into ffmpeg
[01:37] <aetasx> I havent run across any other libs that have it and have it just work out of the box without fiddling
[01:37] <Timothy_Gu> it's literally a 20-line change of adding `-flto` so nothing surprising hard here
[01:38] <Timothy_Gu> aetasx: cairo has it IIRC
[01:38] <aetasx> yeah but if you pass -flto in through CFLAGS, things go horribly wrong
[01:38] <Timothy_Gu> but as cairo is a library downstream complained about cairo enabling LTO BY DEFAULT and then they removed it altogether
[01:39] <aetasx> yeah there's too many hiccups when trying to link it into other things to turn it on by default
[01:39] <Timothy_Gu> aetasx: you just need to pass -flto into LDFLAGS too
[01:40] <Timothy_Gu> aetasx: all the other changes in https://github.com/FFmpeg/FFmpeg/commit/65d12900432ac880d764edbbd36818431484a76e are either refactoring or checking lto /really/ works
[01:40] <aetasx> it doesnt work, I think its applying flto to object files with assembly or something and they end up getting trashed on the way out
[01:41] <Timothy_Gu> aetasx: oh yeah that
[01:41] <aetasx> I ran into that problem initially before finding the flag
[01:41] <Timothy_Gu> that's because gcc is dumb
[01:41] <Timothy_Gu> https://github.com/FFmpeg/FFmpeg/commit/a64df19c5bd22f543a254a7b93c82ade50038ff5
[01:41] <Timothy_Gu> https://github.com/FFmpeg/FFmpeg/commit/a01fedd9b87f05de45b7e49a62bec4bcbd0116d9
[01:41] <aetasx> lol
[01:42] <aetasx> their IRC room, despite having hundreds of people, is like a ghost town
[01:42] <Timothy_Gu> aetasx: lol
[01:42] <aetasx> I could go there to take naps
[01:43] <Timothy_Gu> aetasx: I sent a message there let's see :)
[01:44] <aetasx> Timothy_Gu: theres quite literally days in gaps between messages in my logs where the only breaks in between silence are people who ask questions and never get replies
[01:44] <Timothy_Gu> aetasx: OK I believe you
[01:45] <Timothy_Gu> aetasx: GCC is dying, slowly
[01:45] <Timothy_Gu> aetasx: only companies like Intel and Google are still keeping it alive
[01:46] <aetasx> Timothy_Gu: whats your opinion on CLANG compared to it?  I've heard its still a bit behind in performance but catching up quickly
[01:46] <Timothy_Gu> aetasx: see http://trac.ffmpeg.org/wiki/CompileBenchmarks
[01:46] <Timothy_Gu> (those are my results)
[01:47] <Timothy_Gu> I mean, it works pretty well. I never had any complaints with it.
[01:47] <aetasx> that is definitely interesting
[01:47] <Timothy_Gu> but it still needs some time to mature, and for big companies to start sending patches to it so that features like LTO are implemented
[01:48] <aetasx> I was reading something about it having built-in opencl support for openmp or something.  I forget what they're calling that standard
[01:48] <Timothy_Gu> omp is semi-automatic parallelization
[01:48] <aetasx> here it is http://www.openacc.org/
[01:49] <aetasx> from the gcc docs: https://gcc.gnu.org/wiki/Offloading
[01:49] <Timothy_Gu> sounds like a competitor to OpenMP
[01:50] <Timothy_Gu> so it's like OpenMP with automatic offloading support
[01:51] <aetasx> thats what I took away from it, yeah
[01:51] <aetasx> gcc5 apparently has it
[01:53] <aetasx> I was looking at it to see if it had any benefit for multimedia uses and encoding
[02:00] <aetasx> what libs do you typically build in with your ffmpeg?  I may just do a generic build with its most used libraries and just enable the LTO flag to get some stats as far as binary reduction size, speed, etc?
[02:17] <compn> Timothy_Gu : should encourage tcc to build ffmpeg ;)
[02:17] <compn> i think gcc will be around forever, if only for backwards compat
[02:23] <aetasx> I think he meant in leading development.  I think its just assumed anything in unix-like systems will be around longer than reasonable
[02:36] <cone-616> ffmpeg.git 03Philip Langdale 07master:d20df2601f02: avcodec/nvenc: De-compensate aspect ratio compensation of DVD-like content.
[02:48] <Timothy_Gu> compn: gcc will be there forever. But the people maintaining it will decrease over time
[03:30] <cone-616> ffmpeg.git 03Lukasz Marek 07master:21051af218d7: lavf/avc: add buffer padding to extradata allocation
[04:26] <jamrial> kurosu, michaelni: http://fate.ffmpeg.org/report.cgi?time=20150205015545&slot=x86_64-archlinux-gcc-valgrindundef
[04:27] <jamrial> very likely to be a regression introduced with da81cc38 or 52f2adc0 (judging by what the last good commit was and which ones touched hevc files since then)
[05:23] <cone-616> ffmpeg.git 03Michael Niedermayer 07master:f2579dbb4b31: avformat/thp: Check av_get_packet() for failure not only for partial output
[05:47] <Timothy_Gu> TGBot: hi
[05:47] <TGBot> Timothy_Gu: Hello!
[05:48] <Timothy_Gu> If I find time I'll use TGBot to make a FATE status bot
[05:48] <Timothy_Gu> TGBot status
[05:48] <TGBot> I'm running quite happily.
[06:12] <cone-616> ffmpeg.git 03Michael Niedermayer 07master:7801a54ec3d9: avfilter/vf_fps: update frame drop comment
[08:45] <j-b> 'lo
[11:02] <cone-125> ffmpeg.git 03Paul B Mahol 07master:57bca64b3f44: avcodec/cllc: use init_get_bits8()
[11:02] <cone-125> ffmpeg.git 03Paul B Mahol 07master:dccd648f9fa0: avcodec/alsdec: use init_get_bits8()
[13:25] <durandal_1707> wm4: what is broken in ffmpeg?
[13:29] <wm4> durandal_1707: returning vp9 timestamps from the parser when parsing webm vp9 packets
[13:29] <wm4> they simply get lost
[13:30] <durandal_1707> is that regression?
[13:30] <wm4> for those "golden frames", which, in webm, are put in the same packet as a normal frame
[13:30] <wm4> I don't know
[13:30] <wm4> the way Libav handles this (inside of the decoder), it just works
[13:30] <wm4> Libav has no vp9 parser
[13:31] <nevcairiel> but libav also has no frame threading
[13:31] <wm4> then this could be the reason
[13:34] <cone-125> ffmpeg.git 03Carl Eugen Hoyos 07master:afada9ac67a4: Fix compilation with --disable-protocol=udp
[13:34] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:7dad2f7bb975: Merge remote-tracking branch 'cehoyos/master'
[14:51] <rcombs> might be a good time to make sure none of ffmpeg's uses of gethostbyname could be vulnerable to CVE-2015-0235
[14:51] <Daemon404> well
[14:51] <Daemon404> the correct solution is to not use gethostbyname
[14:52] <Daemon404> its not useful in 2014
[14:52] <Daemon404> er
[14:52] <nevcairiel> shouldnt people just update the libc :p
[14:52] <Daemon404> 2015\
[14:52] <rcombs> Daemon404: you'd think!
[14:53] <Daemon404> you should use getaddrinfo
[14:53] <rcombs> Daemon404: but if you're running on a machine old enough not to have getaddrinfo (which AFAIK is the only case where we'd use gethostbyname)&
[14:53] <Daemon404> inb4 some stupid AIX system doesnt have it
[14:53] <Daemon404> ot something
[14:53] <Daemon404> ... getaddrinfo is not new
[14:53] <Daemon404> in any sense of the word
[14:54] <rcombs> if no supported systems lack getaddrinfo, we should remove the gethostbyname wrapper
[14:54] <Daemon404> depends what you define as support
[14:54] <Daemon404> e.g.: i dont give ashit about haiku
[14:54] <Daemon404> or plan9
[14:55] <Daemon404> or in fact HP-UX or AIX
[14:56] <Daemon404> i see the abomination of ffserver also directly uses gethostbyname for some reason
[14:56] <Daemon404> that makes no sense
[14:56] <rcombs> \o/
[14:58] <Daemon404> well if you are running ffserver in prod, youre probably not smart enough to update your systems either. so.
[14:58] <Daemon404> <_<
[15:01] <Daemon404> rcombs, the sole author if the wrapper said primarily for win2k...
[15:01] <Daemon404> so... perhaps we can nuke it
[15:01] <rcombs> \o/
[15:01] <rcombs> sounds good to me
[15:01] <JEEBsv> from the orbit
[15:02] <Daemon404> we dropped win2k support quite a while back
[15:02] <rcombs> if you're running win2k you shouldn't be on a network anyway
[15:02] <Daemon404> xp has getaddrinfo.
[15:02] <rcombs> (nor should you reproduce)
[15:04] <Daemon404> even compn updated.... to xp
[15:04] <Daemon404> ... last year
[15:04] <nevcairiel> lol
[15:04] <nevcairiel> after it went out of support, i'm sure
[15:05] <Daemon404> aye
[15:05] <rcombs> :|
[15:05] <nevcairiel> i saw some idiots on doom9 yesterday advocating for xp64 to be the best OS ever
[15:05] <nevcairiel> i was not sure if it was a troll post
[15:06] <Daemon404> it most certainly was not
[15:06] <rcombs> :|
[15:06] <kierank> yes it was
[15:06] <kierank> much better than lunix at the time anyway
[15:07] <Daemon404> kierank, the key here is: in 2015
[15:07] <nevcairiel> but the post was from yesterday
[15:07] <nevcairiel> not from 15 years ago
[15:31] <compn> it was a mistake to update to xp too
[15:31] <compn> because xp didnt support my 4tb hd :\
[15:31] Action: compn should switch back
[15:34] <wm4> so when do we drop xp support?
[15:35] <ramiro> compn: so you upgraded from one obsolete OS to another?
[15:36] <Daemon404> wm4, the official stance is: we drop it when it gets in the way in an unreasonable way
[15:36] <Daemon404> i.e. we're not strictly keeping it if it's a big problem
[15:37] <wm4> dropping it would allow easy implementation of pthread_once, and removing stupid things like the lock manager
[15:38] <Daemon404> propose it
[15:38] <Daemon404> you have my axe^Wsupport
[15:41] <wm4> I'm trying to find out how the fuck parsers handle timestamps
[15:42] <av500> they fuck with them
[15:50] <compn> ramiro : yes. i also installed vista on another machine to handle the 4tb :P
[15:51] <ramiro> compn: win2k to vista is a downgrade =P
[15:51] <compn> whys everyone hate on obsolete OS anyhow. 
[15:51] <Daemon404> ... why would you install vista
[15:51] <Daemon404> win7 is agreed to be superior in every way
[15:51] <compn> i wanted to switch to linux but then debian removed ffmpeg and mplayer so it took me a while to find a replacement distro :\
[15:52] <compn> Daemon404 : except w7 is bloated more than vista
[15:52] <ramiro> nothing is bloated more than vista. not even windows me
[15:52] <compn> have you used w7 ?
[15:52] <Daemon404> what
[15:52] <Daemon404> w7 is LESS bloated
[15:52] <Daemon404> sys reqs are far less
[15:52] <compn> anyways i'm done with windows
[15:53] <compn> next upgrade/install is 100% linux.
[15:53] <Daemon404> i have used every windows within a month or two of its release.
[15:53] <ramiro> compn: this is a great distro: http://www.linuxfromscratch.org/
[15:53] <Daemon404> sicne ~98se
[15:53] <ramiro> even though it's technically not a distro =)
[15:56] <compn> building from source sounds like a big hassle :P
[15:57] Action: compn remembers installing slackware and compiling a kernel
[15:58] <compn> ah well
[15:58] <compn> whos going to test binary codecs when i ditch the windows boxes ?
[15:59] <ramiro> install win2k in a virtualbox =)
[15:59] <ramiro> to remember the good ol' times
[16:04] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:e09ad5bd0de4: avcodec/h264_refs: set last_pic_for_ec only if it has not been set previously
[18:37] <jamrial> kurosu: since you oked 2 and 3, is "[PATCH 1/3] hevcdsp: remove compilation-time-fixed parameter from sao_edge_filter" ok as well? (the former depend on the later after all)
[18:38] <kurosu> oh right
[18:38] <kurosu> indeed
[18:39] <jamrial> ok, thanks
[18:40] <kurosu> I have one last patch on sao band filter, but it depends on whether you want to use the fixed parameter to reduce the number of gprs so as to port to x86_32
[18:41] <kurosu> so I'll just send it, up to you afterwards
[18:44] <jamrial> sao_band already uses only 6 gprs even if one of the parameters is stride_src. making it 5 by removing stride_src will not make x86_32 any easier since it's already good to go as is
[18:44] <jamrial> it's a matter of using stack to get around the xmm reg limit of x86_32
[18:44] <kurosu> ok, I didn't quite check it
[18:44] <jamrial> nonetheless i was planning on also removing stride_src from it
[18:45] <kurosu> patch sent, basically, we can most often do band filtering in-place
[18:45] <jamrial> to keep both band and edge similar
[18:45] <kurosu> but the stride is different in that case
[18:46] <jamrial> yeah, 2*MAX_PB_SIZE
[19:05] <cone-125> ffmpeg.git 03James Almer 07master:1f1c7c8a57e8: hevcdsp: remove compilation-time-fixed parameter from sao_edge_filter
[19:05] <cone-125> ffmpeg.git 03James Almer 07master:042c1159fcf8: x86/hevcdsp: add ff_hevc_sao_edge_filter_8_{ssse3,avx2}
[19:06] <cone-125> ffmpeg.git 03James Almer 07master:15574c505b81: x86/hevcdsp: add ff_hevc_sao_edge_filter_{10,12}_{sse2,avx2}
[19:39] <klmno> q:how can I tell if my reply was received at ffmpeg-devel at ffmpeg.org ? 
[19:39] <klmno> I did add myself on bcc, and the email went out, but there is no update on the email list, and I got no notification from the email list
[19:50] <nevcairiel> If you want to get replies you should be signed up for the ML
[19:56] <kurosu> michaelni, so yes, you're right, the original reference counting was just a lazy av_freep, and we can readd just that
[19:57] <kurosu> it's supposed to be a new sps, but I'm not sure how it would behave if other threads are still using those buffers, though
[19:58] <klmno> nevcaririel: I am in the ffmpeg-devel ML, and I also have "Receive acknowledgement mail when you send mail to the list?" and "Mail Delivery" enabled
[19:59] <klmno> it works when I send patches using send-mail but it doesn't work when I just reply to emails
[20:00] <klmno> I also have "Avoid duplicate copies of messages?" set to NO
[20:57] <michaelni> kurosu, if other threads can acess the buffers after free() that would be bad, is that possible ?
[21:08] <michaelni> seems it passes hevc fate under valgrind, should i apply it ?
[21:17] <kurosu> michaelni, I have mixed feelings on this
[21:17] <kurosu> the only sequence behaving that way isn't sufficient to evaluate a risk
[21:19] <kurosu> it's an improvement for the fate test, but I would imagine cases where stream changes format with a new sps, and then...
[21:19] <kurosu> the problem is we can only do a best guess fixing that issue, which isn't nice
[21:23] <cone-125> ffmpeg.git 03wm4 07master:a83b6b077c56: vp9: assign PTS to visible instead of invisible frames
[21:29] <kurosu> I'm not so sure other parts of the decoder are resilient to resolution change anyway
[21:33] <kurosu> I'm more for applying the fix, overall
[22:00] <cone-125> ffmpeg.git 03Christophe Gisquet 07master:9a2f5d825a25: hevc: free sao buffers when receiving a new SPS
[22:00] <michaelni> kurosu, applied
[22:17] <cone-125> ffmpeg.git 03Seppo Tomperi 07master:0c494114ccbe: hevcdsp: ARM NEON optimized deblocking filter
[22:37] <wm4> getting a crash in asm with wma lossless
[22:38] <cone-125> ffmpeg.git 03Michael Niedermayer 07master:43b1fd5bb4ef: avcodec/hevc: drop redundant ifs()
[22:54] <j-b> michaelni: why does FFmpeg has this very peculiar way of dealing with VP9 ?
[22:55] <j-b> Is there a good reasons?
[22:55] Action: j-b curious
[22:55] <nevcairiel> Frame threaded decoding
[22:55] <wm4> and webm being stupid
[22:55] <nevcairiel> Its not that peculiar either, it just splits individual frames
[22:56] <nevcairiel> The super frames are really the ones you should blame
[23:10] <wm4> could it be that ff_scalarproduct_and_madd_int16_ssse3 is broken on 32 bit?
[23:14] <wm4> michaelni: ping, it seems your changes to lossless_audiodsp might have caused this, although it's only a theory, I didn't check
[23:15] <ubitux> does it exists?
[23:16] <wm4> what exists?
[23:16] <ubitux> ff_scalarproduct_and_madd_int16_ssse3
[23:16] <ubitux> i see only the definition for mmxext and sse2
[23:16] <wm4> why wouldn't it? I have no diea how it comes into existence, though
[23:17] <ubitux> but i indeed see the assignment for ssse3
[23:17] <ubitux> ah, it's below, my bad
[23:17] <ubitux> yeah it can't work for 32-bits
[23:17] <ubitux> it uses 10 reg
[23:17] <wm4> so it tries to use scalarproduct_and_madd_int16_fallback?
[23:18] <j-b> nevcairiel: sure, but it works with libav, and with libvpx. Only FFmpeg neeeds the parser to be inserted, as far as I can ee
[23:18] <j-b> see
[23:18] <nevcairiel> j-b: libav is drastically slower though
[23:19] <nevcairiel> and libvpx has a entirely different architecture (and is slower, too)
[23:19] <nevcairiel> some codecs just require the parser, vp9 is not the only one, its just a fact of live and doesnt really change anything
[23:20] <ubitux> wm4: ff_scalarproduct_and_madd_int16_ssse3 should not be called on 32-bit, xmm reg is 10, it can't work
[23:21] <ubitux> you can probably send a fix for libavcodec/x86/lossless_audiodsp_init.c
[23:21] <nevcairiel> that file is weird .. the SSSE3 variant is slower when the CPU has SSE 4.2?
[23:22] <jamrial> it wouldn't compile with x86_32 if it really needed 10 xmm regs
[23:22] <wm4> ubitux: how do I check for 32 bits?
[23:22] <wm4> sizeof(void*)?
[23:23] <nevcairiel> wah, you check at compile time with a config thing of course
[23:23] <jamrial> wm4: no, but still, the function should work on x86_32
[23:23] <ubitux> wm4: !ARCH_X86_64
[23:23] <jamrial> look at the SCALARPRODUCT_LOOP macro
[23:23] <jamrial> it has a path for both x86_64 and x86_32
[23:23] <nevcairiel> a definition higher than 8 in the head isnt actually bad, as long as it doesnt use any more
[23:24] <ubitux> jamrial: the definition should be conditional then
[23:24] <ubitux> btw, can't we check that at compile time too?
[23:24] <nevcairiel> ubitux: it doesnt change generated code however, x86inc just lowers the number on 32-bit iirc
[23:24] <ubitux> like, a cglobal with more registers than your cpu allow
[23:25] <nevcairiel> it would break anyway if you actually used more  than allowed
[23:25] <ubitux> at build time?
[23:25] <ubitux> didn't know that, ok
[23:25] <jamrial> why do you want to check for x86_32?
[23:25] <nevcairiel> yeah, no opcodes for the extra regs
[23:25] <nevcairiel> cant assemble
[23:25] <ubitux> wm4: where does it fail more exactly then?
[23:25] <jamrial> the function compiles regardless of arch
[23:26] <ubitux> sorry for misleading
[23:26] <jamrial> It's written to work on both archs. with x86_64 it uses 10 xmm regs, with x86_32 it uses stack
[23:30] <wm4> ubitux: I don't know, the debugger stops in the middle of nowher
[23:30] <wm4> e
[23:36] <michaelni> wm4, what changes? how can i reproduce ?
[23:41] <wm4> michaelni: d3512a0e89262a3ab08f30bab6ff3b98ac4c6e01 and the next 2 parent commits looked suspicious to me, especially since this was a lossless wma track that didn't decode before (so probably a 24 bit one)
[23:42] <wm4> this is the file I tested with http://www.cccp-project.net/beta/test_files/[CCCP]_Mega_Lossless_Audio_Test.mkv
[23:42] <klmno> can I get some help with sensing a reply to ffmpeg-devel at ffmpeg.org?
[23:42] <wm4> it has 12 audio tracks or so
[23:42] <klmno> I did add myself on bcc, and the email went out, but there is no update on the email list, and I got no notification from the email list
[23:42] <klmno> I am in the ffmpeg-devel ML, and I also have "Receive acknowledgement mail when you send mail to the list?" and "Mail Delivery" enabled
[23:43] <klmno> it works when I send patches using send-mail but it doesn't work when I just reply to emails from my mail-client
[23:43] <nevcairiel> sounds like your mail client is broken
[23:43] <wm4> michaelni: oh sorry, it's http://www.cccp-project.net/beta/test_files/[CCCP]_Mega_Weird_Audio_Test.mkv
[23:43] <klmno> is gmx web interface
[23:43] <nevcairiel> or you're using a different address which is not subscribed
[23:43] <klmno> I use the proper one, if different then I get a bounced email
[23:44] <klmno> that the email is waiting for approval
[23:44] <wm4> michaelni: both wmalossless tracks crash if I allow AV_CPU_FLAG_SSSE3; seems to work if that is disabled
[23:45] <wm4> I can just send a patch and disable it on 32 bit
[23:45] <wm4> if that's ok
[23:45] <nevcairiel> that doesnt sound like the reason for the breakage
[23:45] <nevcairiel> fix it, dont disable it :p
[23:45] <jamrial> wm4: try changing 4,5,10 to 4,4,10 in the ssse3 version
[23:46] <wm4> jamrial: appears to work
[23:46] <wm4> no crash and output sounds like it should be
[23:46] <jamrial> good
[23:46] <jamrial> 32 bits takes all arguments from stack, jumping from the ssse3 version to the mmxext version screwed everything
[23:47] <jamrial> since it was 4,4
[23:47] <wm4> so part of the signature has to match
[23:47] <wm4> seems silly to do the jump in the asm though
[23:47] <jamrial> ssse3 did 5 push, mmxext 4 pop, so stack was ruined
[23:47] <nevcairiel> oddly enough the ssse3 version even uses mulm to access it, and not a register anyway
[23:49] <klmno> nevcairiel: can I forward  the email to you? is there a chance that you can post it?
[23:50] <nevcairiel> if you want to participate in development, you should figure out why your mail isnt working, not really feeling the need to play mail proxy
[23:50] <klmno> make send, ty for y time
[23:50] <wm4> wat
[23:55] <nevcairiel> apparently patience to find someone who actually admins the ML is a lost virtue
[23:55] <nevcairiel> or getting a proper mail client
[00:00] --- Fri Feb  6 2015