Playback fails on some H.265-encoded files

[artas360 1]

Hi all,

I have been getting the error "Playback Error No compatible streams are currently available." when trying to play some (few) videos. So far, it looks like it only happens with some H.265 videos files containing several streams (though I do not know enough about video encoding to say for sure).

The server version is 4.8.6.0 and it is running inside a FreeBSD/TrueNAS jail.

I have tracked down the issue to a failing call to ffmpeg (causing a broken pipe). I have tried to invoke the failing ffmpeg call manually within the jail, for instance

/usr/local/lib/emby-server/bin/ffmpeg -loglevel +timing -y -print_graphs_file "/var/db/emby-server/logs/ffmpeg-transcode-5592eefb-7ab6-49e2-965d-69649d402c31_1graph.txt" -copyts -start_at_zero -f matroska,webm -c:v:0 hevc -noautorotate -i "vid1.mkv" -filter_complex "[0:0]scale@f1=width=1920:height=1080,format@f2=pix_fmts=yuv420p[f2_out0]" -map [f2_out0] -map 0:1 -sn -c:v:0 libx264 -g:v:0 72 -maxrate:v:0 3616002 -bufsize:v:0 7232004 -sc_threshold:v:0 0 -keyint_min:v:0 72 -r:v:0 24 -pix_fmt:v:0 yuv420p -preset:v:0 veryfast -profile:v:0 high -x264opts:v:0 "subme=0:me_range=4:rc_lookahead=10:partitions=none" -crf:v:0 23 -c:a:0 aac -ab:a:0 192000 -ac:a:0 2 -metadata:s:a:0 language=eng -filter:a:0 "volume=2" -disposition:a:0 default -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1 -map_chapters -1 -segment_format mpegts -segment_list "/var/db/emby-server/transcoding-temp/0B6479/0B6479.m3u8" -segment_list_type m3u8 -segment_time 00:00:03.000 -segment_start_number 0 -individual_header_trailer 0 -write_header_trailer 0 -segment_write_temp 1 "/var/db/emby-server/transcoding-temp/0B6479/0B6479_%d.ts" -map 0:2 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1 -segment_format webvtt -segment_list "/var/db/emby-server/transcoding-temp/0B6479/0B6479_s2.m3u8" -segment_list_type m3u8 -segment_time 00:00:03.000 -segment_start_number 0 -break_non_keyframes 1 -individual_header_trailer 1 -write_header_trailer 0 -write_empty_segments 1 -segment_write_temp 1 -min_frame_time 00:00:00.000 "/var/db/emby-server/transcoding-temp/0B6479/0B6479_s2_%d.vtt" -map 0:3 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1 -segment_format webvtt -segment_list "/var/db/emby-server/transcoding-temp/0B6479/0B6479_s3.m3u8" -segment_list_type m3u8 -segment_time 00:00:03.000 -segment_start_number 0 -break_non_keyframes 1 -individual_header_trailer 1 -write_header_trailer 0 -write_empty_segments 1 -segment_write_temp 1 -min_frame_time 00:00:00.000 "/var/db/emby-server/transcoding-temp/0B6479/0B6479_s3_%d.vtt" -map 0:4 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1 -segment_format webvtt -segment_list "/var/db/emby-server/transcoding-temp/0B6479/0B6479_s4.m3u8" -segment_list_type m3u8 -segment_time 00:00:03.000 -segment_start_number 0 -break_non_keyframes 1 -individual_header_trailer 1 -write_header_trailer 0 -write_empty_segments 1 -segment_write_temp 1 -min_frame_time 00:00:00.000 "/var/db/emby-server/transcoding-temp/0B6479/0B6479_s4_%d.vtt" -map 0:5 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1 -segment_format webvtt -segment_list "/var/db/emby-server/transcoding-temp/0B6479/0B6479_s5.m3u8" -segment_list_type m3u8 -segment_time 00:00:03.000 -segment_start_number 0 -break_non_keyframes 1 -individual_header_trailer 1 -write_header_trailer 0 -write_empty_segments 1 -segment_write_temp 1 -min_frame_time 00:00:00.000 "/var/db/emby-server/transcoding-temp/0B6479/0B6479_s5_%d.vtt" -map 0:6 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1 -segment_format webvtt -segment_list "/var/db/emby-server/transcoding-temp/0B6479/0B6479_s6.m3u8" -segment_list_type m3u8 -segment_time 00:00:03.000 -segment_start_number 0 -break_non_keyframes 1 -individual_header_trailer 1 -write_header_trailer 0 -write_empty_segments 1 -segment_write_temp 1 -min_frame_time 00:00:00.000 "/var/db/emby-server/transcoding-temp/0B6479/0B6479_s6_%d.vtt" -map 0:7 -map 0:0 -an -c:v:0 copy -c:s:0 webvtt -max_delay 5000000 -avoid_negative_ts disabled -f segment -map_metadata -1 -segment_format webvtt -segment_list "/var/db/emby-server/transcoding-temp/0B6479/0B6479_s7.m3u8" -segment_list_type m3u8 -segment_time 00:00:03.000 -segment_start_number 0 -break_non_keyframes 1 -individual_header_trailer 1 -write_header_trailer 0 -write_empty_segments 1 -segment_write_temp 1 -min_frame_time 00:00:00.000 "/var/db/emby-server/transcoding-temp/0B6479/0B6479_s7_%d.vtt"

