[Made an upstream bug report https://github.com/HandBrake/HandBrake/issues/4029, was sent to Gentoo because « non standard build » https://github.com/HandBrake/HandBrake/issues/4029#issuecomment-996581907] When requesting subtitles (whatever type), the resulting file displays « unsynchronized » subtitles, completely out of phase with the actors' speaking. The subtitles are displayed almost without pause. If you jump somewhere in the movie, the subtitles are initially properly synched but, as previously written, are displayed without regard to the actors' (not) speaking. So they get desynch'd pretty fast. This problem arises with handbrake 1.4.2, but not 1.3.3, on several machines. Reproducible: Always Steps to Reproduce: 1.request subtitling 2.play resulting file Actual Results: Subtitles should « follow the action » Expected Results: Subtitles are displayed continuously, sometimes overlapping each other
Small error in bug description. Current results : Subtitles are displayed continuously, sometimes overlapping each other Expected results : Subtitles should follow the action/actors' (not) speaking.
Hi, Sargastic! Thanks for reporting this error, I am also having the same error!
(In reply to sargastic from comment #0) > [Made an upstream bug report > https://github.com/HandBrake/HandBrake/issues/4029, was sent to Gentoo > because « non standard build » > https://github.com/HandBrake/HandBrake/issues/4029#issuecomment-996581907] I just commented on the upstream bug asking for clarification on the most significant modifications Handbrake makes to various libraries. Thanks for filing that bug! With clear feedback upstream it *might* be possible some USE flags could get created that bring Gentoo ebuilds closer to the upstream ideal. > When requesting subtitles (whatever type), the resulting file displays « > unsynchronized » subtitles, completely out of phase with the actors' > speaking. The subtitles are displayed almost without pause. If you jump > somewhere in the movie, the subtitles are initially properly synched but, as > previously written, are displayed without regard to the actors' (not) > speaking. So they get desynch'd pretty fast. I use Handbrake regularly enough and I semi-depend upon the subtitles / caption system working as expected (I'm hearing impaired). I have NOT noticed this issue in my last few transcodes with Handbrake, but now that I think about the last few things I ripped might have lacked subtitles. For completeness sake, can you tell me arch you're on, what USE flags are enabled for your build, etc? Also, can you tell me what file format (or even specific DVD if you don't mind) you were transcoding from and what the transcoder settings where? If you're using a pre-set, just tell me that along with any modifications you made. I'm not the package maintainer but I'll see what I can do to reproduce this on my end and see if I can figure out why this is happening and how consistent it is.
Hello Jeff, (In reply to Jeff Gazso from comment #3) > I just commented on the upstream bug asking for clarification on the most > significant modifications Handbrake makes to various libraries. Thanks for > filing that bug! With clear feedback upstream it *might* be possible some > USE flags could get created that bring Gentoo ebuilds closer to the upstream > ideal. That is what I've been thinking too. > For completeness sake, can you tell me arch you're on, what USE flags are > enabled for your build, etc? Also, can you tell me what file format (or even > specific DVD if you don't mind) you were transcoding from and what the > transcoder settings where? If you're using a pre-set, just tell me that > along with any modifications you made. Arch is amd64, pretty regular. CHOST="x86_64-pc-linux-gnu" eix handbrake : [I] media-video/handbrake Installed versions: 1.3.3-r3(18:26:06 18/12/21)(fdk gtk -gstreamer -libav-aac -numa -nvenc -x265) For ffmpeg (if I'm not mistaken, handbrake relies heavily on it) : [I] media-video/ffmpeg Installed versions: 4.4.1-r1(0/56.58.58)^td(17:31:53 17/12/21)(X alsa bzip2 dav1d encode fdk gnutls gpl iconv mp3 network opengl openssl postproc pulseaudio sdl svg threads truetype vorbis x264 xvid zlib -amr -amrenc -appkit -bluray -bs2b -cdio -chromaprint -chromium -codec2 -cpudetection -cuda -debug -doc -flite -fontconfig -frei0r -fribidi -gcrypt -gme -gmp -gsm -hardcoded-tables -iec61883 -ieee1394 -jack -jpeg2k -kvazaar -ladspa -libaom -libaribb24 -libass -libcaca -libdrm -libilbc -librtmp -libsoxr -libtesseract -libv4l -libxml2 -lv2 -lzma -mipsdspr1 -mipsdspr2 -mipsfpu -mmal -modplug -openal -opencl -openh264 -opus -oss -pic -rav1e -rubberband -samba -snappy -sndio -speex -srt -ssh -static-libs -test -theora -twolame -v4l -vaapi -vdpau -vidstab -vpx -vulkan -webp -x265 -zeromq -zimg -zvbi ABI_MIPS="-n32 -n64 -o32" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" CPU_FLAGS_ARM="-neon -thumb -thumb2 -v6 -v8 -vfp -vfpv3" CPU_FLAGS_PPC="-altivec -vsx -vsx2" CPU_FLAGS_X86="mmx mmxext sse sse2 -3dnow -3dnowext -aes -avx -avx2 -fma3 -fma4 -sse3 -sse4_1 -sse4_2 -ssse3 -xop" FFTOOLS="aviocat cws2fws ffescape ffeval ffhash fourcc2pixfmt graph2dot ismindex pktdumper qt-faststart sidxindex trasher" VIDEO_CARDS="-nvidia") Problem arises on *all* DVDs, as long as I need subtitles. Transcoding to mp4/m4v (seems to be the default). No fancy handbrake configurations except subtitles choice. > I'm not the package maintainer but I'll see what I can do to reproduce this > on my end and see if I can figure out why this is happening and how > consistent it is. If you need any other data, feel free to ask. And if there are patches to test, no problem either.
And... the reason I didn't get subtitles from the past few vidoes I transcoded was because the option appears to be disabled altogether in Handbrake; only "burned in" subtitles are an option. I previously thought I had a small batch of source files that coincidentally lacked subtitles. Actually inspecting the source files with ffmpeg confirms the subtitles are present. I rebuilt Handbrake with the same flags as @sargastic and still no joy. As ffmpeg clearly sees the subtitle streams, ffmpeg can be ruled out as the culprit. (My build of ffmpeg simply takes the build's default flags plus 'fdk'; otherwise there is nothing special about it.) I'll try building older versions of Handbrake to see if I can make any headway on this issue. I still haven't gotten any comments from my request for Handbrake specific patch information in the upstream GitHub issue #4029. BTW, is there a way to link the upstream issue to the metadata of this bug?
It looks like the issue has been identified upstream per the following comments by Frej Drejhammar: > From my point of view we should either report the missing PTS as a bug to > Ffmpeg or do a proper job of preserving the PTS (it will have to go into the > context and we need one PTS per subtitle stream). Either of those solutions > would allow Handbrake to drop the > A25-dvdsubdec-fix-processing-of-partial-packets.patch. See https://github.com/HandBrake/HandBrake/issues/4029#issuecomment-1005979346 for complete context.
As far as the few tests I did recently (but nothing complete), the bug seems to have been solved.
