Re: [media-source] Sample Flags - Correctness vs Reality

Hi

there is active discussion of an improved track run design at MPEG.  May I forward this email to the file format group?  There are a couple of designs there and we hope to converge at the next meeting (Jan).

> On Oct 17, 2018, at 16:43 , Jamie Stackhouse via GitHub <sysbot+gh@w3.org> wrote:
> 
> itsjamie has just created a new issue for https://github.com/w3c/media-source:
> 
> == Sample Flags - Correctness vs Reality ==
> In debugging a few issues, I've started to look at how encoders are defining sample_flags at the ISOBMFF level, and noticed through working with content and talking with others in debugging this content that often times the data was incorrect. So I looked at what would go into defining the information as correct as possible.
> 
> However, what I found was that many encoders were taking advantage of `default_sample_flags` in the `tfhd` box, and `first_sample_flags` in the `trun` box.
> 
> This works for achieving playback, but through talking with @wolenetz and debugging a rise of failures related to our MP4 metadata in the Chrome implementation, we were notified that some frames were incorrectly marked as not keyframes when they in fact were.
> 
> In our case, verbosely defining the sample_flags for every sample entry lead to a box size increase of ~10% (600 bytes) per segment and was also of an unknown value as some demuxers only look for the first keyframe currently.
> 
> I believe that currently multiple `trun` boxes could be defined for each GOP, but in my investigation, I didn't see any encoder that output fragmented MP4 in this way. Curious if anyone knew why?
> 
> ---
> 
> Alternatively, I wanted to run by here, and if it makes sense raise for a revision to 14496-12 for including into a future revision of the spec.
> 
> The proposal is to add a new flag to the `trun` box, `indexed-sample-flags-present`. It would be treated as mutually exclusive to `sample-flags-present`, and `first-sample-flags-present`.
> 
> It would be an optional field + variable field array combination of the type:
> 
> ```
> unsigned int(32) indexed_sample_count
> {
>  unsigned int(32) sample_index;
>  unsigned int(32) sample_flags;
> }[indexed_sample_count]
> ```
> 
> I believe it would require a new minor_compliance brand in the same way as `default-base-is-moof`. This would allow a single `trun` box to define specific samples that had non-default flags easily. I believe striking a balance.
> 
> Thank you for any consideration of this.
> 
> Please view or discuss this issue at https://github.com/w3c/media-source/issues/221 using your GitHub account
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Monday, 22 October 2018 07:15:29 UTC