[implemented] Actually keep transcoded tracks? (why transcode again on second play?)

Looking at the new feature to allow thumbnails on the roku (Generate media index files automatically), which basically uses the transcoder to generate all the required files in the correct format and keeps them....

 

Wouldnt it be possible to have a similar option that did something like "Generate AAC audio track" and just add it to the media?

 

If you play a file once, then you transcode. However, if you play that file again, you transcode again - which is a waste of CPU time and electricity. It seems to me it makes sense to only do the transcoding once and then save it to the file. This would also allow low powered servers (that cant transcode in real time) to still serve clients that need transcoding, i.e. a nas or similar could spend the night generating the audio tracks ready to play during the day.

 

This will obviously take up a little space - but its not a lot and could be a tick box just like the media index... It also still allows the transcoder to be used when its needed. Its also not designed to account for every possibly (i.e. things that dont like AAC). However, generating AAC audio will allow a lot of files to at least direct stream (mkv with h264 + acc will direct steam on rokus and apple tvs) which means little cpu usage on the server side.

While this sounds like a great idea, there are a lot of things that can go wrong.

First, the library is going to increase in size by A LOT. For just a 45min TV show, most stereo audio tracks are going to run 75mb alone. That doesn't even account for the video track being transcoded if needed.

Next, you have to have a whole set of options around how and when these sort of files would be generated and saved and where!

Then there is the inevitable, "PLEX messed up my library but keeping transcoded files"

While it's a good idea on the outside. It is a standing notion that Plex doesn't modify files. Personally I'd like to see an added Indicator in the Plex/Web that a file should be transcoded to make it more portable.

There is also the issue of PMS transcoding a file for one device, and another transcode for yet another device, etc., and then, even if it is the same device, and PMS somehow knew that, what if it was on a slower connection, so PMS made another transcode specific to the situation.

I can envision a server with a dozen versions of the same movie...

Of course, you can do this manually and save multiple versions of files so that do not need transcoding (just streaming), e.g., SD and HD versions.

So have an external track, I.e movie name.aac in the folder with the movie, just like how meta data works. Plex can then pick the best parts from what you have available and transcoded the rest. There is no need to have multiple copies of files, containers (mkv, etc) can already have multiple audio tracks within them.

I forgot the whole “plex doesn’t mess with your files” mantra. So external files sounds like a winner - as you are going to remux the files can be separate anyway.

Plex can still transcode on the fly, nothing is changing there. But adding an option to create an aac audio track externally means a lot of files will direct stream (with little overhead on the PMS) on most devices. Mkvs tend to have h264 already and aac plays on pretty much anything. Having the file externally and plex picking it up also solves editing files - its just yet more metadata

You also missed that I only asked for an aac option, not all the video etc. The thread title also says track

Sent from my Nexus 4 using Tapatalk 4

Thinking about it, my wording of saying to keep the transcoded tracks is wrong. Because if you do were to do as I propose, you shouldn’t really have much transcoding going on (at least for local clients). I guess a better thread title is something like "allow plex transcoder to pre generate aac tracks to avoid needing to transcode as often"

Sent from my Nexus 4 using Tapatalk 4

So have an external track

Actually, I think this is a great idea, if Plex after the generation could trigger an agent to update the database.

That way, it would be just like sidecar subtitles, except sadly, and don't get me wrong here Elan, if you are looking over my shoulders, that it as default would be stored within the metadata.

So to recap....

Allow Plex when transcoding for the first time, also to save that transcode as an external file, in the same directory as the origen media.

That way, we'll not affect small SSD disk's etc, and also pump up our rep. when sharing...Arrhhh.....I mean deposit a backup @ our closest friends house.

Sad thing though is, that it would req. a small change to the new transcoder code, so when req. to start a new transcode, it should instead look in the media directory for maybe a job already done.

/Tommy

Then there is the inevitable, "PLEX messed up my library but keeping transcoded files"

With this idea, the origen file would be left intact, AFAISI

/T

Considering that Plex is handling content that you OWN, and that you have format shifted yourself from DVD or Blu Ray. When you rip a disk, just save it as AAC instead of AC3 or save both AC3 and AAC tracks inside the MKV. Plex figures out multi-track audio and send you the stuff your client understands.

Problem Solved :)

Even if you don’t own the media you could do that.

If that’s the case, you could encode everything to suit all your players and we don’t need a transcoder at all.

Not helpful

Sent from my Nexus 4 using Tapatalk 4

I can see the appeal of sidecar audio (as opposed to the whole transcode stream -- which is what I understood this request to be originally). After all, the codecs are all there to be instructed to do exactly that!

However, I still see some issues ...

