Fast forwarding/skipping seems to seize up playback.

[matsonjr 6]

Emby 4.8.10.0 running in docker and has an nvidia gpu for transcodes.  

Current setting for transcodes was set to no throttling.

Initial problem discovered last night while trying to watch Christmas Vacation (Roku).  Hit play and we were watching.  About 10min in and my wife comments she wants subtitles on (apparently the new annoying fad with everyone these days).  Turn them on and it locks up.  Try to resume the film...no good.  Restart and it goes....skip ahead to the 10min mark, no good.  We just rewatch the first ten minutes, then I accidently rolled/sat on the remote and turned the TV off.  Turn back on and try to resume....seizes up.  Through this, I notice we can skip ahead to about the 7min mark fine.  Basically, we start again from the beginning. 

 

Fast forward to this morning.  I am trying to figure out what is going.  I check to make sure I have space in my temp directory.  Yes, I do.  So that isn't it.  Try again with Elf.  Same problems.  In this process, I do notice that if I wait a few minutes for the whole video to get transcoded, I can skip around.  So then I try turning throttling on.  Then I'm back to square one and having it lock up with anything more than a few minute skip.  So I shut throttling back off.  Test resumes watching Buddy and then my computer (client) locks up (unrelated issue) and has to reboot.  I go back to Elf and hit resume...video is seized again.  Sometimes even, audio and video get really out of sync.  

I'm not sure what is going on.  

ffmpeg-transcode-1a253c7c-2c10-490a-8bc3-d90d75506ee7_1.txt ffmpeg-transcode-4b0bfc20-47ef-4754-8ff8-7a3d0c1a7df4_1.txt ffmpeg-transcode-4ff236ae-1607-4ef0-92cb-ed080ae4f607_1.txt ffmpeg-transcode-10d760d5-109c-49db-bf8a-a2c63fbc8bda_1.txt ffmpeg-transcode-3557f090-3014-43ac-b13b-43a4d894573f_1.txt ffmpeg-transcode-b4121dab-109f-4ab0-b4f0-9603873fe6b5_1.txt ffmpeg-transcode-d99c0480-108b-4cd6-883b-9971c68e29b8_1.txt embyserver (1).txt

[Luke 42077]

Hi, is this only an issue with videos that has vc1?

[matsonjr 6]

12 hours ago, Luke said:

Hi, is this only an issue with videos that has vc1?

I had not added that up, but in a quick test, yes, it seems it is a vc1 issue.

[Luke 42077]

OK we'll take a look at it. Thanks.

[matsonjr 6]

20 hours ago, Luke said:

OK we'll take a look at it. Thanks.

Thanks.  

[matsonjr 6]

Any update?

Also, is there anyway to easily search and see which are vc1?

[speechles 2055]

It isn't because it is VC1. That just causes the video to transcode. But your subtitles are PGSSUB which will also need to be burned in. So it has to transcode the VC1 into H264 and at the same time embed those PGSSUB subtitles into the video stream.

 

Spoiler

10:13:14.146 [matroska,webm @ 0x2db08300] Could not find codec parameters for stream 8 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
10:13:14.146 [matroska,webm @ 0x2db08300] Could not find codec parameters for stream 9 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
10:13:14.146 [matroska,webm @ 0x2db08300] Could not find codec parameters for stream 10 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
10:13:14.146 [matroska,webm @ 0x2db08300] Could not find codec parameters for stream 11 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
10:13:14.146 [matroska,webm @ 0x2db08300] Could not find codec parameters for stream 12 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
10:13:14.146 [matroska,webm @ 0x2db08300] Could not find codec parameters for stream 13 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options

It also looks like ffmpeg is having issues reading all the streams inside the container. The subtitles you want to burn in it cannot see. You might be able to use MKVToolNix GUI to remux the file to organize the streams better and optimize it. That might be enough to solve the issue and get transcoding to work properly.

Conversely, if you were to download textual SRT subtitles for that title and then used those it would not need to burn in the subtitles. This would eliminate the need to parse the subtitle streams which is where ffmpeg is having problems.

[Luke 42077]

On 1/8/2025 at 12:17 PM, matsonjr said:

Any update?

Also, is there anyway to easily search and see which are vc1?

Hi, we are still looking at this. In the meantime, have you checked out emby server's media conversion feature?

Convert Media

That could help you get a jump start on converting those to h264, which would be much simpler for all of your devices to deal with.