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.
Excellent work! These test videos perfectly demonstrate the problem.
ReplyDeleteThey seem to make progress. I uploaded a video this morning with timecode and framemarks, same tests as kekkomatic: http://www.youtube.com/watch?v=NLduRN4QuCA
ReplyDeleteI tried to download my video with this script (http://googlesystem.blogspot.com/2008/04/download-youtube-videos-as-mp4-files.html), played it with VLC, still the same choppiness and even worst. But I noticed that the video resolution was 768x432, the same as the uploaded file. It's no more 640x360 as before. Maybe they're trying to make the encoded videos as near as possible to the source?
I don't know... wonder if that script isn't accessing the original upload somehow, rather than the FLV-wrapped h.264/AAC streams that have been active until now? This has really piqued my curiosity, now.
ReplyDeleteIt's too late here at the moment for me to explore this, but I'll try to look again in the next day or two.
@Telordya: Looking at that scriptlet (and trying it on one of my vids) it seems it only will DL either the HQ18 or the HD22 encoding, whichever is the best one available. Since HQ18 is not the encoding most affected by the frame droppage, that migh explain your experience at least in part.
ReplyDeleteThe HQ18 is less sharp and a lower bitrate than HQ35 (which I believe was still an FLV wrapper, though one containing an h.264 video stream, last time I DL'd one).
I'm going to keep looking into this though, since things are always changing on YouTube.
Ha yeah, I forgot to mention that I really downloaded the HQ35 version, in a .flv. I just changed the (isHDAvailable?'22':'18') part in the script to (isHDAvailable?'22':'35'). Otherwise, as you said, it'll download the HQ18, which runs perfectly.
ReplyDeleteWish I understood javascript better... I suppose I could just make up a separate one for each format if I could get rid of that isHDAvailable bit.
ReplyDeleteThanks for the clarification.
FWIW I just confirmed that, at least for a 764x432 upload, what you picked up on is true. (And the downloaded version seems to have similar choppiness issues, though I didn't frame-mark it as I did with the others, I was mainly wanting to confirm that the encoding was in fact 764x432.
ReplyDeleteIf only they could fix the part that's actually broken. Still, this would seem to be good news for those who want HQ35 and don't want an HD render showing up.
My example of 764x432 is at:
ReplyDeletehttp://www.youtube.com/watch?v=KKPFyUGtuts
Did you have some feedback from your contact about Google's engineering dept?
ReplyDeleteSorry, still nothing definite from YouTube. Despite Google owning YouTube, technically their support staffs remain separate, so far as I understand it. But in any case there's still been no answer aside from "We're looking at it, thanks for showing us this IS a problem."
ReplyDeleteAll my latest video uploads have this problem as well. I thought it was me.
ReplyDeletehttp://www.youtube.com/watch?v=infvwxgioVg
Very apparant. And it sucks.