Aa! Idea.

[Animaniac]

With the advent of newer container formats, it has become increasingly possible to place several different types of video and audio formats in containers, most notably Matroska and OGM. In the past, in order to decode an your run-of-the-mill AVI, an MPEG4 video decoder and an MP3 decoder sufficed; however, recent formats, which are usually distinguished simply by their extension and not by their contained media type, could contain any of a hodgepodge of different codec types.

It seems that the development of tools to create such "variety" in Matroska and OGM files has left the end-user experience quite confusing and unorganized. To someone unfamiliar with either format, but smart enough to know to install the "Matroska Codec" or "OGM Codec", the variety of different audio/video/subtitle formats available can be quite daunting. The different possible combinations are no longer able to be counted on one hand, as is the case with good old AVI. When someone receives a next-generation container file (through legitimate means of course), he/she could be completely lost on how to get the audio/video streams to play correctly.

Now, with my limited understanding of the underlying specifications and capacities of either format, I would like to propose a solution that I feel is [possibly] easy on developers , relatively easy on container overhead, and definitely easy on the user (this is my main sticking point). I understand that a "quick fix" for such concerns would to provide an information text file along side the media file to outline which combination of decoding software is needed; however, there is no guarantee that the common person will be able to understand and configure his/her system correctly with just this information. They may even break their system in the process...

In order to provide content consistency and integrity, a system needs to be devised on the container level to provide the appropriate decoders to the end-user. Now, it is widely understood that the majority of files are going to be [maybe not now, but eventually] played back on Windows machines. It's also understood, however, that other platform users, i.e. *nix users, would be above this problem, since the operating system mandates a certain level of computer intelligence and know-how. However, this does not mean that the following system cannot be implemented on other platforms--I am just unfamiliar with the relevant OS underpinnings.

Now that the problem has been clearly explained (and probably beaten to death), let me get into the heart of my idea--attachments. I know Matroska has the ability to store "file attachments," and while the specifications of such a feature eludes me, I'm sure there are people here that can fill the gaps. I am also not educated enough to know if attachments are possible in OGM (if not, I'm sure they could be implemented) and/or if it goes against the OGM model of being streamable.

Whether we like it or not, Windows users are our main clients, therefore, I believe that it would be best to describe this system using DirectShow as a model, since it will allow the most interoperability so that the user can use his/her favorite player.

1) I suggest that tools be created so that the appropriate DirectShow filters and Windows DLLs can be packaged and housed inside the container. (Side note: For a file that requires four such inclusions, the "overhead" of storing these files would probably on the order of 1 MB.) This is within Matroska specification, and possibly in OGM specification (please enlighten me here).

2) Next, I have a variety of ideas of implementation since obviously some will be better/more implemental than others:

a) A DirectShow splitter should be devised so that it is "Decoder packaging aware." Such a splitter would react to unconnectable pins (indicating the lack of a viable decoder) or to a mandatory flag set by the file creator to install the appropriate decoders to ensure a quality end-user experience. The splitter would then using a Windows scripting engine (possibly VisualBasic since it is the most widespread, or a scripting engine of choice installed with the Matroska/OGM install routine) install (via regsvr32) the correct decoders (in a temporary location), sets a flag, rebuilds the filter graph, and begins playback possibly with a small message saying the container dynamically compensated for missing decoders. Obviously, leaving the decoders installed after playback would be a terrible idea, so when the end user exits the player, or loads another file, the exiting/stopping routine of the splitter should include an uninstall script to remove any installed decoders. This subsystem should have the option of being disabled. The problem with this implementation is that it requires rebuilding a filter graph; however, it has the possibility of being the most seamless to the end user.

b) The "decoder package aware" DirectShow splitter provides the end-user with a message, upon failure to connect pins, indicating that codecs are packaged with this file. Along with the Matroska/OGM install package there is a program that will allow the "registering" of an MKV/OGM with the system. This program would look at the file and unpack the require decoders and uninstall them. The afore-mentioned message should tell the user to run this program. The program should also set a flag to remind the splitter to prompt the user, upon player exit/stopping/complete playback of the file, to run the program again to uninstall the codecs. This program could be a drag-and-drop implementation similar to the regsvr32 tools we love so much. Again, such a subsystem should be able to be disabled on the splitter level. The flaw with this implementation is that it relies on the end-user to do something, albeit a very simple something.

