tilleke

Erik, you're wrong! Vu+ Players uses it and you know it.  

Sorry for writing in English but my Dutch is not the best

As a third party developer, I think it is a pity there is now fragmentation (different APIs to handle). On the other hand, I think Eric's approach is good, especially for teams like OpenPli, VIX and others teams which support different brands that may have STBs with transcoding-abilities. I guess here it is only a matter (to make it sound easy  ) of adapting the "backend"-code to make it "speak" with a particular STB and its APIs for transcoding and then through Eric's streamproxy make them available for other developers.

I have already told Eric that I disagree with him what regards Vu+'s transtreamproxy when he says it crashes every two times. There were indeed initial problems but with the latest driver (December 2013 I think), I find them much better now and I hardly experience any crashes changing bit-rates while streaming and so forth. However, some options can still create crashes but they are rarely used and better not touched. I have been testing many images such as VTi, BH (native images) but also VIX and I get very good results. Let us also remember that Solo2 and Duo2 have huge differences in quality as to transcoding so it might also depend on what STB you are using for transcoding.

That said: Eric's streamproxy works very well! He also added streaming-authentication which works fine despite what is being said in the other thread. Another important thing that I noted is that Eric's implementation seems to be more compatible. WIth Vu+'s transtreamproxy I have some incompatibly-issues but with Eric's streamproxy the problematic Android-devices in question work fine.

I also want to thank Eric for his willingness to listen to a third-party developer like me and the availability shown. In the past weeks we have worked and tested things together and I think the streamproxy is mature and I can say it works fine with my Android-projects.

@колбаскин

Do you mean streaming authentication on port 8002 using transcoding? I am not sure VLC on mobile (Android, iPhone) supports streaming authentication. I think most players do not. The native android videoview does not, at least not out-of-the- box and may require a hack to do it.

@SpaceRat

Whatever your opinion is, there is no need to be offensive and insult people. Nothing can justify such a behaviour.

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.