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

[burek]

[04:06:06 CEST] <cone-062> ffmpeg 03Ludmila Glinskih 07master:4a9bc12fe74a: fate: add api-band-test
[05:18:37 CEST] <jamrial> http://users.atw.hu/instlatx64/GenuineIntel00506E3_Skylake_InstLatX64.txt
[09:14:54 CEST] <cone-614> ffmpeg 03Paul B Mahol 07master:c864de3c8ff5: fate: add tests for waveform filter
[09:52:05 CEST] <j-b> 'moroning
[10:19:43 CEST] <durandal_1707> j-b: something is wrong?
[10:22:54 CEST] <j-b> durandal_1707: not that I know :D
[10:26:19 CEST] <cone-614> ffmpeg 03Janne Grunau 07master:faa3f17a7633: fate: test only demuxing in asf-repldata
[10:26:20 CEST] <cone-614> ffmpeg 03Hendrik Leppkes 07master:11014dd3d47b: Merge commit 'faa3f17a76333b672ce4a40cf80f678ab68bdbae'
[10:26:55 CEST] <cone-614> ffmpeg 03Henrik Gramner 07master:e13da244f416: checkasm: x86: properly save rdx/edx in checked_call()
[10:26:56 CEST] <cone-614> ffmpeg 03Hendrik Leppkes 07master:38b42250dc88: Merge commit 'e13da244f41610ee073b2f72bcf62b60fa402bb5'
[10:27:59 CEST] <cone-614> ffmpeg 03Henrik Gramner 07master:515b69f8f8e9: checkasm: Explicitly declare function prototypes
[10:28:00 CEST] <cone-614> ffmpeg 03Hendrik Leppkes 07master:fea156367d30: Merge commit '515b69f8f8e9a24cfaee95d8c1f63f265d8582fe'
[10:29:57 CEST] <cone-614> ffmpeg 03Anton Khirnov 07master:a1926a29fb43: hevc: avoid invalid shifts of negative values
[10:29:58 CEST] <cone-614> ffmpeg 03Hendrik Leppkes 07master:001ea567ff80: Merge commit 'a1926a29fb4325afa46842883f197c74d4535c36'
[10:33:10 CEST] <cone-614> ffmpeg 03Anton Khirnov 07master:d8ebb6157d12: hevcdsp: fix a function name
[10:33:11 CEST] <cone-614> ffmpeg 03Hendrik Leppkes 07master:0cbae3763d96: Merge commit 'd8ebb6157d12183ed3fc987cd2ba18b404758828'
[10:35:08 CEST] <cone-614> ffmpeg 03Luca Barbato 07master:47b447aaff1b: imgutils: Fix a typo in avcodec_get_pix_fmt_loss
[10:35:09 CEST] <cone-614> ffmpeg 03Hendrik Leppkes 07master:59cae1916e30: Merge commit '47b447aaff1bc30ba986ca757346a2c5c95b786a'
[10:37:12 CEST] <cone-614> ffmpeg 03John Högberg 07master:f9ab4fe1f7c1: h264: Discard currently unsupported registered sei
[10:37:13 CEST] <cone-614> ffmpeg 03Luca Barbato 07master:61d8fa2a1ab7: h264: Fix faulty call to avpriv_request_sample
[10:37:14 CEST] <cone-614> ffmpeg 03Hendrik Leppkes 07master:a4c13f95fbe2: Merge commit 'f9ab4fe1f7c1e9d410ca5ee2c9ff8d2892aad068'
[10:37:15 CEST] <cone-614> ffmpeg 03Hendrik Leppkes 07master:0f72dfeb5f24: Merge commit '61d8fa2a1ab76f0f3ac1442faa104ace4b29decc'
[10:38:04 CEST] <cone-614> ffmpeg 03Luca Barbato 07master:167ea1fbf15e: xavs: Do not try to set the bitrate tolerance without a bitrate
[10:38:05 CEST] <cone-614> ffmpeg 03Hendrik Leppkes 07master:87ee98c89866: Merge commit '167ea1fbf15ecefa30729f9b8d091ed431bf43bd'
[10:44:33 CEST] <cone-614> ffmpeg 03Luca Barbato 07master:d5eab59a5373: aac: Make sure to set err on the failure path
[10:44:34 CEST] <cone-614> ffmpeg 03Luca Barbato 07master:e23f84d96524: channel_layout: Add a 16channel default layout
[10:44:35 CEST] <cone-614> ffmpeg 03Hendrik Leppkes 07master:d2d6ca6f98cc: Merge commit 'd5eab59a5373b22aa52d6053a8e853e95a6e131e'
[10:44:36 CEST] <cone-614> ffmpeg 03Hendrik Leppkes 07master:fd2977d85f42: Merge commit 'e23f84d9652474353d8bbc42787a56ec1991908f'
[12:02:40 CEST] <j-b> is Thilo on the chan
[12:28:08 CEST] <durandal_1707> j-b: nope, why?
[13:04:47 CEST] <cone-614> ffmpeg 03Arthur Grant 07master:781efd07415c: avformat/hevc: Fix parsing errors
[14:41:56 CEST] <arpu> hello. are there any dashenc patches for aes encryption? 
[14:43:07 CEST] <j-b> cenc?
[14:46:27 CEST] <arpu> j-b, hi should i know this? 
[14:47:24 CEST] <cone-614> ffmpeg 03Michael Niedermayer 07master:ee155c18a2c5: avformat/hevc: Check num_long_term_ref_pics_sps to avoid potentially long loops
[14:49:12 CEST] <Compn> arpu : hmmm, i dont remember , but i havent been looking closely at the dash threads
[15:31:39 CEST] <Compn> Soylent contains GMO and conventional ingredients.  It is not certified organic or GMO-free.
[15:31:41 CEST] <Compn> herp derp
[15:32:04 CEST] <Daemon404> so?
[15:32:10 CEST] <Daemon404> GMO scaremongering is retarded
[15:32:21 CEST] <Compn> also ingredients from china.
[15:32:50 CEST] <Daemon404> do you never eat rice then?
[15:32:51 CEST] <Daemon404> ;)
[15:34:17 CEST] <Compn> made in thailand, or japan, or california, yes
[15:34:47 CEST] <iive> https://en.wikipedia.org/wiki/2008_Chinese_milk_scandal
[15:35:03 CEST] <Compn> iive : dont bother, people who dont care what they eat dont care.
[15:35:14 CEST] <Daemon404> i care if there's *proven* downsides
[15:35:19 CEST] <Daemon404> GMOs do not fit that bill.
[15:35:19 CEST] <Compn> should be called chinese milk poisoning
[15:35:24 CEST] <Compn> not scandal
[15:35:43 CEST] <Compn> chinese dog food poisoning too
[15:36:03 CEST] <Daemon404> btw that link -> fallacy of composition
[15:36:51 CEST] <iive> not really
[15:36:56 CEST] <Compn> although growing rice in california is probably stupid :P
[15:37:11 CEST] <Compn> did you know you dont have to flood a rice "paddy" though ? can just grow it like other grains...
[15:37:47 CEST] <Compn> growing anything in california is stupid*
[15:38:21 CEST] <iive> of course, not all food from china is poisonous,
[15:38:41 CEST] <Compn> of course not. i frequently eat things made in china
[15:38:53 CEST] <Daemon404> there's a dirty joke in here somewhere
[15:39:27 CEST] <Compn> bunch of chinese grocery stores near me :)
[15:40:23 CEST] <iive> but you cannot trust them to provide quality product
[15:40:57 CEST] <Compn> even testing their products, you cannot trust them to not cheat the testing procedure (which is what they were doing to cheat the milk tests)
[15:41:14 CEST] <iive> especially when looking for the lowest bidder.
[15:41:31 CEST] <Compn> generalizations of a whole country :P
[15:41:50 CEST] <Daemon404> there are some very good engineers in china.
[15:41:51 CEST] <Compn> that contains 1/6th the population , ah yes.
[15:41:56 CEST] <Daemon404> however, they do not work for outsourcing companies
[15:41:57 CEST] <Daemon404> obv
[15:42:24 CEST] <iive> absolutely, but it is wild capitalism out there.
[15:59:06 CEST] <durandal_1707> should i pass student?
[16:30:03 CEST] <cone-614> ffmpeg 03Paul B Mahol 07master:c34c050303b1: avfilter/vf_vectorscope: make intensity user configurable
[16:30:04 CEST] <cone-614> ffmpeg 03Paul B Mahol 07master:2f731d46f0e4: avfilter/vf_vectorscope: add options with shorter name
[17:45:28 CEST] <cone-614> ffmpeg 03Michael Niedermayer 07release/2.4:b15311eb6f97: ffmpeg: check avpicture_fill() return value
[17:45:29 CEST] <cone-614> ffmpeg 03Michael Niedermayer 07release/2.4:1c058d94b9ea: ffmpeg: Check for RAWVIDEO and do not relay only on AVFMT_RAWPICTURE
[17:45:30 CEST] <cone-614> ffmpeg 03Michael Niedermayer 07release/2.4:5b41bb29d73e: avcodec/h264_mp4toannexb_bsf: Reorder operations in nal_size check
[17:45:31 CEST] <cone-614> ffmpeg 03Michael Niedermayer 07release/2.4:3faf44401012: ffmpeg: Check av_parser_change() for failure
[17:45:32 CEST] <cone-614> ffmpeg 03Michael Niedermayer 07release/2.4:e0bd87de8fa3: ffmpeg: Use correct codec_id for av_parser_change() check
[17:45:33 CEST] <cone-614> ffmpeg 03Arthur Grant 07release/2.4:cc39b2be236f: avformat/hevc: Fix parsing errors
[17:45:34 CEST] <cone-614> ffmpeg 03Michael Niedermayer 07release/2.4:b06958917cca: avformat/hevc: Check num_long_term_ref_pics_sps to avoid potentially long loops
[19:51:11 CEST] <cone-614> ffmpeg 03Michael Niedermayer 07master:fa9af304f0a1: avcodec/mjpegdec: Remove message asking for a non mod 16 AMV sample
[20:35:41 CEST] <BtbN> So, i think i'm passing all(well, most, but the ones i ignore are ignored by gst as well) parameters for vaapi now.
[20:35:52 CEST] <BtbN> It still doesn't work. But also doesn't spit out any errors.
[22:19:08 CEST] <nevcairiel> BtbN: a long time ago i wrote myself a tiny library which intercepts dxva2 calls and prints out the structures into a file, so i can compare what ffmpeg does and what the vendors own codecs do .. it came in quite handy sometimes. so.. implement a libva shim :D
[22:19:22 CEST] <JEEB> :D
[22:19:31 CEST] <JEEB> that kind of stuff can be quite useful
[22:19:42 CEST] <BtbN> And compare it to what? :D
[22:19:47 CEST] <nevcairiel> gst of course
[22:19:52 CEST] <nevcairiel> assuming that actually produces an image
[22:20:04 CEST] <BtbN> Well, the problem could very well also be on the kodi side of things
[22:20:17 CEST] <BtbN> gst doesn't use the EGL direct rendering stuff
[22:20:20 CEST] <nevcairiel> i guess we dont have ffmpeg_vaapi.c yet, eh
[22:20:33 CEST] <BtbN> I actualy wanted to write that
[22:20:49 CEST] <BtbN> But then i realized i'd have to do uswc sse4 copying code for it to be any usefull
[22:21:00 CEST] <nevcairiel> we dont have that for any others either
[22:21:15 CEST] <nevcairiel> stefano (iirc?) was poking that at some point
[22:21:29 CEST] Action: Daemon404 barfs
[22:21:31 CEST] <nevcairiel> personally i view those as a development tool, not a user feature
[22:21:43 CEST] <BtbN> Problem with libva is, copying back yuv data from it with a normal memcpy is way too slow
[22:21:52 CEST] <BtbN> like, 5-10 fps slow
[22:21:58 CEST] <nevcairiel> fine for testing!
[22:22:46 CEST] <nevcairiel> if i get super bored one day, i may try to write a simple gpu memcpy in yasm code and submit it, since the patch on the ML seems to have died (and used inline asm)
[22:23:07 CEST] <BtbN> I even have such copying code flying around somewhere
[22:23:22 CEST] <BtbN> Written with intrinsics though
[22:23:29 CEST] <nevcairiel> if you make the function super limited, like assuming alignment of in/out buffers and padding requirements, its kinda trivial too
[22:23:55 CEST] <BtbN> The super lazy way is to just borrow it from vlc
[22:24:10 CEST] <nevcairiel> theirs is weird, for some reason it does a double copy
[22:24:17 CEST] <nevcairiel> uswc into a small cache, memcpy into normal buffer
[22:24:20 CEST] <nevcairiel> i never understood why
[22:24:30 CEST] <nevcairiel> makes no sense to me, and i tested, its not faster or anything
[22:24:32 CEST] <BtbN> That's how the intel paper describes it though
[22:25:09 CEST] <nevcairiel> maybe there is some theoretical improvement with cache usage or something?
[22:25:26 CEST] <BtbN> There has to be some reason behind that 4k buffer
[22:25:55 CEST] <nevcairiel> in any case, i tested all these weird combinations, and at least on windows it made absolutely no difference, in fact the extra buffer was a bit slower
[22:27:55 CEST] <BtbN> The weird thing currently is, it works. vaapi does not throw any error. But it's slow as hell, and it renders nothing.
[22:28:37 CEST] <nevcairiel> now i just use the uswc read in groups of 4 to use the cpu read buffer properly, and non-temporal store into the dest buffer, that seemed best and most simple
[22:28:44 CEST] <nevcairiel> if its slow as hell, it may actually be doing things :D
[22:29:23 CEST] <BtbN> There's only one place left where i'd strongly suspect something beeing wrong, which still is the slice_param->slice_data_byte_offset
[22:29:43 CEST] <BtbN> the gst implementation does a lot of math to calculate that
[22:30:15 CEST] <BtbN> And with that beeing wrong i can totaly see it doing nothing usefull at all.
[22:30:17 CEST] <nevcairiel> that being wrong could result in a lot of brokenness
[22:30:29 CEST] <nevcairiel> cant you just add a debugg print into gst
[22:30:42 CEST] <BtbN> I haven't yet managed to get gst working at all.
[22:30:46 CEST] <nevcairiel> oh
[22:30:53 CEST] <nevcairiel> so you dont even know if your driver works
[22:30:55 CEST] <nevcairiel> much fun
[22:30:55 CEST] <nevcairiel> :D
[22:30:58 CEST] <BtbN> Not because of libva stuff, but because of it beeing gst.
[22:31:09 CEST] <BtbN> So yeah, i have basicaly no idea if the driver actualy works.
[22:31:52 CEST] <BtbN> I'm still a bit annoyed that this NUC is faster than my big desktop.
[22:32:04 CEST] <nevcairiel> lol
[22:32:18 CEST] <nevcairiel> the only nuc i have around is some atom cpu
[22:32:50 CEST] <BtbN> It's running at only half the clock rate of my desktop, which is a snb i5
[22:32:59 CEST] <BtbN> But it beeing the latest cpu generation more than compensates that
[22:33:09 CEST] <nevcairiel> then it really shouldnt be faster
[22:33:19 CEST] <nevcairiel> not at half clock speed
[22:33:24 CEST] <nevcairiel> there wasnt a 100% increase from snb
[22:33:43 CEST] <BtbN> Building ffmpeg on my desktop takes 9 minutes.
[22:33:45 CEST] <BtbN> On the nuc it's 7
[22:33:59 CEST] <BtbN> So no idea which part of the system is faster, but it is
[22:34:09 CEST] <BtbN> Can't be only the CPU
[22:34:28 CEST] <nevcairiel> code on your main system on a ssd?
[22:34:34 CEST] <BtbN> tmpfs on both
[22:34:38 CEST] <nevcairiel> hm
[22:37:20 CEST] <jamrial> nevcairiel: i think the problem with saste's patch wasn't the fact it was inline asm but that getting it to choose at runtime if it should use sse2 or sse4 was proving to be difficult
[22:37:59 CEST] <philipl> BtbN: use mpv for testing.
[22:38:13 CEST] <nevcairiel> its a function that runs once per frame, just make it branch
[22:38:17 CEST] <philipl> It has vaapi display support and is thin enough to comprehend
[22:38:43 CEST] <nevcairiel> (and severly limit the scope and definition of that function, don't try to build something overly generic)
[22:39:20 CEST] <nevcairiel> worst case, make it an actual dsp module like the other simd things in avutil
[22:39:27 CEST] <philipl> BtbN: So that offset is meant to be where the data starts after the slice header?
[22:39:33 CEST] <BtbN> philipl, but does it support vaapi hevc?
[22:39:58 CEST] <BtbN> philipl, http://cgit.freedesktop.org/vaapi/libva/tree/va/va_dec_hevc.h#n259
[22:40:31 CEST] <philipl> BtbN: output support should be completely generic.
[22:40:37 CEST] <philipl> (in mpv)
[22:40:50 CEST] <philipl> so yeah, it should work immediately. wm4 can comment, but that's how it is for vdpau
[22:41:10 CEST] <BtbN> Anyone happens to know where the gstreamer-vaapi repo went, after gitorious went down?
[22:41:28 CEST] <philipl> I think it's on __gb__'s github now
[22:42:01 CEST] <philipl> BtbN: that's one of the worst descriptions of anything I've ever seen.
[22:42:19 CEST] <BtbN> exactly
[22:42:43 CEST] <BtbN> https://github.com/gbeauchesne/gstreamer-vaapi/blob/master/gst-libs/gst/vaapi/gstvaapidecoder_h265.c#L2477
[22:42:46 CEST] <BtbN> that's what gst does there
[22:42:49 CEST] <BtbN> quite a bit of calculation
[22:44:06 CEST] <nevcairiel> hm yeah because it has to undo the emulation prevention bytes
[22:44:22 CEST] <nevcairiel> everything else is straight forward
[22:44:44 CEST] <BtbN> https://github.com/BtbN/FFmpeg/blob/vaapi_hevc/libavcodec/vaapi_hevc.c#L341 that's what i'm currently doing there
[22:45:41 CEST] <philipl> Well - your divide by 8 could produce different results
[22:46:03 CEST] <philipl> You need to divide each part separately to get the same result as the gst code, I think
[22:46:12 CEST] <BtbN> How else would i get from bits to bytes?
[22:46:28 CEST] <nevcairiel> the gst code only divides the header size as well
[22:46:37 CEST] <nevcairiel> nal_header_bytes is always 2?
[22:46:47 CEST] <philipl> Is that supposed to be the start code?
[22:46:56 CEST] <BtbN> I add the 2 because the ffmpeg code starts the getbits context at data + 2
[22:47:09 CEST] <BtbN> because it already read the nal header
[22:47:30 CEST] <philipl> Ok, so then you're missing the emulation prevention byte adjustment
[22:47:34 CEST] <nevcairiel> you should go kill someone at intel for requiring the long slice header struct
[22:47:48 CEST] <philipl> One can only imagine how their hardware works.
[22:47:52 CEST] <BtbN> the LongSliceFlags?
[22:48:03 CEST] <nevcairiel> vdpau and dxva are happy without it, so the drivers have to somehow know how to do it
[22:48:04 CEST] <wm4> wait what
[22:48:28 CEST] <philipl> wm4: wait what what? :-)
[22:48:46 CEST] <wm4> <philipl> so yeah, it should work immediately. wm4 can comment, but that's how it is for vdpau <- libavcodec's vaapi support has no generic codec support, so a small patch to mpv is required to make vaapi HEVC decoding work
[22:48:47 CEST] <nevcairiel> all dxva tells the hardware about the slice is its size in bytes =p
[22:49:03 CEST] <philipl> wm4: If BtbN adds vaapi hevc to ffmpeg, it should Just Work(tm) in mpv right?
[22:49:19 CEST] <philipl> wm4: Ah ok.
[22:49:19 CEST] <wm4> philipl: no, because there's no generic support for vaapi codec init
[22:49:23 CEST] <wm4> unlike vdpau has now
[22:49:39 CEST] <wm4> but it looks like __gb__ wanted to improve the lavc vaapi API into this direction
[22:49:45 CEST] <nevcairiel> .. and vdpau slices are equally simple, just data and size
[22:49:55 CEST] <nevcairiel> so screw you intel for making vaapi extra super duper complex
[22:50:11 CEST] <wm4> actually, mpv could try to init vaapi with HEVC anyway... it just won't work
[22:50:38 CEST] <philipl> BtbN: so anyway, how are the emulation prevention bytes handled in ffmpeg?
[22:50:48 CEST] <philipl> You aren't accounting for them, so is something else doing that?
[22:50:49 CEST] <BtbN> I have no idea, i haven't found that part yet
[22:51:01 CEST] <BtbN> There is no notion of them anywhere
[22:51:51 CEST] <philipl> https://en.wikipedia.org/wiki/Network_Abstraction_Layer
[22:51:59 CEST] <philipl> They seem to be a NAL thing
[22:52:30 CEST] <nevcairiel> BtbN: ff_hevc_extract_rbsp in hevc_parse.c will remove emulation bytes and fill HEVCNAL
[22:52:52 CEST] <nevcairiel> but there is no way to do what you want
[22:53:12 CEST] <philipl> Can't it save the number of bytes and then he can use the count?
[22:53:25 CEST] <nevcairiel> but it wouldnt know where the header ends and the slice starts
[22:53:29 CEST] <nevcairiel> because its the same NAL
[22:53:42 CEST] <philipl> This shit makes my head hurt
[22:53:58 CEST] <philipl> The correct solution is to write a new parser
[22:54:03 CEST] <BtbN> The worst part of it is that i don't even fully understand what offset vaapi wants there
[22:54:16 CEST] <nevcairiel> well that part seems easy
[22:54:30 CEST] <nevcairiel> the offset to the slice data in the escaped buffer
[22:54:38 CEST] <nevcairiel> .. but ffmpeg never handles the e scaped buffer
[22:54:43 CEST] <nevcairiel> it un-escapes it and handles that
[22:55:19 CEST] <nevcairiel> so any offsets avcodec gives you are in the un-escaped buffer without the emulation prevention
[22:56:00 CEST] <nevcairiel> i had to augment HEVCNAL to actually keep a reference to the original bitstream so i can pass it to the hardware
[22:56:09 CEST] <nevcairiel> but i luckily never needed such offsets
[22:57:34 CEST] <BtbN> hm
[22:58:40 CEST] <philipl> nevcairiel: So if you retain the reference to the original bitstream, and you can count the bytes as part of constructing the unescaped stream, isn't that enough to work this out?
[22:59:09 CEST] <philipl> The header byte count is accurate right?
[22:59:30 CEST] <nevcairiel> but it doesnt know where he header ends
[22:59:35 CEST] <nevcairiel> the*
[22:59:49 CEST] <nevcairiel> since its a generic function to un-escape things
[23:00:10 CEST] <philipl> because the header might have escaped bytes in it?
[23:00:30 CEST] <nevcairiel> sure, otherwise you could just assume both offests are the same :)
[23:00:38 CEST] <nevcairiel> (which I would probably do for now and worry later)
[23:01:16 CEST] <philipl> Well, the current code assumes the byte count is zero, so that's perhaps not working :-)
[23:02:26 CEST] <philipl> Build a mapping of escaped bytes to their offset in the stream and then after you know the header size, see how many escaped bytes were in it.
[23:03:06 CEST] <nevcairiel> thats a lot of crap for one peculiar hwaccel
[23:03:09 CEST] <wm4> philipl, BtbN: I added the hevc/vaapi profile entries to mpv, if you'd like to use that for testing
[23:03:27 CEST] <BtbN> propably a bit more leightweight than kodi
[23:03:37 CEST] <nevcairiel> i still say hunt down the intel engineer that thought this structure is a good idea
[23:03:48 CEST] <nevcairiel> i bet he was just lazy and didnt want to build parsing
[23:04:07 CEST] <BtbN> The last time i talked with them they shouted at me for asking for a better api.
[23:04:49 CEST] <BtbN> Something along the lines of me obviously having never used any video hardware acceleration api. Because that's how they work.
[23:04:58 CEST] <nevcairiel> its not like its the first time this happened, on windows intel was the only vendor that required long slice structures for h264 as well for a very long time
[23:05:09 CEST] <nevcairiel> they got their act together a few years ago though
[23:05:15 CEST] <wm4> BtbN: except dxva, vdpau, and videotoolbox don't, hehe
[23:05:28 CEST] <BtbN> And nvenc...
[23:05:35 CEST] <BtbN> Their encoding api is also a giant pile of bullshit
[23:05:38 CEST] <nevcairiel> .. and for hevc, MS didnt even specify a long slice struct anymore
[23:05:51 CEST] <philipl> __gb__ never gets involved in these conversations...
[23:06:10 CEST] <nevcairiel> maybe he is the certain engineer =p
[23:06:22 CEST] <BtbN> In the vaapi encoding api you have to generate the NAL, and pass it to libva
[23:06:25 CEST] <philipl> heh
[23:06:37 CEST] <BtbN> Which was already a mess for h264
[23:06:40 CEST] <wm4> nevcairiel: or he knows the certain engineer and doesn't want to involved in a shit-match
[23:06:43 CEST] <wm4> +get
[23:06:46 CEST] <BtbN> don't even want to think about how that is supposed to work for hevc
[23:07:06 CEST] <philipl> qsv!
[23:07:27 CEST] <BtbN> libyami
[23:07:32 CEST] <JEEB> libdarkness
[23:08:47 CEST] <wm4> JEEB: what BtbN  gets is green and white, not darkness, though
[23:09:24 CEST] <BtbN> Nah, green and white is gone. It's just nothing now
[23:33:13 CEST] <BtbN> Hm, if I only knew how to make gst at least try to decode hevc with vaapi
[23:33:59 CEST] <philipl> BtbN: playbin doesn't work?
[23:34:24 CEST] <BtbN> I have no idea about gst at all
[23:35:57 CEST] <BtbN> "gst-launch-1.0 playbin uri=file:///home/btbn/tos-1720x720-cfg01.mkv" seems to work. And it also initializes libva. So I assume it's working.
[23:36:38 CEST] <philipl> there you go.
[23:36:51 CEST] <BtbN> So at least the driver is alive
[23:37:21 CEST] <philipl> does that play the video?
[23:37:26 CEST] <BtbN> yep
[23:37:52 CEST] <BtbN> with notably lower CPU usage
[23:38:00 CEST] <philipl> then you're good :-)
[23:38:20 CEST] <BtbN> So mpv-9999 it is
[23:38:27 CEST] <BtbN> To rule out kodi for now
[23:38:31 CEST] <philipl> yep
[23:40:08 CEST] <wm4> if you think something strange is going on after the decoder (and with display), try --hwdec=vaapi with --vo=vaapi, and --hwdec=vaapi-copy
[23:40:27 CEST] <nevcairiel> hm, anyone have any experience with multimedia apps on osx? any hints how i can get my app to get something like multimedia priority so the OS wont make the sound cut out when i do something simple like open another app? =p
[23:41:11 CEST] <BtbN> yes, i actualy remember having to deal with that before, one second
[23:42:29 CEST] <wm4> nevcairiel: I don't think I ever needed something like that, but good question
[23:43:01 CEST] <nevcairiel> on windows  there is an explicit API to tell the OS "I'm multimedia, make me run good" and it usually is all you need to do :d
[23:43:20 CEST] <nevcairiel> but some users complaining that sound cuts out on osx when they do the simplest things
[23:43:35 CEST] <wm4> nevcairiel: what's that API, maybe I should use it...
[23:43:43 CEST] <wm4> hm just add more buffering
[23:44:02 CEST] <nevcairiel> apparently the thread feeding coreaudio is not getting enough time
[23:44:03 CEST] <wm4> let your coreaudio callback read from a ringbuffer
[23:44:30 CEST] <nevcairiel> and for windows, lookup MMCSS (multimedia class scheduling service or something)
[23:45:12 CEST] <BtbN> nevcairiel, https://github.com/jp9000/obs-studio/blob/master/libobs/util/platform-cocoa.m#L206
[23:45:26 CEST] <wm4> interesting, didn't even know this exists
[23:45:51 CEST] <wm4> (to both)
[23:46:05 CEST] <nevcairiel> interesting, thanks
[23:46:09 CEST] <nevcairiel> I'll g ive it a try tomorrow
[23:46:39 CEST] <BtbN> That was added for the exact same problems you just described
[23:47:06 CEST] <nevcairiel> SO says its only for app-nap, which we tried to have the user disable manually
[23:47:10 CEST] <nevcairiel> but maybe they screwed up
[23:48:27 CEST] <wm4> clearly Linux is superior, it doesn't need such things
[23:50:02 CEST] <BtbN> mpv with --vo=vaapi shows the same nothing kodi does
[23:50:12 CEST] <BtbN> nothing as in "what was on the screen there previously"
[23:52:18 CEST] <wm4> nice
[23:52:33 CEST] <wm4> what hevc profile is the clip using?
[23:52:50 CEST] <BtbN> Stream #0:0(eng): Video: hevc (Main), yuv420p(tv), 1720x720, SAR 1:1 DAR 43:18, 24 fps, 24 tbr, 1k tbn, 1k tbc (default)
[23:53:46 CEST] <BtbN> Is there anything besides Main?
[23:53:59 CEST] <nevcairiel> Main10
[23:54:31 CEST] <nevcairiel> but no, the profiles are  much si mpler than in h264
[23:54:41 CEST] <BtbN> But they introduced tiers instead
[23:54:42 CEST] <nevcairiel> Main, Main 10, Main 12, Main 422 10 .... etc
[23:55:26 CEST] <nevcairiel> tiers dont change coding tools t hough, its just like levels - arbitrary DPB and bitrate limits
[23:55:43 CEST] <wm4> for anything other than main, special surface allocation might be required etc. (well who knows)
[23:55:58 CEST] <BtbN> vaapi only supports main anyway i think
[23:57:13 CEST] <BtbN> It does decode some frames if i leave it running. But it's only garbage.
[23:58:58 CEST] <BtbN> This slice byte offset thing is the only reason i can think of for that.
[23:59:36 CEST] <BtbN> I'll just grab the right value for the first frame from gst, and hardcode it into ffmpeg.
[00:00:00 CEST] --- Tue Aug 25 2015