which fails immediately with `/usr/local/lib/emby-server/bin/ffmpeg: No match` . This can be fixed by manually removing the argument `-map [f2_out0]` from the call, which does not look to me like a valid stream specification.
Did anybody encounter this behavior ? The playback works fine with a H.265 test file that contains a single stream (and no -map in the call to ffmpeg).

I am attaching the server log (cleared before the failing stream) and one of the transcode logs.

Thanks!

Bonus question : a bunch of the filenames of tmp files generated by emby contain a "%d" which look like a failed string expansion, is that normal?

embyserver.txt ffmpeg-transcode-39969ea6-c4bd-4f09-8e4e-62e976f9167d_1.txt

[artas360 1]

Tried to upgrade to 4.8.8.0, no luck...

[Luke 42077]

On 9/2/2024 at 7:38 AM, artas360 said:

Tried to upgrade to 4.8.8.0, no luck...

Hi, what do you mean by no luck? What exactly happened?

[artas360 1]

Hi,

Sorry, I meant that the same issue persists on 4.8.8.0 and the playback still fails.

[artas360 1]

@LukeHi, do you have any suggestions on what I could check to understand where these weird ffmpeg params are coming from?

[Luke 42077]

Hi, they are valid params. Can you try playing in Chrome? How does that compare?

[artas360 1]

Hi,

thanks @Luke. I just gave a try to chrome, same error "Playback Error No compatible streams are currently available."

But I think the issue is with the ffmpeg call: if I copy the ffmpeg call from the logs into the jail's terminal it fails immediately with the error `/usr/local/lib/emby-server/bin/ffmpeg: No match`. However, if I remove the `-map [f2_out0]` param from the call, ffmpeg starts doing its thing. I tried to look at the manpage for something looking like `[f2_out0]` I did not find anything. If you say this is a valid param, could it be an ffmpeg version issue?

 

 

[Samkook 18]

f2_out0 would be the name of the video stream filtered just before the map and if you remove the map, it probably uses the default so sounds like the filter is failing for some reason.

Don't know how those work so don't really have any insight as to why that would be.

Having an idea of what the video file structure is would probably help them to tell what could be the issue. With the output of mediainfo, ffprobe or something similar.

[artas360 1]

@Samkook thanks for the suggestion, I had the same idea, but as far as I can tell this in not the case. For reference I attached the full output of `ffprobe` as a separate file to avoid making this thread unreadble.

My guess is that, for some reason, the emby code that parses the `ffprobe` output fails and generates malformed params for `ffmpeg`.

