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

[burek]

[00:01:38 CEST] <cone-616> ffmpeg 03Andreas Cadhalpun 07master:75fd5ce4c1c0: imc: use correct position for flcoeffs2 calculation
[00:30:18 CEST] <cone-616> ffmpeg 03Michael Niedermayer 07master:c06e55627444: avcodec/mpeg4videodec: Check P cbpy
[00:44:52 CEST] <cone-616> ffmpeg 03Andreas Cadhalpun 07master:1410eeb6ea6b: imc: Use correct position for flcoeffs2 calculation
[00:44:53 CEST] <cone-616> ffmpeg 03Michael Niedermayer 07master:235e903b6323: Merge commit '1410eeb6ea6bc5784e40032430afcdf54a79aedb'
[02:54:18 CEST] <BBB> is it possible to compile libavfilter and only compile a select set of filers?
[02:54:23 CEST] <BBB> filters*
[02:58:14 CEST] <J_Darnley> Is there not a --disable-filter option?
[02:58:21 CEST] <jamrial> BBB: --disable-filters --enable-filter=something
[02:58:27 CEST] <BBB> \o/
[02:58:39 CEST] <J_Darnley> or even that ^^
[02:59:03 CEST] <BBB> now only need to figure out how to use filters as push-one-get-one
[02:59:45 CEST] <J_Darnley> I wish you luck
[03:02:07 CEST] <BBB> that sounds so unhopeful
[03:02:51 CEST] <J_Darnley> Well after trying to understand how the system works I was not impressed
[03:05:10 CEST] <J_Darnley> as far as I could tell requests for frames come from the sink up to the source through the request_frame functions...
[03:05:20 CEST] <J_Darnley> until the source provides a frame which goes through the filter_frame functions to the sink...
[03:06:06 CEST] <J_Darnley> then the returns appear to go back down through the filter_frames to the source then back up through request_frames to the sink
[03:06:43 CEST] <J_Darnley> but at any one of these functions a filter could turn around and ask for more or just do more
[04:40:05 CEST] <cone-833> ffmpeg 03Ronald S. Bultje 07master:0303d43964cd: vf_psnr: add channel weighting based on chroma subsampling.
[10:42:23 CEST] <zer0byte_> hey
[10:42:33 CEST] <zer0byte_> someone here with el capitan beta 3?
[10:52:25 CEST] <zer0byte_> noone
[10:52:26 CEST] <zer0byte_> ??
[12:48:00 CEST] <cone-899> ffmpeg 03Dan Flett 07master:87f98a2b9d4c: fbdev: Support the RGB565 colour space.
[12:48:00 CEST] <cone-899> ffmpeg 03Michael Niedermayer 07master:e76c34d08c6f: Merge commit '87f98a2b9d4c7218ad82bb45347a53b65e5244f3'
[12:56:31 CEST] <cone-899> ffmpeg 03Ronald S. Bultje 07master:c381af77c5a9: vF_psnr: move set_meta() calls out of loop.
[12:59:29 CEST] <J_Darnley> Now where was I?  (Bloody distractions)
[13:11:21 CEST] <BBB> question for muxer experts here. why would this be necessary? https://github.com/rbultje/ffmpeg/commit/f718677b7bd49c3e8eb2ca9bc2ff4512b7d98e21
[13:11:26 CEST] <BBB> and does it even make sense?
[13:12:03 CEST] <BBB> (I think I simply created a webm file and then ffmpeg -i file.webm -codec:v copy file.ivf, and the duration was invalid)
[13:13:48 CEST] <BtbN> hm? It even says in the commit message why it's neccesary.
[13:15:03 CEST] <BBB> I wrote the commit message :-p
[13:15:22 CEST] <BBB> I dont understand _why_ its necessary, Id expect these fields to be valid after find_stream_info
[13:15:24 CEST] <BBB> (or so)
[13:15:34 CEST] <BtbN> There are many reasons why the duration might be unknown
[13:15:37 CEST] <BBB> although I guess these are muxer fields, not demuxer fields
[13:15:54 CEST] <BtbN> A live stream for example
[13:18:14 CEST] <BBB> ok lets send it to the list and see if people mind it
[13:22:48 CEST] <nevcairiel> yeah muxers dont know the duration beforehand
[13:22:57 CEST] <nevcairiel> it could be valid in the muxer context, but its usually not
[13:23:26 CEST] <nevcairiel> should probably put a if (seekable) check on top of that
[13:23:54 CEST] <wm4> or filters
[13:24:15 CEST] <wm4> or seeking
[13:24:51 CEST] <wm4> or simply inaccurate duration estimation in the demuxer (of which we have a lot)
[13:30:17 CEST] <BtbN> Also, isn't there SEEK_END?
[13:30:43 CEST] <BtbN> What even is ivf?
[13:31:05 CEST] <nevcairiel> a lightweight container for vp8/9
[13:32:02 CEST] <Compnn> couldnt stick it in flv eh
[13:50:21 CEST] <BtbN> i hate rtmp... why is video streaming so annoying.
[13:52:31 CEST] <JEEBsv> just wait until you get to dash.js and MPEG-DASH
[13:52:50 CEST] <JEEBsv> the lavf thing is generally good, but dash.js is one giant piece of lulz
[13:53:02 CEST] <BtbN> I already did, works without any issues so far.
[13:53:14 CEST] <BtbN> The problem is getting the stream to the machine intended as server
[13:53:18 CEST] <durandal_170> J_Darnley: how is asm going for removegrain?
[13:54:40 CEST] <Compn> rtmp is total crap.
[13:55:20 CEST] <Compn> we were hoping that hls/hds would obsolete it, but nope
[13:55:38 CEST] <BtbN> Well, DASH is on a good way
[13:55:43 CEST] <Compn> million mp4 files, pfft
[13:55:48 CEST] <JEEBsv> well it can be one
[13:56:02 CEST] <JEEBsv> it will just request parts of that file
[13:56:05 CEST] <BtbN> And HLS/DASH both don't help me, as the machine i'm streaming from is unable to act as server.
[13:56:19 CEST] <JEEBsv> can't you do NFS or something?
[13:56:36 CEST] <JEEBsv> so the output dir is shared between the server and the encoder
[13:56:41 CEST] <BtbN> I tried that, but it's on an unstable Wifi link, i need something that can do intelligent framedropping
[13:56:46 CEST] <JEEBsv> ok
[13:56:49 CEST] <Compn> BtbN : is it time for ffmpeg to nih their own stream protocol? :)
[13:57:23 CEST] <BtbN> rtmp is the only thing I know that can do on demand frame dropping
[14:01:43 CEST] <durandal_170> michaelni: can nb_threads be changed without recreating graph in lavfi? 
[14:44:55 CEST] <J_Darnley> durandal_170: I am just about to start selecting which ones are x86_64 only
[14:46:49 CEST] <J_Darnley> I got severly distracted by reporting a bug in mintty
[14:47:07 CEST] <cone-899> ffmpeg 03Ronald S. Bultje 07master:733c5d889b98: yuv4mpeg: add rough duration estimate and seeking.
[14:48:28 CEST] <michaelni> durandal_170, in principle that should be possible
[15:03:40 CEST] <cone-899> ffmpeg 03Michael Niedermayer 07master:9b8b804cfb37: avformat/yuv4mpegdec: Remove unused variables
[15:17:15 CEST] <J_Darnley> durandal_170: that's done and I pushed to gitlab
[15:17:46 CEST] <J_Darnley> I will squash the commits together and send a patch to the list
[15:42:05 CEST] <BBB> durandal_1707: lets say that I have two 8bit movies and I want to calculate the psnr in the yuv420p12
[15:42:11 CEST] <BBB> durandal_1707: how do I do that using the psnr filter?
[15:42:47 CEST] <BBB> like, what magic do I do to convert each movie to yuv420p12 before calling psnr filter
[15:46:13 CEST] <nevcairiel> swscale, but that isnt magic, rather evil sorcery
[15:47:13 CEST] <BBB> I know, but whats the magic ffmpeg cmdln invocation
[15:47:35 CEST] <J_Darnley> Are you looking for the filter called "format"?
[15:47:40 CEST] <BBB> its something like ffmpeg -i file1 -i file2 -lavfi MAGIC HERE;[0:v][1:v]psnr -f null -
[15:47:44 CEST] <BBB> what is MAGIC HERE
[15:47:52 CEST] <BBB> I suppose I need multiple magics since its multiple streams
[15:48:26 CEST] <J_Darnley> try to apply format=yuv420p12 to each on the input streams
[15:49:08 CEST] <J_Darnley> *each of the input streams
[15:55:53 CEST] <durandal_1707> [0:v]format=...[first],[1:v]format=...[second],[first][second]psnr...
[16:03:30 CEST] <BBB> durandal_1707: ty!
[16:03:35 CEST] <BBB> (see, I told you its magic)
[16:17:08 CEST] <BBB> there, some simd for vf_psnr
[16:18:15 CEST] <BBB> I should write some for ssim also, then at least theres a real practical reason to move from tiny_ssim to lavfi
[16:29:53 CEST] <durandal_1707> BBB: asm is under gpl? You copied license from interlace filter...
[16:33:14 CEST] <J_Darnley> durandal_1707: you want the removegrain asm to be LGPL, right?
[16:34:23 CEST] <durandal_1707> Is it gpl so you can sold it to be lgpl?
[16:35:01 CEST] <durandal_1707> whatever you prefer.....
[16:35:46 CEST] <durandal_1707> update license file too in top directory
[16:35:56 CEST] <J_Darnley> I mean I prefer GPL but I only wrote it because you asked (and I was bored with everything else)
[16:37:08 CEST] <nevcairiel> just make it the same as the main filter and be done with it =p
[16:37:17 CEST] <J_Darnley> I also assumed it was from a GPL source
[16:38:41 CEST] <durandal_1707> it is from fuck license, maybe we should stick with it. But people may not like that word
[16:38:55 CEST] <durandal_1707> :)
[16:39:41 CEST] <J_Darnley> You can say it comes from rgtools which is MIT licensed (if you don't want to say the f-word)
[16:39:48 CEST] <J_Darnley> :)
[16:41:31 CEST] <durandal_1707> just do whatever you prefer
[16:43:19 CEST] <nevcairiel> having optimizations on a stricter license than the code that would use them always gives me bad feelings, so I would go for LGPL in this case, but in the end its still your choice.
[16:44:33 CEST] <kurosu> J_Darnley, you always declare the stack size as 0, but you can just skip declaring it if it is 0
[16:44:54 CEST] <J_Darnley> Even if I have argument names following it?
[16:44:59 CEST] <nevcairiel> yes
[16:45:00 CEST] <kurosu> yes
[16:45:04 CEST] <kurosu> at least cglobal rg_fl_mode_20 look like it could use fewer xmms regs (by reusing some)
[16:45:04 CEST] <J_Darnley> ah
[16:45:16 CEST] <kurosu> but overall, really nothing of importance
[16:46:36 CEST] <kurosu> classical question for some of those filters is "does ssse3 help here", for instance when you do unpack + paddw, some could use pmaddusbw with 1, 1
[16:46:59 CEST] <kurosu> I don't really think so, though, because you still need an unpack anyway
[16:47:25 CEST] <kurosu> though I remember putting that to use for some mpeg2 half pel interpolation
[16:47:27 CEST] <BBB> durandal_1707: oops, its lgpl ofcourse
[16:48:07 CEST] <durandal_1707> BBB: what is speedup?
[16:48:33 CEST] <BBB> dunno
[16:48:45 CEST] <BBB> Im guessing its faster
[16:50:49 CEST] <BBB> there, new version with lgpl header
[16:50:51 CEST] <BBB> sorry about that
[16:51:07 CEST] <BBB> and yes please do try to make all code lgpl, I always feel sad whenever we have new code thats gpl
[16:51:32 CEST] <BBB> (its obviously the choice of whoever writes the code)
[16:52:01 CEST] <BBB> I coped the license header from vf_interlace, so I guess thats gpl then?
[16:52:03 CEST] <BBB> (why?)
[16:52:58 CEST] <J_Darnley> I assume it is the same reason as other filters are/were GPL, the source they came from is GPL, like yadif was.
[16:55:07 CEST] <durandal_1707> BBB: trivial code from mplayer era
[16:55:27 CEST] <kurosu> J_Darnley, doing lgpl helps not bothering with the makefile/configure part, and it doesn't make much difference to the worst infringers
[16:56:37 CEST] <kurosu> on the other hand, so many users are used to freeload that what happened to yadif is actually something nice
[16:56:56 CEST] <durandal_1707> I have joinfields sitting there somewhere...
[16:58:14 CEST] <BBB> 53097 -> 27826 decicycles
[16:58:19 CEST] <BBB> so about 2x speedup
[16:58:55 CEST] <BBB> thats for the sse portion only, 1920x1080 video
[16:59:53 CEST] <kurosu> probably much larger on 32bits
[16:59:53 CEST] <BBB> oh thats for the 16bpp version
[17:00:44 CEST] <BBB> 27346 -> 21236 decicycles
[17:00:47 CEST] <BBB> thats not very much, odd...
[17:01:44 CEST] <BBB> anyway
[17:01:47 CEST] <BBB> there you go, speedup
[17:03:12 CEST] <BtbN> How do you measure that? I still have to int-math/optimize my colorkey filter.
[17:03:54 CEST] <durandal_1707> hmm but it still use floats...
[17:03:55 CEST] <kurosu> {START_TIMER / STOP_TIMER("my_function")}
[17:04:14 CEST] <J_Darnley> Don't forget to #include "timer.h"
[17:04:37 CEST] <BtbN> yes, the int-math conversion is still flawed. I think it overflows with certain color combinations, but i haven't found time to investigate yet.
[17:15:05 CEST] <BBB> durandal_1707: about the ssim filter, what is s->coefs[]?
[17:15:27 CEST] <BBB> its very odd that you would give uv equal weighting regardless of subsampling
[17:15:38 CEST] <BBB> durandal_1707: did you mean to maybe weight it by subsampling instead of by colorspace?
[17:20:25 CEST] <durandal_1707> indeed you are correct, ignoring subsampling is wrong
[17:20:33 CEST] <BBB> Ill fix some things, Im working on it anyway
[17:21:16 CEST] <durandal_1707> adding >8 bit is messy
[17:21:43 CEST] <BBB> gI wasnt going to
[17:21:45 CEST] <BBB> -g
[17:21:47 CEST] <BBB> I wasnt going to
[17:23:23 CEST] <zer0byte_> someone
[17:23:23 CEST] <zer0byte_> ?
[17:24:09 CEST] <zer0byte_> someone get this ierror during playing with ffmpeg
[17:24:11 CEST] <zer0byte_> WARNING:  140: This application, or a library it uses, is using the deprecated Carbon Component Manager for hosting Audio Units. Support for this will be removed in a future release. Also, this makes the host incompatible with version 3 audio units. Please transition to the API's in AudioComponent.h.
[17:24:22 CEST] <zer0byte_> with el capitan beta 3
[17:24:53 CEST] <BBB> zer0byte_: I guess apple introduced a new audio api and our code doesnt use it yet. ignore the warning, it works for now
[17:37:15 CEST] <durandal_1707> is someone going to benchmark/test my slice thread patches for lut and stereo3d filter?
[18:23:05 CEST] <J_Darnley> durandal_1707: I'll have a go at the lut filter.
[18:23:51 CEST] <J_Darnley> Is there any particular filter command you want me to use?  Otherwise I'll look at a fate test or the docs.
[18:24:27 CEST] <durandal_1707> simple negate should do it
[18:25:13 CEST] <durandal_1707> I wondering how much this filter would benefit from simd
[18:26:23 CEST] <J_Darnley> I don't think LUTs lend themselves to SIMD
[18:26:44 CEST] <J_Darnley> I guess you could detect some specific cases and use SIMD for those.
[18:26:57 CEST] <J_Darnley> ... like negation
[18:29:51 CEST] <BBB> I think altivec has lut simd
[18:29:54 CEST] <BBB> or something like that
[18:39:14 CEST] <jamrial> J_Darnley: regarding the marco changes i mentioned in my review: http://pastebin.com/2j8KyZfV http://pastebin.com/RDXqgE6V
[18:53:53 CEST] <cone-029> ffmpeg 03Ronald S. Bultje 07master:9879421f1ac1: vf_psnr: always calculate MSE over full pixel range.
[18:55:21 CEST] <J_Darnley> jamrial: noted
[18:57:21 CEST] <kurosu> also avx syntax? mova a, b / op a, c => op a, b, c
[19:04:35 CEST] <J_Darnley> yes, I plan to add avx2 but more is needed than just 3-arg instructions
[19:08:03 CEST] <J_Darnley> OMFG!  Thanks null muxer!  I really care that I have "non monotonically increasing dts"
[19:10:47 CEST] <nevcairiel> didnt someone send a patch to disable timestamps for the null muxer
[19:13:52 CEST] <BtbN> i still have this amazing webcam that gives me 100% random timestamps...
[19:14:17 CEST] <BtbN> Also causes a whole lot of log-panic
[19:14:44 CEST] <cone-029> ffmpeg 03Ronald S. Bultje 07master:3bb58c377b45: vf_psnr: fix rgb channel order mixup in final log message.
[19:18:33 CEST] <J_Darnley> All I tried to do was use the concat demuxer to concat my short y4m test file to give me more frames.
[19:55:51 CEST] <J_Darnley> Ah yes!  I forgot I had the tallship clip
[20:13:08 CEST] <J_Darnley> Well, I think those test results are rubbish.  2, 3, and 4 threads all appear to be the same speed
[20:18:52 CEST] <durandal_1707> J_Darnley: how you run it?
[20:38:38 CEST] <J_Darnley> ffmpeg -i ... -threads N -vf ... -f null /dev/null
[20:44:20 CEST] <durandal_1707> and how each takes time?
[20:44:34 CEST] <J_Darnley> START_TIME
[20:44:39 CEST] <J_Darnley> START_TIMER
[20:44:45 CEST] <J_Darnley> STOP_TIMER
[20:45:01 CEST] <durandal_1707> use simple time
[20:45:19 CEST] <durandal_1707> instructions do not change
[20:45:50 CEST] <durandal_1707> time ffmpeg ....
[20:46:10 CEST] <J_Darnley> I'm trying to not measure the time it takes decoding or reading from disk
[20:47:26 CEST] <durandal_1707> you can't so repeat it 4 times in a row and take minimal result
[20:54:28 CEST] <kurosu> Or under linux, use perf, running something like perf stat -r <times> <command>
[20:55:08 CEST] <J_Darnley> Does that do the math for you?
[20:55:44 CEST] <kurosu> yes
[20:55:49 CEST] <kurosu> https://perf.wiki.kernel.org/index.php/Tutorial#Repeated_measurement <- example
[20:55:49 CEST] <J_Darnley> sold
[20:56:22 CEST] <kurosu> perf is also useful to find source-level hotspots
[20:57:15 CEST] <kurosu> need perf record <command> then perf report, possibly with the right options to use several perf data files
[21:33:41 CEST] <cone-029> ffmpeg 03Paul B Mahol 07master:36669742301f: avformat/yuv4mpegdec: remove unused variable
[21:35:29 CEST] <cone-029> ffmpeg 03Paul B Mahol 07master:9ea81fe95e63: fate: add tests for w3fdif filter
[21:42:10 CEST] <durandal_1707> ah looks like there is lut instruction for avx called vgatherdps
[21:46:37 CEST] <jamrial> there's gather and scatter, and i remember reading ithey are pretty slow
[21:49:32 CEST] <J_Darnley> That might not be so useful for 8 bit samples
[21:49:44 CEST] <J_Darnley> > VGATHERDPS/VGATHERQPS  Gather Packed SP FP values Using Signed Dword/Qword Indices 
[23:39:37 CEST] <durandal_1707> my CPU have sse2 but it is not enabled. Why?
[23:40:14 CEST] <J_Darnley> Someone disabled it int he BIOS?
[23:42:05 CEST] <BtbN> Is that even possible?
[23:42:27 CEST] <J_Darnley> I have seen it in some.  I've never tried it though.
[23:44:41 CEST] <cone-029> ffmpeg 03Michael Niedermayer 07master:bc976e579300: avcodec/utils: Fix potential overflow in overallocation code
[23:44:42 CEST] <cone-029> ffmpeg 03Michael Niedermayer 07master:b3415e4c5f92: avutil/mem: Fix potential overflow in overallocation code
[23:44:43 CEST] <cone-029> ffmpeg 03Michael Niedermayer 07master:59a07df06731: avcodec/utils: Avoid undefined void casts in ff_fast_malloc()
[23:44:44 CEST] <cone-029> ffmpeg 03Michael Niedermayer 07master:f8db81074a96: avcodec/utils: Assert that the pointer is set when size is in ff_fast_malloc()
[23:49:54 CEST] <nevcairiel> maybe its one of those with sse2slow
[23:52:12 CEST] <J_Darnley> (it's not very new then)
[23:52:30 CEST] <J_Darnley> When you say "not enabled" what do you mean?  You get an illegal instruction error?  Your OS doesn't report sse2?  Some other tool doesn't report sse2?
[23:59:04 CEST] <durandal_1707> J_Darnley: CPU celeron m, perhaps with crappy sse2
[23:59:57 CEST] <durandal_1707> its still alive at least
[00:00:00 CEST] --- Sun Jul 12 2015