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

burek burek021 at gmail.com
Sun Aug 20 03:05:04 EEST 2017


[00:01:01 CEST] <atomnuker> zlib instructions when
[00:01:03 CEST] <Gramner> they made the AES ones exist as both legacy and VEX. I expected new stuff to be VEX-only but they went legacy-only of all things?
[00:01:43 CEST] <TD-Linux> they have to be very careful with their power routing and "precharge"... otherwise you might droop the voltage of the core enough to cause glitches
[00:02:38 CEST] <atomnuker> you have capacitors everywhere to handle that
[00:03:31 CEST] <TD-Linux> yes but on chip capacitance is small. and some of that capacitance is in the thing you're powering up :)
[00:05:14 CEST] <TD-Linux> (I am kind of speculating because I'm not a chip designer. but such a thing is common at larger scales)
[00:36:33 CEST] <rcombs> is VEX longer?
[00:39:34 CEST] <nevcairiel> yes, but saner :p
[00:40:02 CEST] <Gramner> vex is the same length as legacy simd code in most cases
[00:40:33 CEST] <Gramner> evex is longer though, but has much more features so that's expected
[00:58:15 CEST] <iive> Gramner: don't worry, they will make VEX version, a bit later
[00:58:57 CEST] <iive> and it would probably need its own flag for detection :E
[01:11:39 CEST] <jamrial> rcombs: speaking of AES, what happened with your aes-ni patch?
[01:11:55 CEST] <jamrial> the cpu flag stuff was committed already
[01:11:59 CEST] <rcombs> it's been sitting on a branch forever
[01:12:18 CEST] <rcombs> mostly because& I guess it's not _that_ important to anybody? It's not like it'd be used for TLS
[01:12:30 CEST] <rcombs> just for a couple dumb DRM things
[01:13:22 CEST] <jamrial> i have committed plenty of shit nobody uses, so that's not an excuse to push something that works and makes a huge difference in performace :p
[01:13:56 CEST] <jamrial> s/push/not push/
[01:14:54 CEST] <jamrial> also, the flac cover art patch just needs a few small changes. it doesn't even depend on the segment and cuesheet patches
[01:16:51 CEST] <jamrial> iive: maybe they will make them vex at the same time they introduce sha3 instructions, so a new flag there will make sense
[01:16:58 CEST] <jamrial> does anything use sha3 for that matter?
[01:17:11 CEST] <iive> there is sha3?
[01:17:24 CEST] <iive> or is that sha512?
[01:17:36 CEST] <jamrial> no, sha512 is still sha2
[01:18:33 CEST] <jamrial> sha3 is a thing since late 2015 or so. but there was a lot of controversy regarding the algorith that won competition
[01:57:37 CEST] <rcombs> jamrial: no of course not, my excuse is that I'm lazy
[01:58:19 CEST] <rcombs> oh that reminds me, could someone review https://ffmpeg.org/pipermail/ffmpeg-devel/2017-August/214826.html
[01:58:26 CEST] <rcombs> in the field of things I actually do need
[09:26:41 CEST] <rcombs> this just in: HEIF is bad
[09:50:51 CEST] <mateo`> rcombs: sure it is, i've started working on adding support of it in lavc/mov, still picture with a simple layout are "ok". Things are starting to go crazy with the grid layout ... which will be the layout used by default by the apple phones with the upcoming release of iOS.
[09:51:01 CEST] <rcombs> mateo`: hi https://ffmpeg.org/pipermail/ffmpeg-devel/2017-August/215003.html
[09:51:20 CEST] <mateo`> @_@
[09:51:21 CEST] <rcombs> I haven't touched the layout shit at all
[09:51:51 CEST] <durandal_170> i added lerp function to lavu eval
[09:53:03 CEST] <mateo`> rcombs: I opened https://trac.ffmpeg.org/ticket/6521 when I started working on it
[09:53:27 CEST] <rcombs> I paid no attention and just jumped in :P
[09:53:37 CEST] <rcombs> it was fun!
[09:53:42 CEST] <rcombs> also extremely frustrating
[09:54:03 CEST] <rcombs> the whole ipco/ipma thing is batshit insane
[09:54:19 CEST] <mateo`> array of references everywhere
[09:54:29 CEST] <mateo`> with types
[09:54:55 CEST] <mateo`> ok, i will review your patch on Monday when I'm at work (i'll have my code to compare with yours)
[09:55:04 CEST] <rcombs> I call it "implementer-unfriendly" for a reason
[09:55:10 CEST] <rcombs> cool
[09:57:34 CEST] <mateo`> The issues with the grid layout is that the hevc tiles are independant to each other and we will need to find a way to expose it to either the decoder to recompose the final each (or maybe lavfilter)
[09:57:57 CEST] <mateo`> final +image
[09:58:00 CEST] <rcombs> that sounds very insane
[09:58:03 CEST] <rcombs> how is it actually used
[09:58:17 CEST] <rcombs> you said in iOS? I figured iOS was just going to produce regular single frames
[09:58:49 CEST] <mateo`> the samples a colleague gave to me where capture on iOS with the grid layout ...
[09:59:18 CEST] <mateo`> i can provide you such samples
[09:59:20 CEST] <rcombs> I haven't been able to get my phone (running iOS 11) to give me HEIFs at all
[09:59:32 CEST] <rcombs> it just gives me JPEGs with an HEIC extension
[09:59:35 CEST] <rcombs> ??????????
[09:59:52 CEST] <rcombs> it's not quite this bad though: https://b3n.org/psd-is-not-my-favourite-file-format/
[10:00:20 CEST] <mateo`> my heic files are mp4 + hevc
[10:01:12 CEST] <rcombs> I've got a few samples like that here
[10:01:22 CEST] <rcombs> but they just work with current lavf out-of-the-box
[10:01:32 CEST] <rcombs> ones with regular moovs
[10:03:09 CEST] <mateo`> see https://0x5c.me/sample.heic
[10:04:00 CEST] <mateo`> heic + grid layout
[10:04:42 CEST] <mateo`> "have fun" :D
[10:05:07 CEST] <rcombs> aww fuck, they've got infe before iloc
[10:05:22 CEST] <rcombs> whose idea was it for the order not to be fixed
[10:07:38 CEST] <mateo`> what I did in my wip is to store a memory representation of each new atoms iloc/infe/... in the MOVContext structure
[10:08:11 CEST] <mateo`> and process this representation at the end of mov_read_meta
[10:17:47 CEST] <mateo`> i introduced the following structure http://sprunge.us/JCTB
[10:19:00 CEST] <mateo`> I'll give a review on monday and send you my wip (i don't have the latest version with me atm and i'm just back from holidays)
[10:23:58 CEST] <rcombs> oh god
[10:24:28 CEST] <rcombs> I wrote a bit of extra code to handle the out-of-order elements (this wasn't hard) and the idat-offset data
[10:24:41 CEST] <rcombs> it's decoding now
[10:25:14 CEST] <mateo`> you are decoding the sample i gave to you ? :)
[10:25:47 CEST] <rcombs> https://gist.github.com/rcombs/fa1c860615fa9ee6620ef70f98c95084 please kill me
[10:26:05 CEST] <mateo`> hahahaha :D
[10:26:14 CEST] <rcombs> mateo`: yeah, as 48 512x512 tiles and some metadata
[10:26:23 CEST] <mateo`> yeah :)
[10:26:28 CEST] <rcombs> plus a 320x240 of what I presume is a thumbnail
[10:26:39 CEST] <rcombs> yeah this looks like fun
[10:26:42 CEST] <mateo`> yeah :)
[10:33:09 CEST] <rcombs> mateo`: yeah I've got no clue where the best place to reassemble these would be
[10:34:26 CEST] <rcombs> this whole format tries to do way too many things and makes it impossible to fit it into any existing workflow
[10:35:30 CEST] <mateo`> it should be exposed in such a way that external decoder (outside lavc) can use it
[10:35:51 CEST] <mateo`> in lavc an idea was to create a virtual hevc decoder
[10:36:11 CEST] <mateo`> but I have no idea if it can work
[10:37:32 CEST] <mateo`> auto inserting a filter to recompose the image is also something that can be considered
[10:37:43 CEST] <rcombs> that seems like it might be the least-insane thing
[10:37:55 CEST] <mateo`> yeah
[10:39:14 CEST] Action: mateo` afk for a bit
[10:39:59 CEST] <ubitux> this reminds me of the edit lists :3
[10:40:27 CEST] <ubitux> "where the fuck are we going to put that shit"
[10:41:44 CEST] <rcombs> yeah it's basically the same problem
[10:41:55 CEST] <rcombs> they decided to put post-decoder shit in the container
[10:45:36 CEST] <ubitux> libavpostdecoder
[10:46:21 CEST] <rcombs> libavjustdoeverything
[11:40:34 CEST] <durandal_170> gonna push pseudocolor filter soon tm
[12:45:24 CEST] <cone-595> ffmpeg 03Paul B Mahol 07master:e3a4afca07b2: avfilter: add pseudocolor filter
[12:45:24 CEST] <cone-595> ffmpeg 03Paul B Mahol 07master:1146133df811: avutil/eval: add linear interpolation helper
[15:49:23 CEST] <durandal_1707> nicolas is frustrating me
[16:07:02 CEST] <wm4> it's his job
[17:04:23 CEST] <kierank> J_Darnley: are you going to vdd
[17:09:53 CEST] <J_Darnley> No, I wasn't planning to.
[20:01:01 CEST] <durandal_1707> J_Darnley: why?, you must go, you will be missed
[23:43:29 CEST] <cone-106> ffmpeg 03Ivan Kalvachev 07master:43dab86bcd86: opus_pvq_search: Restore the proper use of conditional define and simplify the function name suffix handling.
[23:56:10 CEST] <kierank> J_Darnley: ok
[00:00:00 CEST] --- Sun Aug 20 2017


More information about the Ffmpeg-devel-irc mailing list