mirror of
https://github.com/CCExtractor/ccextractor.git
synced 2026-02-16 13:35:45 +00:00
[Bug] Random failures with buffered input on stdin with certain files #448
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 @mackworth on GitHub (Oct 22, 2018).
Per @cfsmp3 request on Issue #436, I am opening a new issue on this bug. I have confirmed it is still a problem.
Just updated my copy to the latest master from github, recompiled on my Mac and have the exact same symptoms.
To be specific, when run through stdin pipe, the sample file available here, has a high probability of failing (averaging 7 successes out of 20) with
Error: Syntax problem: Final 0xFF marker missing. The log file saysTS continuity counter not incremented prev/curr 4/15. But depending on the run, I've seen 2, 9, or 15 for the "curr" number.To recreate in Bash, set
fto test file andccextractorto compiled exe, then runfor i in $(seq 1 1 20); do cat "$f" | $ccextractor -bi - -o junk3.srt > "junkNew$i.log"; if [ $? -eq 0 ]; then echo "OK "; else echo "Fail"; fi; doneCCExtractor version : 0.87
In raising this issue, I confirm the following (please check boxes, eg [X] - and delete unchecked ones):
[X ] I have read and understood the contributors guide.
[X ] I have checked that the bug I am reporting can be replicated
[ X] I have checked the pull requests tab for existing solutions/implementations to my issue/suggestion.
[X ] I have used the latest available version of CCExtractor to verify this issue exists.
[X ] I absolutely love CCExtractor, but have not contributed previously.
Necessary information
ccextractor -bi - -o junk3.srt > "junkNew$i.log";**Video links (replace text below with your links) **
https://www.dropbox.com/s/zo6ta9d8ppl093p/RobotChicken-RandomFailuresBI.mpg?dl=0
@mackworth commented on GitHub (Nov 7, 2019):
So the good news is this looks like this bug was patched over in 0.88.
(From Release notes:
- Fix: Warn instead of fatal when a 0xFF marker is missing' )However, the log still reports random failures (11/20 on my last run). It still says
TS continuity counter not incremented prev/curr 4/15.(and depending on the run, I've seen 2, 9, or 15 for the "curr" number, but always 4 for theprev). But now v.88 follows it withWarning! Syntax problem: Final 0xFF marker missing. Continuing...and dumps a bunch of video data (7Mb log file v 7K on a 'successful' run).So given we're using the same video over and over and getting different results, it still looks to me like some uninitialized variable affecting the
currvalue, which is then triggering the FF problem.On the other hand, the .SRT file generated is now close to correct. The FF issue skips a bit of video, as comparing the results gives:
Runs with 'TS continuity' error msg:
They're supposedo one the most gentle(16 seconds in; correct otherwise)Runs without error msg
They're supposed to be one of the most gentleRandomly generating a file with a minor glitch is certainly far better than the randomly failing, but I don't think the underlying bug is fixed.
Attached are the log files and SRTs for a good run and a bad run, as well as the shell script I used.
Archive.zip From our previous discussion, note that this bug only happens if the video be piped in (in this case from
cat).The video is still on Dropbox. Note that I added a .jnk as there was an issue before about downloading a video file; just remove that extension.
My binary copy of ccextractor is here (compiled from source yesterday)
Let me know if there's anything else I can provide.
@cfsmp3 commented on GitHub (Jan 25, 2020):
@mackworth is this still happening with current master?
@mackworth commented on GitHub (Jan 25, 2020):
so, the literal answer to your question is yes, I'm seeing exactly the same results as in Nov, but I'm also still seeing version 0.88 in master (with a reference in changes.txt to a version 0.89 TBD). Is there a different branch I should use?
@cfsmp3 commented on GitHub (Jan 26, 2020):
No, current master. We still haven't bumped the version number, even though it has a significant amount of changes.
@mackworth commented on GitHub (Jan 26, 2020):
Okay, then, yes, I did a git pull and rebuilt prior to running the test again, but got almost the exact same results. Still seeing about 5-9 "good" runs out of twenty tries. The bad runs still drop exactly the same characters.
Comparing the "good runs" logs to an old good log with debug off, I see "Filter profanity: No" and dozens of "WARNING:get_decoder_line_encoded:Invalid Color index Selected 151587081" msgs (not in the variable region), but otherwise identical. Identical differences in the bad logs.
Same difference between good and bad runs. Identical until
XDS Notice: Program is now Robot Chicken, Easter Basketthen the good one says:But the bad one says:
@cfsmp3 commented on GitHub (Mar 22, 2023):
@mackworth Is the problem still happening?
@cfsmp3 commented on GitHub (Dec 21, 2025):
Closing since we didn't have confirmation - @mackworth let us know if it's still happening.
@mackworth commented on GitHub (Dec 24, 2025):
Sadly, I never saw the 2023 request, and I no longer seem to have the file that demonstrates the problem. I've tried a few new videos, and I do see some failures in captioning with errors like "Syntax problem: Final 0xFF marker missing. Continuing" "Unexpected SEI unit length...trying to continue. Failed block (at sei_rbsp) was: " ...
But with TiVo's gradual decay into irrelevance, not many folks are using the cTiVo app any more, so if you're not seeing similar errors elsewhere, I'm good with closing this out.