[PR #1528] [FIX] Incorrect skipping of packets #2250

New Issue

claunia · 2026-01-29T17:21:08Z

claunia commented

2026-01-29 17:21:08 +00:00

Original Pull Request: https://github.com/CCExtractor/ccextractor/pull/1528

State: closed
Merged: Yes

In raising this pull request, I confirm the following (please check boxes):

I have read and understood the contributors guide.
I have checked that another pull request for this purpose does not exist.
I have considered, and confirmed that this submission will be valuable to others.
I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
I give this submission freely, and claim no ownership to its content.
I have mentioned this change in the changelog.

My familiarity with the project is as follows (check one):

I have never used CCExtractor.
I have used CCExtractor just a couple of times.
I absolutely love CCExtractor, but have not contributed previously.
I am an active contributor to CCExtractor.

Partially Fixes #1468

The reason why none of the text was showing up was because the given sample had service blocks of this kind:
80 ff 8c ff 9c 18 46 19 00 1f 11 84 92 00 04 90 05 00 91 2a 00 00

80 - Set Current Window to 0 - Does nothing since Window was never defined before.
ff - character from G1 charset - The current implementation skips the entire packet if character is attempted to be inserted in an undefined window, which it was during this point.
8c ff - Delete Windows specified with bitmap ff - Does nothing since no windows were defined in the first place.
9c ... - Define Window 4 - Here comes the actual definition of the window that will contain all the text but this is never executed due to the second byte (ff).

All the window definitions followed the above pattern, hence a window was never defined, so all the text did not show up.
After fixing the implementation to only skip 1 character instead of entire packet, the following text was extracted:

1
00:00:01,234 --> 00:00:01,634
    <font color="#aaaaaa">Closed Captioning Insertion</font>

2
00:00:02,235 --> 00:00:02,635
    <font color="#aaaaaa">From PixelTools </font>

3
00:00:03,236 --> 00:00:03,636
    <font color="#aaaaaa">Have a Nice Day!</font>

Only the first line is skipped because the packet stream literally started from This is a demo of the. Definition of Window 4 only came later. We could fix it by defining all windows before hand but that will against the CEA-708 spec.

This was enough to get it fixed at the Rust side. The C side required more work.

The given sample file had packets of invalid length specified. The current implementation assumes the given packet length is valid. If the specified length is more than the actual length, it just keeps appending the content of the next packet too. (Here the actual length is till the next Packet Start). This problem was fixed by clearing the packet before the start of a new packet if it was not cleared previously. Hence this would skip the packets of invalid length.
Even though this error was not visible in Rust, I have still ported the code for parity's sake. The code at Rust side was able to clear the packet correctly even before this. I still haven't figured out how. Some help on this would be great.

Also, it is debatable if packets of invalid length should be processed or skipped. For now, I have chosen to skip them but they could very well be processed since such packets in the sample file had service number 0. Some advice on this will be very helpful.

**Original Pull Request:** https://github.com/CCExtractor/ccextractor/pull/1528 **State:** closed **Merged:** Yes ---  **In raising this pull request, I confirm the following (please check boxes):** - [x] I have read and understood the [contributors guide](https://github.com/CCExtractor/ccextractor/blob/master/.github/CONTRIBUTING.md). - [x] I have checked that another pull request for this purpose does not exist. - [x] I have considered, and confirmed that this submission will be valuable to others. - [x] I accept that this submission may not be used, and the pull request closed at the will of the maintainer. - [x] I give this submission freely, and claim no ownership to its content. - [x] **I have mentioned this change in the [changelog](https://github.com/CCExtractor/ccextractor/blob/master/docs/CHANGES.TXT).** **My familiarity with the project is as follows (check one):** - [ ] I have never used CCExtractor. - [x] I have used CCExtractor just a couple of times. - [ ] I absolutely love CCExtractor, but have not contributed previously. - [ ] I am an active contributor to CCExtractor. --- Partially Fixes #1468 The reason why none of the text was showing up was because the given sample had service blocks of this kind: `80 ff 8c ff 9c 18 46 19 00 1f 11 84 92 00 04 90 05 00 91 2a 00 00` - `80` - Set Current Window to 0 - Does nothing since Window was never defined before. - `ff` - character from G1 charset - The current implementation skips the entire packet if character is attempted to be inserted in an undefined window, which it was during this point. - `8c ff` - Delete Windows specified with bitmap `ff` - Does nothing since no windows were defined in the first place. - `9c ...` - Define Window 4 - Here comes the actual definition of the window that will contain all the text but this is never executed due to the second byte (`ff`). All the window definitions followed the above pattern, hence a window was never defined, so all the text did not show up. After fixing the implementation to only skip 1 character instead of entire packet, the following text was extracted: ``` 1 00:00:01,234 --> 00:00:01,634 Closed Captioning Insertion 2 00:00:02,235 --> 00:00:02,635 From PixelTools 3 00:00:03,236 --> 00:00:03,636 Have a Nice Day! ``` Only the first line is skipped because the packet stream literally started from `This is a demo of the`. Definition of Window 4 only came later. We could fix it by defining all windows before hand but that will against the CEA-708 spec. This was enough to get it fixed at the Rust side. The C side required more work. The given sample file had packets of invalid length specified. The current implementation assumes the given packet length is valid. If the specified length is more than the actual length, it just keeps appending the content of the next packet too. (Here the actual length is till the next Packet Start). This problem was fixed by clearing the packet before the start of a new packet if it was not cleared previously. Hence this would skip the packets of invalid length. Even though this error was not visible in Rust, I have still ported the code for parity's sake. The code at Rust side was able to clear the packet correctly even before this. I still haven't figured out how. Some help on this would be great. Also, it is debatable if packets of invalid length should be processed or skipped. For now, I have chosen to skip them but they could very well be processed since such packets in the sample file had service number 0. Some advice on this will be very helpful.

claunia added the pull-request label 2026-01-29 17:21:08 +00:00

claunia closed this issue

2026-01-29 17:21:08 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/ccextractor#2250