693 replies to this topic

[колбаскин]

We have a conversation of the deaf with the blind

If you made work of authorization on the, not as was earlier.  Make the normal instruction and fix it in 1м to a subject post.  You write information scraps.  You promise something to correct that, you agree that doesn't work.
I already several times wrote that your image is used by many Russian-speaking people.  They don't go to you on a forum.  Each your change is a problem for all.  You made use of your image not convenient.  It is necessary to do image with opportunity everything to establish from a remote control.  You start everything transferring to configuration files leaving from a graphic cover.

Make the normal instruction for authorization and transkoding work!

[Erik Slagter]

You start everything transferring to configuration files leaving from a graphic cover.

Yes this is something I understand (the rest of the post not).

I have explained several times now that most configuration options do not work. Little sense in making a graphical interface for things that don't work.

 

Also this is not a finished project. Wait and see before you make up your mind.

 

On the other hand, I think we (as image maker) have put "some" effort in making the image. I think it's not too much to ask from the community to put some effort in it as well. In this case, a perfect example would be you explaining to the Russian community, how transcoding is handled in OpenPLi from now onwards.

[delavega]

"I have explained several times now that most configuration options do not work. Little sense in making a graphical interface for things that don't work."

 

Especially if it crashes/freezes the box.

[Erik Slagter]

Yes, very frustrating. Although I must say the solo2 is more susceptible to it than the duo2.

[delavega]

Yea i can tell lol

[tilleke]

Eric,

 

In my beta-app for Android, you can change framerates and, more importantly, bitrates on the fly (and also frequently) by using the current transcoding-apis in OWIF and this works flawlessly and without any crashes. This has been tested extensively both with Solo2 and Duo2 using BH, VTi and OpenVIX and other OE-Alliance images. There were indeed problems in the past but they are nearly non-existent now using the latest drivers issued in 2014. I agree though that sometimes when playing around with the more advanced options such as Profile, Level and so forth, there are occasional crashes but not that frequent as you seem to imply in this thread. Besides, those are normally less important and to set them requires a click on Advanced Options in the transcoding-plugin (now not available in OpenPLI). The only time I needed to play with them was when I tried to get ChromeCast working with my Duo2. 

 

While I like your idea to create a universal approach for transcoding (and perhaps the reason you are implementing this is because you have been commissioned by other STB-manufacturers which are to release STBs with transcoding-support) but I see a few problems as a third-party developer who wants to support transcoding and OpenPLI (and OpenPLI based images):

 

1) the current transcoding-apis in OWIF are not available, probably because the transcoding-plugin is missing. This means there is currently no way using APIs to change important parameters such as bitrate and framerate. I think you mentioned you would later release some information how to do this. I know, we need to have patience but do you have an idea when?

 

2) we need a way to determine that the image in use is OpenPLI (or based upon OpenPLI) so we know when to use the required APIs (the "new" request style) you implemented for transcoding (which are working fine by the way) i.e:

•   /livestream?service=service
•   /live?service=service
•   /filestream?file=file
•   /file?=file 

To determine that the image is OpenPLI (or based upon OpenPLI), I would suggest a similar implementation what OE-Alliance did i.e. they added in the web/about-api a new xml-tag indicating it is an OE-Alliance image. If you could insert an additional tag in web/about indicating that it is an OpenPLI-image (and hoping also other images using your base would use it), we third-party developer would know that we would need to use a different approach by using the new "APIs" mentioned above (for transcoding and when available for changing transcoding parameters). Of course, another type of tag could be used just as long as there is a way to determine that your implementation of transcoding must be used.

 

Ideal would be of course that eventually there will be a unique API but I am not that optimistic and if it happens, it surely won't happen overnight.

 

Above suggestion would ensure that users of OpenPLI can benefit fully from apps like mine and other third-party developers. If you have any other ideas to resolve this dilemma, I am all ears.

 

Hope to hear your comments in this regard.

 

 

 

 

[Erik Slagter]

I am going to reply to this in chunks later on, I think it's very valuable feedback.

Let me start with a little bit of context.

At the moment I am experimenting with app-less streaming on Android. IOW you start the browser, point it to your_stb:8001 and browse through your services and channels, then simply choose "play" or "transcode" and then it goes. This is not possible with the OpenWebIf because 1) the mobile variant does not allow to do anything with selected services and 2) the non-mobile layout sends a .m3u file, which Android browers and players cannot handle if they contain http references (which I think is stupid, but that is another story).

