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

[burek]

[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/20160229010139 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/original/08%20-%20Migrating%20code%20from%20ARM%20to%20ARM64.pdf 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=225e84e74544062706c0159ec0737b0e1d40915f
[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 at 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 at 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