Picking best file format not working

I really appreciate your contribution, but I am not familiar with this patch format.

Can you try this and see if we can get a standard GIT patch format?

In your terminal do the following....

cd [--- PATH TO THE MEDIAFRONT MODULE FOLDER ---]
git init
git remote add origin http://git.drupal.org/project/mediafront.git
git fetch origin
git checkout -f origin/7.x-2.x
git checkout -b 7.x-2.x
# NOW APPLY YOUR PATCH FILE HERE, OR MAKE YOUR CHANGES TO THE FILES
git diff > 1536226-pick_best_format-2.patch

You should then just be able to upload that patch file and it will be in GIT format. Let me know if that works.

Thanks,

Travis.

I am taking the same approach to HTML5 video as what I perceive refman1073 is, using a multivalued file field to contain mp4, webm, and ogg versions of the video. MediaFront always chooses the first file, which I have verified by changing the order of the files in the FILE INFORMATION area of the node edit page and inspecting the page with Inspect Element. The result is that the video may not play in some browsers. In Safari, the video plays if the mp4 is the first file; in Firefox, the video plays if the ogg is the first file; in Chrome, the video plays if webm is the first file. When the video plays, the HTML contains the tag. When the first file is of a type not supported by the browser, the Flash player fall back occurs, but the video refuses to play.

In the case of multi-valued fields for the media file, I would like to see the files used as the src for the tag in the order in which they appear in the file listing. This allows the browser to select the file that it can play, which is how I understand the tag is intended to work. As it seems to work now, MediaFront (or is it Media) is selecting the file it thinks will work, and not doing so correctly.

When I manually apply the patch from #2 against dev-2012/04/29, I can get the video to play in Safari and Chrome by ordering the files in ogg, webm, mp4 order. However, Firefox (v11.0) insists on loading the webm version and refuses to play it.

In the case of multi-valued fields for the media file, I would like to see the files used as the src for the tag in the order in which they appear in the file listing. This allows the browser to select the file that it can play, which is how I understand the tag is intended to work. As it seems to work now, MediaFront (or is it Media) is selecting the file it thinks will work, and not doing so correctly.

