Streaming timeout (no playback possible) when transcoding large videos with subtitles (ffmpeg bug)

[luziferius 0]

Hi there,

 

This report is meant as a »please note« notice to the emby developers.

 

TL/DR: Internal text subtitles in large videos cause transmission time-outs when transcoding.

 

In long:

Setting: I try to play back a movie on my Sony smart tv using DLNA. I select a film that has a large filesize and embedded text subtitles that need to be burnt in during a transcode step.

Symptom: My tv starts a »processing« animation and after some time i get a »failed to connect« message. Playback never starts.

 

All logs look OK. The transcoding log shows a successful transcode start that is either successfully finished or aborted later. (Success or not doesn’t matter)

 

What happens without indication:

ffmpeg processes text subtitles in a two step way: First extract the subtitle stream from the video, then burn in/transcode.

The culprit is the first step, which happens fully transparent and without any notice in the ffmpeg log. To extract a subtitle stream, the whole file has to be read once.

When a transcode starts, the following things happen:

1. emby starts ffmpeg to transcode a video
2. ffmpeg reads the whole file once to extract the subtitle track that it will burn in
3. ffmpeg reads the file again, this time transcoding.

Let’s do an example calculation based on this observation:

Assume Alice has ripped a movie on a Bluray she owns to her hard disk. The video file is about 20GB in size. She muxes text subtitles into the video file. (She OCRs a PGM forced subtitle stream found on the disc or downloads a free one.)

The movie is stored on a new SATA SSD disk that can read at a rate of about 500 MB/s. When a transcode is requested for that file, the subtitle extraction is done by ffmpeg in 20000MB/(500MB/s) = 40 seconds.

So it takes ffmpeg 40 seconds to extract the subtitle track, which means that the actual transcoding start and video delivery is delayed by that time. This time frame should be enough to time-out many DLNA clients.

Things get worse when the read bandwidth is lower. On a USB2 connection (40MB/s), every file greater than 2.4GB[*] will have an initial delay of over one minute.

[*]: when it has text subtitles and transcoding with subtitle burn in is required.

 

How to reproduce: Take a large video (preferably >10 GB), some text subtitles and mux both into an MKV container. Flush your disc cache, so that ffmpeg has to actually read it from disk. Let it transcode by ffmpeg. Watch the process hanging right before the actual transcode starts for several seconds. Observe high disc activity during this »hang«.

 

As long as this is not fixed by ffmpeg, the only possible work around is to not use ffmpeg for transcoding under this circumstances…

A proper fix from ffmpeg side would be parsing the text subtitles in parallel to the transcode and not delay the start.

 

At the current state transcoding using emby server will work for many users and most files, but large files with text subtitles will cause issues every now and then.

I assume most users will blame the specific emby app or platform used instead of ffmpeg…

 

Proposed »fix«: Put a note about this external issue into the wiki.

 

Some reference links to ffmpeg bug reports regarding this issue:

https://trac.ffmpeg.org/ticket/4499 (»Parse internal subtitles in realtime«, marked as duplicate of bug…)

https://trac.ffmpeg.org/ticket/2067 (»Support subtitles in libavfilter so seek is honored for subtitles filters (like hardsubbing)«)

Edited April 5, 2017 by luziferius