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

[burek]

[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-levels.pdf
[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/hurry.html
[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