Trying to search for answers, but don"t know terminology Created 2 weeks and 1 days ago

Here's some scaling info

Setting which defines how video is scaled on the video screen. Available options are:

* fit: Fit to window by preserving the aspect ratio encoded in the file's metadata.
* half: Half-size (preserves aspect ratio)
* orig: Use the dimensions encoded in the file. If the video is too big for the available space, the video is scaled using the 'fit' option.
* scale: Scale the video to fill all available space. Ignores the dimensions in the metadata. This is the default setting.

From here "in the clip properties section". http://flowplayer.org/documentation/configuration/clips.html

What you need to research is how to change the size of a DIV container dynamically using JavaScript or Ajax or JQuery. There is nothing specifically in Flowplayer to provide this; it's standard CSS and JavaScript coding.

That said, you'd be advised not to do this. Flash works best when the presentation player is the same size as the encoded video. When it's not Flash must work extra hard to rescale things dynamically. This is especially true when the size is in odd numbers (not divisible by 2) and for at least FLV videos when the size is not an even multiple of 16.

The problem is the most apparent when Flash is downloading the video while playing it.

Users could experience jittery playback, or greatly diminished quality - blockiness is a common complaint. The problem is worse on older machines or those with slower processors or limited RAM.

So, there is a reason players are statically sized on the page. When there is a sizing option (as there is on YouTube) the sizes are carefully chosen to minimize any negative effects. They don't give you all the sizes inbetween.

If what you're saying is true (and I've not doubt that it is, as you know more than I do) then why does my video still look good at full screen. I'm encoding my Flash video (and I have tons of Flash online) at a dimension greater than the current player size but less than full screen. Looks good at player size, looks good at full screen (which is important since full screen is necessary to see some of what the instructor is writing). My current player also does not allow for stretching, and because I'm switching CDNs I'm also switching to Flowplayer. Based on your advice, I'm inclined not to instruct my developer to allow for "dragging/resizing" of player size, but I still think that I'll continue to encode at a dimension greater than player size because, in my experience, that will allow it to look better at full screen. Mine is DV footage originally, so I encode to native 720x480. I have done many test encoding my video to the player size, and this results in lower quality when client goes to full screen mode.

Perhaps, based upon your advice, my best bet is not to ask developer to allow for "dynamic resizing" but rather for me to pick a larger default size for the player that is consistent with the 720x480 aspect ratio. Do you agree? If so should I just point my developer to that link above that Edge provided?

Thank you both for your responses and your advice. Regards, Dave

Because in fullscreen Flash uses full hardware acceleration (when available). This is the same for most any video player on Windows or Macintosh that can take over the whole screen.

If your vids are keeping good quality in fullscreen that's good, but you're also starting out with videos that are slightly larger than most people's, so this is helping Also keep in mind that the quality at fullscreen depends entirely on the user's computer (hardware level graphics support, size of monitor), version of Flash, and so on.

And, as I mentioned, the problems are worse when presenting the video AND downloading at the same time (very high CPU usage, etc., where Flash will dynamically degrade the quality in order to keep up). In other words, there are A LOT of variations.

Seeing that you're using video for instruction requiring a high level of screen detail you may find Flash may not be the best technology to use. A Flash player like Flowplayer is great for interactivity with the page because the player is embedded into the page. You can interact with the video while still being able to access the rest of the page.

If you're needing to go to fullscreen just to adequately see the video I suspect you've picked the wrong video technology. Distributing your videos as HD WMV or Quicktime files (or similar) may be something to consider.

No. Flash technology is fine. Again, this is a product that is working in production with a different content delivery network utilizing a proprietary player. I'm switching CDNs and thus have chosen to purchase commercial Flowplayer. The videos work perfectly fine in Flowplayer. WMV and QT are not ideal for streaming, and work better for progressive download. Our content must be streamed for reasons not necessary to get into. Again, I'm not new to this technology, only to Flowplayer. I'll instruct my developer to avoid the "streatch to resize" type of customization and we'll just use a slightly larger player configuration that maintains my aspect ratio.

Thanks again.

The scaling 'fit' option should always maintain the aspect ratio as long as the content/video has the correct meta data and is not anamorphic.

Right. I've seen as much before, but generally I'm playing the videos locally, so you might not see the degredation you could see from dynamic resizing of something carried over the Internet. That said, my CDN (the reason for my switch) offers pretty impressive bandwidth - but I guess it is still only as good as the download speed of my client's end customer. Still, our clips are broken into 4 to 5 minute chops, and I'm encoding these things so that they're only about 10 MB at 460 max bit rate (yes, some will consider that high, but we're not getting performance complaints). My client's customers are generally watching these things from Fortune 500 companies, so they're connection speed is pretty darn good usually. I might still experiment with dynamic resizing, test it with a select group of customers, and decide from there.

