HDR10+ SEI payloadSize being injected twice.
Last version I was using for HDR10+ metadata encoding was from 2017-07-06 commit and the payloadSize was showing up correct in the payload stream.
Current version inserts the payloadSize into the stream TWICE and it actually has a +1 value for the first injected payloadSize value. (this +1 is the amount of bytes in the payload size value)
I think the issue comes from commit 2f6bb6f to fix Issue #353
From what I found, m_payloadSize is being used to write the payload size bytes at sei.cpp
if (hrdTypes || m_payloadType == USER_DATA_UNREGISTERED || m_payloadType == USER_DATA_REGISTERED_ITU_T_T35)
{
if (hrdTypes)
{
X265_CHECK(0 == (count.getNumberOfWrittenBits() & 7), "payload unaligned\n");
payloadSize = count.getNumberOfWrittenBits() >> 3;
}
else if (m_payloadType == USER_DATA_UNREGISTERED)
payloadSize = m_payloadSize + 16;
else
payloadSize = m_payloadSize;
for (; payloadSize >= 0xff; payloadSize -= 0xff)
WRITE_CODE(0xff, 8, "payload_size");
WRITE_CODE(payloadSize, 8, "payload_size");
}
else
WRITE_CODE(m_payloadSize, 8, "payload_size");
but the actual m_payload from sei.h ALSO includes the payloadSize bytes, so they are writen twice.
// daniel.vt@samsung.com :: for the Creative Intent Meta Data Encoding ( seongnam.oh@samsung.com )
void writeSEI(const SPS&)
{
if (!m_payload)
return;
uint32_t i = 0;
for (; i < m_payloadSize; ++i)
WRITE_CODE(m_payload[i], 8, "creative_intent_metadata");
}
The original idea was the second approach, but since being adapted to use m_payloadSize (the more libx265 like approach) there seems to be a conflict in the payloadSize injection logic.
It might be needed to skip the injection of payloadSize bytes from the m_payload in sei.h, and also don't consider that byte(s) for the value of m_payloadSize.
Comments (5)
-
-
reporter Thank you for the patch Bhavna.
This works for the general case where the payloadSize is only one byte long (payload of 255 or less), but the repeat effect still happens for the second byte if the payloadSize is longer.
-
https://mailman.videolan.org/pipermail/x265-devel/2017-September/011262.html
Please verify with this updated patch. Thanks.
-
reporter This patch seems to fix the issue correctly, thank you for your help Bhavna!
-
Account Deactivated - changed status to closed
fix pushed into default branch
- Log in to comment
Could you please apply this patch and try again? This should fix the issue.
https://mailman.videolan.org/pipermail/x265-devel/2017-September/011260.html