The Mystery of the Disappearing M2TS Encodings

There have been a fair number of threads in YouTube Forums lately complaining about the fairly sudden disappearance of M2TS upload capability. For those who think I may have coughed and hit 4 random keys back there, M2TS stands for MPEG Transport Stream. It's commonly the container format used by many HDV and AVCHD cameras today when video is captured from the camera and moved to local disc for editing purposes, though if you followed the link to the Wiki article, you'll also note that it's a container format primarily meant for digital broadcast (not quite the same thing as streaming video). It's a fine format for that. Uploading it to YouTube for streaming presents some problems though.

For one it's much higher definition (usually) than anything YouTube (or any other site) can actually stream back to most users, considering, for example that the data rate is usually at least 15MB/s, and can be as high as 30MB/s -- while a fast cable connection under the very best of conditions streams not much higher than 20MB/s and in reality is often limited to 6-10MB/s.

That said, it is actually possible to upload the format to YouTube and get it to convert adequately. This, however, is not an example of success:



But the following video did convert more or less correctly:



A few ideas on why these videos converted differently come after the jump...


My leading theory has to do with interlaced versus progressive scan video. The big difference between those two renders was that the first one was defined at the frame rate that my Canon XL H1 (and many HD cameras) claim to shoot at. In my case, 60i, meaning 60 frames per second, interlaced. If you're in Europe or somewhere else where PAL video is the standard, the equivalent is 50i (50 fps, interlaced).

Look at the rendering details in the video description, though, and you'll see it's closer to 30 fps, and though it's still interlaced, something tells me that YouTube want to make that act like progressive scan. Somewhere in the encoding process there's a bit of confusion, and the result seems to be that all the frames play at 30fps, in effect making the video twice as long as real time.

In contrast, the successful version was rendered at 30fps and the project definition was also at 30fps. There are some slight defects in that version that I suspect are related to it being uploaded in an interlaced format, though, and among other things that means that YouTube decided that a much higher resolution interlaced video was more artifacted and did not rate the HQ35 rendering that many people have been striving for as the happy middle that gives decent quality and sharpness without requiring viewers to have the hottest, fastest new computer or a super-fast connection.

A few key threads from YouTube Help Forums:

- Failed to convert MTS...

- M2TS Files Failed to Convert

- AVCHD and .mts files

Testing strange things

Testing an issue with playlists and favorites. This is an embedded list of 20 videos taken from my favorites. I've since pared it down to 16 videos, eliminating private videos and those that appear to not permit external embedding.



This is the part above the jump.

And this comes after. This is a video uploaded from a cellphone. (Or recorded on a cellphone, transferred to a PC, and then uploaded to the Yoob).

It's pretty chunky when viewed in "blowup" size on its YouTube page. It's not so hideous when shown in a tiny window no larger than its original resolution.

YouTube's High Quality Mystery

For those just tuning in, in about the past month or so, various problems have shown up for many people, most dramatically, the tendency of HQ videos -- those that have been encoded to YouTube's Format 35 (&fmt=35) -- to play back at roughly half their intended, uploaded frame rate.

So far there's been no real word on what's going on with the High Quality format. I do have it on reliable authority that this issue has been brought to the attention of YouTube's engineering department, but so far no word has gotten back to me that the source of the problem has been found.

The following videos will demonstrate this behavior, at least as long as the problem persists. I tried in this and other videos to duplicate the method used by user kekkomatic and described in detail in his video description.

Basically, an alternating pattern, frame-by-frame of graphic boxes were laid into the video as two overlaying video tracks. The boxes alternate left-to-right, frame for frame.

If there were no dropped frames one would see these as a sort of constantly "shimmering", rhythmically consistent set of images. When frames are dropped, instead one is likely to see the boxes "stick" on one side or the other.

To confirm that this is limited to HQ35 encoding, you can go to any affected video and force display at another quality level by pasting the following to the end of the video URL.

NQ5 - add "&fmt=5" (without the quotes)
NQ34 - &fmt=34
HQ18 - &fmt=18
HD22 - &fmt=22 (where available)
Related videos should include several other demos. Here's a playlist of several tests, including ones that did not get HQ35 encoding and are therefore largely unaffected by frame droppage. (Playlist appears below the fold).

Playlist of test videos, as noted above, appears below. (The preceding hotlink will also take you to the playlist on YouTube itself).

Videos that were not strongly affected by dropped/skipped frames are in the playlist, towards the end. The following is a further attempt to explore issues related to this problem, but it seems to have failed to achieve the HQ35 encoding. It's included here instead to test whether one can truly disable related videos in a auto-generated custom player. Only one video should be playable in this player, if that's true.

Beluga Whale Speaking

Here's footage of the beluga whales at the Mystic Aquarium (Mystic, CT) taken on April 4.




Nada. Sorry. SRSLY