If you produce video from a DVD or Blu-Ray you will get an 'aspect ratio'. That means it is not a 1 to 1 ratio of pixels. For example, NTSC DVDs (North American spec DVDs) use an aspect ratio of 0.9. Computers use 1.0. Therefore your import may detect that your source video is not using a 1.0 aspect ratio and will appropriately widen the content based on the actual correct aspect ratio. You are then free to resize the clip back to what you think is correct.
You might be able to determine this information on the source clip by right-clicking and selecting properties. If the codec it was made in is common enough Windows can tell you the aspect ratio of the codec. Otherwise, load the source video in any video player (windows media player, VLC media player (recommended), Quicktime, etc) and get the properties or movie info of the video you're loading. They should be able to tell you the codec used to make the video as well as the 'aspect ratio'. Chances are it is not 1.0. Flash expects 1.0 for viewing video on a computer.
Hi Sinious, thank you for your reply, but I think the odd behaviour I am witnessing is not due to aspect ratio.
I have for instance an FLV video which I downloaded off some video hosting site. Media Info and VLC player both report its dimensions as 320x240. If I use "Import to stage..." or "Import video..." to place the video on the stage, the dimensions are correctly picked up as 320x240. But if I use the Parameters window to change the source file on an existing Flash project (in other words, to replace some exisitng video with this new video - or even replace itself), the dimensions default to 1x1. I type the proper dimensions (320x240) into the Parameters or Properties fields, but they 'correct' themselves to 318.8x239.1 (still a 4:3 aspect ration, note). If I enter the values a second time, they stay at whatever I specify.
If I wish to double the video size and enter values of 640x480, these values get 'corrected' to a variety of values, depending whether I enter the width first or the height first, and where I click afterwards. The width comes out at either 634.4 or 637.5, and the height at either 478.1 or 479.9. But if I enter distinctly incorrect values, such as 560x280, the values I enter are accepted without modification..
Clear as mud?
Cloudy as mud. What format are you trying to import? A FLV or some other format?
There are many FLV player apps on the market. Grab one and see what the FLV player (even adobe media player) tells you for a resolution and aspect ratio.
Assuming you're telling us you know the content to be 1.0 aspect ratio I see no reason for the bizarre random size values. If the FLV is nothing special and you can send it to me I can tell you if the issue is fixed in CS5.5. CS3 is pretty old but I still see no reason it would behave like that unless the FLV has been encoded to a newer format than CS3 supports.
I agree with sinious that there should be no bizarre sizes... not without some reason.
So where are you getting the w/h? when you:
type in what I assume to be the correct width and height
There is no guarantee that videos you do not create yourself will have the exact dimensions you expect. Can you view the actual metadata embedded in the video?
Are you placing the component at exact full pixel dimensions or partial? This may be the most important part!!.. when you:
reposition the video on the canvas
How?? drag and drop? or manually set exact x, y pixel loaction in property panel?...for example, set to exactly x, 20, y 20... or drag drop to x, 20.5? Double check that when you first "reposition" that the video is at exact, full dimension pixel locations in your properties panel.
To clarify a couple things here on aspect ratio... first, a ratio is a relationship between two dimensions. So for example, you can't have a ratio of 2. You need to compare that to something. You could have a ratio of 1:1... one of this equals one of those.
Second, don't confuse "pixel aspect ratio" with "video display aspect ratio".
"Pixel aspect ratio" has to do with the ratio of the width to height of the individual pixels, and does not necessarily have anything at all to do with the display "aspect ratio" of a video. So if you see 1:1 as a ratio, it's referring to "pixel aspect ratio", NOT video display ratio... meaning the video was created using square (1:1) pixels. This is the aspect ratio of pixels commonly used in computer monitor.
Standard def TV (but not wide screen) on the other hand, uses a pixel that is slightly taller than it is wide... by approx 10% or so. So instead of 100 pixels for a certain height, you only need about 90 to give the exact same display. This type of pixel is commonly referred to as rectangle.
So let's take a standard def NTSC video display dimensions, 720 x 480... supposed to be a 4:3 display aspect ratio, correct?
720/4 = 180, 180 x 3 = 540
So what's up? NTSC uses rectangle pixels that are taller than they are wide (so you don't need as many)!
That same video if created for Internet viewing on computers (with square pixels) would need to be created and display at 720 x 540 (a true mathmatical 4:3 display ratio). Yet depending on the display device, they COULD both look the same.
So now let's look at true High Def TV (videos and blue-ray). By definition the resolution of High Def is 1920 x 1080. So what is the pixel aspect ratio for high def?.... the "wisescreen display aspect ratio" is 16:9... 16 units wide to 9 units high.
So...1920/16 = 120. 120 x 9 = 1080.
Square or rectangle pixels?
Still, I'd say look real close at how you first "reposition" the video, second, get the exact dimensions by reading any dimension metadata in the video file.
I don't know what the pixel aspect ratio is. The video currently in question (but it is by no means the only one) is this one:
I repeat that this peculiarity DOES NOT occur when I import the file initially to the stage, it is only if I modify an existing instance of a video by changing the 'source' value in the component parameters. And it is only the first time I enter new values for the height and width that they get modified. Subsequently, whatever values I enter are adopted.
Ninjastrator, I don't know what the pixel aspect ratio is. VLC player shows no metadata. I suspect that it is because there is no metadata that the initial size is set to 1x1. The modified dimensions as automatically assigned by Flash CS3 always involve fractions of a pixel. It is a minor irritation and I have learnt to always enter the values twice, but my concern is that by forcing it to adopt the dimensions it didn't choose I might be reducing the quality or compressibility of the video file. But how would compression work on a 318.8 x 239.1 video? How would it even be displayed in native resolution?
I have noticed now that it is not necessary to reposition the video for the values to be altered. Simply clicking back on the stage (or in the Property Inspector but outside the 'height' or 'width' boxes) causes the value I have entered to be modified.
Adninjastrator, to further answer your question about placement, it doesn't seem to matter whether or not I adjust the placement to a full pixel position before typing in values for the height and width - the size I type in still gets modified to some fractional value, even though the x-y co-ordinates keep the same full-pixel values. (Sorry I got your name wrong last time - I had just woken up!)
To be honest, I really doubt that pixel aspect ratio has anything at all to do with the problem..... display aspect ratio usually plays a much more important roll. For example, if you are working with a video that was created for standard def TV, say at 720 x 480 resolution (which is not an exact mathmatical 4:3 ratio... meaning rectangle pixels), it will display a little squished down on a computer. To fix, simply set the display to be 720 x 540 (a 4:3 aspect ratio), and it will display just fine.
My discussion of aspect ratio was mainly to clarify the defintion and point out the differences between pixel aspect ratio and display aspect ratio.
my concern is that by forcing it to adopt the dimensions it didn't choose I might be reducing the quality or compressibility of the video file
Yes you can reduce the quality by altering the display size but you are not changing the compression at all. "Quality" is directly related to the "video bitrate" (or amount of data) used to encode the video. And this video bitrate is optimal at one display size. Increase the display dimensions and the quality degrades. For review:
Video bit rate
Video bitrate is the minimum amount of data that must continually flow into the video player in order for the player to display that particular video uninterrupted. If that supply of data is not high enough, the video player will stop…. Wait for more data to download, then resume. The video bitrate is set as a parameter when the video is encoded.
For highest quality playback, the video bitrate is tied directly to the display dimensions. That is, the larger the display, the more incoming data is required to properly display the video. Think of bitrate in terms of a can of paint. If you have 1 quart of paint, you might be able to do a very nice job on a 32 X 24 foot area. But if you try to stretch that same amount of paint out over a 64 X 48 foot area, the coverage will not be nearly as good and you get poor results.
In the same way, a video displayed at 640 X 480 pixels will require 4 times the bitrate (or amount of data) as a video displayed at 320 X 240 pixels to produce the same quality. So for example a video with a bitrate of 100kbps, displayed at 160 X 120 will produce the same quality results as a video with a bitrate of 1600kbps if displayed at 640 X 480.
Video display size has a direct bearing on the final quality.
So I don't know why you are getting fractions pixel dimensions. And yes, altering display size can affect quality (as per discussion above). So it's a good idea to try find out the video bitrate as well as the original display size.
A 320 x 240 video with a bitrate of 1000kbps can be scaled up with less loss of quality than can a 320 x 240 video with only a 500kbps video bitrate, for example.
The Bruce Lee video has this embedded metadata:
so a total bitrate of about 415kbps (video and audio)... display dimensions 320 x 240.
To display at 640 x 480... seems like you are only "doubling" the display size, but not really, you are quadrupling the display size. So to maintain quality, the data requirement (video birtate) grows very quickly when you scale up a video.
My knowledge of video compression is in the realm of "it is a greater miracle than the virgin birth" but as I understand things, at a given bitrate, the picture quality can be affected by the dimensions. For instance, width and height divisible by two helps. A fractional width and height is definitely not divisible by two!
As for the video size, 320 x 240 comes out very tiny on a modern monitor, so to save the viewer the hassle of choosing between 320x240 or full-screen (or knowing how to mess about with their video player - my audience are by and large not computer geeks) sometimes I prefer to deploy videos stretched to say 640x480. This doesn't change the bandwidth requirement, and even Internet Explorer (what player does it use?) does a reasonable job of zooming by a factor of 2. If the recipient uses a decent player like VLC which can stretch 320x240 to 1920x1080 without significant pixellation then we're all winners.
By the way, do you think that Bruce Lee video is genuine?
Upscaling video to larger than original dimensions without also increasing the video bitrate will ALWAYS result in the same amount of data being spread thin out over a larger area.
Whether or not you are satisfied with that degree of quaility degradation... only you can say.
If the video is genuine, he was one hellava ping pong player!!
I'm also concerned with how you're getting a video with a (impossible) fractional width and height. 318.8 x 239.1? That must be a value derrived from flash after "something" altered its width. There is no such thing as exporting a video with a fraction in its width and height.
If you're talking about embedding a video that has already been encoded into a FLV format (as it appears to be the case) then forget aspect ratio. FLV will be 1.0 to be compliant with computers so we'll shelve that as the problem.
400kbit/s+ for 320x240 video is a huge bitrate that can easily be doubled. I could easily compress that to half the size with minimal noticable compression at full frame rate with Sorenson Squeeze with a modern codec. I doubt you'll have any issue doubling it.
Video bitrate, easily described, is how much data you allow the video and audio, per second. There are a few things in video that really chirp up the needs of the size of the data. Audio consumes a constant portion of it and typically ranges from 96kbit/s (mono) to 128kbit/s (stereo). Subtract, say, 96 mono from it and the video has 404kbit/s left over. The reason it only has 404kbit/s left over is the person who encoded the video told the encoder to limit it to that.
Now the encoders job is to do 2 basic things to encode the video given its known data limits, both of which I'll loosely explain.
One, you have "frames per second". In the video mentioned above Adninjastrator mentioned the framerate was 25 (ignore the floating point value for the most part). Now it knows it needs to split 404kbit/s between 25 frames. That comes out to 16.6kbit per frame, or a measily 2KB per 320x240 image. That sounds tiny. However encoders are smart and when you do multi-pass encoding it pre-analyzes all 25 frames for "what changed". If your video is not high motion but rather is more of a talking head, the entire background is probably doing nothing. The codec realizes this and uses all available 404kbit on what actually changes frame to frame. That reduces the size of the motion from 320x240 to whatever the motion in the picture actually is. If nothing changes for half of a second, the other half of a second gets the full 404kbit, if it needs it. If nothing changes in the entire second at all (in variable bitrate encoding) you can actually watch the kbit/s on that part of the video drop from 500 to 96 (audio only).
That said, secondly, you do need to make sure every so often that what appears to be an unmoving background looks as good as possible. A keyframe is a frame that is full quality. A true 320x240 full quality frame regardless if anything changed or not. It's easy to see keyframes. If you see a low kbit/s video pan a camera fast you'll see compression blocks all over the screen. Though when the camera stops panning you'll notice that the blocks suddenly disappear. You just hit a keyframe. A full quality frame that cleaned up the compression blocks. Great encoders will 2-pass encode video and have an "auto keyframe" option that can sense when a video is changing between scenes (all pixels change at once) or goes high motion and will ramp up bitrate and add in extra keyframes to keep the video as clean as possible. But keyframes are expensive as it is a full quality frame.
That's the 101 of compression. Knowing that, you'd know that taking a 320x240 video encoded to 250kbit/s with 128kbit audio at 25fps leaves a mere 122kbit/s to be divided between 25 frames. Therefore it's unlikely you'll be able to scale that video up. If it's 1000kbit 320x240 video, you'll definitely have some room to scale. However, it is STILL only 320x240, so you cannot scale it without softening the picture, no matter what the kbit/s is. You can encode 320x240 video to 10,000kbit/s but it will look like utter crap at anything above twice its size. A soft, blurry mess.