• 1
  • 2
  • 3(current)
  • 4
  • 5
  • 8
ACCEPTED: On-the-Fly Transcoding
#31
In 99.5% of all cases I only met people that had not a single clue of h264 internals... Get the architecture right and the rest is parametrized easily.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#32
IMO transcoding "just has to work" for the initial implementatoin. In further development we could have XMLs that define the transcoding profile for certain devices and these XMLs ideally could allow power users to do some low level fine tuning. Having a GUI to tune this stuff would be overkill IMO.
Reply
#33
There's 2 kind of transcoding needs :

- The one when you use play to inside Kodi, that will at terms needs xml for specific devices that will not support X or Y codec. With Kodi automatically selecting the correct profile based on the target device.

- The one where something request the streaming and want some specific things, like on a phone, control over the final bandwidth required to play the media. This could be profile based too. But in the end for most users, the need will be a simple profile list and a max bandwidth list. There can't really be automated profiles as there's multiple needs and bandwidth is not related to device but to location of the device.
Reply
#34
Once and for all: This is no time for wishlists / Nice-to-have's
Is it so hard to understand, especially to dev's, that we need to have the basics first?

Both your points are the same, btw. 1) just request a renderer to play a file. The renderer will then do 2).
Reply
#35
Once and for all: why do you even bother answering ?

Is it so hard to understand that I was not talking to you and do not care about your always same kind of answers ?

This is not a fucking wishlist I answer to someone that says only X will be needed after, and I just remember that no (And yes sorry but no 1 and 2 are not the same but you know so better than everybody how things work like in all your answers .....)
Reply
#36
Yeah, you're right, why do I bother. People like you know so much better.
I'm out of the forums. I'm sick and tired of all this...
Reply
#37
And again, we lost someone - that I will miss. Damn it. I think forking xbmc-cmake and just coding what I need and like is my next step, without talking stuff to dead prior to arrival.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
#38
I have to apologize, I didn't understand Tolriq was directly answering to da-anda.
I still stands that there is too much BS on the public forums to bother, though.
Reply
#39
@Koying : No problem you have the same problem as me, answer sometimes too fast with nerves high, and since I still can't fix myself on this I can't ask others to be better than me Sad

And since I alone do support for million users sometimes I'm a little rude on subject where I get thousand of mails of users that does not understand that I can't do things that Kodi does not offers.

(I perfectly understand too much BS on public things, but imagine a big part of this for myself alone with insults and all that goes with that).
Reply
#40
Dear developers,

Thank you a lot about bringing this proposal to attention it deserves. After several years of using OE, I always missed proper DLNA support in XBMC. I like every aspect of the proposal. Whichever way this goes - it will be good, in a sense that things will move forward.

Now, I'm not developer who can help you with this stuff, but I am developer and I agree with the Author: one small but safe step at the time. I think that topics about codecs, containers and bit rates at this time are too complex at this stage of proposal and that focus topic needs to be about crucial (for this stage) issue of implementing any sort of transcoding + streaming into kodi. Once that starts working, discussing additional layers should be appropriate.

p.s. English is not my native language; sorry If I offended anyone - I did not want that.
Reply
#41
have you seen universal media server and the jumpy plugin
http://www.universalmediaserver.com/
Reply
#42
I was kinda curious and hoping someone could tell me if development on transcoding for kodi went or is going anywhere?
Reply
#43
Its a Google Summer of Code project, so you will find out at the end of summer if it was a success Wink

The students are busy working on their projects right now.
Reply
#44
Since I took the time to do the photoshop for another conversation, I figured I'd post it here too. It'd be nice if there was a place to put the Play Using button that didn't require a context menu. So I shopped this.

Image
Reply
#45
(2015-03-17, 13:44)Montellese Wrote: Transcoding could also be done through our normal webserver which tools like the Chorus webinterface use to play video in the browser. IMO that would be the easier initial approach than a fully working UPnP profile system.
I fully agree that transcoding is probably most useful for our UPnP stuff but it's also much more difficult to integrate because we use a third party library which is not that easy to modify. It is much easier to add some simple HTTP GET options to one of the URLs in our webserver and use that for development and testing than first having to define and agree upon a UPnP profile structure, hack that into the UPnP Platinum SDK and integrate it into Kodi.

+1
Reply
  • 1
  • 2
  • 3(current)
  • 4
  • 5
  • 8

Logout Mark Read Team Forum Stats Members Help
ACCEPTED: On-the-Fly Transcoding1