Is this the appropriate way to do this? (I don't really know.) First, requiring the user to think of the order the files need to go in may be putting too much on them. Second, I can envision a time (since HTML5 media support is a rapidly moving target) when the order the user chooses now might not work with then-exisiting browsers and codecs. I would think that making the order a setting in MediaFront would be a better way to go. Define the file formats you'll be using, then order and enable them as needed.

@refman1073,

I will get this patch in, but I do have some concerns.... see below.

+++ b/mediafront.moduleundefined
@@ -522,33 +525,36 @@ function mediafront_get_node($type, $entity, $fields) {
+          $file = new MediaFile($values[0]);

Why are you referencing the 0 index here? I take it for images, it will always just be one item in this array?

Also, this patch doesn't apply to the latest 7.x-2.x version. Can you please re-roll to the latest and then I will provide my own changes to it and we can get this into the next release.

The only media types that need to have multivalued fields would be audio and video based upon the HTML5 video and audio tags. All of the audio and video files provided in the multivalued file field should be placed into the HTML that is produced. Instead of the module choosing the correct file, let the browsers do it from the src fields in the video/audio tag. The module can concentrate on the great looking, feature packed player that MediaFront is becoming.

In order to make video playable on all the modern browsers and devices requires a minimum of three files mp4/h.264, ogg, and webm versions of the video with a Flash fallback for older browsers. The HTML produced should look something like

<video>
	<source src="videofile.mp4" type="video/mp4" /><!-- Safari/iOS    -->
	<source src="videofile.webm" type="video/webm" /><!-- Chrome/Android-->
	<source src="videofile.ogg" type="video/ogg" /><!-- Firefox/Opera -->
	<!-- fallback to Flash -->
	<object type="application/x-shockwave-flash" data="videoflash.swf"> <!-- Firefox uses `data` attribute -->
		<param name="movie" value="videoflash.swf" /> <!-- IE/Safari use param -->
	</object>
</video>

If other formats are also included in the multi-valued file field, I would add them as additional source parameters for the video tag before the Flash fallback. If one of the three file types for video is not included in the multi-value field, the video is unlikely to play on all devices.

I do not see the need for multi-valued fields for other types of media or for needing multiple titles, but I am mainly concerned about video and audio working properly on modern browsers and devices using HTML5.

What about the other media types, for example, title, custom and everything else? I was not sure what to do with these either so the patch only picks the first value.

To clarify jlholmes' response, you can pretty much assume that the fields used for title, image, or a custom MediaFront field type will not not be multi-value. There's no reason to have different titles and images for each format of the same media. The same title and image will be used regardless of the format of the media the browser chooses to play.

Patch from #11 manually installed against beta1 does what it intends. However, we are not quite all the way to having HTML5 video play everywhere that I have tested.

I have tested the patch with mp4 and webm versions of a video uploaded locally to a multi-valued file field with the mp4 file first in the listing of files. Chrome/Firefox/Opera play the video and using the webm file within a video tag. Safari plays the video using the mp4 file within the video tag. I have tested against the latest versions of Chrome, Safari, and Opera on Windows 7 and Mac OS X 10.7. However, IE9 (Windows 7) uses the Flash fallback to play the mp4 version of the file resulting in only audio. This behavior is consistent for Flash, which typically plays only the audio for my mp4 files. I have verified that the video files are being served with the correct MIME types.

I also have Media 7.2.unstable4 and File Entity 7.2.unstable4 installed.

I think that the IE video problem is a duplicate issue, so I will take that discussion over there.

The more I think about it, I think what we have here is at least a good iteration toward maybe an end goal to make the markup handle all cases, but this does cause some issues as to event handling with the media and controls. I will go ahead and push this up to head.

Thanks!

Travis.

Committed to HEAD with attribution. Thanks refman1073!

Travis.

Please test the heck out of this so that we can make sure it doesn't break anything when we go to the next beta.

I see you committed this to head travist, but in the latest 2.x release this is still not working. Can you give us an update when you have a chance to see where this issue is at?

I have done some testing on this and have identified the following:

• When using mp4, ogg/ogv and webm, it appears that the only issue is that Safari (iOS and OSX) and Internet Explorer are trying to load ogg/ogv unless mp4 is last in the sort order.
• When using just mp4 and webm, it doesn't matter on on the sort order. All browsers play it nicely.

This appears to only happen in MediaFront. You can test out just straight HTML 5 Video Code at http://www.w3schools.com/html5/tryit.asp?filename=tryhtml5_video_all

Take note that there is only mp4 and ogg in this demo but the order is mp4 then ogg. As mentioned above, using this order in Mediafront results in IE and Safari trying to use ogg (rather than what it should be using: mp4.

Further to jlholmes comment above

If the type attribute isn't specified, the media's type is retrieved from the server and checked to see if the browser can handle it; if it can't be rendered, the next source is checked. If none of the specified source elements can be used, an error event is dispatched to the video element. If the type attribute is specified, it's compared against the types the browser can play, and if it's not recognized, the server doesn't even get queried; instead, the next source is checked at once.

Each element can container multiple elements and the browser will go down the list of video sources in the order they are listed and play the first one it is able to play. This however is a waste of time and bandwidth and creates a bad user experience so it is important to tell the browser which type of video is which with the element so each browser will only play the video it supports. The type attribute containers need three pieces of information: MIME type, video codec, audio codec.

e.g.

<video width="640" height="480" controls> 
<source src="video.mp4" type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'> 
<source src="video.webm" type='video/webm; codecs="vp8, vorbis"'> 
<source src="video.ogv" type='video/ogg; codecs="theora, vorbis"'> </video>

Some further testing on Audio. When using mp3 and ogg/oga, in a multivalue filefield the order is ignored. All browsers still try to play the first file in the order.

I will take a look at this as soon as I can. I just release RC3, but this fix was not included. (there is a new theme though!)

Hopefully I can include this in the 2.0 release that I am planning on having done before the end of this month.