object code enhancement

[Michiel.Schok]

It would be nice if the objectcode that MediaMosa returns via the /asset/{id}/play?response=object call not only returns an object that can play video, but also displays a still when the video is not started.

I think work has to be done:
* in the management interface, where we can define the objectcode, we need a new variable that provides the link to the still (e.g. {STILL_URL})
* the still_url has to be filled with a ticketlink to the default still

If multiple object definitions become possible (that's a trick one), the /play-call can be extended to select the object that the EGA wants to be used (with a still, without a still).

[Frans]

MUST HAVE

[MC-arjen]

When still images are generated from a video a size is given. Ideally the STILL_URI uses an image size with the same size as the object video code is. The /asset list however wants to use thumbnails, it is inefficient to use the same imagesize here. We want to introduce different sizes of a still.

ImageCache? ( http://drupal.org/project/imagecache) from Drupal provides the solution here. Preferably MediaMosa should generate a still with ffmpeg on the correct time (and takes also into account blackstills) with the same size as the video. Imagecache can provide the needed efficient sizes.

Considering the REST interface: this means a change from the size parameter from the still generation to the request of a image. We could maintain backward compatibility by storing the default display size to be used for the still-play call.

This needs to be discussed further.

[Michiel.Schok]

I'll start discussion via this ticket. If needed, discussion can continue f2f of course.

For SURFmedia, I envisioned the creation of 3 stills per asset, for diverse use-cases:
* original format of video, to be used in the 'object-player'.
* medium format: on search-pages we use approx 145x110
* small format: on some places we use approx. 86x65

I expected to use a mediafile 'tag' for this purpose, eg tag the three stills with 'smHigh, smMid and smLow' to differentiate. When issueing a REST-call to MediaMosa (e.g. the /asset search call) witch returns image-URLs, by default it returns image-URLs to the default mediafile. Using a new parameter (/asset?image_tag=smLow) it returns the URL to the image with tag 'smLow', with fallback to the default still if no still with tag 'smLow' is found.

I'm not sure what imagecache exactly provides. If it's 'resizing on the fly and store the result for later use', there possibly is a lot of overhead at search time. Maybe the overhead should be put when the browser fetches the image, because I can imagine that a lot of searchqueries are being executed that never result in an image that is showed to the user.

For another project we make use of  http://www.tinysrc.mobi/ which resizes on the fly as a cloud service. You could use the URL of  http://i.tinysrc.mobi/100/http://mediamosa.org/sites/default/files/logo.png of  http://i.tinysrc.mobi/50/http://mediamosa.org/sites/default/files/logo.png for resizing an image to arbitrary size.
Not sure about there privacy-policy though...

[forgacs]

"in the management interface, where we can define the objectcode, we need a new variable that provides the link to the still (e.g. {STILL_URL})"

This is ready. The name of the variable is {STILL_URI}.

I have implemented Image Style (formerly known as Image Cache).
* Client app edit page

Every client may have one or more image styles. These image styles usable just for that client. The users can freely create new image styles, like "medium", "small". Image style support resize, rotate etc. for images.

* The still REST calls were extended by style. Eg.

still/$still_id/style/$style_name
still/ticket/$ticket_id/style/$style_name

* The process: The user request a style for an image. If the style and the image exists for that client app, then it creates a derivate (if it didn't exist), and make a symlink for that derivate.
* Deleting image derivates were improved:

• When still is deleted
• In the cron for temporary stills
• When ACL rule is implemented
• The delete methods delete the symlinks and not the derivates.

* The SAN/NAS data/stills and still_links both have a "style" directory now. The first store the derivates, while the second store the symlinks, like "style/14_thumbnail/X/X2YEssWC78IGCXFSHWSW4VXW" (14 is the app_id). If a still is protected by ACL rule, then the symlink works, like in the original situation. They are valid just for a short term.
* New error code was introduced when the process of creating image style fails: "Unable creating derivative from image"

[Michiel.Schok]

I've been playing with this feature for the last couple of minutes.
It seems that the configuration pages in backend (e.g.  https://beheer.acceptatie.vpcore.snkn.nl/admin/config/media/image-styles/edit/5_5_thumb ) needs some rework.

I've created style 'thumb', went allright. But editing is not possible. All of a sudden the style '5_thumb' appeared (prefix with EGA_id?). Editing '5_thumb' (adding styles) is also only sometimes possible. It says 'style "thumb" already exists'. Or '5_thumb' already exists.

[forgacs]

Michiel, I have checked this issue.

Yes, the EGA id is the prefix. It is necessary, because in this way we can separate the image styles per client application.

You couldn't edit your "5_thumb" style, because the MediaMosa has already a "thumb" style:  https://beheer.acceptatie.vpcore.snkn.nl/admin/config/media/image-styles . I have fixed this problem. Also I have changed the code a little bit. It won't hide the app_id any more, the user should write style name like "5_thumbnail", and the application validates the prefix number (app_id).

Do you want a different behavior, or is it good?

[robert]

I find the whole solution with app_id attach to the front of the image style name a very weak idea and never liked it in the first place.

Think the better solution would have been to make a link between the image styles and the app without prefixing the image style name.

Also see problems here with client application admins editing image styles that don't belong to their client app because they need the global image edit style role ('Administer image styles' role) and that enables the admin to edit *any* image style. Because of this we are breaking the client application roles we finally have working.

Your ideas on this Peter?

[forgacs]

Hi Robert, First of all the original idea (was discussed together and was reviewed and accepted) with hiding and using prefixes wasn't a good idea, and caused more problems. It was the reason I rewrote it. Both solution have the same security issues. But I'm totally agree with you about the problems, eg. image styles role.
I will take an another look on this issue next week.

[Frans]

Will be fixed soon. Bugfix is ready.

[forgacs]

I have fixed the solution:
* The application uses link table between the client applications and the image styles.
* No more app_id prefix.
* The permission problems are solved. "Administer image styles" permission allows the users to edit their (and just their) client image styles. Only the super user "Administer MediaMosa" permission allows to change all image styles.

[forgacs]

Two parts:

1) You can use {STILL_URI} on the object code of edit pages of servers:
 https://beheer.acceptatie.vpcore.snkn.nl/admin/mediamosa/config/server

2) You can define styles eg. here:
 https://beheer.acceptatie.vpcore.snkn.nl/admin/mediamosa/config/app/16/edit?destination=admin/mediamosa/config/app

Original still:
 http://app.acceptatie.vpcore.snkn.nl/still/x2JbPSoouP8bWYj8UHy0VwGv

Still with style:
 http://app.acceptatie.vpcore.snkn.nl/still/x2JbPSoouP8bWYj8UHy0VwGv/style/little