c) The Matroska/OGM complaint player is "Decoder package" happy, and implements its own system of handling such packaged decoders.

d) A combination of the above ideas.

e) [Insert your implementation idea here.]

At the end of the day, I know that all of us here would like that the average user have some standard understanding of Audio and Video, and be able to handle using the next-generation of files without any help, but, truth be told, the average user is quite clueless. Such a system would definitely speed up the uptake of these new formats we love so much. I feel that an effective implementation of such a system will actually be what will revolutionize this field, and not uber-container formats that only bedazzle the audio/video geeks. So, with that said, let the discussion begin! ^_^ I'm sure this idea can be extended, corrected, and improved!

P.S. Sorry about being so verbose, I just wanted to try and cover every angle. This idea is still a rough sketch since I just came up with it in my sleep... o.O; Now, I go back to bed. -_-;

[robUx4]

Well, yes it could be a nice feature to use matroska attachements for that. I'm not sure there are any tools so far to read/write them, but I know it works as it's the first thing I implemented :)

One other feature of matroska not used yet is that for each track you can put a text description and also attach a URL for that track. So on matroska.org we might create a friendly page for each codec we know/support and explain where/how it can be read on various platforms... Let's see if someone wishes to do that. Then this URL could be added for each track the muxer writes (of course, the encoder should be able to put his own URL instead).

[[Toff]]

I think it's a bad idea to remove the codec at end of playback. That mean i will not be able to play my poor not-embedded-decoder-aware avi files :D
Just 1 idea, when installing the codec, the "installer" update the codec if it's already installed, or just install the codec normally if it's not already on the system.
And the codec is not removed at the end.

Another comment, it's a pretty bad idea to have this job done by the splitter, a filter must not insert/remove other filters this is the job of the graphbuiler or application.
So it could be done by a third party program, or maybe by the player, or the player could start the third party program on the file berfore really opening it.

Finally, the problem of viruses, which is not really solvable. Unless you have a way to identify the file and that you trust the author.

[Teegedeck]

Originally posted by [Toff]

Finally, the problem of viruses, which is not really solvable. Unless you have a way to identify the file and that you trust the author.

That was my first thought, too, when I got an impression what was possible with EBML. There's already enough scriptable, interactive stuff around that one has to be careful about. So, while the idea of integrating the codec inside the container is nice (and I've read about such an idea before on this forum), I wouldn't touch it with a pole.

[celtic_druid]

For MKV, you can just right-click and look at the properties to see what streams it contains. What is so hard about that? Although if it were linked to an online database, containing info, links to required codecs/filters, etc. it would be much simpler for the average user.

Then once the user knows about the streams and what is needed to install for playback, they can make a decission to download and install or not.

[Animaniac]

Originally posted by robUx4
Well, yes it could be a nice feature to use matroska attachements for that. I'm not sure there are any tools so far to read/write them, but I know it works as it's the first thing I implemented :)

Great. Hopefully attachment tools are easy to code!

Originally posted by robUx4
One other feature of matroska not used yet is that for each track you can put a text description and also attach a URL for that track. So on matroska.org we might create a friendly page for each codec we know/support and explain where/how it can be read on various platforms... Let's see if someone wishes to do that. Then this URL could be added for each track the muxer writes (of course, the encoder should be able to put his own URL instead).

Although this sounds nice and dandy to experienced users, it will still prove quite confusing with the average user. I'm sure we've all experienced seeing the same questions over and over with regards to media in AVI, and all I see is this becoming worse as Matroska and OGM expand both technically and with their user base. In additioin, this is far from seemless to the average user.

Originally posted by [Toff]
I think it's a bad idea to remove the codec at end of playback. That mean i will not be able to play my poor not-embedded-decoder-aware avi files :D

