n-Tube? (Pointing the YouTube browser to any *.flc provider)
daryl.m...@gmail.com
to other URLs? This would be great for other providers of that
content.
(And being able to save locally, or at least "Record from YouTube"
would be cool too.)
-D
Fernando Cassia
http://en.wikipedia.org/wiki/Flash_Video
FC
Dream of the Daily Mail
It is the Holy Grail
And then the BBC
Your life would be complete
-Manic Street Preachers, "Royal Correspondent"
nerochiaro
Each provider has its own API (or requires screen scraping even), so
for each one you have to implement a separate way of reaching the
videos.
If on the other hand you already have the full URL to the flv video in
some way, then it's possible to play these back most probably, unless
they are encoded in some way that is slightly different than youtube's
and that breaks out transcoder (it was tested only on youtube).
--
nero
Joe Born
> Each provider has its own API (or requires screen scraping even), so
> for each one you have to implement a separate way of reaching the
> videos.
>
> If on the other hand you already have the full URL to the flv video in
> some way, then it's possible to play these back most probably, unless
> they are encoded in some way that is slightly different than youtube's
> and that breaks out transcoder (it was tested only on youtube).
>
information on the api or algorithm for parsing, I think we'd be happy
to include it on the OSD, that would be great IMHO.
alex
MythTV server.
http://www.mythtv.org/wiki/index.php/MythFlash
The plug-in works by allowing a user to convert a recording to a flv
using ffmpeg and then use the provided flvplayer to play the recording
remotely in any flash browser. With a bit of php code, the plug-in can
be made to list all available flv files that the OSD can then digest
and play. I don't know whether the OSD YouTube plug-in will be able to
handle the resulting large flv files. Will it be able to buffer so
much data?
alex
Jeremiah Johnson
at home yet, but using the OSD as some sort of interface to my future
mythtv box is definitely one of my goals. I personally would hate
only being able to view my recordings through a flash frontend.
-miah
alex
mythfrontend is too heavy for the OSD. This flv work around might be
an excellent opportunity to bring the OSD closer to a MythTV front end
device.
alex
On Jul 18, 3:48 pm, "Jeremiah Johnson" <jeremiah.john...@gmail.com>
wrote:
> Is it not possible to run the mythfrontend app? I havent run mythtv
> at home yet, but using the OSD as some sort of interface to my future
> mythtv box is definitely one of my goals. I personally would hate
> only being able to view my recordings through a flash frontend.
>
> -miah
>
kirk
how all this software is put together, but one of the things that I
noticed immediatly about the youtube plugin was all of this
information is hard coded into the plugin, and ultimately burned into
the firmware.
As new requests come in to support additional sites, and existing
sites change the structure of their pages and/or urls, there seems to
be a need to support this feature in a way that saves storage space,
on the OSD, and eliminates the need for firmware updates.
Ok enough with the long winded intro. I propose that dynamic content
meta data, from the web, be obtained through a central gateway
controlled by Neuros administration and/or developers which would
serve this purpose well. A simple web site that scrapes the meta data
from youtube, google and others would provide the OSD with a
consistant interface to descriptions and urls of web video. Is this
something that could run on the neuros servers?
With a central web site like this, the OSD could also provide
additional information to the users such as firmware updates, etc...
On Jul 17, 9:16 pm, Joe Born <jb...@neurostechnology.com> wrote:
Jeremiah Johnson
source as well.
-Jeremiah Johnson
Sent from my iPhone
Fernando Cassia
No thank you very much, I don't want my device's functionality to be dependent on the vendor's site being available or not.
Reminds me of the "wise guy" approach by some shareware vendors who check licensing info (registration data) on-line. The result is that you don't actually purchase al license to use the software indefinitely, just license to use it as long as the vendor chooses to keep the licensing validation server online...
FC
nerochiaro
> meta data, from the web, be obtained through a central gateway
> controlled by Neuros administration and/or developers which would
> serve this purpose well. A simple web site that scrapes the meta data
> from youtube, google and others would provide the OSD with a
> consistant interface to descriptions and urls of web video. Is this
> something that could run on the neuros servers?
>
> With a central web site like this, the OSD could also provide
> additional information to the users such as firmware updates, etc...
A better approach to this would be to simply have an infrastructure in
place on the OSD for fetching the actual flv files that is based on
some kind of virtual file system and plugins.
Basically all the navigation into the FLV provider site is exposed to
the OSD file browser (or anything else) as a regular file system tree
(using fuse and/or something else on top of it to manage interactions
with GUIs).
Internally, the VFS does all the scraping or XML API parsing it needs to do.
This is similar to what the current upnp browsing feature works.
And this work can be further offloaded to specialized plugins, that
may be into the OSD flash, or may be on some external mediacard if the
user wants to add his own without reflashing (using unionfs or just
searching on the cards).
Finally, I have to say that 90% of this brilliant idea is actually
Steven Robertson's idea, so I'm sure he will want to pitch in with
more on this.
Cheers,
--
nero
Steven Robertson
>> With a central web site like this, the OSD could also provide
>> additional information to the users such as firmware updates, etc...
>
> A better approach to this would be to simply have an infrastructure in
> place on the OSD for fetching the actual flv files that is based on
> some kind of virtual file system and plugins.
This is a long mail. I was wisely advised to provide an executive
summary by nerochiaro, so here it is.
A proposal for an abstract content browser that:
* Provides a single API for browsing many content sources.
* Supports tree and parameter browsing, and searching.
* Allows for one-touch Xim search (Joe's Xim vision).
* Is extensible.
* Will allow new sources to be supported in days, not months.
* Can be tested and integrated in small sections.
* Complements YouTube, UPnP, and iPod projects.
Pretty much anything can be supported as a source. Off the bat, without
changes to nmsd, it should enable:
* iPod, with parameterized browsing and searching.
* xmms2 library, with the same.
* UPnP, with the same for both video and music.
* Any flash video site that can be screen-scraped.
Okay, here's the details.
* Content Selection *
Usually, we access our media by one of three methods: the traditional
tree hierarchy used for filesystems; a parameterized query (think "paned
browser" in iTunes, Quod Libet and others), where media are selected
based on categories of metadata; and a search. The content selection
system (csel for now) will abstract all three methods of identifying
content, allowing each method to be used seamlessly across dozens of
sources.
** Selection Plugins **
The actual implementation of any of these three interfaces resides in a
selection plugin. For example, if I'm implementing a simple filesystem
browser, I would choose to implement the tree browser, but not the
parametric browser. The tree browser would be little more than a
wrapper around readdir and friends. A search interface would be optional.
If I wished to provide a YouTube plugin, I would instead omit the tree
interface as it is pretty meaningless. The parametric interface would
allow selection of the things currently done by the YouTube browser -
timeframe of "Last Month", category of "Comedy", etc.
Searching would also be parametric. Of course, the default search would
be a simple "text" match, which may be interpreted whatever way a
particular plugin wants to (YouTube could run a search; filesystem
browser could do a case-insensitive, space-tokenized find). However,
plugins may support alternative parameters. For example, a music
library may accept an "Artist" search. More interestingly, so could
YouTube.
That last point is perhaps the most important. Let's elaborate.
** Parameterization for Search and Selection **
A plugin must provide a callback to inform a program which parameters it
supports, both for parameterized selection and for searching. A
hypothetical is necessary here, so let's use the example of an iPod.
Newer iPods support both music and video; it would seem, at first
glance, that there should be two different plugins (or at least sets of
parameters) for the two types of content.
In fact, there are - sort of. If a user wants to listen to music, she
plugs in her iPod, goes to the music player, and starts looking for
content. The iPod plugin is now active. The music player's selection
window appears. She chooses to select by parameter, and browses to the
"Artist" tab. She selects Pinback, then flicks over to the "Album"
selector and starts playing their new leaked release, Autumn of the Seraphs.
Behind the scenes, the music player requests the values for the
parameter "Artist". All of the selection plugins which support the
"Artist" parameter, like the iPod, respond with a list of possible
values to choose from. But no videos are selected here, because the
iPod selection plugin knows that videos shouldn't be selected by
"Artist", and neither does YouTube. When the user selects Pinback for
Artist and switches to viewing Albums, Csel is queried again, but with a
restriction on Artist. Each plugin in turn responds with whatever it
had available, and so on. Straightforward stuff.
Here's where the magic happens. On the "Now Playing" screen, the user
highlights "Artist: Pinback", hits the Xim button, and chooses "Search
for this artist...". A search results box pops up (it would be a
standard widget like the filebrowser), and the user is presented with a
list of sources that could be searched - the local xmms2 music library
(wrapped by a selection plugin), the iPod, YouTube, Last.FM Recommends...
The user selects YouTube and in seconds is watching a Pinback music
video on YouTube. After it finishes, she opens up the "Playback
History" dialog box from the YouTube browser, scrolls down to "Artist:
Pinback, Album: Autumn..." (recognizable because it had the Music Player
icon next to it), hits enter, and is back at the music player.
Behind the scenes, when she chose to "Search for this artist", Csel
identified which searches accepted "Artist" as a search parameter. The
author of the YouTube plugin, knowing that YouTube often had
music-related content, accepted "Artist" as a valid parameter
(internally, the plugin simply shunts "Artist" arguments to the full
text search engine, but of course this is source-dependent behavior).
The search history is a simple mechanism, and can be implemented
independently of Csel. When a search is performed, and an application
wants to save the search to history, it calls a cooler function to push
that search on the history stack. It passes its own application ID, a
string telling that application how to repeat the search, and a string
for displaying the search to humans. The "history" dialog knows how to
take app ids and launch the respective program with the saved search.
In this way, we leave whether or not to save a search entirely up to an
application.
*** So, what parameters are available? ***
There's no chance that I would be able to successfully predict what
parameters would be needed or available. I doubt any one of us could
imagine how the internet will categorize the next wave of content. So,
aside from one reserved word ("text", for searching based on some text)
and a few restrictions on syntax (only lowercase letters, dashes,
underscores, and numbers permitted), we leave the selection of
parameters entirely up to plugin authors.
Because most forms of content we have now rely on common sets of
parameters - for example, most music can be identified by "Artist" and
so on - I firmly believe that a sensible set of parameters will emerge
via consensus. And, of course, program authors can choose which
parameters to query and which to ignore.
Some parameter values, like the "timeperiod" value of YouTube (last
month, last day, all), are not rigidly defined, and their implementation
may vary across sites. However, again due to the convergent evolution
of the Internet, I believe that most of these parameter values will be
largely compatible across content sources. It is the responsibility of
the plugin and program authors to reach a consensus on these matters;
usually it'll be the right of the first author, or the most motivated,
to decide these things.
** How Csel identifies content **
Csel, despite its fluidity and extensibility, has a very simple output
schema. For each selected source of content, it outputs three things: a
content type (integer), a content UID (string), and a content URI (string).
The content UID is, in theory, opaque; it's used as an argument to a
method to obtain metadata about a particular content item. The metadata
system is based on the same "let the coders decide" mantra as above; no
restrictions are placed on what's in metadata by Csel itself, but
instead will be naturally developed depending on a plugin's application.
For example, music of course would have metadata information like
"Artist" and so on. YouTube clip metadata could contain a link to the
clip thumbnail, ratings, related videos... Any plugin author wishing to
implement the features of the YouTube browser merely has to identify
what parameters are required for browsing and which metadata entries to
populate for things like related videos.
The content URI is what actually gets passed to the 'source' plugin.
More about that below.
** Csel Architecture **
I'm pretty convinced that Csel must be implemented as a Lua daemon.
Yes, Lua.
Yes, a daemon.
*Yes,* a Lua daemon...
Why Lua? Most of the cool plugins that could be implemented will have
to deal with HTTP, XML, and so on. Most of the plugins that handle huge
quantities of data - the large music library plugins, for example - will
be mostly in C anyway, and unaffected by the Lua wrappers. Lua
therefore gains us massive ease of use by programmers without
sacrificing much speed, because the most CPU-intensive areas are still
in C. If you're not convinced, try writing a screen-scraper in C, then
do the same in Lua. You'll know the difference.
Furthermore, the small speed penalty we'll get for doing some
light-weight tasks in Lua can be further offset via LuaJIT, should it
become important later on.
Why a daemon? Initialization cost for this system will far outweigh the
couple of dozen of KB this app should take up, excluding shared
libraries. Leaving it running will increase system speed. Furthermore,
some plugins need to "spool up" before they can be used. For instance,
SMB browsers must spend time scanning the network before use. Running
as a daemon negates that time for every access but the first (which
would ideally be started as soon as the daemon loads). Finally, Lua has
some features within its garbage collector that could allow us to cache
data for short periods of time without worrying about manually releasing
that data, again increasing speed over integrated code. In essence,
daemon == speed.
** Communicating with the Csel daemon **
My nipc system should function well for this purpose, but that is far
from the only possibility. If someone has a better suggestion, please
name it.
* Content Access *
Of course, supporting formats like HTTP for content will require a few
changes to nmsd. I believe this solution has minimal impact and can be
implemented cleanly, quickly, and extensibly, particularly since most of
the infrastructure for this work is already available.
The URI isn't anything particularly unusual - "file://path/to/file" or
"http://domain.com/file.ext". It will get picked up by a slightly
modified nmsd interface, which will parse the header and route it to an
appropriate "source" plugin. The "input" plugin (or the default input
handler) then does what it currently does - reads and assembles the
headers from the data provided by the "source" plugin, and then presents
more data when requested. Thus, a .divx decoder wouldn't have to be
rewritten to support streaming divx from HTTP, then again from UPnP, SMB...
For now, the system can and will simply use FUSE for everything, and
until we're ready the "URI"s will be raw filesystem paths. I'm only
passingly familiar with the way input plugins work, so I should not be
the one to author this API (or, at least, not right now).
I'm dual-wielding fire extinguishers, so flame away.
Steven
Joe Born
> This is a long mail. I was wisely advised to provide an executive
> summary by nerochiaro, so here it is.
>
> A proposal for an abstract content browser that:
>
> * Provides a single API for browsing many content sources.
> * Supports tree and parameter browsing, and searching.
> * Allows for one-touch Xim search (Joe's Xim vision).
> * Is extensible.
> * Will allow new sources to be supported in days, not months.
> * Can be tested and integrated in small sections.
> * Complements YouTube, UPnP, and iPod projects.
>
> Pretty much anything can be supported as a source. Off the bat, without
> changes to nmsd, it should enable:
>
>
I'm quite confident that the future of the OSD is found in the type of
plug-ins that something like this could enable.
I can't tell you how excited I was to compile wget on the OSD... that is
until I figured out that I couldn't integrate it in the UI (with my
meager skill level). What I wanted to do is simply create a box that
could allow the grandparents to automatically download videos of the
grandkids. It's a simple thing, but think of how powerful it would have
been! Now the grandparents can watch their grandkids on TV whenever
they want.
But the grandparents don't have such a device, and the reason is not any
deep technical obstacle, but the lack of a simple way for someone like
me, and I suspect there are lots of folks like me, to implement creative
stuff on that (fetching + web database + interactivity) level. If we
can unlock that, we'll really have something!
Michael Gao
sense in terms of code reuse, expandability. Instead of Lua Daemon, I
tend to believe a C Demon is better while certain plugin can be written
in Lua if performance is not an issue?
To get this done, I'd suggest to create a browser2 application to work
with the Daemon and plugin framework, once it is shaped up with file
browser(and iPod browser?) working, browser2 will replace current file
browser application, and we'll start from there to extend it, by when
the details like how this Csel Demon system works with Nano-X etc are
figured out and working.
Thanks,
/MG
Tom Bruno
> What about MythFlash. This might be a nice way to link the OSD to a
> MythTV server.
>
> http://www.mythtv.org/wiki/index.php/MythFlash
>
> The plug-in works by allowing a user to convert a recording to a flv
> using ffmpeg and then use the provided flvplayer to play the recording
> remotely in any flash browser. With a bit of php code, the plug-in can
> be made to list all available flv files that the OSD can then digest
> and play. I don't know whether the OSD YouTube plug-in will be able to
> handle the resulting large flv files. Will it be able to buffer so
> much data?
>
I know this post is days old, however i thought I would note that Mythtv
can transcode its files to open formats that the OSD can play. Why
would you want to convert to closed limited format like FLV. Instead
have a small client to the Mythtv backend than can play the files in the
original quality and format.
alex
available flv files, you can watch the movies real time or almost real
time from anywhere in the world. The OSD can act as a client allowing
you to watch your recordings on the go. Since the flv playing and
encoding (on the mythtv) capabilities are already there, chances are,
just the way the OSD receives its content will need to be tweaked.
alex
Tom Bruno
> If you were to have a remote mythtv server that can encode and list
> available flv files, you can watch the movies real time or almost real
> time from anywhere in the world. The OSD can act as a client allowing
> you to watch your recordings on the go. Since the flv playing and
> encoding (on the mythtv) capabilities are already there, chances are,
> just the way the OSD receives its content will need to be tweaked.
>
Right, my point was, why flv? why not divx, mpeg, xvid, or any of the
other formats that the OSD fully supports and that are much more open
than the closed FLV format.
alex
connected to and recording their cable. I already convert all my
recordings to flv so that I can watch my favorite shows in any browser
using a flv player. Making a second encoding to another format would
be annoying and would take up unnecessary space.
Other than that, I have no objections to other formats. Flv is just
convenient for me. The added benefit, is that in case I don't have the
OSD with me, I can still watch shows real time in any browser.
I think it would be a nice feature to claim that the OSD can act as a
remote client to MythTV content, however it does it.
alex