Mobile Smith

Video Encoding formats and bitrates for maximum compatibility

2006-08-10T07:34:00.000-07:00

Use the following settings as a guide for video encoding. your videos will be playable on lower-end devices if you choose lower bitrate encodings.

wmv 320x240 bitrates under 1000kbps should be playable on Windows Mobile devices over 400MHz (mid- to high-end modern devices)
wmv 320x240 bitrates under 700kbps should be playable on most Windows Mobile Pocket PC devices (i.e. 300MHz and above)
wmv 320x240 bitrates under 250kbps should be playable on Windows Mobile Smartphone devices (i.e. 200MHz and above)

Use Flash for the web interface version of your videoblog. This will cover the vast majority of desktops without an additional installation (or an installation that has likely already occurred). Stick with Flash 7 compatibility or earlier. Flash 6 if you can swing it.

WMV 320x240 5-15fps (near 10 is a good balance); keyframe every 10 seconds; 250kbps total

This should cover native (no 3rd-party players) Windows Mobile Devices 200MHz and above, which include all Windows Mobile Pocket PC devices that are shipping and many (most?) current Windows Mobile Smartphone devices.

m4v - MPEG4 Part 2 (video) and Part 3 (audio "AAC"), see http://mobilesmith.blogspot.com/2006/08/mpeg4-overview.html, will be playable on iPod and (soon) Windows Mobile devices with 3rd-party software. Stick with bitrates and settings as specified for WMV to get maximum device compatibility. It is important to NOT choose H.264 (aks MPEG 4 Part 10 aka "AVC").

I'm not really sure how to "cover" the current crop of Nokia and Sony-Ericsson devices (low-bitrate and low-resolution 3gp is probably a good guess). It's not really clear to me if the low-end devices even have aggregators available. With iPods dominating the Videoblog client world, I would expect that they should now or very soon have plans for (or actual) devices to handle MPEG4 Video, with low end devices having major difficulty with H.264, so therefore stick with MPEG4 Part 2 and MPEG4 Part 3 video.

So if I had to choose today on one set of formats, I would choose as many of the following as possible, in this order:
m4v (for feed/website) - Use MPEG4 Part 2 and Part 3 - NOT H.264 and not AVC!!
wmv (for feed/website, website as an option to m4v)
flash (replacing m4v/wmv on the website)
3gp (for feed)

Video encoders, optimizing bitrates and file sizes

2006-08-08T06:14:00.000-07:00

I wrote this for a friend as suggestions for a specific video, but the advice is generic. (Also, see my previous post on MPEG4 for an explanation of MPEG4 "Parts").

I spoke with the person who advocated 3ivx to me (due
to quality) and he has not tried DivX or XviD at all,
so any of the three encoders would probably work as
long as you are creating "MPEG4 Part 2"-compatible
encodings.

If I calculate correctly, 70MB for 30 minutes is
roughly 311 kilobits per second. That's getting close
to the limit of decent quality (I think) for 320x240
video, though you are using 180 vertical which should
allow you to reduce bitrate at the same quality of
320x240 by 30%. After verifying 5 frames per second
and key frames every 10 seconds, and 320 x 180, you
may want to crank down the bitrate to 200 kbps (file
size would be 45MB), or 250kbps (file size of 56MB).
With your frame size of 320x180, you may even get okay
quality out of 150kbps.

Once you determine the lower limit of decency
(bitrate-wise), then you can start using that for
everything. You'll probably want to always select
multiple passes and, if possible, variable bit rate.
Then if you run into video with fast movement, or a
lot of movement for more than 10 seconds (the keyframe
spacing), you'll want to verify the quality
post-encoding.

MPEG4 Overview

2006-08-08T06:11:00.000-07:00

MPEG4 is a standard that includes many "parts". The important ones in our case are Parts 2, 3, 10, and 14.

MPEG4 Part 2 is the original MPEG4 video encoding specification that specifies the resultant bitstream itself.
MPEG4 Part 3 is also known as AAC and is an audio successor to MP3.
MPEG4 Part 10 is a newer MPEG4 video encoding specification also known as "AVC" or "H.264".
MPEG4 Part 14 is the file format specification also called, generically, a "container" format.

In general, the confusion between audio encoders, video encoders, and file formats is not readily resolved by the companies that create and promote this software. I've had to learn about all of this through bits and pieces and lots of reading.

