RPi Transcoding

Dev Community Apps & Creations
81

----- re: Why enforce transcoding just because the user choose a quality bitrate limit ?

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'm sorry, but that statement shows that you didn't fully understand how I meant that it should work.
I regret seeming to go on a rant here, but I want my suggestion to be completely understood before it is rejected.
If you still decide to reject it I will accept that, but right now I need to clarify what I meant.

My suggestion was that the quality bitrate limits should be enforeced CORRECTLY, which is currently not the case.
Such a correct implementation would allow "Direct Play" of media with LOWER bitrate than the chosen bitrate limit.
Naturally the test for CODEC compatibility should still enforce transcoding for incompatible media, but that is a separate condition,
which should be applied in addition to the test for the bitrate condition.

To express it like in programming:
IF (bitrate_too_high OR codec_unsupported) THEN goto transcode ELSE goto direct_play.

That method will work well both with quality settings for some bitrate limit or for unlimited "Direct Play".
(the latter case being handled as a 21 Mbps bitrate limit due to RPi limitations).

It's impossible for such an implementation to cause playback at a rate higher than the specified limit.
(Unless PMS has failed to report the correct bitrate, in which case all our methods falter.)
 

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.

 
That choice does not exist if the 'old style' is implemented, since it enforces transcoding for everything when any bitrate limit is used.
So any user who needs a specific limit is deprived of the ability to 'Direct Play' media that would fit below that limit.
(Unless they choose to fiddle with the quality settings each and every time.)
 

The always transode flag is already existing and its when you define the always transcode bitrate settings in preferences / network.

 
Huh ? I never saw any "Always transcode bitrate" settings in any menu.
What I see in that menu are settings for "Local video quality" and "Remote video quality".

While it's true that PHT has no separate 'Direct Play'/Transcode option, and forces transcoding for all set bitrates, this does NOT make it correct. I consider it an incorrect design leading to worsened playback quality for all cases where a video would have worked fine with 'Direct Play' without exceeding the limit set by the user. That design choice is probably due to the strange goal of the PHT project to minimize the number of configurable options. (I just don't get it, but they have stated that goal many times)

For comparison you can check the 'Kepler' client for Android, which does have an explicit 'Direct Play' option, which when set makes the client behave like I suggested you do it for RasPlex, as the 'Direct Play' only applies if both the CODEC and the bitrate conditions are satisfied. And users who want everything transcoded can get this by disabling the separate 'Direct Play' option. But without a separate option the client should use the method that allows the maximum quality compatible to each setting.
 
----- re: Bringing up the issue of scant pre-play media info via API with the PMS programmers

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.

I agree, though I also think it would be a good idea to open an issue ticket about it right away.
That way there's a chance that the API will have been extended if/when we really need such features in future.
 

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 :)

Agreed, but this lack of the API is not just our concern. It's bound to affect all clients.
Still, there's no real hurry here, since most clients have managed fairly well so far.

----- re: Looking forward to next RasPlex release

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 :)

I'll be sure to participate in the testing of that release candidate as soon as it's available
 
Best regards: dlanor

82

Just be careful with those goto statements dlanor…

http://xkcd.com/292/

83

Hi

Here is a couple of minutes of ads recorded in Windows Media Center, that I am unable to play on Rasplex.  If I change the container, it works.  So I assume Rasplex doesn't like .wtv.

https://dl.dropboxusercontent.com/u/41885869/Australian%20SD%20TV%20Example.wtv

Can you see whether the transcoding thing can help in this regard?

Thanks

Matt

ps - My TV is currently being fixed, so I haven't actually tested this exact file (because I currently cant), but in the past I have been completely unable to do so.

84

My suggestion was that the quality bitrate limits should be enforeced CORRECTLY, which is currently not the case.
Such a correct implementation would allow "Direct Play" of media with LOWER bitrate than the chosen bitrate limit.
Naturally the test for CODEC compatibility should still enforce transcoding for incompatible media, but that is a separate condition,
which should be applied in addition to the test for the bitrate condition.

 

I dont seem to understand the logic, sorry dlanor :) DirectPlay just means play media without any modifications, DirectPlay with reduced bitrate is called transcoding :)

There is just simply no way that the PI has the necessary CPU to reduce bitrate of a video. if you want to play videos that would DirectPlay (with original bitrate) with a reduced bitrate, then you need to trancode them to reduce the bitrate.

It looks like there is a misunderstanding of what transcoding is. it is not only used for changing codecs, but it i used to alter whatever change you would make to the original video stream as RPi cannot handle it CPU wise.

Therefore, should you require to play all your H264 videos with a lower bitrate, you would need to define that in the transcoding preference and select the desired bitrate that uou want them to play with so that PMS can do the job.

I have the feeling that we aim at the same thing but we just cant understand each other :)

85

Hi

Here is a couple of minutes of ads recorded in Windows Media Center, that I am unable to play on Rasplex.  If I change the container, it works.  So I assume Rasplex doesn't like .wtv.

