http://uriplay.org/about/overview/
URIplay aims to restore simplicity to the experience without reducing choice. We compile and publish metadata files listing the URIs at which content can be played. Each URI is described in terms of media data format, revenue model, and restrictions applied. Developers will be able to use this information and our open API to refer precisely to the content and select appropriate URIs for their users.
Showing posts with label Media. Show all posts
Showing posts with label Media. Show all posts
Thursday, July 9, 2009
Wednesday, July 1, 2009
FUSE Filesystem Suggestions
http://sourceforge.net/apps/mediawiki/fuse/index.php?title=Filesystem_Suggestions#MEDIAFS
MEDIAFS
File system that demuxes and exports frames for multimedia streams, for example animated .gif, .avi and .ogg files, etc. Somewhat like tar:/ and audiocd:/ under KDE. So for example mounting demo.avi on /mnt reveals /audio and /video, files describing the container and format, resolution, channels, chapters/indexes, and the title. /audio contains the tracks converted to trackN.wav, trackN.raw (unconverted stream), and files describing the format of the raw streams. /video contains trackN.YUV (stream of uncompressed frames), trackN.raw, files describing the raw format, and /frames. /video/frames contains timestamped .YUV and .PNM files, maybe even .JPG could be thrown in since the source is already FFT encoded it would be a pretty lightweight operation.
Write support would turn standard shell tools into a non-linear multimedia editing suite. ;-) Obviously write support would be easier to implement on an HUFFYUV/WAV formatted .avi file, which is pretty standard for video editing anyhow.
I admit that all of this can be achieved by using mplayer and co. to extract the media file into a directory, work with the decoded files, and then re-encode the file, but I think this functionality is needed and reusable by a number of programs, from Konqueror (thumbnailing, previews) to biff, and pretty much any media player/editor.
It could easily replace a large number of the programs in use today. It would become an API for multimedia work, hopefully help join the forces working on multimedia APIs in general, make codec inclusion transparent to the apps, etc. Also while this sounds naive compared to mboxfs and other brilliant user-space re-interpretations of metadata and namespace views, media streams are generally simple linear storage containers, much larger in size than typical email, and therefore much more relatively efficient to look at through a mount.
SerhijStasyuk says: IMHO better to implement this via Hybrid objects.
MEDIAFS
File system that demuxes and exports frames for multimedia streams, for example animated .gif, .avi and .ogg files, etc. Somewhat like tar:/ and audiocd:/ under KDE. So for example mounting demo.avi on /mnt reveals /audio and /video, files describing the container and format, resolution, channels, chapters/indexes, and the title. /audio contains the tracks converted to trackN.wav, trackN.raw (unconverted stream), and files describing the format of the raw streams. /video contains trackN.YUV (stream of uncompressed frames), trackN.raw, files describing the raw format, and /frames. /video/frames contains timestamped .YUV and .PNM files, maybe even .JPG could be thrown in since the source is already FFT encoded it would be a pretty lightweight operation.
Write support would turn standard shell tools into a non-linear multimedia editing suite. ;-) Obviously write support would be easier to implement on an HUFFYUV/WAV formatted .avi file, which is pretty standard for video editing anyhow.
I admit that all of this can be achieved by using mplayer and co. to extract the media file into a directory, work with the decoded files, and then re-encode the file, but I think this functionality is needed and reusable by a number of programs, from Konqueror (thumbnailing, previews) to biff, and pretty much any media player/editor.
It could easily replace a large number of the programs in use today. It would become an API for multimedia work, hopefully help join the forces working on multimedia APIs in general, make codec inclusion transparent to the apps, etc. Also while this sounds naive compared to mboxfs and other brilliant user-space re-interpretations of metadata and namespace views, media streams are generally simple linear storage containers, much larger in size than typical email, and therefore much more relatively efficient to look at through a mount.
SerhijStasyuk says: IMHO better to implement this via Hybrid objects.
Wednesday, October 10, 2007
Sony IMX proxy filter graph
Errore sul player Unreal:
No description on Streaming Server console:
IMX MPEG4 correct filter graph on streaming server machine:
Wednesday, October 3, 2007
HTC Trinity P3600 with Unreal Streaming Server
Device: HTC P3600 (Trinity)
OS: Windows Mobile 5
Player: Unreal Media Player 2.00.62 & WindowsMediaPlayer 10 Mobile
Server: Unreal media Server v.5.5 Single Site License
Playing a WindowsMediaFile:
Playing an MPEG2 file:
OS: Windows Mobile 5
Player: Unreal Media Player 2.00.62 & WindowsMediaPlayer 10 Mobile
Server: Unreal media Server v.5.5 Single Site License
Playing a WindowsMediaFile:
Playing an MPEG2 file:
Playing the same file throught MMS protocol:
Subscribe to:
Posts (Atom)