Question: What's the meaning of <is_streamable> in /mediafile call

[Michiel.Schok]

When I execute a /mediafile/{id} call, in the response, I see
<is_streamable>FALSE</is_streamable>

I tested quite a few mediafiles, and I observed everywhere a 'FALSE' response.
Couple of questions:
1. When is this field filled (or supposed to be filled)
2. Why does it get filled with 'FALSE' in the case of streamable mediafiles
3. What can we use it for?

[Michiel.Schok]

Possible related: on a [get] /asset/{id} call there is a
<has_streamable_mediafiles>FALSE</has_streamable_mediafiles>

where the asset clearly has multiple streamable files

[MC-arjen]

to match the container_type of the mediafile against the currently supported streaming server container types.

The idea once was that if the container type of the mediafile is supported by one of the streaming server definitions, the file is streamable.

My guess is that the introduction of the configurable object codes in the streaming server definitions in 1.6 this field was broken. Clearly we are missing a unit test for this field.

A client application could use to prevent play errors, and show a message beforehand ("unplayable mediafile"). Is it still needed?

[Michiel.Schok]

At the moment, in SURFmedia we look at the 'ega_play_url' to see if a mediafile is playable. We are at that moment not sure which of the possible responses will succeed or will fail.

For instance, on a flash-movie, the 'response=metafile' results in an error 611 - This container type doesn't support metafiles (flv). On a Windows Media file, all is well.
As far as I know, there is no way for us to get this information out of VP-core when a user opens a webpage for an asset, except for trying...

Maybe, some clever guy could come up with a way to denote to us:
* response=object will work
* response=plain will not work
* response=metafile will not work

Especially, when users start uploading strange combinations of containers, codecs etc, and we are supporting more and more, this should be transparent.

Based on the output, we could decide which buttons in SURFmedia we show to the user: "Play now', 'direct link', 'embedded code', 'Open in Player', 'Virtual Cutter'.

or something like that?

[Frans]

Moved to MediaMosa 2.1

[Frans]

Needs discussion

[MC-arjen]

So we could add to the mediafile xml output in the restcalls:

/asset/{asset_id}/mediafile [GET]
/asset/{asset_id} [GET]

next to

  <is_streamable>FALSE</is_streamable>

the fields:

<response_object_available>,<response_plain_available>, <response_metafile_available>

of type TRUE/FALSE

for example:

  <response_object_available>TRUE<response_object_available>
  <response_plain_available>TRUE<response_plain_available>
  <response_metafile_available>FALSE<response_metafile_available>

The values would depend among other things on the container type versus the defined streaming servers. (and i suppose this would make <is_streamable> deprecated).

[Michiel.Schok]

I think, that would be a good solution, that solves the problem of knowing beforehand if a /play call will succeed.

Furthermore, in the response of the [get] /asset call there is the field

      <has_streamable_mediafiles>FALSE</has_streamable_mediafiles>

which also, is always (very often....) FALSE.
That can be also deprecated if not filled correctly, or otherwise filled with 'TRUE' if any of its mediafiles have a TRUE response in one of the object, plain, metafile above. But possibly that is to computationally intensive to be of use.

[robert]

2.1.1 release.

[Michiel.Schok]

OK, we see the proposed xml:

      <response_object_available>TRUE</response_object_available>
      <response_plain_available>TRUE</response_plain_available>
      <response_metafile_available>TRUE</response_metafile_available>

and it seems correctly filled (metafile FALSE with flv-content).