@cayars said:
Have you processed any files yet?
What do you think of the results?
I have just started processing a few AVI’s, M4Vs and MKVs, but haven’t watched anything yet. Inspection of processed files with MediaInfo appears to show everything is as expected, that is: english language set for audio, additional stereo english AAC track added, soft subtitles removed from container, external srt file created for english language subs and H264 High profile L4.0 codec for video. I suppose processed files will work nicely on all my plex client devices (AppleTV4 with Plex client app, Infuse4 Pro app, MrMc app, Simple X app, as well on the Raspberry Pi 2 with Rasplex 1.0.3)…
On a side note, I thought that, in order to AVOID transcoding from the Plex Server when playing on compatible devices (e.g. AppleTV4), one should have the subs EMBEDDED onto the container file, not removed… Can you please elaborate?
Additionally, how can I modify the script so it creates external subs for ALL soft subtitles it finds inside containers?
Best regards,
Cesar
This is something I am wondering about also, the only subtitles I want are forced subtitles for scenes where foreign language is being spoken in movies, and I want them to be embedded, as I dont want any transcoding to take place.
Yes, I see your point. But my case is just the opposite, since I’m Brazilian, most, if not all, movies/tv shows are actually spoken in a foreign language (English)…
It’s my understanding that if one selects external SRT files before playing a tv show or movie from a Plex client, the Plex Server defaults to transcoding or remuxing the outgoing media, no matter if the client is capable of playing those directly or not. On the other hand, if subtitles are soft embedded into the container, then the client direct plays. Is that your understanding also?
@richarddc79 you had asked about changing the audio bitrate to 128K.
Personally I wouldn’t do this as 256K should work with every client but should you want to do this try editing mkvtomp4.py around line 27
audio_bitrate=256,
I assume that is directed @richarddc79 - I was just mentioning the setting in the .ini file is easier than poking in the scripts
I tend to use 160K for TV audio, not for comparability reasons - just found it a sweet spot for TV for file size reasons without too much noticeable drop in quality.
I watch a lot of tv shows with headphones / ipads etc
I reserve the real 5.1 sound tracks for movies when I might actually sit down and turn on the real kit!
yep, that would be the better way. To many options I hardly ever use to remember!
Just curious but why do you want to limit yourself to 128K for audio? Have you hit a problem with any particular client?
I have found that on idevice and android if I set the audio to 128k I can get direct play on full bd mp4 rips no problem, I tend to get stuttering on anything above this, I tried changing the .ini file but this had no effect.
Ok, I have now watched a few converted episodes and everything played fine on the AppleTV4 using the Plex app. But, as I expected, whenever I select an externa SRT subtitle on the client, the server goes into transcoding mode. If I choose Off for subtitles, then it direct plays.
Yes, if the SRTs are embedded in the container file (soft subs), then it direct plays and you can choose between different subtitles WHILE the episode is playing. If the subs are external SRT files, then you need to select the desired sub BEFORE you hit play, as there’s no way of changing them while the episode is already playing. I guess embedded subs are present in all media sold at the iTunes store, so the AppleTV knows how to deal with them better.
I suppose the scripts can be modified to embed SRTs instead of removing them. I don’t know the first thing about Python programming, but I have a feeling it may be doable, maybe by changing a few of the parameters sent to ffmepg. I will investigate ffmpeg options and come back if I find anything about it.
autoProcess.ini and readSettings.py both contain the following lines:
download-subs = False
embed-subs = False
I wonder if changing each or both options to True would result in subs being downloaded (in case there is not already available SRT local file) and embedded into the mp4 container…
Ok, I have tried changing embed-subs to True and got the expected result. The conversion process embeds all SRT files already present in the Process folder into the container and the resulting mp4 does direct play (without server transcoding) on the AppleTV4 Plex App. I haven’t tried playing the same file from the Raspberry PI 2 running Rasplex 1.0.3. Yet…
But I’m quite satisfied with the results so far. So, in order to summarise the changes I made see below:
Changes to autoProcess.ini:
audio-language =
subtitle language =
embed-subs = True
Changes to readSettings.py:
audio-language = ‘’
subtitle language =’’
embed-subs = ‘True’
I haven’t tried changing download-subtitles to True, because I already had SRT files for English and Portuguese-Brazilian available. All I had to do is put them right next to the mkv file I was willing to convert.
Thanks once again for everyone who provided this set of scripts for the Windows environment, as they are very capable and I really didn’t have much trouble adapting them to my needs (run in OS X and embedding subs).
Cesar/Brazil
UPDATE: I have now tried processed files using Rasplex 1.0.3 and they also direct play while showing embedded subs. At last, no need for server transcodes when using subtitles!
Hi cayars, thanks for this script. One question though, you mention the moov being placed at the front of the file, but looking at your autoProcess.ini file, it has this option set…
relocate_moov = False
…shouldn’t this be True? Or am I misunderstanding this option?
@shpankey said:
Hi cayars, thanks for this script. One question though, you mention the moov being placed at the front of the file, but looking at your autoProcess.ini file, it has this option set…
relocate_moov = False
…shouldn’t this be True? Or am I misunderstanding this option?
Thanks again!
Yes you DO WANT relocate_moov = False I create the moov atom a different way than the original script did. It's faster and has less issues with compatibility. Carlo
