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

[burek]

[00:03:50 CET] <cone-585> ffmpeg 03Michael Niedermayer 07master:df36257a5356: swscale/input: Fix GBRAP16 input
[00:03:50 CET] <cone-585> ffmpeg 03Michael Niedermayer 07master:67e5bd0c501f: swscale/utils: Fix chrSrcHSubSample for GBRAP16
[01:26:17 CET] <proxima> Explain about the qualification task(about fixing the crash using zzuf) mentioned for project Create a fuzzing testsuite for FFmpeg for Outreachy 2016. Please clear what kind of crash i.e. software or a simple file or any other specification?
[01:30:09 CET] <iive> proxima: is that question to michaelni  or somebody else?
[01:31:00 CET] <Compn> iive : its to clarify the task
[01:31:13 CET] <michaelni> proxima, ask kierank 
[01:31:29 CET] <Compn> proxima : crashes and memory leaks i'd guess
[01:31:47 CET] <Compn> so it would have to tie in with valgrind
[01:32:23 CET] <Compn> maybe you could assemble the different fuzzing tools, zzuf is one of them
[01:32:46 CET] <proxima> okay, i tested that for a normal exe file. So, just wanted to know if we need to test on any ffmpeg program
[01:33:28 CET] <Compn> probably ffmpeg program only. i dont think we currently fuzz test ffprobe/ffplay/ffserver
[01:33:39 CET] <Compn> much.
[01:33:48 CET] <proxima> thanks, i will contact kierank for further description
[01:33:55 CET] <Compn> no problem
[01:34:15 CET] <proxima> thanks for help
[02:34:07 CET] <Timothy_Gu> Compn: it'd be better if you read the description of the task before replying to students. We are fuzzing with a modified version of an example in doc/ so that we actually end up fuzzing libavcodec/format and not ffmpeg.c
[02:43:20 CET] <cone-585> ffmpeg 03Ganesh Ajjanagadde 07master:e86444b19d0b: lavc/utvideodec: prevent possible signed overflow
[02:44:57 CET] <Timothy_Gu> ethe: the SDL device is supposed to support window resizing: https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/sdl.c#L210
[02:48:36 CET] <Compn> Timothy_Gu : it'd be better if mentors spent some time establishing contacts and communications so students didnt come here and ask me, we are in accord.
[03:27:48 CET] <cone-585> ffmpeg 03Kieran Kunhya 07master:4170a44bbc7b: Add GBRAP12 pixel format
[03:27:49 CET] <cone-585> ffmpeg 03Michael Niedermayer 07master:10fa50c156ea: avcodec/mpeg12dec: Fix missing slice handling without padding
[05:57:44 CET] <proxima> kierank: can you elaborate the qualification task for creating a fuzzing testsuite for FFmpeg
[06:00:15 CET] <Timothy_Gu> proxima: the wiki page says "Compile and run fffuzz and report and (possibly fix) a crash using zzuf or afl-fuzz."
[06:00:51 CET] <Timothy_Gu> the first step is obviously using git to clone the GitHub repo for fffuzz and build it
[06:01:08 CET] <proxima> yeah i have done that, just wanted to know about fuzz part
[06:01:23 CET] <proxima> currently i have tested it on a c program and an exe file
[06:01:39 CET] <Timothy_Gu> ok so have you installed afl yet?
[06:01:40 CET] <proxima> what should be my next step?
[06:01:59 CET] <Timothy_Gu> have you installed afl?
[06:02:01 CET] <Timothy_Gu> http://lcamtuf.coredump.cx/afl/
[06:02:12 CET] <proxima> no i havent done with afl yet. i did with valgrind
[06:02:26 CET] <Timothy_Gu> valgrind is not a fuzzing too
[06:02:27 CET] <Timothy_Gu> *tool
[06:02:42 CET] <Timothy_Gu> it merely checks for correctness in handling memory
[06:02:47 CET] <Timothy_Gu> afl is a "fuzzer"
[06:03:26 CET] <proxima> i followed this tutorial https://fuzzing-project.org/tutorial1.html.I  did it with zzuf. i will attempt it with afl now
[06:03:36 CET] <Timothy_Gu> zzuf works too
[06:04:08 CET] <Timothy_Gu> proxima: I'm not sure if afl works on windows though
[06:04:19 CET] <proxima> i am working on ubuntu 
[06:04:50 CET] <Timothy_Gu> uhm didn't you said you got an exe?
[06:04:59 CET] <Timothy_Gu> well never mind
[06:07:17 CET] <proxima> Okay, and how do we have to submit or report the progress about the task for Outreachy
[06:07:31 CET] <Timothy_Gu> that you gotta ask kierank 
[06:08:28 CET] <proxima> thanks
[06:27:39 CET] <rcombs> nevcairiel: michaelni: doesn't 93d336fb076a8abe33e37251af5475673e716f6d break segment manifests?
[06:28:24 CET] <rcombs> i.e. list files
[08:47:19 CET] <nevcairiel> rcombs: why would it break, it just changes how the filename is allocated
[08:49:04 CET] <rcombs> nevcairiel: `seg->cur_entry` points to the end of a linked list
[08:49:52 CET] <rcombs> say `size` never changes (a common case): `av_reallocp(&seg->cur_entry.filename, size)` will leave `seg->cur_entry.filename` the same, so we just keep writing into the same buffer forever instead of making a new one for each segment
[08:50:57 CET] <nevcairiel> every new segment gets this buffer cloned when its created
[08:51:05 CET] <nevcairiel> its not shared between segments
[08:51:21 CET] <nevcairiel> using realloc just avoids leaking the memory
[08:53:16 CET] <rcombs> ohhhh, I see my mistake
[08:55:25 CET] <rcombs> this was with https://ffmpeg.org/pipermail/ffmpeg-devel/2016-February/189992.html
[08:57:45 CET] <rcombs> sorry, my bad
[09:44:49 CET] <ubitux> is it OK to preload beyond allocated size?
[11:07:55 CET] <ubitux> what can i use to load/dup a byte/word/dword/... into a mm reg?
[11:08:10 CET] <ubitux> that is, something not constant
[11:16:19 CET] <jkqxz> mov* + pshufw for things larger than bytes.  Not sure for a single byte.
[11:20:44 CET] <jkqxz> Probably just dup the byte into a word?  Given pshufb a zero register gives you the right shuffle, but probably you don't want to use SSSE3.
[11:22:26 CET] <ubitux> i'm limited to mmx
[11:23:14 CET] <rcombs> what are you doing on MMX :3
[11:23:37 CET] <ubitux> because i'm porting ancient code
[11:23:44 CET] <ubitux> and it's a nightmare
[11:23:46 CET] <ubitux> :(
[11:24:54 CET] <rcombs> what code
[11:25:02 CET] <wm4> swscale?
[11:25:13 CET] <rcombs> ubitux: btw any chance you're planning on replacing zvbi in the near future
[11:25:52 CET] <ubitux> yes, swscale, yuv to rgb
[11:26:06 CET] <rcombs> wm4: double btw, mpv barfs on zvbi subs because the codec descriptor says it's a text format, but the decoder gives you bitmaps by default (for some reason?????)
[11:26:07 CET] <ubitux> rcombs: not really
[11:26:23 CET] <wm4> rcombs: it can give both, AFAIK
[11:26:28 CET] <ubitux> rcombs: -txt_format option configures for one way or another
[11:26:37 CET] <rcombs> and there's an AVOption to give text instead, but I can't figure out how to specify that in mpv
[11:26:42 CET] <ubitux> the text version is most of the time broken
[11:26:45 CET] <rcombs> since there's no --sd-lavc-o option
[11:26:53 CET] <wm4> rcombs: yeah, you can't
[11:26:55 CET] <rcombs> ubitux: lovely
[11:27:16 CET] <ubitux> rcombs: http://ubitux.fr/pub/pics/_zvbi-shit-happens.jpg
[11:27:16 CET] <wm4> bitmap decoders have to be added explicitly to sd_lavc.c
[11:27:19 CET] <ubitux> stuff like this
[11:27:38 CET] <rcombs> wm4: so I hacked it in lavc to output text by default and now the stream appears to work (`ffmpeg -i file.ts -f ass -` gives normal-looking output), but mpv doesn't display anything
[11:28:05 CET] <rcombs> ubitux: &lovely
[11:28:23 CET] <rcombs> what's that look like rendered as bitmaps?
[11:28:24 CET] <wm4> (I'd welcome an API that'd allow handling text vs. bitmap output more sanely)
[11:31:08 CET] <ubitux> rcombs: no idea, it was a while ago
[12:00:52 CET] <saij123> Hello. I am jahnavi doing my final year of engineering in IIIT hyderabad. I am very much interested in contributing to FFmpeg via outreachy . Could someone guide me how to start the work?
[15:08:30 CET] <Daemon404> i think the first two mails of my 2/2 got caught in spam?
[15:08:40 CET] <Daemon404> they do not show up on pipermail.
[15:19:58 CET] <ubitux> mmh so there is no concept of tb in the codec param thing
[15:20:11 CET] <Daemon404> timebase?
[15:20:52 CET] <ubitux> yeah
[15:21:07 CET] <ubitux> codec timebase, which seems to be used but disappeared
[15:21:12 CET] <Daemon404> wtf is codec timebase
[15:21:16 CET] <Daemon404> and why does it exist
[15:21:44 CET] <Daemon404> (inb4 h264 sei)
[15:22:17 CET] <ubitux> dunno but it's been in use
[15:22:35 CET] <Daemon404> that is not a valid answer
[15:22:55 CET] <ubitux> i feel like this merge is going to be problematic if we don't worry about it asap
[15:23:06 CET] <Daemon404> i was planning to merge up to the Big COmmit
[15:23:11 CET] <Daemon404> then Team Effort Time
[15:23:33 CET] <ubitux> i will probably push my subtitles patchset pretty soon btw
[15:23:49 CET] <Daemon404> doesnt affect me ;p
[15:23:57 CET] <ubitux> well actually it does
[15:24:08 CET] <ubitux> because subtitles decoders are using the avctx time base
[15:24:21 CET] <ubitux> (they won't after the patch)
[15:24:34 CET] <Daemon404> yes but where does it (avctx timebase) come from
[15:24:41 CET] <Daemon404> and it sounds dumb as hell to have a tb in avctx
[15:24:44 CET] <ubitux> i don't know
[15:24:48 CET] <Daemon404> you use it but you dont know?
[15:24:50 CET] <Daemon404> A+
[15:25:04 CET] <ubitux> ffmpeg works in mysterious ways
[15:25:06 CET] <ubitux> ;)
[15:25:34 CET] <ubitux> idr, this time rescaling madness has been here for a long time and most of the patchset is about dropping it
[15:25:43 CET] <Daemon404> is this some sort of crappy way of exporting subtitle timestamps with when they have no real demuxer
[15:25:45 CET] <ubitux> bc timestamping doesn't belong in lavc but in lavf so.,
[15:26:09 CET] <ubitux> decoders were duplicating lavf work
[15:26:32 CET] <ubitux> by rescaling timestamps to ASS tb and inserting them as text into the decoded payload
[15:26:49 CET] <Daemon404> is there a problem with just exporting all timestamps with AV_TIME_BASE
[15:26:51 CET] <wm4> <Daemon404> yes but where does it (avctx timebase) come from <- I just set an arbitrary timebase on subtitle converters
[15:29:05 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:c51b2c79a7ba: Allow linking to CUDA dynamically instead of dlopen()ing it at runtime
[15:29:05 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:1f32d01de217: Merge commit 'c51b2c79a7ba084253e892c56dd49ee97115c7de'
[15:30:17 CET] <BtbN> another commit that raises the question "but why?".
[15:30:32 CET] <Daemon404> BtbN, ?
[15:30:40 CET] <BtbN> "Allow linking to CUDA dynamically instead of dlopen()ing it at runtime"
[15:30:42 CET] <BtbN> why?
[15:30:43 CET] <ubitux> we're going to have a bad time with ffserver btw
[15:30:52 CET] <wm4> ubitux: should have dropped it sooner
[15:30:53 CET] <Daemon404> ubitux, ffserver can fuck off and die
[15:31:05 CET] <ubitux> okay
[15:31:06 CET] <Daemon404> it cant even bloody run with public api
[15:31:09 CET] <Daemon404> as it stands.
[15:32:01 CET] <BtbN> "This commit is a no-op. We already have such functionality." I don't think that's true, I'm not aware ffmpeg is able to link against cuda.
[15:32:18 CET] <Daemon404> oh, i misread
[15:32:27 CET] <nevcairiel> BtbN: its one of those pointless things that elinril  likes, for some reason dlopen is offensive to him or something
[15:32:30 CET] <Daemon404> but we still dont wnat to merge anyway
[15:32:34 CET] <Daemon404> nevcairiel, MUH FREEDUMS
[15:32:51 CET] <BtbN> I put in quite some effort to avoid linking against cuda, and even depending on the CUDA SDK.
[15:33:10 CET] <Daemon404> BtbN, it's fine; i didn't merge it
[15:33:30 CET] <BtbN> Yeah, I'm not complaining about the no-op merge, was just a comment regarding the original libav commit.
[15:35:13 CET] <Daemon404> BtbN, great; youre here
[15:35:19 CET] <Daemon404> youre opinion on
[15:35:20 CET] <nevcairiel> i would love to get dlopen support for more things, say like vaapi, so i can build without a hard dep
[15:35:26 CET] <Daemon404> merge / no-merge / re0impl
[15:35:34 CET] <Daemon404> https://git.libav.org/?p=libav.git;a=commit;h=7bc780cd4413f688d3b834037b0f9ddfd6948140
[15:35:36 CET] <BtbN> Of the CUDA-Stuff?
[15:35:37 CET] <Daemon404> https://git.libav.org/?p=libav.git;a=commit;h=ad884d100259e55cb51a4239cd8a4fd5154c2073
[15:35:47 CET] <Daemon404> [..]
[15:35:47 CET] <Daemon404> https://git.libav.org/?p=libav.git;a=commit;h=871d0930d4c8666df5514093beff874acbe5cce0
[15:35:53 CET] <Daemon404> two are cuda, oen is nvenc/cuda
[15:36:45 CET] <BtbN> I'm personaly not a fan of CUDA in ffmpeg, but if the general opinion on it is accepting, I'm fine with it. If it's possible to merge it at all.
[15:36:58 CET] <Daemon404> the first two should not be an issue
[15:37:02 CET] <Daemon404> the latter may be messy
[15:37:17 CET] <BtbN> The one touching nvenc is probably not possible to merge, but if the other two are possible, I'll add the neccesary changed to NVENC.
[15:37:27 CET] <Daemon404> ok
[15:37:33 CET] <Daemon404> ill skip th nvenc one
[15:37:53 CET] <BtbN> They probably need the CUDA-Linking, which you already no-op'd though?
[15:38:39 CET] <Daemon404> BtbN, ah... that's why
[15:38:56 CET] <Daemon404> blarg
[15:39:19 CET] <Daemon404> lavu hard dep on cuda <3
[15:39:33 CET] <BtbN> well, the pixel format should not create any dependencies
[15:40:09 CET] <Daemon404> oh indeed
[15:40:32 CET] <BtbN> https://git.libav.org/?p=libav.git;a=commit;h=ad884d100259e55cb51a4239cd8a4fd5154c2073 does though
[15:41:05 CET] <Daemon404> i guess ill-have to re-merge cuda linking... really would rather not, but eh...
[15:41:24 CET] <BtbN> I realy dislike linking against CUDA, but it's non-free anyway, so...
[15:41:42 CET] <nevcairiel> as long as it remains optional
[15:42:36 CET] <Daemon404> BtbN, is there something which precludes dlopening CUDA with lavu / nvenc change?
[15:42:45 CET] <Daemon404> i haven't looked super-hard at it (i hate hwaccel)
[15:43:11 CET] <nevcairiel> its kinda silly to link to it at one place and then dlopen in another, but it shouldnt break
[15:43:26 CET] <Daemon404> no i mean pure-dlopen
[15:43:32 CET] <BtbN> In libav, they ifdefed in nvenc.c so it also uses the linked one if cuda is in linking-mode.
[15:44:03 CET] <Daemon404> as in, why is it necessary to link to support it
[15:44:22 CET] <BtbN> Because there is no official dyn-load version of it. I made that myself.
[15:44:42 CET] <Daemon404> ah.
[15:45:15 CET] <BtbN> So for every new function and struct it uses, it means writing the loading code and adding the struct somewhere
[15:45:31 CET] <Daemon404> so it's possible, just incredibly tedious
[15:45:50 CET] <BtbN> For the code that's added so far, that wouldn't be too hard. But I guess they have plans for more.
[15:46:24 CET] <Daemon404> beats me
[15:46:47 CET] <Daemon404> i ask because i dont want to write new hwaccel code, which i cant test, or build
[15:46:54 CET] Action: Daemon404 is just a merger
[15:48:19 CET] <BtbN> The CUDA functions needed for NVENC to work are extremely minimal. You only need to create a contex, nothing more.
[15:48:55 CET] <BtbN> But if libav plans to actualy to video-processing with CUDA, they will need a whole lot of it. Dyn-Loading all that would be horribly annoying and would mean duplicating larger parts of the CUDA SDK into ffmpeg.
[15:49:14 CET] <Daemon404> [libav-devel] [RFC] lavfi: add an NVIDIA NPP-based scaling filter
[15:49:15 CET] <Daemon404> like this?
[15:49:19 CET] <BtbN> yep
[15:49:40 CET] <Daemon404> i see
[15:49:45 CET] <Daemon404> so what's your opinion then
[15:49:57 CET] <Daemon404> i'll defer to you to decide the Best Course
[15:49:58 CET] Action: Daemon404 runs
[15:50:32 CET] <BtbN> linking CUDA is fine for that purpose, as long as plain NVENC is kept in a way where it works without all that.
[15:50:44 CET] <BtbN> Which it currently is, so I'm fine with it.
[15:51:34 CET] <cone-242> ffmpeg 03Justin Ruggles 07master:e1c15a9475f0: img2dec: Support Progressive JPEG in jpeg_probe
[15:51:44 CET] <BtbN> Feel free to merge what's possible, I'll take care of the CUDA-Frame-Input stuff for nvenc.c
[15:52:04 CET] <Daemon404> BtbN, wouldnt the lavu change + cuda/nvenc necessitate linking?
[15:52:09 CET] <BtbN> yes
[15:52:09 CET] <Daemon404> if i merged as-is
[15:52:12 CET] <Daemon404> or will you take care of that
[15:52:18 CET] <nevcairiel> its an optional feature
[15:52:23 CET] <nevcairiel> just dont enable it if you dont want linking
[15:52:34 CET] <BtbN> It's an optional feature for nvenc.c, but the other CUDA stuff needs linking.
[15:52:39 CET] <Daemon404> gotcha
[15:52:47 CET] <nevcairiel> you can still build lavu without these features, of course
[15:53:08 CET] <Daemon404> unrelated: holy crap mats v26
[15:53:12 CET] <BtbN> yeah, if you merge the lavu changes right now, ENABLE_CUDA will never be set, so it won't ever be built.
[15:53:59 CET] <Daemon404> BtbN, so you *dont* want me to go back and merge teh configure changes right now?
[15:54:15 CET] <Daemon404> otherwise it's possible it will be set by user interaction
[15:54:29 CET] <nevcairiel> well you could merge the mandatory parts for future cuda support, without the nvenc changes
[15:54:42 CET] <BtbN> I'll make sure it builds and works, and then send a the CUDA-Configure-Patch again
[15:54:48 CET] <nevcairiel> or that
[15:54:50 CET] <Daemon404> BtbN, awesome
[15:55:25 CET] <BtbN> So merge the lavu changes, even though they are currently impossible to activate.
[15:55:38 CET] <nevcairiel> be careful though
[15:55:44 CET] <nevcairiel> without configure support it will error
[15:55:52 CET] <nevcairiel> because the defines are not set
[15:56:00 CET] <BtbN> I couldn't find it checking the defines anywhere, except in the Makefile
[15:56:07 CET] <nevcairiel> any feature define we have is a lways set, to either 0 or 1
[15:56:13 CET] <nevcairiel> but without configure, it would remain undefined entirely
[15:56:44 CET] <nevcairiel> so there should be configure support before its merged to avoid nastyness
[15:56:54 CET] <BtbN> ah, no. hwcontext.c has a check
[15:57:10 CET] <BtbN> Would adding cuda to the external lib list be enough to make the define appear?
[15:57:25 CET] <Daemon404> no i dont think so
[15:57:40 CET] <nevcairiel> the configure check itself is pretty simple and should work vanilla from libav, shouldnt it
[15:57:48 CET] <Daemon404> it should
[15:57:52 CET] <BtbN> nevcairiel, yeah, but it's already no-op merged.
[15:58:06 CET] <Daemon404> that doesnt stop one from re-applying it
[15:58:24 CET] <nevcairiel> just skip the nvenc  hunk in configure, and grab the other 3
[15:58:26 CET] <nevcairiel> should be fine
[15:58:43 CET] <BtbN> Sure. I guess it needs to be applied first then. If some user decides to go for it, and it explodes, well...
[15:59:17 CET] <Daemon404> lavu will build, but itll just accomplish nothing
[15:59:19 CET] <Daemon404> afaict
[15:59:27 CET] <Daemon404> i dont think anything will explode
[15:59:36 CET] <nevcairiel> evne in libav master it doesnt accomplish anything yet
[15:59:38 CET] <nevcairiel> so thats ok =P
[15:59:43 CET] <Daemon404> lol
[16:00:28 CET] <nevcairiel> in other news, libav forgot to fix the concat exploit in their latest stable point release
[16:05:32 CET] <Daemon404> nevcairiel, http://sprunge.us/YQMd
[16:05:36 CET] <Daemon404> that seem right?
[16:05:56 CET] <nevcairiel> seems fine
[16:11:37 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:7bc780cd4413: pixfmt: add a CUDA hwaccelled format
[16:11:38 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:9f2c1c77d209: configure: Allow linking to CUDA dynamically instead of dlopen()ing it at runtime
[16:11:39 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:63c3e3533283: Merge commit '7bc780cd4413f688d3b834037b0f9ddfd6948140'
[16:16:03 CET] <Daemon404> BtbN, btw i remember why this is happening now, i think
[16:16:19 CET] <Daemon404> some guy from nvidia talked to me (for some reason) + anton at the last VDD
[16:16:23 CET] <Daemon404> about hardware filtering
[16:23:51 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:ad884d100259: hwcontext: add a CUDA implementation
[16:23:52 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:6992276acaae: Merge commit 'ad884d100259e55cb51a4239cd8a4fd5154c2073'
[16:27:38 CET] <wm4> what did he say? something about doing unpaid work to further their sales?
[16:27:59 CET] <Daemon404> i think he mentioned them doing work or something
[16:28:03 CET] <Daemon404> my memory is vague
[16:28:19 CET] <nevcairiel> maybe anton even is paid, who knows
[16:41:25 CET] <Daemon404> people are uploading VTT files that start at 1 hr and expecting us to handle it "correctly" (they want us to subtract 1 hr and then display at that time)
[16:41:30 CET] <Daemon404> goddamn broadcast people
[16:41:34 CET] <Daemon404> thats not a valid VTT.
[16:42:04 CET] Action: Daemon404 wonders why this persists
[16:43:04 CET] <durandal_1707> implement ssetpts filter
[16:43:43 CET] <Daemon404> lol
[16:43:49 CET] <Daemon404> no, im not goign to fix it
[16:43:54 CET] <Daemon404> also we dont use libav* for subtitles.
[16:44:08 CET] Action: Daemon404 was just lamenting "professional" subtitlign software
[16:45:05 CET] <wm4> Daemon404: how would that even be fixable in theory
[16:45:29 CET] <wm4> the first subtitle event can come at an arbitrary time, and you can't just display it at the start
[16:45:41 CET] <Daemon404> it's not legitimately fixable
[16:45:52 CET] <Daemon404> only with heuristics
[16:53:52 CET] <ubitux> you can adjust the ts from sub events with libav*
[16:54:04 CET] <ubitux> remuxing with itsoffset and stuff like that works
[16:54:18 CET] <wm4> it's about finding the offset, not applying it
[16:54:35 CET] <J_Darnley> Gah!  These strides are not in bytes!
[16:55:04 CET] <Daemon404> J_Darnley, google product?
[16:55:09 CET] <Daemon404> google stuff tends to have strides in pixels
[16:55:14 CET] <J_Darnley> no, ffmpeg product
[16:55:18 CET] <Daemon404> aw :(
[16:57:08 CET] <cone-242> ffmpeg 03Michael Niedermayer 07release/2.8:536f6c4ec2f8: avutil/frame: Free destination qp_table_buf in frame_copy_props()
[16:57:09 CET] <cone-242> ffmpeg 03KO Myung-Hun 07release/2.8:8dd71d0bd40f: MAINTAINERS: add myself as an OS/2 maintainer
[16:57:10 CET] <cone-242> ffmpeg 03Michael Niedermayer 07release/2.8:530192b0e06c: swscale/x86/output: Move code into yuv2planeX_mainloop
[16:57:11 CET] <cone-242> ffmpeg 03Michael Niedermayer 07release/2.8:21a6b7930e5d: swscale/x86/output: Fix yuv2planeX_16* with unaligned destination
[16:57:12 CET] <cone-242> ffmpeg 03Michael Niedermayer 07release/2.8:b3a64fc0397a: avcodec/h264: Execute error concealment before marking the frame as done.
[16:57:13 CET] <cone-242> ffmpeg 03Michael Niedermayer 07release/2.8:23ef5996a589: avutil/pixdesc: Make get_color_type() aware of CIE XYZ formats
[16:57:14 CET] <cone-242> ffmpeg 03Carl Eugen Hoyos 07release/2.8:1e9aa7907ed4: postproc: fix unaligned access
[16:57:15 CET] <cone-242> ffmpeg 03Michael Niedermayer 07release/2.8:a3d698dcb143: swscale/input: Fix GBRAP16 input
[16:57:16 CET] <cone-242> ffmpeg 03Michael Niedermayer 07release/2.8:4ccb97650a94: swscale/utils: Fix chrSrcHSubSample for GBRAP16
[16:57:17 CET] <cone-242> ffmpeg 03Michael Niedermayer 07release/2.8:800334947d95: avcodec/avpacket: clear priv in av_init_packet()
[17:04:11 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:b3dd30db0b2d: lavfi: pass the hw frames context through the filter chain
[17:04:12 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:10424024a16a: Merge commit 'b3dd30db0b2d857147fc0e1461a00bd6172a26a3'
[17:29:44 CET] <BtbN> Daemon404, yes, nvidia sent a patch like that to ffmpeg-devel a while ago, but it was horrible and changed every library in some horrible way to make full CUDA transcoding possible.
[17:29:57 CET] <BtbN> It was rejected, and they never followed up with something.
[17:30:15 CET] <BtbN> Instead they published a guide on how to use nvenc with ffmpeg, where they included said hack-patch as a compilation-step.
[17:30:16 CET] <Daemon404> i guess that was the follow up
[17:30:25 CET] <Daemon404> fb did that too
[17:30:38 CET] <Daemon404> its popular with big companies with Very Clever engineers who you couldnt possibly be more clever than
[17:31:01 CET] <BtbN> Well, I don't have a problem with the general Idea of that patch, it was just horrible code.
[17:31:02 CET] <durandal_1707> ah
[17:31:11 CET] <BtbN> If it comes in as propper code that way, well...
[17:31:22 CET] <Daemon404> BtbN, the was my point about clever :P
[17:31:38 CET] <Daemon404> you dont want their code, but theyre more clever, so they just take their code and leave!
[17:32:09 CET] <BtbN> And then something like libva happens.
[17:35:08 CET] <BtbN> I wonder if this -lcuda just works on Windows.
[17:39:49 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:1bf34134612e: avconv: use the new buffersrc parameters API
[17:39:50 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:14f942b35982: Merge commit '1bf34134612e509fa68c70dfff418c6022459259'
[17:40:02 CET] <Daemon404> BtbN, depends what it is named on windows
[17:40:06 CET] <Daemon404> and with which compiler
[17:46:48 CET] <Daemon404> is there anything special to do when merging a new filter in lavfi from libav?
[17:47:00 CET] <Daemon404> i cant find ANY examples from the last 1-2 years in git history
[17:55:43 CET] <BBB> jamrial: I understand what youre saying (re: md5)
[17:55:57 CET] <BBB> jamrial: but I dont understand why its an issue. we only do it on platforms where unaligned loads are specifically supported
[17:56:42 CET] <BBB> jamrial: Id go as far as to say that ubsan is buggy, but I think the point of ubsan is like tsan, its to be buggy, nosiy and tell you stuff that is sometimes intentionally done so as a speed optimization, i.e. its a great tool for ignorant high level java coders, but not useful for development of highly performant libraries
[18:00:04 CET] <jamrial> well, if we're going to do what ubitux mentioned about making ubsan fail for every runtime error, something like that will be needed
[18:00:29 CET] <jamrial> BBB: there's also big endian. i'm still interested to know if this change benefits those systems or not
[18:01:36 CET] <BBB> so does ubsan not complain about av_rl32 doing unaligned loads?
[18:01:42 CET] <jamrial> no
[18:01:49 CET] <BBB> very interesting
[18:01:57 CET] <BBB> I wonder why
[18:02:17 CET] <BBB> the change probably benefits be b/c you dont memcpy anymore
[18:02:27 CET] <BBB> although youre doing it scalar instead of vector...
[18:02:31 CET] <BBB> I guess who cares
[18:02:48 CET] <BBB> I think patch is fine, I still dont udnerstand ubsan being ok with av_rl32 but not the direct access
[18:03:34 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:21f7cd4acd8d: lavfi: add a filter for uploading normal frames to CUDA
[18:03:35 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:ef9915a0e243: Merge commit '21f7cd4acd8dc4b4796b55966dd015cb037164d8'
[18:06:50 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:7b3214d00506: lavc: add a field for passing AVHWFramesContext to encoders
[18:06:51 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:871d0930d4c8: nvenc: support CUDA frames as input
[18:06:52 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:7e49cdd12973: Merge commit '7b3214d0050613bd347a2e41c9f78ffb766da25e'
[18:06:53 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:e05704bd46b9: Merge commit '871d0930d4c8666df5514093beff874acbe5cce0'
[18:07:56 CET] <BBB> are we still blacklisted by vlc? or is that fixed now that mt/hwaccel issue is fixed?
[18:08:11 CET] <BtbN> it's now unsupported! so they left in the block,.
[18:08:32 CET] <BBB> huh what?
[18:08:39 CET] <BtbN> exactly
[18:08:54 CET] <BBB> j-b: Im gonna cry, what else do you want?
[18:10:35 CET] <iive> have mt/hwaccel been fixed for real?
[18:11:03 CET] <iive> i thought we just reverted to the previous state
[18:11:28 CET] <BBB> theres a bug left in dxva2, I believe
[18:11:34 CET] <BBB> but in general it works again, yes
[18:12:07 CET] <BBB> so you can call that previous state if you want
[18:14:37 CET] <jamrial> BBB: since instead of failing we now warn, they consider the functionality as unsupported, meaning a future commit could break it, even if it works right now
[18:15:09 CET] <jamrial> so they are going to change how they inits hwaccel, and scheduled it for vlc 3
[18:15:36 CET] <jamrial> for vlc 2.2.x i think they don't plan to change the current blacklist
[18:16:00 CET] <BBB> great...
[18:16:06 CET] <jamrial> although michaelni was trying to see if a change in the warning could convince them otherwise
[18:16:12 CET] <BBB> do we warn?
[18:16:15 CET] <BBB> I dont think we warn anymore
[18:16:22 CET] <BBB> I fixed the bug, so why are we warning?
[18:16:35 CET] <BBB> the only hwaccel with issues is dxva2
[18:16:48 CET] <jamrial> BBB: https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=5edd1f62ca15ad34705789f155f68ca18914d0f4
[18:17:09 CET] <BBB> we should remove that warning
[18:17:15 CET] <Daemon404> this alls sounds petty
[18:17:23 CET] <BBB> its supported and known to work with everything except dxva2, right?
[18:17:38 CET] <BBB> Ill go grab lunch :/
[18:17:50 CET] <jamrial> well, j-b's priority seems to be windows, so... :P
[18:18:03 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:c15f6098b1b2: avconv: pass the hw context from filters to the encoder
[18:18:04 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:259fef86bb91: Merge commit 'c15f6098b1b25689dd5e86aeb5ce69bc12efe1e1'
[18:20:37 CET] <iive> what's the bug exactly?
[18:20:43 CET] <iive> the one that's been fixed?
[18:22:18 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:47570dbde8b3: fft: ppc: Place ff_fft_calc_interleave_altivec() under correct ifdefs
[18:22:19 CET] <cone-242> ffmpeg 03Luca Barbato 07master:2edc718723b6: configure: Relax the implication of --enable for components
[18:22:20 CET] <cone-242> ffmpeg 03Vittorio Giovara 07master:b92962436bdc: mov: Fix the format specifier type for size
[18:22:21 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:2cfb34a4e8b4: Merge commit '47570dbde8b33001d5ccac44e7ebaaeecbcb807c'
[18:22:22 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:33215d3c4898: Merge commit '2edc718723b60530aead26c20cbc891102f7d529'
[18:22:23 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:f6d633d72686: Merge commit 'b92962436bdcfae478c8598dca397a397762eef8'
[18:24:20 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:9c0bc1e980a9: qsv: add a missing #include
[18:24:21 CET] <cone-242> ffmpeg 03Anton Khirnov 07master:d847a40888c0: hwcontext_cuda/vdpau: add to skipheaders
[18:24:22 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:0d4c0240affc: Merge commit '9c0bc1e980a99106d6749ec632f166b87275871e'
[18:24:23 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:cb0355537d6a: Merge commit 'd847a40888c064cc8c35b546fc5a0ccb69136a7c'
[18:31:44 CET] <nevcairiel> BBB: they are just being silly, we dont even use the word unsupported anywhere, so it sounds to me like someone is just trying to stir up problems, i'm done catering to those people
[18:32:40 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:29c2d06d6772: cosmetics: Drop empty comment lines
[18:32:41 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:1a12eb4a7314: Merge commit '29c2d06d67724e994980045afa055c6c34611b30'
[18:36:56 CET] <durandal_1707> its politic, evil people everywhere
[18:37:32 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:6b96d2dcdaa6: cosmetics: Drop particularly redundant silly comments
[18:37:33 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:3d8025d60204: profiles: Add missing #endif comment
[18:37:33 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:7c82d31cbe9f: checkasm: Use standard multiple inclusion guards
[18:37:35 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:5eb4073781ee: Merge commit '6b96d2dcdaa60d7919d710432c6ca204b7fab0ab'
[18:37:35 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:aaa3d6227279: Merge commit '3d8025d602045cbd2894e5182d9243c2e864c8c8'
[18:37:37 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:ca408cf557b8: Merge commit '7c82d31cbe9fc5d5a321ad49c14a472bd629b50f'
[18:39:22 CET] <cone-242> ffmpeg 03Vittorio Giovara 07master:71eaefa64a54: build: Add missing celp_math dependency for G723_1 encoder and decoder
[18:39:23 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:e45312932177: build: Add missing dependencies for eatqi decoder
[18:39:24 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:7e12a3d57ca0: Merge commit '71eaefa64a54bece571299ca600d06f48ac7c6c3'
[18:39:25 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:3c5a040ad94d: Merge commit 'e453129321778886813dcecf73c8b42f8352ca0e'
[18:39:36 CET] <nevcairiel> only a couple patches left until the evilness
[18:40:00 CET] <Daemon404> like 20 diego patches
[18:47:00 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:7403be9b1bce: build: Fix dependencies for components relying on H.263 data tables
[18:47:01 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:2870972e9de6: build: Fix mpegvideo component dependencies
[18:47:02 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:de3b134be3f5: build: Adjust mpeg4video parser dependencies
[18:47:03 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:82454c3a826b: build: Let the WTV demuxer select the MPEG-TS demuxer
[18:47:04 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:34e4c588c8e8: Merge commit '82454c3a826bc8aa42474097784b70befd5be532'
[18:54:01 CET] <jamrial> regarding the codecpar stuff, does every demuxer need to be updated at the same time to avoid compilation failures? because we have a bunch libav doesn't
[18:54:24 CET] <nevcairiel> yes
[18:54:52 CET] <nevcairiel> well not compilation problems as such, but it wouldnt work
[18:55:08 CET] <nevcairiel> but we'll just do what we did last time, merge it into a github branch and slowly work on fixing it
[18:55:50 CET] <jamrial> right
[18:56:25 CET] <Daemon404> this one will probably be less painful
[18:56:29 CET] <Daemon404> than TEP1
[18:58:28 CET] <nevcairiel> i'm not that sure
[18:59:30 CET] <ubitux> Daemon404: can you explain why it's a noop sometimes?
[18:59:38 CET] <ubitux> i'm thinking of "avconv: use the new buffersrc parameters API"
[19:02:14 CET] <nevcairiel> avconv and avplay have largely diverged, so its hard to merge those
[19:02:35 CET] <Daemon404> ubitux, it cant be done easily afaik
[19:02:44 CET] <Daemon404> we have a bunch of stuff set thats not in the param struct
[19:02:54 CET] <Daemon404> i tried, but it wasnt working out
[19:03:25 CET] <J_Darnley> atomnuker: I've got a couple of questions about the vc2 encoder
[19:03:29 CET] <Daemon404> the code thats already there doesnt use any deprecated api calls afaik either
[19:03:49 CET] <J_Darnley> I'll start with: does it accept arbirary frame dimensions?
[19:03:58 CET] <J_Darnley> *arbitrary
[19:06:06 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:ab9068cc9cc7: build: Fix typo in HEVC VDPAU hwaccel dependencies
[19:06:07 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:624e235502c5: build: Introduce iso_media component
[19:06:08 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:0d1229f1d2b8: voc: Split ff_voc_get_packet into a separate file
[19:06:09 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:b4a0f172c7f1: Revert all recent configure changes related to dependency resolution
[19:06:10 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:745d0c030085: Merge commit '624e235502c5aa2d17e22dd6c0ccdf080a177310'
[19:06:11 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:f99195d56f4a: Merge commit '0d1229f1d2b8f26dd50c6be7917bb8ed8cb95364'
[19:06:12 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:9fad1ce7c95a: Merge commit 'b4a0f172c7f116d8d329ff02f29c138a9291fd3c'
[19:09:40 CET] <cone-242> ffmpeg 03Luca Barbato 07master:3ef98937f512: mov: Force the full parsing of mp3
[19:09:41 CET] <cone-242> ffmpeg 03Luca Barbato 07master:f273f7fb25b6: mkv: Force the full parsing of mp3
[19:09:42 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:79127dbbeffa: Merge commit '3ef98937f512184f80d3bd30015f5ec83dc11eb0'
[19:09:43 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:dc61014319ba: Merge commit 'f273f7fb25b68792be481c9241b0ec2876e41f35'
[19:09:53 CET] <Daemon404> almost at the evil
[19:10:03 CET] <JEEB> the evil within
[19:10:16 CET] <Daemon404> good game
[19:10:50 CET] <JEEB> hmm, I don't remember how good its PC port is but I guess I should try it out
[19:12:50 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:7d16d8533daf: build: More precise dependencies for h264dsp
[19:12:51 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:b10c33c5ea9a: build: Add missing mpegvideo dependency for the MSS2 and VC-1 decoders
[19:12:52 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:0ffaae60e849: Merge commit '7d16d8533daf73b66d318c5e27de3b17208aa0ba'
[19:12:53 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:d61849f0b7f0: Merge commit 'b10c33c5ea9a41c41726fb5488ea1633e3f898ac'
[19:15:39 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:79866803ffc4: msmpeg4data: K&R formatting cosmetics
[19:15:40 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:f9fbd474676e: msmpeg4data: Move WMV2 data tables to their own file
[19:15:41 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:133aa68601d5: Merge commit '79866803ffc4c1a1b02663de9bab216b8cfdb8b4'
[19:15:42 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:2814f06abf43: Merge commit 'f9fbd474676e903e12efe83203697d60a9d28cf9'
[19:22:26 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:15a24614aef5: build: Add vc1dsp component for more fine-grained dependencies
[19:22:27 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:b056482ef361: Merge commit '15a24614aef5836af3cd2c7cc3b2b737eee6bf3c'
[19:22:35 CET] <BBB> nevcairiel: I suppose, but I can at least try
[19:25:47 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:d24bd96bdd5b: build: Disentangle VC-1 decoder and parser
[19:25:48 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:8d918a98aa24: rtpdec: Use the right logging context
[19:25:49 CET] <cone-242> ffmpeg 03Diego Biurrun 07master:8caadfc53ddc: fate: Be silent when switching to Git branch
[19:25:50 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:ef7ce480c848: Merge commit 'd24bd96bdd5b4bae9a9e0055fa8d1104db1283a9'
[19:25:51 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:79b1a24b7ddd: Merge commit '8d918a98aa24134a043d578ef45bae363dbed9db'
[19:25:52 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:8ae21fd95985: Merge commit '8caadfc53ddc55a269722ada65294f0ea8b609ac'
[19:27:45 CET] <cone-242> ffmpeg 03Luca Barbato 07master:bf7be043fcfd: matroska: Always consider S_TEXT/UTF8 as SRT when demuxing
[19:27:46 CET] <cone-242> ffmpeg 03Derek Buitenhuis 07master:2ef37691a059: Merge commit 'bf7be043fcfda29c81ef2268885b4ccc643e7c49'
[19:28:02 CET] <Daemon404> nevcairiel, we're now at the start of the TEP2 commit cluster
[19:28:12 CET] <Daemon404> i think some can be merged though
[19:28:35 CET] <Daemon404> or rather, there are some prep commits first before TEP
[19:28:42 CET] <Daemon404> and some unrelated ones
[19:29:05 CET] <Daemon404> ack, i was mistaken.. there's still a bunch of crap before TEP
[19:29:08 CET] <Daemon404> nevermind, carry on
[19:29:11 CET] <Daemon404> i will do it later
[19:29:12 CET] <Daemon404> dinner time
[19:38:15 CET] <cone-242> ffmpeg 03Paul B Mahol 07master:b6a0aa1c0a6c: avfilter/vf_blend: add freeze and heat modes
[19:49:25 CET] <BBB> poor daemon404
[19:51:58 CET] <cone-242> ffmpeg 03James Almer 07master:fc404460bd92: configure: add missing vc1dsp dependency to vc1_decoder
[20:06:32 CET] <philipl> fritsch: kodi's configure is demanding decadec even when shared ffmpeg is used. This seems unnecessary from my reading
[20:09:15 CET] <michaelni> Daemon404, some merge today broke packed_maindata.mp3.mp4 
[20:12:33 CET] <michaelni> https://dl.dropboxusercontent.com/u/76042064/packed_maindata.mp3.mp4
[20:16:40 CET] <J_Darnley> In x86 assembly, can I do x*17 with fewer instructions than 3 LEAs other than an IMUL?
[20:17:06 CET] <kurosu_> imul would be better
[20:17:25 CET] <durandal_1707> writing assembly for what?
[20:17:33 CET] <J_Darnley> vc2 encoder
[20:18:25 CET] <BBB> J_Darnley: how many registers?
[20:18:43 CET] <jkqxz> x | x << 4?  imul might still be better.
[20:18:45 CET] <jamrial> J_Darnley: can't you do y = x; x <<= 4; x += y?
[20:18:53 CET] <BBB> J_Darnley: if you have two, simply do ebx=lea[eax*4]; ebx=lea[ebx*4+eax]
[20:19:10 CET] <BBB> J_Darnley: thats two instructions, but requires a free register
[20:19:58 CET] <J_Darnley> I have a few free but I might like to save some if I want to use 32-bit at some point.
[20:21:18 CET] <jamrial> since lea is slow, how about mov ebx, eax; shl eax, 4; add eax, ebx?
[20:21:43 CET] <J_Darnley> Wait, it's slow now?
[20:22:04 CET] <kurosu_> all of these are sequential - I doubt that they are actually faster than an imul
[20:22:06 CET] <jamrial> latency of three cycles afaik
[20:22:33 CET] <jamrial> mov, shl, add, all those are one
[20:22:47 CET] <kurosu_> yeah but sequential
[20:23:00 CET] <ubitux> clang does an imul, gcc does mov,shl,add
[20:23:04 CET] <ubitux> pick your favorite
[20:23:26 CET] <jamrial> the mov and the shl can run at the same time. only the add needs to wait for the two former instructions to finish
[20:23:29 CET] <J_Darnley> How many of you went off to a compiler?  Raise your hands.  :)
[20:23:43 CET] <kurosu_> I'd personally solve the question by just using START/STOP_TIMER anyway
[20:24:01 CET] <kurosu_> s/solve/answer
[20:25:26 CET] <J_Darnley> Well, thanks for the suggestions, I'll stick with imul for now and optimise later
[20:32:49 CET] <kurosu__> re fixed point synth_filter & dts, I really wonder if a sse4 version, particularly on x86_64, will improve much anything
[20:34:20 CET] <jamrial> kurosu__: it should. try decoding a dts-ma file and use perf
[20:34:57 CET] <jamrial> most cpu time is spent in a parse function and synth filter last time i checked
[20:35:07 CET] <kurosu__> what I mean: you're just going to do twice the multiplies and then you'll need some more shuffling
[20:35:29 CET] <kurosu__> I'm not contesting it's an hot point
[20:35:36 CET] <jamrial> ah
[20:35:58 CET] <jamrial> well, it helped with mlp/truehd
[20:36:32 CET] <kurosu__> ok, then it's more like the effort is not that much rewarded
[20:36:39 CET] <kurosu__> but yeah, parsing is probably more rewarding, I haven't looked at it
[20:37:17 CET] <jamrial> with mlp using pmuldq i got the function to be 2.5x faster than the c version
[20:39:15 CET] <jamrial> pity there's no pmuhdq instruction
[20:39:50 CET] <kurosu__> pmaddddq ? :D
[20:40:04 CET] <jamrial> heh, that'd be even better :p
[20:40:06 CET] <JEEB> :D
[20:40:19 CET] <jamrial> one of the avx512 extensions adds pmullq
[20:42:07 CET] <kurosu__> well, I'd look it up, weren't there that much corruption on the network I'm on (which manages to poison google or any dns)
[20:54:42 CET] <rcombs> pmadgpgpgpgpuwaitaminute
[20:54:43 CET] <michaelni> Daemon404, found the commit breaking the mp3, posted a patch
[20:55:25 CET] <rcombs> michaelni: maybe fix the MP3 parser instead?
[20:55:52 CET] <rcombs> I've definitely seen MKV files the equivalent change fixes; would not be surprised if the same was true of MP4
[20:56:36 CET] <rcombs> it fixes files where the MP4 (or in MKV, that) packets aren't aligned with MP3 frames
[20:56:43 CET] <rcombs> which is pretty stupid but happens in real files
[21:04:48 CET] <michaelni> rcombs, mp4 allows packing mp3 so it cannot easily be parsed if thats not the case our mp4 demuxer uses the parser, mkv always uses the parser for mp3
[21:06:02 CET] <michaelni> rcombs, that said, if the parser can be made to handle such packed mp3, dong that of course wont hurt either
[21:06:35 CET] <rcombs> seems like the most general solution
[21:06:57 CET] <jamrial> kurosu__: with avx2 you also have 256bit wide regs, so four multiplies per pmuldq
[21:11:38 CET] <michaelni> rcombs, are you ok wth reverting the merge that broke it ?
[21:12:18 CET] <rcombs> as long as we're handling it in the specific case known to be broken, I guess it's fine
[21:13:26 CET] <kurosu__> gtg
[21:13:29 CET] <michaelni> rcombs, iam not aware of a file that doesnt work, and iam interrested in files that dont work (please CC me on any tickets about such bugs)
[21:13:50 CET] <rcombs> I've just got the MKV one laying around (that's since been fixed)
[21:14:04 CET] <rcombs> I'll tell you if I run into an MP4 though
[21:14:18 CET] <michaelni> ok, please do
[21:14:24 CET] <rcombs> I think these things come from some crappy camcorders
[21:24:10 CET] <atomnuker> J_Darnley: yes, the VC-2 encoder should be able to accept arbitrary frame sizes
[21:24:26 CET] <J_Darnley> drat.
[21:24:32 CET] <atomnuker> why?
[21:24:37 CET] <J_Darnley> I will need to split some of these loops
[21:24:42 CET] <atomnuker> that
[21:25:19 CET] <J_Darnley> split for width & ~mmsize and width & (mmsize-1)
[21:25:46 CET] <cone-242> ffmpeg 03Michael Niedermayer 07master:5870f2a1dc46: Revert "Merge commit '3ef98937f512184f80d3bd30015f5ec83dc11eb0'"
[21:26:20 CET] <atomnuker> J_Darnley: couldn't you fall back to C code in case the dimensions aren't 1080p?
[21:26:22 CET] <J_Darnley> Unless I am mistaken about its operation and that the smaller dwt sections are not nested into the same frame/buffer
[21:27:03 CET] <atomnuker> The current Haar transform can be applied fully in-place
[21:27:35 CET] <J_Darnley> yeah, because they don't do 8 samples at a time
[21:27:47 CET] <atomnuker> for a single level transform, since you still need to deentangle the coefficients to prepare them for another level
[21:28:20 CET] <J_Darnley> Okay, let me ask a more simple question.
[21:29:05 CET] <fritsch> philipl: since ffmpeg-3.0 most likely, yes
[21:29:28 CET] <J_Darnley> If it needs to do a width of 9, are the extra 7 samples going to overwrite something important?
[21:29:31 CET] <fritsch> philipl: we have some parts of the code that want the dcadec codec for e.g. number of channels estimation
[21:30:17 CET] <atomnuker> J_Darnley: a width of 9 for what? slice size, frame size?
[21:30:34 CET] <fritsch> philipl: my next todo is bumping kodi's ffmpeg to 3.0 + some hevc-10 bit patches, but I want to cure all the tons of warnings before that. Will start next week.
[21:30:36 CET] <J_Darnley> i don't know, whatever width the DSP function gets
[21:30:51 CET] <J_Darnley> a "subband" I think
[21:31:48 CET] <atomnuker> J_Darnley: ah, you mean the actual transform functions
[21:31:56 CET] <J_Darnley> yes
[21:32:51 CET] <t4nk748> fritsch: What are the 10bit hevc patches?
[21:33:31 CET] <fritsch> dxva hwaccel
[21:33:33 CET] <fritsch> by nevcairiel 
[21:33:43 CET] <fritsch> from ffmpeg 3.1
[21:34:02 CET] <t4nk748> thank you
[21:35:53 CET] <atomnuker> J_Darnley: the subband function gets called with the size of a single plane (e.g. 1920x1080 luma and twice for 960x540 for 420 chroma)
[21:36:19 CET] <atomnuker> for every single level (wavelet_depth), the function gets called again with the size of the previous image halved
[21:36:39 CET] <J_Darnley> A max of 5 levels, right?
[21:37:01 CET] <atomnuker> so 1920x1080 for level 1, 960x540 for level 2, 430x270 for level 3, etc.
[21:37:05 CET] <atomnuker> yes, maximum of 5 times
[21:37:39 CET] <J_Darnley> okay, I'll limit the function's use at first
[21:37:49 CET] <J_Darnley> thank you.
[21:38:04 CET] <atomnuker> J_Darnley: keep in mind that everything is padded
[21:38:25 CET] <atomnuker> FFALIGN(p->width,  (1 << s->wavelet_depth))
[21:38:45 CET] <atomnuker> so for a 4 level transform at 1080p you get a vertical resolution for the plane of 1088
[21:39:24 CET] <J_Darnley> okay, I'll look at the padding later
[21:39:29 CET] <atomnuker> so in case you overwrite some stuff you have some leeway at the end of your buffer
[21:58:40 CET] <philipl> fritsch: no worries.
[21:59:05 CET] <fritsch> philipl: what's the status on 10 bit hwaccel on linux / vdpau?
[22:01:38 CET] <philipl> fritsch: no update I'm afraid. We'll know things are moving when the 10bit libvdpau changes appear on the vdpau mailing list.
[22:02:13 CET] <fritsch> will stay tuned
[22:02:24 CET] <fritsch> as vaapi already has pushed 10 bit libva / libva-driver-intel patches
[22:02:28 CET] <fritsch> though no hw yet
[22:08:38 CET] <atomnuker> btw J_Darnley, which subband function are you currently trying to DWT?
[22:09:31 CET] <J_Darnley> the first one, uh 97
[22:09:36 CET] <J_Darnley> vc2_subband_dwt_97
[22:12:12 CET] <atomnuker> nice
[22:13:26 CET] <atomnuker> in the future i'd be nice to do DWT per slice so we can just do transform->encode per slice rather than do the first per plane
[22:13:35 CET] <atomnuker> though that's only possible with the Haar wavelet
[22:15:15 CET] <atomnuker> 9_7 gives you the best quality as long as you don't give it crazy low bitrates
[22:16:55 CET] <atomnuker> Haar wins then because having blocking artifacts due to quantization wins over having ugly eliptical artifacts (due to the fact 9_7 isn't doable without overlap per slice)
[22:18:19 CET] <atomnuker> but the 9_7 is the default for a good reason (which is that it simply looks better at all other cases)
[22:33:54 CET] <cone-242> ffmpeg 03Paul B Mahol 07master:c09248aecd0d: avfilter/af_astats: reset stats prior not after filtering
[22:39:02 CET] <rcombs> philipl: fritsch all for HEVC, though, yeah?
[22:49:59 CET] <nevcairiel> in the meantime, microsoft pushed vp9 10-bit support, although no hardware and/or drivers support it yet =p
[22:53:23 CET] <wm4> isn't vp9 10 bit obscure?
[22:54:34 CET] <TD-Linux> right now yes, but the latest broadcast standards and blu-ray specs specify 10 bit so presumably there is some demand
[22:54:57 CET] <philipl> rcombs: for now yes. nvidia hardware doesn't do 10bit h264 and I don't know what their vp9 hardware capabilities are
[22:55:34 CET] <nevcairiel> specifiying it in the dxva2 context isnt all that hard, the structs all contained the necessary information anyway, so all they had to do is define a restricted profile
[22:55:41 CET] <nevcairiel> philipl: no hardware does h264 10-bit
[22:55:50 CET] <nevcairiel> consumer hardware anyway
[22:55:55 CET] <rcombs> maybe some broadcast stuff might :3
[22:56:07 CET] <JEEB> and the non-consumer stuff most probably only handles intra-only anyways
[22:56:14 CET] <rcombs> inb4 GPGPGPGPGPU
[23:00:07 CET] <wm4> is vp9 still fixed to bt.601?
[23:00:51 CET] <nevcairiel> no, it has flags
[23:01:05 CET] <nevcairiel> including bt2020 and rgb even
[23:02:27 CET] <wm4> I swear at least vp8 was once fixed to bt.601
[23:02:58 CET] <wm4> is bt2020 patent unencumbered?
[23:03:16 CET] <nevcairiel> vp8 is i think
[23:03:35 CET] <nevcairiel> also, TIL there is a difference between "texture array" and "array of textures" in d3d11
[23:04:06 CET] <wm4> the former is a hardware abstraction, the latter is just a bunch of unrelated textures?
[23:11:19 CET] <TD-Linux> yes, vp9 has tags though yt videos are untagged and chrome magically picks bt.709
[23:13:17 CET] <nevcairiel> wm4: apparently so, you can either allocate a bunch of Texture2D objects, or allocate one with X "elements"
[23:13:51 CET] <nevcairiel> and the hevc dxva2 spec lets the driver ask for one of the two modes for better performance =p
[23:14:15 CET] <nevcairiel> although obeydience is optional
[23:15:03 CET] <wm4> interesting, wouldn't have thought that it makes a perf difference at all with just 2 textures
[23:15:55 CET] <nevcairiel> the difference is only in d3d11 anyway, i dont do that (yet)
[23:16:14 CET] <nevcairiel> d3d11 hw decoding api is freaking weird anyway
[23:16:51 CET] <wm4> weird in what way? I'll have to implement this at some point too
[23:17:03 CET] <nevcairiel> it seems just so complex
[23:17:19 CET] <nevcairiel> but i havent done it yet, so maybe it'll fall in place and make sense somehow
[23:24:47 CET] <nevcairiel> .. so much to do, so little time
[23:46:56 CET] <BBB> wm4: yes, vp8 was fixed to bt601
[23:47:14 CET] <BBB> wm4: vp9 isnt
[23:47:19 CET] <wm4> ok
[23:47:37 CET] <BBB> its allowed to be unknown just like in h264/hevc so often its unknown"
[23:47:49 CET] <BBB> I dont know how yt decides it should be bt709 or whatever
[23:49:33 CET] <wm4> BBB: possibly resolution?
[23:49:42 CET] <TD-Linux> BBB, chrome decides that if it's MSE then it's bt 709
[23:49:53 CET] <BBB> could be. I didnt mean Id have no idea, I meant I dont know :)
[23:50:02 CET] <TD-Linux> otherwise it's >480 height it's bt 709
[23:50:11 CET] <BBB> ah ok
[23:50:16 CET] <wm4> MSE?
[23:50:32 CET] <TD-Linux> media source extensions, aka "detect youtube"
[23:50:33 CET] <nevcairiel> but but pal sd is 576, always with these limited american minds
[23:50:36 CET] <wm4> oh
[23:57:08 CET] <BBB> status:closed, resolution: works4me
[00:00:00 CET] --- Thu Feb 25 2016