Page 2 of 2

Re: Java errors and media identified as transcoded rather than streamed since 9.6.1 update

Posted: Tue Jun 16, 2020 2:48 pm
by Nadahar
I'm puzzled by the distinction Americans make between "subtitles" and "closed captions". To me, this is a distinction without a difference. Yeah, I know that they say "Music plays", "Engine revs" etc, but honestly - 99% of the time they are the same thing.

I always use subtitles if I have them, regardless of the audio language. I often listen to Norwegian audio with Norwegian subtitles or English audio with English subtitles. I simply prefer having subtitles because it means that I don't have to have to volume so loud that I can hear everything over music or other sounds, or mumbling or other sources of "obfuscation". So, I'd almost always prefer having the "closed captions" shown if they are there ;)

Re: Java errors and media identified as transcoded rather than streamed since 9.6.1 update

Posted: Tue Jun 16, 2020 11:39 pm
by ajkessel
For future reference, the following settings in UMS.conf caused the tracks in questions to switch back to streamed:

Code: Select all

subtitles_languages = eng
forced_subtitle_language = eng
Also, this command line will removed the embedded closed caption track from an mpeg2video stream (e.g., vob):

Code: Select all

ffmpeg -i input.vob -c:a copy -c:v copy -bsf:v "filter_units=remove_types=178" output.vob
I couldn't find the "178" value documented anywhere else. For h264 content (e.g, in an mkv container), it appears this is the right command line:

Code: Select all

ffmpeg -i input.mkv -c:a copy -c:v copy -bsf:v "filter_units=remove_types=6" output.mkv
Hopefully this will be helpful to others. I do think people typically distinguish between closed captions (for the hearing-impaired) versus subtitles (when you don't speak the audio language), and aren't expecting the former to be rendered by default, especially when they are not a separate stream in the media container.

Re: Java errors and media identified as transcoded rather than streamed since 9.6.1 update

Posted: Wed Jun 17, 2020 12:58 am
by Nadahar
ajkessel wrote: Tue Jun 16, 2020 11:39 pm I do think people typically distinguish between closed captions (for the hearing-impaired) versus subtitles (when you don't speak the audio language), and aren't expecting the former to be rendered by default, especially when they are not a separate stream in the media container.
The fact that many, especially in the US in my impression, distinguish is an obvious fact. I was merely pointing out that I don't really see the difference, you might want subtitles in the same language as the audio and you might not want it. It should really be up to the "consumer" of the video, and I don't see why the fact that one describes other sounds than speech and the other doesn't warrants the use of two different terms that if often referred to as "two completely different things".

I'm not hearing impaired (except if you ask my wife, but she claims it's a "selective hearing-impairment) and I usually prefer subtitles whether I understand the audio language or not.

Re: Java errors and media identified as transcoded rather than streamed since 9.6.1 update

Posted: Fri Jul 17, 2020 8:59 am
by SubJunk
I think that fix will have worked because it removed the "und" language from the list of languages you want subtitles for. Thanks for confirming, glad it's working now :)

Re: Java errors and media identified as transcoded rather than streamed since 9.6.1 update

Posted: Fri Jul 17, 2020 9:06 am
by ajkessel
SubJunk wrote: Fri Jul 17, 2020 8:59 am I think that fix will have worked because it removed the "und" language from the list of languages you want subtitles for. Thanks for confirming, glad it's working now :)
Yes. I would suggest you consider whether by default "und" language should *not* be rendered -- i.e. it seems to me something people are more likely to want to enable manually rather than have turned on by default.

Re: [Solved] Java errors and media identified as transcoded rather than streamed since 9.6.1 update

Posted: Fri Jul 17, 2020 9:44 am
by SubJunk
Yeah it has been agonized over before. I could really go either way on it. Either way, the "und" situation is a catch-all mess because the file author didn't correctly tag the file. It's definitely a frustrating situation because in the past we had a different default and then people didn't like that either, so we are criticized either way :)