Handbrake is not detecting/offering closed captions

[keriah]

I have a video, recorded from TV, that has closed captions, that I'm trying to encode as mp4. I do not find this in the current version of Handbrake, as I have in previous versions. (Note I'm speaking of closed captioning, not subtitles.) This is the latest HB (1.2.2) and I'm running Mojave.

Here's a screenshot:

[sr55]

Please provide an activity log as requested.

[keriah]

Here you go:

[11:01:33] macgui: Handbrake Version: 1.2.2 (2019022300)
[11:01:33] hb_init: starting libhb thread
[11:01:33] hb_init: starting libhb thread
[11:01:50] macgui: trying to open a package at: /Users/macmini/Documents/EyeTV Archive/Vera_9-3_Cold_River.eyetv
[11:01:50] macgui: trying to open eyetv package
[11:01:50] macgui: found mpeg in eyetv package
[11:01:50] macgui: ScanCore scanning titles with a duration of 10 seconds or more
[11:01:50] CPU: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz
[11:01:50] - Intel microarchitecture Ivy Bridge
[11:01:50] - logical processor count: 4
[11:01:50] hb_scan: path=/Users/macmini/Documents/EyeTV Archive/Vera_9-3_Cold_River.eyetv/000000002352ca92.mpg, title_index=0
udfread ERROR: ECMA 167 Volume Recognition failed
disc.c:323: failed opening UDF image /Users/macmini/Documents/EyeTV Archive/Vera_9-3_Cold_River.eyetv/000000002352ca92.mpg
disc.c:424: error opening file BDMV/index.bdmv
disc.c:424: error opening file BDMV/BACKUP/index.bdmv
[11:01:51] bd: not a bd - trying as a stream/file instead
libdvdnav: Using dvdnav version 6.0.0
libdvdread: Encrypted DVD support unavailable.
libdvdread:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.IFO failed
libdvdread:DVDOpenFileUDF:UDFFindFile /VIDEO_TS/VIDEO_TS.BUP failed
libdvdread: Can't open file VIDEO_TS.IFO.
libdvdnav: vm: failed to read VIDEO_TS.IFO
[11:01:51] dvd: not a dvd - trying as a stream/file instead
[11:01:51] file is MPEG Transport Stream with 188 byte packets offset 0 bytes
[11:01:52] Found the following PIDS
[11:01:52] Video PIDS :
[11:01:52] 0x12c type MPEG2 (0x2) (PCR)
[11:01:52] Audio PIDS :
[11:01:52] 0x12d type MPEG1 (0x3)
[11:01:52] Subtitle PIDS :
[11:01:52] Other PIDS :
[11:01:52] stream id 0x12d (type 0x3 substream 0x0) audio 0x12d
[11:01:56] scan: decoding previews for title 1
[11:01:56] file is MPEG Transport Stream with 188 byte packets offset 0 bytes
[11:01:56] scan: audio 0x12d: mp2, rate=48000Hz, bitrate=128000 English (MPEG) (2.0 ch)
[11:01:58] stream: 19 good frames, 0 errors (0%)
[11:01:58] scan: 10 previews, 720x480, 29.970 fps, autocrop = 60/60/12/4, aspect 4:3, PAR 8:9
[11:01:58] libhb: scan thread found 1 valid title(s)
[11:01:58] macgui: ScanCore scan done
[swscaler @ 0x10f27f000] Warning: data is not aligned! This can lead to a speed loss

[keriah]

As we see, the video does have captioning. This is the encoding via the Turbo app:

[keriah]

and playing in Quicktime, with captions displaying:

[sr55]

I'm afraid this isn't supported with HandBrake. You'd need to remux the separate video and subtitle files into a single container such as an MKV file before processing with HandBrake.

[keriah]

Since there's only one source file (from the EyeTV recorder app) I wouldn't know how to go about that. And as part of the daily workflow to get recordings from EyeTV to AppleTV it doesn't sound like an activity that makes sense to spend time on.

That's a pity because Handbrake was looking like the best candidate to replace the legacy Turbo app when it no longer runs (under Catalina).

[bradleysepos]