The different encoders such as DivX, XviD, 3ivx all can encode into MPEG4 Part 2-compatible bitstreams, yet they encode it using different algorithms thus resulting in various subtle differences in quality. XviD was started by DivX releasing an Open Source version of DivX, called OpenDivX, and now is developed separately. Part of the confusion is that the terms "DivX", "XviD", "3ivx" and others can refer to a company, a program, an encoder, a decoder, an encoding format or a container format. And it is frequently not clear which one is being referred to. This is particularly confusing when referring to one or both of the encoding format and the container format.

In encoders that differentiate between "MPEG4" and "H264" or "MPEG4" and "AVC" as two different ways to encode video, then MPEG4 in this case likely means MPEG4 Part 2 whereas "H264", "H.264", or "AVC" refers to MPEG4 Part 10.

So the reason for the statement that all DivX-encoded video is MP4 is that DivX-encoded video conforms to MPEG4 Part 2. But all MPEG4 video is not DivX: for example, MPEG4 Part 10-encoded video. Incidently, I don't think the first part of this statement is actually true. The latest incarnation of the DivX encoder can, I understand, create ".divx" files which are essentially AVI format enclosing among other things an MPEG4 Part 2 video. And the AVI files would not be MPEG4 Part 14. So calling the result .divx file an "MPEG4" file is misleading at best.

Incidently, Part 10 video is said to be of higher quality than Part 2 for any given file size, but Part 10 is more computationaly expensive. Leading me to surmise that the quality per battery life for Part 10 vs. Part 2 is similar if not slightly favoring Part 2.

Feedburner doesn't support Enclosure Redirect?

2006-07-28T06:21:00.000-07:00

Feedburner doesn't support Enclosure Redirect?

I'm helping a client with their audio podcast feed and it appears that through feedburner, the enclosure URLs are rewritten to go "through" feedburner. I assume this is to more accurately track traffic. It's not clear to me whether these rewritten URLs are redirected or byte-by-byte passthrough.

The problem is that these rewritten enclosure URLs do not appear to support the HTTP RANGE request, which prevents what is commonly known as "resume". I can't immediately tell who is at "fault", but it is very common that a flat file on an HTTP server (such as that which would be pointed to by a "redirect") does support the HTTP RANGE request.

If Feedburner is using byte-by-byte passthrough, then you should add support for the RANGE request. If Feedburner is using a redirect, then it could be a problem with one of the following.

1) HTTP: Does HTTP Redirect support a RANGE request in the redirection?
2) Feedburner: Does Feedburner support the redirected RANGE request?
3) .NET Compact Framework: Does the library I'm using in my application support the redirected RANGE request?
4) HTTP Server: Does the clients' server support the RANGE request? (it is extremely likely that the RANGE request is supported here)

Can Feedburner confirm that at least that 1 and 2 are true?

For mobile devices, this causes a HUGE problem when the connection length is less than the download length (which is often the case with GPRS downloading 36 MB).

CommentAPI, CAPTCHA, and Credentials

2006-04-10T09:21:00.000-07:00

CommentAPI and CAPTCHAs

