Universalmediaserver: FFmpeg timeout on burning subtitles
On a lot of my files, FFmpeg times out or takes 2+ minutes before outputting anything (in its initial parsing of internal subtitles
My TV doesn't wait for 2+ minutes so it fails playback.
There are a few different bugs at play here but my goal is to successfully transcode the files with FFmpeg, or to be able to detect problematic ones and defer to MEncoder, and I'm working on that.
In the output, FFmpeg gets stuck at:
Using font provider directwrite
SubJunk
All 42 comments
Related link on the FFmpeg mailing list, specifically mentions UMS https://lists.ffmpeg.org/pipermail/ffmpeg-user/2017-May/036026.html
SubJunk
on 15 Dec 2018
Is this why the following files don't play (you only need on episode). Both shows give an error with FFmpeg on my PS3, but will play by manually selecting MEncoder.
MadokaAyukawa
on 20 Dec 2018
Yes.
https://trac.ffmpeg.org/ticket/4499
FFmpeg doesn't handle natively the subtitles from the libavfilter library, so that is why this delay and why it fail following the UPnP/DLNA standard.
A cheap trick could be done but with a limited effect, and that will not remove the lowering of video quality that you can see when FFmpeg transcode video with subtitles other than ASS/SSA du to the FFmpeg filter trick used for the subtitles sync.
https://trac.ffmpeg.org/ticket/2235
Its why such media are automatically transfered to MEncoder, for Windows users at least.
Of course, when selecting the video engine from the #-TRANSCODE-# folder it doesn't do such automatic engine triggering.
Sami32
on 20 Dec 2018
Currently, even if "Defer to MEncoder" checked, UMS does not use MEncoder for second set of files (I no longer have the first set handy to test). In fact, I haven't seen UMS defer to MEncoder in quite some time now.
MadokaAyukawa
on 21 Dec 2018
Only media with embedded text subs except ASS or Vobsub subtitles are deferred to MEncoder if the deferring FFmpeg option has not been disabled.
That is said, I don't use any UMS version after 6.7.4 so i cannot say if something have been broken since then.
Sami32
on 21 Dec 2018
Currently, even if "Defer to MEncoder" checked, UMS does not use MEncoder for second set of files (I no longer have the first set handy to test). In fact, I haven't seen UMS defer to MEncoder in quite some time now.
@MadokaAyukawa MEncoder should kick in with that file, I just tested and it does for me. Can you post logs?
SubJunk
on 22 Dec 2018
Ok, I tried again, but it used FFmpeg again.
MadokaAyukawa
on 22 Dec 2018
@MadokaAyukawa You can attach pretty much anything here as long as you change/add extension. Only a few extensions are allowed, so we usually just add .txt to "unsupported" file types.
Nadahar
on 22 Dec 2018
@Nadahar what do you want to say? As you can see the .zip files are supported and I am able to open it without any problem.
valib
on 23 Dec 2018
rar.txt
7z.txt
...
Sami32
on 23 Dec 2018
@Sami32 nice but .zip is supported or not?
valib
on 23 Dec 2018
In case someone didn't knew :
https://help.github.com/articles/file-attachments-on-issues-and-pull-requests/
Outside of these formats, do as @Nadahar already explained.
Sami32
on 23 Dec 2018
@Sami32 I don't understand what do you want to say if you don't want excuse @Nadahar that he is wrong with the .zip format.
valib
on 23 Dec 2018
Lol
It seem that you didn't get any of us then ;)
Sami32
on 23 Dec 2018
You probably have missed the Madoka post, now deleted, where he was saying that he was not able to attach ahis log here i guess?
Sami32
on 23 Dec 2018
@Sami32 I undesrstand it well. If @Nadahar says
@MadokaAyukawa You can attach pretty much anything here as long as you change/add extension. Only a few extensions are allowed, so we usually just add .txt to "unsupported" file types.
seems that he is not able to open the .zip attachment but this is not the GItHub problem because you explained it in
In case someone didn't knew :
https://help.github.com/articles/file-attachments-on-issues-and-pull-requests/ 😄
valib
on 23 Dec 2018
Nice.
That is probably why Madoka said that he was posting his log on the forum then ;)
Sami32
on 23 Dec 2018
He probably had used a 7Z file i guess.
Sami32
on 23 Dec 2018
@valib
Ok, so made a thread on the forum as I don't think I can attach anything here. It used FFmpeg for me.
https://www.universalmediaserver.com/forum/viewtopic.php?f=9&t=13194
This was posted by @MadokaAyukawa originally and then later deleted. I assumed that he deleted it because he found out that he could attach zip files. If you look inside the attached zip file, there's only a .log file - so my assumption was that he originally tried to attach debug.log itself here.
My comment was meant to inform him that he could just name it for example debug.log.txt instead.
Nadahar
on 23 Dec 2018
.log or 7z same same for Github ;)
Sami32
on 23 Dec 2018
@MadokaAyukawa If you mean the second file "[Tezu] Monte Cristo Haku Complete Batch [720p]", yes it is normal, as it have ASS subtitle that are the ones not trigerred automatically to MEncoder.
Sami32
on 23 Dec 2018
Yes, I was trying to play Monte Cristo Haku. Thanks for the explanation.
I did manage to find an episode of Switched, and it does defer to MEncoder if that option is selected since the file has .srt subs. However, I also have other movies with internal .srt subs that FFmpeg can play just fine. I notice that if the "Defer" option is selected, UMS will defer theses as well when it doens't really have to,
MadokaAyukawa
on 23 Dec 2018
@MadokaAyukawa I am really interested to make the "defer to mencoder" option more accurate. When I made it it was an urgent bug fix since a lot of users were getting failed playback on their subs, so I wanted to make sure they were all fixed, but if you can help me figure out how to detect which files FFmpeg can play with internal SRT (I have seen them too but I didn't get around to looking yet) that will make that feature better :)
Also I noticed that Sherpya is doing builds of MEncoder again (before we used my builds of MEncoder we used his ones) so we might want to look at using his newest one for Windows. I can always release new builds too but if he already is, it would save me time
SubJunk
on 23 Dec 2018
IIRC, the following file has internal .srt subs, and FFmpeg can play it just fine.
MadokaAyukawa
on 23 Dec 2018
@MadokaAyukawa Yes, that is normal that FFmpeg engine is used and work in that case because such 10-bit H.264 need to be transcoded for your renderer.
Sami32
on 23 Dec 2018
I think user knows encoding will be engaged. He don't understand why sometimes MEncoder is used and sometimes FFmpeg when UMS should DEFER to MEncoder for all files with internal subtitles.
Must say I haven't read all comments here so maybe I am wrong:)
ExSport
on 23 Dec 2018
Monte Cristo Haku and Switched will not play with FFmpeg (assuming it's because of the bug mentioned in the title of the thread). If "Defer" is checked, MCH will not defer to MEncoder since it has .ass subs, while Switched will since it has .srt subs. I would not want UMS to defer to MEncoder in all cases with subs as FFmpeg will play the majority of my files. For example, anime shows with .ass subs play with FFmpeg, perhaps since the shows are short, they don't time out.
Bleach is an example of a movie with .srt subs that FFmpeg can play, but is deferred to MEncoder if "Defer" is checked. In this case, I would not want it to use MEncoder. I no longer have any short anime shows with .srt subs as no groups will use them anymore, so I can't test if anime with .srt would also be deferred. Just deferring to MEncoder if it has .srt subs (Switched and Bleach) is not optimal.
So out of the three examples, "Defer" is working correctly only on one case.
MadokaAyukawa
on 23 Dec 2018
@MadokaAyukawa Yes, FFmpeg can display text subtitle other than ASS/SSA with shorter videos as long as the waiting delay stay in the DLNA specifications..
The ASS/SSA exception is du to the libass project library been added some years ago to FFmpeg to handle such specific case. That is why it get a proper, faster handling.
I agree that FFmpeg should be prefered when possible.
About the engine triggering fine tuning you will have to deal with @SubJunk, as by now Defer seem to work as it was coded for.
Sami32
on 23 Dec 2018
@MadokaAyukawa thanks for the sample file that works, I will test it and see if I can find a way for us to detect the ones that work. Hopefully it isn't just a matter of smaller files working because they take less time to extract.
Also it occurred to me that another way to workaround this is to have a task that extracts the internal subtitles ahead of time. Now that we have the initial scanning process, we can do things like that - the scan can save the files to a cue that is worked through, and then FFmpeg can play the external one instead of the internal one. Just an idea.
SubJunk
on 23 Dec 2018
This is another series that won't play with FFmpeg, but will with MEncoder. Using external .srt subs. Unfortunately, it's on a private tracker.
https://avistaz.to/torrent/93558-story-of-yanxi-palace-2018-complete-1080p-web-dl-aac-h265-cyw
Here's the MediaInfo on it, in case it's obvious from the file info.
Complete name : Story.of.Yanxi.Palace.2018.Complete.1080p.WEB-DL.AAC.H.265-CYW\Story.of.Yanxi.Palace.EP01.2018.1080p.WEB-DL.x265.AAC-CYW.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom)
File size : 455 MiB
Duration : 45 min 26 s
Overall bit rate mode : Variable
Overall bit rate : 1 401 kb/s
Encoded date : UTC 2018-07-19 11:55:42
Tagged date : UTC 2018-07-19 11:55:42
Writing application : MP4 Tags Editor @ nilaoda
Cover : Yes
Comment : 菜牙电影网@浅笑
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main@L5@Main
Codec ID : hev1
Codec ID/Info : High Efficiency Video Coding
Duration : 45 min 26 s
Source duration : 45 min 26 s
Bit rate : 1 274 kb/s
Maximum bit rate : 4 348 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Bits/(Pixel*Frame) : 0.025
Stream size : 414 MiB (91%)
Source stream size : 434 MiB (95%)
Tagged date : UTC 2018-07-19 11:55:48
Codec configuration box : hvcC
Audio
ID : 2
Format : AAC LC SBR
Format/Info : Advanced Audio Codec Low Complexity with Spectral Band Replication
Commercial name : HE-AAC
Format settings : Implicit
Codec ID : mp4a-40-2
Duration : 45 min 26 s
Bit rate mode : Variable
Bit rate : 62.8 kb/s
Maximum bit rate : 71.4 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 44.1 kHz
Frame rate : 21.533 FPS (2048 SPF)
Compression mode : Lossy
Stream size : 20.4 MiB (4%)
Default : Yes
Alternate group : 1
Tagged date : UTC 2018-07-19 11:55:48
@MadokaAyukawa which version of the MediaInfo do you use? And is it 32-bit or 64-bit?
valib
on 25 Dec 2018
@SubJunk the extraction of the internal subs I implemented long time ago but after the FFMpeg support of internal subs was implemented it was overridden.
valib
on 25 Dec 2018
It's from MPC-HC x64 1.8.3 so I'm assuming x64?
MadokaAyukawa
on 25 Dec 2018
@valib that's good news, maybe we can resurrect that old code and hook it up to the scan, and I can write the cuing functionality for them. I want to do a similar thing for OpenSubtitles lookups so it makes sense to do that. Can you dig up the old implementation to start us?
@MadokaAyukawa that Bleach file took a long time to start for me with FFmpeg (from 20:23:21.175 to 20:24:06.002 so 45 seconds, most renderers won't wait around for that.
There are lots of factors that can affect it like SSD or HDD caching - for this reason often it will be faster the second time if you try it straight away. So it seems to me like we are right to still defer to MEncoder for that
SubJunk
on 26 Dec 2018
@MadokaAyukawa about that file you posted the mediainfo for, can you upload it to somewhere I can download? It is much faster for me to see what is happening by reproducing it
Edit: Feel free to PM me the link on the forum if privacy is a concern
SubJunk
on 26 Dec 2018
@SubJunk Can a faster CPU also start the file faster? Speaking of MEncoder, I noticed you mentioned newer builds which I found. There's now a MEncoder 64-bit. Can I make UMS use that? Currently, UMS uses a 32-bit version. Would I need to change the name to a 32 at the end, even though it's 64-bit?
I don't have any online file posting currently. Let me see what I can do though it may not be fast.
MadokaAyukawa
on 26 Dec 2018
@SubJunk the subtitles extraction is still there. You can use SubtileUtils.getSubtitles() or SubtileUtils.convertSubsToSubtitleType()
valib
on 26 Dec 2018
I vaguely remember this subtitles extraction. IIRC, one issue I had with the old implementation was that UMS did not clean up the extracted subs (I could be wrong here). If this solution is used, can these subtitles be made to also respect the following option:
# Live subtitles timeout
# ----------------------
# Number of days that live subtitles need to be keep.
# If live_subtitles_keep is true this setting is ignored.
# Default: 0 (meaning keep indefinitely)
live_subtitles_timeout = 10
So that any extracted subs are automatically cleaned up. I realize with today's huge hard drives these files are insignificant in size, but I would rather not have hundreds of subs I don't "need" as they were extracted only for FFmpeg.
MadokaAyukawa
on 26 Dec 2018
@MadokaAyukawa if the subs are only temporary they are deleted when the UMS is closed. For extracted subtitles I set 30 days before they will be deleted.
EDIT: thanks for this comment because it seems to me that live_subtitles_timeout is implemented in the master branch but not in the 8.0.0
valib
on 27 Dec 2018
@SubJunk @valib Is it still true for v8beta? Thx
ExSport
on 3 Jan 2019
@ExSport yes. It is missing in this branch. Maybe wrong merging.
valib
on 3 Jan 2019
Thanks Libor for info.
ExSport
on 3 Jan 2019
Related issues
MediaMania1
·
40Comments
ExSport
·
38Comments
Nadahar
·
50Comments
onon765trb
·
45Comments
Nadahar
·
42Comments