| Message ID | 20230712183252.302971-1-jeebjp@gmail.com |
|---|---|
| Headers | show |
| Series | avcodec: move HDR10 (MDCV/CLL) SEI handling to h2645_sei | expand |
On Wed, Jul 12, 2023 at 9:33 PM Jan Ekström <jeebjp@gmail.com> wrote: > > This allows parsing code to be re-utilized from H.264, as well as probably > from VVC in the future. > > This additionally eases verification of the AVCodecContext side data patch > set, which includes libx264 integration for HDR10 side data. > > Notes: > * At least in ffprobe and FATE tests the code works even without the additional > sync in "update_thread_context" in either HEVC or H.264 (as the viewing > environment SEI patch set showed earlier). As the current HEVC code had such > sync, I kept it and added a similar thing to the H.264 decoder. > ** If this is required for all things, the sync should possibly be added to > ff_h2645_sei_ctx_replace? As currently both the HEVC and H.264 decoders are > synchronizing various structs by themselves in addition to calling > ctx_replace. > * I did not add a simlar decrementing logic to the H.264 decoder for now, > as not sure how it should be handled exactly. > > Jan Ping for the set. Jan
On Sat, Jul 15, 2023 at 12:11 PM Jan Ekström <jeebjp@gmail.com> wrote: > > On Wed, Jul 12, 2023 at 9:33 PM Jan Ekström <jeebjp@gmail.com> wrote: > > > > This allows parsing code to be re-utilized from H.264, as well as probably > > from VVC in the future. > > > > This additionally eases verification of the AVCodecContext side data patch > > set, which includes libx264 integration for HDR10 side data. > > > > Notes: > > * At least in ffprobe and FATE tests the code works even without the additional > > sync in "update_thread_context" in either HEVC or H.264 (as the viewing > > environment SEI patch set showed earlier). As the current HEVC code had such > > sync, I kept it and added a similar thing to the H.264 decoder. > > ** If this is required for all things, the sync should possibly be added to > > ff_h2645_sei_ctx_replace? As currently both the HEVC and H.264 decoders are > > synchronizing various structs by themselves in addition to calling > > ctx_replace. > > * I did not add a simlar decrementing logic to the H.264 decoder for now, > > as not sure how it should be handled exactly. > > > > Jan > > Ping for the set. Ping^2 Jan
Quoting Jan Ekström (2023-07-12 20:32:44) > This allows parsing code to be re-utilized from H.264, as well as probably > from VVC in the future. > > This additionally eases verification of the AVCodecContext side data patch > set, which includes libx264 integration for HDR10 side data. > > Notes: > * At least in ffprobe and FATE tests the code works even without the additional > sync in "update_thread_context" in either HEVC or H.264 (as the viewing > environment SEI patch set showed earlier). As the current HEVC code had such > sync, I kept it and added a similar thing to the H.264 decoder. > ** If this is required for all things, the sync should possibly be added to > ff_h2645_sei_ctx_replace? As currently both the HEVC and H.264 decoders are > synchronizing various structs by themselves in addition to calling > ctx_replace. Is it supposed to apply to the current frame only or all the following ones as well. If the latter, you need to propagate it between thread contexts. > * I did not add a simlar decrementing logic to the H.264 decoder for now, > as not sure how it should be handled exactly. Not sure what you mean by decrementing - what is being decremented?
This allows parsing code to be re-utilized from H.264, as well as probably from VVC in the future. This additionally eases verification of the AVCodecContext side data patch set, which includes libx264 integration for HDR10 side data. Notes: * At least in ffprobe and FATE tests the code works even without the additional sync in "update_thread_context" in either HEVC or H.264 (as the viewing environment SEI patch set showed earlier). As the current HEVC code had such sync, I kept it and added a similar thing to the H.264 decoder. ** If this is required for all things, the sync should possibly be added to ff_h2645_sei_ctx_replace? As currently both the HEVC and H.264 decoders are synchronizing various structs by themselves in addition to calling ctx_replace. * I did not add a simlar decrementing logic to the H.264 decoder for now, as not sure how it should be handled exactly. Jan Jan Ekström (3): avcodec: move mastering display colour volume SEI handling to h2645_sei avcodec: move content light level SEI handling to h2645_sei avcodec/hevcdec: simplify decrementing of MDCV/CLL flags libavcodec/h2645_sei.c | 112 +++++++++++++++++++++++++ libavcodec/h2645_sei.h | 16 ++++ libavcodec/h264_slice.c | 2 + libavcodec/hevc_sei.c | 50 ----------- libavcodec/hevc_sei.h | 16 ---- libavcodec/hevcdec.c | 78 +++-------------- tests/ref/fate/hevc-hdr-vivid-metadata | 6 +- 7 files changed, 143 insertions(+), 137 deletions(-)