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

[burek]

[00:44] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:bf8bcd3b2b51: avdevice/openal-dec: Check the return code of av_new_packet()
[03:21] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:a582705d1540: ffmpeg: Favor filter graph based duration over ost->frame_rate in fps code
[03:47] <ac_slater> hey all, this might be a question for the other channel. Anyways, without looking to much into the 'plugin' system ffmpeg has in place, would it be possible to register plugins at runtime? ie - I want to create some demuxers/decoders but I'm not sure if I *HAVE* to compile them in
[03:47] <ac_slater> thanks
[04:00] <cone-798> ffmpeg.git 03Michael Niedermayer 07master:90c98994f68b: ffmpeg: Reduce noisiness of frame clipping in rate convertion
[04:02] <compn> ac_slater : theres a rfc on the devel list asking about creating such a feature
[04:02] <compn> with a intro patch posted there
[04:02] <compn> you may want to look at it
[04:02] <ac_slater> compn: interesting, thanks mate
[04:03] <compn> i think the thread title is dynamically loading something or other
[04:03] <compn> should find it easily
[04:14] <ac_slater> compn: thanks again mate. 
[08:11] <jamrial> nevcairiel: https://github.com/jamrial/FFmpeg/commits/hevc_intr
[11:31] <k_sze> How does the DirectShow support in ffmpeg work? Does it just use a SampleGrabber to grab samples from a source filter and feed it to the encoder?
[11:34] <ramiro> k_sze: did you take a look at the source code?
[11:36] <ramiro> k_sze: it implements a custom grabber filter and uses that to output frames through libavdevice
[11:57] <k_sze> ah, you wrote it.
[11:57] <k_sze> so it doesn't implement ISampleGrabber at all.
[12:02] <ramiro> k_sze: exactly
[12:03] <k_sze> libAVFilter, right?
[12:04] <k_sze> It's ... a struct. o.O funky
[12:07] <ramiro> it's in C but it has to work like a C++ class
[12:07] <k_sze> oh, right
[12:07] <k_sze> I forgot it's C.
[12:17] <k_sze> thanks for the tips. I'll be back later.
[12:34] <wm4> I get a huge memory leak when seeking (probably when resetting the h264 decoder), does anyone observe the same?
[12:34] <wm4> I get it with my own player, but also with ffplay
[12:35] <wm4> (in ffplay, keep the mouse button down, and move the mouse between left and right window a few times)
[12:38] <wm4> it happens with the ffmpeg from now, and also from a week ago
[12:43] <nevcairiel> wm4: seems fine here
[12:44] <wm4> time to bisect
[12:44] <nevcairiel> define "huge"
[12:45] <nevcairiel> memory usage seems stable here anyway seeking a stream
[12:45] <wm4> quickly goes into the gigabytes
[12:47] <nevcairiel> seems fine here in any case, so maybe something OS specific? but that would be odd
[12:48] <nevcairiel> of course i tried with my own code
[12:48] Action: nevcairiel grabs some ffplay
[12:49] <wm4> only tried on Linux
[12:50] <nevcairiel> can reproduce with ffplay, so i must be doing something "right" in my code. ;)
[12:51] <wm4> do you reset the decoder with avcodec_flush (or whatever it was)?
[12:56] <nevcairiel> of course
[13:22] <wm4> and of course this whole merge bullshit makes bisecting very hard
[13:23] <nevcairiel> using the ffbisect thing actually worked ok for me
[13:23] <wm4> what was ffbisect again?
[13:24] <nevcairiel> it automatically skips points on the libav branch, so you dont end up having to switch to avplay for testing
[13:24] <nevcairiel> instead you'll end up on the merge that merged said commit from libav (if the libav change was faulty)
[13:56] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:723c37d3b7b5: avfilter/vf_idet: reduce noisyness if the filter has been auto inserted
[13:56] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:56a33b232cbb: avfilter/vf_idet: flush internal buffers on parameter changes
[13:56] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:6c702c3c6314: avfilter/avfilter: allow idet like scale to have parameter changes
[13:59] <ubitux> michaelni: is it really wise to insert an idet filter everytime we have a yuv420p output?
[14:00] <ubitux> it doesn't sound like a good idea to me, unless it's really a no-op for progressive content?
[14:00] <ubitux> i'm afraid of various slowdowns with complex filtergraph graph
[14:01] <ubitux> it's probably a better idea to let users insert it themselves, but well..
[14:03] <michaelni> it should be a no-op for progressive content but if someone finds a slowdown with progressive i would be very interrested
[14:04] <michaelni> the problem with letting the user do it is that the user #1 doesnt know she shoule do that and #2 doesnt know that some scale was auto inserted and needed an idet
[14:05] <michaelni> also note idet is not auto inserted yet, the patch is still on the ML
[14:43] <arwa> I am getting errors while using rsync : rsync: failed to connect to fate-suite.ffmpeg.org (192.190.173.45): Connection refused (111).
[14:43] <arwa> I think this maybe because of the proxy settings.
[14:44] <arwa> I tried out a lot of things to bypass the proxy, but I am unable to do so.
[15:02] <wm4> kierank is going to get a stroke from all those nicolas posts
[15:22] <kierank> wm4: i saw a wall of text and ignored
[17:15] <wm4> man this thing sure took a while to find
[17:15] <nevcairiel> i still wonder why mine didnt leak
[17:16] <wm4> I'm wondering how the other frames are unreffed, but I'm too scared to ask
[17:16] <wm4> nevcairiel: a single seek is still minor
[17:16] <nevcairiel> i seeked a lot
[17:16] <wm4> hm
[17:17] <wm4> maybe it has to do with whether there are still frames in flight?
[17:17] <iive> threading?
[17:17] <wm4> part of why it took me so long was: memcpy(h, h1, offsetof(H264Context, intra_pcm_ptr));
[17:17] <wm4> truly evil
[17:18] <wm4> this copies a big load of stuff from one context to another, including all refs
[17:18] <wm4> maybe I didn't fix it properly
[17:28] <nevcairiel> i shall remember to check for applied h264 patches soon then and make sure  they are applied
[17:30] <nevcairiel> (the second applied to my own version, i mean)
[18:43] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:438c0a665af3: avcodec/xan: Use av_realloc_array()
[18:43] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:f9a5a89bbfde: avcodec/xsubdec: Check av_mallocz() return codes
[19:39] <kurosu> I have recently tried msys2, seeing how some people here seem to use it
[19:40] <kurosu> the OS is identified as msys_nt61, causing a configure failure: incorrect installation?
[19:41] <Daemon404> did you use the installer from msys2.github.io?
[19:41] <kurosu> I think so
[19:41] <Daemon404> (thats what i used)
[19:41] <Daemon404> actually i was just going to send a patch to change msys links to msys2 links
[19:43] <kurosu> it's on a computer I can't access atm, though, so what I'm writing isn't 100% sure
[19:44] <Daemon404> ok
[19:45] <kurosu> that was the 20141113 version though
[19:45] <jamrial> kurosu: try --target-os=mingw32
[19:46] <kurosu> jamrial, will do that, thanks
[19:47] <jamrial> also, assuming you're using their mingw toolchains, you should use mingw64_shell.bat or mingw32_shell.bat to start the environment
[19:47] <jamrial> that way uname -s will output MINGW64_NT-6.1 or MINGW32_NT-6.1 respectively
[19:48] <kurosu> oh right, I did run the msys shell
[19:48] <jamrial> yeah
[19:48] <kurosu> what's the toolchain to install then? the mingw64 one and not the msys one ?
[19:48] <Daemon404> you want the mingw-w64 one
[19:48] <jamrial> they also change the PATH enviroment var, to add either /mingw64 or /mingw32
[19:49] <kurosu> ok, I didn't make sure if the mingw-w64 was prefixed yet
[19:49] <jamrial> Yeah, "pacman -S -l | grep mingw64" will show you all the mingw64 packages, for example
[19:49] <kurosu> (hence the failure to detect initially)
[19:50] <kurosu> well, actually, the fewer packages installed and picked up by ffmpeg, the shorter the compilation and link times, so I don't expect to install a lot of libs :D
[19:50] <kurosu> thanks
[19:51] <Daemon404> although i dislike pacman, it is roughly 1000x better than mingw-get ever was
[19:52] <jamrial> check "pacman -S mingw-w64-x86_64-ffmpeg". it will try to install like 40 dependencies :p
[19:52] <kurosu> I only work on ffmpeg as a hobby, so I tend to avoid such distractions as updates
[19:53] <Daemon404> nobody sane uses a packaged ffmpeg
[19:54] <kurosu> (and thus I only ran mingw-get on install)
[19:57] <wm4> I use mxe-packaged ffmpeg sometimes
[20:00] <jamrial> configure needs to be fixed anyway. if you use the mingw64 shell from msys2, uname -s will output mingw64 and configure only checks for "mingw32"
[20:01] <kurosu> btw, does the package mingw-w64 toolchain accepts -m32, so as to be able to build both 64b and 32b versions of ffmpeg?
[20:02] <kurosu> *packaged
[20:03] <jamrial> i don't think so, but i haven't tried
[20:03] <jamrial> they offer the x86 toolchain separately after all
[20:06] <jamrial> you have both mingw-w64-x86_64-gcc and mingw-w64-i686-gcc
[20:06] <kurosu> :/
[20:10] <kurosu> jamrial, do you know the package name for bc ?
[20:10] <kurosu> might also be useful for the doc patch from Daemon404
[20:12] <jamrial> no, i couldn't find it in any package, so i had to download it from http://gnuwin32.sourceforge.net/packages/bc.htm
[20:13] <jamrial> i assume they offer it. i just didn't bother much searching for it :p
[20:15] <Daemon404> kurosu, i thouht about that too
[20:20] <cone-871> ffmpeg.git 03wm4 07master:e0e33ebe6bd7: h264: unref leaking error recovery picture
[20:22] <wm4> so apparently the fix was correct enough
[20:24] <nevcairiel> apparently
[20:39] <cone-871> ffmpeg.git 03Michael Niedermayer 07master:5c1a8d3b7d33: avfilter/vf_idet: factorize av_frame_free(&idet->prev)
[21:16] <aetasx> any of you guys know why when encoding to libfdk_aac, it widens mono to stereo output so that there's 2 channels duplicating the original?
[22:17] <kurosu> Daemon404/jamrial, I don't think bc is packaged: pkgfile.exe -r ".*bc\.exe" returns nothing valid
[22:18] <nevcairiel> bc is something thats missing often :d
[22:18] <ubitux> bc is in the... bc package on archlinux
[22:19] <ubitux> (where that pacman comes from)
[22:19] <Daemon404> bc is one of those gnu projects with no real upstream iirc
[22:19] <Daemon404> and no vcs at all
[22:19] <ubitux> we should probably try to exec a zsh or something if bc is not found
[22:19] <kurosu> I'll be waiting for ffbc then
[22:19] <ubitux> (zsh supports the float arithmetic which we use bc for)
[22:20] <ubitux> kurosu: actually... we have ffeval
[22:20] <ubitux> that might work..
[22:20] <wm4> what's bc used for?
[22:20] <Daemon404> float arith
[22:20] <Daemon404> some sort of metric
[22:20] <ubitux> tests/fate-run.sh:    echo "scale=2; v = $1 - $2; if (v < 0) v = -v; if (v > $3) r = 1; r" | bc
[22:20] <ubitux> just here.
[22:20] <Daemon404> i thought t was elsewhere
[22:28] <ubitux> actually i don't get that bc like
[22:29] <ubitux> oh r is the exit value maybe
[22:29] <ubitux> seems not
[22:29] <nevcairiel> bc is just weird, deal with it! :D
[22:29] <ubitux> so it's simply a abs($1-$2)>$3?1:0
[22:31] <ubitux> so something like echo "gt(abs($1-$2),$3)" | run tools/ffeval might actually do the trick?
[22:34] <ubitux> i should have read the comment above
[22:38] <ubitux> -    echo "scale=2; v = $1 - $2; if (v < 0) v = -v; if (v > $3) r = 1; r" | bc
[22:38] <ubitux> +    [ "$(echo "gt(abs($1-$2),$3)" | ./tools/ffeval)" == "=> 1.000000" ] && echo 1 || echo 0
[22:38] <ubitux> seems to do the trick :p
[22:38] <ubitux> (yes that's a bit ugly but well)
[22:41] <ubitux> ah, got a better one :)
[22:44] <ubitux> dammit bash
[22:44] <ubitux> -    echo "scale=2; v = $1 - $2; if (v < 0) v = -v; if (v > $3) r = 1; r" | bc
[22:44] <ubitux> +    printf "%d\n" $(echo "gt(abs($1-$2),$3)" | ./tools/ffeval -p '')
[22:44] <ubitux> this doesn't work with the printf implementation of printf
[22:45] <ubitux> $ printf "%d\n" "1.0"
[22:45] <ubitux> bash: printf: 1.0: invalid number
[22:45] <ubitux> :(
[22:45] <Daemon404> because its a float
[22:45] <ubitux> i know, but i'm not trying to do bash arithmetic here
[22:46] <nevcairiel> what kind of printf do you have, seems to work here
[22:46] <ubitux> bash builtin
[22:46] <ubitux> it works fine with zsh
[22:47] <ubitux> it warns but it works though..
[22:47] <ubitux> [ux at en ~]$ printf "%d\n" "0.0000" 2>/dev/null
[22:47] <ubitux> 0
[22:47] <ubitux> [ux at en ~]$ printf "%d\n" "1.0000" 2>/dev/null
[22:47] <ubitux> 1
[22:47] <ubitux> now how portable is that?
[22:47] <nevcairiel> not very?
[22:47] <nevcairiel> :D
[22:47] <ubitux> :(
[22:47] <ubitux> dammit
[22:47] <nevcairiel> i dont know
[22:48] <nevcairiel> why are you fighting bc anyway
[22:48] <nevcairiel> its been a dep for ever
[22:48] <ubitux> because it's not in the base system :p
[22:48] <ubitux> yeah but it's a stupid one
[22:48] <Daemon404> neither is rsync
[22:48] <Daemon404> who cares
[22:48] <nevcairiel> nor is git, or yasm, or gcc (on most base systems)
[22:49] <nevcairiel> probably not even make
[22:49] <nevcairiel> i should go sleep, 11pm is no time to be fighting 20 year old automation interfaces
[22:49] <ubitux> maybe i can just use awk
[22:50] <ubitux> since we use it in other places
[22:50] <aetasx> you guys have any clue about the libfdk question I asked a bit ago?
[22:53] <ubitux> -    echo "scale=2; v = $1 - $2; if (v < 0) v = -v; if (v > $3) r = 1; r" | bc
[22:53] <ubitux> +    awk "BEGIN { v=$1-$2; printf \"%d\\n\", ((v<0?v:-v) > $3) ? 1 : 0 }"
[22:53] <ubitux> this works \o/
[22:54] <aetasx> what the hell is that?
[22:54] <nevcairiel> shell magic
[22:55] <aetasx> yeah I got that, for what
[22:55] <ubitux> doing a check of abs(a-b)>c
[22:55] <ubitux> with a, b and c floats
[23:03] <aetasx> isnt there a bc for that?
[23:04] <nevcairiel> he wants to get rid of bc
[23:04] <nevcairiel> thats the entire point of this endavour :D
[23:04] <aetasx> ah, missed that part
[23:20] <aetasx> do people still use acovea?  looks like their website is long since gone
[00:00] --- Tue Jan 20 2015