https://dl.dropboxusercontent.com/u/41885869/Australian%20SD%20TV%20Example.wtv

Can you see whether the transcoding thing can help in this regard?

Thanks

Matt

ps - My TV is currently being fixed, so I haven't actually tested this exact file (because I currently cant), but in the past I have been completely unable to do so.

I'll give it a look. could you get me the xml information detail from PMS (Go into the movie, click information and then view XML on the poping window).

86

I dont seem to understand the logic, sorry dlanor :) DirectPlay just means play media without any modifications,


Yes, and that should be the goal for all Plex playback whenever possible, as it gives maximum quality.
But since it isn't always possible to DirectPlay well, there are three different conditions that should enforce transcoding.

1: Media CODEC incompatibility should enforce transcoding.

2: Media bitrate higher than a limit chosen by user should enforce transcoding

3: If the client has an explicit 'Direct Play' toggle in OFF state, or an explicit 'Always Transcode' toggle in ON state, then all media should be transcoded, even if not necessary according to the other conditions.

If none of those three conditions are true then the media should DirectPlay.

And this method is exactly what has been implemented in the 'Kepler' Plex client for android devices, like I told you earlier.

The method of PHT is far more primitive and less flexible, as it permits DirectPlay only for users who don't need to set a bitrate limit.

This is BAD because there are lots of people who need access to PMS servers through Internet connections with low bitrates.

These people need an explicit bitrate limit in order to play high-bitrate media (transcoded of course), but they should still be able to

DirectPlay media with bitrates lower than their limit, which the PHT method won't allow.

(unless the user repeatedly fiddles with settings back and forth to suit current media files).

DirectPlay with reduced bitrate is called transcoding :)

No. DirectPlay with reduced bitrate is a contradiction in terms. It's impossible. Any reduction means that it's not DirectPlay.
And I have never ever suggested such an impossibility.

What I have said is that each quality bitrate setting should be seen as the limit below which DirectPlay should be allowed.
The quality setting 'Direct Play' should be treated identically, but with an infinite limit (though we may lower that to 21 Mbps, as discussed earlier).
 

There is just simply no way that the PI has the necessary CPU to reduce bitrate of a video. if you want to play videos that would DirectPlay (with original bitrate) with a reduced bitrate, then you need to trancode them to reduce the bitrate.

I have never ever spoken of reducing any media bitrate in the client.
The actual transcoding is of course done by PMS for all transcoding cases.
It's only the criteria for requesting the transcoding that are handled by the client.

What I have said is that there are two different ways of respecting a user-chosen bitrate limit.

The way I prefer will only transcode media that originally have higher bitrates,
but will DirectPlay media that originally have bitrates below the limit.
(Unless the CODECs are incompatible of course, which should also enforce transcoding)

The way you prefer will transcode everything when the client has a user-chosen bitrate limit.
And by so doing it will reduce the playback quality of all media that could have been DirectPlayed (without exceeding limit).
And reducing playback quality unnecessarily is a very bad thing for any media player to do.
 

It looks like there is a misunderstanding of what transcoding is.

No there isn't. I know full well the significant aspects of transcoding.
We only disagree on the criteria which should enforce transcoding.
 

I have the feeling that we aim at the same thing but we just cant understand each other :)

And then I must continue to clarify my statements until no further misunderstanding is possible...

Best regards: dlanor

87

I think we basically are on the same line. The only difference that i might see between what you suggest and what has been implemented is that the bitrate transcoding threshold set to 21 mbits total is not a parameter as of now.

Its more likely a general limitation of RPi that i dont expect to change really on different Pis (except maybe if you have a very bad network bandwidth issue).

I suggest we look at how this behaves in next release and if some needs show up regarding the fact that this should be user configurable, then we'll add an option as the current bitrate setting in PHT is used for the alsways transcode option.

We'll see if these settings need to be considered as directplay bitrate transcoding limit. the only thing that might be an issue is that the options available have quite big jumps as of now (20 mbits being the highest, then it drops to 16 or 12 i cant remember).

88

The method of PHT is far more primitive and less flexible, as it permits DirectPlay only for users who don't need to set a bitrate limit.

This is BAD because there are lots of people who need access to PMS servers through Internet connections with low bitrates.

These people need an explicit bitrate limit in order to play high-bitrate media (transcoded of course), but they should still be able to

DirectPlay media with bitrates lower than their limit, which the PHT method won't allow.

I think there's a misunderstanding of the definitions of bandwidth vs bitrate. If I have media at a bitrate that the Pi can't handle, it doesn't matter how much bandwidth I have to get the media to the Pi, the media will need to be transcoded for a smooth viewing experience. The inverse is also true. Even if the Pi can handle the media's bitrate, but the bandwidth isn't there to transport for smooth playback, the media will still need to be transcoded.

89

-
I regret seeming to go on a rant here

Dude you are not seeming to rant.

YOU ARE ranting -_-

90

Right that was my point :

 If I have media at a bitrate that the Pi can't handle, it doesn't matter how much bandwidth I have to get the media to the Pi, the media will need to be transcoded for a smooth viewing experience. 