Naa 460 is fine. I usually use 850-1100>using 2 pass vbr in mp4 container, they only require 180-210k download speeds.

You could just make a few different size play buttons via html or js. Eg, click here for Small, Med, large ect.

The jquery tools overlay might be of interest. http://flowplayer.org/tools/demos/overlay/index.html
There's a few different demos there to take a peek at.

Yeah. That's good advice regarding quality options. I had that with last vendor too, but never opted for it since we don't get any complaints ever about streaming.

I would love to use 850 or more because quality is great. For me it is just a matter of storage space. Right now I have about 60 GB limit under current contract, and I'm already pushing that number. If I changed from 460 to 850 I'd go right past that. There are somethings though, like demos, where I would opt for the 850. It is good to know that download requirement for that, as I was unaware. Thanks!

>I usually use 850-1100>using 2 pass vbr in mp4
>container, they only require 180-210k download speeds

How is that possible? How do you get (as an example) 1 megabit of data down a 200 kilobit pipe in real time? Are these short videos with a long buffer? Or maybe I'm misunderstanding what you meant here.

Flowplayer buffer is @ 1 second. And I'm using Pseudostreaming Not rtmp so I limit the speed for the mp4 file type @ 180k.
As long as I stick with my encoding params it works great.

YouTube does the same thing. Though lately watching videos there has become painfully slow.

Here you can see it in action.
Via flowplayer at 180k speed limit.
http://vizmu.com/movie-trailers/804/129846/

Here's a direct link to the video, Download it, it will limit you @ 180k give or take 5 or so. It will also limit most download accelerators.
http://vizmu.com/downloads/hd-movie-trailers/Salt-trailer.mp4
Edit: You may have to copy and paste that link in your browser.

Like I said though these are vbv so the bitrate is all over the place, by the time it hits a 2k bitrate scene its already been buffered. The target bitrate I work from is 900k though.

I see. This is a question of nomenclature. Those videos don't really have an average bitrate of 850-1100 kbps, but that's your ceiling (constrained). Your reference to multipass encoding made me think you were listing the ABR of your videos.

Most of the encoding tools I use refer to the average bitrate with a separate constrained rate that can be equal to or higher than the ABR. Therefore, setting a bitrate of (say) '512' will give you an average 512 kbps. You'd need a sustained 512kbps pipe to adequately view it without buffering pauses.

Yes, I've seen YT's throttling. Often stays under 100k, in fact. You can watch it especially when using something like Safari to download a clip from the page you're looking at.

I'll instruct my developer to avoid the "streatch to resize" type of customization and we'll just use a slightly larger player configuration that maintains my aspect ratio.

[ ADMIN EDIT: this is spam ]

Is this just SPAM or are you trying to show me a sample. It appears to be SPAM as I see no sample illustrating a resizing Flash window. If so, then this would seem like an awfully strange place to SPAM, since I'm guessing that the users on this board are pretty sophisticated with tactics like this. But, what do I know.

If you're trying to help me, I'm missin git. If you're trying to SPAM, then you're in the wrong place, I'm guessing.

Yep he's spamming, his only other post was pretty much the same.

On the bitrate subject, I just re-read and should clarify a little more. I'm using x264 with VBR not CBR. @ 900k-CBR both the storage and bandwidth requirements would be substantially higher.

I'm using VBR as well. Thanks for checking that out though.

On the spam: those are posting bots. The forum has had some issues with these lately. If you ever spot it on new threads you can mark it, and the forum admins will (eventually) remove it.

On choosing Flash: I'm sure you are right that it's the best format for your project, but do remember that Windows Media and Quicktime are also streamed, probably more so in business environments than progressive download. (As an example, Netflix uses Silverlight and VC-1/WMV to stream desktop movies; it does not use Flash.)

Of course I'm a Flash/Flowplayer proponent or I wouldn't be here! But it pays to look at all the alternatives.

On 460kbps bit rate being considered "high" by some: Not sure who'd consider that high! That's actually on the low end of medium. But if your videos are looking okay there's no reason to change it. The lower the better, as long as quality is there. In my experience Fortune 500 companies don't always have the latest or best IT infrastructure. In fact, because of corporate budgets, they often have less capable machines than the typical home user.

Yeah. What you're saying is definitely true about Fortune 500 companies. I spent quite a bit of time imprisoned at one of those places before breaking free (thank God). But, my client's customers are typically technology companies, and, as stated, I've never had complaints about the stream itself (in terms of choppy playback, stuck videos, etc.).