Well no, this will just install the temporary codec to be used with this specific file. If another codec exists on the system with the same media type ID (sorry don't know the technical term), it should just be tempoaraily disabled and reenabled on exit. The underlying notion here is that the codec is loaded just for the file and just used when playing that file.

Originally posted by [Toff]
Just 1 idea, when installing the codec, the "installer" update the codec if it's already installed, or just install the codec normally if it's not already on the system.
And the codec is not removed at the end.

That is also an option, and I had thought about that, but it lead me to realize scenarios similar to those created by imfamous codec packs. After playing several files with such a feature, the user's system could become mired in many many codecs he/she does not need. Furthermore, there's not telling how experience the file encoder/creator is, so it's much safer to uninstall anything at the end.

Originally posted by [Toff]
Another comment, it's a pretty bad idea to have this job done by the splitter, a filter must not insert/remove other filters this is the job of the graphbuiler or application.
So it could be done by a third party program, or maybe by the player, or the player could start the third party program on the file berfore really opening it.

Yeah, I agree it goes against DirectShow rules. That's why I like idea (b) above best, since it relies on a third-party program, and leaves the user with the option of keeping the codecs.

Originally posted by [Toff]
Finally, the problem of viruses, which is not really solvable. Unless you have a way to identify the file and that you trust the author.

Well, any file, including MKVs could be viruses in disguise, and there's nothing that can really be done about it. I agree that such a feature could be easily exploitable, but if someone were to want to infect systems using MKVs they can do it already. -_-;

Originally posted by celtic_druid
For MKV, you can just right-click and look at the properties to see what streams it contains. What is so hard about that? Although if it were linked to an online database, containing info, links to required codecs/filters, etc. it would be much simpler for the average user.

Then once the user knows about the streams and what is needed to install for playback, they can make a decission to download and install or not.

Again, this is a feature that makes life easy for the average user, which in any argument needs to be depicted as dumb as a rock. -_-; This idea sounds all well and good for us, but the average user may not even think of having the shell extension installed, let alone what it is and how to use it. The average user doesn't like to do extra leg work either, and some are wary of installing anything at all, so we should be happy that they've installed our Matroska or OGM package. Of course options to install packaged codecs should be present, but having the user do any work is what this idea tries to eleminate, so most tend to mess up and go post on forums without searching and write nasty e-mails. ^_~

I'm not sure if I made the basic premise clear. Each format needs to ensure out-of-the-box playback in order to be accepted by the masses. AVI got around this problem for the most part because the required decoders were packaged with the OS, or there was just one more needed, namely MPEG4 video. And as more formats are added to Matroska/OGM specifications, this becomes a bigger and bigger problem. It would be absurd to have all these codecs installed with an initial installation package, that's why I thought this file-specific, à-la-carte option would be best.

[Danzel]

IMHO, wouldnt it be better if there was like some text inside the matroska file sayings what format the streams are, then the splitter could pick up what codecs are needed and if the video failed to play it could tell the user what filters they are missing?

Or, you could right click on the tray icon of the splitter (i dont know if mkv has one, i haven't played with it yet, but from my OGM experiences..) and then choose an option like stream list, and it would tell you the format there.

This would be a useful feature IMO.

Danzel.

[Animaniac]

Originally posted by Danzel
IMHO, wouldnt it be better if there was like some text inside the matroska file sayings what format the streams are, then the splitter could pick up what codecs are needed and if the video failed to play it could tell the user what filters they are missing?

Or, you could right click on the tray icon of the splitter (i dont know if mkv has one, i haven't played with it yet, but from my OGM experiences..) and then choose an option like stream list, and it would tell you the format there.

This would be a useful feature IMO.

Danzel.

Yeah, that would be useful for people that know what they're doing. Unfortunately when these formats pick up pace, the people that will be using it won't know what they're doing, and this would not be an option. The basic premise is to provide seamless, out-of-box playback without having the user do anything and thereby eliminating serveral errors and problems created by the user. I guess this is an idea you can only understand after trying to help people use such formats. The questions never end, and they repeat themselves over and over. Therefore, the only solution is to remove any step where these problems arise, which is always at the codec stage.

[jcsston]

Originally posted by Animaniac
Great. Hopefully attachment tools are easy to code!
The latest version of the Matroska Shell Ext can list and open (exe's run, txt opened with Notepad, ...) attachments in MKV's :)
And the LemAPI Matroska Writer has code to write attachments but no user interface for it yet ;)

[[Toff]]

Originally posted by robUx4
Well, yes it could be a nice feature to use matroska attachements for that. I'm not sure there are any tools so far to read/write them, but I know it works as it's the first thing I implemented :)
Hehe jcsston is already using that to embedd is avisynth script using a modified vdubmod version.

Originally posted by Animaniac
Well no, this will just install the temporary codec to be used with this specific file. If another codec exists on the system with the same media type ID (sorry don't know the technical term), it should just be tempoaraily disabled and reenabled on exit. The underlying notion here is that the codec is loaded just for the file and just used when playing that file.
IMO You can't (easily) temporarily disable a codec.
And what do you do of the codec settings ? do you remove them also ? maybe they will not be compatible with the new/old embedded codec. And how you will restore them.
Unfortunately there is no common interface for that :(

Originally posted by Animaniac
Well, any file, including MKVs could be viruses in disguise, and there's nothing that can really be done about it. I agree that such a feature could be easily exploitable, but if someone were to want to infect systems using MKVs they can do it already. -_-;

Hmm i don't agree with this.
Automatically executing a program without the user agreement and without way to check the origin of the program is really bad!
And there is no way at all to do that in mkv ATM, unless you exploit an unkown vulnerability of the system.

IMO it's really a big problem.

[Teegedeck]

I go with [Toff]. Heavy integration of the operating system with multimedia applications is what brought us vulnerable OS'es. I know where I don't want to go today.;)

[jcsston]

Originally posted by [Toff]
Hehe jcsston is already using that to embedd is avisynth script using a modified vdubmod version.
:confused: , How could I forget that? I guess I'll soon be forgeting that I added FLAC muxing to VDubMOD ;)

IMHO The aspect of attaching codecs that are loaded on-the-fly is too dangerous because of viruses, also don't forget different platforms such as Linux, Mac, and prehaps Windows on Alpha.

[Tuesday]

@ [Toff] & Teegedeck

In this day and age with the general state of the internet and computing in general i think you can quite safly say its the users own fault if they dont have some kind on anti-viral software installed.

Integrating the decoders for media in the container has been something i have been hoping for for a long time, i regularly have to work with "the average user" and trying to explain why they have to install so many codecs/decoders is a real problem, especially if you dont happen to be easily available, ie making files available on the 'net. The amount of people who don't seem to acknowledge the existence of ReadMe files is astounding!

The potential benefits of this solution, ie out-of-the-box easy play back easily out way any viral threat.

Concerning other OS's/CPU's, the person encoding the file can be given the option of which decoders to include, stating which OS the file will play under is alot more user-freindly than describing which codec combo is required...

[ChristianHJW]

It was always my dream and wish to have a central MKV download server, based on the matroska codec IDs, and i still believe its the better option to attaching codecs to the movie, because you always deliver the latest codec this way ....

[Atamido]

I think that we could add a little button to the ShellExtension that contacted a central server to see what files need to be downloaded to playback certain tracks. That should be easy. One of the problems is, of course, keeping the list updated.

[Phanton_13]

This isn't a bad idea, but for the viruses is very dificult to find without an antivirus instaled, but in de sourcecode is more simple to find a suspictous code, we only ned to find a disc acces ore a not allowed sistem call, this idea if bad for a non opensource decoder but if we have a opensource decoder we can implement a especial compiler and only alow a code building when this only use the codec interface, and in the codec interface is neded the existence a metode to store a setings, this isn't dificult to obligate the setings are stored in XML style file, when the codec is used a asambler optimizitations isn´t dificult to restrict this optimization to MMX, SSE,SSE2... only, the ironi of this is: we sacrificate time to install but we can have a crosplatforms implemetation of de codec. This implementation is good for use in conbination with UCI.

[Animaniac]

Originally posted by Pamel
I think that we could add a little button to the ShellExtension that contacted a central server to see what files need to be downloaded to playback certain tracks. That should be easy. One of the problems is, of course, keeping the list updated.

I'm keeping an up-to-date list (http://forums.animesuki.com/thread.php?threadid=6697&sid=) at an anime message board, and I could doe something similar to it for Matroska, maybe even put my PHP/MySQL skills to good use.

After reading through these replies, I think the best solution would still be to have a mechanism to install codecs automatically; however, they should not be packaged with MKVs. Instead, a third piece of software independent from the splitter and player, should be able to take Matroska/OGM(/AVI?) files, contact an online database and provide the user with up-to-date installers. After this system is proven effective, maybe even player integration would be a viable option. The drawback here is that as these containers' user bases grow, the server may or may not be able to handle such load. Though I'm sure there's still some time for this to happen.

[robUx4]

OK, what you need looks like WMP downloading automatically the needed codec and then play a file (never worked with Quicktime;) ). It can easily be done in TCMP or MPC (and probably the others too). We just need a web place to centralize all the known Codec ID/decoders for each platform/system and it will be easy to download them and install it on the fly before playing the file. Nothing is needed more in the existing matroska files to do that.

It is a bit harder to do with the Shell Extension because you don't know if the user uses a DirectShow based app, VLC or MPlayer. But it wouldn't be hard to detect all these players and install codecs for each (if they are not already installed).

We could make a simple DLL that do just this : you give it a matroska CodecID + CodecPrivate (usefull for VCM/DShow based codec recognition) and it installs the up-to-date codec for all player (if they are not installed).

There might be some problems choosing which MPEG4 decoder to install/use (there are so many).

Maybe the interface to do that in WMP for AVI could be found (Gabest ?) and then we could hack it and use the same system for matroska.

[Animaniac]

Originally posted by robUx4
OK, what you need looks like WMP downloading automatically the needed codec and then play a file (never worked with Quicktime;) ). It can easily be done in TCMP or MPC (and probably the others too). We just need a web place to centralize all the known Codec ID/decoders for each platform/system and it will be easy to download them and install it on the fly before playing the file. Nothing is needed more in the existing matroska files to do that.

