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

[burek]

[00:09:05 CET] <J_Darnley> kierank: another function patch for you, h264 chroma422 https://gitlab.com/J_Darnley/ffmpeg/commit/6380c010adfb2462318599263db5d83c4045a230
[00:10:59 CET] <J_Darnley> jamrial ^ if you want to look too
[00:15:25 CET] <kierank> NICE
[00:19:31 CET] <J_Darnley> oops a slight bug there
[00:19:46 CET] <J_Darnley> I need to reserve 1 mmsize more stack space
[00:27:57 CET] <kierank> J_Darnley: is ff_h264_dct_dc_add_8_c a bug?
[00:28:00 CET] <kierank> there seems to be asm
[00:32:01 CET] <cone-219> ffmpeg 03Maxim Andreev 07master:7145e80b4f78: avformat/hls: forbid all protocols except http(s) & file
[00:33:00 CET] <kierank> seems to be different for 422
[00:33:16 CET] <wm4> haha that commit
[00:33:57 CET] <wm4> wait why is file allowed
[00:34:36 CET] <durandal_170> send that picture of you over here
[00:35:03 CET] <durandal_170> kill server side
[00:37:10 CET] <J_Darnley> kierank: did I comment something by accident?
[00:37:24 CET] <kierank> no I mean in the asm profiler I sent you
[00:37:35 CET] <kierank> one of the asm functions runs as c but it appears the asm exists
[00:37:44 CET] <kierank> in the init it's chroma_format dependent but I dunno why
[00:37:46 CET] <J_Darnley> ah
[00:37:56 CET] <kierank> don't see how the c can be chroma independent but the asm not
[00:38:42 CET] <kierank> some nice work though
[00:38:47 CET] <kierank> big speedups on 422
[00:39:09 CET] <durandal_170> numbers!
[00:39:33 CET] <J_Darnley> grep can't find that function for me
[00:40:24 CET] <kierank> J_Darnley: https://github.com/FFmpeg/FFmpeg/blob/235381e674bf0921cbb7871946e2ff08bd84d6ba/libavcodec/x86/h264dsp_init.c#L228
[00:40:40 CET] <ChALkeR> Btw, does mplayer use ffmpeg or share code with ffmpeg in any way?
[00:40:44 CET] <ChALkeR> mplayer is also affected
[00:41:00 CET] <ChALkeR> even after installing a fixed version of ffmpeg.
[00:41:28 CET] <wm4> mplayer has no hls code and uses ffmpeg's
[00:43:23 CET] <J_Darnley> Oh yes, its buried in the templating
[00:43:54 CET] <ChALkeR> wm4: I guess it bundles libavformat
[00:44:15 CET] <wm4> normal builds do
[00:44:43 CET] <durandal_170> make sure it uses new libavformat
[00:46:52 CET] <wm4> so why does the fix allow local files?
[01:05:10 CET] <J_Darnley> kierank: I can't explain why that uses a C function
[01:05:27 CET] <kierank> there's a check in the init that looks at the chroma format
[01:06:56 CET] <J_Darnley> but not for that idct function
[01:07:38 CET] <J_Darnley> oh wait, am I looking at the wrong function
[01:09:53 CET] <J_Darnley> oh add vs add8
[01:10:28 CET] <J_Darnley> Are mmx and mmxext functions disabled on that system you profiled?
[01:10:41 CET] <kierank> that is avdev iirc
[01:10:45 CET] <kierank> no shouldn't be
[01:11:07 CET] <J_Darnley> oh I see one mmxext further down
[01:11:38 CET] <kierank> hmmm
[01:11:58 CET] <kierank> all protected by if (chroma_format_idc <= 1)
[01:12:57 CET] <J_Darnley> I'll step though in gdb and have a look
[01:21:46 CET] <J_Darnley> I wonder whether it is from probing
[01:22:16 CET] <J_Darnley> the dsp_init function gets called a few times and one with idc value = 1
[01:25:45 CET] <cone-219> ffmpeg 03Andreas Cadhalpun 07master:44ac13eed495: dca: fix misaligned access in avpriv_dca_convert_bitstream
[01:31:31 CET] <kierank> I don't understand why the >= 422 check is needed
[02:07:43 CET] <cone-219> ffmpeg 03Ganesh Ajjanagadde 07master:a0a47a09b0e2: lavu/libm: add isfinite fallback
[02:11:51 CET] <jamrial> wtf
[03:21:28 CET] <BBB> jya: hey there - really happy to see you guys using ffvp9
[03:36:10 CET] <jya> So am I :). However unless we can change the threading model as I referred to in my post to the devel list. It's going to have problem. 
[03:40:49 CET] <BBB> jya: it sounds like it can be figured out& wm4 can sometimes be a little grumpy, thats ok
[03:41:30 CET] <BBB> jya: if we do what derek and somebody else suggested (michael?) and use a threadqueue as a optional parameter into each avcodeccontext and allow you to implement that in whatever way, would that be sufficient?
[03:42:00 CET] <BBB> its a little bit overdesigned maybe but then again this isnt a problem that will occur for simple usage so maybe thats ok
[04:04:10 CET] <jya> BBB: yes that would be. So long that we can share the thread pool. So for us we can limit the overall number of threads used globally.
[04:05:20 CET] <jya> wm4 suggestion of not using threads is a very poor one. Because there are times when you *do* want to use many threads. In fact I would want to use as many threads as possible.
[04:06:13 CET] <jya> Like the user has one window watching YouTube. Multi-threading is pretty much a must.
[04:07:48 CET] <jya> I can't really understand why you would want to limit the use of a thread pool overall though and make that optional. It's such a superior concept :)
[04:09:28 CET] <jya> Being C, such new API would probably only need a pointer to a context and a pointer to the function to call. Similar to how Apple VideoTooolbox callback system works.
[04:10:21 CET] <BBB> jya: right& we use that for integrating with threading frameworks already
[04:12:24 CET] <BBB> example: https://www.ffmpeg.org/doxygen/trunk/group__lavc__misc.html#gae120ec60cdf49cf0f793eff3ec731bcc
[04:12:35 CET] <BBB> all this stuff is rather creepy, but hey&
[04:12:38 CET] <jya> If one of you could provide the framework/API to connect to. I would be able to write something very quickly to integrate that in gecko.
[04:13:17 CET] <jya> I wonder what chrome is doing for addressing this problem.
[04:13:31 CET] <BBB> they cap it at 2 threads or so, dont they?
[04:13:38 CET] <jya> For their use of libvpx, they just create new threads per decoder.
[04:13:42 CET] <BBB> there might be other things that Im not aware of
[04:13:52 CET] <BBB> I dont think they do anything advanced TBH
[04:14:07 CET] <BBB> but its been a while since I last looked at it
[04:14:30 CET] <jya> They use 2 for vp8; then 4 if width >= 1024 and 8 if >= 2048. Then they min that with what ever number of processors is available.
[04:15:20 CET] <jya> Having said that. WebKit has never been much caring about resources and low-end system :)
[04:15:32 CET] <jya> Well now blink.
[04:15:57 CET] <BBB> I couldnt build chrome on my laptop for the longest of times :D
[04:16:29 CET] <jya> In my tests, I found that ffvp9 pretty much always allowed us to decode one resolution up compare to libvpx.
[04:16:58 CET] <jya> Eg 1080p where it used to do 720p max, 720p where it was 480p etc
[04:17:15 CET] <BBB> its a lot faster, thats all I know ;)
[04:17:19 CET] <jya> That's on quad core laptops. Not that much on dual core.
[04:17:24 CET] <BBB> its not as much faster on hyper-high end machines
[04:17:32 CET] <jya> The difference isn't as dramatic there.
[04:17:54 CET] <BBB> like, 40% or so on mid-to-low end hardware (sandybridge to old intel pentiums)
[04:17:58 CET] <BBB> and more like 25% on haswell
[04:18:12 CET] <jya> I found a sample video where my Mac Pro 8 cores will takes 49s to decode 10s worth
[04:18:25 CET] <BBB> haswell can be improved a lot (theres not much axv2, jamrial wrote some but loopfilter/idct is not covered)
[04:18:37 CET] <BBB> holy crap thats bad
[04:18:41 CET] <BBB> how big is that video
[04:18:42 CET] <jya> And with ffvp9 it's fast enough to play real time.
[04:18:43 CET] <BBB> is that 8k?
[04:19:10 CET] <BBB> ooo I know, it doesnt use frame-parallel=1
[04:19:13 CET] <jya> No 4K, encoded with one of the early version of libvpx, with a single keyframe at the beginning.
[04:19:23 CET] <BBB> if you disable frame-parallel and tiling, libvpx doesnt do multithreading
[04:19:34 CET] <BBB> Ive brought this up several times with them but I dont think they hav manpower to fix it
[04:19:47 CET] <BBB> its quite some work and they dont care since youtube uses tiling and frame-parallel
[04:19:54 CET] <jya> YouTube doesn't use that encoding. So the difference isn't as flagrant.
[04:20:39 CET] <BBB> Im going to sleep now& is what I said about the threadpool helpful or do you need more details on that?
[04:20:52 CET] <jya> And I'm going for lunch :)
[04:21:19 CET] <jya> It is. So long that there's a possibility that it can be done.
[04:21:40 CET] <jya> Makes me feel better that reading wm4 ridiculing the idea.
[04:22:08 CET] <BBB> well, were not an organization so youll get more noise in discussions, not noise as in stupid people, but noise as in more noticeable when theres no complete agreement
[04:22:38 CET] <BBB> but I think the threadpool idea isnt completely outrageous, and derek/michael seem to be ok with the basic concept also, so its probably fine
[04:23:49 CET] <jya> Great.
[05:25:37 CET] <cone-730> ffmpeg 03Claudio Freire 07master:62dfe1d40d87: avcodec/aacenc_is: replace pow(x, 0.75) by x/sqrtf(sqrtf(x))
[08:11:46 CET] <wm4> jya: so I still don't understand why you think it's a good idea to keep hundreds of decoders alive at the same time - even if you use a thread pool, it will use a lot of memory and CPU time no matter how you implement it
[08:13:05 CET] <jya> because you may have 100 of videos playing at the same time. of course it will use a lot of memory. But we're not going to rewrite the W3C spec because you think it's silly :)
[08:13:50 CET] <wm4> I believe you already deallocate images etc. if they're not visible (and many websites also lazily load images with JS)
[08:13:58 CET] <wm4> now I'm wondering why this should be different with video
[08:14:15 CET] <wm4> but I guess I'm just stupid
[08:14:58 CET] <jya> if they are not visible, then sure, we have strategies in place to not display hidden videos, though we continue to play audio (we have to)
[08:15:10 CET] <wm4> (meanwhile I'm restarting firefox every other day because its memory management is so great, heh)
[08:15:43 CET] <jya> when a video is hidden, we stop decoding while we continue to play the audio if there's an audio track, or otherwise simulate where it's up to
[08:16:27 CET] <jya> however, many videos used in ads, happen to not even have more than a single keyframe, and they may use JS to make them play in a loop
[08:16:50 CET] <jya> wm4: which distribution are you using?
[08:16:57 CET] <jya> (assuming you're using linux)
[08:17:30 CET] <jya> because the funny thing is we're tracking a big leak in libavcodec 54 from LibAV used in ubuntu 14.04
[08:19:50 CET] <wm4> jya: debian unstable (I believe it uses ffmpeg already)
[08:20:08 CET] <wm4> I wonder if that memory leak is the one I fixed a long time ago
[08:21:12 CET] <jya> unfortunately, unlike google, we aren't at liberty to ship ffmpeg 
[08:21:36 CET] <jya> so we're stuck with whatever is installed, and you wouldn't believe how many people are still using 12.04 with LibAV 8
[08:22:15 CET] <jya> and we've only allowed to use ffmpeg directly in firefox 43, before it had to be through gstreamer
[08:23:46 CET] <jya> back to playing a video in the background, the user expect when a tab is put in the background that the only difference is being hidden. E.g. any animations, music, videos, just continue as if it wasn't hidden. And so when the tab/window becomes visible again it shows up as if it hadn't been hidden at all
[08:23:54 CET] <jya> many people put youtube and listen in the background
[08:24:29 CET] <jya> while we attempt to suspend decoding the video track, when becoming visible and resuming decoding: we want the seek to be fast
[08:24:51 CET] <jya> so if we've determined that the keyframe is too far off , we may not pause the decoding
[08:25:14 CET] <wm4> I'm sure the user appreciates it when hundreds of audio clips are played at the same time (sorry I find this still absurd)
[08:25:44 CET] <jya> well, they can disable the audio by clicking on the volume for a particular tab
[08:26:09 CET] <jya> doesn't mean that when you make it back , you have to resume from where you were
[08:26:23 CET] <jya> and if it was a live audio stream, you have trouble
[08:27:07 CET] <jya> there's also the issue that a JS could very well decide to grab frames from a video playing
[08:27:26 CET] <jya> so we also have to detect that (in which case you can't pause)
[08:28:02 CET] <jya> but to cut it short, how its used is pretty much limitless. You don't "educate" the user on how many windows they should have opened
[08:28:26 CET] <jya> so it comes down to what actually happen: and having lots of videos playing at once, happen a lot
[08:28:56 CET] <jya> if we're too slow at decoding video, we drop and ultimately skip to key frame
[08:29:14 CET] <wm4> is that why my firefox seems to be constantly using CPU even if it runs in the background and I don't interact with websites (yay we're getting more of that in the future)
[08:29:22 CET] <jrosser> we built a video editor in a browser http://www.bbc.co.uk/rd/projects/nearly-live-production
[08:29:35 CET] <jrosser> lots of simultaneous videos
[08:30:10 CET] <jrosser> that sort of thing is key for new production tools
[08:30:53 CET] <jya> wm4: because a page is rarely static it'd made of anymated objects.
[08:31:19 CET] <jya> you could always use lynx, it's very efficient
[08:31:50 CET] <jya> i
[08:33:02 CET] <jya> what jrosser describe is typically a case where having a global pool thread would help: it goes super fast when you have just the main video playing, but doesn't bog down the entire machine when you have too many
[08:35:37 CET] <jrosser> get them all synced too please :)
[08:35:52 CET] <jrosser> but thats a different discussion.....
[08:41:38 CET] <dinux5> which repository should I clone in order to get started with contributing to ffmpeg ? I am a newbie and good at C .
[08:43:31 CET] <JEEB> git.videolan.org's ffmpeg
[08:43:51 CET] <JEEB> that's the current main repo
[11:45:13 CET] <kierank> jya: why cant you ship ffmpeg
[11:46:45 CET] <jya> legal reasons, I can't comment further
[11:48:11 CET] <durandal_1707> patents
[11:48:17 CET] <kierank> On what
[11:48:26 CET] <kierank> ffvp8 and vp9?
[11:49:25 CET] <jya> we are shipping the ffmpeg code for ffvp8 and ffvp9 since last week.
[11:49:51 CET] <kierank> Then why can't you statically link
[11:50:01 CET] <kierank> Or ship your own .so
[11:50:12 CET] <t4nk283> what is the best way to package ffmpeg into software so that a program refers to its own copy instead of searching the system?
[11:50:16 CET] <jya> well, more exactly a butchered version of ffmpeg that can only do vp8 and vp9
[11:51:14 CET] <jya> kierank: 1: firefox isn't GPL (static linking) 2. again we can't ship ffmpeg nor use its code. 
[11:51:45 CET] <kierank> Probably only a few hundred kB with vp8/9
[11:51:57 CET] <jya> I wish
[11:53:31 CET] <t4nk283> please let me know if my question is unclear
[11:53:48 CET] <jya> 5.2MB source code, 3.6MB for libavcodec, 300kB for libavutil
[11:54:07 CET] <jya> that's debug build though
[12:05:06 CET] <wm4> was this with --disable-everything? (or whatever it was)
[12:42:04 CET] <jya> wm4: i exctracted such as only vp8/vp9 decoder and all it depends on would compile (so that upgrading in the future would be easy). So for example there is common code in the h264 part, so that's included too. It was made in such a fashion that no one could ever enable any other codecs. 
[12:42:15 CET] <jya> the files were identified after using ./configure --disable-everything --disable-protocols --disable-demuxers --disable-muxers --disable-filters --disable-programs --disable-doc --disable-parsers --enable-parser=vp8 --enable-parser=vp9 --enable-decoder=vp8 --enable-decoder=vp9 --disable-static --enable-shared --disable-debug --disable-sdl --disable-libxcb
[12:42:16 CET] <jya> --disable-securetransport --disable-iconv --disable-swresample --disable-swscale --disable-avdevice --disable-avfilter --disable-avformat --disable-d3d11va --disable-dxva2 --disable-vaapi --disable-vda --disable-vdpau --disable-videotoolbox --enable-asm --enable-yasm as command
[12:42:42 CET] <jya> (note that I find it rather humour that there are still so much stuff you must disable on top of --disable-everything)
[12:43:22 CET] <nevcairiel> there is also --disable-all that disables even more, but unless you turn some stuff back on after that, i dont think it actually builds anything
[12:44:55 CET] <atomnuker> that's kinda evil unless you can't even distribute the source code
[12:45:28 CET] <wm4> (I really love how ffmpeg shares parts between vp8 and h264, even though Google claims vp8 does not violate h264 patents)
[12:45:50 CET] <wm4> it's like ffmpeg devs said "no, that's bullshit"
[12:46:12 CET] <nevcairiel> there is always overlap in the more generic DSPs
[12:46:35 CET] <wm4> at least that doesn't have "h264" in the names
[12:47:52 CET] <nevcairiel> vp8 uses h264pred apparently
[12:47:55 CET] <nevcairiel> vp9 doesnt
[12:49:12 CET] <nevcairiel> looks like just for soem defines
[12:49:38 CET] <nevcairiel> oh no, it actually uses the pred code as well
[13:08:45 CET] <durandal_1707> I just remove bass note with GIMP, will push spectrumsynth soon
[13:22:50 CET] <ubitux> tmm1: i will look tonight
[14:31:59 CET] <cone-990> ffmpeg 03Paul B Mahol 07master:70df51112ccc: avfilter/af_dynaudnorm: fix possible null pointer dereference
[14:54:08 CET] <durandal_1707> how to do afftfilt, like aeval but in frequency domain?
[14:54:43 CET] <Daemon404> kierank, gopro having layoffs
[14:54:44 CET] <Daemon404> it's all your fault
[14:57:50 CET] <Compn> did apple buy it out ?
[14:58:09 CET] <Compn> gopro cameras going to go up in price and also white plastic...
[15:14:15 CET] <an3k> is this the channel of the well-known ffmpeg package in debian/ubuntu ?
[15:14:53 CET] <J_Darnley> No
[15:14:57 CET] <J_Darnley> We are imposters
[15:16:36 CET] <an3k> so you are the libav guys who caused the removal of the ffmpeg package?
[15:16:56 CET] Action: J_Darnley facepalms
[15:17:01 CET] <J_Darnley> that was a bad joke
[15:17:07 CET] <J_Darnley> Yes this this is FFmpeg
[15:17:10 CET] <BBB> hehehe
[15:17:27 CET] <J_Darnley> Libav is that way *points* somewhere
[15:17:48 CET] <BBB> an3k: were ffmpeg developers; some of us may be involved with debian packaging, but were primarily involved in the actual software development, not so much debian packaging
[15:18:18 CET] <an3k> J_Darnley I understood the joke. Just wanted to be sure that I'm not talking with these bastards who cause a huge headache :)
[15:19:04 CET] <BBB> wm4: h264pred is just a name
[15:19:32 CET] <BBB> wm4: to say that that tecnology originates in h264 is kind of silly, its shared between various decoders and h264 is just the bestknown/first of them so the naming originates from that
[15:20:03 CET] <an3k> Since two days I'm trying to get VapourSynth + L-SMASH + L-SMASH Works compiled and because there's no ffmpeg I have to compile that too and I haven't yet figured out what I have to compile/link statically and what dynamically so everything works ...
[15:20:26 CET] <BBB> nevcairiel: and the intra prediction between vp8/vp9 is mostly identical, its in fact a todo item of mine, the issue is simply that vp9 has much bigger prediction sizes (up to 32x32 for intra), so h264pred would have to essentially be rewritten for it to work
[15:20:41 CET] <BBB> nevcairiel: also note that hevc/vp9 duplicate nearly identical code between their intra predictors
[15:21:01 CET] <BBB> I just dont feel like merging it all back together, so much work for so little gain :/
[15:21:09 CET] <wm4> BBB: let's say, calling it "h264pred" for a codec which claims to be completely independent from h264/mpeg could be considered an offense
[15:21:23 CET] <BBB> wm4: various people have told me that :)
[15:21:27 CET] <BBB> wm4: but its just a name
[15:21:35 CET] <BBB> it has no legal meaning
[15:21:54 CET] <BBB> if it really offends you, we can consider renaming it I suppose
[15:22:16 CET] <wm4> I still find it funny
[15:22:37 CET] <BBB> I think it shows how nearly-identical most dct-based codecs are
[15:22:57 CET] <BBB> but it doesnt mean vp8 is based on h264, or vice versa
[15:23:09 CET] <BBB> it just means all of them are veyr similar
[15:23:22 CET] <nevcairiel> But it could mean that there is a patent common to all those codecs
[15:26:49 CET] <BBB> regardless of whether it does exist, isnt there some agreement between mpegla and google to not sue re:vp8 and vp8++ (i.e. vp9)?
[15:32:13 CET] <J_Darnley> an3k: I don't really know what you're talking about but is there a problem when you statically link everything?
[15:34:34 CET] <kierank> Gramner: ping
[15:34:48 CET] <an3k> J_Darnley: not with ffmpeg but L-SMASH Works. However since you're asking and the current topic is VPx: when I configure libvpx with --disable-static latest ffmpeg from git complains about libvpx being too old (>= 0.9.1). Without --disable-static ffmpeg doesn't complain
[15:36:19 CET] <J_Darnley> Is configure/gcc/ld picking up an old system libvpx?
[15:37:06 CET] <J_Darnley> Shared libs tend to be preferred (by these tools)
[15:37:31 CET] <J_Darnley> Also what does config.log say about the failing test?
[15:37:36 CET] <an3k> no other libvpx installed
[15:37:56 CET] <J_Darnley> And I guess we should take this to #ffmpeg
[15:38:45 CET] <J_Darnley> ha ha I haven't been there since "FFmpeg 2.4.2" was in the topic
[15:38:54 CET] <an3k> sure. hehe
[15:46:51 CET] <atomnuker> the current git master of the linux kernel finally supports using ath9k as an RNG
[15:47:01 CET] <atomnuker> result: the blocking /dev/random never blocks now
[15:48:38 CET] <cone-990> ffmpeg 03Michael Niedermayer 07master:5e5f82a28737: swscale/yuv2rgb: Factor YUVRGB_TABLE_LUMA_HEADROOM out
[15:48:39 CET] <cone-990> ffmpeg 03Michael Niedermayer 07master:8f3a9a8c278a: swscale/yuv2rgb: Increase YUV2RGB table headroom
[15:48:40 CET] <cone-990> ffmpeg 03Michael Niedermayer 07master:cc538e9dbd14: swscale/utils: Detect and skip unneeded sws_setColorspaceDetails() calls
[15:54:03 CET] <BBB> did ganesh ever revert the patch I asked him to revert?
[15:55:14 CET] <J_Darnley> was that isfinite?
[15:55:46 CET] <J_Darnley> (I didn'tsee any reverts in cvslog)
[15:55:54 CET] <BBB> yes
[15:57:36 CET] <nevcairiel> dont think so
[16:03:24 CET] <durandal_1707> Revert war
[17:03:36 CET] <J_Darnley> Heh.  Trying to defend your GPL violations never looks good.
[17:04:15 CET] <J_Darnley> If you distribute a binary you must offer the source.  What's hard about that?
[17:07:01 CET] <atomnuker> michaelni: I have this incredibly naive function to write golomb: http://paste.debian.net/365845/
[17:07:21 CET] <atomnuker> I'm trying to remove the while loop but I've no idea how to do it efficiently
[17:09:46 CET] <michaelni> something with ff_log2(val) maybe a +- 1 somewhere
[17:29:07 CET] <BBB> I really dont know what to do with ganesh anymore
[17:29:10 CET] <BBB> ...
[17:29:12 CET] <BBB> I give up :(
[17:29:31 CET] <durandal_170> what happened?
[17:30:36 CET] <BBB> he commits a patch saying that I reviewed it (which I didnt), so I ask him to revert it so it can go through regular review and he refuses
[17:30:40 CET] <BBB> I dont know what to do anymore
[17:30:42 CET] <BBB> I give up
[17:32:21 CET] <durandal_170> I'm gonna revert it then
[17:32:42 CET] <BBB> I dont want a revert war
[17:32:49 CET] <BBB> thats not helping anyone :/
[17:37:18 CET] <michaelni> i think ganesh is a bit stressed because he will be away from internet or so IIRC i guess he wanted to get some work/patches done before 
[17:37:49 CET] Action: michaelni just guessing
[17:49:50 CET] <Daemon404> not sure why that is stressful
[17:58:32 CET] <Gramner> kierank: pong
[17:58:52 CET] <kierank> can you have a look at J_Darnley's v210 patch
[17:59:03 CET] <kierank> i.e does it look sane
[17:59:24 CET] <Gramner> sure
[18:43:39 CET] <durandal_1707> michaelni: what fftfilt could do beside what is in examples?
[18:51:50 CET] <nevcairiel> BBB: its been months and he still hasnt learned the basic netiquette of pushing, but noone wants to listen to me, soo.
[18:57:35 CET] <jamrial> if you're talking about ganesh, then everybody agrees with you
[19:26:19 CET] <BBB> nevcairiel: ok, I was wrong
[19:27:05 CET] <J_Darnley> Have you people seen the news today about a severe bug in openssh?
[19:27:10 CET] <J_Darnley> http://undeadly.org/cgi?action=article&sid=20160114142733
[19:27:54 CET] <nevcairiel> doesnt seem that serious
[19:28:05 CET] <nevcairiel> client only, needs malicious server
[19:29:09 CET] <J_Darnley> True.
[19:29:26 CET] <rcombs> and the server verification check happens before you can exploit it
[19:29:43 CET] <J_Darnley> You can also defend against leaks by using different priv. keys for different hosts.
[19:30:01 CET] <rcombs> or by turning off the roaming client code
[19:30:01 CET] <wm4> heh, it's always useless features that cause the security issues
[19:30:12 CET] <rcombs> (for this particular bug)
[19:30:18 CET] <wm4> "Server side was disabled/gutted for years already, but this aspect was surprisingly forgotten."
[19:30:33 CET] <J_Darnley> PuTTY is also claimed to be unaffected
[19:30:35 CET] Action: J_Darnley cheers
[19:30:37 CET] <rcombs> wm4: hey it probably would've been useful if it actually got significant deployment
[19:30:50 CET] <nevcairiel> putty is an entirely different client
[19:30:55 CET] <rcombs> but I guess everyone just uses mosh instead
[19:31:48 CET] <rcombs> and I guess mosh is just as "affected" since it uses OpenSSH at startup
[20:01:30 CET] <atomnuker> something odd just hit the mailing list
[20:02:35 CET] <Daemon404> atomnuker, shhh it;s SMPTE
[20:02:38 CET] <Daemon404> not BBC
[20:03:28 CET] <atomnuker> it's the allcodecs description
[20:03:36 CET] <atomnuker> which is ALWAYS correct
[20:03:49 CET] <Daemon404> lul
[20:03:58 CET] <atomnuker> VP-3 is *totally* not Theora
[20:04:08 CET] <wm4> does this belong into the category "awesome but useless"?
[20:04:33 CET] <Daemon404> people use it vc-2 in real life
[20:04:34 CET] <atomnuker> mhmaybe, it supports lossless though
[20:04:37 CET] <Daemon404> it is unfortunate
[20:04:59 CET] <atomnuker> it's almost always used with interlacing too -_-
[20:14:04 CET] <kierank> jrosser: patch on ML
[20:16:25 CET] <jrosser> i see
[20:16:32 CET] <jrosser> nice work :)
[20:17:49 CET] <jrosser> Systemd a typo?
[20:18:18 CET] <kierank> rofl
[20:18:40 CET] <jrosser> on so many levels :)
[20:19:03 CET] <kierank> atomnuker actually loves systemd
[20:19:31 CET] <durandal_1707> noooooo!!
[20:19:35 CET] <Daemon404> he can meet his idol at FOSDEM
[20:19:56 CET] Action: durandal_1707 crying
[20:21:52 CET] <kierank> Gramner: thanks
[20:23:30 CET] <kierank> 7:04 PM <"wm4> does this belong into the category "awesome but useless"? --> for you maybe
[20:24:56 CET] <wm4> so who uses it?
[20:25:01 CET] Action: kierank 
[20:25:25 CET] <durandal_1707> anime folks certainly not
[20:26:01 CET] <wm4> kierank: and what for?
[20:26:06 CET] <wm4> sorry if I'm being too curious
[20:26:14 CET] <kierank> compressing live videos and stuff
[20:26:48 CET] <durandal_1707> snow?
[20:26:52 CET] <kierank> the same reason people use jpeg2000
[20:27:16 CET] <Compn> same reason people use dirac? :P
[20:27:44 CET] <kierank> is it possible to have an avpacket use your own memory
[20:27:57 CET] <wm4> yes, same as with AVFrame
[20:29:03 CET] <wm4> "compressing live videos"
[20:29:14 CET] <wm4> and archiving them?
[20:29:20 CET] <jrosser> vc2 is in the same class as j2k and tico, and some of prores
[20:29:40 CET] <kierank> jrosser: i doubt anyone knows what tico is here
[20:29:57 CET] <jrosser> if you want a codec with only a few lines of latency and mild compression, its useful
[20:30:01 CET] <jrosser> otherwise not
[20:32:59 CET] <tmm1> ubitux: thanks
[20:47:31 CET] <gajjanag> @all: updated fclose business with more verbose/detailed info, https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/187154.html
[20:48:26 CET] <gajjanag> want to achieve some level of common understanding regarding it, so request for interested people to be on irc
[20:49:03 CET] <Compn> yo gajjanag , nice to see you here
[20:49:14 CET] <Compn> yes there are a few devs who have questions about patches 
[20:49:30 CET] <gajjanag> in particular, seems like BBB, michaelni, and wm4 have expressed opinions on it, so it would be helpful if all 3 are there
[20:49:42 CET] <gajjanag> @Compn: was here yesterday as well ;)
[20:49:45 CET] <Compn> ahhh :)
[20:50:09 CET] <Daemon404> my only opinion is: no gnulib
[20:50:19 CET] <Compn> no systemd
[20:50:25 CET] <Compn> no autotools
[20:50:26 CET] <Compn> :p
[20:50:35 CET] <gajjanag> @Daemon404,compn: definitely agreed :)
[20:56:10 CET] <cone-777> ffmpeg 03Paul B Mahol 07master:653f9d84ae83: avfilter: add spectrumsynth filter
[20:59:26 CET] <durandal_1707> gajjanag: what's point of is_finite hack?
[21:00:23 CET] <durandal_1707> @ is not part of nick it means nick is channel operator
[21:00:34 CET] <gajjanag> durandal_1707: just to simplify something michael pushed recently
[21:01:16 CET] <gajjanag> he had an isnan/isinf check
[21:02:03 CET] <gajjanag> btw, are .i64 of hann/hanning supposed to be identical (recently pushed)?
[21:05:38 CET] <durandal_1707> yes
[21:09:23 CET] <gajjanag> durandal_1707: nothing else I can find by code inspection, thanks
[22:02:20 CET] <ubitux> tmm1: is your github up-to-date?
[22:02:53 CET] <tmm1> yes, but i changed the branch name to upstream-cc
[22:03:11 CET] <ubitux> ok
[22:03:46 CET] <ubitux> tmm1: are you available for quick reviews?
[22:03:54 CET] <tmm1> yep
[22:04:05 CET] <ubitux> ok, give me sth like 5-10 minutes then
[22:04:15 CET] <ubitux> time to get a ff setup working again
[22:04:43 CET] <tmm1> sure
[22:05:21 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:7b6e6895f2cb: swscale: Move VScalerContext into vscale.c
[22:05:22 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:e06403331cec: swscale: Move Contexts used only in hscale.c into it
[22:05:23 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:8feeffc1d7ca: swscale/slice: Fix doc typo
[22:05:24 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:705a2f70ee14: swscale/slice: Fix indention
[22:05:25 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:fe6372bb614d: swscale/vscale: Add fixme comment to "ugly" code
[22:05:26 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:b99f49871679: swscale/output: Assert that yalpha and uvalpha are within their expected range
[22:05:27 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:eb7802afefb7: swscale/vscale: Check that 2 tap filters are bilinear before using bilinear code
[22:09:30 CET] <cone-777> ffmpeg 03Aman Gupta 07master:260e3687173b: lavc/ccaption_dec: flush context on seek
[22:12:41 CET] <ubitux> tmm1: the fate test introduced in the 3rd commit is not correct
[22:12:48 CET] <ubitux> it still includes this 999 thing
[22:13:03 CET] <ubitux> i'm going to fix it up, unless you have an objection
[22:13:19 CET] <ubitux> but if you can do it that would help
[22:17:31 CET] <tmm1> ah, i can fix that
[22:18:04 CET] <ubitux> thanks
[22:19:35 CET] <tmm1> hrm, i changed taht previous commit to use 10s as the duration
[22:19:45 CET] <tmm1> (i noticed that's what VLC does, and it makes a lot more sense than infinite)
[22:22:15 CET] <tmm1> oh i only changed one spot, i see
[22:25:15 CET] <tmm1> ubitux: pushed, fix that realtime commit and the following fate test
[22:28:04 CET] <ubitux> tmm1: well, 10sec is actually not that great
[22:28:46 CET] <ubitux> the thing is, with the incoming timing patch, you could get a negative duration reaches the final user
[22:29:02 CET] <ubitux> who could set it to whatever prefered timeout
[22:29:15 CET] <ubitux> while is 10s duration is actually very misleading
[22:29:19 CET] <ubitux> s/is/a/
[22:29:45 CET] <cone-777> ffmpeg 03Paul B Mahol 07master:2bbc7e9625f2: avfilter/vf_fftfilt: use the name 's' for the pointer to the private context
[22:29:46 CET] <cone-777> ffmpeg 03Paul B Mahol 07master:d6f1abe9ce08: avfilter/vf_fftfilt: this is video filter so use pixels instead of samples
[22:35:08 CET] <tmm1> ubitux: ok so you prefer -1 ?
[22:35:21 CET] <ubitux> yes
[22:36:05 CET] <ubitux> tmm1: what you can do though is adding an option to force a special timeout
[22:36:41 CET] <ubitux> not sure that's worth the effort but well
[22:36:57 CET] <ubitux> i might apply the timing patch this week end, if things go well
[22:39:19 CET] <tmm1> ubitux: pushed
[22:42:17 CET] <cone-777> ffmpeg 03Aman Gupta 07master:5c041e2cccc1: lavc/ccaption_dec: implement real_time option
[22:42:18 CET] <cone-777> ffmpeg 03Aman Gupta 07master:fdbe5cd5c523: fate: add test for realtime ccaption decoder
[22:45:19 CET] <ubitux> tmm1: what's this 0 value you're refering to in 'Row 10 was chosen as it corresponds to the value of "0" in a PAC'?
[22:45:27 CET] <ubitux> i see no 0 in row_map
[22:45:45 CET] <ubitux> (i don't get what this is really about)
[22:47:06 CET] <tmm1> ubitux: row_map[0] == 11
[22:47:45 CET] <tmm1> ubitux: basically it defaults the position of subs to near the bottom, in the case where you tune into a stream *after* a PAC which tells you where to place characters
[22:47:54 CET] <tmm1> if you're not planning on merging the positioning changes it doesn't matter
[22:48:12 CET] <tmm1> i should have put it later in the patchset
[22:48:36 CET] <tmm1> i can rearrange if you want, or you can skip that one for now
[22:49:02 CET] <ubitux> just trying to figure out the thing
[22:49:30 CET] <ubitux> about tab offset, is there something to do about the skipped ' ' in capture_screen()?
[22:50:40 CET] <ubitux> my other comments about the musical notes and positioning still hold btw
[22:50:49 CET] <tmm1> tab offset similarly doesn't matter without the positioning patch, since it will be skipped as you said
[22:50:58 CET] <ubitux> ok
[22:51:07 CET] <ubitux> do you mind if i postpone the review of these patch for this week end or so?
[22:51:17 CET] <tmm1> ubitux: yea that's fine, i mostly want the real time one merged
[22:51:17 CET] <ubitux> (i think the most urgent one was the real time thing?)
[22:51:20 CET] <ubitux> right
[22:51:22 CET] <ubitux> ok
[22:51:45 CET] <tmm1> the claer patch is useful too
[22:52:08 CET] <ubitux> is it reorderable?
[22:52:21 CET] <tmm1> yes it should be independent
[22:53:17 CET] <tmm1> i reordered and pushed
[22:53:20 CET] <ubitux> you have an unrelated change in this commit, and pointless (); can you fix those and move it as a first commit in your branch?
[22:53:51 CET] <tmm1> ok, separate whitespace commit?
[22:54:16 CET] <ubitux> yeah
[22:55:43 CET] <ubitux> but the file still has style mistakes all over, so you probably want to do them all at once
[22:55:51 CET] <tmm1> pushed
[22:56:00 CET] <tmm1> that's the only one i had changed in this patchset, if you see others i can include them in the first commit
[22:57:02 CET] <ubitux> the condition shouldn't be >=?
[22:57:26 CET] <ubitux> i mean it was originally "until i < ctx->cursor_row - keep_lines"
[22:57:36 CET] <ubitux> so i == ctx->cursor_row - keep_lines wasn't reached
[22:59:32 CET] <tmm1> yea i think that was incorrect, that line is supposed to be cleared as well
[23:00:24 CET] <ubitux> why not make a simpler loop?
[23:00:41 CET] <tmm1> how so
[23:01:50 CET] <tmm1> if keep_lines is 2, the cursor_row and the one above it should stay and everything else is cleared
[23:02:18 CET] <ubitux> like, for (i = ctx->cursor_row; i < ...
[23:02:45 CET] <ubitux> and UNSET_FLAG(.., i - ctx->cursor_row)
[23:03:01 CET] <ubitux> you would about crawling through all the entries before reaching the start
[23:03:05 CET] <ubitux> and all the entries after the end
[23:03:19 CET] <ubitux> and the loop might be more readable
[23:03:23 CET] <ubitux> no?
[23:03:34 CET] <ubitux> s/about/avoid/
[23:04:11 CET] <tmm1> doesn't seem as intuitive to me, i want to scan all rows and clear them unless they fall in the whitelisted range
[23:04:41 CET] <ubitux> oh my bad, ok i see
[23:04:55 CET] <ubitux> i had it the other way around in mind
[23:08:19 CET] <ubitux> tmm1: broken } or something
[23:08:54 CET] <tmm1> looking
[23:09:18 CET] <ubitux> maybe broken git.. the '}' looks present
[23:09:42 CET] <ubitux> ah you put it in the whitespace one
[23:10:02 CET] <tmm1> ah i see it
[23:10:07 CET] <tmm1> i was surprised when i rebased that without conflicts
[23:11:03 CET] <tmm1> pushed
[23:11:18 CET] <tmm1> ugh now the next one got messed up lol
[23:11:20 CET] <tmm1> good job git
[23:12:10 CET] <tmm1> ok fixed up
[23:13:58 CET] <cone-777> ffmpeg 03Aman Gupta 07master:9027806e3cf6: lavc/ccaption_dec: clean up whitespace
[23:13:59 CET] <cone-777> ffmpeg 03Aman Gupta 07master:3a0e5cfcee5b: lavc/ccaption_dec: clear all unused rows during rollup
[23:20:03 CET] <tmm1> ubitux: re: positioning, it works quite well for me. i've watched several hours of content from different feeds with it enabled
[23:20:08 CET] <tmm1> here are some examples https://www.dropbox.com/sh/oczgb8e8t3ggz18/AABeH2hVvRXWxNtYPjkYnM6la?dl=0
[23:21:16 CET] <ubitux> isn't it a bit too much on the left?
[23:21:39 CET] <ubitux> are we good on the font size?
[23:22:51 CET] <tmm1> yea i suppose it never gets all the way to the right, since PLAYRES is 4:3
[23:23:11 CET] <ubitux> https://www.youtube.com/watch?v=8TZLxPdC3hk  you might want to check this
[23:23:20 CET] <ubitux> with the sample i gave you last time
[23:23:30 CET] <ubitux> so you can see expected output
[23:24:02 CET] <tmm1> good idea i'll try that
[23:24:08 CET] <tmm1> i am seeing captions on the far right side too actually
[23:24:13 CET] <tmm1> so i guess libass is scaling the aspect as well
[23:24:31 CET] <tmm1> and many captions show up dead center, so pretty sure its correct
[23:24:42 CET] <ubitux> btw, one thing we can do too
[23:24:49 CET] <ubitux> is actually have a bitmap mode
[23:24:59 CET] <ubitux> we have cga fonts builtin ffmpeg
[23:25:08 CET] <ubitux> so creating a bitmap might be doable 
[23:25:13 CET] <tmm1> ah interesting, didn't know there were fonts available
[23:25:25 CET] <ubitux> that's what we often use in filters
[23:25:28 CET] <ubitux> to print text
[23:25:33 CET] <tmm1> tbh i didn't plan on spending so much time on closed captions, and now that its working i'm ready to move on
[23:25:40 CET] <tmm1> that's the main reason i'm hesitant to dive into character sets
[23:26:28 CET] <ubitux> try git grep 'avpriv_cga'
[23:26:30 CET] <ubitux> sure
[23:26:33 CET] <ubitux> okay
[23:26:48 CET] <ubitux> i think supporting the styles and positioning correctly is important though
[23:27:05 CET] <ubitux> that test case with the expected output on youtube could be a good check
[23:27:20 CET] <ubitux> since it's showing how tv are displaying them
[23:27:39 CET] <ubitux> it's using various charset, colors and positioning
[23:39:28 CET] <durandal_1707> michaelni: so no other examples for fftfilt?
[23:40:00 CET] <durandal_1707> I tried some and failed
[23:45:48 CET] <tmm1> ubitux: positioning looks equivalent, colors and charsets are obviously still missing
[23:49:13 CET] <michaelni> fftfilt=weight_Y='cos(X)'
[23:49:20 CET] <michaelni> but i dont know what to call it
[23:52:03 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:fc2588a1d6cb: swscale/vscale: Use matching sliceY/chrSliceY for luma/chroma
[23:52:04 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:80fd348bb7d9: avformat/rmdec: Check size in ivr_read_packet() before use
[23:52:05 CET] <cone-777> ffmpeg 03Michael Niedermayer 07master:c3a24006d552: avformat/rmdec: Fix Packet memleak at close()
[00:00:00 CET] --- Fri Jan 15 2016