For instance below are the first few lines of the `ffprobe`. First, the only video stream is not called `f2_out` (again as far as I understand ffprobe...); second, the `yuv420p10le` part looks like it is translated as `pix_fmts=yuv420p[f2_out0]` in the `ffmpeg` command (in the first message of this thread). So, assuming that this is indeed an invalid parameter, my guess is that something went wrong between `ffprobe` and the `ffmpeg` command generation, but with no access to the code, that's just a wild guess...

ffprobe version 5.1-emby_2023_06_25 Copyright (c) 2007-2022 the FFmpeg developers and softworkz for Emby LLC
  built with gcc 10.3.0 (crosstool-NG 1.25.0)
Input #0, matroska,webm, from 'vid1.mkv':
  Metadata:
    encoder         : libebml v1.4.5 + libmatroska v1.7.1
  Duration: 00:58:03.61, start: 0.000000, bitrate: 22048 kb/s
  Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt2020nc/bt2020/smpte2084), 3840x1920 [SAR 1:1 DAR 2:1], Level 153, 23.98 fps, 23.98 tbr, 1k tbn (default)
    Metadata:
      BPS             : 21403799
      DURATION        : 00:58:03.605000000
      NUMBER_OF_FRAMES: 83523
      NUMBER_OF_BYTES : 9320297915
    Side data:
      DOVI configuration record: version: 1.0, profile: 8, level: 6, rpu flag: 1, el flag: 0, bl flag: 1, compatibility id: 1

 

ffprobe.txt

Edited September 18, 2024 by artas360

[visproduction 315]

ffmpeg-transcode log above.

Line 16 shows about 25 subtitles embedded in this .mkv.  I believe that this may be causing your issue.  Doesn't the transcode need to look at all subtitles and handle them?  When there are so many the transcoding can time out or fail for some reason?  It seems like I have seen this a lot.

If you remove the excess subtitles and save to a new media file, your playback and transcoding may start working.  To remove these subtitles with mkvmerge, or command line ffmpeg.  This will take perhaps 20 seconds, on average, for 2 hours of media.

Hope that helps

[artas360 1]

@visproduction Thanks a lot for the suggestion. It looks like this did the trick. I guess it's time to invest in a beefier server then...

[visproduction 315]

5 hours ago, artas360 said:

@visproduction Thanks a lot for the suggestion. It looks like this did the trick. I guess it's time to invest in a beefier server then...

LImiting your subtitles to the ones you really need, may be the best approach.  I use  mkvtoolNix, remux the media and copy audio and video.  It lets you remove the subtitles.  This app is is very fast.  ffmpeg can work, but you have to get the command just right.  It takes less than a minute to do a 2 hour media file and remove any excess subs. 

I also will use the mkvCleaver which is a quick way of pulling out any subtitles you want.  You can then just assign then as separate subfiles.  If you name the sub files correctly, they will show up on the media page with a pull down option.  Having separate subtitle files is nice, because the transcoder is not taxed with doing anything for subs. 

Just get the naming correct:

Run Lola Run (1998) - 720P.mkv
Run Lola Run (1998) - 720P.en.default.srt

Run Lola Run (1998) - 720P.fr.srt

You can get hardware to be faster and maybe leaving 25 subtitles alone, might work.  I would NOT count on that.  Pull out all the subs, you need and create separate files.  It is just selecting check boxes, click 'Go' and then rename the subtitles.

Hope that helps.

Edited September 18, 2024 by visproduction

[hjason7812 34]

you really need to re code your videos especially when it comes to h265 videos. i use the wonderfox set of tools to do it and the videos and sound comes out amazing use wonderfox dvd video converter and dvd ripper pro and also hd video converter factory pro. i use dvd converter first and then run it through the hd video converter factory pro before uploading it to the server for emby. and the video is clear as day and sound is amazing as well. don't ask why i run it through twice but i do because to me i can see a difference in quality if i only run it through once. it is a personal preference to say the least.