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

[burek]

[10:18:45 CEST] <cone-650> ffmpeg 03Tobias Rapp 07master:4b736bc921ed: fftools/cmdutils: add support for level flag in loglevel option parser
[12:11:16 CEST] <durandal_1707> does having lots of #ifdef stuff in source make it slower to compile?
[12:12:21 CEST] <nevcairiel> sort of but not really
[12:12:38 CEST] <nevcairiel> the impact is probably marginal
[12:12:40 CEST] <jdarnley> Not from what I know.  The preprocess step is much quicker than the compiling step.  That' is why ccache is good.
[12:14:15 CEST] <durandal_1707> why i get extra slowdown when compiling new bit reader?
[12:15:14 CEST] <durandal_1707> try patch which i will post and report time
[12:18:31 CEST] <durandal_1707> i have ccache enabled, maybe its doing this notorious slowdown
[12:20:13 CEST] <durandal_1707> still slooww
[12:20:41 CEST] <nevcairiel> maybe the optimizer has a lot more work to do on your new code
[12:21:03 CEST] <durandal_1707> nevcairiel: not really, the cache reader is enabled only on utvideo
[12:22:39 CEST] <nevcairiel> and everything gets slower?
[12:23:01 CEST] <durandal_1707> up to 10X
[12:24:22 CEST] <durandal_1707> aacpsy is still compiling, it was using 4 cores, and other cores managed to get to h264*, while this one is still on aacpsy
[12:24:35 CEST] <nevcairiel> odd
[12:25:44 CEST] <durandal_1707> now using compiler without ccache
[12:28:16 CEST] <durandal_1707> now aacpsy was compiled in under 1 second
[12:28:37 CEST] <nevcairiel> maybe you need to clear the ccache cache
[12:28:44 CEST] <durandal_1707> i did
[12:28:48 CEST] <nevcairiel> i've heard it can get confused sometimes
[12:28:48 CEST] <durandal_1707> did not helped
[12:28:54 CEST] <nevcairiel> i dont really use it myself
[12:43:21 CEST] <durandal_1707> i get 2x speed decoding overall in tak when using cached bitstream reader
[12:45:18 CEST] <durandal_1707> so 76x realtime while 36x with older bitreader crap
[12:45:36 CEST] <durandal_1707> misdesigned for pentium 1
[12:46:14 CEST] <nevcairiel> some seem to benefit greatly from it, some others seemed to even get slower, its all weird
[12:48:08 CEST] <durandal_1707> nevcairiel: i don't think so, people lacks abbility to simple test overall improvement with random file
[12:49:54 CEST] <durandal_1707> crap, my testcase is wrong: there is no actual improvement much
[12:50:07 CEST] <durandal_1707> at least with tak
[13:22:27 CEST] <kwizart> hi, sorry about the kind of question: is this statement true: "fdk-aac is free but GPL incompatible" ?
[13:37:50 CEST] <jdarnley> I think that is what we believe.
[13:38:10 CEST] <jdarnley> It might be backed up by FSF saying the licenses are incompatible.
[13:43:16 CEST] <kwizart> so it would means that a LGPL license is GPL incompatible. weird but possible
[13:43:36 CEST] <durandal_1707> kwizart: no
[13:44:48 CEST] <kwizart> durandal_1707, care to elaborate ?
[13:45:33 CEST] <kwizart> the problem IMO is that because the patent notice is in the copyright notice, I would more inclineded to say that there is a dual license. And there is a doubt to consider which one apply first
[13:47:17 CEST] <jdarnley> The LGPL does not place any more restrictions on distribution than GPL so you can mix code using both. 
[13:48:17 CEST] <nevcairiel> the patent clause is an additional limitation to the license, which makes it incompatible
[13:48:58 CEST] <kwizart> nevcairiel, you mean GPL incompatible  ? but is it still FLOSS ?
[13:49:18 CEST] <nevcairiel> you should consult license lawyers for such questions, anything we can tell you means nothing
[13:50:56 CEST] <kwizart> Okay, FYI, still the more recent feedback https://bugzilla.redhat.com/show_bug.cgi?id=1501522#c75 there is apparently a question raised to FSF about this
[13:57:18 CEST] <nevcairiel> from the best of our knowledge we consider it incompatible to the GPL, hence it being only available in non-free ffmpeg builds. if it still qualifies as being FLOSS is another question entirely, and not one we ask ourselves much around here
[14:26:35 CEST] <durandal_1707> is there instruction that does pmaddwd+paddd in one?
[14:29:26 CEST] <kierank> nevcairiel: but if the patents have expired then it's gpl compatible
[14:30:46 CEST] <JEEB> that's RH's opinion (and they patched out the HE-AAC parts of fdk-aac, IIRC)
[14:37:35 CEST] <BBB> durandal_1707: VPMACSSWD?
[14:37:45 CEST] <BBB> I believe its AMD-only though
[14:40:48 CEST] <BBB> huh, no, that ignores half the register
[14:40:51 CEST] <BBB> what a totally braindead instruction
[14:40:54 CEST] <BBB> nevermind
[14:43:24 CEST] <atomnuker> durandal_1707: can you benchmark how long it takes fate to run with it enabled for all codec and for none?
[14:47:31 CEST] <durandal_1707> atomnuker: that is pointless task
[14:48:08 CEST] <BBB> for most codecs, there is no measurable difference
[14:48:14 CEST] <BBB> most modern codecs dont use bitstream readers like that
[14:48:20 CEST] <BBB> its only useful for a minimal subset
[14:48:25 CEST] <BBB> and for these, it can be inidivudally tested, right?
[14:48:48 CEST] <durandal_1707> utvideo is still by 1/4 faster with new reader
[14:50:14 CEST] <BBB> thats great!
[14:50:23 CEST] <BBB> I wasnt intending to say that your work is not useful, dont get me wrong
[14:50:32 CEST] <BBB> I was agreeing with you that measuring the impact on all codecs isnt very useful
[14:50:49 CEST] <BBB> since for many codecs, it wont make a difference, and they make up a disproportional part of fate (vp9, hevc, h264, etc.)
[14:55:12 CEST] <atomnuker> lets just enable it for all codecs
[14:56:47 CEST] <durandal_1707> but for some cases, it is big drop in performance
[14:58:01 CEST] <atomnuker> which places? the old bitstream reader is probably small enough to specialize and put inside
[15:02:37 CEST] <durandal_1707> for dca it is slower by small margin
[15:09:30 CEST] <durandal_1707> kierank: you got any crashes with clearvideo P patch?
[15:09:39 CEST] <kierank> no
[15:09:44 CEST] <kierank> but was dumb fuzzing
[15:11:27 CEST] <durandal_1707> i will apply it, and let others to fuzz it for free :)
[15:14:50 CEST] <BBB> I dont understand fundamentally why the new bitstream reader is faster at all
[15:14:54 CEST] <BBB> like, I understand caching etc.
[15:15:10 CEST] <BBB> but a cache is still places in heap memory, since the getbits struct is on heap, and thus so is the cache
[15:15:14 CEST] <BBB> and so is the bitstream
[15:15:17 CEST] <BBB> so why is it different?
[15:15:38 CEST] <durandal_1707> it is simpler
[15:15:39 CEST] <BBB> the only thing I can think of it that its the larger cache leading to fewer refills
[15:15:55 CEST] <BBB> but then why not just change it from cached to refill using 64 bits on 64 bits cpis?
[15:16:03 CEST] <BBB> Ive never understood that very much
[15:16:09 CEST] <atomnuker> if you're reading a few bits at a time it'll be faster since it won't have to redundantly read bytes
[15:16:19 CEST] <BBB> right, so its refill
[15:16:23 CEST] <BBB> but you dont need a cache for that
[15:16:31 CEST] <BBB> cache is just heap->heap
[15:16:41 CEST] <BBB> right
[15:16:42 CEST] <BBB> ?
[15:17:06 CEST] <nevcairiel> the bitstream reader is often on the stack, isnt it
[15:17:14 CEST] <atomnuker> heap, stack, it all winds up in some l cache
[15:21:10 CEST] <nevcairiel> as far as i can tell, the non-cached reader accesses the underlying byte array everytime you run get_bits etc, while the cached variant has a variable it actually stores this in
[15:21:47 CEST] <BBB> yes
[15:21:51 CEST] <BBB> but the variable is on heap
[15:21:53 CEST] <BBB> or stack
[15:21:54 CEST] <BBB> whatever
[15:21:55 CEST] <BBB> memory
[15:22:00 CEST] <BBB> and so is the underlying byte array
[15:22:01 CEST] <BBB> so
[15:22:06 CEST] <BBB> why is one different from the other?
[15:22:09 CEST] <BBB> ...
[15:22:25 CEST] <nevcairiel> probably optimizes better
[15:23:42 CEST] <kierank> BBB: there's an explanation somewhere on either ffmpeg list or libav one
[15:23:48 CEST] <kierank> but I think yes, a 64-bit load into cache rather than 32
[15:26:34 CEST] <nevcairiel> my guess would be that its easier for a compiler to properly optimize repeated access to a single variable then it is to keep track of shifted/masked access to the array directly
[15:27:12 CEST] <nevcairiel> the way its written, it reads 32-bit everytime you request a single bit, if it doesnt optimize that properly, it could end up slow
[15:27:56 CEST] <nevcairiel> actually thats not true, get_bits1 is actually optimized to not do that, but if you read 2 bits each time, it would
[15:28:58 CEST] <nevcairiel> so a "dumb" compiler would have far less memory access in the cached model
[15:29:53 CEST] <nevcairiel> from the results  being as inconsistent as they are, it seems clear that its just another attempt at tricking the optimizer into making good code
[15:30:02 CEST] <nevcairiel> but it does work for some usage patterns
[15:30:22 CEST] <BBB> but the cache is also in memory
[15:30:26 CEST] <BBB> Im not trying to be dumb
[15:30:28 CEST] <BBB> Im really not
[15:30:38 CEST] <BBB> but theyre both in memory and they both end up in L1 depending on access pattern
[15:31:07 CEST] <nevcairiel> if you flat out translate the code without any optimizations, the old reader would do a lot more
[15:31:10 CEST] <BBB> I truly appreciate the results showing that its faster, and thats great, as I said, but I dont fundamentally understand why :)
[15:31:31 CEST] <nevcairiel> every get_bits call is basically a re-fill, no matter how much you read
[15:31:36 CEST] <nevcairiel> the new code only refills when needed
[15:31:39 CEST] <nevcairiel> hence, less work, faster
[15:32:00 CEST] <BBB> ok so it *is* refill overhead
[15:32:54 CEST] <nevcairiel> basically, because the old code throws away the refill result
[15:33:06 CEST] <nevcairiel> it fills its temporary cache, reads from it what it wants, and then throws it away
[15:33:09 CEST] <nevcairiel> the new one keeps that cache
[15:34:25 CEST] <nevcairiel> its not quite that simple because that temporary cache is most certainly a register and the permanent cache is memory again, but shrug
[15:34:55 CEST] <nevcairiel> if it would be that simple, we would be seeing speedups everywhere
[15:36:54 CEST] <BBB> for me, thats the interesting question
[15:36:55 CEST] <nevcairiel> its all trickery because we dont want to write assembly
[15:37:16 CEST] <BBB> if we can understand how this all works in reality, we can apply lessons learned to the entropy readers in hevc/h264/vp9/av1 and make coef reading much faster
[15:37:20 CEST] <BBB> now *that* would be exciting
[15:37:39 CEST] <BBB> mru did something weird for vp8 coef reading once, and it made it a lot faster
[15:37:47 CEST] <BBB> something like that for vp9/av1/hevc/h264 would be so cool
[15:37:50 CEST] <nevcairiel> i'm sure there is a reason why  the cabac reader doesnt even use the get_bits stuff but its own simplified variant
[15:38:01 CEST] <BBB> cabac is not raw bits...
[15:38:12 CEST] <nevcairiel> ultimately, it all comes down to raw bits
[15:38:59 CEST] <nevcairiel> what other entropy reading does hevc have?
[15:40:31 CEST] <nevcairiel> cabac uses something that looks a bit like the cached reader, with a cache and a refill function, although it already does processing to the bits right in refilling
[15:41:21 CEST] <BBB> hevc has cabac also
[15:41:33 CEST] <BBB> vp8/vp9 use rac, which is non-adaptive but fundamentally based on the same theory
[15:41:37 CEST] <BBB> av1 has a multi-symbol entropy coder
[15:42:12 CEST] <BBB> (non-adaptive per-symbol, so instead it does adaptivity per-frame; this is better for inter - since it maintains state between frames - and worse for keyframe-only)
[16:17:53 CEST] <durandal_1707> lol, michaelni you borked playback of pal8 on any player
[16:20:31 CEST] <jamrial> kierank: your mpeg4 patch broke a lot of tests under valgrind
[16:21:04 CEST] <jamrial> http://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-valgrind-no-undef&time=20180403134813
[16:22:54 CEST] <nevcairiel> looks like basically one problem, some vlc table not freed
[16:24:05 CEST] <cone-650> ffmpeg 03Simon Thelen 07master:8c2c97403baf: avcodec/imgconvert: fix possible null pointer dereference
[16:25:33 CEST] <kierank> jamrial: hmmm
[16:25:35 CEST] <kierank> yes
[16:38:09 CEST] <kierank> will fix later but feel free to send a patch
[17:02:37 CEST] <wm4> <durandal_1707> lol, michaelni you borked playback of pal8 on any player <- ?
[17:03:41 CEST] <durandal_1707> wm4: it broke mpv playing smc video codec (pal8)
[17:04:09 CEST] <durandal_1707> wm4: see last committ
[17:05:23 CEST] <wm4> "avcodec/imgconvert: fix possible null pointer dereference"?
[17:05:46 CEST] <durandal_1707> yes
[17:05:59 CEST] <durandal_1707> that one fixes regression
[17:06:17 CEST] <wm4> that looks like its only effect is to make a case that would crash to not crash?
[17:06:46 CEST] <wm4> or do you mean "avcodec/imgconvert: Fix loss mask bug in avcodec_find_best_pix_fmt_of_list()" broke everything
[17:08:09 CEST] <durandal_1707> yes, that one
[17:12:25 CEST] <durandal_1707> BBB: was native vmaf finished? why it is not in tree?
[17:31:17 CEST] <cone-650> ffmpeg 03Paul B Mahol 07master:a8745869946d: avcodec/clearvideo: add inter-frame decoding
[17:31:18 CEST] <cone-650> ffmpeg 03Paul B Mahol 07master:be3a051ca8fe: avcodec/sheervideo: move tables to own header
[17:41:30 CEST] <jamrial> durandal_1707: did you or Konstantin write the inter frame support for clearvideo?
[17:42:46 CEST] <durandal_1707> jamrial: why you asking?
[17:43:17 CEST] <jamrial> you should add your copyright to the file if you wrote it, instead of extending the date in Konstantin's
[17:43:48 CEST] <durandal_1707> jamrial: i only ported kostya code from rust
[17:44:08 CEST] <jamrial> ah ok
[17:44:58 CEST] <jamrial> is nihav actually a thing, then?
[17:46:03 CEST] <nevcairiel> they wish
[17:46:07 CEST] <nevcairiel> its a pipe dream
[17:47:16 CEST] <durandal_1707> see rustav :)
[17:54:23 CEST] <cone-650> ffmpeg 03wm4 07master:e53d3348d10f: avcodec/xwdenc: do not rely on AV_PIX_FMT_FLAG_PSEUDOPAL palettes
[17:54:24 CEST] <cone-650> ffmpeg 03wm4 07master:d6fc031caf64: avutil/pixdesc: deprecate AV_PIX_FMT_FLAG_PSEUDOPAL
[18:17:23 CEST] <durandal_1707> kierank: i gonnna apply cineform patch as it fixes ticket #6675, is that ok?
[18:17:46 CEST] <kierank> durandal_1707: yes but commit message sucks 
[18:17:53 CEST] <kierank> was going to tell gagandeep
[18:17:55 CEST] <kierank> but he never online
[18:19:08 CEST] <durandal_1707> kierank: i can edit it?
[18:19:59 CEST] <kierank> yes
[18:23:31 CEST] <durandal_1707> kierank: like: "lavc/cfhd: fix distortion of lowest 8 lines when height is not multiple of 16" ?
[18:25:09 CEST] <kierank> ok
[18:25:14 CEST] <kierank> I don't care that much i am not maintainer
[18:25:55 CEST] <jamrial> but you wrote that decoder
[18:31:34 CEST] <cone-650> ffmpeg 03Gagandeep Singh 07master:673604e0e3b7: lavc/cfhd: fix distortion of lowest 8 lines when height is not multiple of 16
[18:31:36 CEST] <BBB> durandal_1707: not all of it was finished, but yes, some part is still sitting locally in my tree
[18:31:46 CEST] <BBB> durandal_1707: it needed some work for high bitdepth (>8bpc) etc.
[18:31:53 CEST] <BBB> and it was float which I dont like, but maybe thats ok
[18:42:17 CEST] <kurosu> durandal_1707, some ricing comments on the old new bitstream reader patch
[18:43:08 CEST] <kurosu> 1) in get_vlc2, skip_remaining(s, nb_bits) should use 'bits' instead for constant propagation ('bits' is often constant in those huffman decoders)
[18:44:04 CEST] <kurosu> 2) get_xbits and some golomb code may be troublesome as is because they require refilling 32 bits, whatever they actually consume
[18:47:04 CEST] <kurosu> these were in the original code, so do whatever you like
[20:45:33 CEST] <cone-650> ffmpeg 03James Almer 07master:d5343a5005af: avcodec/libaomdec: remove duplicate code
[20:45:34 CEST] <cone-650> ffmpeg 03James Almer 07master:f3fae8204259: avcodec/libaomdec: add support for monochrome files
[20:59:30 CEST] <durandal11707> atomnuker: do we have this already? https://github.com/kakaroto/libsiren/blob/master/dct4.c
[21:03:11 CEST] <atomnuker> that's just for encoding
[21:03:37 CEST] <atomnuker> apparently siren7 is pretty much identical to g722 which we already support
[21:08:24 CEST] <jamrial> wm4: your pseudopal mpv patch refers to the wrong libavutil version
[21:10:20 CEST] <wm4> huh
[21:11:55 CEST] <wm4> ah, one off
[21:13:03 CEST] <jkqxz> Is there a way to distinguish between an AV1 raw bitstream (with obu_size fields) and an annex B bitstream (with obu_length fields), or do you just have to know which you are getting?
[21:16:28 CEST] <atomnuker> :<
[21:18:14 CEST] <wm4> what does annex b have to do with av1
[21:18:37 CEST] <gnafu> jkqxz, wm4: I don't know if this is helpful, but it came to mind: https://aomedia.googlesource.com/aom/+/29c46fb4f906ae6a12c4e6b6307dfe3f114a31f7
[21:18:51 CEST] <gnafu> https://bugs.chromium.org/p/aomedia/issues/detail?id=1590
[21:18:57 CEST] <gnafu> https://bugs.chromium.org/p/aomedia/issues/detail?id=1591
[21:19:02 CEST] <jkqxz> wm4:  AV1 has an annex B as well, which contains a bitstream format.  Apparently it's the thing to do.
[21:19:07 CEST] <jamrial> wm4: av1 has its own Annex B section in the spec
[21:19:30 CEST] <jamrial> which can be either super confusing, or make people instantly understand what it is about
[21:19:48 CEST] <wm4> I don't know the details, but sounds horrible
[21:20:46 CEST] <jamrial> jkqxz: aomdec seems to have an "is_annexb" option, so maybe there's no way to distingish it
[21:20:52 CEST] <jamrial> atomnuker should know
[21:21:05 CEST] <jkqxz> From just making some read/write code putting the size after the header is really quite annoying.
[21:22:32 CEST] <durandal11707> atomnuker: it is used for decoding too, do not be deceived by fake wiki info
[21:23:14 CEST] <jkqxz> It doesn't look like it can be distinguished (yay), but I might have been missing some magic.
[21:24:27 CEST] <jkqxz> Maybe we need extradata for AV1 containing a single bit.
[21:28:02 CEST] <jamrial> or we could request the addition of some startcode or whatever to the spec :p
[21:28:23 CEST] <jamrial> the past four days have seen a lot of changes to it after all
[21:28:44 CEST] <jkqxz> It's probably better to remove one or other of the formats.
[21:28:46 CEST] <jamrial> i'm not encoding shit until it's fully frozen because every file i create stop working after i git pull libaom
[21:29:22 CEST] <jkqxz> Or at least, it's not clear to me why having two incompatible but not distinguishable formats is anything but completely insane.
[21:30:03 CEST] <jamrial> atomnuker: ^
[21:31:51 CEST] <jamrial> or TD-Linux
[21:44:47 CEST] <rcombs> jamrial: maybe just standardize on one format in AVPacket and convert between them in muxers and demuxers
[21:44:53 CEST] <rcombs> erm, that was meant for jkqxz
[21:59:51 CEST] <durandal11707> atomnuker: so do we have that dct implementation or not, what do you think?
[22:14:31 CEST] <atomnuker> don't know, you can always make a dct using an fft though
[22:15:11 CEST] <durandal11707> how?
[22:16:37 CEST] <nevcairiel> seems like a terrible idea to make two bitstream formats without the ability to actually recognize them somehow
[22:17:06 CEST] <nevcairiel> that said you also need extradata to tell h264 annexb/mp4 apart properly, but at least its already defined there
[22:17:39 CEST] <nevcairiel> wtf is the av1 annexb mode even good for, without startcodes it cant go into TS anyway, so where would one use that
[22:18:47 CEST] <kierank> RTP I guess
[22:21:04 CEST] <nevcairiel> i saw the mode in the spec the other day, but as it is with specs, it  has no mention of why its useful
[22:25:48 CEST] <TD-Linux> jamrial, the annexb is basically a "container"
[22:25:50 CEST] <daddesio> durandal11707: The DCT-II of a signal x[n] (with length N) is equivalent to the (first N coefs of the) DFT of the sequence {0, x[0], ..., 0, x[N-1], 0, x[N-1], ..., 0, x[0]}.
[22:26:01 CEST] <TD-Linux> it should never exist inside e.g. mp4
[22:26:10 CEST] <daddesio> dct-iv requires a length 8N sequence. not sure about mdct.
[22:26:43 CEST] <TD-Linux> it is obnoxious and I argued against any such thing but some people love their "bitstreams"
[22:27:04 CEST] <nevcairiel> bitstreams without resync support seem hardly useful to me
[22:27:13 CEST] <atomnuker> daddesio, durandal11707: https://dsp.stackexchange.com/questions/2807/fast-cosine-transform-via-fft
[22:27:19 CEST] <atomnuker> I think the second method is simple
[22:27:20 CEST] <TD-Linux> nevcairiel, people like to pipe them between tools etc
[22:27:42 CEST] <atomnuker> mirror the output, 2n FFT, take the first n sampler
[22:27:45 CEST] <atomnuker> *saples
[22:27:45 CEST] <jamrial> that's ok and similar to h26x, but nothing stops anyone from muxing it anyway, and nothing seemingly distinguishes it from the "raw" bitstream
[22:27:51 CEST] <TD-Linux> without loss, no resync method is needed. some people wanted resync too but it really explodes the complexity
[22:28:06 CEST] <TD-Linux> jamrial, yeah it still makes the possibility of broken files :(
[22:28:14 CEST] <nevcairiel> having resync would mean you could go into mpegts
[22:28:21 CEST] <nevcairiel> not sure thats a good thing to have going for you tho
[22:28:36 CEST] <jkqxz> The raw bitstream with obu_size included already has the properties you want now.
[22:28:53 CEST] <TD-Linux> nevcairiel, you can go into mpegts even without
[22:29:09 CEST] <nevcairiel> yeah thats not going to be fun
[22:29:14 CEST] <TD-Linux> 99% of mpegts usage is for HLS which is not lossy
[22:29:21 CEST] <jkqxz> Or at least, there doesn't appear to be anything distinguishing them other than the annex B format being slightly nicer to read and write.
[22:29:22 CEST] <nevcairiel> seems like a bad idea
[22:30:03 CEST] <TD-Linux> you could also add something specific to the mpegts containerization, I suppose. currently there isn't one
[22:30:05 CEST] <nevcairiel> mpegts has no clear packetization, just some squirmy indicators where stuff is supposed to start
[22:30:18 CEST] <nevcairiel> and a 16-bit length field which is never big enough for video
[22:31:40 CEST] <TD-Linux> yeah. it would probably "work" as long as you split your HLS chunks in convenient locations
[22:31:48 CEST] <nevcairiel> you could call it mpegts, but a generic mpegts reader might have real trouble figuring it out
[22:31:49 CEST] <TD-Linux> (without adding a complex containerization)
[22:32:36 CEST] <TD-Linux> but yeah maybe whoever does the ts containerization should add some extra ts-specific resync stuff
[22:32:45 CEST] <nevcairiel> if thats even planned
[22:32:53 CEST] <nevcairiel> hls can use other containers now
[22:33:17 CEST] <TD-Linux> yeah, no one has started working on it so maybe we will never need it. but I'm pretty sure someone will do it at some point
[22:33:23 CEST] <TD-Linux> after all, we have h265 in AVI now
[22:33:51 CEST] <nevcairiel> "now"? I've seen that the day hevc was announced, pretty much
[22:34:00 CEST] <nevcairiel> also flv, but we successfully refused to support that
[22:34:54 CEST] <TD-Linux> jamrial, anyway I'd suggest being maximally strict right now wrt what you parse with ffmpeg and what containers you'll mux into right now
[22:35:15 CEST] <TD-Linux> maybe if browsers and ffmpeg don't play badly muxed files we can contain the damage
[22:35:17 CEST] <nevcairiel> so basically, we just ignore annexb then
[22:35:22 CEST] <TD-Linux> yes
[22:35:43 CEST] <nevcairiel> are any other containerizations defined yet? i think we only have matroska
[22:35:49 CEST] <jamrial> the wrapper is flagged as experimental, so at least people creating bad files will know they are doing so
[22:36:29 CEST] <TD-Linux> matroska/webm isn't even really defined but aomenc has a writer for it
[22:36:34 CEST] <jamrial> nevcairiel: ivf and matroska so far, but i think the latter isn't finished
[22:36:45 CEST] <TD-Linux> the isobmff one is the closest to having a real spec https://aomediacodec.github.io/av1-isobmff/
[22:36:50 CEST] <nevcairiel> how finished does matroska need to be, are we going to get extradata or what
[22:37:34 CEST] <jamrial> vp9 got CodecPrivate with vpcc kind of content down the road, although Google isn't really using it on youtube videos
[22:37:38 CEST] <TD-Linux> nevcairiel, are you happy with the current way it's packed? maybe we can just write it up and call it done
[22:37:55 CEST] <nevcairiel> mkvmerge added AV1 support in its latest release, which is why I assumed it was done already
[22:37:56 CEST] <jamrial> AV1 might get something like that, who knows
[22:38:06 CEST] <nevcairiel> he usually doesnt add unfinished stuff
[22:38:45 CEST] <TD-Linux> no one has talked about doing that, so it probably wouldn't happen. but I could try harder to turn that into a "definitely won't happen" by writing an actual spec
[22:39:11 CEST] <TD-Linux> nevcairiel, does adding codecprivate / extradata have any advantages as far as you're concerned?
[22:39:39 CEST] <TD-Linux> note that the isobmff spec actually puts the sequence header OBUs into the av1C
[22:40:23 CEST] <jamrial> TD-Linux: firefox uses the vpcc atom in mp4 to know if the file can be played before trying to decode a frame
[22:40:29 CEST] <nevcairiel> TD-Linux: mkv likes to borrow this design from mp4 (at least it did from h264/hevc), but with those codecs its actually required to decode, so eh.. it may have an advantage to be able to look at the codecprivate and figure out whats in the stream
[22:40:36 CEST] <jamrial> the CodecPrivate defined in https://www.webmproject.org/docs/container/ i guess can be used for the same thing
[22:40:52 CEST] <jamrial> so i could see AV1 taking advantage of something like that as well
[22:41:02 CEST] <TD-Linux> yeah, you either have to do that or peek into the sample entries / Blocks and find the sequence header there.
[22:41:31 CEST] <nevcairiel> isobmff seems to allow annexb, unless i read this wrong?
[22:41:55 CEST] <jamrial> Google for some reason still doesn't mux files using that CodecPrivate for youtube videos, so i haven't gotten around to add support for it in our muxer
[22:42:00 CEST] <nevcairiel> OBU_length_mode  seems to suggest the length code can be before the OBU header, which would be annexb?
[22:42:36 CEST] <TD-Linux> nevcairiel, ah yeah you're right. the spec has a note that we could mandate just one mode but isn't written that way right now
[22:44:34 CEST] <TD-Linux> this has changed since I last looked at it, sorry :(
[22:47:26 CEST] <atomnuker> as bad as it is at least the still image profile we defined is saner
[22:47:57 CEST] <atomnuker> just an av1 keyframe with the real time requirements dropped
[22:48:13 CEST] <TD-Linux> https://github.com/AOMediaCodec/av1-isobmff/issues/3
[22:49:27 CEST] <rcombs> atomnuker: what container did you go with
[22:49:36 CEST] <atomnuker> <NULL>
[22:50:15 CEST] <TD-Linux> jamrial, nevcairiel, do you want to comment there? ^ or give me opinions and I'll comment
[22:50:52 CEST] <rcombs> oh it's just a raw keyframe in a file?
[22:50:55 CEST] <rcombs> (or is it annex b)
[22:51:40 CEST] <TD-Linux> rcombs, it would be the isobmff mapping above, if the HEIF containerization gets adopted. so "annex b"
[22:51:58 CEST] <rcombs> please ban HEIF tiling thx
[22:52:17 CEST] <TD-Linux> rcombs, it is. it bans a lot of the insane HEIF stuff https://github.com/AOMediaCodec/av1-avif
[22:52:21 CEST] <TD-Linux> maybe not enough of it :)
[22:53:20 CEST] <TD-Linux> I still think it's super bloated for what you get
[22:54:03 CEST] <rcombs> oh are they still doing the "alpha is a separate bitstream" thing
[22:54:38 CEST] <rcombs> "we care about alpha enough to define specs to work around its absence, but not enough to actually make it a first-class part of the format"
[22:54:40 CEST] <nevcairiel> TD-Linux: the fact that multiple bitstream syntax variants even exist (beyond annexb, even at that) is going to make any decision insane, because it might require the muxer to rewrite it (as noted in that ticket already). That makes me wonder, does one even need to distinguish between "seciton 5" and "optimized" on a muxer level, there is a header flag for that anyway, isn't there.
[22:57:07 CEST] <TD-Linux> yeah there's a header flag, your muxer would have to distinguish because it'd have to set the container level flag appropriately. you could carry this as side data, but that seems super gross to me and I think a solution where all AVPackets are the same format would be way better.
[22:57:52 CEST] <nevcairiel> assume the container level flag doesnt exist, wouldn't both be decodable without any signaling? (exclude annexb in that scenario)
[22:58:22 CEST] <nevcairiel> it seems not overly relevant to the container to know this difference in the bitstream
[23:01:40 CEST] <TD-Linux> no. you can't parse without knowing whether the length is there or not. note that in the isobmff spec, the length at the beginning of the packet is different than the length encoded when the obu_has_size_field is 1.
[23:03:00 CEST] <nevcairiel> but the info if the length is there is included in the obu header, or so I understand the wording of this
[23:03:02 CEST] <TD-Linux> e.g. isobmff OBU_length_mode = 1 or 2 are decodable without signaling, but mode=0 is not
[23:03:15 CEST] <nevcairiel> yeah i want to ban 0 in that scenario
[23:03:17 CEST] <nevcairiel> death to annexb etc
[23:03:24 CEST] <TD-Linux> OBUs can have an internal length field, that's controllable with a flag in their header
[23:03:30 CEST] <TD-Linux> and annexb adds a second external length field
[23:04:11 CEST] <nevcairiel> Basically allow both 1/2 modes without signaling, dont allow 0
[23:04:19 CEST] <TD-Linux> nevcairiel, I agree. I would ban 0, remove the OBU_length_mode field, make AVPackets never contain annexb, and if some container allows annexb, that parser must de-annexb it
[23:04:52 CEST] <nevcairiel> de-annexbing s ounds a bit annoying if you actually need to add the internal size fields
[23:05:14 CEST] <nevcairiel> maybe annexb should've been the only mode to ever exist
[23:05:17 CEST] <nevcairiel> but what can you do
[23:05:59 CEST] <nevcairiel> but we seem to agree at least
[23:06:17 CEST] <TD-Linux> yeah, though annexb does waste a fair amount of space.
[23:06:43 CEST] <nevcairiel> are the internal size fields smaller?
[23:07:03 CEST] <nevcairiel> at worst you have the size field for the last obu which the 2 mode could skip
[23:08:40 CEST] <TD-Linux> I think some are also fixed size, so you don't need an internal size field at all, though the isobmff spec seems to imply that those would still need a signaled length so that benefit is lost
[23:15:42 CEST] <TD-Linux> nevcairiel, /s/timestamp/payload_length
[23:16:02 CEST] <nevcairiel> oh yeah
[23:16:06 CEST] <nevcairiel> i got confused
[23:16:20 CEST] <nevcairiel> thanks
[23:18:14 CEST] <TD-Linux> thanks for commenting though, I'll also keep following up with it
[23:18:47 CEST] <nevcairiel> no clue how much a comment from some random guy weighs for them tho, but better then not i guess
[23:22:10 CEST] <TD-Linux> I think you're pretty far from a "random guy" :)
[23:31:48 CEST] <nevcairiel> never know who actually knows you
[23:51:46 CEST] <TD-Linux> btw https://aomedia-review.googlesource.com/c/aom/+/54241
[23:57:24 CEST] <jamrial> TD-Linux: "encodere" :p
[23:58:33 CEST] <TD-Linux> fixed :)
[00:00:00 CEST] --- Wed Apr  4 2018