freenode :: #aomedia

8 Aug 2017
15:35atomnukerI guess its useful to adjust the lpf strength though
16:59tj_davie1atomnuker: there also are not enough segments for you to cover the range of QPs you need to
16:59tj_davie1and you had to send segment IDs for every block, even skip, IIRC
17:00tj_davie1then you might want to use segments independently, e.g. for foreground-background coding
17:01atomnukertj_davie1: 7 segments are plenty for anything
17:02tj_davie1not when you really need them
17:02tj_davie1e.g. when you need to rapidly change bit rate
17:03atomnukeryou can signal them on a sub-superblock basis so you can still rapidly change it
17:04atomnukersure you'll need to partition more if that's the case but crazy things like rapid bitrate changing demand crazy usage of bitstream features
17:06TD-Linuxthe definition of the 8 segments is only sent once per frame
17:07atomnukeryes, its not that much, but the need to have a seg_prob flag + a seg_id index drives costs up
17:07atomnukerand also the seg_id is predicted only temporally, not spatially
17:09TD-Linuxyes it's murderously expensive
17:09atomnukertj_davie1: I think we ought to remove the deltaq bitstream signalling and cheapen/sanify segment coding
17:10atomnukerthere's no excuse in having 2 ways to adjust the quantization index
17:10atomnukerespecially if the latter is useless for doing any AQ
17:11atomnukerand only really useful for extremely obscure crazy things which can be done using segments anyway (right now even, not like cost matters much )
17:13tj_davie1why is segment coding useless for AQ? i thought there were a couple of AQ modes that used it
17:13atomnukerI was speaking about deltaq, not segment coding
17:13atomnukerand yes, a couple of aq modes use it
17:14atomnukerand really if you signal it even on skips its not really a problem for your particular use case
17:14atomnuker('sides, we can fix it)
17:14tj_davie1yes it is
17:14tj_davie180-90% of blocks are skipped
17:16atomnukerhm, could skip segments having alt_q in such blocks
17:16atomnuker(rather signalling the flag + index)
17:18atomnukeranyway, if you're going to waste bits making every frame the same size, those costs are a drop in a bucket
17:24TD-Linuxatomnuker, segment coding is now split into two haves. the q segment stuff is not on skips
17:24tj_davie1actually, you don't make every frame the same size, but you do have to hit a frame target pretty accurately
17:25TD-Linuxatomnuker, (old) segment coding stuff is so bad that the costs very much aren't a drop in the bucket
17:25TD-Linuxthe new segment coding stuff might be good enough
17:26TD-Linux(old segment coding with no reference in particular)
17:26atomnukerso that's great, we just need to cheapen segment index coding and make it spatially predictive
17:27atomnukertj_davie1: would you agree to use it once that happens and drop deltaq?
17:28tj_davie1well, that would depend on the details, and the usual reviews
17:30tj_davie1i still don't know how you choose your set of QPs in advance of coding anything
17:31tj_davie1you are also encoding things in parallel in multiple tiles, and whilst you are doing that you have limited info about the overall state of the bit buffer
17:31tj_davie1it can be that updates to that information can change how you want to code something in a tile quite rapidly
17:33tj_davie1basically, it has to work when it *has* to work - when everything is screwed up
17:34tj_davie1in normal coding, predicting QPs for a frame is relatively simple, but that is not what matters
17:36tj_davie1e.g. we do transcoded conferences - what QP should you use if the input has dropped a frame due to loss, and you've fallen back to using a long-term reference from ages ago for prediction?
17:36atomnukerthat's simple to solve too - make the segments not signal a delta of the qindex but rather a multiple of the log2 of the qindex
17:36atomnukerthat way you have enough precision and range to do what you need
9 Aug 2017
No messages
Last message: 13 days and 19 hours ago