I already implemented a mini-http-server in streamproxy, that can serve streaming and transcoding, skipping the .m3u step. This is already in the non-public development version, for files only. It works, the streamproxy serves a videostream immidiately (video/mpeg mime), which is recognized by both the Android browser and players like vplayer and vlc. It appears to have a major drawback though, which I did not foresee: both the browser and the player start streaming the file, so immediately both encoders are engaged (in case of solo2 it simply won't work anyway). I don't think there is a clean solution for that. It looks like the integrated http server is not the way to go in the end. Bummer!

Also the VU+ App isn't actively maintained, e.g. lacks the file transcoding feature and also is VU+specific (which is wrong imho, knowing other manufacturers offer transcoding as well nowadays).

I was under the impression your App wasn't maintained either, but it appears I was wrong. As it now shows, it looks like using an App really is the way to go with at least Android, the available browsers on Android don't allow streaming the way I want them to.

So to conclude, I really look forward to teaming up with you to make things work great and add some features as well.

[Rob van der Does]

Let me short phrase this: I'm using the latest ViX-image and a beta version of the VU-android app (on my phone), and it works (almost) flawless for both the DUO2 & Solo2. And that includes changing settings via the app: they take place on the fly.

So I'm really looking forward to cooperation between Eric & Tilleke to get the best out of all the options and to share experience.

Edited by SatKiekerd, 26 April 2014 - 10:24.

[delavega]

Yes the vuplayer android app works perfectly with my solo2.

[Erik Slagter]

Is this the relevant App?

http://play.google.c....AndroidDreamer

[delavega]

no this one 

 

https://play.google.com/store/apps/details?id=com.vuplus.vuplusplayer
 

[delavega]

AndroidDreamer wont even display my bouquets...

[Erik Slagter]

In my beta-app for Android, you can change framerates and, more importantly, bitrates on the fly (and also frequently)

The version I found is from 2012, is that correct?

I have done experimenting with the frame rate settings, but I never got it working. Either it does not have any (real) effect (checked with ffmpeg) or it yields a crash. So for the moment I am ignoring the frame rate configuration completely.

The bitrate is more or less valuable imho, but it's not as fine-tunable as many people seem to think. The feedback to the encoder is quite coarse. Which doesn' mean it cannot be used of course. Depening on whether you're on lan or small or wide bandwidth, you want to change the setting.

Actually I was thinking of a set of profiles, which incorporate bit rate, frame size and level/profile settings. That would a) make things clearer for end-user and prevent the encoder from crashing from "illegal" combinations of settings. The actual implementation (how/what, /proc layout or use of ioctl's etc.) would be independent of the user interface then.

Something like:

low bandwidth - low complexity (old/cheap pda soc hardware) = small frame, low bitrate, constrained profile, low level
low bandwidth - high complexity (new hardware) = '' high profile, high level
medium bandwidth - low complexity ...
medium bandwidth - high complexity ...
high bandwidth ...

without any crashes.

Hmmm, I can't believe that 100% if that's only using the vuplus tools. They lack the constant draining that's necessary to keep the drivers happy.

the past but they are nearly non-existent now using the latest drivers issued in 2014.

Interesting because the changelogs of the recent driver updates don't mention transcoding. Also the problems I am seeing, also appear with current driver versions. The dmesg output doesn't lie ;-) Try e.g. transcoding a file that doesn't have a complete PMT or PAT within the first second...

I agree though that sometimes when playing around with the more advanced options such as Profile, Level and so forth, there are occasional crashes but not that frequent as you seem to imply in this thread.

Setting the /proc entries is another story. There are a few values that work (completely independent from what the driver advertises as "usable"). Any other values will crash the transcoding engine and you can reboot. This is not "now and then", it's 100% reproducable. That's why I always advice users not to touch the settings if they don't know exactly which ones are safe.
 

I've mentioned before that OpenPLi never had a plugin that allows setting the "advanced" options. I had a commit ready to add the vuplus transcoding plugin, but I never committed it, because of the very disappointing results. Almost every setting made the engine crash. I believe you can't give users a plugin that makes the stb crash all of the time, it's unexplicable.

 

That (indeed) means the OpenWebIf in OpenPLi never had the transcoding settings options.

 

Besides this issue, we as a team feel transcoding options should not be set on a global base, but instead on a per-connection base. And that is what the streamproxy implements. This approach allows you to fully use the transcoding on the duo2, where you could transcode to a "small" and a "large" device simultanuously.

 

I am not saying the user should always have to completely configure each indivual connection, there should be defaults (which the streamproxy also implements) and all of them should be override-able per connection without messing up other and future connections.

[Erik Slagter]

