YouTube being a light player has nothing to do with YouTube. All flash player are based from Adobe themselves. You did not download something special from YouTube to playback their videos. All YouTube made was the GUI for the "flash player."
I don't really understand what you are trying to say. I do know that youtube causes a cpu load of about 30-50% on my system, while most other video sites hit 80% cpu load easily. (For comparison playing a video with mplayer takes something like 10%) My point was that while the youtube player is relatively lightweight, it's still heavy, and doubling the framerate is probably not going to help.
Joined: 6/25/2007
Posts: 732
Location: Vancouver, British Columbia, Canada
There are options for a reason. Your ancient computer not being able to handle running a video at 60 fps doesn't hold the rest of us back if there are playback options.
I don't really understand what you are trying to say. I do know that youtube causes a cpu load of about 30-50% on my system, while most other video sites hit 80% cpu load easily. (For comparison playing a video with mplayer takes something like 10%) My point was that while the youtube player is relatively lightweight, it's still heavy, and doubling the framerate is probably not going to help.
I am basically saying there is no "YouTube Player." YouTube did not make some special player. It is built in Adobe Flash Player. That's it. As to why the differences in CPU usage, I really can't say what is the cause. Maybe overlays of ADs, maybe what Dada mention, but regardless, YouTube did not send you some special player. The only thing YouTube added is a GUI to the Flash Player.
So what if YouTube's using the same player as everyone else? If their videos cause less CPU load than other videos, then that's a significant benefit to going with them.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
So what if YouTube's using the same player as everyone else? If their videos cause less CPU load than other videos, then that's a significant benefit to going with them.
I doubt we can go by one person's observation. It's like me saying YouTube takes the most CPU usage and we shouldn't use it. =p
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
Warp, right click on the video and select "Show Video Info".
Tell us if your PC is performing hardware accelerated video decoding or not. Most people I see that have issues with YouTube don't have hardware based video decoding.
So what if YouTube's using the same player as everyone else? If their videos cause less CPU load than other videos, then that's a significant benefit to going with them.
I doubt we can go by one person's observation. It's like me saying YouTube takes the most CPU usage and we shouldn't use it. =p
With my old computer, YouTube consistently had smoother playback than pretty much any other video streaming site I tried.
Now granted, this was a six-year-old iMac (i.e. OSX and thus not as optimized of a Flash implementation as the Windows yonks yet). But still, throw enough anecdotes together and it starts to look something like data. :)
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Warp, right click on the video and select "Show Video Info".
Tell us if your PC is performing hardware accelerated video decoding or not. Most people I see that have issues with YouTube don't have hardware based video decoding.
It says "software video rendering, software video decoding". (It might be that Flash Player does not support hardware rendering/deconding on Linux.) Anyways, there's no problem I am having with YouTube, what gives you that impression?
Lex wrote:
Wouldn't that be because YouTube transcodes everything into lower-quality versions? I'm almost certain that's the reason.
Wouldn't that affect bandwidth requirements rather than the video decoding/rendering speed?
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Aktan wrote:
As to why the differences in CPU usage, I really can't say what is the cause. Maybe overlays of ADs, maybe what Dada mention, but regardless, YouTube did not send you some special player. The only thing YouTube added is a GUI to the Flash Player.
It's pretty easy to do things incorrectly in Flash and cause needless CPU usage. But I doubt they're doing that.
One major difference between Youtube and other sites is that Youtube's pages are relatively clean and free of other advertisements or heavy content. The only ads they have, other than the ones in the video player, are lightweight ones from AdSense. Flash ads/banners by third parties are some of the most notorious CPU hogs.
(Should be noted that DailyMotion also has relatively light pages.)
PS: Youtube's video player is a derivative of the JW Player.
Warp wrote:
Wouldn't that affect bandwidth requirements rather than the video decoding/rendering speed?
The quality probably doesn't matter too much for decoding speed. But the size does. The lower quality encodes are simply smaller in dimensions, so they're easier to decode.
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
Aktan wrote:
Dada wrote:
PS: Youtube's video player is a derivative of the JW Player.
How did you find this out?
Sorry, I went and checked and it seems I'm wrong. Maybe Youtube changed their player since then to an original creation. I distinctly remember reading about this maybe two years ago. In any case the files (Youtube's player and JW 5.7) don't show any resemblance right now.
edit: apparently this was true only for the first version back in 2005.
[YouTube's main purpose is to share home videos. Most cameras can't even record over 30 FPS. What possible advantage would there be in YouTube supporting framerates higher than that?
Every consumer camcorder that can record in HD can record at 60fps in 720p mode. 60fps is super common.
If there are any other encodes of mine that are improperly encoded in 30fps, please note that here. In time, I will replace them, but the priority for me right now is NoYoutube and non-HD YouTube streams.
There's a bit more to the Youtube issue, but I'm not sure if it would belong to the page...
Some emulators emulate their system not at exactly 60.0 fps. For example SNES9x v1.43 rr17 uses 60.038, but still sets the AVI framerate to 60/1. This causes the video to lag behind the audio, which becomes noticeable in long movies (>15 minutes). It can be fixed by...
1. Setting the framerate to the correct value. But after TASBlend or ChangeFPS it's still larger than 30.0 so Youtube drops frames or halves the framerate again (not sure which one it does now).
2. Slowing the audio down a tiny bit: TimeStretch(rate=100.0 * 60.0 / 60.038)
The latter option is completely unnoticeable and leaves the video intact.
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
creaothceann wrote:
or example SNES9x v1.43 rr17 uses 60.038, but still sets the AVI framerate to 60/1. This causes the video to lag behind the audio, which becomes noticeable in long movies (>15 minutes).
It is true that SNES9x has audio issues, but your comment is based on a false premise - having just inspected the relevant source code, at NTSC speeds, snes9x aims for an approximate framerate of 60fps but really ends up at (1 frame/16.667μs)~= 59.9988 fps.
The actual cause is [post 218066]32kHz sound output[/post] (I think there's a more recent explanation for the issue than that, but that was the one I could most readily find). In practice, we avoid this by using 48kHz sound output.
Alright. bsnes has the problem that the framerate of the real SNES is not exactly 60 fps so it needs some adjustment of the audio rate (SNES9x 1.53 also uses 31900 as the default); I thought this problem was related.
http://www.youtube.com/watch?v=xi0_4mYz4Fw
I figured this approach needed a full game to compare, so I picked Alisia Dragoon - it is a game I'm familiar with, as well as one with a noticeable amount of flicker throughout the entire game.
For the most part, 66%:33% blending did a neat job on Youtube. There are some parts where it is noticeably wrong - when the Thunder bar in the top left has a full charge, there is noticeable blur a lot of the time. The enemies that warp in are meant to flicker, but instead they look faded until they fully form. Check the encode between 1:50 and 2:20 to see examples of both of these.
The normal Thunder attack is greatly improved, since they only appear for a single frame in one direction, and the flame jets in Stage 5 appear how they do in the game. Overall, there's a lot gone right, but a few things that could possibly be improved with a different ratio of blending - perhaps 25:75, since the game like to alternate between frames when animating.
Call this with 25.0/100; leaving out the parameter will revert to 66:33.
function TASBlend(clip c, float "ratio") {
# reduces framerate to 1/2 but leaves flicker effects partly visible
# blends frame pairs with alternating opacity (default is 2/3+1/3;1/3+2/3)
# optional "ratio" is the opacity of the first frame out of the four
ratio = default(ratio, 2.0 / 3)
opacity1 = round((1 - ratio) * 257)
opacity2 = round(( ratio) * 257)
c
Interleave(Layer(SelectEvery(4, 0), SelectEvery(4, 1), level=opacity1),
\ Layer(SelectEvery(4, 2), SelectEvery(4, 3), level=opacity2))
}
sgrunt:
Could you change part of the TASBlend page, please?
"creaothceann suggests using this in the following fashion to select only certain segments of the clip for blending" -> "If only certain segments of the clip are to be blended, creaothceann suggests using this in the following fashion"
Joined: 10/28/2007
Posts: 1360
Location: The dark horror in the back of your mind
creaothceann wrote:
sgrunt:
Could you change part of the TASBlend page, please?
"creaothceann suggests using this in the following fashion to select only certain segments of the clip for blending" -> "If only certain segments of the clip are to be blended, creaothceann suggests using this in the following fashion"
