-
Notifications
You must be signed in to change notification settings - Fork 6k
Description
Previous version of the v1 and v2-dev branches had the entire SEI data put into a buffer and then read by the Eia608Parser. The parser had a check that the type and validity bits are set to channel 1 of the 608 content, and everything else was dropped. See: V1
if (ccType != 0) { seiBuffer.skipBits(16); continue; }
Here the ccType values mean:
- 0 = channel 1 and 2 of EIA-608
- 1 = channel 3 and 4 of EIA-608
- 2 = Start of EIA-708 content (channel ID is defined inside the stream)
- 3 = Chunk of EIA-708 content
As only value 0 was handled, and no additional checks were used to separate channel 1 and 2: a single 608 channel was supported. I added my additional channel and EIA-708 support by updating the Eia608Parser to collect the data instead of dropping it, so channel 3-4 and EIA-708 bits were collected and parsed appropriately.
In the latest v2 code, all these additional data are dropped at SeiReader level:
V2
like:
if (ccValidityAndType != 0x04) { seiBuffer.skipBytes(2); }
The change was: Link
SeiReader seems to be the correct location to filter 608/708 and channel information, but needs serious changes in the architecture I had. Are you guys planning to ever support EIA-708 (as it is an FCC requirement from 2017)? Did you consider supporting the other channels of EIA-608? Any similar changes like the one you made in the v2-dev branch requires lots of changes to support all subtitles correctly, that is why I am interested in the plans about supported formats.
Are you willing to accept pull requests related to these features or are you maybe already working on these issues?
Big Thanks!