[00:02:47 CEST] <rcombs> dolby vision is just HDR10+ with more Brand" [00:03:36 CEST] <JEEB> wasn't HDR10+ samsung's edition? [00:03:42 CEST] <JEEB> while dolby vision was the other thing [00:03:48 CEST] <JEEB> https://kuroko.fushizen.eu/screenshots/smpte/st2094_apps1_4.png [00:03:54 CEST] <JEEB> app 1 was dolby (dolby vision) [00:04:00 CEST] <JEEB> app 4 was samsung (hdr10+) [00:04:16 CEST] <nevcairiel> dolby vision is more then that [00:04:24 CEST] <nevcairiel> they hide a whole stack of tech behind that name [00:04:25 CEST] <JEEB> they had N different profiles for it [00:04:39 CEST] <JEEB> https://www.dolby.com/us/en/technologies/dolby-vision/dolby-vision-profiles-... [00:05:01 CEST] <nevcairiel> they also have some hacks to transport that over lower hdmi versions by encoding it into the image data [00:05:43 CEST] <nevcairiel> noone is going to mind a few pixels with metadata in them right ? :D [00:05:48 CEST] <JEEB> :D [00:07:04 CEST] <nevcairiel> in hevc they also have this dual layer concept where you h ave the hdr info as a secondary layer you need to decode using a proprietary dolby NAL prefix [00:07:19 CEST] <nevcairiel> its not just a different expression of smpte st 2094 metadata [00:07:19 CEST] <JEEB> yup [00:07:30 CEST] <JEEB> the profiles go over those things [00:07:44 CEST] <JEEB> base layer and enhancement layer [00:26:16 CEST] <rcombs> yeah but most dolby vision is decodeable as HDR10+ [00:26:36 CEST] <rcombs> or so they told me [00:26:54 CEST] <rcombs> there are a bunch of profiles but the most commonly-used ones are compatible [00:27:20 CEST] <rcombs> in-band signaling sure is on-brand for them, though [00:43:41 CEST] <TD-Linux> certainly the dual later hevc wouldn't be [00:46:33 CEST] <JEEB> yea, dual layer avc/hevc was custom [00:46:53 CEST] <JEEB> I've got some MPEG-TS sample of dolby vision but I've been :efff: to look into how that's coded [00:47:04 CEST] <JEEB> it didn't seem to be PQ/BT.2020 at least [10:38:50 CEST] <jya> hi.. I'm investigating a bug reported to us (https://bugzilla.mozilla.org/show_bug.cgi?id=1486080). Now why we it now be required to allocate memory in a particular way (and worse have it automatically freed) when the doc has clearly stated for years that it was up to the user to allocate and free? [10:43:59 CEST] <nevcairiel> its just how it has always worked, you just never hit one of those cases before, now you do [10:54:06 CEST] <jya> nevcairiel: the doc should be amended then [10:56:17 CEST] <cone-220> ffmpeg 03Zhong Li 07master:d91370e0f12a: lavc/encode: fix frame_number double-counted [14:11:50 CEST] <durandal_1707> atomnuker: you cant review new 2 decoders for some reason? [15:08:58 CEST] <nevcairiel> hrm who broke checkasm once again [15:11:14 CEST] <durandal_1707> it works here [16:36:35 CEST] <cone-426> ffmpeg 03Avi Halachmi (:avih) 07master:58b81ac621ae: configure: speed up flatten_extralibs_wrapper() [16:36:35 CEST] <cone-426> ffmpeg 03Avi Halachmi (:avih) 07master:923586a58f37: configure: speed up print_enabled_components() [16:36:35 CEST] <cone-426> ffmpeg 03Avi Halachmi (:avih) 07master:45499e557c80: configure: speed up check_deps() [16:36:45 CEST] <jamrial> configure is no longer a pain to run [16:37:11 CEST] <JEEB> \o/ [16:37:21 CEST] <iive> under windows too? [16:37:28 CEST] <JEEB> yes, the time is now really cut [16:37:36 CEST] <JEEB> there were some msys2 numbers in the ML messages [16:37:39 CEST] <iive> nice [16:37:44 CEST] <JEEB> aka closer to a minute than 10 [16:37:45 CEST] <JEEB> lol [16:38:26 CEST] <jamrial> iive: real 3m30.198s [16:38:31 CEST] <jamrial> On win10 [16:38:40 CEST] <jamrial> it was 16 min before [16:38:49 CEST] <jamrial> or worse [16:41:43 CEST] <JEEB> yup [16:41:49 CEST] <JEEB> I completely stopped building on windows because of it :D [16:49:49 CEST] <atomnuker> durandal_1707: yeah, I'll review them tonight [16:50:10 CEST] <atomnuker> one thing which stood out: frame->key_frame = rle_uncompress(.... [16:50:28 CEST] <atomnuker> you run an unpack all over again to get a flag [16:51:10 CEST] <atomnuker> oh nvm, you write to the bytestream when you do that which writes to frame->data [16:56:12 CEST] <BtbN> I'm kinda expecting this to break on some occasions [16:56:21 CEST] <BtbN> But it's a good starting point [17:06:00 CEST] <BtbN> dash ./configure --disable-doc 28,89s user 36,35s system 63% cpu 1:42,42 total [17:06:11 CEST] <BtbN> That's on cygwin [17:26:29 CEST] <kierank> not bad at all [20:05:16 CEST] <kurosu> nice, configure taking 1m30s [20:05:37 CEST] <atomnuker> on windows? [20:05:43 CEST] <kurosu> yes, win7 x64 [20:06:00 CEST] <atomnuker> nice, didn't it take like 15 minutes before? [20:06:11 CEST] <kurosu> I think this is Win10 [20:06:28 CEST] <kurosu> I can't remember the last time measured [20:06:41 CEST] <kurosu> probably in my logs when the python script was being discussed [20:07:10 CEST] <kurosu> bah, local history doesn't go that far [20:07:22 CEST] <nevcairiel> it was about 15-20 minutes on windows before, so thats nice [20:07:26 CEST] <JEEB> atomnuker: yea it was 10-15min until then :D [20:07:34 CEST] <JEEB> so that change was very nice speed-wise [20:10:07 CEST] <kurosu> 4m15 [20:12:00 CEST] <kurosu> eh, except I was clocked much higher [20:12:10 CEST] <kurosu> s/I/CPU [20:19:40 CEST] <cone-704> ffmpeg 03Mark Thompson 07master:2fd962efbaf4: vaapi_encode_h264: Move options and common structures into context [20:19:40 CEST] <cone-704> ffmpeg 03Mark Thompson 07master:46d1313fcd31: vaapi_encode_h265: Move options and common structures into context [20:19:40 CEST] <cone-704> ffmpeg 03Mark Thompson 07master:2c3ad16d3e6e: vaapi_encode_mjpeg: Move common structure into context [20:19:40 CEST] <cone-704> ffmpeg 03Mark Thompson 07master:537d6aa30ebc: vaapi_encode_mpeg2: Move common structure into context [20:19:40 CEST] <cone-704> ffmpeg 03Mark Thompson 07master:58d3ac31c8a4: vaapi_encode_vp8: Move options and common structures into context [20:19:41 CEST] <cone-704> ffmpeg 03Mark Thompson 07master:1616106f1168: vaapi_encode_vp9: Move options and common structures into context [20:19:41 CEST] <cone-704> ffmpeg 03Mark Thompson 07master:c5b4ad247b9d: vaapi_encode: Remove common priv_data and options fields [20:19:42 CEST] <cone-704> ffmpeg 03Mark Thompson 07master:38ec5b4aa473: vaapi_encode: Factorise out adding global parameters [20:29:53 CEST] <jamrial> jkqxz: if you don't get reviews for the remaining vaapi stuff (not a lot of active devs using it maybe?) then just push them [20:30:00 CEST] <jamrial> most of those patches are months old by now [20:33:54 CEST] <atomnuker> yeah, I did take a look at the patch which ported vaapi to the new decode api and it looked okay [20:34:24 CEST] <BBB> jamrial: did you consider attending vdd this year? please please please [20:34:39 CEST] <BBB> (Im finally in the correct timezone again, allowing me to badger you to no end) [20:35:12 CEST] <atomnuker> durandal_1707: you too ^^, there's still time, the register link does allow you to get sponsored still [20:35:13 CEST] <j-b> +1 [20:35:27 CEST] <j-b> jamrial: jkqxz: durandal_1707: plz plz plz, come :) [20:35:56 CEST] <atomnuker> but don't open the webpage, they've stuck a picture of me, I'm hideous :) [20:36:27 CEST] <BBB> just say the picture is old [20:37:13 CEST] <BBB> and yes, others should come also, come on guys, its fun [20:37:19 CEST] <j-b> atomnuker: please send me another one [20:37:20 CEST] <j-b> BBB: same [20:37:38 CEST] <BBB> that presumes I can find a picture of me that is not ugly [20:37:54 CEST] <BBB> its ok, Ill live with the old one and just use its oldness as an excuse [20:39:32 CEST] <durandal_1707> atomnuker: zlib checks if there is enough buffer size, and in that case it will error out as it should [20:39:35 CEST] <JEEB> yes, I'd love to see durandal_1707 and share words <3 [20:40:49 CEST] <JEEB> mostly thanks :D [20:40:55 CEST] <durandal_1707> j-b said there are guards, i cant go [20:41:01 CEST] <JEEB> there's no need [20:41:09 CEST] <JEEB> it's nerds and everyone's under the CoC [20:41:24 CEST] <JEEB> /geeks/whatever [20:41:29 CEST] <kurosu> I believe vdd helps people see through the mail/irc persona, and generally improves relationships afterwards [20:41:37 CEST] <JEEB> yes [20:42:01 CEST] <kurosu> considering how prolific and essential jamrial and durandal_1707 have become, it seems really a miss they don't come [20:42:01 CEST] <atomnuker> durandal_1707: should be fine then [20:42:24 CEST] <durandal_1707> i already stated my position regarding vdd location [20:42:45 CEST] <pasouza> atomnuker: could you please give you opinion on the patch (https://patchwork.ffmpeg.org/patch/10037/) when you have time [20:43:20 CEST] <atomnuker> durandal_1707: dude, its the only technical conference in europe [20:43:24 CEST] <kurosu> durandal_1707, you never travel? Don't you want to meet some people? not everyday ones, but maybe people like kostya? [20:50:03 CEST] <j-b> even Kostya came to VDD [20:50:07 CEST] <j-b> and Jason! [20:50:31 CEST] <j-b> and security is to help you, not annoy you. [20:52:13 CEST] <atomnuker> jason has been to a vdd? wasn't the first one in ireland only a few years ago? [20:52:35 CEST] <j-b> yes, he even went to the Louvre [20:52:38 CEST] <j-b> with Lydia [20:52:50 CEST] <j-b> I think it was the year before ireland [20:54:17 CEST] <JEEB> yea I think he was around 2010/2011 [20:54:27 CEST] <atomnuker> what about pengvado? [20:54:44 CEST] <JEEB> that ninja :D [20:56:15 CEST] <atomnuker> I've scanned all the chatlogs I have, never seen him utter a single word :/ [20:56:57 CEST] <JEEB> Freenode/#x264dev.log:33 [20:57:24 CEST] <atomnuker> ah, well, that's one channel I'm not in [20:59:13 CEST] <durandal_1707> kurosu: i generally avoid people [21:00:34 CEST] <atomnuker> good choice in case there are self-checkout machines, but those won't be supermarket clerks you're meeting, but other experts on video coding [21:05:20 CEST] <durandal_1707> av_image_fill_black is useless [21:05:33 CEST] <JEEB> orly? [21:05:36 CEST] <durandal_1707> why it uses ptrdiff for linesize? [21:05:36 CEST] <JEEB> I thought it was a nice helper [21:05:57 CEST] <durandal_1707> libavcodec/wcmv.c:67:42: warning: incompatible pointer types passing 'int [8]' to parameter of type 'const ptrdiff_t *' (aka 'const long *') [-Wincompatible-pointer-types] [21:06:05 CEST] <kurosu> durandal_1707, why should it not ? [21:06:25 CEST] <kurosu> I think because of win64, ptrdiff_t is now favored for pointer offsets [21:06:44 CEST] <kurosu> (high 32bits of 64 regs not being cleared/... by Win64 ABI) [21:06:44 CEST] <durandal_1707> but frame linesize is int[8] [21:06:52 CEST] <kurosu> ah, ok, yes [21:06:55 CEST] <kurosu> legacy code [21:07:20 CEST] <kurosu> at some point, I would expect frame linesize to also become ptrdiff_t [21:07:30 CEST] <atomnuker> I don't think we can change the type of a variable without deprecating it and making a new one [21:07:40 CEST] <atomnuker> thankfully frame->stride is still up for grabs [21:16:05 CEST] <gnafu> If someone wanted to sponsor me and pay for the travel, I'd love to go to VDD as Resident Fanboi or something ;-D. [21:16:53 CEST] <atomnuker> if we do deprecate frame->linesize pretty much 100% of our code + 100% of api users will have to change their code too, so when we bump major eventually it'll be an apocalypse [21:20:34 CEST] <durandal_1707> gnafu: post few patches to ffmpeg/videolan/libav and you will be sponsored [21:22:46 CEST] <gnafu> durandal_1707: Maybe someday :-). Anyway, I don't have a passport and probably couldn't get one in time even if I could go :-P. [21:23:21 CEST] <durandal_1707> you live in north korea? [21:23:56 CEST] <gnafu> durandal_1707: No, but close. USA. I've never traveled internationally, so I never needed a passport. I suppose I might be able to get one in a month, but I've always had the impression it can take a while. [21:24:12 CEST] <gnafu> I really should get one just so I can be ready for something like that. [21:57:41 CEST] <BradleyS> https://travel.state.gov/content/travel/en/passports/apply-renew-passport/hu... [21:58:11 CEST] <BradleyS> gnafu: ^ [22:01:09 CEST] <gnafu> BradleyS: Thanks :-). [22:01:15 CEST] <BradleyS> ;) [22:01:54 CEST] <j45> I just did that a couple of weeks ago. Took 1 week from the day I sent in the application [22:02:31 CEST] <BradleyS> E_NOTHREAT [22:07:58 CEST] <cone-704> ffmpeg 03Paul B Mahol 07master:f7d749e95b93: avcodec: add MatchWare Screen Capture Codec [22:07:59 CEST] <cone-704> ffmpeg 03Paul B Mahol 07master:ad2ac1e7dd90: avcodec: add WinCAM Motion Video decoder [22:11:10 CEST] <atomnuker> bofh_: ping [23:36:07 CEST] <cone-704> ffmpeg 03Shiyou Yin 07master:e13e52fd0de6: configure: [loongson] revert no-expensive-optimizations [00:00:00 CEST] --- Tue Aug 28 2018