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

[burek]

[02:03:41 CEST] <CounterPillow> 4.0 when
[14:48:45 CEST] <durandal_1707> atomnuker: ping for atrac9 and fft non power of 2
[14:49:20 CEST] <atomnuker> felt like utter crap for the last 2 days, I'm better today
[14:55:48 CEST] <JEEB> that sucks, hope you get better
[14:57:11 CEST] <durandal_1707> atomnuker: what you eat?
[15:01:53 CEST] <JEEB> oh hey
[15:01:58 CEST] <JEEB> HEIF now has conformance files
[15:01:59 CEST] <JEEB> lol
[15:01:59 CEST] <JEEB> https://github.com/nokiatech/heif_conformance
[15:03:49 CEST] <JEEB> also another MPEG thin
[15:03:51 CEST] <JEEB> Multi-Image Application Format (MIAF)
[15:31:20 CEST] <JEEB> question on the libvpx and libaom wrappers
[15:32:10 CEST] <JEEB> ok, never mind :D I was searching for keyframe but the flag is "AV_PKT_FLAG_KEY"
[15:32:13 CEST] <JEEB> d'uh
[19:50:37 CEST] <jkqxz> Is there anywhere which tracks how well the AV1 specification matches what libaom actually does?
[19:51:44 CEST] <jkqxz> libaom is a really terrible reference for the bitstream because it doesn't use the same names or structure as the specification and the decoder/encoder logic is all mixed into the bitstream stuff.
[19:52:08 CEST] <thardin> there is another encoder also. might be good to compare them maybe?
[19:57:14 CEST] <jkqxz> rav1e?  It hard-codes everything at the top level, so not much help - e.g. <https://github.com/xiph/rav1e/blob/master/src/lib.rs#L245>.
[20:01:04 CEST] <jamrial> jkqxz: the spec should match libaom perfectly, seeing every commit to it references some bug # which in turn references some libaom commit
[20:01:47 CEST] <jamrial> libaom however atm has some stuff unimplemented, reading some bitstream values into the void during parsing
[20:02:35 CEST] <jamrial> like the HDR stuff (mastering, content light, etc)
[20:05:51 CEST] Action: JEEB succeeded in his first aarch64 boot
[20:06:09 CEST] <JEEB> fedora 28 beta aarch64 image which boots nicely on rpi3 :)
[20:06:59 CEST] <atomnuker> the frame types and how they need to be organized will be pure masochism
[20:08:18 CEST] <atomnuker> I think you can pack 2 keyframes in 1 packet with 1 of the keyframes being invisible and serving only as a reference to the previous gop but the latter starting a new gop and being visible
[20:08:29 CEST] <jkqxz> jamrial:  <https://0x0.st/sumB.patch>   Just reading most of the headers so far.  The lack of a trace mode on libaom (like JM and HM have) to compare with makes it painful going.
[20:11:56 CEST] <atomnuker> jkqxz: cbs_av1_read_uvlc seems like it reads a golomb coded value, we should have code for that
[20:13:19 CEST] <jkqxz> Making a stream with tiles to test that was rather nasty.  The libaom API wants numbers of superblocks for tile sizes, but the size of superblocks can be 64x64 or 128x128 and there doesn't seem to be any way to tell which will be used.  (Also none of those parameters get any validation at all.)
[20:13:55 CEST] <atomnuker> there's a frame level flag to signal sb size
[20:14:23 CEST] <jkqxz> atomnuker:  Not safe code.
[20:14:53 CEST] <jkqxz> atomnuker:  It's in the sequence header, and you can't see it in the libaom API.
[20:15:22 CEST] <jkqxz> Consider <https://0x0.st/sum_.patch>.
[20:18:06 CEST] <atomnuker> we messed that up, should've been in the uncompressed header. TD-Linux: did someone ask for it to be in an OBU?
[20:18:44 CEST] <atomnuker> jkqxz: what do you mean not safe code? its used in dirac and (a branch of that) its pretty well fuzzed
[20:21:29 CEST] <jkqxz> Returns an error if you try to read or write beyond the end of the buffer.
[20:23:02 CEST] <jkqxz> And I do want the traceability as well.  Speed isn't very relevant when reading a few values from headers.
[20:28:39 CEST] <jamrial> jkqxz: is cbs_av1_split_fragment() reading the old Annex-B stuff instead of "Annex-B Prime"?
[20:29:03 CEST] <jamrial> the pdf seems outdated, so if you used that then i guess yeah
[20:29:30 CEST] <jamrial> look at https://aomediacodec.github.io/av1-spec/ (which is only one commit behind https://github.com/AOMediaCodec/av1-spec/commits/master )
[20:30:14 CEST] <jamrial> the pdf is literally one day older and that's enough to be missing the annex-b rewrite, heh
[20:30:28 CEST] <jkqxz> Yeah, I wrote that before the change to annex B prime.  That code should maybe just be deleted given that they aren't distinguishable.
[20:30:59 CEST] <jkqxz> Unless some format actually uses annex B?  It would need an option on the private context to set it, though.
[20:32:42 CEST] <jamrial> afaik, annex b is not going to be used in isomff or matroska, so probably no
[20:33:38 CEST] <JEEB> I guess it's for stuff that needs start codes, like MPEG-TS or RTP?
[20:35:30 CEST] <jkqxz> Start codes?  What start codes?  :P
[20:37:25 CEST] <JEEB> :D
[20:42:00 CEST] <jamrial> jkqxz: i think nevcairiel and TD-Linux both more or less agreed that we should ignore annex b internally, so yeah, just remove that
[20:42:46 CEST] <nevcairiel> jamrial: especially now that we managed to get annexb out of mp4
[20:43:04 CEST] <nevcairiel> otherwise we would have had to think about that
[20:43:27 CEST] <jamrial> congrats on the successful lobby, for that matter :p
[21:31:39 CEST] <TD-Linux> atomnuker, it being in the sequence header is intentional, it makes temporal MVs easier in hw
[21:34:32 CEST] <TD-Linux> jkqxz, it sounds like we should just change the libaom api. have a preference?
[21:35:37 CEST] <TD-Linux> JEEB, also RTP doesn't need start codes
[21:35:44 CEST] <JEEB> ah
[21:39:02 CEST] <TD-Linux> (you can do start codes in RTP, it's just a bit wasteful because you already have packet boundaries so you can make use of that instead)
[21:39:45 CEST] <JEEB> right, I never really looked into that protocol
[21:39:54 CEST] <JEEB> just that people tend to use Annex B AVC/HEVC in it... I think?
[21:40:52 CEST] <jkqxz> No, H.26[45] have proper packetisation modes with sensible definitions.
[21:41:02 CEST] <jkqxz> The people with start codes are those dumping MPEG-TS in RTP.
[21:41:28 CEST] <JEEB> ah, roger
[21:44:05 CEST] <jkqxz> TD-Linux:  For tiles?  Given tile widths in pixels rather than superblocks, I think.  (And actually validate them.)
[21:44:32 CEST] <TD-Linux> ok, just spit back an error if it's wrong?
[21:45:06 CEST] <jkqxz> Though it might be more elegant to just have "use NxM tiles" and don't specify the widths manually.  I'm not sure exactly what the use-case is for the explicit ones.
[21:45:11 CEST] <TD-Linux> I guess right now you only get 64x64 superblocks by asking for them with a ctl
[21:46:02 CEST] <TD-Linux> jkqxz, that's how vp9 worked (and how it's bitstream signaled). the idea for the explicit sizes is that you can load balance tile threading by dynamically changing the sizes so that both threads complete at about the same time
[21:46:29 CEST] <TD-Linux> that said... that's probably logic you would expect to be inside libaom and not ffmpeg.
[21:47:21 CEST] <jkqxz> Because uniform_tile_spacing_flag gives you 2048 + 112 for two row tiles at 4K, I suppose?
[21:48:07 CEST] <jkqxz> (Which is probably not what you wanted.)
[21:49:19 CEST] <jkqxz> But yeah, that does sound like ffmpeg shouldn't be thinking about it.
[21:54:47 CEST] <TD-Linux> uniform tile spacing should actually give you a sane distribution
[21:55:08 CEST] <TD-Linux> I think, I haven't looked at this in a while
[21:58:37 CEST] <jkqxz> Urgh, seems I misread that.  I was thinking it made you power-of-two tiles, but that's not what it does.
[00:00:00 CEST] --- Mon Apr  9 2018