No this one 

https://play.google.com/store/apps/details?id=com.vuplus.vuplusplayer

I was talking about the App from tilleke, not VU+.

[stick50jr]

Let me short phrase this: I'm using the latest ViX-image and a beta version of the VU-android app (on my phone), and it works (almost) flawless for both the DUO2 & Solo2. And that includes changing settings via the app: they take place on the fly.

So I'm really looking forward to cooperation between Eric & Tilleke to get the best out of all the options and to share experience.

 

I'm using an S3 4g mobile to transcode with the 'Vuplus Player' app (ver 1.8 beta - April 2014) from a Vu+Duo2.  The set up is limited by a 1Mbps upload limit between the Duo2 and the internet.  Accordingly, I have set the transcode resolution to 320x240 within OWIF and I set the bitrate and framerate within the android app to 500kbps and 50fps.  This combination of parameters is very reliable and plays both live and recorded material. The PQ is acceptable given the BW limitations and has improved with Vu+ latest drivers.  I'm using Vix but understand it works well in BH, VTI and OEAlliance images.  This app allows many other 'remote' control features as well.  Highly recommended.

 

Hopefully Tilleke can get it going for openPLi as well

Edited by stick50jr, 26 April 2014 - 12:54.

[Rob van der Does]

No this one 

https://play.google.com/store/apps/details?id=com.vuplus.vuplusplayer

I was talking about the App from tilleke, not VU+.

Yes, that's the one made by Tilleke (Android dreamer as well, but that's not been maintained for a long time).

Edited by SatKiekerd, 26 April 2014 - 12:54.

[stick50jr]

No this one 

https://play.google.com/store/apps/details?id=com.vuplus.vuplusplayer

I was talking about the App from tilleke, not VU+.

 

The VU+ app is developed by Tilleke... so moving forward we are talking about the VU+ player as Tilleke has stopped development of the other app.

 

Whoops! someone beat me to the post

Edited by stick50jr, 26 April 2014 - 13:03.

[Erik Slagter]

While I like your idea to create a universal approach for transcoding (and perhaps the reason you are implementing this is because you have been commissioned by other STB-manufacturers which are to release STBs with transcoding-support)

I know we are accused of having ties with Xtrend (let's call it how it is), but it's really not the case. I just want a neutral interface. Other manufacturers will start using the "nextgen" Broadcom SoC's sooner or later, and they'd be stupid if they wouldn't support the transcoding capabilities.

1) the current transcoding-apis in OWIF are not available, probably because the transcoding-plugin is missing.

Correct. We never had the vuplus plugin (see other message).

This means there is currently no way using APIs to change important parameters such as bitrate and framerate. I think you mentioned you would later release some information how to do this. I know, we need to have patience but do you have an idea when?

We believe transcoding parameters should be connection-level, not system-level, so there won't be such an api. We can discuss this further.
 

2) we need a way to determine that the image in use is OpenPLI (or based upon OpenPLI) so we know when to use the required APIs (the "new" request style) you implemented for transcoding (which are working fine by the way) i.e:

In fact, you shouldn't probe for OpenPLi but for streamproxy. You never know what image inherits what parts from OpenPLi, the streamproxy may very well be in a non-OpenPLi-image or derived image.

I am also struggling with this issue. For now there is basic compatibility; in the default configuration it can act just like the vuplus streaming tools. But for advanced usage, you have to know if you're talking to vuplus or to streamproxy. For me it's very easy to make the streamproxy "probable", but the question is whether that is the best approad. OTOH I can't think of a better approach for the moment.

[Erik Slagter]

To determine that the image is OpenPLI (or based upon OpenPLI), I would suggest a similar implementation what OE-Alliance did i.e. they added in the web/about-api a new xml-tag indicating it is an OE-Alliance image.

But the web/about-api is part of the OpenWebIF, you'd have to discuss that with SpaceRat. But I can make a probe-able virtual page on the streamproxy, that's no problem. It could also report how many transcoding devices are available, what their capabilities are, in text, html, xml, whatever.

Ideal would be of course that eventually there will be a unique API but I am not that optimistic and if it happens, it surely won't happen overnight.

Legacy... VU+ of course has never wanted to make their stuff neutral, which is understandable.

I am interested in your answers and possibilities for your app.

[Erik Slagter]

No this one 

https://play.google.com/store/apps/details?id=com.vuplus.vuplusplayer

I was talking about the App from tilleke, not VU+.

Yes, that's the one made by Tilleke (Android dreamer as well, but that's not been maintained for a long time).

Now I am confused...