I do sincerely appreciate the suggestions, experience and opinions though. I did look - very seriously, actually - at QT, mostly because I run a Mac shop and prefer QT quality to Flash (for what I'm doing). As you said, my product does look better in QT (in my opinion, everything looks better in QT than Flash, doesn't it?), but I've been discouraged by 2 different content delivery architects from using QT. And, no doubt, my strorage space would be pretty big compared to the compressed file sizes of .flv if I switched to .mov. Anyway, I think that what I plan to do in regards to my original question is to have my developer create a larger default size for Flowplayer when launched from our site. The reason I wanted to allow user to "scale" it themselves is because the default size for Flowplayer is too small to see the details, and the "full screen" sees some - albeit minor - degredation. Halfway between the two works perfectly, so I'll just work with my developers to create a happy medium that sticks with my 720x480 aspect ratio. I'm sure that if I do so, people won't even opt to expand to full screen, because it will be unnnecessary.

You're using FLV? Somehow I thought it was H.264.

Anyway, one last thing - though you may already be doing this. Be sure to use VP6 FLVs, not the older Sorenson Spark FLVs. If you're using FFmpeg or another free tool, it's Sorenson. Switch to VP6 (legally only available using licensed tools) and the quality will be 50-100% improved. If you have Macromedia Flash 8 or later you have a VP6 encoder. Quicktime will even pick up the encoder and use it as an export option. (At least that's how it is in Windows. I assume it's the same on the Mac.)

I am using VP6, transcoding using Flix On2 encoder via export option in QT Pro. Now, having said that, I am at an ideal time to make a switch (still using Flash technology) since I'm reencoding all of my nearly 100 hours of video. I would love any ideas that I could try quickly using the available tools that I have, which include FCP, QT Pro, Sorenson Squeeze, and that Flix On2 Flash encoder. You mention H.264 which I believe is an option out of FCP (but the file has a .mov extension still, I believe, right?). Also Edge mentions that he uses mp4 file types. Any advice from either of you (or anyone else that wants to chime in) on some experiments I could do today to compare quality is appreciated. In other words, given these tools do I have other high quality options besides my current process, which is to export a self-contained movie from FCP, then encode from QT Pro using the Flix encoder?

Thanks again for any thoughts.

On2 Flix (Pro) is a good program. I'd stick with that if it's working.

H.264 provides for better video (in general; it depends on the encoding settings) but do keep in mind that it requires a later version of Flash 9 that not everyone has. Adobe's stats does not break down penetration by release numbers; that is, is shows penetration of Flash 8, 9, and 10, but not the individual releases for each version. To support H.264 your users must have Flash 9 r115.

If you have a defined target audience you can poll them to see what version of Flash they have. They won't know, so it's best to write up a little Flash app they can visit that shows them (same as what Adobe does).

Because there is a chance a Flash 9 user will not have r119 or later, you may need to create a fallback video with VP6 just the same. You'd have to decide if this is worth it to you.

