Showing posts with label frame skip. Show all posts
Showing posts with label frame skip. Show all posts

Tuesday, June 2, 2009

Is the HQ35 Mystery Solved?

[This post is under review: Expect revisions soon (or not). Specifically, I spotted some issues in my test video that have me questioning some assumptions I've made so far. More detail will be added, once I've sorted out just how significant the effect of these discoveries may be on the issue at hand, getting smooth, high frame rate playback under HQ35 encoding and the related issue of getting the HQ35 encoding at all.

At this point, getting HQ35 has become such a rarity that I've backed off on seeking an answer to a question that has almost become moot.]


Sadly it's going to be a little hard to tell since so far, uploading test videos comparable to the ones in the previous demo of this problem will not seem to render to HQ35. However, without the alternating squares in each pair of frames, there still seems to have been significant progress, in this video.



and in this one:



The first video was rendered in Sony Vegas Pro 8.0c. Full specs are provided in the description section of the video's YouTube page.

I need to confirm just how the second video was rendered. I suspect it was done in Final Cut Pro, probably as a Quicktime container using H.264 video and AAC audio.

The key either way is to boost the number of reference frames or (in Quicktime) keyframes. Onno (maker of the animation) says that he increased the keyframes to 1 keyframe per frame... in other words, each frame is also a keyframe. I hope he will see fit to share more detailed rendering specs and settings that I can download and implement. This was discussed in some detail in a recent thread in YouTube's recently renovated Help Center.

A render of my adapted test video, with the alternating blocks appears below the fold.



Be warned, though, that at least at the time this was uploaded, it only received the HQ18 encoding. I suspect this may be because, to defeat frame droppage in HQ35, videos have to meet a certain standard of "compressibility," so as to avoid presenting them at such a high bit rate that they become too difficult, time consuming, (and costly) to stream effectively, particularly for those of us with slower connections.

So here's the one with the bouncing boxes:



Enjoy! And please leave comments if you find that this information is not helping to eliminate stutter and lost frames in your HQ35 videos. This is a very new development and I'm far from confident that this is a definitive answer.

Wednesday, April 8, 2009

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.