Burning subtitles hangs on Android

[tanersener]

When the following command is used to burn subtitles on Android, the execution does not return and hangs forever.

-y -i .../video.mp4 -vf subtitles=.../subtitle.srt:force_style='FontName=MyFontName' -c:v mpeg4 .../video-with-subtitles.mp4

This behaviour can be seen on the test application as well. Sometimes, after the test-application is upgraded on a device this issue happens. Restarting the app doesn't fix the issue. The only way to fix this is to uninstall the test app and install it again.

Both LTS and Main releases are affected from this. mobile-ffmpeg also has the same issue. It was seen on most mobile-ffmpeg releases since v3.1.

Test application use setFontDirectory method before burning subtitles. It can be related to the issue.

These are the latest log lines printed.

D/ffmpeg-kit-test: [Parsed_subtitles_0 @ 0xb908d380] Setting 'filename' to value '/data/data/com.arthenica.ffmpegkit.test/cache/subtitle.srt'
D/ffmpeg-kit-test: [Parsed_subtitles_0 @ 0xb908d380] Setting 'force_style' to value 'FontName=MyFontName'
D/ffmpeg-kit-test: [Parsed_subtitles_0 @ 0xb908d380] Raster: FreeType 2.10.2
D/ffmpeg-kit-test: [Parsed_subtitles_0 @ 0xb908d380] 
D/ffmpeg-kit-test: [Parsed_subtitles_0 @ 0xb908d380] Shaper: FriBidi 1.0.10 (SIMPLE) HarfBuzz-ng 2.7.4 (COMPLEX)
D/ffmpeg-kit-test: [Parsed_subtitles_0 @ 0xb908d380] 
D/ffmpeg-kit-test: [Parsed_subtitles_0 @ 0xb908d380] Initialized
D/ffmpeg-kit-test: [Parsed_subtitles_0 @ 0xb908d380] 
D/ffmpeg-kit-test: [NULL @ 0xb928a380] Opening '/data/data/com.arthenica.ffmpegkit.test/cache/subtitle.srt' for reading
D/ffmpeg-kit-test: [file @ 0xb91f8a70] Setting default whitelist 'file,crypto,data'
D/ffmpeg-kit-test: [srt @ 0xb928a380] Format srt probed with size=2048 and score=100
D/ffmpeg-kit-test: [srt @ 0xb928a380] Before avformat_find_stream_info() pos: 441 bytes read:441 seeks:0 nb_streams:1
D/ffmpeg-kit-test: [srt @ 0xb928a380] All info found
D/ffmpeg-kit-test: [srt @ 0xb928a380] After avformat_find_stream_info() pos: 441 bytes read:441 seeks:0 frames:0

The following logs belong to a similar run where burning does not fail.

D/ffmpeg-kit-test: [Parsed_subtitles_0 @ 0xb9097b30] Shaper: FriBidi 1.0.10 (SIMPLE) HarfBuzz-ng 2.7.4 (COMPLEX)
D/ffmpeg-kit-test: [Parsed_subtitles_0 @ 0xb9097b30] 
D/ffmpeg-kit-test: [Parsed_subtitles_0 @ 0xb9097b30] Initialized
D/ffmpeg-kit-test: [Parsed_subtitles_0 @ 0xb9097b30] 
D/ffmpeg-kit-test: [NULL @ 0xb92802a0] Opening '/data/data/com.arthenica.ffmpegkit.test/cache/subtitle.srt' for reading
D/ffmpeg-kit-test: [file @ 0xb8f7f5d0] Setting default whitelist 'file,crypto,data'
D/ffmpeg-kit-test: [srt @ 0xb92802a0] Format srt probed with size=2048 and score=100
D/ffmpeg-kit-test: [srt @ 0xb92802a0] Before avformat_find_stream_info() pos: 441 bytes read:441 seeks:0 nb_streams:1
D/ffmpeg-kit-test: [srt @ 0xb92802a0] All info found
D/ffmpeg-kit-test: [srt @ 0xb92802a0] After avformat_find_stream_info() pos: 441 bytes read:441 seeks:0 frames:0
D/ffmpeg-kit-test: [Parsed_subtitles_0 @ 0xb9021f80] Using font provider fontconfig
D/ffmpeg-kit-test: [Parsed_subtitles_0 @ 0xb9021f80] 
D/ffmpeg-kit-test: [Parsed_subtitles_0 @ 0xb9021f80] Event: [Script Info]

Further tests show that <application-home>/cache/.ffmpeg-kit folder which is registered as font directory using the setFontDirectory method have a fonts.conf file inside as it should be when this issue occurs in the test application.

And these are the logs printed on application start-up. Nothing is wrong here as well.

I/ffmpeg-kit: Loaded ffmpeg-kit-full-gpl-x86-4.4-lts-20210123.
D/ffmpeg-kit: Deleted old temporary font configuration: true.
D/ffmpeg-kit: Saved new temporary font configuration with 1 font name mappings.
D/ffmpeg-kit: Font directory /data/data/com.arthenica.ffmpegkit.test/cache registered successfully.
D/ffmpeg-kit-test: Application fonts registered.

[tanersener]

This issue happens when font directory registered using setFontDirectory includes named pipes created using registerNewFFmpegPipe.

When subtitle burning command is being executed, fontconfig reads all files under the registered font directory as part of the font loading process. However, in this case, font directory also contains named pipes not closed by closeFFmpegPipe. So, fontconfig tries to read named pipes as well. And, since named pipes require someone to write something into the pipe, fontconfig can not read named pipes successfully and wait forever.

There are two wrongs in this case but none of them are ffmpeg-kit bugs.

• An ffmpeg pipe created using registerNewFFmpegPipe is not closed
• Cache directory is used as font directory

Unfortunately, fontconfig scans sub-directories as well. So, creating ffmpeg pipes under a sub-directory of cache does not solve this problem.

The only solution is not to register application cache directory as font directory on Android.

This issue does not happen on Apple platforms, because they use different directories to create pipes and load fonts. Pipes are created under the application cache folder and fonts are loaded from the resource folder. But the same principle must be followed on them too. Application cache directory shouldn't be registered as font directory on iOS/tvOS/macOS. If not it will happen on Apple devices too.