It is a bit harder to do with the Shell Extension because you don't know if the user uses a DirectShow based app, VLC or MPlayer. But it wouldn't be hard to detect all these players and install codecs for each (if they are not already installed).

We could make a simple DLL that do just this : you give it a matroska CodecID + CodecPrivate (usefull for VCM/DShow based codec recognition) and it installs the up-to-date codec for all player (if they are not installed).

There might be some problems choosing which MPEG4 decoder to install/use (there are so many).

Maybe the interface to do that in WMP for AVI could be found (Gabest ?) and then we could hack it and use the same system for matroska.

WMP9 has something like that? I doubt they list ffdshow, CoreAAC etc. on it. Nevertheless, I don't want to touch WMP9 with a ten-foot pole. -_-; I never liked the shell extension idea, since it would be obscure to the user base I'd like to target with this idea. Integration on some level during playback is necessary, so before the user gets annoyed that file is not working, a solution is proposed by the player.

For MPEG4, ffdshow should be used of course. ^_~

Sounds like a plan! ^_^

[Teegedeck]

I stand by my point (sorry for acting like a spoilsport). I dislike software that tries to access the internet if it isn't a browser or a mail-client. Be it M$ products, Real or open-source. Paranoia? Perhaps, but I prefer no to open new potential security-holes in my system if possible.

