Ticket #41 (closed enhancement: fixed)

Opened 4 years ago

Last modified 4 years ago

0016770: 8 [PlayProxy] Quicktime en Flash object code icm 'start' en 'duration' parameters

Reported by: admin Owned by: MC-arjen
Priority: major Milestone: MediaMosa 1.6
Component: Core Version: Tested and Accepted
Keywords: Cc:
MoSCoW: Estimated time after impact analysis:
Related to project: none Tested:
Accepted: yes Estimated Hours:

Description


0016770: 8 [PlayProxy?] Quicktime en Flash object code icm 'start' en 'duration' parameters
 http://mantis.kennisnet.nl/view.php?id=16770

In issue 16570 is een feature verzoek behandeld die voor Windows media files een 'object' terug kon geven via /asset/{id}/play?mediafile_id={id}&response=object dat extra parameters als &start=xxx&duration=yyy honoreert.

Als NIBG materiaal gaat uploaden in H.264 formaat, dan dienen voor de andere containers (flash of quicktime) die objecten ook correct te werken

Change History

Changed 4 years ago by admin

(0027088)

SURFnet - Frans (manager)
2009-05-26 11:59

Arjen,

Lijkt ons een prima aanpassing om dit zo in de beheer interface op te nemen. Maarkt het inzetten van andere
In de beheer interface moet je dan niet alleen per streaming server maar ook per containertype een objectcode tekstveld kunnen invullen wat de default dan overruled.
Ik denk bijvoorbeeld aan een audio-stream, die anders behandeld
moet worden (qua height en width) dan een video stream. Voor Windows
Media bijvoorbeeld gaat het met de hoogte wel goed (default object is 64
pixels hoger dan de video (0+64=64)), maar voor de breedte moet er
eigenlijk een minimum zijn.
(0027086)
klop01 (manager)
2009-05-26 11:37

Frans, ik wil dit issue aanwenden om de playproxy wat verder te verfijnen.

Het is met de wowza server gebleken dat de objectcode per streaming server kan varieeren en dat per containertype (wat nu het geval is) niet voldoende is.

Ik wil voorstellen dat de objectcode per containertype default wordt gegenereerd in de code, maar dat dit per streaming server overrulled kan worden. In de beheerinterface moet dan per streaming server een textveld worden opgenomen waarin object code gezet kan worden. Hierbij moeten enkele voorgedefinieerde variabelen gebruikt kunnen worden ({width}, {height}, ...)

De aanpassing die Michiel hier wil, is dan waarschijnlijk ook eenvoudiger te realiseren.

Changed 4 years ago by MC-arjen

  • status changed from new to closed
  • resolution set to fixed
  • accepted set to 0
  • component set to Core

Major change in the handling of the playrequests with objectcode; In the administration interface "servers", we can per streaming server modify the objectcode. fixed in 1.6

Changed 4 years ago by Frans

  • related_to set to none

Seen and tested. Remarks and 1 question:

- The flash object code lost support for the autostart parameter.
- The ogg object code uses {AUTOSTART} where {AUTOPLAY} should be used.
- The ogg object code also contains a 64 extra pixels in the "height"
parameter, which is unnecessary because Firefox renders controls over
the video instead of below.
- An ogg file with a failed analysis gets default height and width.
These parameters should be omitted because the browser then uses default
size. See
 http://www.20.test.surfmedia.nl/medialibrary/play.html?id=ZMZYcTkcl6YcujTKaXNn6rnW&format_id=IxleNY6i0kCOAdgzuIWbtptS

N.B. Where can we find documentation on how this functionality
works/which parameters are allowed?

Changed 4 years ago by marek

Done in test db.

1. AUTOPLAY voor FLV embed code:
(een toevoeging in de URL voor StroboScopeLoader? &autoStart={AUTOPLAY_NUM})
2. {AUTOSTART} vervangem met {AUTOPLAY}

--

Other points still under development

Changed 4 years ago by marek

3. The height of the ogg is taken into consideration

Changed 4 years ago by marek

4. Question: I do not understand what is going wrong in the last point. Could you explain it please?

Changed 4 years ago by Michiel.Schok

A litte extra on bullet 4.

When looking at mediafile IxleNY6i0kCOAdgzuIWbtptS the analysis had some problem determining height and width of the ogg-file. They are both set to 0

 <width>0</width>
 <height>0</height>

When issuing a play request on this mediafile:

/asset/ZMZYcTkcl6YcujTKaXNn6rnW/play?mediafile_id=IxleNY6i0kCOAdgzuIWbtptS&user_id=foo&response=object

the object that is returned is

<output>&lt;video id="video" src="http://app.acceptatie.vpx.kennisnet.nl/ticket/5/M5Hky7EIBVgRymPfrs1eUMA4" height="304" width="320" autoplay="true" controls="true"&gt;Your browser does not support this video&lt;/video&gt;</output>

