mirror of
https://github.com/CCExtractor/ccextractor.git
synced 2026-02-13 21:22:29 +00:00
[BUG] MP4 box name as random video data at beginning of TS-recording trips format-detection #693
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 @hurda on GitHub (Mar 8, 2022).
CCExtractor version: 0.94
In raising this issue, I confirm the following:
Necessary information
ccextractorwinfull.exe -autoprogram -out=srt -bom -utf8 file.tsVideo links
Additional information
After running countless of DVB-recordings through ccextractor to the subtitles from the teletext, this file was the first to not getting processed at all, instead I got this console-output:
Forcing the input-file-format with
-in=tsworked and the subtitle was created successfully, but I wanted to get down to the cause of the problem.After going through the source and checking how the format-detection works, I saw that CCE is checking the video for certain strings to determine the format, at least that's how I understood it.

I opened the TS-file in a hex-editor and searched for
moov:Position 727131 0xB185B
Luckily that was a payload-only TS-packet of the video-PID, so I was free to just change the text to something else.
Then I ran this modified file through ccextractor, which worked:
@canihavesomecoffee commented on GitHub (Mar 9, 2022):
Well, it's the first time in about 7 years we see this kind of issue (code for this was added by me in #165), so that sample would definitely be welcome.
Looks like my approach back then wasn't fully bulletproof.
@hurda commented on GitHub (Mar 9, 2022):
Trimmed the file to the first megabyte, as that's what the format-autodetection is looking at, right?
https://www.mediafire.com/file/xt5s9pd6yj3hc4q/ccextractor_moov_ts.zip/file
Contains the original file and the edited version.
@canihavesomecoffee commented on GitHub (Mar 9, 2022):
Yes, that should be sufficient indeed. Thanks for the quick share.
@cfsmp3 commented on GitHub (Mar 21, 2023):
Closing since it seems fixed already (at least based on the merge, I haven't validated)