Technically the .eyetv file is a folder with multiple files inside. I'm not very familiar with the format but I'm guessing the subs are in a separate file. Could you provide a short sample, maybe just a few seconds?

[sr55]

It is indeed an archive.

IIRC the Macgui peers into it to find the mepg program stream only. Everything else is ignored.
Also not supported on Windows/Linux which is probably a non-issue

[bradleysepos]

Right, was just interested in how the subs are stored so perhaps we could provide a more specific alternative. If they're SRT or ASS/SSA they could be imported by HandBrake separately. The process would be somewhat manual but it could work; otherwise something like MKVToolNix would be an option.

[keriah]

I have saved a 10 second clip from the middle of the recording, confirming that it has audio with captioning in that part. The file is 6.6mb. (If you'd like it sent some other way, or some other duration, just let me know. It does look like it has been 'zipped' here -- the source extension is .eyetv)

Vera_9-3_Cold_River_-_Clip.eyetv.zip

[keriah]

If I 'show package contents' (on this short clip), this is what I find:

[bradleysepos]

Same. Well that's odd. None of the additional files contain subs. I'm guessing they're indeed embedded in the mpeg file, but we can't read them.

@jstebbins Any chance you can check this mpeg for subs?

[sr55]

Just checked the mpg file. No subtitles present.

[bradleysepos]

Same, this is what FFmpeg shows:

[mp3float @ 0x7feab9800600] Header missing
    Last message repeated 37 times
[mpegts @ 0x7feada800000] decoding for stream 2 failed
[mpegts @ 0x7feada800000] Could not find codec parameters for stream 2 (Audio: mp3 (mp3float), 0 channels, fltp): unspecified frame size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Input #0, mpegts, from '/Users/bradley/Downloads/Vera_9-3_Cold_River_-_Clip.eyetv/000000002353ab7e.mpg':
  Duration: 03:45:03.87, start: 887.286400, bitrate: 3 kb/s
  Program 1 
    Stream #0:0[0x12c]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, top first), 720x480 [SAR 8:9 DAR 4:3], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Stream #0:1[0x12d](eng): Audio: mp2 ([3][0][0][0] / 0x0003), 48000 Hz, stereo, fltp, 224 kb/s
  No Program
    Stream #0:2[0x12e]: Audio: mp3, 0 channels, fltp

It would seem there's something else at play. Are there any other relevant files next to the eyetv archive? Perhaps the eyetv software is doing something clever behind the scenes.

[bradleysepos]

Perhaps it's the third stream, which ffmpeg is detecting as mp3.

[sr55]

Nothing I have locally sees that 2nd audio stream so I guess it could be.

Seems like eyetv is doing something a bit odd here.

[bradleysepos]

I've asked whether this is a known issue on #ffmpeg-devel IRC, hopefully someone has an idea.

[bradleysepos]

It appears EyeTV might be stripping the CC from the video stream and adding it as a separate track. Unfortunately, FFmpeg currently does not have any method for reading this and their developers do not seem interested in changing the code to handle this odd case.

On the other hand, if this is exactly as the stream was delivered over the air, then it could be more common and would warrant a change. Is there any way you can provide us with a capture directly from the tuner not using EyeTV, @keriah?

[keriah]

You’ve caught us in transition to winter quarters so it will be a few days before we’re unpacked and have the technology up and running. I’d be happy to continue to work this issue, with the caveat that I’m not at all as technical as those of you helping out with this question.

For example, I wouldn’t know how to capture the video stream other than by the EyeTV gear, which is a combination of hardware and software. The hardware is a small box that connects to our cable feed (note, not “over the air” per se). I can capture either from a coax line or AV pair. The EyeTV app gives me access to some modest settings for captioning but, frankly, not all shows from the cable subscription offer cc these days. PBS seems to be one of the few that does.

What would I use to capture the cable box feed on my Mac, ignoring the EyeTV setup?

[bradleysepos]

You could use the EyeTV hardware with different software if it supported it, but I'm afraid it seems that might not be possible according to https://forum.videohelp.com/threads/383656-Using-a-DVB-tuner-from-a-macOS-application#post2487113

I'm not sure there's much else we can do here, sadly.