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.