Dear Maintainer,
===================================================================================================
* What led up to the situation?
Tried to convert 2 different DVDs, both NTSC, into m4v (or mp4)
including subtitles.
In both cases, using many different options for handbrake (H264,
H265, different audio encoders, etc), was easily able add subtitles
(as well as burn-in). HOWEVER: the subtitles NEVER worked correctly:
- there are places where characters speak and no subtitles appear at
all
- also places where characters speak at length and a subtitle pops
up for only a second
- parts where there is lenghty narration, but no character speaks, and no
subtitle appears ever
NOTE: in both DVDs, playing the DVD directly results in subtitles
working perfectly. The DVDs have subtitles working but the debian
package of handbrake does not work.
* What exactly did you do (or not do) that was effective (or ineffective)?
I contacted handbrake.fr and they recommended using their nightly
snapshot as they claim debian is using a version of ffmpeg that
breaks subtitles.
Entire thread is at: https://forum.handbrake.fr/viewtopic.php?p=202972#p202972
Using the nightly snapshot from handbrake.fr worked perfectly and
produced an m4v file with subtitles that match exactly the
characters.
* What outcome did you expect instead?
I expected the debian packaged handbrake to work exactly as the one
from the upstream source but it does not. Failure to generate all
subtitles and insert them at the correct spot in the video is a major
failure that makes this packaged version of handbrake unusable for
videos with subtitles.
I recommend adding a test case of ripping a DVD with subtitles AND
verifying that the subtitles really match the speech.
===================================================================================================
I've installed the snapshot version of handbrake from handbrake.fr directly (via flatpak)and verified that on the same DVDs, it generates the subtitles perfectly. I also built the debian version of handbrake from source and that one still has the same problems.One can also see the subtitles overlaying each other so that in rapid dialog multiple subtitles appearone on top of each other, making them all illegible. This does not happen in the handbrake snaphshot. thanks,--jack
This is the exact version of handbrake I used from fr.handbrake.ghb that fixed the subtitles issue (which seems caused because the character encoding of the subtitles is not always recognized): => flatpak info fr.handbrake.ghb HandBrake - Video Transcoder ID: fr.handbrake.ghb Ref: app/fr.handbrake.ghb/x86_64/stable Arch: x86_64 Branch: stable Version: 1.6.1 License: GPL-2.0+ Origin: ghb-origin Collection: Installation: user Installed: 123.3 MB Runtime: org.gnome.Platform/x86_64/43 Sdk: org.gnome.Sdk/x86_64/43 Commit: 227d2a8398a850cd93a6662116c0bc64be187eeb4f2e5a2ae1e490838cd03248 Subject: Export fr.handbrake.ghb Date: 2023-01-23 18:08:28 +0000
Ouch, yes, to confirm, upgraded to bookworm and now subtitles are broken when using HandBrake to convert DVD to .mkv (worked in bullseye handbrake-cli 1.3.1+ds1-2 and previous versions) The problem occurs with all DVD subs I tried, both types: VOBSUB and CC608 # Example command: HandBrakeCLI -i /dev/sr0 -o "7r0N.mkv" -t 1 -s 1 # Title 1, subtitle track 1 Produces lots of decavsub warnings (I'm guessing for every subtitle frame): [warning] decavsub: track 1, invalid PTS Result: video ok, but subtitles do not appear and/or not at the correct times. upstream: https://github.com/HandBrake/HandBrake/issues/4029 ...Handbrake depends on custom ffmpeg patches, hmmm...?
I stumbled on this issue as well. It looks to me like this patch: https://github.com/HandBrake/HandBrake/blob/master/contrib/ffmpeg/A07-dvdsubdec-use-pts-of-initial-packet.patch is particularly important for how handbrake handles dvd sub titles. My understanding is: dvd subtitles are large (being images) and will usually exceed a packet in the stream. ffmpeg only returns the pts with the first invocation (packet), where no complete subtitle results. The second invocation (packet), which usually completes the subtitle and results in a complete subtitle returned, does not contain the pts anymore. The above mentioned patch to ffmpeg changes ffmpeg to remember the pts. But handbrake can remember the pts just as well. So see the attached patch which does exactly that: if the subtitle is incomplete, it saves the pts to the handbrake subtitle context, and retrieves it if there is no pts on a completed subtitle ready for output. I am unsure how to proceed from here. Is that fix acceptable? Where would I submit it?
I tried this patch out and it works. Subtitles are with right timings.
Hi Michael,
thanks for looking into this!
michael spreng wrote:
Can you please send/propose this upstream, they are in a much better position
to assess this approach.
Either by making a pull request https://github.com/HandBrake/HandBrake or
by opening an issue there.
Cheers,
Moritz
Hi Moritz https://github.com/HandBrake/HandBrake/issues/4029 In short: HandBrake developers insist that handbrake is buildt with their heavily patched version of ffmpeg (they prefer ffmpeg handling the pts). The Debian package gets branded as unsupported. FFmpeg on the other hand does not accept that "convenience" patch (reasoning "That makes no sense": https://trac.ffmpeg.org/ticket/10681). And Debian seems to be caught in the middle of the hardened positions between those two projects. So sorry, someone has already tried that, and unfortunately for human reasons that has failed. Debian has may sympathy, being the anonymous bystander caught in the proverbial crossfire. Thank you for your efforts to resolve this, Michael
So what is the solution? The workaround is to install handbrake from the flatpak repo. If this is supposed to be the permanent solution, I suggest removing handbrake from the debian distribution.