(This is how YouTube does it for many videos, working both ways - iPhone/iPod uses H.264 encoded vids and can't play FLVs, for example. So for many/most of their videos they double encode to make sure their videos are viewable by as many people as possible.)

Thank you. It sounds like .flv using the On2 Flix (Pro) VP6 encoder is going to work for most, if not all, so I'll stick with that for now.

I know that we're way off from my original question, but in reading responses from you and Edge yesterday I was curious so I've been playing with my settings in On2 Flix this morning. I'm using the 512k Broadband Preset, and as I said I'm using my host dimensions of 720x480 (I know that is large for most Flash settings, but it allows for the details to be seen better when folks expand to full screen). I'm also doing variable bit rate with 2 pass encoding.

In the past I've set my max streaming bit rate to 460, but after hearing from you guys yesterday, I've been experimenting this morning with higher max bit rates. I do see significant quality increase when I up that max bit rate to 700, for example. Even the file size change is not significant there. My 2.5 minute clip went from 8.2 MB to 10.2 MB. My question is, if I use that 512 preset but increase my max bit rate up to 700 (using VBR), can I expect that this will impact users at slower connection speeds? I ask because if I can increase that max bit rate, then I can set my Flowplayer size to default to - let's say - 648x432 (which, if my math is right, maintains my aspect ratio) and user would likely never need to expand to full screen mode. I guess in that scenario, I could just set me encode settings to 648x432 so I'd be encoding at the same size of player size.

Does what I'm saying make sense? Feel free to tell me that I'm all mixed up.

Because of your target audience 'Fortune 500 companies' VP6-e is the best route. Many administrators of such companies limit the user account privileges. Often upgrading flash by the user is not allowed.

gmccomb mentioned polling the users, that's a great idea. h.264 in mp4 both looks and compresses better. But it's pointless if your audience can't view it.

Regarding the max streaming rate question. I've never used Flix pro but I do have access to cs4/media encoder. If you have a link to an un-encoded version of one of your files I could experiment with some settings. I used to set a pretty low target then set the max high. But its been a while.

Aspect ratio:
Using scaling: 'fit', in your flowplayer clip section will maintain the aspect. However adjusting the player width and height to fit the videos natural resolution when not in full screen always looks better.

Unfortunately I don't have a link to anything uncompressed as they are all stored here locally. Even my small 2 minute clip is 491 MB - too big for email, or I'd be happy to throw it over to you and let you fool around with it.

Here's my dilemma. I want to spend the weekend reencoding all of my assets before I send them up to my new CDN servers. I know that even after increasing to 700 max bit the clips still stream perfectly fine for me, but I have a pretty impressive machine and good download speeds, etc. These assets are originally encoded at 720x480 using 512 preset and max bitrate of 460 without too many complaints (complaints were usually browser or Flash plug in related). My question is, if I opt for the better quality and change my max bitrate to 700 is it conceivable that the same group of clients would suddenly experience download issues? If that happened, I would find myself rencoding, yet again, at 460 max. I'd love to use the visible quality difference that I see with 700 max.

Not sure if this matters as well, but my old CDN was using http buffering and my new CDN uses rtmp streaming. Is one better than the other (from a user performance perspective)?

webmasterworl.com/ said it is goog for your own web.

vdscollection.com

[ADMIN EDIT: this is spam]

I can't speak to what your clients connections are capable of. If its possible try what gmccomb mentioned and send out a sample html page with the higher bitrate video inside flowplayer. Just tell them "We're working on improving our service" or something, and ask for responses.

RTMP is great. However the download speed requirement is directly related to the bitrate of the video. Thus making it that much more important to know your audience. I would still choose rtmp over Pseudostreaming any day. Especially if your videos are fairly long. It's more professional and will save on bandwidth as its only streaming what's being watched.

I agree you should be using VP6-E (supported by Flash 8 and above) so make sure you're not selecting VP6-S. That requires 9r115 just like H.264 does.

At the bitrates you're experimenting with there will likely be only modest improvements, depending on the amount of action between frames, the fineness of detail (text, graphics lines) of your content, etc.

If your videos are narrated with voice only (no music) you could trade some audio bandwidth for the video. Compress mono and select a lower bitrate and sampling for the audio. Stop if the audio becomes "tinny" or hollow.

I'm assuming your videos contain screencasts. These are very difficult to do and keep quality throughout. There tends to be a lot of motion (which increases bandwidth needs) and the fine detail can break up if the bitrate is too low.

You can often cut back on the frame rate and no one will notice. The Flix encoder will skip frames to keep proper time. A good target is half the original frame rate, though with a good encoder this is not critical. But, be sure on review of the output the video doesn't exhibit any playback issues, and the audio is still in sync.

There are many other tricks, and you'll find a lot of them here and there on the Internet. I wouldn't get too tied up with it though as there will be diminishing returns.

Finally, as for user experience, most people are willing to sacrifice picture quality for uninterrupted presentation. As long as your subject matter can be reasonably discerned, people will object most to a video that has to stop to rebuffer. This you want to avoid much more than squeezing out the last bit of resolution.

PS: Agree with Edge: RTMP streaming is better, not for quality as much as flexibility. In time, for example, you could work up bandwidth detection and have your server stream one of several, based on the detected connection speed. RTMP is also generally better for overall bandwidth usage, as it will stream only what is requested.

Thanks again, to both of you for your responses.

I am using VP5-E.

And, my product has been in production for a year without issue. There are no sync or playback problems that have been reported, and there are hundreds of customers each quarter (as in quarter of the year) who are streaming the clips. That said, I'm always looking to try to improve, and the difference between 460 and 700 was pretty good, just in terms of clarity without having to go to full screen.

I do already cut sample rate to 22050, change bit rate to 32, and compress mono.

By the way, I am using the native framerate in the On2 Flix encoder preset (29.97) and have my keyframes at 60. Are you suggesting that I try a test with alterations to those 2 variables?

>By the way, I am using the native framerate in the On2 Flix
>encoder preset (29.97) and have my keyframes at 60. Are you
>suggesting that I try a test with alterations to those 2 >variables?

Yes, these two. When changing frame rate that's when you want to observe the output to look for jerky playback or sync issues. These are rarely a problem when you compress at the native rate.

I wouldn't get carried away with hacking the keyframe spacing too much. You have it now at every two seconds, which is the default on Adobe Encoder. I wouldn't go above every four seconds. It all depends on the amount of action. Slow movement can make do with fewer keyframes. Keep key frames to every 2-4 seconds if your content is ever going to be delivered HTTP again, or locally. Otherwise users will have trouble accurately scrubbing to a specific spot.