freenode :: #aomedia

17 May 2017
12:49BBBpeloverde: is the talk submission period for demuxed still open?
12:51ltrudeauBBB I think you have until the end of june https://demuxed.com/proposal-form/
12:51BBBah good, good
12:51BBBthat means I only need to figure out what I want to talk about
12:52ltrudeauEVEV1 ?
12:53BBBI sometimes feel its better to talk about opensource stuff first, or at least partially
12:53BBBso maybe ffav1
12:54BBBdepends on status of standard, though
12:54BBBis there going to be some kind of aom meeting later this year?
12:55ltrudeauThat's a good question
12:55BBBI have a lot of suggestions based on stuff where in hindsight, even today, working with vp9 has some practical limitations/issues and action needs to be taken during the standardization process to prevent the same from happening to av1
12:55BBBor, well, dont call it suggestions, just call it experience, or whatever
12:56atomnukerBBB: ffav1 is mine, you hear?
12:56BBBand people likely already know most of that, its not like Im smarter than anyone else here, but I havent seen any written documentation or other evidence that theres outstanding action items to address them
12:56BBBatomnuker: how about we split it?
12:56atomnukerdeal :)
12:56BBB\o/
12:57BBBalternatively, we can fight to the death and the winner takes all
12:57atomnuker(just waiting to see what sticks to the wall before it has to start)
12:57BBB(maybe it wasnt obvious, but thats a joke)
12:57BBBis there a timeline for that?
12:58BBBnot so much the literal standardization, but the formal submission and acceptance of features/experiments into the av1 codebase
12:58atomnukerpaint dries end of june-ish, after that anything thrown will fall
12:58BBBhow long is the paint-drying period?
12:59ltrudeauBBB: if you want to propose things to AV1 you should probably hurry
12:59BBBltrudeau: no, Im more interested in the stuff done with accepted features
12:59atomnukerBBB: from what I know after june the tools will be frozen, though not sure about the bitstream
12:59atomnuker(but bitstream should be stable enough to work with by then)
12:59BBBI can explain a little: some of the features hard to work with in vp9 are things like multi-arf, direct-ref (skip-p) and intraonly
13:00BBBthese were things enabled in the standard but the encoder didnt use them
13:00BBBas a result, there were initially no samples
13:00BBBas a result, hardware didnt support it
13:00BBBas a result, I cannot really expect it to work and so its not available for me to use in practice
13:00BBBas a result, Im sad
13:00atomnukerwow, that sounds mpeg-ish
13:00BBBwhat do I know, Im just stupid
13:01BBBbut, for av1, this could be prevented by having a process in place to make sure that features in the standard are a) used in model encoder b) tested in conformance samples from day 1 and c) expected to be functional in all deployed hardware because they rely on (a) and (b)
13:02BBBso Im not literally interested in features, but more in the process to make sure the features will actually end up working to the largest extent, and not just the limited method that the model encoder implements them in day 1
13:03BBB(or conformance samples)
13:03ltrudeauBBB: For the most part, the experimentation is the day implementation
13:03ltrudeauday 1 implementation
13:08ltrudeauBBB: AWCY is helping a lot to reach your (b)
13:08BBBawcy only helps with what the model encoder supports
13:09BBBso if the model encoder doesnt test intraonly frames or multi-arf in particular ways, were kind of screwed, right?
13:09ltrudeauBBB: You should join the alliance you could see the process at work and help improve it :)
13:09BBBIm almost thinking in terms of these compiler-generated video files which make sure all branches and all values in the bitstream (Decoder) are tested
13:10BBBI dont have enough money to pay for lawyers to join an alliance (yet? :D)
13:11ltrudeauBBB: Yeah, I understand that can be tricky. However, if you have such sequences, they could be added to AWCY
13:11BBBawcy is about source material; what I meant was about encoded material and the features exposed in the bitstream
13:12BBBsorry, I wasnt entirely clear about that
13:12BBBso imagine that you have a compressed sample that uses intraonly frames in the way that its meant to be used in the bitstream, and a few other odd (but theoretically legal) ways
13:13BBBthats not so much about source, but about bitstream features
13:13BBBhaving such samples included in the conformance suite would help hardware decoder makers ensure their hardware is not semi-broken
13:13BBB(or limited)
13:14ltrudeauBBB: yeah, those would be pointless for now. I totally agree, VideoLAN could also be interested in this
13:14smarterthere's at least one company who sells vp9 bitstreams to stress-test implementations: http://www.argondesign.com/products/argon-streams-vp9/
13:14BBByeah, so basically Im advocating for argon-av1 at day 1
13:14BBBgo argon!
13:14smarterget argon to join the alliance? :)
13:15BBBeven better if the samples are free so we all get access to it
13:15BBBI remember that on day 1 of vp9, I had a decoder that didnt actually handle alt-ref frames (not even multi-arf!) correctly in ffmpeg, and it decoded all conformance samples correctly
13:16BBBthats pretty weird, I mean its obvious because it decodes conformance samples but not vpxenc-generated samples
13:16BBBbut imagine that I didnt have access to vpxenc or I didnt know how to use it
13:16BBBI could theoretically ship a broken decoder that on paper looks fine
13:16smarterfor HEVC, a bunch of companies each contributed some bitstreams testing different features, maybe AOM should ask people to do that too
13:16BBBthats basically what Id like to not see for av1 day 1 ;)
13:20ltrudeauFor what it's worth, I think that since many hardware companies are in the alliance, that these issue will be considered.
13:24ltrudeauI guess that with VideoLan involvement in the alliance they will work towards making sure projects like ffav1 will not be broken decoders that look fine on paper
13:24BBBI hope so :) but like I said, its good to confirm ;)
13:24BBBoh videolan is actually involved in aom?
13:24BBBI didnt know that
13:25ltrudeauhttps://www.videolan.org/press/aomedia.html
13:25BBBah nice
13:26ltrudeauThe issue you are raising will be of great concern to them
13:29BBBis j-b in charge of that?
13:29BBBmaybe I should poke them
21:46peloverdewhen do pixels outside of visible MIs but in a codable area get filled on the bottom and right borders?
21:48peloverdedoes that make sense as a question
21:48peloverdesource pixels for intra modes
21:58TD-Linuxyou mean for "right up" intra mdoes?
22:01peloverdehttps://usercontent.irccloud-cdn.com/file/grU3ITEX/invisible.png
22:01peloverdeI mean the left neighbors of the highlited block
22:23peloverdeI think it's extend_dir and dec_extend_dir respectively
22:31TD-LinuxI'd appreciate if someone can take a harder look at https://aomedia-review.googlesource.com/#/c/11725/
22:31TD-Linuxthis seemed to cause a regression, however the old behavior *crashes* sometimes
22:33TD-Linuxit's actually possible that uninitialized mvrefs happen to be good things to seed the search with, but I don't really like that answer
22:36tmatthpeloverde: been wondering the same thing myself
22:37peloverdethough I'm still a bit confused about extension directions up and left in that code
22:38tmatthpeloverde: sort of related, i've been working on padding the MI grid to the nearest superblock: https://goo.gl/q8ozbo
22:39TD-LinuxI think derf recently fixed the up and left extensions for cb4x4
23:34peloverdeTD-Linux: Perhaps fill unused slots with deterministic, random, valid values
23:34TD-Linuxwell the values aren't actually random. they are from previous frames (or partially from previous frames)
23:39peloverdeSo what's causing them to make stuff crash
23:40TD-Linuxpeloverde, they sometimes point out of the frame
23:40TD-Linuxwhich leads to the question "why would they point out of the frame if they are uninitialized from previous frames"
23:42peloverde0x7ffffffed5f4 does not look like anything leftover from a previous frame
23:44peloverdewhy is it 64-bits, that seems odd
23:44peloverdeoops pointer, my bad
23:45TD-Linuxpeloverde,
23:45TD-Linux pred_mv = {{row = -18, col = 20}, {row = -1355, col = 1153}, {row = 0, col = 0}}
23:45TD-Linuxpred_mv[1] is the one out of bounds in this case
23:46TD-Linuxactually looks like debargha has a fix https://aomedia-review.googlesource.com/#/c/12185/2/av1/encoder/rd.c
23:47TD-LinuxI'm not sure which of the 3 things that patch does fixes it though
23:56peloverdeInterior tiles always need to align to the SB size?
23:58TD-Linuxyes
18 May 2017
No messages
   
Last message: 11 days and 14 hours ago