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

[burek]

[00:00:54 CET] <durandal_1707> how much it would take for you * 10
[00:05:56 CET] <rcombs> wm4: probably not; most of the work is already done
[00:14:15 CET] <nevcairiel> jamrial_: i dont think vlc 2.2 works with ffmpeg 3.0 either way due to API issues
[00:14:20 CET] <T4ng10r> can someone help me? how to debug internals of libavformat?
[00:14:52 CET] <nevcairiel> jamrial_: ie. it refuses to work with avutil > 55 already before that change
[00:15:17 CET] <durandal_1707> T4ng10r: what exactly?
[00:15:32 CET] <rcombs> wm4: basically I just need to add something to send a "extradata changed" packet side-data when that happens
[00:15:36 CET] <nevcairiel> jamrial_: sorry, >= 55
[00:15:56 CET] <rcombs> and if the decoders don't handle that, well, sucks
[00:16:02 CET] <T4ng10r> I would like to see what is goin on in eval_function and func_pts
[00:16:23 CET] <T4ng10r> i start with cgdb ffmpeg from inside ffmpeg folder where I run configure and make
[00:16:30 CET] <T4ng10r> but no symbols were loaded
[00:16:53 CET] <durandal_1707> stripped binary?
[00:16:57 CET] <drv> use ffmpeg_g
[00:17:34 CET] <T4ng10r> objdump --debuging on libavformat.a shows that symbols are available
[00:18:06 CET] <T4ng10r> @drv: wow - that it
[00:18:12 CET] <T4ng10r> thank you
[00:24:07 CET] <T4ng10r> wrr, still not satisfayin results
[00:24:29 CET] <T4ng10r> ffmpeg_g runs, but no breakpoint set in vf_drawtext.c is triggered
[00:24:51 CET] <T4ng10r> even when I go manualy to this file and set breakpoint
[00:29:21 CET] <T4ng10r> doeasn't matter if I run from ffmpeg_g or ffmpeg - in both situations breakpoints on vf_drawtext arent triggered
[00:29:24 CET] <T4ng10r> Linux, cgdb
[00:29:47 CET] <JEEB> check if the libraries have debug symbols
[00:29:56 CET] <JEEB> they should, but just in case
[00:30:43 CET] <T4ng10r> objdum --debugiing libavformat.a show that they are
[00:31:33 CET] <T4ng10r> how do you debug on linux?
[00:31:43 CET] <T4ng10r> maybe my approach is faulty
[00:32:49 CET] <JEEB> I just use standard gdb and then the binary name
[00:32:50 CET] <T4ng10r> or perhapse cgdb ffmpeg uses system libraries without debug symbols
[00:33:02 CET] <T4ng10r> and from where are you doing it?
[00:33:03 CET] <JEEB> and yes, if you have an ffmpeg in path
[00:33:15 CET] <JEEB> you will probably want to do gdb ./ffmpeg_g or so
[00:33:24 CET] <JEEB> it should tell if it loaded symbols or not
[00:34:07 CET] <T4ng10r> i'll try
[00:34:08 CET] <jkqxz> "gdb --args ./ffmpeg_g -foo -bar -ffmpeg -args", "break function_name", "run".
[00:34:41 CET] <JEEB> I usually just "gdb binary" and then "run parameters more of them" when inside
[00:34:42 CET] <T4ng10r> still nothign
[00:34:52 CET] <JEEB> so it says it couldn't load symbols?
[00:35:10 CET] <T4ng10r> cgdb -x debug_cmd ffmpeg_g
[00:35:11 CET] <JEEB> also please enlighten me what is cgdb :D
[00:35:23 CET] <T4ng10r> its wraper on gdb with course
[00:35:39 CET] <llogan> I assumed it was Canadian.
[00:35:43 CET] <JEEB> :D
[00:35:46 CET] <T4ng10r> it shows code in upper part of screan and gdb in lower
[00:36:15 CET] <JEEB> try with plain gdb first, pastebin what it tells you when you load the binary
[00:36:44 CET] <T4ng10r> with ffmpeg_g I see that breakpoint set on vf_drawtext.c functions name are successful
[00:36:48 CET] <T4ng10r> no pedning
[00:36:51 CET] <T4ng10r> ok, pure gdb
[00:38:43 CET] <T4ng10r> http://pastebin.com/fWVipmjc
[00:38:49 CET] <T4ng10r> pure gdb
[00:39:18 CET] <JEEB> ok, so it does indeed read symbols, that's great
[00:39:29 CET] <JEEB> otherwise it would say that symbols weren't found
[00:39:43 CET] <T4ng10r> yes
[00:39:58 CET] <jkqxz> None of your breakpoints were ever hit, because it didn't get that far?
[00:39:59 CET] <ubitux> [Parsed_drawtext_0 @ 0x1ff35c0] Both text and text file provided. Please provide only one
[00:40:04 CET] <T4ng10r> there's possibility that it didn't reached point of breakpoints
[00:40:50 CET] <ubitux> which is a pretty strange error actually
[00:41:19 CET] <T4ng10r> and you were all right
[00:41:24 CET] <jkqxz> Look in libavfilter/vf_drawtext.c.  The failure message is near the top of the init() function.
[00:41:36 CET] <T4ng10r> I'm testing pts:gmtime and time value
[00:42:00 CET] <T4ng10r> I've set breakpoint in init (vf_drawtext:596) and it hits
[00:42:12 CET] <T4ng10r> thank you all for you help and patience
[00:42:30 CET] <T4ng10r> now I can go sleep :)
[00:43:02 CET] <ubitux> why the hell is textfile defined here
[00:43:25 CET] <T4ng10r> to much \ 
[00:43:52 CET] <T4ng10r> i tried to escape time in place  of delta parameter - and whole parsing is fooled
[00:44:07 CET] <ubitux> oh, it's hitting the escaping madness, ok
[01:20:55 CET] <atomnuker> michaelni: with 4096x4096 images ffv1 tries to allocate a packet over 2Gb per frame (which fails)
[01:21:05 CET] <atomnuker> that doesn't seem right
[01:21:15 CET] <atomnuker> test it with one of the images from here: http://svs.gsfc.nasa.gov/vis/a000000/a004100/a004128/frames/4096x4096_1x1_30p/
[01:28:53 CET] <cone-912> ffmpeg 03Ganesh Ajjanagadde 07master:7dabc78ce13e: lavu/rational: add more info regarding floor(x+0.5) usage
[01:32:34 CET] <rcombs> that seems like a lot
[01:33:12 CET] <Compn> bonus points to the dev who tests all encoders with those images ^^^^^^^^
[01:34:18 CET] <atomnuker> well, doesn't seem like a lot, ffv1 does this to calculate it: AV_INPUT_BUFFER_MIN_SIZE + avctx->width*avctx->height*3LL*4;
[01:35:35 CET] <atomnuker> (shouldn't that 4 be just the number of planes?)
[01:39:19 CET] <michaelni> atomnuker, -level 4 should use less than 2gb, also it could be chnaged to realloc if it runs out
[01:40:18 CET] <michaelni> 4 should be planes, yes i think so too
[01:41:06 CET] <michaelni> or rather channels, as in 1 plane packed RGBA64 
[01:49:42 CET] <atomnuker> michaelni: yeah, that works
[01:49:53 CET] <atomnuker> that enables version 2, right?
[01:49:59 CET] <atomnuker> how to enable version 3 though?
[01:57:30 CET] <atomnuker> nevermind, ffprobe reports the files as version 4
[02:20:22 CET] <cone-912> ffmpeg 03Andrew Shulgin 07master:1c7e2cf9d339: avformat/rtpdec_h264: Ignore invalid sprop-parameter-sets missing PPS
[04:51:00 CET] <Timothy_Gu> 8%... that's quite a lot
[06:13:28 CET] <Zeranoe> I'm dropping Windows XP support. This will allow Intel QSV support to be included in the Windows builds. I will provided periodic Windows XP builds, but the daily builds will not support it.
[09:37:13 CET] <j-b> 'moroning
[10:13:46 CET] <durandal_1707> j-b: why I get connection reset by peer?
[10:13:57 CET] <j-b> durandal_1707: doing what? :D
[10:14:05 CET] <ismail> j-b: git clone
[10:14:16 CET] <durandal_1707> git pull
[10:14:18 CET] <ismail> interminently having that
[10:14:37 CET] <j-b> I'd guess because we're getting hammered once again by chinese IPs?
[10:14:41 CET] <j-b> I'll ask our master.
[10:36:42 CET] <cone-750> ffmpeg 03Clément BSsch 07master:090621d7cece: lavfi: add bench and abench filters
[11:04:23 CET] <ubitux> http://pastie.org/pastes/10743129/text  ./ffmpeg -nostats -f lavfi -i testsrc2=s=uhd2160:d=1 -vf format=yuv420p,bench=start,format=rgba,bench=stop -f null -
[11:04:30 CET] <ubitux> before and after aarch64 optims
[11:09:40 CET] <rcombs> Zeranoe: good call
[11:10:18 CET] <nevcairiel> Zeranoe: qsv can be build with XP support, one just has to build the dispatcher library appropriately
[11:10:32 CET] <nevcairiel> (although QSV itself wont work on XP, but thats beside the point)
[11:12:58 CET] <rcombs> nevcairiel: btw, re: https://trac.ffmpeg.org/ticket/4828 afaik AudioToolbox falls under the GPL system library linking exception
[11:13:43 CET] <rcombs> (much like VideoToolbox)
[11:14:53 CET] <nevcairiel> i suppose
[11:15:04 CET] <nevcairiel> anyone ever tried to debug mov seeking?
[11:15:35 CET] <nevcairiel> i can see it finding a key frame index at a specific timestamp, but  the first packet i get from the demuxer after the seek is 2 packets after said keyframe
[11:24:09 CET] <nevcairiel> nvm i was confused, looks like the index just marks a keyframe which isnt actually one
[11:31:05 CET] <rcombs> quality
[11:42:09 CET] <nevcairiel> apparently it happens because there is a "rap group", whatever that is
[11:42:24 CET] Action: nevcairiel digs up specs
[11:42:50 CET] <wm4> better than "boy band" I guess
[11:47:22 CET] <nevcairiel> supposedly its a way to mark random access points
[11:50:34 CET] <nevcairiel> but there just isnt any at this point in the file
[11:50:36 CET] <nevcairiel> oh well
[11:57:18 CET] <rcombs> ISOBMFF BoyBandDescriptor
[12:24:55 CET] <JEEB> lol
[12:27:09 CET] <rcombs> the drummer is stored in a `rngo` atom
[12:27:41 CET] <JEEB> now you just have to find a brand for it ;)
[12:28:35 CET] <rcombs> hmm, "Apple Records" produces confusion with the tech giant
[12:39:38 CET] <cone-750> ffmpeg 03Rostislav Pehlivanov 07master:6061b78e8374: vc2enc: remove redundant put_padding() and use skip_put_bytes() instead
[12:49:32 CET] <kurosu_> anybody having a problem with latest msys2 vim package (7.4.1415-2) ?
[12:49:57 CET] <kurosu_> Doesn't start but no error, and when running strace, complains about missing acl_free in msys-2.0.dll
[13:12:20 CET] <Daemon404> kurosu_, yes, same here
[13:13:50 CET] <kurosu_> Daemon404, while I have your attention, no issue running gdb? Haven't been able to insert breakpoints in months
[13:14:23 CET] <Daemon404> i dont use gdb on windows much, but i can try and check
[13:14:38 CET] <Daemon404> that sounds pretty broken though...
[13:16:38 CET] <Daemon404> Type "apropos word" to search for commands related to "word".
[13:16:38 CET] <Daemon404> Traceback (most recent call last): File "<string>", line 3, in <module>
[13:16:38 CET] <Daemon404> ImportError: No module named libstdcxx.v6.printers
[13:16:38 CET] <Daemon404> /etc/gdbinit:6: Error in sourced command file:
[13:16:38 CET] <Daemon404> Error while executing Python code.
[13:16:41 CET] <Daemon404> not off to a good start
[13:16:47 CET] <kurosu_> only think deviating from a normal install is maybe that I allow loading .gdbinit in the current path, and that I set those breakpoints from there
[13:16:56 CET] <kurosu_> only pthread and iconv msys2 dlls are linked by the ffmpeg binary, so shouldn't be the source of the issue
[13:17:06 CET] <kurosu_> getting something like:
[13:17:07 CET] <kurosu_> Cannot insert breakpoint 2.
[13:17:07 CET] <kurosu_> Cannot access memory at address 0x140df4e30
[13:17:07 CET] <kurosu_> Cannot insert breakpoint 1.
[13:17:07 CET] <kurosu_> Cannot access memory at address 0x140e06840
[13:17:42 CET] <kurosu_> from script of the shape:
[13:17:49 CET] <kurosu_> file ffmpeg_g.exe
[13:17:49 CET] <kurosu_> b main
[13:17:49 CET] <kurosu_> b ff_butterflies_float_avx
[13:17:56 CET] <kurosu_> r <parameters>
[13:19:17 CET] <Daemon404> just installing gcc
[13:20:05 CET] <kurosu_> (btw I think I edited out /etc/gdbinit to not list this anyway)
[13:22:48 CET] <Daemon404> i can set bp on a test program (didnt try ffmpeg)
[13:22:55 CET] <Daemon404> but i get other wierd issues 
[13:23:21 CET] <Daemon404> ah... wrong gdb
[13:23:25 CET] <Daemon404> i forgot msys2 has 3.
[13:24:03 CET] <kurosu_> invoking /mingw64/bin/gdb configured for x86_64-w64-mingw32 afaik
[13:24:46 CET] <kurosu_> but I do have the msys/gdb package installed
[13:26:29 CET] <Daemon404> i686 works fine
[13:26:33 CET] <Daemon404> with vanilla install
[13:26:44 CET] <Daemon404> and a simple test prog
[13:27:40 CET] <kurosu_> huh
[13:27:56 CET] <kurosu_> installing mingw-w64-i686-gdb in addition solved the issue
[13:28:08 CET] <Daemon404> O_o
[13:28:14 CET] <kurosu_> I mean msys/*
[13:28:28 CET] <kurosu_> mingw64/mingw-w64-x86_64-gdb wasn't enough apparently
[13:28:35 CET] <Daemon404> that seems... odd
[13:28:45 CET] <nevcairiel> i feel so much happier not even bothering to use the msys2 provided toolchains
[13:29:05 CET] <kurosu_> gcc used should be x86_64-w64-mingw32
[13:29:57 CET] <Daemon404> i've never used the msys2 toolchains/gdb myself either
[13:29:57 CET] <kurosu_> nevcairiel, maybe the effort is worth it, but it's sad to actually have to go through those lengths - and I don't think I have been atypical
[13:30:05 CET] <Daemon404> that too.
[13:30:24 CET] <nevcairiel> well the msys2 people are a bit peculiar when it comes to their toolchain
[13:30:45 CET] <nevcairiel> for some reason they insist to use mingw trunk, which is more often broken than not, and then apply a boatload of questionable patches on top
[13:31:06 CET] <nevcairiel> so since i use my toolchain to produce production builds that get distributed to users, i prefer to make my own
[13:31:10 CET] <Daemon404> their gcc was from svn too wasnt it
[13:31:46 CET] <kurosu_> I wouldn't have time, patience nor knowledge to roll a few of those on my own
[13:31:58 CET] <Daemon404> most people download nevcairiel's
[13:32:00 CET] <Daemon404> afaik
[13:32:00 CET] <nevcairiel> i have most of that scripted by now
[13:32:18 CET] <kurosu_> at some point, it may be simpler for what I do to just use a linux vm
[13:32:19 CET] <nevcairiel> but yes, plenty people use mine
[13:32:39 CET] <kurosu_> "just" (btw)
[13:32:41 CET] <ismail> nevcairiel: mingw trunk is fine now actually but msys people apply lots of weird patches
[13:32:46 CET] <nevcairiel> (https://files.1f0.de/mingw/ btw)
[13:34:46 CET] <kurosu_> nevcairiel, how do you "install" it (probably will wait for next such issue)? Unpack in <msys2 install path>/mingw64 ?
[13:34:51 CET] <nevcairiel> i only apply one patch to my mingw to fix a bug that caused builds to randomly fail
[13:35:05 CET] <nevcairiel> kurosu_: just unpack somewhere where the shell finds it
[13:35:34 CET] <nevcairiel> could be any path if you update your PATH appropriately
[13:35:40 CET] <kurosu_> k, could be /opt or whatever I may like then
[13:35:44 CET] <kurosu_> ah yes, exactly
[13:36:09 CET] <kurosu_> I never know if they stopped hardcoding rpath or whatever it is/was called
[13:36:56 CET] <ismail> we should really upstream that patch, we (openSUSE) apply it too and apparently its written by one of our contributors
[13:38:08 CET] <nevcairiel> which patch, the mkstemp one?
[13:38:11 CET] <nevcairiel> i wrote that myself =p
[13:38:27 CET] <nevcairiel> after a day of debugging
[13:38:29 CET] <nevcairiel> was ratehr painful
[13:38:58 CET] <ismail> https://sourceforge.net/p/mingw-w64/bugs/471/
[13:39:12 CET] <ismail> well surely you are not Jan :P
[13:39:30 CET] <nevcairiel> no, but unfortunately I only found that ticket after hours of debugging
[13:39:38 CET] <nevcairiel> since before I had no clue mkstemp was breaking everything
[13:39:42 CET] <ismail> ah hehe, anyhow let me me mail upstream.
[13:40:30 CET] <nevcairiel> The change was included in some huge diff dump as linked in that ticket, no clue how mingw works, but such dump seems unlikely to be very welcome
[13:41:07 CET] <ismail> I'll post the one line fix: https://build.opensuse.org/package/view_file/windows:mingw:win64/mingw64-runtime/mkstemp.diff?expand=1
[13:43:48 CET] <ismail> http://article.gmane.org/gmane.comp.gnu.mingw.w64.general/12244
[13:50:47 CET] <kurosu_> nevcairiel, you don't have a gdb in that file, though ? Meaning I still have to install it from msys2 ?
[13:51:18 CET] <nevcairiel> hm i have gdb from soemwhere else
[13:51:22 CET] <nevcairiel> i forget where its from
[13:51:57 CET] <nevcairiel> but yeah this is compiler only
[13:54:42 CET] <Daemon404> its like msys1 days all over again
[13:54:50 CET] <Daemon404> lemme find some random zips of stuff i need, etc
[13:55:03 CET] <nevcairiel> its not my fault msys2 does weird things =p
[13:55:04 CET] <kurosu_> I'll still stick to gdb, even if I prefer msvc' debugger, because of yasm & co
[13:55:14 CET] <nevcairiel> i really never use gdb
[13:55:28 CET] <Daemon404> has gdb support now doesnt it
[13:55:31 CET] <Daemon404> or is that only for ARM
[13:55:40 CET] <nevcairiel> works for everything that gdb works on
[13:55:48 CET] <nevcairiel> although setting it up is a bit finnicky
[13:56:23 CET] <Daemon404> interesting
[13:56:50 CET] <Daemon404> i figured it would be, since it uses teh gdb server stuff, iirc
[13:57:07 CET] <wm4> I didn't know we had coded_side_data
[14:02:04 CET] <nevcairiel> stream global side data? it was added a while ago
[14:03:31 CET] <wm4> isn't that in AVStream
[14:03:35 CET] <wm4> too many side datas
[14:05:05 CET] <nevcairiel> stream and codec each have one
[14:05:11 CET] <nevcairiel> i suppose codec is filled by decoders?
[14:05:17 CET] <nevcairiel> or maybe encoders
[14:05:20 CET] <nevcairiel> so confusing
[14:13:24 CET] <ubitux> https://trac.opensubtitles.org/projects/opensubtitles/wiki/HashSourceCodes weird hashing...
[14:15:06 CET] <nevcairiel> it just sums all bytes into a 64-bit value and lets it overflow? =p
[14:15:15 CET] <Daemon404> seems like NIH gone wrong
[14:15:44 CET] <nevcairiel> ah it only does that for the first and last chunk of the file
[14:16:05 CET] <wm4> yeah that's dumb
[14:16:06 CET] <ubitux> afaict it's sth like size+sum(content[:0xffff+1])+sum(content[:-0xffff])
[14:16:34 CET] <wm4> there's even a LISP impl
[14:17:08 CET] <ubitux> wth is foxpro
[14:17:09 CET] <nevcairiel> i have not even heard of "Vala" or what that is
[14:17:12 CET] <nevcairiel> looks Cish
[14:17:22 CET] <wm4> Vala is Gnome's C# clone
[14:17:27 CET] <wm4> it's based on gobject
[14:18:11 CET] <nevcairiel> FoxPro i know, its one of microsofts decades old things related to one of their database projects
[14:18:29 CET] <nevcairiel> its like implementing this in SQL =PO
[14:47:48 CET] <cone-750> ffmpeg 03Rostislav Pehlivanov 07master:41985d40c652: vc2enc: simplify slice cost caching
[14:47:49 CET] <cone-750> ffmpeg 03Rostislav Pehlivanov 07master:7bcc57ad9938: vc2enc: fix packet underallocation and minimum bitrate with interlacing
[14:48:44 CET] <wm4> I didn't realize ff_init_buffer_info accesses the "current" packet
[14:48:47 CET] <wm4> how does this even make sense
[14:49:03 CET] <wm4> oh well
[14:53:54 CET] <kierank> nevcairiel: haven't heard FoxPro in years
[14:54:04 CET] <nevcairiel> its been dead for ever
[14:54:08 CET] <nevcairiel> its from DOS times
[14:54:08 CET] <nevcairiel> :D
[15:01:05 CET] <Daemon404> we learned foxpro in elementary school....
[15:04:55 CET] <kurosu_> nevcairiel, what's the default for your compiler? -m32?
[15:05:33 CET] <nevcairiel> there is two in there, different binaries for x86 and x86_64, need to use a cross prefix for x86_64 builds
[15:06:20 CET] <kurosu_> ok...
[15:06:23 CET] <nevcairiel> ie x86_64-w64-mingw32-gcc
[15:06:46 CET] <ubitux> hey btw, if you're looking for GSoC subject; https://trac.ffmpeg.org/ticket/4364
[15:07:48 CET] <ubitux> since we have a lot of advanced color filters it makes sense
[15:08:06 CET] <ubitux> and there is enough to get busy if you're not relying on a library
[15:09:07 CET] <Daemon404> raw camera files are a rabbit hole...
[15:09:11 CET] <Daemon404> full of insanity
[15:12:11 CET] <ubitux> Daemon404: yeah but this one has a standard
[15:13:02 CET] <ubitux> it's actually the format used by chdk (alt firmware for canons)
[15:13:41 CET] <Daemon404> ubitux, oic
[15:14:41 CET] <RiCON> https://en.wikipedia.org/wiki/OpenRAW#Limitation reminded me of https://xkcd.com/927/
[15:24:17 CET] <Daemon404> BBB, fyi i will be in NYC again in may
[15:24:26 CET] <Daemon404> if youre up for dinner/drinkd
[15:25:04 CET] <BBB> yes absolutely
[15:37:15 CET] <mateo`> wm4, JEEB: "bad" news, I will have to reintroduce a public function the set the java vm, the google c++ jni wrapper is only "available" since android 4.4 (i just found out by testing on a bunch of old devices)
[15:45:25 CET] <JEEB> yeah, I noticed that but I was anyways thinking of limiting any apps to 4.4+
[15:45:38 CET] <JEEB> esp. due to the fact that libmpv's opengl renderer requires opengl es 3 :)
[15:45:52 CET] <JEEB> of course I understand that you might want to support older ones, too
[15:46:13 CET] <mateo`> I can still dlsym JNI_GetCreatedJavaVMs before android 4.4, but i have no idea what will be the result of calling this function from exec without a vm initialized (as opposed to an app env)
[15:47:37 CET] <mateo`> btw I can keep the dlopen/dlsym code and give an api to set manually the vm, what do you think ?
[15:47:57 CET] <JEEB> sounds good
[15:58:35 CET] <atomnuker> Can I realloc a buffer allocated by ff_alloc_packet2?
[15:59:27 CET] <Daemon404> i somehow doubt this is kosher
[15:59:44 CET] <nevcairiel> i believe so, however since a realloc can result in a memcpy, wouldnt it be wiser to adjust the original estimate
[16:00:28 CET] <atomnuker> well, since it would solve like 99% of all vc2 stability problems it might be a good idea to _not_ put any bits before I know the cost of everything
[16:01:00 CET] <iive> just make ff_realloc function, if there isn't already one
[16:01:27 CET] <iive> i think that manual memalign after malloc is still a thing, so...
[16:01:54 CET] <Daemon404> i thought memalign hack was removed
[16:02:41 CET] <Daemon404> apparently not
[16:02:47 CET] <Daemon404> im not sure what systems would even need it
[16:03:10 CET] <Daemon404> (it's all sorts of illegal/wrong)
[16:03:40 CET] <nevcairiel> its not that wrong really, thats practically how many of such OS implementations also work
[16:04:00 CET] <Daemon404> i meant by the c spec :P
[16:04:07 CET] <Daemon404> casting pointers to long and doign arith on them
[16:04:08 CET] <Daemon404> yum yum
[16:04:20 CET] <nevcairiel> they even invented intptr_t for that purpose
[16:04:25 CET] <Daemon404> we use long
[16:04:31 CET] <nevcairiel> well easy enough to fix that
[16:04:54 CET] <Daemon404> good luck finding a system that doesnt have aligned malloc to test on
[16:05:03 CET] <nevcairiel> easy enough to fake that
[16:05:04 CET] <nevcairiel> :D
[16:05:10 CET] <Daemon404> not my point :P
[16:05:23 CET] <Daemon404> as far as im concerned, it's now a theoretical problem
[16:05:48 CET] <nevcairiel> its slightly odd though, the long thing worked all this time, but long is 32-bit on windows
[16:05:58 CET] <nevcairiel> and people apparently still use the hack today
[16:06:52 CET] <Daemon404> because we dont care
[16:06:53 CET] <Daemon404> diff = ((~(long)ptr)&(ALIGN - 1)) + 1;
[16:06:56 CET] <Daemon404> we calculate the diff
[16:07:29 CET] <nevcairiel> still potentially casts a 64-bit ptr value to 32-bit long
[16:07:54 CET] <Daemon404> i dont even know what the behavior is there
[16:10:50 CET] <jamrial> maybe it should be changed to intptr_t just in case then?
[16:11:32 CET] <kurosu_> using nevcairiel's gcc and tdm-gcc's gdb, still can't have valid breakpoints: it either fails (albeit at the correct line) to set them in the same fashion, or they are never triggered
[16:11:47 CET] <Daemon404> that is super weird
[16:11:55 CET] <jamrial> or just make configure fail (or silently disable) memalign hack if _aligned_realloc() is available
[16:12:18 CET] <kurosu_> yes, and the issue is I don't think I did anything but install or reinstall various packages
[16:13:33 CET] <kurosu_> full msys2 reinstall on the way...
[16:14:03 CET] <Daemon404> :/
[16:15:12 CET] <durandal_1707> kierank: doing gradient thing for showvolume?
[16:15:24 CET] <kierank> maybe later in the month
[16:15:39 CET] <kierank> got to get lavfi into our pipeline first
[16:16:11 CET] <Daemon404> RIP kierank 
[16:16:32 CET] <durandal_1707> haven't using smptehdbars?
[16:16:44 CET] <kierank> different codebase
[16:18:28 CET] <durandal_1707> there's no vs filter that could do this
[16:21:15 CET] <kierank> VS?
[16:21:31 CET] <Daemon404> vapoursynth
[16:27:06 CET] <Timothy_Gu> hmm AudioToolbox
[16:27:31 CET] <Timothy_Gu> next step: DirectShow audio decoder (with support for dshow DCA decoders)
[16:29:46 CET] <kurosu_> well, same thing...
[16:41:36 CET] <kurosu_> nice, just deleted my ffmpeg folder - see you next year I guess
[16:44:01 CET] <kierank> what happened?
[16:45:52 CET] <kierank> a real shame, osprey made good cards
[16:47:21 CET] <Daemon404> kierank, he was reinstalling msys2
[16:47:25 CET] <Daemon404> no drama.
[16:47:48 CET] <kierank> lol
[17:01:49 CET] <wm4> sigh, trying to port my decode API patches to ffmpeg
[17:02:24 CET] <wm4> but for some reason I get an obscure fate failure due to VSYNC_VFR dropping the last frame...
[17:03:05 CET] <wm4> and it involves things like float timestamp calculations (???)
[17:03:14 CET] <Daemon404> wut
[17:03:29 CET] <durandal_1707> where?
[17:04:20 CET] <wm4> durandal_1707: do_video_out
[17:05:17 CET] <durandal_1707> I can't grep I'm outside
[17:19:34 CET] <wm4> int64_t ts = av_rescale_q(decoded_frame->pts = best_effort_timestamp, ist->st->time_base, AV_TIME_BASE_Q);
[17:19:37 CET] <wm4> such nice code
[17:20:10 CET] <wm4> gotta save 1 line of code in a 250 loc function
[17:21:02 CET] <J_Darnley> is that an assignment in a function call?
[17:21:43 CET] <wm4> yes, isn't it concise and elegant
[17:22:50 CET] <kierank> wow
[17:24:45 CET] <fritsch> until you need to debug it ...
[17:26:51 CET] <wm4> ok, I see my problem... apparently, the flush packet carries a dts, which is then output by the flushed AVFrame as pkt_dts, which is then used by the ffmpeg.c timestamp logic
[17:27:11 CET] <wm4> maybe
[17:28:45 CET] <wm4> ah yes
[17:29:04 CET] <wm4> ffmpeg.c explicitly sets a dts on every video input AVPacket, even if it's a flush packet
[17:29:10 CET] <wm4> is this a bug or feature
[17:29:37 CET] <wm4> avconv does not do this
[17:45:25 CET] <ubitux> omfg apple
[17:45:32 CET] <ubitux> die please die ffs
[17:45:54 CET] <ubitux> SO. apple asynchronous design summary
[17:46:17 CET] <ubitux> you have a custom callback for when the frame is decoded, and a function to push data
[17:46:20 CET] <ubitux> so far, everything is OK
[17:46:42 CET] <ubitux> but now, you want to end shit, and decide that you need to make sure that callback won't be called again
[17:47:14 CET] <ubitux> smartass like you are, you decide to call VTDecompressionSessionFinishDelayedFrames() to make sure the internal queue gets pushed to the user
[17:47:34 CET] <ubitux> then because you don't trust apple one second, you also call VTDecompressionSessionWaitForAsynchronousFrames()
[17:47:53 CET] <ubitux> now you are happy and pretty sure your callback won't be called again
[17:48:12 CET] <ubitux> so you start trashing your internal queue which is filled in your callback etc
[17:48:15 CET] <ubitux> AND THEN
[17:48:20 CET] <ubitux> THIS SHIT FUCKING CALL YOUR CALLBACK AGAIN
[17:48:22 CET] <ubitux> SEVERAL TIMES
[17:48:24 CET] <ubitux> FFS
[17:48:32 CET] <ubitux> I'M GONNA KILL THESE FUCKING STUPID DESIGNERS
[17:48:40 CET] Action: J_Darnley is reminded of libavfilter
[17:49:06 CET] <ubitux> i'm going to need to add a fucking counter
[17:49:11 CET] <mateo`> :D
[17:49:12 CET] <ubitux> with a lock and shit
[17:49:32 CET] <ubitux> because these idiots can think for a second with their little brain
[17:49:35 CET] <nevcairiel> isnt apple shit generally reference counted
[17:49:56 CET] <ubitux> it's not the problem
[17:50:41 CET] <mateo`> reference counted and in a dispatch queue
[17:55:13 CET] <cone-865> ffmpeg 03Clément BSsch 07master:f1148390d7ed: sws/aarch64: add {nv12,nv21,yuv420p,yuv422p}_to_{argb,rgba,abgr,rgba}_neon
[18:17:13 CET] <michaelni> "MXF Demuxer Improvements" has no mentor (thardin told me he doesnt have time this year)
[19:17:25 CET] <wm4> Timothy_Gu: what are DCA decoders?
[19:17:33 CET] <wm4> mateo`: that seems unfortunate, but whatever
[19:23:23 CET] <kierank> wm4: dts coeherent acoustics
[19:23:31 CET] <kierank> the official name afaik
[19:23:38 CET] <kierank> like ac-3 to dolby digital
[19:23:45 CET] <nevcairiel> why would anyone want that, we have a fully compatible decoder now =p
[19:35:21 CET] <BBB> wm4: sweet!
[19:43:54 CET] <mateo`> wm4: nice patchset :)
[19:54:38 CET] <cone-817> ffmpeg 03Wan-Teh Chang 07master:4845f0720e38: Move the |die| member of FrameThreadContext to PerThreadContext.
[20:02:09 CET] <hush> hi all, I am trying to improve the test coverage of the lib. Please review my first patch http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/190530.html
[20:02:37 CET] <crot^^^> hello All, I have an issue where I cannot consume a udp stream. Running ffprobe -v trace udp://237.1.1.0:1234  ends in nothing more than [udp @ 0x28c1940] end receive buffer size reported is 131072
[20:04:12 CET] <crot^^^> does anyone have any pointers to run this down I have verified via wireshark that the join is going out and the content is present after the command is ran. 
[20:12:10 CET] <Timothy_Gu> nevcairiel: yeah right, forgot about that :)
[20:34:19 CET] <durandal_1707> nobody picking my hard project :D
[20:35:24 CET] <Timothy_Gu> durandal_1707: didn't michaelni have a patch using motion est from avcodec?
[20:35:57 CET] <wm4> durandal_1707: make it sound more interesting and friendly
[20:36:03 CET] <durandal_1707> that one, from mpeg?
[20:36:37 CET] <Timothy_Gu> durandal_1707: think so
[20:37:01 CET] <Timothy_Gu> also what should the motion estimation filter do? print out motion vectors?
[20:37:15 CET] <durandal_1707> Isnt it far from ideal?
[20:37:44 CET] <durandal_1707> calculate mv and store in frame side data
[20:37:53 CET] <Timothy_Gu> oh ok
[20:38:01 CET] <Timothy_Gu> make your description more speicific then
[20:56:45 CET] <cone-817> ffmpeg 03Mark Harris 07master:c3bb6166dd05: sdp: fix opus sprop-stereo fmtp syntax
[21:02:33 CET] <iive> durandal_1707: michael had 100fps filter in maillist, then BBB flamed him and michael gave it up. Good work BBB :P
[21:02:57 CET] <BBB> huh?
[21:03:09 CET] <BBB> I almost never flame
[21:03:12 CET] <BBB> only very sparingly
[21:03:59 CET] <durandal_1707> iive: proper what is to have 3 separate filters
[21:04:10 CET] <durandal_1707> *way
[21:05:20 CET] <iive> durandal_1707:  why 3?
[21:06:39 CET] <durandal_1707> motion: estimation, interpolation, compensation
[21:06:40 CET] <wm4> iive: the approach wasn't very good, it just pulled libavcodec implementation details into libavutil
[21:08:06 CET] <iive> wm4: maybe it wasn't, maybe it was. The thing is we don't have such filter.
[21:08:50 CET] <wm4> I'm talking about the motion est. API
[21:09:11 CET] <iive> well, BBB wanted the API...
[21:09:12 CET] <wm4> (which could have been used to write such a filter)
[21:09:32 CET] <wm4> having such an API is a good idea (probably), hooking it to libavcodec internals is not
[21:10:16 CET] <BBB> so, wait, am I being trolled now or do you agree with my complaints about that patch?
[21:10:23 CET] <iive> durandal_1707: i don't think the interpolation merits its own filter.
[21:11:02 CET] <iive> BBB: I do not agree with your complaints about that patch. What you demanded was academics. And of course, nobody is interested in doing it.
[21:11:10 CET] <iive> engineers want to make stuff that works.
[21:11:23 CET] <wm4> iive: that's completely wrong
[21:11:26 CET] <BBB> Im slightly smiling now, I always heard the inverse complaint
[21:11:36 CET] <BBB> (academics just want to make stuff work, engineers are tedious about details)
[21:11:45 CET] <BBB> but ok thanks for explaining
[21:11:47 CET] <fritsch> mmh
[21:11:57 CET] <fritsch> academics want a proof of concept
[21:12:00 CET] <fritsch> and are done after that
[21:12:11 CET] <fritsch> no matter it works in the field
[21:12:14 CET] <wm4> iive: if we create an unmaintainable mess, it will be hard to fix, improve, or optimize it later
[21:12:34 CET] <wm4> iive: I know it goes against the ffmpeg doctrine, but look at libswscale what happens
[21:12:38 CET] <durandal_1707> iive: several filters that are good are better than one big that sucks
[21:13:09 CET] <durandal_1707> avscale and nascale
[21:13:50 CET] <Timothy_Gu> what does the 100fps filter do any way
[21:13:57 CET] <iive> wm4:  at least we have a WORKING mess.
[21:14:07 CET] <Timothy_Gu> iive: I disagree
[21:14:28 CET] <wm4> iive: yeah, no user complaints about libswscale at all!
[21:14:47 CET] <Timothy_Gu> mess is worse than nothing
[21:14:59 CET] <iive> everybody complains about everything.
[21:15:38 CET] <wm4> iive: that's an overly general statement completely ignoring the problem, but ok
[21:16:07 CET] <iive> what goes around, comes around.
[21:16:34 CET] <Shiz> engineering is not "makings things work", it's designing proper systems
[21:17:28 CET] <iive> Shiz: it's literally, making stuff works. even when you don't know the math and tune things by trail and error
[21:17:42 CET] <Shiz> uhm no
[21:18:35 CET] <iive> Shiz: i'll give you an example. Have you heard of EmDriver?
[21:18:37 CET] <BBB> well look
[21:18:43 CET] <BBB> iive: I understand your point of view
[21:18:45 CET] <Shiz> kindly lookup the definition of an engineer
[21:18:45 CET] <iive> ops...
[21:18:46 CET] <BBB> iive: but I disagree with it
[21:18:50 CET] <BBB> iive: ok?
[21:18:53 CET] <Shiz> i don't care whatever shoddy thing you're going to bring up
[21:21:09 CET] <iive> Shiz: it's simple. engineers make stuff that works. academics figure out how and why stuff works.
[21:21:30 CET] <Shiz> not gonna repeat myself
[21:21:36 CET] <Shiz> engineers build systems, not hacks
[21:21:43 CET] <Timothy_Gu> iive: FFmpeg isn't a hackathon product, which just needs to work. FFmpeg was back in 2003, but it is not any more. Now it needs to be stable, well-designed, and well-thought out.
[21:21:45 CET] <JEEB> engineers have standards and rules
[21:22:12 CET] <Timothy_Gu> and case in point: the 100fps filter raises a bunch of objections against its methodology
[21:22:27 CET] <BBB> oops
[21:22:31 CET] <BBB> crap, wrong button
[21:22:38 CET] <JEEB> like, I build systems but I would never, ever consider myself an "engineer".
[21:23:09 CET] <iive> Timothy_Gu: first time when you make something, it is always a hack. You need to see it work and grow in order to figure out its initial flaws.
[21:23:11 CET] <Timothy_Gu> if you are at a hackathon, you need ot finish it. We are not. We don't have a deadline. We do have an obligation to make sure that it fits future needs.
[21:24:04 CET] <Timothy_Gu> iive: Yes. THing is, these initial flaws have already been repeated elsewhere, and some people are just trying to prevent it from getting into FFmpeg again.
[21:24:17 CET] <iive> if you want to make something perfect from the first iteration, then you will never make anything good enough.
[21:24:40 CET] <iive> Timothy_Gu: And that's why we don't have 100fps filter. Thank you very much.
[21:24:44 CET] <JEEB> you can't make things perfect, just that you can make something that doesn't raise general objections
[21:24:59 CET] <JEEB> although I know, bikesheds et al
[21:25:04 CET] <Shiz>  @iive  Timothy_Gu: first time when you make something, it is always a hack.
[21:25:08 CET] <Shiz> i hope you never become an architect
[21:25:34 CET] <Timothy_Gu> We don't want to make it perfect. We want to make it as good as it can be. If there are objections, we fix them. If there are conflicting objections, we fidn the "middle ground."
[21:25:37 CET] <iive> Shiz: well, you start with bike sheds first :P
[21:26:56 CET] <JEEB> also nothing wrong with hacks when you are trying out designs. think of scaled-down models of an actual work
[21:27:11 CET] <iive> Shiz: however architecturing anything non-standard involves a lot of simulations.
[21:27:37 CET] <Shiz> of course
[21:27:37 CET] <JEEB> but those things don't automagically become the house, they are not necessarily anywhere close getting merged
[21:27:42 CET] <Shiz> what jeeb said
[21:28:40 CET] <iive> and that's why we don't have 100fps filter.
[21:30:06 CET] <Timothy_Gu> ^^ that's a good thing
[21:30:06 CET] <JEEB> yes, that's why we don't have a 100fps filter that could have accessed some internals in a rather not-necessarily-nice way (I don't remember the patch itself, but I will go by the hearsay that it used avcodec internals from outside in a hacky way)
[21:30:27 CET] <JEEB> that it didn't become something merge'able is of course unfortunate
[21:31:07 CET] <iive> let me say something and I'll drop the matter.
[21:31:08 CET] <wm4> <iive> Shiz: however architecturing anything non-standard involves a lot of simulations. <- yeah, but not building it
[21:31:16 CET] <wm4> they didn't make rocket tests by blowing up test pilots
[21:31:26 CET] <Shiz> well actually
[21:31:30 CET] <wm4> except sometimes
[21:32:04 CET] <iive> Cleaning up and having perfectly designed API is LIbAV goal. It's one of the reason for their demise. Don't make the same mistake here.
[21:32:18 CET] <wm4> the stupidest thing I've ever heard today
[21:32:18 CET] <JEEB> nothing is perfect
[21:32:20 CET] <JEEB> also wow
[21:32:46 CET] <iive> it's ok to don't have perfectly designed stuff. especially if it stays internal.
[21:32:46 CET] <wm4> could write an essay how stupid it is, but I'd rather do something else now
[21:33:19 CET] <Timothy_Gu> iive: it's ok to don't have perfectly designed stuff. especially if it stays internal. <-- yes. the 100fps patch makes bad apis public
[21:33:39 CET] <iive> Timothy_Gu: not the first patch. BBB request an API...
[21:33:50 CET] <iive> to make it clean separation.
[21:33:57 CET] <iive> and then he didn't like the API.
[21:35:18 CET] <Timothy_Gu> Am I correct in saying that you like the first patch better?
[21:36:29 CET] <rcombs> what are people mad about this time
[21:36:47 CET] <iive> Timothy_Gu: let's say I had no issues with the first patch.
[21:37:43 CET] <iive> especially since we already have some filters that literally reuse codecs code. e.g. mcdeint
[21:38:04 CET] <michaelni> btw, i do plan to return to the mcfps code and improve it and get rid of the Motion est libavcodec dependancy. but too long todo list and other things where more interresting or more important ...
[21:39:33 CET] <Timothy_Gu> iive: and that's your first mistake. It is simply wrong to say that it is technically acceptable to use a private API from another library.
[21:40:56 CET] <iive> Timothy_Gu: technically it is. Academically, it's blasphemy.
[21:42:57 CET] <iive> michaelni: it might also be good idea to port the h264 hexagonal search into ffmpeg. iirc
[21:46:25 CET] <TD-Linux> BBB, what was your experience with frame-parallel and ffvp9? is it not worth using ever?
[21:47:07 CET] <BBB> the bitstream feature?
[21:47:19 CET] <BBB> like, vpxenc frame-parallel=1/0?
[21:47:21 CET] <TD-Linux> BBB, yes.
[21:47:32 CET] <BBB> hm & it depends on your goals (/me hides)
[21:47:46 CET] <BBB> youll lose about 1-2% in coding efficiency, from what I recall
[21:47:55 CET] <BBB> depending on the target bitrate and so on
[21:48:03 CET] <TD-Linux> BBB, I had read earlier that ffvp9 doesn't gain additional parallelism from it
[21:48:05 CET] <BBB> if your goal is to decode with ffmpeg, I wouldnt use it
[21:48:22 CET] <BBB> if your goal is to decode with vpxdec/libvpx, maybe its worthwhile
[21:48:42 CET] <BBB> I think vpxenc nowadays enables both tiling as well as frame-parallel, both cost 1-2%, I think having both isnt worth it
[21:48:53 CET] <BBB> one should be enough, and Id probably use tiling over frame-parallel
[21:49:10 CET] <BBB> but ffmpeg doesnt need them, it is always parallel even without either feature in the bitstream
[21:49:20 CET] <TD-Linux> OK. I'm asking because I'm considering removing it as an encode possibility
[21:49:58 CET] <BBB> youll get minor speedups from it, but not much
[21:50:18 CET] <BBB> (over the already-existing frame parallelism)
[22:26:41 CET] <user123> what are the parameters required to scale a video using scale_video.c program given in example of documentation
[22:30:40 CET] <user123> please help with this
[22:33:27 CET] <BBB> user123: #ffmpeg please
[22:53:18 CET] <wm4> I wonder if there should be something between ffmpeg CLI help, and ffmpeg internal development
[22:53:24 CET] <wm4> like the api mailing list
[22:58:11 CET] <jkqxz> For help developing thing using the libav* APIs?  It could be called libav-devel, perhaps...
[23:01:30 CET] <ubitux> for some reason my fate instance --disable-everything seems to get stalled all the time
[23:03:51 CET] <ubitux> the fuck is going on
[23:05:23 CET] <ubitux> api-seek-test is stalled
[23:05:57 CET] <ubitux> #0  0x00007ffff7bc93e8 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
[23:05:59 CET] <ubitux> #1  0x0000000000461e32 in udp_read (h=0x7107c0, buf=0x721220 "", size=65536) at src/libavformat/udp.c:923
[23:06:01 CET] <ubitux> here ^
[23:06:32 CET] <ubitux> ah, looks related to the URL protocol thing?
[23:09:51 CET] <jamrial> ubitux: api-seek has failed on that client since it was introduced
[23:10:08 CET] <jamrial> maybe the dependecies should be fixed so it doesn't run wiht --disable-everything?
[23:10:09 CET] <ubitux> i don't remember having it stall
[23:10:27 CET] <jamrial> i mean fail
[23:10:31 CET] <jamrial> look at the history
[23:10:40 CET] <ubitux> right, but then there is a regression
[23:10:47 CET] <ubitux> because now it's blocking all my other fate instance :p
[23:10:53 CET] <jamrial> yes, if it stalls now then it's a different issue, but nonetheless, it was never meant to run with --disable-everything
[23:11:49 CET] <ubitux> Using network protocols without global network initialization. Please use avformat_network_init(), this will become mandatory later.
[23:11:53 CET] <ubitux> erm
[23:13:13 CET] <ubitux> bit doesn't help apparently
[23:13:40 CET] <ubitux> oh fuck i don't have time for this
[23:35:59 CET] <wm4> ubitux: why is a fate test using network?
[23:36:46 CET] <ubitux> no idea
[23:36:57 CET] <ubitux> the flv is triggering some network madness maybe?
[23:37:21 CET] <wm4> shouldn't happen IMO
[23:37:54 CET] <ubitux> it's actually in the probing
[23:38:34 CET] <ubitux> http://pastie.org/pastes/10744176/text
[23:39:47 CET] <ubitux> maybe it's trying to probe with the wrong protocol
[23:40:01 CET] <ubitux> like, disable everything disabling file but still keeping network stuff
[23:40:11 CET] <wm4> you should use a better paste site
[23:40:26 CET] <ubitux> so the first/only protocol available would be udp, it would use that for probing
[23:40:35 CET] <wm4> but yeah, sounds like something goes EXTREMELY wrong
[23:41:10 CET] <ubitux> maybe i should add --disable-network to --disable-everything
[23:41:23 CET] <ubitux> which makes me think that carl might be aware of this
[23:42:40 CET] <ubitux> wm4: what's the issue with pastie?
[23:43:12 CET] <wm4> look at your paste
[23:43:21 CET] <wm4> it's not txt but html, and also corrupts the contents
[23:43:31 CET] <J_Darnley> "[email protected]"
[23:43:43 CET] <ubitux> wm4: i just miss copy the first '#'
[23:43:56 CET] <ubitux> and yeah it's not txt, but doesn't really matter
[23:44:15 CET] <ubitux> sprunge is not handy, i often need to pick a specific part, or edit it
[23:44:18 CET] <wm4> often enough it does
[23:44:34 CET] <wm4> sprunge has a web interface too
[23:44:52 CET] <ubitux> ah?
[23:44:59 CET] <ubitux> oh, indeed
[23:45:02 CET] <ubitux> ok
[00:00:00 CET] --- Wed Mar  2 2016