[BetaBoy]

As robUx4 metioned we can easily add this to TCMP (we already thought threw the framework for this) the BIG qustion here is bandwidth. It's not technical at all. I can easily take www.CoreCodec.net and use this as a 'Central Codec Repository' as we had originally intented to do almost 2 years ago. This would not be limited to just TCMP but ANY media player who would support it.

The question is of sponsorship... Naturally I can probally count on Bez and Jordan at DXN to help... but what about the OS codecs, MS, etc?

I would really like to hear more ppl's thoughts on this.

----
Dan "BetaBoy" Marlin

[ChristianHJW]

I cant speak for OGM, but ( and we never made a secret about this ), we have added a kind of 'fallback system' to the matroska project to cover things like this.

AS you may know, our libraries ( libebml and libmatroska ) have been released under a dual licensing sheme, GPL and QPL. The GPL license means that EVERY opensource project thats using GPL as well, like Virtualdub and many others, can easily use libmatroska within the GPL license, and of course completely free. Same can be done from the few apps that use the QPL license.

However, there is always the possibility to license the libraries to closed source apps, such as Adobe Preimiere, Ulead VideoStudio, NeroDigital, Vegas Video, etc. . Of course, this is only going to happen if matroska would really become a wide used defacto standard. In this case, we could use the 'revenues' from the licenses to finance a central download server.

As matroska is an open standard also, there is always to possibility for a closed source app that they code their own library, and they are fully free to do this ( matroska specs are copyrighted, but free to everybody, and in the very moment they were published under this free license they became public domaine also ). But its maybe better for companies wanting to support matroska to use the official library and pay some 'minor' licensing fees to matroska association ( still to be founded ). Or they hire Gabest for this job, and he writes them a new lib in 2 days :P .....

[Schultz]

