ubuntu-tv team mailing list archive

["Ian Nicholson" <ian@xxxxxxxxxxxxx>]

Why unity 2d instead of 3d? Any other reason than resource usage?

Sent from my Palm PreOn Jan 1, 2012 13:49, Thomas Söderberg <thomas@xxxxxxx> wrote: 

Hello Bruno 
 
Comments on Q1 
Myth backend are very solid and could be used for the streaming part. The only thing that I believe needs to be adjusted with mythbackend are the the way it's handling livetv and timeshifting. Right now you really never watch livetv on myth instead it's always start by recording the livetv and then you watch the recorded tv. This could and should be made different from the way it's handled right now, it's important that switching channels are really fast and behaves like a standard dvb box. But I definitely think mythbackend could be used and it should be quite easy to modify existing myth to deliver fast channel switching by sending out the stream right away and then start the recording in the background instead.  


Comments on Q2
I think unity 2d would be the perfect base for UbuntuTV. 


Cheers, 

Thomas







2012/1/1 Bruno Girin <brunogirin@xxxxxxxxx>


Thomas,

I completely agree with your comments on usability. It should behave exactly the same as a TV when you switch it on and all more involved tasks should be accessible via the menu button on the remote: so press "menu" and you get access to the full distro in a way that is still TV friendly.



Having said that, I have two questions that you may be able to comment on:


Could that be a achieved by creating a different MythTV front-end but keeping the back-end unchanged?
Could unity-2d be a good starting point to do something like this?
Cheers,

Bruno 




On 31/12/11 00:09, Thomas Söderberg wrote: 
Regarding repo this one is the one to use git@xxxxxxxxxx:obit/ObitTV.git 


2011/12/30 Thomas Söderberg <thomas@xxxxxxx>

Hello all 

My simple thoughts to success for UbuntuTV 

I've been using mythtv for a long time and even though I found it really nice but complains have been issued by my relatives :-( They found it hard to use, mainly because they are all used to a normal tv (press channel 1 on remote and channel 1 pops up without hazzle and waiting). I think this is very keen to success for future UbuntuTV. It should be simple as 'hel'l from start and if you need extra features you add it as you go along, However it should also contain the extra feature that we all want, but from the basic it should be very easy to use and look nice (It's all about perceptions) . Another important thing is speed. Switching between channels should be fast. The other thing that I see as important are that it's easily customizable 




Below are my recipes 

I've did some quick hacking tonight and come up with the following arrangement. (eg It's not about perceptions in this POC just a quick hack)

Frontend client should be made by Qt/QML it should be capable of reading almost all  media url's rtp/rtps/fileshares etc etc 


Backend included for dvb should be made of streaming dvb card out in the air (rtp). 

The poc that I've came up tonight could be followed and cloned at https://obit@xxxxxxxxxx/obit/ObitTV.git 




basic ideas are followed


QT app handles core play of files to screen (currently using vlc lib did start with gstreamer but the sink was not fast enough and I didn't have the time to speed it up for th POC)  See a great future for using gstreamer as main lib for viewing. 


QML handles all the GUI stuff for presenting menus etc (Right now it doesn't do much just show a simple overlay when pressing F1 where you could choose channels) This would make it easy to modify and expand without changing the core. 


PosgresDB as stores for url to medialinks etc 
For my home right now I'm using DVBLast for streaming dvb (It's working as a charm and is very stable)



My simple thoughts, 



Thomas 







 




 


--
Mailing list: https://launchpad.net/~ubuntu-tv
Post to     : ubuntu-tv@xxxxxxxxxxxxxxxxxxx


Unsubscribe : https://launchpad.net/~ubuntu-tv
More help   : https://help.launchpad.net/ListHelp