The issue here is that we do not handle application mime types. I am not familiar with this mime type, but if he want to get it to play using Quicktime, as it did before, he should set the mime type to video/*. Then it will be handled by Quicktime. I am a little hesitant to modify the code to allow quicktime to handle this mime type without investigating this further.

-Sam

MEDIA_SIZE of 0x0 is the special value that asks for the native resolution of the media.

What it looks like (for the image) is that it gets squished down in size and aligned bottom left.
It also looks like it has has about 3/4 of the pixels dropped.

The same occurs for the smil files.

On my next chance to test, I will try setting the MEDIA_SIZE to 0x0, but I did try setting the media size to 512X512, but it didn't seem to affect the image positively as far as resolution went, only in size on the texture.

I had also tried setting the mime type to "video/quicktime" but this didn't make them play any better. I will try "video/*" on my next trial run.

Comment or uncomment as needed to run the particular test you want to see. If you run the test that uses an agent key, you will need to change the agent key to your key (I was testing on group owned land so I couldn't use llGetOwner).

Note, the current test script contains lines using PARCEL_MEDIA_COMMAND_SIZE,0,0 and PARCEL_MEDIA_COMMAND_TYPE, "video/*" so using these commands did not work either.

http://www.w3.org/TR/2005/REC-SMIL2-20050107/smil-modules.html#smilModulesNSSMIL20MimeType

A HEAD check of the two urls posted confirmed image/jpeg and application/smil as the mimetypes.

HEAD http://www.silverstreamnetwork.com/media_test/one1205451892.smil HTTP/1.0

HTTP/1.1 200 OK
Date: Sat, 15 Mar 2008 16:00:53 GMT
Server: Apache
Last-Modified: Fri, 14 Mar 2008 02:33:45 GMT
ETag: "d9392a-8e8-47d9e409"
Accept-Ranges: bytes
Content-Length: 2280
Connection: close
Content-Type: application/smil

Connection closed by foreign host.

Is it a server issue that would just take too much time, or is it a viewer QT wrapper issue that can be worked on through the open source?

Is it a Quicktime issue that isn't really in LL responsibility?

Does this mean that the new media features aren't going to be released, or are you planning to release them in the official viewer without fixing this?

Any extra information that can be provided would be greatly appreciated as continuing without fixing this definitely breaks a number of our products, and I'm sure a number of other people's as well. If you have some alternate options that might be available, that would also be greatley appreciated.

'Yes we know its broke and we did it, but it will stay this way'.

It doesn't matter how many business's rely on the very technology innovated and invested in to make SL a BETTER place, that has attracted those companies and individuals that have increased the sizeable cashflow to LL, it seems a very careless attitute.

Strip away all the innovations created by technology and expertise of such systems introduced at NO cost to LL and what do we have? A Platform riddled with bugs, unable to see the good work that so many have been and are doing, offering trade and commerce, struggling against the stacked odds of those that are shortsighted and unfortunately in control over the overal platform.

Your World, Your Imagination?.... or is it Our (LL) World, Your Limitation?

I guess you have far more important things to do, like introduce looping media, or tear off menus, a Dazzle Client that is as useful as a handbrake in a canoe. Sorry LL... all these years of being in control, its about time it was taken away from you and elevated to a proper business.

If you change the image or smil size by just 1 pixel then it will be fine. This is possible the result of an incorrect < vs <= somewhere.

I will place 2 new URL's and some images to show how this issue is exhibited. The smil files that the URL's point to can be DLed, modified and then viewed easily to see more testing results.

I have also found that if you switch between URL's you may have to touch the device twice for the view to be updated with the new smil if you are setting the parcel media.

However, if you uncomment and use the section where it only plays for the agent key, it will occur right away.

Just wanted to add this info for those testing.

while ( texture_width < media_width )
{ texture_width <<= 1; };

I believe that this would take a 512 pixel movie and place it on a 1024 pixel texture when it should be on a 512 pixel texture.
I think that changing it to
while ( texture_width <= media_width )
{ texture_width <<= 1; } };
would fix this. Could anyone help me test this? I will try again to see if I can fix my viewer compile problems if I can.