[00:23:39 CET] <cone-054> ffmpeg 03Michael Niedermayer 07master:a11258b73234: tests/fate/lossless-video: Add test for ticket4119 [01:02:59 CET] <Timothy_Gu> michaelni: a bunch of your bsd stations still have weird system clocks, like http://fatebeta.ffmpeg.org/report/x86_64-openbsd5.6-gcc4.2-conf2/20160229010... whose supposed run time is in an hour [01:06:45 CET] <michaelni> Timothy_Gu, probably fixed [01:20:05 CET] <cone-054> ffmpeg 03Michael Niedermayer 07master:993d622d0070: fate/filter-video: add test for Ticket1578 [02:53:34 CET] <Timothy_Gu> how many gp registers are available on x86-32 again? [02:53:48 CET] <jamrial_> 7 [02:54:11 CET] <Timothy_Gu> thx [02:57:40 CET] <Timothy_Gu> is it faster if say I use fewer regs? [02:57:49 CET] <Timothy_Gu> like 6 instead of 7 [03:02:19 CET] <michaelni> 8 [03:03:18 CET] <michaelni> no, its not faster to use fewer [03:03:36 CET] <michaelni> btw using all 8 is tricky [03:04:19 CET] <michaelni> one is for the stack pointer so it interacts with some instructions like call/push/pop/ret and also "m" operands [03:05:03 CET] <michaelni> gcc also likes to have ebp and ebx for itself sometimes see HAVE_EBX_AVAILABLE [03:06:25 CET] <michaelni> that is for inline asm, for yasm there will be problems too if you try to use the stack pointer ... [03:07:09 CET] <michaelni> but its possible in both cases, ive done it long time ago when x86-64 was not existing yet [03:09:06 CET] <jamrial_> if you use x86inc magic exclusively you will be limited to 7, though [03:14:56 CET] <michaelni> small correction "<michaelni> no, its not faster to use fewer" <-- it is faster to use fewer in some cases like for passing them over the stack / saving / restoring whatever. But for the CPU itself using more registers is not slower [03:15:04 CET] <Timothy_Gu> ok [03:15:08 CET] <Timothy_Gu> thanks all [03:15:23 CET] <Timothy_Gu> I am using x86inc, so 7 [03:27:21 CET] <cone-054> ffmpeg 03Michael Niedermayer 07master:1b659101852b: fate/gif: add Test for Ticket3052 [03:27:22 CET] <cone-054> ffmpeg 03Michael Niedermayer 07master:77524ee2dce9: avformat/utils: Be slightly more tolerant with fps vs. stream timebase [03:27:23 CET] <cone-054> ffmpeg 03Michael Niedermayer 07master:4d338f9b64da: fate/vp8: add test for Ticket2451 [04:41:40 CET] <cone-054> ffmpeg 03Michael Niedermayer 07master:080be982e9e5: fate/mpeg4: add mpeg4-es with codec timestamps (vlc ticket 7571) [08:35:39 CET] <rcombs> \o/ aarch64 RPi3 :D [08:35:47 CET] <JEEB> yeah [08:35:51 CET] <rcombs> now I'll finally be able to test AArch64 code easily [08:36:12 CET] <JEEB> will just have to wait for when it becomes order'able [08:36:20 CET] <rcombs> I just ordered 2 from Pi Hut [08:36:25 CET] <JEEB> oh [08:36:37 CET] <JEEB> lessee rsdelivers [08:36:40 CET] <rcombs> might cancel and grab from element14 if they can ship faster to US though [08:36:49 CET] <rcombs> (Pi Hut is RS) [08:37:50 CET] <JEEB> cool. it's on rsdelivers. need to order today I guess [08:38:11 CET] <JEEB> and enjoy dat mmal among other thingos [08:38:23 CET] <rcombs> I'm thinking I might set up an abstraction layer for arm + arm64 like what we have for x86 + x86_64 in x86inc.asm [08:38:49 CET] <ubitux> heh, they're all starting to get available [08:38:51 CET] <rcombs> obviously you can't handle all the differences, but for basic cases I think it should be plenty doable [08:38:55 CET] <JEEB> how different is armv7+neon agains arm64? [08:39:24 CET] <ubitux> different. [08:40:31 CET] <rcombs> removed thumb and a bunch of conditional execution stuff, for one [08:41:14 CET] <rcombs> https://www.linuxplumbersconf.org/2014/ocw/system/presentations/2343/origina... I should probably read this [08:41:16 CET] <ubitux> nice move wrt pine64 btw [08:43:08 CET] <rcombs> no multiple loads, PC no longer accessible as a register (so returning is different) [08:45:06 CET] <rcombs> NEON mnemonics have changed, since they're now part of the core instruction set instead of an extension, and they now set the main condition/flags register instead of their own [08:48:46 CET] <rcombs> the NEON mnemonic stuff is probably trickiest, but it'll probably just need register macros like x86inc [08:49:43 CET] <rcombs> also I wonder if you can use macros with local labels [08:50:01 CET] <rcombs> some genius decided those names had to be numbers and frwwwwwaaaaaaah why the hell [09:45:16 CET] <mateo`> JEEB: great and thanks for testing. If you have problematic samples, let me know (I'll push a new branch (-v4) during the day) [09:52:31 CET] <JEEB> mateo`: basically just feeding stuff like high 10 profile and seeing if the thing fails or not. my oneplus one handles it properly and I can fall back, nexus 10 on the other hand goes *poof* [09:52:36 CET] <JEEB> so I guess we need sanity checking somewhere [09:52:55 CET] <JEEB> like checking the profile and/or bit depth | chroma subsampling [09:56:00 CET] <mateo`> JEEB: does it fail when in the decoder init function ? or when you actually try to decode a frame ? [09:57:04 CET] <JEEB> I think during the latter... although I will have to confirm. it's not my device so I don't have it on hand right now :) [10:10:17 CET] <cone-912> ffmpeg 03Muhammad Faiz 07master:d1401cb1d05c: avfilter/avf_showcqt: optimize draw routines [10:22:30 CET] <kierank> Shall I buy an rpi3 [10:22:38 CET] <kierank> And expose it? [10:32:41 CET] <atomnuker> did they hook up the wifi on the usb bus as well? [10:37:45 CET] <jkqxz> Not sure it's worth pursuing yet: "At launch, we are using the same 32-bit Raspbian userland that we use on other Raspberry Pi devices; over the next few months we will investigate whether there is value in moving to 64-bit mode.". [10:37:47 CET] <wbs> the official distro (raspbian) only seems to be 32 bit so far (and they'll look into whether it'd make sense to make it available as 64 bit as well); they didn't provide separate armv7 stuff when the rpi2 was released (since there's quite little extra benefit to recompiling everything for v7), but for 64 bit it might matter more [10:38:07 CET] <jkqxz> Heh. [10:38:19 CET] <wbs> but otoh I guess there'll be other distros available in 64 bit mode soon [10:41:31 CET] <jkqxz> It's not clear that they've made a kernel which runs in 64-bit mode for the SoC at all yet, so that could be further away than you might hope. [10:41:32 CET] <av500> they will stay compatible to pi1 forever [10:42:17 CET] <wbs> av500: well, for v6 vs v7 it makes sense, too little gain for duplicating everything [10:43:18 CET] <av500> think of the users! [10:44:31 CET] <wbs> jkqxz: the new images and raspberrypi-firmware packages (that do contain other files named rpi-3) don't contain any new kernel, so that might very well also be the case [10:55:15 CET] <kierank> wbs: I never used raspbian [10:55:32 CET] <kierank> on the pi2, just used ubuntu (almost) vanilla [11:00:46 CET] <wbs> right [11:13:02 CET] <cone-912> ffmpeg 03Clément BSsch 07master:98084adccf14: build: add --install-name-dir=DIR Darwin option [11:16:40 CET] <rcombs> >no out-of-order execution on RPi3 [11:17:57 CET] <wbs> rcombs: where are you reading that? [11:18:04 CET] <rcombs> https://en.wikipedia.org/wiki/Comparison_of_ARMv8-A_cores [11:18:12 CET] <rcombs> it's a Cortex-A53 [11:19:02 CET] <wbs> yeah, that's the one used in almost all low-cost boards; the hikey that ubitux got, the dragonboard that I have, and the pine64 [11:20:18 CET] <wm4> same gpu, boring [11:20:25 CET] <av500> cheap chips are cheap [11:20:27 CET] <wm4> (though faster) [11:20:47 CET] <rcombs> inb4 the GPU OS is somehow even shittier than on the pi2 [11:21:06 CET] <wm4> certainly the same [11:22:38 CET] <rcombs> hey they could ship a new firmware version for it [11:22:42 CET] <rcombs> that deadlocks 50% faster [11:24:08 CET] <wm4> to be fair at least their firmware devs are responsive [11:24:27 CET] <wm4> they could be all like LOL WE DONT CARE and not even have a bug tracker [11:24:31 CET] <rcombs> that CABAC buffer-size bug has been sitting there for months [11:24:48 CET] <JEEB> ok, ordered my rpi3 [11:33:56 CET] <ubitux> still can't plug a gtx 950 on the rpi :( [11:34:06 CET] <JEEB> :D [11:34:06 CET] <nevcairiel> being responsive and actually fixing glaring problems are two different things =p [11:40:42 CET] <JEEB> I wonder if rpi3 will have UEFI [11:40:56 CET] <JEEB> since some arm64 boards have it (at least the magical AMD ones) [11:45:56 CET] <wbs> I'm pretty sure it won't; it will work and behave just as the old ones for all practical matters [11:52:30 CET] <JEEB> ok [12:00:17 CET] <cone-912> ffmpeg 03Carl Eugen Hoyos 07master:c0ecc597fa96: lavf/img2dec: Skip SOS when auto-detecting jpeg. [12:43:24 CET] <cone-912> ffmpeg 03Carl Eugen Hoyos 07master:4e05a12a41f4: lavc/pcxenc: Update format description link. [15:05:41 CET] <mateo`> hello there, i'm looking for a way to pass a pointer to a protocol via the options of avformat_open_input but AVDictionary only handle strings and int64_t. [15:06:02 CET] <Daemon404> to what end [15:06:05 CET] <Daemon404> sounds like an XY problem [15:06:13 CET] <nevcairiel> passing pointers through AVOptions is not something that should ever be done [15:07:07 CET] <mateo`> i'm looking for a way to make android content uris support work without providing a public api to set the android application context (the pointer i'm talking about) [15:07:34 CET] <nevcairiel> rather introduce some type-safe API than passing pointers through some generic options interface [15:07:36 CET] <mateo`> in short, i need this particular pointer to be able open such uris [15:08:07 CET] <wm4> I keep wondering why there's no mechanism to do special format or codec specific things [15:08:12 CET] <wm4> only AVOptions [15:08:24 CET] <wm4> (and to some degree side-data) [15:09:20 CET] <Daemon404> doesnt the ffurl stuff already use the opaque pointer anyway [15:11:29 CET] <J_Darnley> How big are your pointers if you can't fit them in int64_t? [15:12:47 CET] <nevcairiel> casting pointers an integer type, a signed type at that, and back is first grade evil and should never be allowed [15:15:19 CET] <Daemon404> its illegal afaik [15:15:57 CET] <mateo`> J_Darnley: they are either of size 4 or 8, so it's likely to endup with a lot of really bad preproc [15:16:30 CET] <J_Darnley> What's the term? "type pun"? [15:17:07 CET] Action: J_Darnley stops offering bad suggestions [15:17:36 CET] <BBB> michaelni: 6853e40106cac769f0641183ea0bdd530ae9a0a1 is a disgusting hack [15:17:41 CET] <BBB> michaelni: what is the actual bug? [15:18:02 CET] <Daemon404> why is r_frame_rate still around anyway [15:18:03 CET] <BBB> michaelni: is it the invisible (altref) frames having identical timestamps as the frames before/after them? [15:19:31 CET] <nevcairiel> BBB: nah its just the same old story, people abuse the default duration field for frame rate, but the semantic of that field promises no such thing [15:19:35 CET] <wm4> BBB: welcome to ffmpeg [15:20:02 CET] <BBB> nevcairiel: so get rid of reading that field and detect framerate using average delta semantics [15:20:21 CET] <Daemon404> avg_frame_rate exists [15:20:22 CET] <BBB> nevcairiel: I dont understand why we read the (obsolete) fps field in mkv files if the defautl software aborts on that field [15:20:36 CET] <wm4> average framerate is 100% useless [15:20:37 CET] <Daemon404> BBB, r_frame_rate was removed from libav entirely [15:20:39 CET] <nevcairiel> Daemon404: honestly the values in avg_frame_rate are mostly crap [15:20:52 CET] <Daemon404> nevcairiel, i wrote my own library for frmaerate at work [15:20:57 CET] <Daemon404> that consumes all pts/dts [15:20:58 CET] <nevcairiel> Daemon404: yes and it was removed for the same reason most things are done in libav, because its easier [15:21:03 CET] <BBB> my own library for fps" [15:21:05 CET] Action: BBB cries [15:21:11 CET] <nevcairiel> "everything can be vfr, so stop pretending" [15:21:20 CET] <Daemon404> BBB, it has some statistical analysis for vfr crap [15:21:23 CET] <BBB> did you hear that story about that guy writing his own library for rtmp and rtsp and xyz and abc? [15:21:24 CET] <nevcairiel> that 99% of all content is actually cfr is beyond their understanding [15:21:24 CET] <Daemon404> to determine the 'best' cfr fps [15:21:28 CET] <Daemon404> its nothing special [15:21:30 CET] <BBB> ALL THE SOFTWARE DIED [15:22:00 CET] <Daemon404> BBB, ffmpeg can never so framerate correctly [15:22:05 CET] <Daemon404> for the same reason it can never seek correctly [15:22:07 CET] <Daemon404> it has to be indexed. [15:22:11 CET] <Daemon404> s/so/do/ [15:23:02 CET] <nevcairiel> i dont care much about perfect accurate seeks, what works right now is good enough for me, i do care however about decent estimates of cfr frame rates, and avg_frame_rate just doesnt work [15:23:20 CET] <nevcairiel> r_frame_rate has much better values in so many cases [15:23:21 CET] <Daemon404> nevcairiel, i should check, but im certain we get a lot more than 1% cfr uploads [15:23:21 CET] <Daemon404> er vfr [15:23:22 CET] <kierank> nevcairiel: are you saying in libav there is no way to get framerate any more? [15:23:51 CET] <nevcairiel> Daemon404: maybe 2%, big deal =p any commercial consumer content is cfr, which is my main focus [15:24:11 CET] <Daemon404> my focus is user created content which has a much larger percentage of insane crap [15:24:15 CET] <Daemon404> so ;) [15:24:22 CET] <wm4> the only thing I use container framerate is for unrounding timestamps anyway [15:24:22 CET] <michaelni> 6853e40106cac769f0641183ea0bdd530ae9a0a1 <-- the bug is that the "average fps" set by the demuxer is complete wrong (1000fps IIRC) [15:24:31 CET] <nevcairiel> and playback itself obeys timestamps, the fps is used for other means [15:24:37 CET] <nevcairiel> like telling the screen which refresh rate to use [15:24:42 CET] <wm4> and that [15:24:43 CET] <nevcairiel> if its entirely off, weird things happen [15:24:57 CET] <Daemon404> IME, r_frame)rate and avg_frame_rate are both wrong just as often [15:25:01 CET] <nevcairiel> kierank: well they have avg_frame_rate, but its more often wrong than r_frame_rate [15:25:14 CET] <kierank> avg_frame_rate is useless [15:25:19 CET] <kierank> I want the framerate in the codec header [15:25:31 CET] <nevcairiel> thats probably codec->time_base [15:25:38 CET] <Daemon404> isnt that being removed [15:26:21 CET] <durandal_1707> they gonna remove everything [15:26:24 CET] <wm4> the timebase isn't the framerate [15:27:06 CET] <nevcairiel> wm4: for any modern mpeg codecs the codec timebase is the frame rate info in the codec headers, if its set at all [15:27:30 CET] <nevcairiel> (not to be confused with the stream timebase) [15:27:32 CET] <wm4> "mpeg codecs" what does that even mean [15:27:38 CET] <wm4> we're talking about containers, right [15:27:39 CET] <nevcairiel> h26x :p [15:27:42 CET] <wm4> not codecs [15:27:46 CET] <nevcairiel> no, codecs now [15:27:48 CET] <nevcairiel> keep up! [15:27:48 CET] <nevcairiel> :D [15:28:40 CET] <nevcairiel> any good encode will likely include such information, since bitrate distribution needs to know the fps anyway to work properly [15:29:19 CET] <Daemon404> x264 haves vfr ratecontrol bruh [15:29:22 CET] <Daemon404> has* [15:29:36 CET] <nevcairiel> well sure, but if you are smart you set it to cfr [15:29:42 CET] <nevcairiel> at least if your content is that [15:29:48 CET] <Daemon404> ofc [15:29:49 CET] <kierank> I regret writing vfr ratecontrol [15:50:58 CET] <cone-912> ffmpeg 03Carl Eugen Hoyos 07master:8c5092912b19: lavf: Add pcx auto-detection. [15:53:09 CET] <durandal_1707> anyone working on codecpar? [15:56:14 CET] <Daemon404> i plan to merge up until TEP2 today [15:56:23 CET] <Daemon404> then i request nevcairiel's help. [16:11:42 CET] <ubitux> Daemon404: cool! [16:30:53 CET] <cone-912> ffmpeg 03Anton Khirnov 07master:dc6527ed908e: nutenc: do not use AVCodecContext.frame_size [16:30:54 CET] <cone-912> ffmpeg 03Derek Buitenhuis 07master:14a69ae60c64: Merge commit 'dc6527ed908e4d330738f139074455ffbe56a2de' [16:37:17 CET] <cone-912> ffmpeg 03Anton Khirnov 07master:5efd91284e56: avprobe: do not call avio_close() on a custom context [16:37:18 CET] <cone-912> ffmpeg 03Derek Buitenhuis 07master:39fdffa73677: Merge commit '5efd91284e56d444139ed811671c59a129bbb92f' [16:39:35 CET] <cone-912> ffmpeg 03Anton Khirnov 07master:7fbb3b5b9857: lavf: use the io_open callbacks for files opened from open_input() as well [16:39:37 CET] <cone-912> ffmpeg 03Derek Buitenhuis 07master:04747c5a73af: Merge commit '7fbb3b5b9857276b4cd17b2a530c7e0880d2bc0a' [16:43:28 CET] <cone-912> ffmpeg 03Anton Khirnov 07master:d082078a88da: dashenc: eliminate ffurl_* usage [16:43:29 CET] <cone-912> ffmpeg 03Anton Khirnov 07master:e192cd9ce2b5: smoothstreamingenc: do not open the files as read+write [16:43:30 CET] <cone-912> ffmpeg 03Derek Buitenhuis 07master:48847ee3577f: Merge commit 'd082078a88da3b3e926197d0d2aa9fa322123b76' [16:43:31 CET] <cone-912> ffmpeg 03Derek Buitenhuis 07master:6a8d05cb4d15: Merge commit 'e192cd9ce2b51c2e6919f2a78b1ce53e0024e728' [16:44:46 CET] <Daemon404> hmm [16:45:09 CET] <Daemon404> trying to figure out exactly wtf this does: https://git.libav.org/?p=libav.git;a=commitdiff;h=225e84e74544062706c0159ec0... [16:45:17 CET] <Daemon404> i dont know what it means by child item in child playlists [16:45:27 CET] <Daemon404> ^ wm4 [16:46:18 CET] <wm4> uh doesn't this break nested playlists? [16:46:36 CET] <wm4> or maybe it's only for leaf files, which are expected to contain .ts data [16:46:38 CET] <nevcairiel> no, nested playlists are not handled by nested IO contexts [16:46:45 CET] <nevcairiel> but by the demuxer directly [16:46:50 CET] <wm4> hm true [16:47:09 CET] <nevcairiel> so the second, it only applies for actual leaf files, which are assumed to be plain ts or mp3 or whatever [16:47:57 CET] <Daemon404> [15:46] <+wm4> uh doesn't this break nested playlists? <-- this was exactly my thought [16:48:11 CET] <wm4> should be fine though [16:48:28 CET] <Daemon404> im still not sure what files its referring to [16:48:33 CET] <Daemon404> like how would it look.occur [16:49:11 CET] <nevcairiel> if it refers to a concat url, concat would open further files, which would be blocked by this [16:49:19 CET] <wm4> yep [16:49:23 CET] <Daemon404> ah [16:49:30 CET] <Daemon404> so LGTM to merge? [16:49:33 CET] <wm4> yeah [16:49:41 CET] <Daemon404> ok [16:50:19 CET] <nevcairiel> at least i hope concat uses io_open, i havent followed how widespread that thing is =p [16:50:58 CET] <Daemon404> hmm im not sure [16:51:24 CET] <Daemon404> it seems to use avformat_open_input [16:51:34 CET] <Daemon404> concat, that is [16:51:57 CET] <wm4> as long as io_open is passed down, it should work, right? [16:52:02 CET] <cone-912> ffmpeg 03Anton Khirnov 07master:225e84e74544: hls: disallow opening nested files in child demuxers [16:52:03 CET] <cone-912> ffmpeg 03Derek Buitenhuis 07master:f1e7c42f08d0: Merge commit '225e84e74544062706c0159ec0737b0e1d40915f' [16:52:11 CET] <Daemon404> wm4, believe so [16:52:29 CET] <Daemon404> mind you, it wont get to concat right now unless you explicitly add it to teh whitelist [17:08:10 CET] <wm4> lol someone posts a final version of a patch, and the bikeshedders are suddenly all over irrelevant parts of the code for minor reasons [17:20:18 CET] <JEEB> herp [17:22:29 CET] <ubitux> wm4: sorry :D [17:22:40 CET] <ubitux> wm4: don't forget to minor bump + Changelog when applying [17:23:05 CET] <wm4> seems like the author intends to redo the string lookup part [17:23:14 CET] <Daemon404> i'd be grateful if you could wait 5 mins or so to push so i dont have to rebase this tedious merge i just did [17:23:17 CET] <Daemon404> (running fate right now0 [17:25:41 CET] <Daemon404> ugh wtf [17:25:51 CET] <Daemon404> one of our tests relies on registered an 3rd party protocol [17:25:58 CET] <Daemon404> (this is no longer possible after the merge) [17:26:25 CET] <Daemon404> what do i even do here [17:26:31 CET] <Daemon404> (this was never public api!) [17:26:41 CET] <wm4> what where [17:26:47 CET] <Daemon404> bottom of async.c [17:26:53 CET] <Daemon404> look in main [17:27:20 CET] <wm4> uh [17:27:52 CET] <wm4> michaelni: opinion? [17:28:04 CET] <Daemon404> this test looks pretty.. wrong [17:28:25 CET] <wm4> I'm wondering what it tests [17:30:28 CET] <nevcairiel> its a fake protocol to allow testing the async protocl without an actual file or so being used [17:30:38 CET] <nevcairiel> ie. a void data source [17:30:41 CET] <Daemon404> but why [17:30:44 CET] <Daemon404> we have tons of files to use [17:31:28 CET] <nevcairiel> yeah it should probably just use a file, or just generate one if it needs a particular pattern [17:31:29 CET] <wm4> it makes no sense to me [17:31:42 CET] <wm4> it doesn't even return data (even though it has a "size") [17:31:51 CET] <nevcairiel> actually it does [17:31:58 CET] <nevcairiel> it writes stuff into buf [17:32:03 CET] <nevcairiel> programmatically [17:32:03 CET] <jamrial> it's pretty recent, and written by Zhang Rui. maybe disable it for now and email him about it? [17:32:15 CET] <wm4> is he on irc? [17:32:21 CET] <Daemon404> av_dict_set_int(&opts, "async-test-read-error", -10000, 0); [17:32:27 CET] <Daemon404> looks like it is primarily there to cover error paths [17:32:41 CET] <nevcairiel> it also tests normal reads, seeks, etc [17:32:50 CET] <Daemon404> sure but you can use a normal file for that [17:34:28 CET] <Daemon404> also [17:34:31 CET] <Daemon404> hmm [17:34:54 CET] <Daemon404> eh... what do [17:35:07 CET] <wm4> disable test, continue [17:36:06 CET] Action: Daemon404 is wary of people ripping his head off [17:36:27 CET] <wm4> be a hydra [17:36:33 CET] <jamrial> can this test even fail? [17:36:43 CET] <jamrial> as in, report as failed [17:38:06 CET] <nevcairiel> it outputs text, if thats diffed, maybe? [17:39:26 CET] <Daemon404> yes [17:40:39 CET] <Daemon404> 810fbd8933031d58764190f58dff3fc6986cf866 seems error was added later [17:46:32 CET] <Daemon404> nevcairiel / wm4 / jamrial - disable, merged, and mail zhang then? [17:46:37 CET] <Daemon404> merge* [17:48:51 CET] <cone-912> ffmpeg 03Timothy Gu 07master:e3461197b1ff: x86/vc1dsp: Split the file into MC and loopfilter [17:49:39 CET] <wm4> yeah [17:51:55 CET] <cone-912> ffmpeg 03Anton Khirnov 07master:2758cdedfb7a: lavf: reorganize URLProtocols [17:51:56 CET] <cone-912> ffmpeg 03Derek Buitenhuis 07master:9c75148e6ebc: Merge commit '2758cdedfb7ac61f8b5e4861f99218b6fd43491d' [17:52:01 CET] <Daemon404> emailing zhang now [17:56:07 CET] <Daemon404> mailed [17:56:10 CET] <Daemon404> michaelni, i CC'd you. [18:03:15 CET] <cone-912> ffmpeg 03Anton Khirnov 07master:0fa00d05911a: lavf: move avio_enum_protocols() to protocols.c [18:03:16 CET] <cone-912> ffmpeg 03Anton Khirnov 07master:7d61dc95d741: lavf: move urlcontext_child_class_next() to protocols.c [18:03:17 CET] <cone-912> ffmpeg 03Derek Buitenhuis 07master:8fd5342463b0: Merge commit '0fa00d05911aa8043ecad8dead4a73cab7faadf6' [18:03:18 CET] <cone-912> ffmpeg 03Derek Buitenhuis 07master:53025fe1870a: Merge commit '7d61dc95d741ca134d59b1f34c4e10c4c4e36f56' [18:13:14 CET] <michaelni> Daemon404, in libavformat/Makefile theres still TESTPROGS = async [18:13:34 CET] <Daemon404> make fate didnt complain [18:13:42 CET] <Daemon404> i should comment it out i suppose [18:13:56 CET] <michaelni> if you want to disable it yes [18:16:11 CET] <cone-912> ffmpeg 03Derek Buitenhuis 07master:95cdc0a5c658: avformat: Remove async from TESTPROGS [18:32:45 CET] <atomnuker> whoa, we have a pcx encoder? [18:32:59 CET] <Daemon404> if there's a format used in 1995, we have it! [18:33:23 CET] <nevcairiel> 1985, please [18:33:44 CET] <Daemon404> damn. [18:34:18 CET] <nevcairiel> those old formats are generally so simple that supporting them is pretty trivial [18:34:20 CET] <Daemon404> interesting... pcx uses per-line planes [18:34:25 CET] <Daemon404> or whatever teh right term is [18:35:05 CET] <nevcairiel> its a bit uncommon, but yes [18:35:08 CET] <atomnuker> it was used up until 1998 (Diablo 1 and StarCraft used it) [18:35:11 CET] <nevcairiel> the planes are interleaved row by row [18:35:47 CET] <nevcairiel> the first formats probably only had 1 plane, apparently it can be paletted [18:36:38 CET] <nevcairiel> 16 color screens, yo [18:37:34 CET] <Daemon404> why would they even use a format [18:37:43 CET] <Daemon404> games that old probably hardcoded it [18:37:47 CET] <Daemon404> with some crafty storage [18:37:55 CET] <Daemon404> (as an array) [18:38:09 CET] <nevcairiel> saves effort to just use an existing format [18:38:19 CET] <nevcairiel> games have a whole lot of artwork [18:38:27 CET] <Daemon404> ive seen lots of old game asm that included a tool to convert to a .asm file [18:38:40 CET] <Daemon404> NES and such, iirc [18:38:47 CET] <nevcairiel> consoles might be different [18:38:53 CET] <nevcairiel> more constrained setup [18:39:16 CET] <Daemon404> iirc the NES could have 16 colors per NxN block or something like that [18:39:18 CET] <Daemon404> or was that SNES [18:39:22 CET] <Daemon404> it was a weird tiled thing [18:45:21 CET] <wm4> clearly ffmpeg should have a native pixfmt for this [18:45:29 CET] <wm4> including codec copy to nut [18:53:20 CET] <atomnuker> btw a few days ago someone (not courmisch) removed the ffmpeg version block from VLC [18:55:21 CET] <wm4> yes it was linked here [19:20:49 CET] <cone-912> ffmpeg 03Anton Khirnov 07master:832a202c47a2: protocols: make the list of protocols static [19:20:50 CET] <cone-912> ffmpeg 03Derek Buitenhuis 07master:bb8cc89b2986: Merge commit '832a202c47a246ed15e3edc6b05dfcfa7d82c4b2' [19:24:43 CET] <atomnuker> can avfilter_graph_create_filter be called with a NULL for the args string? [19:30:33 CET] <atomnuker> every example I've come across uses a string + snprintf to set time base, pixel format, etc. [19:30:42 CET] <atomnuker> surely there's a better way [19:31:09 CET] <wm4> avoption probably works [19:31:13 CET] <wm4> if you find that "better" [19:31:53 CET] <wm4> also, recently something was added to pass them in a struct [19:32:10 CET] <wm4> av_buffersrc_parameters_set() [19:36:03 CET] <cone-912> ffmpeg 03Michael Niedermayer 07master:a6cd817a544e: avformat/msf: Also check the codec tag in probing [19:36:04 CET] <cone-912> ffmpeg 03Michael Niedermayer 07master:4899c02c385f: avformat/protocols: Fix ff_urlcontext_child_class_next() [19:43:31 CET] <cone-912> ffmpeg 03Anton Khirnov 07master:cae448cfbf31: aviobuf: add a private data struct for avio_open()ed contexts [19:43:32 CET] <cone-912> ffmpeg 03Derek Buitenhuis 07master:b9aa4ccff515: Merge commit 'cae448cfbf31d492cba782bc64fc4eed556ed83d' [20:01:02 CET] <darkapex> Congrats, FFmpeg is selected for GSoC'16 :) [20:01:22 CET] <wm4> now we only need some applicants [20:01:31 CET] <darkapex> I wish to participate this time, so really good news for me [20:03:01 CET] <wm4> awesome [20:03:05 CET] <wm4> which project? [20:14:02 CET] <darkapex> ffmpeg, the TrueHD encoder task [20:15:25 CET] <JEEB> sounds like fun [20:15:37 CET] <JEEB> at least it's lossless so you would know when you fail and when you succeed [20:16:09 CET] <darkapex> Yes it would be fun [20:16:59 CET] <BBB> atomnuker: so does that mean ffmpeg+vlc is all cuddly cuddly again? [20:17:32 CET] <BBB> whos mentor for that project? [20:17:51 CET] <Daemon404> i dont think anyone is listed [20:18:13 CET] <Daemon404> oh. it's atomnuker [20:18:25 CET] <JEEB> cool [20:26:56 CET] <wm4> BBB: yes, except it's really a bipolar abuse relationship which will end in tears [20:27:01 CET] <wm4> *abusive [20:27:20 CET] <BBB> everything is abusive nowadays [20:27:23 CET] <BBB> ohwell [20:27:29 CET] <BBB> anyone want to review my abusive bsf patch? [20:28:01 CET] <cone-912> ffmpeg 03James Almer 07master:3acbb91d1359: fate: fix fate-libavformat target [20:28:09 CET] <T4ng10r> hi [20:28:24 CET] <T4ng10r> is drawtext extension pts:gmtime working? [20:29:55 CET] <T4ng10r> ffmpeg -i S4310001.MP4 -vf 'drawtext=fontfile=Verdana.ttf:expansion=normal:text='\''%{pts\:gmtime\:0\:2015-11-25 20\\\:15\\\:24}'\'':r=30:x=(w-tw)/2:y=h-(2*lh):fontcolor=white:box=1:boxcolor=0x000000@1' -strict [20:29:55 CET] <T4ng10r> -2 -y out.mp4 [20:30:00 CET] <T4ng10r> isn't working [20:32:08 CET] <wm4> T4ng10r: wrong channel [20:33:55 CET] <J_Darnley> We aren't being very helpful over in #ffmpeg [20:36:09 CET] <T4ng10r> I understand that this feature - pts and gmtime are features introduced in 2.9 [20:36:13 CET] <T4ng10r> which is in development phase [20:36:20 CET] <T4ng10r> thats Why I'm asking here [20:36:36 CET] <T4ng10r> ffmpeg -i S4310001.MP4 -vf 'drawtext=fontfile=Verdana.ttf:expansion=normal:text=%{pts\\:gmtime\\:0\\:2015-11-25 20\\\\\\:15\\\\\\:24}:r=30:x=(w-tw)/2:y=h-(2*lh):fontcolor=white:box=1:boxcolor=0x000000@1' -strict -2 -y out.mp4 [20:37:02 CET] <T4ng10r> this command uses provided DATATIME but it's NOT chaning [20:38:06 CET] <T4ng10r> I can't find in code enough information to understan WHY it's not working [20:40:17 CET] <michaelni> Daemon404, last merge broke at least some hls cases [20:40:20 CET] <michaelni> ./ffmpeg -f lavfi -i "aevalsrc=cos(2*PI*t)*sin(2*PI*(440+4*t)*t)::d=20" -f segment -segment_time 10 -map 0 -strict -2 -codec:a aac -segment_list list.m3u8 out-%03d.mp4 [20:40:28 CET] <michaelni> ./ffmpeg -i list.m3u8 [20:40:30 CET] <Daemon404> michaelni, name some [20:40:36 CET] <michaelni> the 2nd command sefaults [20:40:42 CET] <Daemon404> hmm [20:40:51 CET] <Daemon404> as in the very last one i pushed? [20:41:46 CET] <michaelni> yes, i thnk so, heres gdb backtrace: http://pastebin.com/jQxup3kv [20:42:21 CET] <Daemon404> i think i know why [20:42:34 CET] <Daemon404> hls abused the opaque pointer in an unsafe way [20:42:36 CET] <Daemon404> i believe [20:42:55 CET] <wm4> could this be turned into a FATE test? [20:43:15 CET] <Daemon404> building... [20:43:40 CET] <michaelni> wm4, that would be great [20:43:59 CET] <Daemon404> i think i know how to fix it, but it's ugly regardless [20:44:53 CET] <michaelni> wm4, the aac probably should be replaced by some integer based codec for fate [20:56:32 CET] <Daemon404> michaelni, whats the correct output for those commands [20:57:04 CET] <Daemon404> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x3326600] stream 0, offset 0x2c: partial file [20:57:05 CET] <Daemon404> list.m3u8: Invalid data found when processing input [20:57:12 CET] <Daemon404> no crash now, but this is output [20:57:39 CET] <Daemon404> using .ts doesnt haver that [20:57:46 CET] <Daemon404> so i assume you may have made a mistake using mp4 for hls? [20:58:57 CET] <Daemon404> http://sprunge.us/MEfR <-- fix [20:59:00 CET] <Daemon404> someone should OK it [20:59:04 CET] <Daemon404> incase i screwed up [21:03:16 CET] <wm4> ugly, but I guess ok... I don't see where hlsopts is actually set though [21:05:38 CET] <michaelni> Daemon404, the same errors occur with old "good" version, the testcase is from https://trac.ffmpeg.org/ticket/2148 so its author must have made a mistake [21:06:20 CET] <Daemon404> michaelni, ok [21:06:37 CET] <Daemon404> i dont think mp4 is valid in hls... [21:07:39 CET] <ubitux> heh, a guy from opensubtitles might give me a shitton of subtitles samples [21:07:44 CET] <ubitux> i'm going to have some fun :3 [21:08:08 CET] <wm4> ubitux: there are already some known unfixed samples [21:08:18 CET] <wm4> like ASS with whitespace or no strict script header [21:08:47 CET] <ubitux> ah? and you didn't tell me! [21:09:01 CET] <ubitux> didn't rcombs locally fixed those? [21:10:18 CET] <cone-912> ffmpeg 03Derek Buitenhuis 07master:9f9ed79d4cb4: hls: Add and use a memebr of AVIOInternal rather than abuse opaque [21:10:24 CET] <Daemon404> bloody typos [21:11:08 CET] Action: JEEB pats Daemon404 [21:11:26 CET] <ubitux> blooyd tpoys [21:55:16 CET] <cone-912> ffmpeg 03Michael Niedermayer 07master:0be09f54fb2a: avcodec: Add utils test [21:55:17 CET] <cone-912> ffmpeg 03Michael Niedermayer 07master:380fd32a8ccd: fate: add libavcodec utils test [22:17:15 CET] <ashish1231> Hi [22:17:43 CET] <ashish1231> I want to be a part of ffmpeg in gsoc 2016 [22:18:19 CET] <ashish1231> Plwase tell me how can I contribute [22:20:56 CET] <ashish1231> Thanks [22:22:51 CET] <ashish1231> I think this link is for outreachy [22:24:17 CET] <omerjerk> this one is for GSoC - https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016 [22:24:30 CET] <omerjerk> that was the automatic message by the bot. [22:25:17 CET] <iive> ashish1231: michael just edited that page. that's why the bot sent that message :) [22:25:42 CET] <ashish1231> How can I contact the mentor? [22:32:37 CET] <iive> ashish1231: i looked at the page, it looks like all available mentors are given with contacts... [22:32:51 CET] <iive> ashish1231: what task do you have in mind? [22:34:01 CET] <ashish1231> I know c++ and c [22:35:21 CET] <ashish1231> So i am thinking to go with improve selftest coverage [22:35:49 CET] <ashish1231> I am also familiar with git [22:38:04 CET] <iive> so you want the "fuzzing testsuite for FFmpeg" task. [22:38:32 CET] <iive> Mentor: Kieran Kunhya (kierank in #ffmpeg-devel on Freenode IRC, kieran at kunhya dot com) [22:38:58 CET] <iive> the last thing is email [22:39:08 CET] <ubitux> speaking of coverage, if someone is up to add a video func comparison to fate that would be useful for testing float filters [22:39:19 CET] <ubitux> that is, compare video output with a threshold [22:39:46 CET] <ashish1231> Yes [22:47:08 CET] <omerjerk> Hey I've been looking into ALS codec source since a couple of days. [22:47:32 CET] <omerjerk> The qualification task says to add the support for IEEE 32-bit floating point numbers to the decoder. [22:47:44 CET] <omerjerk> I've read the papers regarding that already. [22:48:03 CET] <omerjerk> The code seems a bit tough though. (not that I'm bad with C) [22:48:20 CET] <omerjerk> so, any tips regarding that would be really appreciated. [23:00:51 CET] <durandal_1707> omerjerk: first study code, ask if something is not clear [23:11:49 CET] <jamrial_> atomnuker: yeah, but they didn't backport it to vlc-2.2 branch yet [23:24:25 CET] <michaelni> wm4, do you want to mentor in gsoc2016 (or rather should i send you an invite? iam not sure we have to invite all mentors by hand or they can register themselfs like in previous years) [23:24:57 CET] <michaelni> i think i invited all that clearly volunteered but i probably forgot someone [23:30:12 CET] <wm4> michaelni: I don't know if there's any project I could mentor? [23:32:17 CET] <michaelni> well, ill send you an invite ... [23:39:13 CET] <darkapex> michaelni: Should we have a qualification task status wiki page like last year? [23:39:56 CET] <michaelni> that would be good [23:45:31 CET] <atomnuker> wm4: you wouldn't want to mentor someone to improve the mkv (de)muxer in ffmpeg? add usable chapters support? [23:45:53 CET] <atomnuker> just a suggestion, I know mpv still uses its own mkv demuxer [23:48:44 CET] <wm4> atomnuker: rcombs has a wip patch for ordered chapters [23:49:33 CET] <wm4> (useful for other API users, but I think at this point I'd rather prefer if mpv could just get the OC metadata from lavf) [23:50:42 CET] <rcombs> wm4: exporting the segment UID for a chapter would be trivial [23:50:54 CET] <rcombs> since chapters have a metadata dict [23:51:57 CET] <wm4> it probably even exports it already [23:52:00 CET] <wm4> didn't check [23:52:32 CET] <durandal_1707> I bet nobody will pick hardest project [23:53:00 CET] <darkapex> Cool, I'll create it [23:56:35 CET] <T4ng10r> hi [23:56:52 CET] <T4ng10r> how can i debug ie. vf_drawtext,c ? [23:57:08 CET] <T4ng10r> when i use cgdb I can't place breakpoint in this file [23:59:38 CET] <T4ng10r> i see - those are independent libraries [23:59:58 CET] <wm4> atomnuker, rcombs: do you think there's enough stuff for a mkv project? [00:00:00 CET] --- Tue Mar 1 2016