Right now, the transcoding is conducted in segments of packaged video/audio, as they are requested by the client, and it would not be until the end of the session that in a typical scenario it would have completed the process -- if I understand it (which I probably don't!). And, one of the beautiful things about streaming is that I can stop/pause watching in the middle of playback, and return to it -- sometimes days -- later. So it seems to me that this idea would push Plex out of its wheelhouse (i.e., streaming) and into the territory so competently filled by others (e.g., Handbrake, eac3to, etc.).

Understand, I love thinking about this stuff, so please don't interpret my comments as an attempt to stifle discussion! But to me, this falls into a category I've been labeling -- in my mind until now -- as a Swiss-Army-Knife feature request. Plex is so cool, that the natural inclination is to want it to do everything. But when you weigh out the costs with the benefits, the audio portion of the transcoding chores PMS executes is minor in comparison to the video. The resources to do it are relatively insignificant. So it would not save a whole lot of the heavy lifting; the segments would still need to be remuxed; and I'm imagining the potential for video/audio syncing issues with tracks stored outside the container...

But more importantly, I don't see the process of creating an AAC sidecar as just piggybacking onto what PMS is already doing. It would require Plex to either

  1. process an entire video ahead of the client's segment requests; or
  2. conduct the AAC conversion as a separate process akin to the indexing feature, or
  3. attempt to stitch together the transcode segments after completing playback of an entire video, and then pull out the audio track; or
  4. run a parallel process apart from the segment transcodes and save the AAC audio track separately as it went along.

But, like I said, I can see the appeal ... I would prefer the idea of Plex recognizing and utilizing sidecar audio -- in the same fashion it does with SRT subtitles -- if present. Perhaps the actual creation of these little puppies, at least for the short-term, might be better accomplished with a plug-in, rather than as a built-in feature of PMS.

And, with all of that said, I already do what was suggested earlier: for movies intended for playback on devices with restrictive capabilities, I embed an AAC Pro Logic II track, and designate it as the default audio.

Plex transcoder is basically ffmpeg (with huge modifications, but ffmepg all the same). Also it already does something similar with the generate media index files already - it goes through your library and reencodes it for the thumbnails for use on the roku and dumps it in the metadata folder.

However at least recognising it is a required first step either way - so not a bad start. However I get the impression you are talking about doing this when something is played, I'm talking about when it's indexed.

Also, conversion tools do not run everywhere - think nas drives etc. So you can't even script it like you could with PMS on a PC/Mac. Oh and plexsync is already reencoding stuff too!

Sent from my Nexus 4 using Tapatalk 4

Yes, that was #2 on my list. I did not suggest there was only one way to do it. Sorry for the confusion.

so to recap....

Allow Plex when transcoding for the first time, also to save that transcode as an external file, in the same directory as the origen media.

While this would work, it wasnt quite what I was suggesting. I was proposing that when media is indexed to do the audio reencode and dump it in the same directory.

The benefit of doing this, is slow servers (nas, etc) can do the encoding in advance, so if the CPU is slow enough to not be able to do realtime encoding - it would still get done and still play when you need it.

But I would settle for either, as it just seems wasteful to transcode the same file twice.

While this would work, it wasnt quite what I was suggesting. I was proposing that when media is indexed to do the audio reencode and dump it in the same directory.

Ups, reread, and your idea is better :)

/T

If I could collect analytics from when media is played: what formats, bitrates, remux/passthrough, playcount, local/remote, etc  then I or someone else could come up with an external tool to optimize your media library.

brilliant. have often thought the same.

brilliant. have often thought the same.

Then press the Like button on the first post please

+1

i think it said before, but every client and every internet-connection needs a different transcoded-stream. for example iPhone and Plex/Web needs to be transcoded to mp4. while Android doesn't. 

or a connection requires a maximum of 4Mbps ... and the next time, u see the movie, the connection is dimensioned for 8Mbps ... then u kept the transcoded file for nothing. 

i think it said before, but every client and every internet-connection needs a different transcoded-stream.

Yes but the same client or even same type of client (house with 2+ of: Rokus, iPhones, iPads/Tablets) will likely transcode with the same settings. Also when a viewer seeks back they watch the same thing twice. My kids have watched the same thing several times in a row.

Anyway, current Plex (on Linux) transcodes to many files with the pattern "/tmp/plex-transcode-{random-id?}/media-[number].ts" 

If:

1. That randon-id isn't random, but based on the media file and transcode settings, and

2. Plex had a tmp dir cache management where you could set a limit (say 16 gigs) and the most recent chunks were kept until  pushed out of the cache.

Then: Plex could avoid re-transcode of recently transcoded content.

My linux plex temp dir in action:

# pwd
/tmp/plex-transcode-51345db9-99f1-4e08-b216-279a04aa2efd-2107c1f5-3864-44cf-8ff8-c55fea92c3fd
# ls
media-00115.ts  media-00120.ts  media-00125.ts  media-00130.ts  media-00135.ts
media-00116.ts  media-00121.ts  media-00126.ts  media-00131.ts  media-00136.ts
media-00117.ts  media-00122.ts  media-00127.ts  media-00132.ts  media-00137.ts.tmp
media-00118.ts  media-00123.ts  media-00128.ts  media-00133.ts
media-00119.ts  media-00124.ts  media-00129.ts  media-00134.ts
 

Those .ts files are anywhere between 200K and 980K in size.