Generally speaking, having the demuxer (or stream parser) peek at coded frame contents can be risky: it violates layers, and more importantly, if the coded frame is encrypted, some or all of the peeked-at-data may not be interpretable by the demuxer.

In this particular case, are Temporal Delimiter OBUs guaranteed to NOT be encrypted, and are they guaranteed to be the very first byte in the coded frame (I'm unfamiliar with the av1 bitstream itself, sorry if FAQ)?

> Generally speaking, having the demuxer (or stream parser) peek at coded frame contents can be risky: it violates layers, and more importantly, if the coded frame is encrypted, some or all of the peeked-at-data may not be interpretable by the demuxer.

I'd love it if there were an alternative, but there really isn't one in this case. AV1 ISOBMFF allows this (omission of TDs is a SHOULD[1]), and so will Matroska (removal is actually a MUST[2] in MKV). 

> In this particular case, are Temporal Delimiter OBUs guaranteed to NOT be encrypted, and are they guaranteed to be the very first byte in the coded frame (I'm unfamiliar with the av1 bitstream itself, sorry if FAQ)?

Yes[3] and yes[4].

[1] https://aomediacodec.github.io/av1-isobmff/#sampleformat
[2] https://github.com/Matroska-Org/matroska-specification/blob/av1-mappin/codec/av1.md#block-data
[3] https://aomediacodec.github.io/av1-isobmff/#CommonEncryption
[4] https://aomediacodec.github.io/av1-spec/av1-spec.pdf#page=204 (see 7.5, ordering of OBUs; a Temporal Unit is a sample)

Ack. Thanks Tom. I'm curious: could the decoder (or the Chrome decoder wrapper) do the insertion of this info, not the parser or demuxer? sandersd@ (cc'ed) has been considering some rework of our existing Annex-B conversion (currently done during parsing) to instead only occur if necessary in the decoder wrapper (e.g. maybe the solution to crbug 758668). I haven't marked this bug as blocked by that refactor, just a heads-up. If such OBU insertion couldn't be done by the decoder wrapper, that other bug will probably need to include that tidbit of info.

I'd be extremely happy if changes can be handled in the decode wrapper-- since this is part of the file format bindings I titled this issue as if it were a demux specific change, but it certainly doesn't have to be that way when support is implemented. Once we have muxers generating content with the TD omitted I'll start work on a patch, and I'll try to keep the patch limited to changes within aom_video_decoder.cc.

Pinging this thread, are we still waiting on the right content w/o Temporal Delimiters?