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

[burek]

[11:25:57 CEST] <January> michaelni: decode_nal_units() in h264dec.c, shouldn't it check if the current run of NALs since the last PPS is not mixed instead of just checking if it hit a IDR slice before?
[13:02:07 CEST] <January> In h264 is it required for there to be non-IDR NALUs inbetween IDR NALUs (excluding runs of slice NALUs)?
[13:02:56 CEST] <JEEB> I'm pretty sure all-IDR is 100% valid?
[13:03:26 CEST] <JEEB> you have your PPS/SPS etc first, then just IDR VCL NALUs?
[13:03:45 CEST] <JEEB> (VCL being Video Coding Layer , aka not metadata packets)
[13:35:09 CEST] <durandal_1707> can i get review for SCPR v3?
[13:35:32 CEST] <durandal_1707> otherwise I fill be forced to push it
[13:42:38 CEST] <January> durandal_1707: I think it looks fine--definitely a lot cleaner now, it previously worked with the samples I tested it with (which are probably the same ones you used, now that I think of it).
[14:07:57 CEST] <January> michaelni: why is h->current_slice set to 0 when not in slice threading mode? Couldn't the user still send incomplete frames to decoder?
[15:35:41 CEST] <January> JEEB: this look somewhat sane then? https://www.irccloud.com/pastebin/3PlPoAG8/slice.diff will send to ml if you think so
[15:44:27 CEST] <kierank> michaelni: ^
[16:04:50 CEST] <durandal_1707> will Dav1d be realtime for qcif content? :))))
[16:24:22 CEST] <atomnuker> durandal_1707: I'll look at it tonight, was waiting for the last version
[18:04:48 CEST] <durandal_1707> January: there is SCPR encoder via VirtualDub2....
[20:15:22 CEST] <durandal_1707> silence like in middle of weekends
[20:17:46 CEST] <atomnuker> yeah, last night was silent everywhere
[20:46:01 CEST] <kurosu_> BBB / j-b / atomnuker: I guess there are contractual issues to even have a taste of dav1d or its vdd presentation?
[20:46:22 CEST] <BBB> ?
[20:46:41 CEST] <BBB> are you asking whether the source will be available at VDD?
[20:46:59 CEST] <kurosu_> BBB, asked j-b on the side of another discussion, no response, so I was taking that as a hint, but I'm still asking
[20:47:11 CEST] <kurosu_> oh, I expect everybody to see the code in due time
[20:47:24 CEST] <kurosu_> just that curiosity killed the cat, and I don't like cats
[20:47:55 CEST] <BBB> afaik, the source will be available at VDD
[20:48:07 CEST] <BBB> Im not aware of any contractual issues or whatever
[20:48:12 CEST] <kurosu_> just whatever information that may interest a ricer (and I'm not speaking of the cooking device)
[20:48:48 CEST] <BBB> Ill tell you what I tell my kids every day for many different reasons: please be patient
[20:48:54 CEST] <kurosu_> ok, my guess was embargo/NDA until some deadline/delivery/another thing we have no need to be aware of
[20:49:14 CEST] <durandal_1707> it will have >1x decoding speed (only) for qcif videos
[20:49:50 CEST] <kurosu_> durandal_1707, you mean, it will call abort() or BUG_ON() if it measures more than 2x realtime ?
[20:50:02 CEST] <BBB> it is clearly a bug
[20:50:13 CEST] <BBB> people tell me av1 has 200k complexity increase over h264
[20:50:17 CEST] <kurosu_> BBB, anyway, from your last sentence, even your kids are excited about dav1d
[20:50:26 CEST] <BBB> so Id better respect that, otherwise they may think its not a real av1 decoder
[20:51:20 CEST] <JEEB> :D
[20:51:24 CEST] <JEEB> sleep()
[20:51:29 CEST] <JEEB> in all the right places
[20:51:56 CEST] <BBB> no, no, no, were not that evil; its if (!did_you_payme_10_dollar) sleep()
[20:52:06 CEST] <JEEB> the classic license check
[20:52:09 CEST] <BBB> right
[20:52:36 CEST] <BBB> we did also consider a more complicated license check where the number of seconds slept depends on how much you paid (inversely), but it had integer overflows if you paid too much so we did away with that
[20:52:53 CEST] <JEEB> :D
[20:53:00 CEST] <kurosu_> JEEB, sleep()  is how you sell 10% improvements agai and again
[20:53:22 CEST] <JEEB> yes, I was going to make jokes about checking the version and removing sleeps with each minor bump
[20:53:30 CEST] <JEEB> (micro bumps aren't supposed to improve perf)
[20:53:41 CEST] <kurosu_> (probably some coding horror or whatever story where someone had to implement this in a progress bar)
[20:57:39 CEST] <durandal_1707> i cant record sample with some special features of codec, what I should do?
[21:05:02 CEST] <BBB> durandal_1707: not much to do right? maybe RE how to enable it in the encoder if you really want to, but otherwise, if you cant use it, likely nobody else can either, av_request_sample()?
[21:05:30 CEST] <BBB> kurosu_: and more seriously, yes, at VDD, I believe there will be source
[21:06:15 CEST] <BBB> dont ask too much, because every second spent answering questions gives us less time to make the source actually available (there are some outstanding todo items)
[21:06:35 CEST] <BBB> were trying our best
[21:15:06 CEST] <kurosu_> I think I've heard that reply in an Apple keynote :D 
[21:17:19 CEST] <atomnuker> kVTVideoEncoderSpecification_EnableHardwareAcceleratedVideoEncoder <- they tried their best
[21:17:45 CEST] <atomnuker> (longest I could find, I think there were longer)
[21:18:30 CEST] <kurosu_> some lines of code would be clipped by irc servers I guess
[21:19:05 CEST] <kurosu_> (can't find the proper word)
[21:34:58 CEST] <michaelni> January, was afk, ill review the patch on ffmpeg-dev, i see you posted it there
[21:35:20 CEST] <January> michaelni: am writing fate test as well
[21:35:44 CEST] <michaelni> good
[21:48:32 CEST] <kierank> michaelni: the intention is to make chunks and slice threading work
[21:48:36 CEST] <kierank> which it does not at the moment
[21:49:42 CEST] <michaelni> this should be in the commit message
[21:52:03 CEST] <gnafu> kurosu_: Truncated?
[21:56:43 CEST] <jkqxz> Are there official AV1 test streams yet?
[22:00:24 CEST] <TD-Linux> jkqxz, https://www.elecard.com/videos
[22:02:51 CEST] <j-b> I'm collecting some for https://streams.videolan.org/misc/AV1/
[22:03:37 CEST] <jkqxz> I was more thinking of the "test every feature" type.
[22:06:21 CEST] <durandal_1707> Compn: need RASC sample?
[22:06:48 CEST] <TD-Linux> ah yeah. those aren't available yet, but this is where they should appear http://www.argondesign.com/products/argon-streams-av1/
[22:08:00 CEST] <j-b> Do the elecard sample even have a valid MKV mapping?
[22:08:08 CEST] <j-b> or are they broken like the normal aomenc?
[22:08:15 CEST] <TD-Linux> I suspect they are borken
[22:08:40 CEST] <jamrial> unlikely. not even libaom muxes them with the updated mapping yet
[22:09:02 CEST] <TD-Linux> I suppose now that the isobmff mapping is "done" I can assume the mkv extradata is going to be the same and send a patch to libaom
[22:09:13 CEST] <jamrial> but it's a wip, afaik. i saw some related work in https://aomedia-review.googlesource.com
[22:09:52 CEST] <jamrial> TD-Linux: https://bugs.chromium.org/p/aomedia/issues/detail?id=2027
[22:10:22 CEST] <TD-Linux> jamrial, oh nice.
[22:10:59 CEST] <jamrial> in any case, the mapping hasn't even been committed to the master branch in the matroska-specification repository yet, so...
[22:24:22 CEST] <jkqxz> Those Elecard streams seem to have warped motion enabled but say "nope, not this time" for every single reference.  How useful.
[22:24:57 CEST] <jkqxz> (Was looking for a warped motion example.  j-b's one stream has it.)
[22:25:35 CEST] <j-b> you mean fwd key?
[22:26:16 CEST] <jkqxz> "fwd key"?
[22:30:37 CEST] <jamrial> jkqxz: i have a sample with global motion params, if you need it
[22:36:05 CEST] <jkqxz> I'd try it.  I have parsing that stuff all looking like it's working through av1_metadata, but I need to instrument the libaom decoder to work out whether it's actually got the right answer.
[22:58:36 CEST] <jamrial> jkqxz: https://0x0.st/svjc.mkv
[22:59:12 CEST] <jamrial> i think this is one of the files i used to find the bugs i fixed in the diff i gave you a while back
[23:03:51 CEST] <jkqxz> Thank you!  I integrated all of that, except for the inference about force_integer_mv on key frames (it looks like it could fail on a valid stream, and isn't used anyway in that case).
[23:04:16 CEST] <jkqxz> Current state here: <http://ixia.jkqxz.net/~mrt/ffmpeg/av1/>.  I need to clean up the global motion stuff, but it seems to work on the few samples I have.
[23:04:43 CEST] <jkqxz> Also remove the vestigial annex B stuff, then it's probably done for the first pass.
[23:11:11 CEST] <jamrial> jkqxz: one thing you also need to add is tile_rows and tile_cols to AV1RawFrameHeader
[23:11:39 CEST] <jamrial> the ones in CodedBitstreamAV1Context contain the values for the last frame in the temporal unit only, and each TU may have several frames
[23:12:37 CEST] <jkqxz> How does that go wrong?  They have to be in order, don't they?
[23:14:33 CEST] <jamrial> yes, but what if i'm interested in knowing how many tiles any of the other frames have?
[23:14:46 CEST] <jamrial> take for example a TU with a frame header OBU + several tile gruop OBUs for the first frame (invisible one), then the same for two more frames (meant to be shown later), then the same for the last one (te visible one for the TU)
[23:15:16 CEST] <jamrial> tile_rows an tile_cols are needed to know how many tile group OBUs each frame has
[23:16:08 CEST] <jkqxz> That's derivable from the tile properties in FrameHeader?
[23:16:42 CEST] <jamrial> how?
[23:17:38 CEST] <jamrial> a frame ends when a tile group's tg_end == tile_cols * tile_rows
[23:17:43 CEST] <jkqxz> In the same way as it was done originally.
[23:18:18 CEST] <jkqxz> All of the syntax elements are present.
[23:19:57 CEST] <jamrial> ok, so as a CBS api user, i pass it a packet/TU and get an array of OBUs. how can i know where a frame ends? (frame header OBU + tile group OBUs, of course. a Frame OBU is complete on its own)
[23:21:04 CEST] <jamrial> i couldn't find any way to do that, other than adding tile_rows and tile_cols to AV1RawFrameHeader, and cheking that frame->tile_rows * frame->tile_cols == tile_group->tg_end
[23:22:49 CEST] <jkqxz> tile_cols is uniform_tile_spacing ? annoying function of tile_cols_log2 : sum of width_in_sbs things.
[23:23:46 CEST] <jkqxz> I guess it is rather inconvenient to have to re-derive that, but it was intended that the directly-from-standard CBS structures do not contain derived values.
[23:26:01 CEST] <jkqxz> Hmm.  A different answer would be to set tg_start/tg_end even if tile_start_and_end_present_flag is false?
[23:26:54 CEST] <jkqxz> No, that's still not quite enough.  Some flag.  (The RTP marker bit, really.)
[23:28:03 CEST] <jamrial> those are already inferred as 0 and tile_cols * tile_rows - 1 when the flag is not set
[23:28:11 CEST] <jamrial> meaning every tile is contained in the tile group in question
[00:00:00 CEST] --- Wed Sep  5 2018