Apple Iphone 5 sample #29

New Issue

claunia · 2026-01-29T16:33:15Z

claunia commented

2026-01-29 16:33:15 +00:00

Originally created by @canihavesomecoffee on GitHub (Jun 17, 2014).

I'll submit it here, and I'll be working on it. I got some extra information and have the next conclusions so far:

file comes from the site of apple. Other samples from same site are apparently ok, this one isn't.
Subtitles are messed up on several different players (VLC, MPC-HC, ...), but play fine on QuickTime
Subtitles are in english.

Some media info:

General:
Format : MPEG-4
Format profile : QuickTime
Codec ID : qt
File size : 15.9 MiB
Duration : 30s 167ms
Overall bit rate : 4 430 Kbps
Encoded date : UTC 2014-02-11 15:46:11
Tagged date : UTC 2014-02-11 15:46:12
Writing library : Apple QuickTime

Text
ID : 5-CC1
Format : EIA-608
Muxing mode : Final Cut
Codec ID : c608
Duration : 30s 167ms
Source duration : 30s 163ms / 30s 155ms
Bit rate mode : Constant
Stream size : 0.00 Byte (0%)
Source stream size : 32.7 KiB (0%)
Language : English
Encoded date : UTC 2014-02-11 15:46:11
Tagged date : UTC 2014-02-11 15:46:12

This would lead me to think that QuickTime doesn't 100% follow the standards or does something special, because they generated the file and can read it out again, but CCExtractor & other media players can't.

Originally created by @canihavesomecoffee on GitHub (Jun 17, 2014). I'll submit it here, and I'll be working on it. I got some extra information and have the next conclusions so far: - file comes from the site of apple. Other samples from same site are apparently ok, this one isn't. - Subtitles are messed up on several different players (VLC, MPC-HC, ...), but play fine on QuickTime - Subtitles are in english. Some media info: General: Format : MPEG-4 Format profile : QuickTime Codec ID : qt File size : 15.9 MiB Duration : 30s 167ms Overall bit rate : 4 430 Kbps Encoded date : UTC 2014-02-11 15:46:11 Tagged date : UTC 2014-02-11 15:46:12 Writing library : Apple QuickTime Text ID : 5-CC1 Format : EIA-608 Muxing mode : Final Cut Codec ID : c608 Duration : 30s 167ms Source duration : 30s 163ms / 30s 155ms Bit rate mode : Constant Stream size : 0.00 Byte (0%) Source stream size : 32.7 KiB (0%) Language : English Encoded date : UTC 2014-02-11 15:46:11 Tagged date : UTC 2014-02-11 15:46:12 This would lead me to think that QuickTime doesn't 100% follow the standards or does something special, because they generated the file and can read it out again, but CCExtractor & other media players can't.

claunia closed this issue

2026-01-29 16:33:15 +00:00

claunia commented

2026-01-29 16:33:16 +00:00

@canihavesomecoffee commented on GitHub (Jun 17, 2014):

I'll be looking into this specific file later, but for now some references:

https://developer.apple.com/library/mac/documentation/quicktime/qtff/qtffchap3/qtff3.html

The file seems to be having a lot of those CC "atoms", which further contain the actual CC data. Task here will be to figure out how those "atoms" are structured and then try to get the actual CC data joined together so that it can be read out correctly.

@canihavesomecoffee commented on GitHub (Jun 17, 2014): I'll be looking into this specific file later, but for now some references: https://developer.apple.com/library/mac/documentation/quicktime/qtff/qtffchap3/qtff3.html The file seems to be having a lot of those CC "atoms", which further contain the actual CC data. Task here will be to figure out how those "atoms" are structured and then try to get the actual CC data joined together so that it can be read out correctly.

claunia commented

2026-01-29 16:33:16 +00:00

@cfsmp3 commented on GitHub (Jun 17, 2014):

Reading the atoms should be easy, since the MP4 library we use is quite
good... Just check the MP4 main loop and you'll see.

I've I remember correct what we do here is just read the H264 NALs (looking
for the one with data) and dispatch the data to the AVC code.

We could easily check if there's one of these specials CC atoms and just
read it with an alternate loop.

On Tue, Jun 17, 2014 at 5:02 AM, wforums notifications@github.com wrote:

I'll be looking into this specific file later, but for now some references:

https://developer.apple.com/library/mac/documentation/quicktime/qtff/qtffchap3/qtff3.html

The file seems to be having a lot of those CC "atoms", which further
contain the actual CC data. Task here will be to figure out how those
"atoms" are structured and then try to get the actual CC data joined
together so that it can be read out correctly.

—
Reply to this email directly or view it on GitHub
https://github.com/CCExtractor/ccextractor/issues/50#issuecomment-46297879
.

@cfsmp3 commented on GitHub (Jun 17, 2014): Reading the atoms should be easy, since the MP4 library we use is quite good... Just check the MP4 main loop and you'll see. I've I remember correct what we do here is just read the H264 NALs (looking for the one with data) and dispatch the data to the AVC code. We could easily check if there's one of these specials CC atoms and just read it with an alternate loop. On Tue, Jun 17, 2014 at 5:02 AM, wforums notifications@github.com wrote: > I'll be looking into this specific file later, but for now some references: > > https://developer.apple.com/library/mac/documentation/quicktime/qtff/qtffchap3/qtff3.html > > The file seems to be having a lot of those CC "atoms", which further > contain the actual CC data. Task here will be to figure out how those > "atoms" are structured and then try to get the actual CC data joined > together so that it can be read out correctly. > > — > Reply to this email directly or view it on GitHub > https://github.com/CCExtractor/ccextractor/issues/50#issuecomment-46297879 > .

claunia referenced this issue

2026-01-29 16:57:14 +00:00

[PR #29] removed errors and warning after converting it to c #918

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/ccextractor#29