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

[burek]

[00:16:58 CEST] <rcombs> to anyone interested: "The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2d and 1.0.1p. These releases will be made available on 9th July. They will fix a single security defect classified as "high" severity.  This defect does not affect the 1.0.0 or 0.9.8 releases."
[00:55:15 CEST] <wm4> misery
[01:18:47 CEST] <Compn> did openssl get their shit together or same problem as always ?
[01:33:36 CEST] <cone-861> ffmpeg 03Michael Niedermayer 07master:b8c438e76236: videodsp: assert that linesize is larger than width
[02:02:01 CEST] <J_Darnley> Well, I think I'm going to call it a night
[02:02:38 CEST] <J_Darnley> durandal_1707 or anyone else who is interested I pushed my code here: https://gitlab.com/J_Darnley/ffmpeg
[03:30:00 CEST] <cone-861> ffmpeg 03Michael Niedermayer 07master:6a1204a1a466: avformat/swfdec: Do not error out on pixel format changes
[07:38:42 CEST] <durandal_170> michaelni: could you follow style of file before committing something?
[08:02:12 CEST] <cone-433> ffmpeg 03Paul B Mahol 07master:7efe81a813ad: avfilter/vf_colormatrix: add yuv444p support
[10:58:30 CEST] <saste> is there a reason why variable declaration is never used in ffmpeg ASM files?
[10:59:08 CEST] <saste> the only variables are the formal parameters defined in the cglobal function declarations
[11:07:21 CEST] <nevcairiel> some functions also use temp variables
[11:07:26 CEST] <nevcairiel> but its not common
[11:09:43 CEST] <saste> nevcairiel, yes i was wondering why
[11:10:00 CEST] <saste> nevcairiel, what do you mean by "temp variables"?
[11:10:31 CEST] <nevcairiel> you can throw extra variables into the cglobal line beyond the function parameters
[11:11:13 CEST] <saste> nevcairiel, ah, didn't know that
[11:15:11 CEST] <saste> mmh, so we have: cglobal FUNCTION_NAME X,Y,Z, PARAMS
[11:15:20 CEST] <saste> X = number of input parameters
[11:15:33 CEST] <saste> Y = number of total parameters (including temp variables)
[11:15:38 CEST] <saste> Z = ???
[11:15:41 CEST] <saste> what is Z?
[11:15:50 CEST] <nevcairiel> number of SIMD regs
[11:15:55 CEST] <nevcairiel> X/Y refer to GPRs only
[11:16:20 CEST] <saste> nevcairiel, fine, thanks
[11:16:48 CEST] <nevcairiel> there is also an optional 4th argument after Z, stack size to allocate for the function
[11:16:58 CEST] <nevcairiel> its all documented in x86inc.asm
[11:17:04 CEST] <saste> nevcairiel, ok
[11:20:21 CEST] <nevcairiel> i've also seen functions re-declare a register under a new name later on the asm body to clear up the code a bit (ie. creating a new local variable), but its not that common, and only used when you are low on GPRs, ie. when trying to build 32-bit compat
[11:20:46 CEST] <michaelni> durandal_170, which comit messed up style ?
[11:25:09 CEST] <durandal_170> michaelni: 6a1204a1a
[12:07:52 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:656e9a68c43c: avformat/swfdec: Fix "}else" style
[12:07:53 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:e83ffb48aca6: avcodec/utils: Check values in apply_param_change()
[12:56:12 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07release/1.2:bd8d8f57e87b: avformat/swfdec: Do not error out on pixel format changes
[12:56:13 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07release/2.0:804b90a5f578: avformat/swfdec: Do not error out on pixel format changes
[12:56:14 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07release/2.1:ada778c7002a: avformat/swfdec: Do not error out on pixel format changes
[12:56:15 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07release/2.2:b61ee9f03f19: avformat/swfdec: Do not error out on pixel format changes
[12:56:16 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07release/2.3:bf4fa00162d8: avformat/swfdec: Do not error out on pixel format changes
[12:56:17 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07release/2.4:d9655621b3dc: avformat/swfdec: Do not error out on pixel format changes
[12:56:18 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07release/2.5:51a624bb80b3: avformat/swfdec: Do not error out on pixel format changes
[12:56:19 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07release/2.6:a5e18e900f7d: avformat/swfdec: Do not error out on pixel format changes
[12:56:20 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07release/2.7:f921a47fae3e: avformat/swfdec: Do not error out on pixel format changes
[13:06:47 CEST] <saste> http://pastebin.com/zn6zAF74 => what am I missing?
[13:07:24 CEST] <J_Darnley> unaligned vs .unaligned
[13:07:44 CEST] <J_Darnley> oh wait
[13:07:52 CEST] <nevcairiel> you also need to specify sizes for the vars, afaik
[13:08:06 CEST] <nevcairiel> unalignedq for native size (ie. size_t)
[13:08:12 CEST] <J_Darnley> ah yes, you need to append the register sizes
[13:08:18 CEST] <nevcairiel> sizeq, unalignedq
[13:08:49 CEST] <nevcairiel> personally i still feel you should just make it a documented constraint that input needs to be aligned
[13:10:18 CEST] <nevcairiel> for the use-cases where this function is useful, it will be anyway
[13:10:26 CEST] <saste> nevcairiel, J_Darnley: thanks
[13:38:33 CEST] <michaelni> Hi all, we have a problem with the new server, we need some help, a simple upgrade of the ubuntu 14.04 wanted to upgrade grub-pc and it now asks which partition to install to, theres sda sdb md1 and md2, ive never seen this question on a server before, what shall be done?
[13:39:08 CEST] <michaelni> simple upgrade being just the normal apt-get dist-upgrade to get security updates 
[13:43:10 CEST] <J_Darnley> If it was just my PC I would probably answer that by choosing whichever was my boot disk
[13:43:57 CEST] <michaelni> J_Darnley, yes, but its a server with RAID, this didnt come up on any of our previous servers before
[13:45:59 CEST] <J_Darnley> Well, I don't really know anything about system administration so I really can't help.
[14:21:29 CEST] <c_14> michaelni: afaik sda and sdb (you might have to install to one of them with grub-install)
[14:22:19 CEST] <c_14> I know it's not the md*, because those only exist post mdadm and grub doesn't do raid
[14:24:18 CEST] <michaelni> c_14, ok ill wait a bit in case tere are any other comments (i dont want to miss anything ) also ill check hetzners forum once my registratio is approved, we are likely not the first to ht this, and then in case of lackig further information will select sda+sdb
[14:31:16 CEST] <durandal_170> J_Darnley: asm you wrote is gpl only?
[15:06:24 CEST] <J_Darnley> durandal_170: is removegrain not GPL?
[15:06:59 CEST] <J_Darnley> Almost all avisynth plugins were GPL
[15:07:12 CEST] <durandal_170> lgpl
[15:07:36 CEST] <J_Darnley> oh
[15:07:38 CEST] <durandal_170> original is wtfpl
[15:07:55 CEST] <durandal_170> The one from vs
[15:08:36 CEST] <durandal_170> Avs one have 30 modes, latest version IIRC
[15:08:53 CEST] <J_Darnley> huh
[15:09:09 CEST] <durandal_170> vs = vapoursynth
[15:09:18 CEST] <J_Darnley> yes, I knwo that
[15:09:53 CEST] <J_Darnley> I must have forgotten it wasn't gpl
[15:13:59 CEST] <J_Darnley> I guess I'll put the lgpl header on it when I get to that todo
[15:16:51 CEST] <[-T-]> is it a know issue that swscale crashes when doing 720x576 to 720x576 pix_fmt convertion ?    
[15:17:24 CEST] <cone-433> ffmpeg 03Ganesh Ajjanagadde 07master:e34a3468f294: build: add LDLIBFLAGS
[15:54:50 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:80e42387dc52: avcodec/g2meet: Clear pointers after deallocation
[15:56:09 CEST] <durandal_170> [-T-]: how to reproduce?
[15:57:56 CEST] <nevcairiel> its not a known or unknown issue, you are probably using it wrong
[15:58:01 CEST] <nevcairiel> such conversions are extremely common
[16:30:10 CEST] <[-T-]> f'durandal_170: i am doing 720x576 to 720x576 / YUV420 to NV12
[16:30:27 CEST] <[-T-]> it works when doing the same with 1080 to 1080
[16:30:35 CEST] <[-T-]> or YUV to YUV
[16:31:29 CEST] <nevcairiel> you need to make sure the data planes are on aligned memory with at least 16 pixel stride alignment
[16:32:50 CEST] <nevcairiel> there may be an alignment check missing in swscale somewhere, but if those fire, the conversions get super slow anyway, as it switches to pure C code
[16:41:57 CEST] <[-T-]> ok understood!
[16:42:02 CEST] <[-T-]> thanks 
[17:00:12 CEST] <BBB> I think swscale only checks for 16 byte alignment
[17:00:19 CEST] <BBB> some code paths are 32byte now (avx2)
[17:00:23 CEST] <BBB> maybe its something related to that
[17:10:31 CEST] <durandal_170> J_Darnley: post patch when you are happy/finished with it, I will push filter shortly if you do not mind
[17:11:17 CEST] <J_Darnley> That was my plan: post a patch which squashes all my asm commits together
[17:12:14 CEST] <J_Darnley> If I don't finish this evening it should then be tomorrow evening
[17:35:06 CEST] <kierank> BBB: afaik there isn't any avx2 in ffmpeg
[17:35:44 CEST] <BBB> sws doesnt have avx2 it seems
[17:35:47 CEST] <nevcairiel> kierank: hevc_mc uses avx2
[17:35:52 CEST] <nevcairiel> and sao
[17:35:52 CEST] <kierank> ah
[17:35:56 CEST] <nevcairiel> and a few more hevc parts!
[17:36:00 CEST] <BBB> hevc/vp9 use avx2
[17:36:00 CEST] <nevcairiel> vp9 too
[17:36:06 CEST] <nevcairiel> thats about it i guess
[17:36:16 CEST] <nevcairiel> mlpdec has avx2 apparently
[18:01:14 CEST] <cone-433> ffmpeg 03Michael Niedermayer 07master:3c63d06d81e7: avcodec/h264_slice: Fix container cropping
[18:03:05 CEST] <cone-433> ffmpeg 03Paul B Mahol 07master:91748662bc02: avfilter: add removegrain
[18:37:25 CEST] <durandal_170> now to port deband.....
[18:49:37 CEST] <wm4> which deband?
[18:52:54 CEST] <BBB> http://stackoverflow.com/questions/31294874/ffserver-supplying-wrong-mime-type-for-mp4 and http://stackoverflow.com/questions/9929940/correct-mime-type-for-mp4 - should movenc.c -> ffserver use video/mp4 for .mp4 files?
[18:52:57 CEST] <durandal_170> fku3 something
[18:53:11 CEST] <BBB> (I bet nobody cares, but Im happy to send a patch if thats more right)
[18:53:35 CEST] <BBB> right now it says: ../libavformat/movenc.c:    .mime_type         = "application/mp4",
[18:54:02 CEST] <durandal_170> ffserver needs desperately some love
[18:59:49 CEST] <BBB> well this is movenc.c, not ffserver
[18:59:53 CEST] <BBB> so it should be more loveable
[19:05:39 CEST] <wm4> durandal_170: this is apparently mostly equivalent to f3kdb, except some thousands of lines of code shorter: https://github.com/haasn/gentoo-conf/blob/master/home/nand/.mpv/shaders/deband.glsl
[19:07:46 CEST] <durandal_170> so I need to REd glsl
[19:14:40 CEST] <jamrial> BBB: https://www.rfc-editor.org/rfc/rfc4337.txt apparently yes, should be video/mp4
[19:15:25 CEST] <jamrial> ogg also sets the wrong mimetypes according to the latest rfc. i mentioned it some time ago
[19:15:52 CEST] <Compn> BBB : send patch
[19:15:56 CEST] <Compn> (or just commit)
[19:18:40 CEST] <BBB> I dont think I have w+
[19:18:45 CEST] <BBB> can you guys commit for me?
[19:29:07 CEST] <durandal_170> what, why?
[19:35:27 CEST] <Compn> BBB : the key changed, so you have to ssh into git.ffmpeg.org
[19:35:39 CEST] <BBB> durandal_170: ?
[19:35:40 CEST] <Compn> er rrrr i'm thinking of git.videolan.org nevermind
[19:36:07 CEST] <Compn> er thinking of the ffmpeg-web repo not videolan ffmpeg repo
[19:36:26 CEST] <Compn> all devs should have write access, if you want it just aks michael and send key...
[19:36:38 CEST] <Compn> but sure i will change it
[19:37:02 CEST] <Compn> or maybe i'll send patch  first
[19:37:40 CEST] <durandal_170> BBB: you should have write access to git
[19:37:50 CEST] <BBB> why?
[19:37:56 CEST] <BBB> Id probably mess things up
[19:38:10 CEST] <BBB> you should see my github tree
[19:38:23 CEST] <BBB> I probably push -f more than half of the time
[19:49:42 CEST] <michaelni> BBB, theres a key for ronaldbultje at ronald-bultjes-computer.local on ffmpeg at videolan 
[19:49:58 CEST] <BBB> thats super scary :D
[19:56:04 CEST] <haasn> wm4: I don't actually know if it's equivalent or not. I never managed to figure out one bit of f3k, the code is such a mess
[19:56:35 CEST] <haasn> (Namely: what pixel pattern it samples from; whether it's always a set pattern or if the direction is randomized as in my code)
[19:56:50 CEST] <haasn> never managed to figure out that bit*
[19:56:59 CEST] <wm4> heh
[19:57:12 CEST] <haasn> But I found randomization helps, so my code does it. Probably the only real difference is the random algorithm
[19:57:16 CEST] <haasn> .. still need to address that in mpv :p
[19:57:20 CEST] <wm4> in any case it probably doesn't make sense to try to port f3kdb fully
[19:57:29 CEST] <haasn> well, that *is* f3kdb, fully
[19:57:43 CEST] <wm4> I mean, copying the code and ffmpeg-izing it
[19:59:37 CEST] <haasn> Most of fk3db is just wrappers around it, alternate modes to do the same thing, optimizations, etc.
[20:01:59 CEST] <haasn> eg. support for the hacked together 16-bit support in avisynth
[20:07:56 CEST] <philipl> wm4: Does mpv support vdpau readback for software filter usage?
[20:11:21 CEST] <Compn> BBB : they let me have write access too , that SHOULD scare you ;)
[20:11:23 CEST] <Compn> ehe
[20:11:29 CEST] <wm4> philipl: no
[20:12:00 CEST] <wm4> philipl: and for screenshots, mpv renders to an output surfaces and reads that
[20:14:41 CEST] <philipl> wm4: I made a half-hearted attempt at implementing support for it in mplayer as a filter but it's a real mess - as you need 90% of the same logic the vo has.
[20:15:07 CEST] <philipl> wm4: I guess the main filter I'd care about it rotation (vertical camera videos) which vdpau can do itself with a little work
[20:15:32 CEST] <libnova> Hi! Related to the hosting request, would be ok for you a OVH (France) 64gb ram xeon server with 4tb storage dedicated for the project? Administration of the server should be on your side. We can offer at least 2 years prepaid server.
[20:16:23 CEST] <wm4> philipl: heh, since mpv has opengl interop for vdpau decoding, the video mixer is separate from the vo in mpv
[20:17:41 CEST] <philipl> wm4: Nice. Then the part that's left is what you'd also use for a read-back filter.
[20:17:47 CEST] <wm4> and rotation would AFAIK require render one output surfaces on another
[20:18:08 CEST] <wm4> +to
[20:18:09 CEST] <philipl> wm4: Yes - you can only rotate output surfaces.
[20:18:38 CEST] <wm4> the nasty thing about all this is that the videomixer does scaling in vdpau
[20:18:50 CEST] <wm4> you can probably scale output surfaces too, but then you can'T select hqscaling
[20:18:55 CEST] <wm4> so this is all a bit annoying
[20:19:07 CEST] <wm4> well, unless you really want to read back to RAM
[20:19:35 CEST] <philipl> That means vdpau-specific rotation would have to rotate after scaling.
[20:19:55 CEST] <philipl> Read-back for software rotation would avoid that for sure.
[20:20:54 CEST] <wm4> philipl: the question is, how slow is read back
[20:21:11 CEST] <wm4> and what latency
[20:21:32 CEST] <durandal_170> libnova: ask michaelni 
[20:21:59 CEST] <philipl> Others here have said it's very good on nvidia. I've tested 'ffmmpeg -hawccel vdpau' transcoding and it certainly isn't decoder limited in that case.
[20:22:28 CEST] <philipl> Don't know about latency - haven't got it working far enough to test.
[20:22:38 CEST] <wm4> so it might be worth a try
[20:23:05 CEST] <philipl> I got my mplayer test code far enough to read-back and loop-back to the mixer one frame. After that it seemed to only show blank frames, so I messed something up in the queue handling.
[20:24:12 CEST] <wm4> not sure what you mean by loop-back
[20:24:24 CEST] <libnova> durandal_170: ok
[20:24:54 CEST] <michaelni> libnova, this sounds interresting but what happens after 2 years ? we would have to pay ?
[20:25:24 CEST] <philipl> wm4: I mean, my filter decodes the frame and reads it back to pass on the chain. Then the vdpau vo takes the yuv frame and displays it like it does for software decoding
[20:25:49 CEST] <wm4> philipl: wait, why would a filter decode?
[20:26:03 CEST] <philipl> wm4: It has to, if you want to chain to normal filters.
[20:26:31 CEST] <philipl> wm4: In mplayer the decoder is managed by the vo, remember.
[20:26:38 CEST] <philipl> I'm sure you fixed that.
[20:26:38 CEST] <wm4> doesn't it just get the video surfaces from the decoder?
[20:26:53 CEST] <philipl> I mean the vdpau decoder object.
[20:27:14 CEST] <wm4> I think I remember something about the VO creating and handling the vdpau decoder in mplayer...
[20:27:41 CEST] <libnova> michaelni, No, I mean that I can assure you will be at least 2 years on that server
[20:27:48 CEST] <philipl> Yeah. It's messy. So while mplayer is using hwaccel, it's using this special path where it passes the decoder in instead of letting avcodec instantiate it.
[20:27:50 CEST] <wm4> yeah, these are completely decoupled in mpv (they only have some shared state like the vdpau device)
[20:28:19 CEST] <philipl> I'm sure I'd have less brain melting trying to do this in mpv :-)
[20:29:26 CEST] <libnova> In the sense of not needing to migrate at least in two years. When 2 years date approach, we could extend free or you migrate to another hosting option
[20:29:39 CEST] <wm4> I guess mpv and mplayer did diverge a bit
[20:29:47 CEST] <haasn> wm4: wouldn't rotation work just fine with vo=vdpau hwdec=vdpau? what am I missing here?
[20:29:54 CEST] <haasn> err vo=opengl
[20:30:04 CEST] <libnova> No hidden motivations here
[20:30:15 CEST] <wm4> haasn: yes it does
[20:30:23 CEST] <michaelni> libnova, yes, this sounds nice, what cpus does it have ?
[20:30:27 CEST] <wm4> haasn: but with vo_vdpau it doesn't yet
[20:30:39 CEST] <wm4> and mplayer doesn't even have GL interop
[20:30:56 CEST] <haasn> (why does it have to be vo_vdpau, though?)
[20:31:09 CEST] <Compn> humm i should have found a better specification url
[20:31:15 CEST] <Compn> safari web mime types :\
[20:31:20 CEST] <Compn> BBB : patch posted.
[20:31:46 CEST] <BBB> lgtm, thanks!
[20:32:18 CEST] <libnova> http://ark.intel.com/products/75779/Intel-Xeon-Processor-E5-1620-v2-10M-Cache-3_70-GHz
[20:32:31 CEST] <libnova> 3.7ghz
[20:33:19 CEST] <Compn> 4 cores , the important bit ;)
[20:33:38 CEST] <BBB> I want a laptop with such a thing
[20:34:32 CEST] <Compn> i7 laptop ?
[20:34:43 CEST] <BtbN> i7 laptops usualy are just dual cores
[20:34:47 CEST] <Compn>  ah
[20:34:48 CEST] <michaelni> libnova, ok, and what disks ? and is there any monthly traffic limit (i have no idea whatsoever in case we are on slashdot how much traffic that would cause)
[20:35:33 CEST] <Compn> kind of funny that 10k people all upgrade at once when a story hits slashdot :P
[20:36:04 CEST] <libnova> No limited. 500mbps wrant 1 gbps burst
[20:37:40 CEST] <michaelni> libnova, your offer is better than the "paid by ourself" server we hastly rented and also better then the other free server we have, so i think we accept your offer :)
[20:38:10 CEST] <libnova> Small ssd disk for php etc and sata raid
[20:39:28 CEST] <libnova> Ok, I'll send my email for you to contact and prepare it ok?
[20:40:26 CEST] <michaelni> libnova, ok
[20:41:23 CEST] <Compn> what happened ot the nex michigan hoster offer ? 
[20:44:10 CEST] <philipl> wm4: I think it would be pretty easy to write a read-back filter in mpv. Everything's organised in a much more usable way than in mplayer. I'll look into it when I get a chance.
[20:46:20 CEST] <wm4> philipl: go ahead... note that the VO is still the thing that creates the hw context (like vdpau device)
[20:46:52 CEST] <wm4> except the vaapi read-back code, which is all kinds of terrible, and exists because direct output tends to cause issues with vaapi
[20:47:28 CEST] <BtbN> vaapi doesn't realy have direct output anyway
[20:48:03 CEST] <philipl> wm4: Right.
[20:48:26 CEST] <BtbN> I think they added something for EGL mode, but it's still way behind vdpau with its own OpenGL extension
[20:48:36 CEST] <wm4> BtbN: I'm just trying not to have to copy it back to RAM
[20:48:58 CEST] <wm4> and last I heard the EGL thing was actually deprecated/discouraged (not sure)
[20:49:15 CEST] <BtbN> hm? Wasn't it just introduced?
[20:49:23 CEST] <wm4> maybe I was thinking of something else
[20:49:29 CEST] <wm4> who knows, there's no documentation
[20:49:44 CEST] <BtbN> I think you can't realy avoid the copy back to system ram.
[20:50:18 CEST] <BtbN> When i tested that stuff for xbmc, the "direct rendering" funtions were slower than copying and manualy uploading to an OpenGL texture
[20:51:54 CEST] <wm4> mpv now lets vaapi render to a GL mapped pixmap
[20:51:59 CEST] <wm4> supposedly it's faster
[20:52:17 CEST] <BtbN> using glx?
[20:52:20 CEST] <wm4> yes
[20:52:26 CEST] <wm4> (but not the vaapi glx interop)
[20:52:29 CEST] <BtbN> Have you looked at how it does that internaly?
[20:52:32 CEST] <BtbN> hm?
[20:53:01 CEST] <Compn> michaelni : i approved a hosting mail on ffmpeg-devel that was stuck in the queue.
[20:53:05 CEST] <wm4> it renders to a Pixmap using the X vaapi API, and then uses GLX_EXT_texture_from_pixmap
[20:53:24 CEST] <BtbN> using vaPutSurface?
[20:53:53 CEST] <BtbN> iirc that was the awfully slow function.
[20:54:21 CEST] <wm4> yes, vaPutSurface
[21:02:17 CEST] <llogan> Compn: i was wondering why there was nothing in the queue...
[21:05:15 CEST] <Compn> beat you to it! :D
[21:06:42 CEST] <llogan> why doesn't claws mail allow searching of the raw message? annoying.
[21:20:05 CEST] <wm4> claws-mail is so bad
[21:20:20 CEST] <wm4> but I'm still using it because other mail clients are bad too
[21:23:43 CEST] <JEEBsv> I noticed recently that thunderbird beta plugged in that calendar thing they've been building for a while
[21:37:10 CEST] <BtbN> lightning?
[21:44:10 CEST] <michaelni> <Compn> kind of funny that 10k people all upgrade at once when a story hits slashdot :P <--- i think your estimation is off a bit, we have 100gb traffic per day at average, in ffmpeg.tar.bz2 units thats 12k a day already that is if all the traffic comes from ffmpeg downloads which sure it does not
[21:54:08 CEST] <llogan> a wiki article written by someone named hahaha1234 is destined to be a dung heap of rambling thoughts and self-talking.
[21:54:28 CEST] <llogan> and here i thought rodgerdpack was bad
[22:00:25 CEST] <Compn> thunderbird is like if netscape came back and did an email client :)
[22:09:52 CEST] <BBB> I was wondering about that account
[22:09:57 CEST] <BBB> the changes seemed helpful though
[22:09:59 CEST] <BBB> not spammy at least
[22:12:12 CEST] <BBB> michaelni: wtf we have 100gb traffic per day?
[22:12:19 CEST] <BBB> like, seriously, wtf?
[22:12:27 CEST] <BBB> what kind of traffic is that?
[22:12:32 CEST] <llogan> that probably excludes trac
[22:12:56 CEST] <llogan> *possibly
[22:15:26 CEST] <jamrial> BBB: fate samples rsync server probably contributes to it
[22:16:21 CEST] <jamrial> It's currently about 900mb
[22:18:37 CEST] <michaelni> BBB, no clue, i just looked at ifconfig stats and divided by uptime
[22:21:52 CEST] <michaelni> also thats not just ffmpeg, its mplayer too, samples, fate-suite
[22:23:01 CEST] <michaelni> not trac, trac was less
[22:23:13 CEST] <wm4> that's only 1.185MB per second sustained
[22:23:57 CEST] <michaelni> yeah about 10mbit ethernet speed at average
[22:27:19 CEST] <philipl> wm4: I've got an mpeg2 TV recording here that mpv is insisting on software decoding. Same commandline uses hw decoding for an h.264 file.
[22:28:11 CEST] <wm4> philipl: mpeg2 hw decoding is disabled for some reason, retry with --hwdec-codecs=all
[22:28:21 CEST] <wm4> I think there was a problem with interlaced video
[22:29:24 CEST] <philipl> This is 720p video. It also failed and said it was going to fall back. Perhaps because it's a raw capture so the first couple of frames are unusable.
[22:29:28 CEST] <philipl> but it plays fine with mplayer
[22:30:15 CEST] <wm4> yep, decoding errors (which are really parser errors or whatever you'd call them) cause a forcible fallback
[22:30:26 CEST] <philipl> Ok.
[22:30:43 CEST] <wm4> (I'm not sure if this behavior still makes sense)
[22:30:56 CEST] <philipl> It seems overly conservative in this case.
[22:33:22 CEST] <wm4> originally, making get_format fail was used for making it fall back if e.g. the codec profile coudln't be handled by the hw
[22:42:05 CEST] <philipl> A reasonable desire. mplayer will just fail frames continuously in that case.
[22:45:05 CEST] <wm4> philipl: is this file available somewhere?
[22:50:27 CEST] <kierank> https://lwn.net/Articles/650495/
[22:51:26 CEST] <wm4> yeah
[22:51:40 CEST] <wm4> all the leverage Libav had is gone now
[22:51:47 CEST] <wm4> and FFmpeg can keep piling hacks upon hacks
[22:53:50 CEST] <JEEBsv> not like it wouldn't do it anyways
[23:18:54 CEST] <philipl> wm4: http://intr.overt.org/misc/mpeg2-sample.mkv
[23:19:23 CEST] <philipl> It's from a raw broadcast ts that I remuxed into mkv.
[23:21:40 CEST] <llogan> does that mean Debian will still provide Libav or not? I wasn't following and didn't really read much because i'm a lazyass.
[23:22:52 CEST] <philipl> It's not clear, but I think they will drop it, given that the security guys don't want to have to follow two projects.
[23:25:05 CEST] <llogan> i wonder why nobody wrote a Libav version of the wiki FFmpeg article written by Andreas
[23:25:29 CEST] <philipl> There doesn't seem to really be anyone left to defend it.
[23:25:39 CEST] <philipl> The security guys started off skeptical but got won over.
[23:25:47 CEST] <philipl> Reinhardt seems to have given up the fight.
[23:25:50 CEST] <philipl> Who else is left?
[23:31:24 CEST] <wm4> philipl: thanks, doesn't fallback here zhough
[23:31:30 CEST] <wm4> *though
[23:31:37 CEST] <philipl> Hmm.
[23:54:18 CEST] <J_Darnley> Am I going insane!?  Did this not work yesterday!?  Did I test it incorrectly!?
[23:56:19 CEST] <jamrial> J_Darnley: if you mean your removegrain asm, i tested half the modes last night and they produced the same output as the c version
[23:56:25 CEST] <jamrial> nice speed up for that matter
[23:57:26 CEST] <J_Darnley> Yes, mode 5 and 18 no longer test correctly for me (and some new ones I've added)
[23:58:05 CEST] <J_Darnley> perhaps I need to double check what I have changed since then.
[23:58:44 CEST] <jamrial> that's the benefit of committing often :p
[23:59:18 CEST] <J_Darnley> I was doing that but not testing every thing everytime I changed something
[23:59:33 CEST] <jamrial> durandal_170: maybe you could add some fate tests for removegrain?
[23:59:52 CEST] <J_Darnley> I will do a git rebase -i --exec
[00:00:00 CEST] --- Thu Jul  9 2015