Tagged: ogg

vfe.sh 3.0

New version of vfe.sh works with ffmpeg v1 and up. Overall the changes to ffmpeg increase the similarity between the ffmpeg and the libav suites, so that makes my life a little easier. I did not try for backward compatibility. If you need to use it with ffmpeg 0.6, then you need to use the 2.0 version. You can get either version from the repo on github:

https://github.com/kwiliarty/vfe-sh

vfe.sh 2.0

The latest version of vfe.sh (2.0) allows you to select whether the script will run the transcoding commands using an 'ffmpeg' or 'avconv' command. The default is ffmpeg, and it's the kind of thing one is likely set and leave, so I have added a 'converter' value in my .vferc file. On my Mac I'm using ffmpeg, and on my Ubuntu machine avconv. With avconv I found that Ogg encoding was sensitive to the audio bitrate, and that 128 was a good value. At any rate, it is now a setting that you can adjust on the command line or in your .vferc file. Lastly I added more explicit output so that you can now see in the terminal the full form of the command that the script ran for each video type.

Updated files are on:

http://github.com/kwiliarty/vfe-sh

External “Video for Everybody” v2.0

I've just released version 2.0 of External "Video for Everybody." New to this version is the option to use remote file detection so that the plugin will generate source tags and download links only for video sources whose existence it can verify. You should use this option only if some of your videos do not have all three source types (.mp4, .webm, and .ogv). If that is the case, though, and if you are using the VideoJS library, then you ought to use file detection. The External "Video for Everybody" plugin is now bundled with Video JS 3, and a missing .webm video will cause VideoJS to fail on FireFox.

vfe.sh 1.11

I just pushed a new version of the vfe.sh script to github:

http://github.com/kwiliarty/vfe-sh

This version (1.11) drops the use of ffmpeg2theora. All of the relevant functionality of this utility is available through ffmpeg. For my script the switch has these advantages:

  1. Fewer dependencies
  2. Greater range of input formats now possible
  3. Consistent and predictable handling of anamorphic pixel aspect ratios

Point #2 lets me work more easily with kdenlive, which I have recently begun using for video editing. Point #3 makes it easier to handle input from a wider range of cameras.

External VfE 0.8

I've just released version 0.8 of the External "Video for Everybody" WordPress plugin. The plugin now supports delivery of .webm video files. The change to the  HTML is minor, and it's been part of Kroc Camen's Video for Everybody for a while now. I'm just catching up, not least of all because I wanted to be able to do testing of my own before putting it out there.

A trickier question was how to handle the links for downloading files. I've decided to continue generating the .ogv and .mp4 links automatically. These two files are still required in order to play your video on as many systems as possible. The .webm file is icing for now, so you can set a shortcode attribute to include the .webm link whenever that file is also available.

To put it another way, if you are using this plugin, you should offer an .ogv and an .mp4, and you can offer a .webm if you like. If .webm is not your thing, you can just keep using the plugin as before.

A fair question to ask might be: Why use .webm at all when it doesn't increase the viewability of your video, when it takes longer to transcode (at least in my experience), when the file sizes are larger (again, in my experience), and when it means uploading and storing three sizable media files instead of two? The simple answer would be that the quality of the video seems higher to me.

Which raises another point: The order of the source elements is dictated by quirks of certain devices on which you might view the video. That's too bad. Even though .webm looks the best, .mp4 needs to be listed first and might therefore be preferred even by clients that could handle the .webm. It would be nice to find a way to privilege .webm wherever it's supported, but that's a matter for a future version.

Good News for External VfE in Safari 5

I just upgraded to Safari 5 (Mac) and was very happy to find:

  1. Safari 5 respects the preload="none" attribute of the HTML5 video tag
  2. Safari 5 will play ogg/theora video

The first point is of immediate relevance to the current version (0.7.1) of my External Video for Everybody WordPress plugin. The second point holds promise for the future of open codecs in HTML5.

Neither improvement seems to be available for the Windows version.

External VfE 0.7

I have just released External Video for Everybody 0.7 as the new stable version. The big change here is that following Video for Everybody 0.4+ I have dropped the embedded QuickTime objects.

Part of the rationale for dropping QuickTime objects is to simplify the HTML, though I would not have done it for that reason alone. After all, the plugin doesn't care about having to write some complicated markup.

I made the switch for three additional reasons:

  • I think it is valuable to stay close to Video for Everybody rather than to fork off in a different direction
  • Dropping QuickTime objects lowers the overhead when preparing files. There is no need now to create a "poster.mp4" file.
  • I want to avoid preloading movies that will not be played, but using the "poster.mp4" was creating an odd user experience. You had to click on the movie to get it to play rather than clicking on the "play" button. So really the poster needed to have some kind of "click me" label. I'm sure I could have automated a smarter poster creation for myself, but it added to complexity for providers and consumers alike. Better to let it go.

External VfE 0.5

I've just released a minor adjustment to the External "Video for Everybody" plugin. The change follows the official version 0.3.3 of Video for Everybody. In the code the .mp4 file is now listed as the first <source>. That's the only difference. Firefox still plays the OGG video, but Chrome will play the .mp4 now instead of the .ogv.