That's where the cleint total 21 Mbits bandwith is used for :)

The inverse is also true. Even if the Pi can handle the media's bitrate, but the bandwidth isn't there to transport for smooth playback, the media will still need to be transcoded.

Yes this toggles once the DirectPlay setting is not used and when you pick the additionnal bitrate limitations in Preferences/network :)

91

Hi

Here is a couple of minutes of ads recorded in Windows Media Center, that I am unable to play on Rasplex.  If I change the container, it works.  So I assume Rasplex doesn't like .wtv.

https://dl.dropboxusercontent.com/u/41885869/Australian%20SD%20TV%20Example.wtv

Can you see whether the transcoding thing can help in this regard?

Thanks

Matt

ps - My TV is currently being fixed, so I haven't actually tested this exact file (because I currently cant), but in the past I have been completely unable to do so.

 

Ok i grabbed your sample, thanks for sharing one this is very helpful  :)

The good news is that the wtv container is not the issue. it is correctly identified and the video included codec is mpeg2, audio one being mp2.

I dont have the RPI MPG2 codec installed, so it has detected that it should transcode which  sounds good.

What about that ? :D
 
http://www.youtube.com/watch?v=BhE2F74WKaw

(Sorry for that poor video)

92

Great to see transcoding support - thanks for all the hard work.

Is the latest code in a sensible state for people to start testing - I see the code is in the rasplex-dev branch?

93

feel free to test it if you want ... but some bits need some OE update as far as setting some files locations :)

We plan to release that one soonish anyways ... 

94

I think there's a misunderstanding of the definitions of bandwidth vs bitrate. If I have media at a bitrate that the Pi can't handle, it doesn't matter how much bandwidth I have to get the media to the Pi, the media will need to be transcoded for a smooth viewing experience. The inverse is also true. Even if the Pi can handle the media's bitrate, but the bandwidth isn't there to transport for smooth playback, the media will still need to be transcoded.

 
What you say is perfectly true.
But it only covers cases where the media bitrate is higher than the available transfer bandwidth.

However, just consider the following scenario:
 
The user has an ISP bandwidth of 5 Mbps for downloads, to be used in accessing shared content of a remote PMS.
Thus he must set a remote quality bitrate limit lower than 5Mbps, or face failure for higher bitrate videos.
So he sets that bitrate limit to 4 Mbps, which is a bitrate that the Pi should have no problem handling.
This setting works fine for transcoding videos that need it due to their higher bitrate.

Then he tries to play a normal 1000 kbps TV episode, expecting it to play at full quality since it's below the bitrate limit.
But RasPlex still tells PMS to transcode the episode, slightly reducing video quality and ruining playback position controls.

That last case of this scenario is what I argue against.
For such cases, if the video has compatible CODECs, I say it should DirectPlay.

I've come to accept that this will not be fixed in the upcoming next release.
But I still have hopes that this improvement will be adopted at some point in the future.

Best regards: dlanor
95

Ok i grabbed your sample, thanks for sharing one this is very helpful :)

The good news is that the wtv container is not the issue. it is correctly identified and the video included codec is mpeg2, audio one being mp2.

I dont have the RPI MPG2 codec installed, so it has detected that it should transcode which sounds good.

What about that ? :D

http://www.youtube.com/watch?v=BhE2F74WKaw

(Sorry for that poor video)


The problem I was having is that I can't direct play, even though I do have the MPEG codec. But if I put it in a different container, I have no problems.

Would it help if I donated you enough for the codec? That way you could test what I mean.
96

Well RasPlex trancoding will detect if MPEG2 and VC1 codec are installed and it will not trigger transcoding if you have them.

Though i guess that if it didnt directplay in current version that would mean that it cannot read that mpeg2 format i guess ... then transcoding will still be required.

97

Ok some update on transcoding things to adjust in next release :

- A bad bug that will trigger transcoding on audio files : Fixed in next release.

- Another bug which doesnt seem to handle properly additionnal codecs (Mpeg2 & VC1). i'm waiting for some samples for that one to test with

- some imporvements that came from upstream and that will allow us to remux properly DTS / FLAC rather than transcoding when possible using a Matroska contaienr rather than MpegTS / HLS one.

i'll try to have those fixed for next release :)

98

Yep, having troubles with mpeg2.

When I go to watch a file, a box briefly pops up in the lower right corner saying something like 'transcoding unknown codec mpeg2video.

Let me know if you need some samples.

Also, just to clarify, I could previously watch mpeg2 codec in a mpegts container no problems, but could not watch the same mpeg2 codec in a wtv container. Not sure why, but there you go.

99

yes this is already fixed... will be available in next release :)

100

Ok some users reported that bitDepth for video higher than 8 bits like 10 bits movies are not supported properly with directplay.

it will result in heavy Pixelation during playback.

I have updated transcoder client to trigger transcoding which will bring it back to 8bit bitDepth... playing smoothly.

Updating first post.