The existing code in this file is inconsistent, but comparing the result with -1 or 0 would clarify that the function does not return a bool.

Thanks for adding this!

t<->a

Can defaultDuration be obtained from Context(aType), here or in ReadMetadata().
Repeating the track property on the NesteggPacketHolders is unexpected to me, given it is not a property of the packet.

ReadMetadata() is already doing some nanosecond conversion.

I can see some benefit of getting the default duration in the NesteggPacketHolder, if it were to use the default duration as a default/fallback value for Duration(). That is, if you are happy to prefer the default duration over using the previous timestamp difference.

Any idea why next_holder->Timestamp() is preferred over holder->Duration().
The docs are clear that BlockDuration should be preferred over using the timecode of the next Block.

When not written and with no DefaultDuration, the value is assumed to be the difference between the timecode of this Block and the timecode of the next Block in "display" order (not coding order).

Do you know why next_holder is assumed to be the next in display order?
I was expecting next_holder to be the next in *coding* order.

We don't need to make a change here at the same time as adding the DefaultDuration, and perhaps better if we don't, at least if this patch might be uplifted. Would be good to know why we do it this way though.

defaultDuration looks a better indicator of duration than tstamp - lastFrameTime.ref(). How would you feel about preferring defaultDuration?

That would be more consistent with what Chromium is doing.