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

[burek]

[00:09:24 CEST] <cone-368> ffmpeg 03Carl Eugen Hoyos 07master:40b7e6071815: lavf/amr: Make the heuristic for auto-detection even stricter.
[00:24:58 CEST] <kierank> why is musl 32-bit undocumented
[01:08:31 CEST] <January> kierank: lol, musl is fun. They removed the float in malloc stuff iirc now btw
[01:19:20 CEST] <January> kierank: what you need docs with 32bit musl
[01:19:31 CEST] <kierank> no
[01:20:26 CEST] <January> they didnt remove the float stuff? i admit i didnt actually check the code
[09:44:34 CEST] <ubitux>  /g 17
[09:44:36 CEST] <ubitux> oups
[13:20:41 CEST] <jdarnley> Can someone familiar with wavelets, dirac, and assembly point out why this commit gives an inverted/negative picture?
[13:20:44 CEST] <jdarnley> https://gitlab.com/J_Darnley/ffmpeg/commit/6fbb656dfcdf04c473645a67caa291568d6a2993
[13:21:13 CEST] <jdarnley> atomnuker: that ^^ might only be you.  Can you have a look?
[13:27:46 CEST] <atomnuker> does multiplying by -1 fix the output?
[13:41:02 CEST] <jdarnley> Not completely.  Still some  problems but at least the picture isn't negative.
[13:41:58 CEST] <jdarnley> I must be loading the wrong data somewhere.
[13:44:52 CEST] <atomnuker> do you make any assumption about coefficient ranges?
[13:44:53 CEST] <jdarnley> And that is almost certainly in the high loop because the picture looks great if I return after the low loop.
[13:45:10 CEST] <jdarnley> None that the C isn't making.
[13:46:03 CEST] <jdarnley> But the coeffs shouldn't be that large because I'm only doing 1 decomposition(?)
[13:46:48 CEST] <jdarnley> Oh actually the C makes casts from int to unsigned but I think that was only to make fuzz testing happy.
[13:47:09 CEST] <jdarnley> or ubsan or whatever
[13:51:53 CEST] <atomnuker> yeah, I don't see anything wrong, you're doing ops on 32 bit ints
[13:52:07 CEST] <atomnuker> sounds like you might be loading the wrong data though
[13:52:47 CEST] <atomnuker> I'd implement the c version part by part in the wrapper code you have and see where they diverge
[18:29:58 CEST] <jerkoo> Compn: you need to get heic / hfif support in ffmpeg for the apple people with their apple photos. microsoft is charging people $1 to be able to decode this standard format in windows 10
[18:30:28 CEST] <jerkoo> maybe durandal_1707 will do this... there is a patch on the trac ?
[18:31:04 CEST] <jerkoo> https://trac.ffmpeg.org/ticket/6521
[18:32:07 CEST] <jerkoo> KODI is relying on usssssss
[18:32:18 CEST] <jerkoo> cant let kodi down
[18:32:41 CEST] <JEEB> the problem with HEIF is that it works against how the FFmpeg APIs work :P
[18:32:53 CEST] <JEEB> because they literally decided to stick separate videos
[18:33:13 CEST] <JEEB> in a single thing
[18:33:21 CEST] <jerkoo> so its like edit lists then 
[18:33:38 CEST] <JEEB> except edit lists aren't about making a mosaic?
[18:33:43 CEST] <JEEB> they're just a time line
[18:34:05 CEST] <JEEB> although you can do a lot of random things in edit lists, yes
[18:34:07 CEST] <jerkoo> oh you mean the image is made up of different parts
[18:34:10 CEST] <JEEB> yes
[18:34:20 CEST] <JEEB> so if you've got an API that says "give me the decoded image"
[18:34:27 CEST] <JEEB> you've suddenly gotten an issue
[18:34:40 CEST] <JEEB> because you've got multiple images and if you decode one, you only get that tile
[18:34:59 CEST] <jerkoo> so decode all of the tiles in order then stitch them together
[18:35:15 CEST] <JEEB> looking at that mojing comment it just looks like he exports the separate images and then uses libavfilter to put them together :P
[18:35:25 CEST] <jerkoo> yep
[18:35:30 CEST] <jerkoo> hack city, here we come
[18:36:16 CEST] <JEEB> the problem is that as far as the decoder is concerned these are 100% separate NAL units with video content
[18:36:42 CEST] <JEEB> there's an actual tiling feature in HEVC which would actually be a spec-compliant way of doing it
[18:36:51 CEST] <JEEB> buuut HEIF decided to not do it
[18:37:17 CEST] <jerkoo> what about just supporting the iphone heic version ?
[18:37:23 CEST] <jerkoo> which should be the biggest use case anyway
[18:37:33 CEST] <JEEB> I'm pretty sure those had tiles, too?
[18:37:38 CEST] <jerkoo> yes probably
[18:38:29 CEST] <JEEB> things like imagemagick can get this easily because they have both demuxing and decoding and all that jazz under one API more or less. now with FFmpeg you end up with awkwardness with how they did it
[18:38:52 CEST] <JEEB> the simplest is to just export the separate images, but how do you tell the API user that he's supposed to stitch the things together
[18:39:23 CEST] <JEEB> or then you add side data to AVPackets that say the tiled image size and each decoded image gets the image filled
[18:39:46 CEST] <JEEB> so you literally would need to still call the decode API N times before you start getting non-gray in the whole image
[18:40:32 CEST] <JEEB> because those are not HEVC tiles, they're completely separate samples in some lolhacky way
[18:40:50 CEST] <JEEB> I really loved how the GPAC dude finally did say the spec was convoluted and complex at the end of his HEIF talk
[18:41:17 CEST] <JEEB> "you could say that" was probably the understatement of a while
[18:41:42 CEST] <JEEB> also then there's the problem that HEIF is not at all limited to HEVC, although it's right now mostly used with it
[18:41:56 CEST] <atomnuker> we talked about this with rcombs for a bit, maybe the heif stream could just be treated as a tiled hevc stream and processed by a bsf
[18:42:11 CEST] <JEEB> so if you add the HEIF-specific hacks to the HEVC decoder, then you suddenly need to add them elsewhere as well
[18:42:29 CEST] <JEEB> atomnuker: ok, that sounds like another relatively sane and less "insane hack flags in the decoder" way
[18:42:38 CEST] <JEEB> if the images can be turned into tiles
[19:06:05 CEST] <mateo`> I confirm that the iphone variant of heif (heic) uses a tiled format (and this is why I totally gave up on supporting the format)
[19:07:05 CEST] <jerkoo> humm
[19:07:25 CEST] <jerkoo> need support, don't care about how hacky it will be :D
[19:07:48 CEST] <jerkoo> NEWS HEADLINE: theres a format ffmpeg does not support!
[19:08:42 CEST] <jerkoo> are there any third party libs we can just call in ?
[19:09:09 CEST] <JEEB> yea but those most likely are gonna be just worse in the compatibility side regarding HEVC features
[19:09:19 CEST] <mateo`> AVFoundation ? :D
[19:09:21 CEST] <JEEB> like imagemagick picked some random hevc decoder lib
[19:10:44 CEST] <atomnuker> BBB: we froze av1
[19:10:59 CEST] <jerkoo> so you dont want to have a demuxer which sends info to a filter to piece it back together ??
[19:11:06 CEST] <jerkoo> extra ? not meant.
[19:12:52 CEST] <atomnuker> BBB: put your repo up somewhere, I demand
[19:13:01 CEST] <jamrial> \o/
[19:14:10 CEST] <JEEB> jerkoo: it sounds like heif demuxer adding a flag to add a special bit stream filter that makes all of those things a proper tiled HEVC image might be the least insane path
[19:14:20 CEST] <JEEB> although I've no idea how possible that is
[19:14:39 CEST] <JEEB> the other thing is to have some insane side dat that says this is tile X out of Y tiles
[19:14:44 CEST] <jerkoo> to save the photo, we must burn it.
[19:19:19 CEST] <daddesio> "BBB: we froze av1"
[19:19:21 CEST] <daddesio> when was this?
[19:19:29 CEST] <daddesio> atomnuker: ^
[19:20:15 CEST] <BBB> atomnuker: <3
[19:23:19 CEST] <atomnuker> daddesio: a few minutes ago
[19:23:31 CEST] <JEEB> nice
[19:24:38 CEST] <atomnuker> I shall celebrate by going to the nearby store and getting myself a bottle of dom
[19:24:47 CEST] <atomnuker> or failing to find one, a 4 pack of stella artois
[20:19:29 CEST] <j-b> Indeed.
[21:20:09 CEST] <Shibe> is there any example of importing a dmabuf in a zero-copy way to a vaapi AVFrame
[21:31:09 CEST] <BtbN> you map them to vaapi frames, not import
[21:31:21 CEST] <Shibe> BtbN: doesnt that create an additional copy though?
[21:31:28 CEST] <Shibe> first mapping the frame and then transfering?
[21:31:32 CEST] <BtbN> it wouldn't be called mapping then.
[21:31:58 CEST] <Shibe> BtbN: so it's zero-copy? how?
[21:32:03 CEST] <Shibe> ive never done something like this before
[21:32:31 CEST] <BtbN> by just not copying the frame, but mappingit
[21:32:52 CEST] <Shibe> oh
[00:00:00 CEST] --- Sat Jun 23 2018