-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Cea708Decoder: Handle multiple service blocks #9967
Cea708Decoder: Handle multiple service blocks #9967
Conversation
When a asset contains multiple cc embedded tracks, current Cea708Decoder service block parsing logic is discarding all the data in that frame. For example, a manifest with 2 embedded CEA-708 close captions tracks: <Accessibility schemeIdUri="urn:scte:dash:cc:cea-708:2015" value="1=lang:eng;2=lang:spa"/> when the spanish track is selected (service number 2), when processing the following CEA-708 frame: FC9420FD2062FF0829FE8CFCFE9818FEE332FE731FFE1042FE2062FE0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000FA0000 the frame can be descomposed as: FF0829 FE8CFC FE9818 FEE332 FE731F FE1042 FE2062 FE0000 08 (00 001000) 0 (sequence) 8 (frame size) 298CFC9818E332731F10 422062 0000 ===== 29 (001 01001) 1 (service number) 9 (service block length) 8CFC9818E332731F10 42 (010 00010) 2 (service number) 2 (service block length) 2062 0000 Null block service The current processCurrentPacket logic will discard the whole frame is discarded because the first service number found in the frame belongs to service number 1, which is not the one we are currently looking for. This commit modifies the processCurrentPacket decoding logic, to take into account all service blocks available in the frame, by iteraring over the full frame data and skipping those service blocks we are not interesting in. Signed-off-by: Jorge Ruesga <jorge@ruesga.com>
Sorry for the delay in taking a look at this, thanks for sending these fixes over - it's really appreciated. I wonder if you'd be able to produce a very short (<500kB) test MPEG-TS file containing two service block IDs in a single packet that we could submit as part of this PR (so it's covered by the CLA) and use to drive some automated testing? No need for you to actually write the test - if you can supply the file I can do that bit. You can see some existing TS files (and you may be able to modify one of them for your purposes) here: |
// buffer is emptied, and, on each iteration, process only the block related to that | ||
// service block. if the specific service number is not the selected one, then just skip | ||
// it and continue with next service block. | ||
serviceBlockPacket.reset(currentDtvCcPacket.packetData, currentDtvCcPacket.currentIndex); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you think we should rename this from serviceBlockPacket
to e.g. captionChannelPacketData
(based on the names used in Figure 4 in Section 5 of CEA-708-B).
The current name suggests it contains a single service block, and the whole point of this PR is that assumption is incorrect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree. I will publish a new commit with the suggested modification.
I'm afraid I cannot provide a MPEG-TS sample file as all them are DRM protected. But, if that helps, I think I can provide sereral cea-708 frames that can be used to test the decoding logic. |
Thanks for the replies - I'll merge this PR as-is, if you get hold of the CEA-708 frames then please open a new PR containing just them and I can have a go at feeding them into the decoder in a test. |
Signed-off-by: Jorge Ruesga <jorge@ruesga.com>
@icbaker First at all, sorry for the delay to provide the requested information. Attached are some cea708 frames (like 1 minute) for a track with 2 embedded languages (1: English; 2: Spanish) The attached document contains the
Please, let me know if you require more information. |
…blocks PiperOrigin-RevId: 444816821
When a asset contains multiple cc embedded tracks, current Cea708Decoder service block parsing logic is discarding all the data in that frame.
For example, a manifest with 2 embedded CEA-708 close captions tracks:
when the spanish track is selected (service number 2), when processing the following CEA-708 frame:
the frame can be decomposed as:
The current processCurrentPacket logic will discard the whole frame is discarded because the first service number found in the frame belongs to service number 1, which is not the one we are currently looking for.
This commit modifies the processCurrentPacket decoding logic, to take into account all service blocks available in the frame, by iteraring over the full frame data and skipping those service blocks we are not interesting in.
Related to #9924