Video playback problems

[Riggs 300]

It appears the subtitle extraction is very slow on your system. We are looking into alternative techniques to improve this for a future update. For now the best workaround is external subtitles. Thanks.

 

Ok, great.

 

Allow me ask someting: Why my system is slow? Do i have a misconfig, or hardware problems? Do i need to change any hardware?

 

I saw everything working fine with standalone players (MPC and VLC) 

 

***Comment that maybe can give you a clue:

 

After test many variables, that issue happens when the audio needs to be transcoded.

-On my PC /web-server: when the audio needs to be transcoded.

-My main system in my room:  if i turn off my receiver  (which is passing through the audio and video) from my Android TV APP (Nvidia Shield) to my TV. Audio needs to be transcoded because my TV support DTS 7.1 but not Dolby ThrueHD or DTS:X. But IF my receiver is ON direct play for thrueHD or DTS:X is supported, no transcoding is needed. Direct Play has no issues/delays or whatever, it works perfect.

-On Roku, because the TV on that living room support stereo only + Roku (anyway) have some audio limitations in his hardware, almost everything needs to be transcoded. IF the movie is stereo, direct play works fine and no subtitle problems found.

 

Seems that everything needs to be with the transcoding and the ffmpeg

 

Thanks

Edited July 19, 2018 by HRSCR

[ebr 14910]

Ok, great.

 

Allow me ask someting: Why my system is slow? Do i have a misconfig, or hardware problems? Do i need to change any hardware?

 

Extracting the subtitles from the video is just extremely intensive and then combine that with having to also transcode the video and, without some serious hardware, you will likely have issues.

 

Again, the best solution is external text-based subs.

 

Thanks.

[Riggs 300]

Extracting the subtitles from the video is just extremely intensive and then combine that with having to also transcode the video and, without some serious hardware, you will likely have issues.

 

Again, the best solution is external text-based subs.

 

Thanks.

 

Hold on, @@ebr

 

What is for you a serious hardware? What kind of hardware Emby needs to run smooth transcoding of anything?

 

Can you please advice me about that. I'm concern about what you said of my hardware and that is not enough.

 

And again...

 

Do you think that i going to return to use the subtitles at side of the MKV container in an almost 2000 movie collection just because Emby can handle that issue and "the other" software can do it without issues?

 

I pretty sure that many people here use machines with less resources of my main server PC.

 

Your answer leave me without support to any .TS future file that i can possible think play from this platform.

 

What I do with the PGS subtitles, maybe send an apreciation card to the studios and fight with the blu-ray standards?

 

To avoid talk of "other" let me be clear. Koki, Infuse and Plex for example, can handle subtitles into MKV containers. Emby can't?

Edited July 20, 2018 by HRSCR

[Waldonnis 148]

There are differences between rendering for playback (think Kodi) and burning in subtitles during transcode (think Emby), so comparing those two is an apples-to-sledgehammers comparison.  I think I know how Plex is doing it, though, even though I have never seen any Plex logs to confirm it (below).

 