Well right now Media Player Classic can kind of do that. If you attempt to render a Avi file where the audio or video cannot render then you get info about it and a choice to look it up on the net witch then points to
http://gabest.org/codec.php?type=1&guid={30355844-0000-0010-8000-00AA00389B71}
which is an Example of a Avi file without decompressor for DX50 and it then lists known decoders that the user can then go, download and install to get the video files working..

[dano5050]

Originally posted by Teegedeck
I stand by my point (sorry for acting like a spoilsport). I dislike software that tries to access the internet if it isn't a browser or a mail-client. Be it M$ products, Real or open-source. Paranoia? Perhaps, but I prefer no to open new potential security-holes in my system if possible.

as a frequent traveler too, either airborne or sometimes down in the jungle in central or latin america for business... i can remind you how nice it would be to have a standard that was able to deliver a self-contained content and decoding package, where you always knew you had everything you needed.

1MB overhead for every 700MB or perhaps 2x700MB? that's about .1% overhead to ensure perfect playback everytime. heck ... load the codecs in and unload em ... or just make that behavior configurable.

now not all clips are 700MB long... certainly you also want the format to be lean enough to support sending a 1MB video clip as an email attachment without a lot of overhead (certainly w/o 100% overhead!!) .... perhaps there it makes more sense to encode the file w/ out the codec attached, and simply use the URL reference.

could both solutions be provided for?

[Mug Funky]

it would definitely be cool to have a CDDB style _trusted_ place to put codecs and have them download _if you tell it to_

the virus issue is still there of course, but i'd not worry about that too much - in my experience you only get a virus if you go download something you shouldn't (paging rule 6...).

even the least savvy computer users are protecting themselves these days. you really can't afford not to. and besides, media files have a certain amount of natural selection to them - generally if you have the knowhow to source them (through whatever means) you also are aware at least in part of possible dangers involved and ways of preventing them.

it would be cool for some up-coming media environment like CoreAPI to allow embedded codecs in a way that prevents inadvertent security problems - it could be written specifically not to allow certain procedures to execute, and it could be designed to decode straight from inside the container rather than installing first to a different location.

[Prettz]

I personally would never use a container format that allowed executable code of any kind to be embedded into it (no matter how seemingly-benign and safe it is, because people will ALWAYS find a way to exploit it). I also would not use a container that allowed websites to be automatically opened up (because someone could always make a file send you to a malicious website).

A special tag field in the file (which might be made to stand out from all the other tag fields) where the encoder can put exactly what codecs were used, where they might be found, and any other tips for proper playback, is probably the best solution.

edit: on a related note, ever notice how indescribably annoying it is when Real Player or Quicktime Player announce that they are downloading updates? I especially love how Real Player will always somehow determine that a newer version is available, and will refuse to play ANYTHING until you completely update the entire player (and it will tell you that the updates are "necessary to play back the file" when that is a boldfaced lie).

[Neo Neko]

Are we making this harder than it should be? Microsoft blessed us(albeit verry belated) with the ability to have file names that contain 255 characters. Sure Microsoft was the last company to implement this in their OS. And windows users continue the tradition with being the last group to think of putting this to good use.

I have a system that will work with any container format that has ever existed on any computer system anywhere at any time. And best of all you don't need a program to decode it for you. Let's pretend for fun you have an AVI file with Xvid video and AC3 audio. It would look something like this.

"My movie(Xvid AC3).avi"

With those two words any novice googler could not only turn up info about the codecs used but the codecs themselves.

Now lets get really wild and pretend we have a Divx video with both MP3 and AC3 audio in an OGG container.

"My movie(Divx AC3 MP3).ogm"

With matroska you could go even further and stor the info as comments!

[Neo Neko]

Originally posted by dano5050
as a frequent traveler too, either airborne or sometimes down in the jungle in central or latin america for business... i can remind you how nice it would be to have a standard that was able to deliver a self-contained content and decoding package, where you always knew you had everything you needed.

1MB overhead for every 700MB or perhaps 2x700MB? that's about .1% overhead to ensure perfect playback everytime. heck ... load the codecs in and unload em ... or just make that behavior configurable.

now not all clips are 700MB long... certainly you also want the format to be lean enough to support sending a 1MB video clip as an email attachment without a lot of overhead (certainly w/o 100% overhead!!) .... perhaps there it makes more sense to encode the file w/ out the codec attached, and simply use the URL reference.

could both solutions be provided for?

