mirror of
https://github.com/CCExtractor/ccextractor.git
synced 2026-07-08 18:06:30 +00:00
[BUG] Garbled SRT from over air transport stream (TS) encoded from HDHomerun Extend #506
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jamesbigler on GitHub (Sep 18, 2019).
Please prefix your issue with one of the following: [BUG], [PROPOSAL], [QUESTION].
CCExtractor version (using the --version parameter preferably) : 0.88 (compiled on OSX with brew)
In raising this issue, I confirm the following (please check boxes, eg [X] - and delete unchecked ones):
My familiarity with the project is as follows (check one, eg [X] - and delete unchecked ones):
Necessary information
-delay 1500 test.ts -o test.v0.88.srtVideo links (replace text below with your links)
This is a truncated file created with dd. Transport streams should support truncation.
https://www.dropbox.com/s/6mivq9mdtupfiy4/test.ts?dl=0
Additional information
Here's an example:
This should say:
This should say:
Here's the output: https://www.dropbox.com/s/0oduki0uyhcmghq/test.srt?dl=0
I viewed it in EyeTV, and it displayed the CC correctly, so I know the data is there.
@thealphadollar commented on GitHub (Sep 28, 2019):
This issue is definitely reproducible though I have not been able to figure out what could be actually causing the issue at first place. @cfsmp3 Any leads?
@cfsmp3 commented on GitHub (Sep 28, 2019):
Do the files play correctly in VLC? The subtitles I mean.
If yes, we have a bug. Otherwise I'd say it's a problem with the input.
On Fri, Sep 27, 2019, 19:34 Shivam Kumar Jha notifications@github.com
wrote:
@jamesbigler commented on GitHub (Sep 28, 2019):
They seem to play fine for me with Windows VLC 3.0.8.
They also played fine with EyeTV as mentioned in the original report.
@thealphadollar commented on GitHub (Sep 28, 2019):
The test.ts file you've provided isn't working in either of my video
players. Can you please provide another file?
On Sat, Sep 28, 2019 at 9:03 AM jamesbigler notifications@github.com
wrote:
@jamesbigler commented on GitHub (Sep 28, 2019):
What video player are you using?
I’m not sure I can provide a different kind of file since the source is
over the air transport streams.
What versions of VLC have you tried if you tried VLC?
On Sat, Sep 28, 2019 at 6:58 AM Shivam Kumar Jha notifications@github.com
wrote:
@thealphadollar commented on GitHub (Sep 28, 2019):
On Sat, Sep 28, 2019 at 7:15 PM jamesbigler notifications@github.com
wrote:
@jamesbigler commented on GitHub (Sep 29, 2019):
That’s the same version (at least by number) I used on Windows. I’m not
sure what the differences are between the same version in different
systems.
What error do you see?
On Sat, Sep 28, 2019 at 7:49 AM Shivam Kumar Jha notifications@github.com
wrote:
@thealphadollar commented on GitHub (Sep 29, 2019):
It's just not playing.
On Sun, Sep 29, 2019 at 10:00 AM jamesbigler notifications@github.com
wrote:
@cfsmp3 commented on GitHub (Sep 29, 2019):
It plays for me, but the captions in VLC also appear totally garbled.
@jamesbigler commented on GitHub (Sep 30, 2019):
OK, I was able to reproduce the (no) playback issue on OSX. VLC said it
was getting end of file. Not sure why, because it is a transport stream
and doesn't need an EOF.
I was able to get it to play back by
Because TS is a stream format, this should work. I was able to open the
file on my system this way.
See if this works for you.
On Sun, Sep 29, 2019 at 7:46 AM Carlos Fernandez Sanz <
notifications@github.com> wrote:
@cfsmp3 commented on GitHub (Sep 30, 2019):
It plays in VLC for me but the closed captions VLC displays are garbled.
On Sun, Sep 29, 2019 at 9:11 PM jamesbigler notifications@github.com wrote:
@jamesbigler commented on GitHub (Sep 30, 2019):
Oh, I missed your second email about being able to play the file.
I'm not sure why the same file using the same version of VLC would have
different behavior. That's frustrating.
Which stream are you using? I'm using "Closed captions 1"
Do you absolutely need to see VLC play the CC back correctly? I can
provide more screen shots if needed.
[image: vlcsnap-2019-09-29-23h13m01s365.png]
Captured from ccextractor:
14
00:00:21,787 --> 00:00:24,722
Orge, t toou yr neighborho
odMcnaDold's now.
On Sun, Sep 29, 2019 at 10:53 PM Carlos Fernandez Sanz <
notifications@github.com> wrote:
@cfsmp3 commented on GitHub (Oct 1, 2019):
Using "closed captions 1" in VLC I get lots of garbled text.
It's not that we need it to play well in VLC. But if CCExtractor shows it garbled, and VLC shows it garbled, most likely the problem is with the input data and not with the software.
This is VLC for me:
@jamesbigler commented on GitHub (Oct 1, 2019):
Right. I totally get that you want to make sure the data isn't corrupt to
begin with.
I have three different instances where the captions worked for me.
used it for years to record and play back TV before getting Plex+NAS).
I don't have a linux machine to test with at the moment, but I'll ask
around at work and see if I can get some additional corroboration.
On Tue, Oct 1, 2019 at 9:42 AM Carlos Fernandez Sanz <
notifications@github.com> wrote:
@jamesbigler commented on GitHub (Oct 1, 2019):
Buddy at work tried on Linux with version VLC v 3.0.7 Vetinari, and it showed the captions correctly.
Would there be an issue with localization or some other aspect of VLC that would treat the data differently between our systems?
@cfsmp3 commented on GitHub (Oct 2, 2019):
Plays OK for me in 3.0.8. Garbled in 2.2.3.
My first idea (haven't verified it) is that HDHomeRun is storing the captions in display order instead of decoding order along the frames and it's actually us garbling them while sorting. But this is just a theory.
In any case I guess a reasonable approach is go over the change file in the VLC and find where they fixed it, then look at the actual source code.
@cfsmp3 commented on GitHub (Dec 17, 2025):
@jamesbigler Do you happen to have this file still around?
@jamesbigler commented on GitHub (Dec 17, 2025):
Dang! I actually just deleted those from my dropbox about 2 months ago, and they only remain in my deleted folder for 30 days.
I'll need to check my other backups.
Hey, I found it on my server's recycle bin. I guess it's good I didn't clean that out. ;)
https://www.dropbox.com/scl/fi/hybmfylnf94p6chk3ff83/test.ts?rlkey=592o2iiig3p94w3f9rh9q9qc5&st=dwgmdm7t&dl=0
@cfsmp3 commented on GitHub (Dec 18, 2025):
Yes! Thanks! Fixed!
@jamesbigler commented on GitHub (Jan 26, 2026):
@cfsmp3 That great you were able to fix the issue.
Do you still need the reproducer file available? I would like to not have to host it forever more. :)
@cfsmp3 commented on GitHub (Jan 26, 2026):
I think we're good, thanks!