yeah i know where your coming from.
that my 2 cents anyway :unsure:
Most DTS audio tracks are 1.5 mbit
The DTS wont be transcoded if the video codec is known ... and if the global bitrate (video + audio) is below 21 mbits.
additionnaly, i bet you wouln't hear the difference between 1 Mbits /sec and 1.5 mbits :)
The DTS wont be transcoded if the video codec is known ... and if the global bitrate (video + audio) is below 21 mbits.
additionnaly, i bet you wouln't hear the difference between 1 Mbits /sec and 1.5 mbits :)
OK cool i did think that just wasn't sure.
And I have Kryptonian hearing :rolleyes:
The main problem I have with Rasplex (0.3.1) is after watching a few episodes of something, i click on the next one and it freezes.
Wen i pull the power and turn it back on again everything works fine for another few episodes (or more)
I usually pull the power at least once a day.
My guess would be something to do with it not clearing the RAM correctly ( but that is a "guess")
I have the 512mb raspberry pi.
I haven't tried any of the betas because I have such a big library and such a slow NAS it takes forever to rebuild all the images etc.
I have just been holding out for the next stable release before i update it.
I hope it blows my mind because it is so good :)
You should try the latest experimentals. Precaching will have your lib all scanned overnight 
I thought precaching was removed a while back because it caused problems with the raspberry pi ?
Has this now been reimplemented with the latest experimental releases then ?
Yes, there is now a menu entry below preferences that allows you to precache the local sections.
Next version of RasPlex will also allow to precache remote servers and will offer a faster precaching speed, but at least it does it on its own and you can run that overnight.
I understand this concern though i have no Div3 Low sample to test with. But the profile information is not something that is available to PHT client when it has to decide whether it should transcode or not.
basically the information which is available for the client is what you can see in the information window in PMS when you are inside you movie in Plex Web (stream codecs, no profile information).
I'm not sure what you mean by 'profile information' here, but the "DIV3" acronym is clearly visible in the PHT info shown by pressing the "i" key on the keyboard during playback, so the client definitely has access to what's needed for this recognition.
At least it's available 'during' playback, though I'm not sure about its availability before starting playback.
However, if PMS is unable to share such info with clients, that is a serious handicap to be corrected by the Plex team ASAP.
This limits not only RasPlex when it comes to efficient transcoding choices. It affects every client in existence...!!!
I believe that whatever the profile is on the server side media, it's not transfered to client side so that he can make the right decision.
If you have any sample that you could make available and PM me a link, i could check it out.
I suppose I could clip an AVI with virtual dub so that it only contains a copyright notice or credits claim (legal to spread), but I'll only post/PM such a clip if you still think it's necessary after checking the screenshot I attached, which shows PHT displaying the DIV3 acronym for such a video.
The current implementation checks for the global bitrate, that is audio bitrate + video bitrate. If this exceeds 21 mbits, then transcoding is triggerred as higher bitrates would probably cause stuttering.
If you're talking about forced transcoding even with "Direct Play" and compatible CODECs, then (and only then) I agree.
The hardware of the RPi is not sufficiently powerful to safely go above that limit.
But for all other settings than "Direct Play" the triggering must always occur for media with bitrates above the set limit, while media with lower bitrates should still 'Direct Play' if they have compatible codecs, but should otherwise be transcoded.
Once the server is applying transcoding, it will cap the video bitrate to 20 Mbits and audio to 1 Mbit no matter what.
Again I hope that you're speaking of the limits for forced transcoding with "Direct Play" setting, since all the other settings must make the server cap the transcoded bitrate to the limit chosen by the user.
Well this is the way it was intended to be implemented by Plex guys, even if the implementation is not completely satisfying, you cannot call this a BUG.
I'm not sure if we're talking about the same thing, so let me restate what I see as the main bug here:
With "Direct Play" setting I play a DIV3 episode, which then plays without video.
This proves that transcoding was needed, but the client doesn't know it, so it didn't request any, and since the bitrate was low (776 kbps DIV3 and 96 kbps MP3 for the episode of the screenshot above), this failed behaviour is CORRECT, though a better CODEC recognition should lead to transcoding once that recognition of DIV3 as unsupported is implemented. So this is NOT the bug.
With "20 Mbps" setting I play the same show episode, which then plays perfectly.
This proves that the video has been transcoded even though both PHT and PMS believe its CODECs are compatible with 'Direct Play' and despite the fact that the user-chosen bitrate would not be exceeded by 'Direct Play'. THIS IS THE BUG.
When the video bitrate is lower than the set limit, and all CODECs involved are compatible, the video should always 'Direct Play'.
For me the bug may have been fortunate, as it allows me to play videos without lowering the bitrate below their orignal value, but it is still a bug.
Transcoding media with CODECs considered compatible and bitrate within the set limits is contrary to Plex standards.
The fact that it appears to have been intentionally coded this way for PHT does not alter the fact that it is a bug, though it may be a bug of design rather than of implementation.
1 - all medias having a global bitrate above 21 Mbits will be transcoded. the directplay setting will have to be set to allow both directplay / transcoding depending on the client-side decision. The 'transcode always' functionality will remain as some people have a use for it (like for remote server playback).
I agree that having a 'transcode always' switch may be useful, but that should then be a separate option flag, not an inevitable consequence of having set a bitrate limit, which is how it works today.
2 - yeah server-side bitrate limitations will be set to 20 mbits video / 1 Mbit audio.
Again I must hope that you left out all the variable limitations, with this one applying only to "Direct Play" setting.
I hope this clarifies a bit the implementation. Don't get me wrong, your points make sense but i need to deal with the current transcoder possibilities which are missing some features in some areas.
Agreed. But I really don't think the current PHT implementation even attempts to use the transcoder correctly.
On the other hand i dont want to overuse transcoding as some users will have gimped PMS and might be in trouble for transcoding even on some lower resolution medias.
Agreed, which is all the more reason to NOT transcode videos just because a bitrate limit has been set, even when it has not been exceeded.
PS : PM me a Divx3 file link so that i can have a look if you can.
If you still think it necessary I can clip out a section with just credits or copyright, or even some 'black screen', neither of which should have any legal implications. But I think the screenshot I made above makes it very clear that PHT does know that DIV3 is being used for these cases. And the string section the acronym appears in should identify the part of the code that can access it.
Best regards: dlanor
After diescussing for a while with the Plex transcoder guys, they would recommend that we dont directplay mpeg4 as there are a lots of variants which might cause troubles to Rpi in directplay.
That sounds like a recommendation based on the goal of minimizing coding changes, rather than optimizing the end result.
As we dont have the necessary infromation on clientside to decide wether it would support it or not,
I disagree. Since the info screen during playback can show such variations, other parts of the client must also be able to extract them. And if there is some PMS-side inability to share this information with the clients, then that is an URGENT issue for correction in PMS. If PMS is not able to tell clients the nature of the media files, then the whole Plex transcoding concept falls flat on its face...
they suggest to trasncode mpeg4 streams to H264.
This would avoid any issue with mpeg4 streams, but might require extra load for PMS as it will have to do more transcoding.
Since the majority of the added transcoding would be unnecessary, such a solution is unacceptable.
There's a HUGE amount of modern DivX and XviD material in many collections, and these do NOT need transcoding.
What would be your thoughts about this ?
I think we should go ahead with the plan of improving the recognition of CODEC support for RasPlex.
And if it turns out that PMS really is incapable of informing clients about the media CODECs properly, then we will have to take that up with the Plex team. They will eventually realize that ALL clients need such information for their transcoding decisions, not just RasPlex.
Best regards: dlanor
@ dlanor
Nice screenshot
Your screenshot shows that the videocodec is msmpeg4 and its something different than mpeg4. Msmpeg4 is not supported by Rpi anyways.
In that specific case the movie would be transcoded anyways.
As far as grabbing the info, your statement though theorically correct just overlooks completely the way things are implemented in PHT and doesnt take into account the pipeline that we have to comply with.
When a movie is played, transcoding decision is made on the information that we have from PMS ( you can see them in movies details from plexweb). Transcoding decision is then taken and movie streams are openned from server. At this point ffmpeg is opening the stream and identifies the codec and other informations which are displayed during the playback (on your screenshot). This information is NOT available when making the transcoding decision as thr movie and streams havent been openned yet.
You can consider that this behaviour has flaws, but thats the way it works now and we have to deal with it.
As of now i have pushed the transcoding code and it will consider mpeg4 can be directplayed as h264 of it remains in the global bitrate conditions. Your msmpeg4 files being something different they will be transcoded.
Ahh ok i see now.
msmpeg4 (Microsoft mpeg4) uses the old divx3.xx. ( which the pi "CANNOT" play)
mpeg4 it seems uses the new divx or xvid. (which the pi "CAN" play.
So there is no need for transcoding mpeg4. "EVER"
Your screenshot shows that the videocodec is msmpeg4 and its something different than mpeg4. Msmpeg4 is not supported by Rpi anyways.
In that specific case the movie would be transcoded anyways.
But that never happens. I've tried it in several different versions of RasPlex, including the current 9.9.20.
Transcoding of those videos only happens if I change the setting from "Direct Play" to any bitrate, such as 20Mbps.
Possibly the string displayed as "msmpeg4" in this info text is simplified to just "MPEG4" in the info from PMS that PHT sees before playback. It is obviously a variation of MPEG4, though not the standard one, and we've already established that Plex doesn't deal with such variations in the way we would wish.
Another possibility for mistakes depends on how the string is parsed for testing. ("MSMPEG4" does contain the substring "MPEG4".)
As far as grabbing the info, your statement though theorically correct just overlooks completely the way things are implemented in PHT and doesnt take into account the pipeline that we have to comply with.
When a movie is played, transcoding decision is made on the information that we have from PMS ( you can see them in movies details from plexweb).
Info like this ?
Transcoding decision is then taken and movie streams are openned from server. At this point ffmpeg is opening the stream and identifies the codec and other informations which are displayed during the playback (on your screenshot). This information is NOT available when making the transcoding decision as thr movie and streams havent been openned yet.
You can consider that this behaviour has flaws, but thats the way it works now and we have to deal with it.
Ok, I can accept that limitation for now, though I do see some ways around it.
Immediately after a "Direct Play" playback has started it should be possible to request the same information as for the "i" command, but internally without any screen display. The retrieved strings can then be parsed to see if they indicate incompatibility with 'Direct Play' mode, in which case the playback could be aborted and restarted with a transcoding request. This would allow such videos to play correctly transcoded after an initial 'glitch' in 'Direct Play' mode.
I'm not suggesting that this be implemented now, but it's a possibility to keep in mind.
I am suggesting that we bring up the lack of detailed pre-play info for client consideration with the PMS coders.
The API should allow a client to know everything about a media file before starting playback.
As of now i have pushed the transcoding code and it will consider mpeg4 can be directplayed as h264 of it remains in the global bitrate conditions. Your msmpeg4 files being something different they will be transcoded.
That sounds good. But if they are transcoded even with 'Direct Play' setting, then this will be the first RasPlex version to do so.
But your description of how it currently works indicates that the old versions should have done it too. (unless I misunderstood you there)
And since that never has worked in the way you describe, I can't help but feel some doubts.
We need to understand why it didn't work in the old versions, in order to make it work in a new one.
Best regards: dlanor
Please don't make it transcode mpeg4 xvid files.
This would make it unusable for me as my PMS is incapable of transcoding because the cpu is too weak.
I would have to go back to something like RaspBMC or OpenELEC :(
But that never happens. I've tried it in several different versions of RasPlex, including the current 9.9.20.
Transcoding of those videos only happens if I change the setting from "Direct Play" to any bitrate, such as 20Mbps.
Possibly the string displayed as "msmpeg4" in this info text is simplified to just "MPEG4" in the info from PMS that PHT sees before playback. It is obviously a variation of MPEG4, though not the standard one, and we've already established that Plex doesn't deal with such variations in the way we would wish.
Another possibility for mistakes depends on how the string is parsed for testing. ("MSMPEG4" does contain the substring "MPEG4".)
Of course it never happens as there is currently no such support and that is what this thread is all about. in current 9.9.20, it uses default PHT behaviour which is basically either transcode everything by setting the bitrate in the preferences settings, or directplay everything.
msmpeg4 is a microsoft version of mpeg codec and it's identified properly by PMS as msmpeg4 like in the information window you showed on PMS.
Therefore as it's not supported by RPI, its not listed in the supported codec list ("h264", "mpeg4") and will get transcoded in next version even if you have DirectPlay setting.
Maybe i wasn't clear enough in the original post, but the sole purpose of this thread was to identify properly the type of codecs that would need to trigger transcoding even when in directplay mode.
I will keep also the original behaviour which was to always transcode when the directplay setting is not used in preferences.
Ok, I can accept that limitation for now, though I do see some ways around it.
Immediately after a "Direct Play" playback has started it should be possible to request the same information as for the "i" command, but internally without any screen display. The retrieved strings can then be parsed to see if they indicate incompatibility with 'Direct Play' mode, in which case the playback could be aborted and restarted with a transcoding request. This would allow such videos to play correctly transcoded after an initial 'glitch' in 'Direct Play' mode.
I'm not suggesting that this be implemented now, but it's a possibility to keep in mind.
I am suggesting that we bring up the lack of detailed pre-play info for client consideration with the PMS coders.
The API should allow a client to know everything about a media file before starting playback.
I understand the idea, though as mentionned before this information is only available once playback has started and when ffmpeg has openned the stream for the server, so that would be quite difficult to implement as this would require to start playback then determine how it should handled and then eventually restart playback ... that doesn't sound very good.
That sounds good. But if they are transcoded even with 'Direct Play' setting, then this will be the first RasPlex version to do so.
But your description of how it currently works indicates that the old versions should have done it too. (unless I misunderstood you there)
And since that never has worked in the way you describe, I can't help but feel some doubts.We need to understand why it didn't work in the old versions, in order to make it work in a new one.
Yes that will be the first version to do so and this behaviour doesnt exist in current version of RasPlex. Current version is using default code and default profile for PHT which on regular platforms like PC / Mac can basically handle every type of media and therefore doesnt require much transcoding.
The next version should be available soon, you'll figure out. There might be still some things that we will have to tune depending on users experiences, but this is a step further towards more playback capabilities for the PI.
Please don't make it transcode mpeg4 xvid files.
This would make it unusable for me as my PMS is incapable of transcoding because the cpu is too weak.
I would have to go back to something like RaspBMC or OpenELEC :(
mpeg4 being listed in supported codecs, they will still use DirectPlay as long as they match the acceptable bitrate criterias :)
mpeg4 being listed in supported codecs, they will still use DirectPlay as long as they match the acceptable bitrate criterias :)
Perfect :D
Thanks for working it all out dude, keep up the good work.
Can't wait to try out the new version, is sounding like it will be a winner !
Of course it never happens as there is currently no such support and that is what this thread is all about. in current 9.9.20, it uses default PHT behaviour which is basically either transcode everything by setting the bitrate in the preferences settings, or directplay everything.
I know that it works this way for me, but one of your earlier posts seemed to refer to some CODEC recognition even in current versions, which was apparently a misunderstanding on my part. That reference must have been to one of the future variants under discussion.
I will keep also the original behaviour which was to always transcode when the directplay setting is not used in preferences.
I don't understand this. Why preserve an existing handicap for no good reason ?
The only sensible behaviour is to transcode only when it needs to be done, like when a specified bitrate limit is exceeded, thus giving users the opportunity to watch the original media in direct play mode as long as they don't exceed that bitrate. Why continue to deny users this obvious benefit ?
Even when transcoding doesn't reduce the bitrate it always reduces the quality (inevitable for any re-encoding) and it also makes in-video navigation fail most of the time. So transcoding should only be used when needed, or explicitly requested by the user.
An 'always transcode' mode is better implemented as a separate flag option. Then each user can choose how to use the client.
But I guess I need to bring that up in the forums for PHT, if that limitation is in the original PHT sources.
----- re: Checking media details after playback start, so as to relaunch if video not playable as-is
I understand the idea, though as mentionned before this information is only available once playback has started and when ffmpeg has openned the stream for the server, so that would be quite difficult to implement as this would require to start playback then determine how it should handled and then eventually restart playback ... that doesn't sound very good.
I agree. Not very good, but still the best possible if needed media details are not available before playback.
My real suggestion was therefore to convince PMS coders to change that limitation. All clients need it...
The next version should be available soon, you'll figure out. There might be still some things that we will have to tune depending on users experiences, but this is a step further towards more playback capabilities for the PI.
Sounds good to me, and I look forward to the next release. (not far off I hope ;) )
Best regards: dlanor
As a temporary workaround to this whole direct play vs transcode debate for ambiguous containers (like MPG4), whichever way we err, could there be a manual override?
Imagine we err on the side of direct playing all MPG4 files. Then, if the user has one that doesn’t play, they can select “Play - Force Transcoding”. I imagine it as simply an option in the Rasplex video browser, underneath “Play”.
It’s not ideal, but it seems to be a good compromise to me.
It also would allow supported videos that have some weird option that causes the Pi problems to still play too.
I don't understand this. Why preserve an existing handicap for no good reason ?
The only sensible behaviour is to transcode only when it needs to be done, like when a specified bitrate limit is exceeded, thus giving users the opportunity to watch the original media in direct play mode as long as they don't exceed that bitrate. Why continue to deny users this obvious benefit ?
Even when transcoding doesn't reduce the bitrate it always reduces the quality (inevitable for any re-encoding) and it also makes in-video navigation fail most of the time. So transcoding should only be used when needed, or explicitly requested by the user.
An 'always transcode' mode is better implemented as a separate flag option. Then each user can choose how to use the client.
I see at least one good reason which is about the remote servers playback as your Internet bandwith might not allow to playback 21 mbits bitrate movies.
I think it's not bad to keep the old style principle as long as you still have the choice of using it or not.
The always transode flag is already existing and its when you define the always transcode bitrate settings in preferences / network. The 'new' transcoding principle will be used when 'DirectPlay' option will has been picked.
I agree. Not very good, but still the best possible if needed media details are not available before playback.
My real suggestion was therefore to convince PMS coders to change that limitation. All clients need it...
I agree and i will eventually put a ticket for such a request if we need some additional info in the future. As of now given the feedback that we had in this post even if its limited, the implemented solution should fit all the mentionned needs i think.
Let's see what the reality check is when the next version is out and then we can try to adjust things.
Even though we're having a good support for Plex Inc, we're not one of their priorities which is quite understandable, so such a feature request might take some time to be coming, should it be coming :)
Sounds good to me, and I look forward to the next release. (not far off I hope ;) )
Yeah that shouldn't be too long now. we will probably release a 0.4.0 rc1 as quite a bunch of things have changed since 9.9.20 to see how things go and depending on feedback, we'll see how much things need to be fixed before 0.4.0.
The finish line is one sight now :)
As a temporary workaround to this whole direct play vs transcode debate for ambiguous containers (like MPG4), whichever way we err, could there be a manual override?
Imagine we err on the side of direct playing all MPG4 files. Then, if the user has one that doesn't play, they can select "Play - Force Transcoding". I imagine it as simply an option in the Rasplex video browser, underneath "Play".
It's not ideal, but it seems to be a good compromise to me.
It also would allow supported videos that have some weird option that causes the Pi problems to still play too.
Well as mentioned earlier this is quite tricky due to the way that things are sequenced in PHT. I think we will try to see how things work for most users.
I have added some specific debug log that will list the transcoding based information in RasPlex as well as some sort of information window that will pop in at transcoding time decision, displaying why the transcoding decision has been taken.
This way we can examine borderline cases and improve the transcoding support if needed.
From what I can gather,
The Raspberry PI Supported codecs are ;
- H.264 / AVC (up to High Profile)
- MPEG-4 (This includes XviD and recent versions on DivX)
- MPEG-2 and VC1 (with license purchase)
- MJPEG, VP6, VP8 and OGG Theora are supported as GPU accelerated software decoders. These are limited to SD resolutions.
- MP3
- AAC
- DTS and AC3 audio passthrough audio is supported