If you want movies that play themselves checkout geexbox or movix. Geexbox is only 4Mb extra could you spare 4Mb? Geexbox provides every bit of software you need to play movies on a PC. It even provides the OS and the drivers not to mention the player software and codecs.

[dano5050]

Originally posted by Neo Neko
If you want movies that play themselves checkout geexbox or movix. Geexbox is only 4Mb extra could you spare 4Mb? Geexbox provides every bit of software you need to play movies on a PC. It even provides the OS and the drivers not to mention the player software and codecs.

4mb is getting pretty chunky.

were you suggesting something for me personally, or trying to contribute in general to the conversation? certainly i'm aware that there are ways for me to accomplish this for my own purposes.

d.

[ProfDrMorph]

Originally posted by Neo Neko
Are we making this harder than it should be? Microsoft blessed us(albeit verry belated) with the ability to have file names that contain 255 characters. Sure Microsoft was the last company to implement this in their OS. And windows users continue the tradition with being the last group to think of putting this to good use.

I have a system that will work with any container format that has ever existed on any computer system anywhere at any time. And best of all you don't need a program to decode it for you. Let's pretend for fun you have an AVI file with Xvid video and AC3 audio. It would look something like this.

"My movie(Xvid AC3).avi"

With those two words any novice googler could not only turn up info about the codecs used but the codecs themselves.

Now lets get really wild and pretend we have a Divx video with both MP3 and AC3 audio in an OGG container.

"My movie(Divx AC3 MP3).ogm"

With matroska you could go even further and stor the info as comments!
You're forgetting that people keep getting more stupid every second even though one may think this process goes into the opposite direction.

Remembers me of the situation when I helped a guy getting a game to work on his system. I never even heard of that game before... but after he gave me the error message he got I found the solution to his problem by using Google. After I asked him why he hasn't tried that himself he told me that he did but doesn't know how to use search engines at all.

IIRC there was this funny thread here which was called something like "Guide on how to find the Search button".

See what I mean? The average person will still have problems even though to many others it's very obvious what to do.





I haven't followed the whole discussion ( the idea is not knew to me so I was a little bored after reading the first post even though it's quite good; I remember chatting with some other guys about this when someone came up with this idea for MCF ) but have you already thought about viruses/worms/trojans? Including possibilities for automatic installation of binaries can be exploited! With all the different methods for viruses to spread AntiVirus Software has already become quite complex. And the more complex a program becomes the more likely it contains which leads as to new problems.

IMO "error message tags" may be a could solution. The author of the file includes a simple guide on where to get the necessay software to play the file. The message is stored as ASCII or Unicode text and will only be shown by the player when there are problems with rendering the file.

[Neo Neko]

Originally posted by ProfDrMorph
You're forgetting that people keep getting more stupid every second even though one may think this process goes into the opposite direction.

Remembers me of the situation when I helped a guy getting a game to work on his system. I never even heard of that game before... but after he gave me the error message he got I found the solution to his problem by using Google. After I asked him why he hasn't tried that himself he told me that he did but doesn't know how to use search engines at all.

That's the problem though. It is useless catering to morons. That only begets bigger more obnoxious morons. These people "can" learn. You just have to make them. If someone does not know how to use a search engine what business do they have on the internet. That is a basic surviaval skill. It is something so basic it should be taught to children the same time they are being potty trained. The reason common sense is no longer common is because no one uses it.

We should not continue the tradition of Microsoft. This is a simple problem with a simple solution already in existance. We don't need new code or altered specs. Just a little bit of old fasshion grade school education. And we don't need to educate every last one of them ourselves. Remember that these people congregate with larger pools of ignorance. We only need to tell a few and they will go and tell their friends.

[Phanton_13]

I prefer intestead of add a compiled codec ad a source codec or a preprocesed code for faster compiling in C or D, they can use a ystem to add optimization for multiple platform an plain decoder, this is platform independent and is best, if this is suported for estanddarlone player they are hable to play new formats.

[Nibor]