CommentAPI is a very useful construct for use on mobile devices (see http://www.feederreader.com/TechnicalGuides/RSS_Basic.html )

One of the most common responses I get to suggesting CommentAPI for use in blogs is that the CommentAPI does not have any mechanism for preventing comment spam.

This is true, but it is also true that an early test (somewhere before 2003, if I recall correctly) by one person, indicated that the CommentAPI does not increase comment spam. Of course, that was early on. I don't know the status of CommentAPI vs. Comment spam, but it is certainly worth addressing because it is often the first response I get when suggesting CommentAPI to others.

On the other side of the fence, there are people who believe (and at least one person who has shown) that CHAPTCHAs are easily circumvented using straightforward algorithms.

To that end, I offer a way to add CAPTCHAs to CommentAPI. At some point I may figure out a way to add this in a backward compatible way or put my head around nailing down all the details. At this point, I would suggest that this is in no way a specification that should be deployed.

We could add one parameter to the RSS feed and the same parameter to the CommentAPI that would add a CAPTCHA capability to the CommentAPI.

URL of image or audio
(of course, this would need to be added to the namespace to be considered valid RSS)

Where "MIME type" is replace with the MIME type of the actual CAPTCHA and the "URL of image or audio" is replaced by a URL. This would handle either image or audio CAPTCHAs for a variety of users and allow the user to select "a priori" the type of CAPTCHA preferred.

I thought of other permutations, such as a CaptchaGuid that woud be retained and submitted, but it seems that sending back the url, which could encode a GUID, covers it.

Because the CAPTCHA could be downloaded then submitted days, weeks, or months apart, the server would need to keep track of each CAPTCHA that has been distributed. It's probably not a good idea to rely on any programmatic encoding of the valid CAPTCHA value within the URL (except if adequately encrypted?). It might be better to create a truly random number as a guid that is located within the URL and associated in the server with the appropriate value at the time of distribution.

An additional parameter would need to be added to the CommentAPI POST XML, specifically:
Reponse here

I'm not sure if CAPTCHAs allow different types of responses other than text, but it could be accommodated, potentially, using a "Type" attribute, and a base64-encoded response.

Another addition could be to specifically allow the use of HTTP Authentication during the CommentAPI POST. The client could keep track of the username and password (in a secure manner, of course) or present the user with a credentials request.

It seems to me that the addition of both of these mechanisms would make CommentAPI as secure as posting comments directly from a browser.

If anyone was interested in creating a server implementation, I would be happy to help by implementing the client side.

Media Type Dilution Round 2

2006-04-10T08:21:00.000-07:00

I'm open the the suggestion that I am not fully aware of how Media Types are used in their entirety. I am, however, suggesting that there is a growing problem with use of Media Types in determining dispatch requirements.

Functional Interpretation

Although I have not seen dispatching based on Media Types generically described in the RFCs that I reviewed, I have found the description in a w3c document "Client handling of MIME headers" [1] and RFC3023 Section 13 (Appendix A) [2].

This seems to me to be a major use and benefit of defining appropriate Media Types, especially with respect to the assignment of Sub-types within the appropriate top-level types.

Common browsers and operating systems both allow dispatching based on Media Types, in addition to the "similar-to-dispatching" uses I mentioned previously in ATOM, RSS Media, and Autodiscovery.

Even at the operating system or the browser level, this sometimes run into problems for the user where a particular audio or video Media Container contains a Media Encoding that is not decodable by the application that has been associated based on the Media Type.

Terminology Interpretation

RFC4288 Section 4.1 "Functionality Requirement" states that "Media types MUST function as an actual media format."

The next sentence states "Registration of things that are better thought of as a transfer encoding...are not allowed." and then goes on to give base64 as an example of a transfer encoding.

It is still unclear which, if any, of the following categories (using my prior terminology) are construed as a "transfer encoding": Type, Media Container, and Media Encoding. To me, these "categories" are the logical way of distinguishing audio and video media simply because these are the broad categories determining how and if a particular file can be played on any particular system.

"Type" clearly corresponds to top-level Media Type (audio, video, etc.). Media Container (such as Ogg, MPEG-4 Part 14, "AVI", "MOV") clearly does *not* correspond to RFC4288 Section 4.1 "Transfer Encoding" and clearly corresponds to an actual media format. So the remaining question is: do media encodings commonly in use correspond to "transfer encodings", in which case they do not qualify as distinct MIME types. As examples of Media Encoding I offer: Vorbis (audio), Theora (video), MPEG-4 Part 2 (video), MPEG-4 Part 3 (audio), MPEG-4 Part 10 (video). A deeper and more exhaustive survey of current Media Type registrations would be useful here.

Part of the issue here may be that "transfer encoding" in the sense of RFC4288 Section 4.1 seems to refer to "lossless," "reversible," and "universally decodable". Such is not the case with many audio and/or video encodings. Based on this interpretation, I would argue that Transfer Encodings do not refer to the common audio and/or video encodings, and therefore that these audio and video encodings qualify for Media Type registration.

Possible Solution

The danger is that if every combination of Media Containers and Media Encodings were registered as distinct Media Types, the result would be an astronomical increase in the number of Media Types and it would increase the number, if not the complexity, of the dispatch rules within operating systems and browsers.

It seems one way around this might be to use a "+suffix" mechanism (obviously specified such that it is backward compatible with RFC3023), or some other "extension". It could be specified that only Media Containers qualify as a Media Sub-type, and that one or more (optional) suffixes would indicate the contained media encodings. And that for containers that can contain or do commonly contain only audio, then they be registered under the audio top-level type. For contains that can contain or do commonly contain video (with synchronized audio), they should be registered as a video top-level Media Type. For Media Containers that serve both functions (including audio only), they should be registered as audio and video top-level Media Types.

With the added "Encoding extension" mechanism, there may be complications in that current dispatching mechanisms are "fixed" meaning that the media dispatchers expect a fixed string match of Media Type to dispatchee. This does not easily permit interpretation of added-in-arbitrary-order suffixes. To solve this problem, the order of suffixes could be programmatically determined (for example, either absolute alphabetical or alphabetical within major groups of audio, video, other). This way, only one permutation of each combination of Media Encodings would need to be added.

Summary

I'm not sure if this is viewed as a problem by others, but it seems to be a serious issue that is beginning to be "worked around" outside of, and parallel to, the Media Type definitions in several different and incompatible ways. Inclusion of more strict interpretation and differentiation of top-level types and/or formal recognition of Media Containers and Media Encodings within the Media Type system seems like significant and appropriate improvements to Media Type registration.

References

[1] "Client handling of MIME headers"

http://www.w3.org/2001/tag/doc/mime-respect-20030709
"The architecture of the Web depends on applications making dispatching and security decisions for resources based on their Internet Media Types and other MIME headers."

http://www.w3.org/2001/tag/doc/mime-respect.html
The current version states "For example, HTTP and MIME use the value of the "Content-Type" header field to indicate the Internet media type of the representation, which influences the dispatching of handlers and security-related decisions made by recipients of the message."

Section 3.1
A media type is not simply an indication of data format; it also refers to a preferred interpretation of that data format. This preferred interpretation may impact the recipient's functional decisions, such as whether the data is rendered, stored, or executed. In practice, media types are often used as the key for selecting an appropriate handler to interpret the data received. It is possible for a single data format to be associated with multiple media types and for a single media type to describe a superset of many different data formats.
--- end excerpt

[2] http://www.ietf.org/rfc/rfc3023.txt

MIME Dilution

2006-04-10T07:55:00.000-07:00

I encourage your thoughtful feedback.

Submitted to ATV working group of the IETF
http://www1.ietf.org/mail-archive/web/avt/current/msg06669.html
----

It appears that alternate means are being deployed to differentiate between major media types in part because the original uses of the MIME type are not being strictly followed. Please exuse me: if these issues have been addressed before, I would appreciate a link or two to the appropriate postings.

I have recently been asked about the Media Type being able to distinguish between audio and video. It was stated to me that, for example, application/ogg, application/smil, and application/smil+xml do not distinguish between audio and video.

My response was that the MIME type *should* differentiate between audio, video, and other major types of media. But the top-level MIME types appear to be suffering from dilution.
RSS Media (excerpt from version 1.1.0)

In addition the latest draft of the Media RSS Specification justifies the addition of a "medium" attribute that differentiates between major "mediums" (image audio video document executable) because "it simplifies decision making on the reader side, as well as flushes out any ambiguities between MIME type and object type"

This appears to model EXACTLY the original purpose of the MIME type (section 3 of http://www.isi.edu/in-notes/rfc2046.txt where we see: text image audio video application, as well as composite types: multipart message).

ATOM

While ATOM (http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-08.txt)Proposes to differentiate between an "entry" (in ATOM format) and all other "media".
It seems like a very useful construct (within ATOM) to be able to differentiate collections based on both top-level MIME type and sub-type. Further dilution of the top-level types seems contradictory to the entire purpose of MIME type.

RSS and Atom Feed Auto-Discovery for Internet TV

http://maketelevision.com/log/rss_and_atom_feed_auto-discovery_for_internet_tvMakes use of an attribute: media="tv", to differentiate between what (in my opinion) should be top-level MIME types.

Granted that these examples are not standards (yet), they substantiate the view that top-level MIME types are not sufficient for media differentiation.

Ogg

As a concrete example of the dilution, application/ogg is the MIME type for use of all audio and/or video that is in the Ogg file format. Ogg often contains vorbis-encoded audio or theora-encoded video. It seems appropriate, then, that either audio/ogg and video/ogg, or audio/vorbis and video/theora, be appropriated for use for files using the Ogg format. I found that in Feb 2006, there was an application that included appropriation of audio/vorbis, specifically for RTP transport, and not for Ogg file format. This concerns me only because audio/vorbis seems very appropriate to use for Ogg file format vorbis-encoded audio and its appropriation for use only using RTP "container" format seems premature or somehow misguided.

Over the past year, I've had quite an introduction to video container formats vs. encoding formats. I maintain the "media chart" for Pocket PCs at http://www.feederreader.com/mediachart.html , which attempts to sort out some of the confusion.

Part of the issue is that Media Type, Media Container, and Media Encoding are variously intertwined and mixed. But not essentially addressed by the MIME type specification. And because these issues are at a level above individual MIME types, it seems they would need to be addressed outside any MIME type application.

These issues appear to me to be ripe for "de-confusioning" and it occurred to me that the organization responsible for MIME types would be the place to start.

Thoughts? Comments?

Greg Smith