backport from dav1d 1.2.0: picture: allow storing an array of Dav1dITUTT35 entries
#528
Conversation
kkysen
changed the title
dav1d 1.2.0: picture: allow storing an array of Dav1dITUTT35 entries
There have been quite a few changes since this was initially written. Definitely needs another round of reviews. I am using |
|
@kkysen Can you have another look at this when you have time? I am sure there are better ways of doing this. Also, some more recent commits in dav1d build on top of this, so it may be good to have this integrated in a not too distant future. |
Please go ahead |
Nothing in the spec prevents a Temporal Unit from having more than one Metadata OBU of type ITU-T T.35, so export them as an array instead of only exporting the last one we parse. This is backwards compatible with the previous implementation, as users unaware of this change can ignore the n_itut_t35 field and still access the first (or only) entry in the array as they have been doing until now.
…e generic and equivalent `mem::take`.
kkysen
changed the base branch from
main
to
kkysen/remove-Rav1dPicture-mem-zeroed
…g it an `Arc<TryLock<DRav1d<Vec<_>, Vec<_>>>>`. Due to the now shared access to the `itut_t35` `Vec` to push new ones during parsing, I added a zero-contention `TryLock` around it. This also adds a lot of explicit initialization that was previously just zero initialized, since the `Arc` is not all zeros.
…o `Box<[_]>`s since the mutation only happens on `Rav1dContext::itut_t35`.
…re::itut_t35` needs it.
|
Ugh, why did this get automatically closed? |
Partially addresses #224