Originally posted by Neo Neko
The reason common sense is no longer common is because no one uses it.
:) Wow, what a sentence!! (Well, at least for me, whose native language isn't English!)
Neo Neko, do I have your permission to add it to my signature?

[Neo Neko]

Originally posted by Phanton_13
I prefer intestead of add a compiled codec ad a source codec or a preprocesed code for faster compiling in C or D, they can use a ystem to add optimization for multiple platform an plain decoder, this is platform independent and is best, if this is suported for estanddarlone player they are hable to play new formats.

Whoa! Have you ever downloaded the source to any of these codecs?? It is generally quite a bit bigger than the compiled codec. ;) And in order for this codec to be compiled you would need a compiler. Which is out of the question for a standalone product. Besides that compiler options will not deliver the best fastest code possible. C is generally quite good but even it can be wanting at times. The way you write your code and the inclusion of assembly code can greatly speed up your binary for platform X. The only way for this to marginally viable would be if the code were packaged in an intermediary format. Not raw or system binary. Something like bytecode. Perhaps java even. Then all that would be required is an optimised java interperitor for system X which is much more acceptable.

Originally posted by Nibor
:) Wow, what a sentence!! (Well, at least for me, whose native language isn't English!)
Neo Neko, do I have your permission to add it to my signature?
sure.:cool:

[ProfDrMorph]

hmmm... Neo Neko, I like your attitude. :D Next time I'm starting to give up making the world a better place because I discover yet another impossible stupidity I'll think of you. ;)



I like that Java-idea but I'm rather unfamiliar with Java. I only know few things ( object-oriented, cross-platform compatible ) about it and one thing I heard about it is that it's rather slow. Is that just an old prejudice? Because with only bad/slow implementations to start with it get's more unlikely that someone is willing to take the task because the project may seem to become too big ( because you have to find people optimizing the tools you want to work with ).

[Phanton_13]

wen i meant a "preprocesed code for faster compiling" is like the java bytecode but isn´t java bytecode, the most important question is they are designed for fast & efficient compiling intested of are designed for interpretation, is like a intermedite language betwen C and the asembler an they size is rater low than the source size, if we can make a eficient intermediate language the compilation can be the better for compile it to any processor or achitecture, the posibility to ad optional asambler rutines is one of teh capabilities for best compiling ( SSE2, VE and some more in the dsp area ). But wat is 250k or 500K for a +700Mb movie?

The size nedded for a compiler in reality is very low (4K-2Mb), the bigger part off the size in GCC is not the compiler and only it's used for the libraries.

[Neo Neko]

Originally posted by ProfDrMorph
I like that Java-idea but I'm rather unfamiliar with Java. I only know few things ( object-oriented, cross-platform compatible ) about it and one thing I heard about it is that it's rather slow.

Well since it is not native machine code it will never run as fast because it has to be translated into machine code. But the perception that it is sloooooooooooow is largely due to Microsoft's poorly writen and verry outdated Java VM. To be quite honest having coded some java using Sun's JDK and JRE as well as several other VMs it is fairly fast and quite capable. There is no reason encoders and decoders could not be written in Java. If someone made a DSP geared to interpriting Java into machine code etc and passing it on to the other system DSPs for decoding it would be quite viable and not out of the question.

Originally posted by Phanton_13
wen i meant a "preprocesed code for faster compiling" is like the java bytecode but isn´t java bytecode, the most important question is they are designed for fast & efficient compiling intested of are designed for interpretation, is like a intermedite language betwen C and the asembler an they size is rater low than the source size, if we can make a eficient intermediate language the compilation can be the better for compile it to any processor or achitecture, the posibility to ad optional asambler rutines is one of teh capabilities for best compiling ( SSE2, VE and some more in the dsp area ).


Wow! That was a long sentance. ;) Why develop a new bytecode when Java's is more than adequate? In fact there are already several parts of the equation written in Java! There are Java based MP3 decoders as well as vorbis etc. We only need a few other audio formats and then some video formats. And IIRC java can decode some video already. .NET most definatly is not a good choice.

Originally posted by Phanton_13
The size nedded for a compiler in reality is very low (4K-2Mb), the bigger part off the size in GCC is not the compiler and only it's used for the libraries.

Those libraries are often heavily used though. And without them it would be rather hard to compile most code today. Without libraries you would not be able to complile much.

Something that is interesting as I understand it is that GCC has the ability to compile java code into native machine code with the addition of a library or two. I have never used it myself. But it is interesting.

[moogie]

to continue the java idea, if you implement the codec using the existing applet framework you will already be using trusted code (if digitally signed) or at least code which is heavily "sand-boxed" as to not be able to peform malicious tasks, such as accessing the local system or opening ports for communication.