Thinking about it, one question popped into my mind: why burn text-based subs in at all...ever?  Emby could probably tell ffmpeg to convert them to webvtt as part of the transcode process, allowing the player to handle the display.  Hell, you could actually transcode all of the subrip tracks at once and make them all available in the HLS playlist so they can easily be changed without rebuffering or restarting the transcode (it's really lightweight).  This would allow the player's caption options to work (for customisation of colour/position) and generally simplify the whole process.  I suppose if there was a supported player/device that didn't support webvtt captions this wouldn't work, but I can't think of a player offhand that supports HLS but doesn't support webvtt  (since it's *the* caption format for HLS).

 

The only other way to potentially speed up subtitle extraction and parsing would be to create a new task to extract and precache muxed-in subrip tracks (or just do it as part of the library scan)....but that's a messy solution, IMO, as it would only really be used in transcode situations that burn in text-based subs.

[Luke 37046]

 

 

Thinking about it, one question popped into my mind: why burn text-based subs in at all...ever?

Just to answer this question. The only reason you see burn in with these examples is that some of the earlier examples were PGS, and some of the SRT examples he had extraction disabled in server transcoding settings. When you disable that they'll be forced to burn in.

[Waldonnis 148]

Just to answer this question. The only reason you see burn in with these examples is that some of the earlier examples were PGS, and some of the SRT examples he had extraction disabled in server transcoding settings. When you disable that they'll be forced to burn in.

 

I'm actually unclear of what "extraction" actually does from a technical perspective, so that may be why I'm not understanding why that operation is something that would ever be "slow".  The webvtt encoder is pretty fast and light, in my experience, and often much faster/lighter than even audio encoding.   Edit: Nevermind, I see now that you're demuxing the SRT stream to a file and providing that to the client...the delay makes sense in that context.  What I was referring to is an alternative idea of just transcoding the SRT (or all of them) using -c:s webvtt and including that output in the mpegts segments along with the video and audio output.  Something like this (very simple example):

ffmpeg -i input -map 0 -c:v libx264 -c:a aac -c:s webvtt output.ts

This would make all text-based subtitles available to the clients as webvtt in the transport stream segments (should be supported) without having to do a potentially lengthy pre-demuxing/caching step.  Worth testing, at least, to check compatibility across platforms...and would likely require some changes to the clients since some (Roku) have special syntax for webvtt delivery.

 

The PGS sub stuff I definitely understand...that has to be dealt with via overlay.

Edited July 20, 2018 by Waldonnis

[Luke 37046]

That would be a good option if it works but i'm not sure roku will play embedded subtitles with HLS.

[Waldonnis 148]

That would be a good option if it works but i'm not sure roku will play embedded subtitles with HLS.

 

Sure does...here's a link to the docs about it.  (I happened to be looking at the SDK docs about something else when I replied, lol).

[snodrog742 31]

Sure does...here's a link to the docs about it.  (I happened to be looking at the SDK docs about something else when I replied, lol).

 

I can confirm it does as well as I've experienced this on Roku for HLS Live.

[Waldonnis 148]

Of course, you could also just demux on the fly by copying the SRT to a file as a second output operation on the same transcoding command line, but I'm not sure how clients would deal with SRTs that were being constantly updated during playback.

Edited July 20, 2018 by Waldonnis

[Luke 37046]

Well OK then, i guess we can embed the subtitles. We'll look into that !

[Waldonnis 148]

Well OK then, i guess we can embed the subtitles. We'll look into that !

 

No prob, glad I could help!     I never thought about how muxed-in text subs were handled nor looked at how my own server was doing it...I would've suggested this sooner if I had known.  There may still be value in demuxing the SRTs instead of doing this, since I'm not sure if any formatting/positioning present in SRT files would be preserved during the conversion to webvtt, but at least it can be more of an optional feature with an explanation of why you would enable it and a warning about the inherent delay in demuxing/caching (and default to off if all supported platforms support muxed-in webvtt).  I don't often see SRTs with formatting because a lot of clients ignore it, so I doubt you'd see many people that would prefer demuxing the SRT just to preserve that stuff.

[Luke 37046]

Just fyi, Ebr and I tested this on both Roku and for kicks, with mpv since it generally handles everything.

 

We could not get the subtitles to show up in either player. Here's a sample command line:

ffmpeg.exe -ss 00:00:39.000 -noaccurate_seek -f matroska,webm -i file:"video.mkv" -threads 0 -map 0:0 -map 0:1 -map 0:2 -codec:v:0 copy -bsf:v h264_mp4toannexb -copyts -vsync -1 -codec:a:0 ac3 -ac 6 -ab 384000  -codec:s:0 webvtt -disposition:s:0 default -f segment -max_delay 5000000 -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 -start_at_zero -segment_time 3 -segment_time_delta -39 -individual_header_trailer 0 -break_non_keyframes 1 -segment_format mpegts -segment_list_type m3u8 -segment_start_number 13 -segment_list "09b4617cdbda0b22b50296ea1b141f6d.m3u8" -y "09b4617cdbda0b22b50296ea1b141f6d%d.ts"

The transcode was successful, no errors, just never saw the subtitles.

[Riggs 300]

Try uncheck and check "on the fly" on server and do some tests..

 

I recommend test

 

with a file with one pgs and one srt. muxed in.

 

only one file with only one srt muxed in.

 

Well the test are above in previous post, but you can confirm them

 

 

Edit: And yes, depends if it is "on the fly" on or off... "just never saw the subtitles."

 

On the fly on or off with pgs subtitles is more or less the same

Edited July 21, 2018 by HRSCR

[speechles 1917]

Roku docs suggest they only work with video on demand. So maybe -hls_playlist_type vod is missing?

 

WebVTT

Roku supports WebVTT captions if embedded in HLS streams or manifests. As with the other closed caption formats, a channel specifies WebVTT captions in the SubtitleTracks metadata. The TrackName property is set to "webvtt/track" where track specifies the index of the caption track to render.

 

Also may need to somehow set this trackname property and such it wants. If testing on the roku, the app has to make this change.

Edited July 21, 2018 by speechles

[ebr 14910]

The trackname I saw in the player metadata was "mkv/[index]".  Where is this value getting set?  I thought it was coming in via the actual stream.

[speechles 1917]

The trackname I saw in the player metadata was "mkv/[index]".  Where is this value getting set?  I thought it was coming in via the actual stream.

 

https://github.com/speechles/BN-ONE/blob/patch-1/source/GeneralMetadata.brs#L1804-L1808

 

Thats if ffmpeg passes these through the manifest as their own external files. If so you just tell it here instead of the url, the "WebVTT/[track]" bit instead of the url to the subtitles. Thats what I was refer to.

[ebr 14910]

https://github.com/speechles/BN-ONE/blob/patch-1/source/GeneralMetadata.brs#L1804-L1808

 

Thats if ffmpeg passes these through the manifest as their own external files. If so you just tell it here instead of the url, the "WebVTT/[track]" bit instead of the url to the subtitles. Thats what I was refer to.

 

Right but that's for external subs.  When they are embedded in the stream we don't do that...

[Waldonnis 148]

Just fyi, Ebr and I tested this on both Roku and for kicks, with mpv since it generally handles everything.

 

We could not get the subtitles to show up in either player. Here's a sample command line:

ffmpeg.exe -ss 00:00:39.000 -noaccurate_seek -f matroska,webm -i file:"video.mkv" -threads 0 -map 0:0 -map 0:1 -map 0:2 -codec:v:0 copy -bsf:v h264_mp4toannexb -copyts -vsync -1 -codec:a:0 ac3 -ac 6 -ab 384000  -codec:s:0 webvtt -disposition:s:0 default -f segment -max_delay 5000000 -avoid_negative_ts disabled -map_metadata -1 -map_chapters -1 -start_at_zero -segment_time 3 -segment_time_delta -39 -individual_header_trailer 0 -break_non_keyframes 1 -segment_format mpegts -segment_list_type m3u8 -segment_start_number 13 -segment_list "09b4617cdbda0b22b50296ea1b141f6d.m3u8" -y "09b4617cdbda0b22b50296ea1b141f6d%d.ts"

The transcode was successful, no errors, just never saw the subtitles.

 

Yeah, this is my fault and I hadn't thought it through (it won't work for several reasons I forgot about).  Captions are usually delivered as their own playlists with HLS and there was talk about allowing embedding them at some point, but I guess the work was never done to make it happen (if it ain't broke, I guess).  The data's in the mpegts container, but it doesn't have a recognisable codec id for demuxers/players to detect....so it just shows as "some type of data" and gets ignored.

 

Back to the drawing board...

 

Edit: I wonder if you could demux the SRT at the same time as a second output (using flush_packets).  If players only read the file once, that probably wouldn't work, though, since you'd be appending to it at the same rate as the transcode.

Edited July 22, 2018 by Waldonnis

[Luke 37046]

Yea we've implemented the playlist method for apple tv already. What we need to do is not have to depend on having the subtitles fully created prior to video start, so that is the next step.