This object has an width of 320 pixels and height of 304 pixels. My guess is that it has a default size of 320 x 240, and an added 64 pixels in height (makes 320 x 304).
So VPcore makes the assumption (or default) of 320 x 240 pixels for the video. VPcore shouldn't do that, but rather omit the height and width parameters in the object definition if it doesn't know how big it should be.

A capable browser (e.g. FF3.5) starts loading the stream, and decides about the object size...

Changed 4 years ago by Michiel.Schok

  • status changed from closed to reopened
  • resolution fixed deleted

Changed 4 years ago by MC-arjen

  • owner set to marek
  • status changed from reopened to assigned

Changed 4 years ago by marek

  • owner changed from marek to MC-arjen

There is a rule in the code where only container type WMV is getting +64 pixels of height. There was a bug where the OGG type also included that. It sould be fixed in the next relase.
The object code for the OGG type is now only HTML 4. That is the reason for that response. If there is a embedded player which supports OGG for HTML 3 then the video will play. The default 0 from transcoding can be a bug in the ffmpeg tools. I can not determine it right now, because it is not my area of expertises.

Changed 4 years ago by Frans

  • status changed from assigned to closed
  • resolution set to fixed

Quoting Arjen:
#41 [PlayProxy?] Quicktime en Flash object code icm 'start' en 'duration' parameters
We changed the {AUTOSTART} in {AUTOPLAY} and modified the objectcode
voor flv. There is no extra 64 pixels for ogg formats anymore. Point
is better now (no extra 64 pixels).

Changed to fixed.

Changed 4 years ago by Frans

  • version set to Not Tested

Changed 4 years ago by Michiel.Schok

  • status changed from closed to reopened
  • version changed from Not Tested to Not Accepted
  • resolution fixed deleted

Windows Media
Als er start en stoptijden worden meegegeven, dan bevat de gegenereerde .asx file geen juiste content. We zien bijvoorbeeld bijgaande tekst in de .asx als we een aanroep doen als:

 http://www.20.test.surfmedia.nl/app/video/KLZ4XJIBhWzCvGVbEyrFWPVO/play?format_id=OOkU1W0hs7h0GWlGRKSOuH5i&mode=object&start=5000&end=10000

{IF_EXTERNAL}
<asx version="3.0">
<entry>
<ref href="{TICKET_URI}" />
{IF_START}
<starttime value="{START_TIME}" />
{/IF_START}
{IF_DURATION}
<duration value="{DURATION_TIME}" />
{/IF_DURATION}
</entry>
</asx>
{/IF_EXTERNAL}

Flash / Wowza
Start en stoptijden worden niet meegenomen in het object. Het lijkt erop dat JW-player dat wel kan via flashvars:  http://developer.longtailvideo.com/trac/wiki/FlashVars

Ogg
Het object is 20 pixels te hoog
(Start/stoptijden zitten niet in HTML5 spec, en gaan dus ook niet mee. Autoplay wordt wel in object genoemd, maar firefox 3.5 negeert de setting).

mp4 / quicktime
Object in firefox doet niks met start/stop tijden. IE8 gaat wel goed.
Heb link  http://www.20.test.surfmedia.nl/app/video/Yqowwrml9j5tSq5vENxvv0p3/play?format_id=7VieheLMkxETXbE7Wjs1ost2&mode=object&start=40000&end=45000 gebruikt om te testen.

mp4 / wowza
Object doet niets met start/stoptijden. Is JW-player, dus zou eigenlijk wel goed moeten kunnen via flashvars (zie eerder comment).
Heb  http://www.20.test.surfmedia.nl/app/video/6B03JmyIgOJTMoAPYNgRyc9E/play?format_id=PgXQQPO3ArQub6mYn6i4rmLu&mode=object&width=320&start=34000&end=44000 gebruikt om te testen.

Changed 4 years ago by MC-arjen

  • status changed from reopened to closed
  • resolution set to fixed

wijzigingen in 1.6.4:

Windows Media

Het voorbeeld geeft nu:

<asx version="3.0">
<entry>
<ref href="mms://wms.acceptatie.streaming.kennisnet.nl/vpx-test/5/RUVZ6oczyC0VdVCq93AhBPbt" />

<starttime value="00:00:05.0" />


<duration value="00:00:05.0" />

</entry>
</asx>

Flash / Wowza

We geven nu ook in de objectcode de start en duration mee richting jwplayer; met als opmerking dat jwplayer een wat andere duration definitie heeft als MM. Momenteel vertaald met de variable: {START_PLUS_DURATION_TIME_SECONDS}

Ogg
20 pixels verwijderd;

mp4 / quicktime

Zoals het objectcode nu is heb ik het werkend getest in ff3.5, chrome en ie7...

mp4 / wowza

Zelfde verhaal als bij flv/wowza.

Changed 4 years ago by Frans

  • accepted changed from no to yes
  • version changed from Not Accepted to Tested and Accepted

check en ack

Note: See TracTickets for help on using tickets.