Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DecodeStatus needs enriching #15

Open
DanielBujnik opened this issue Feb 27, 2024 · 0 comments
Open

DecodeStatus needs enriching #15

DanielBujnik opened this issue Feb 27, 2024 · 0 comments

Comments

@DanielBujnik
Copy link

Hello,

ARIB-B24 spec does not specify how/when caption management data should be sent. While analyzing various streams, I've observed two distinct patterns: some streams consistently place management data ahead of caption statements, while others exhibit sporadic transmission of management data, with intervals of around 10 seconds. During these intervals, numerous caption statements are broadcasted, necessitating the ability to distinguish and ignore them until management data is received.

Currently, users of the libaribcaption library face challenges in determining the type of data received. The DecoderImpl::Decode function, along with the enum DecodeStatus, only covers three cases: error, noCaption, and gotCaption. Therefore, I attempted to treat noCaption as an indicative of caption management data. However, this approach proved unreliable, as valid caption statement data was occasionally misinterpreted as noCaption. This occurred particularly when utilizing EncodingScheme::kAuto with a Latin broadcast stream where no regions were recognized, resulting in noCaption from DecoderImpl::Decode. Resolving this required switching to EncodingScheme::kABNT_NBR_15606_1_Latin during decoder initialization.

To address this inconsistency, it would be beneficial to extend the DecodeStatus enumeration with a new value, such as kMgnt and enhancing DecoderImpl::Decode to return kMgnt specifically for identifying caption management data.

Alternatively, it's worth investigating the possibility of a bug within the library where valid caption statement data is erroneously interpreted as noCaption as described above.

Kind regards
Daniel

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant