We shoot standard NTSC 720x480 and output compressed FLVs at 400x300. We've been doing it for two years - no problem. But now, whenever we output to 400x300, there are two thin black bars - one on top and one on the bottom. This makes no sense, as all settings are the same.

I've done a quick workaround, setting the size to 400x294, but this is not realistic given the massive amount of videos we output, and the interactive way we deliver them... we have to maintain the 400x300 consistently. I can't think of any reason that CS3 and CS4 would interpret the same footage output to the same dimensions as something different.

Can anyone shed some light on why this would happen, and possibly how to remedy it?

Instead of NTSC DV being interpretd by default as having a 0.9 PAR, it is now read (by default, and correctly) as having a 0.91 PAR.

You can try interpreting your footage as having a 0.9 PAR by accessing it's footage intepretation settings by selecting the item in the Project WIndow, hitting cmd/ctrl F, and adjusting the default PAR.

edit: once again, Mylenium used his ability to transcend space and time answer this with incredible speed.

OK... I thought this would fix the issue, but we may need a little more uncovering. I did follow the link and read about the PAR updates, along with a few related stories. At first glance, this seems like it would cover everything.

However... In our particular instance, it isn't just one piece of footage, but rather the entire comp that turns up with black bars. These bars don't show up while editing - but only after I render the comp. Also, when I go to interpret the footage, there is no option to turn it back to .9 in any case. And in the output module of the render queue, there aren't any options to adjust PAR settings.

They talk about changing a text preference to disable automatic update of PAR, but that only applies to projects that are converted from CS3 to CS4... it says that anything new you create will still maintain the new PAR settings. This is great for some old projects, but not good at all for anything new we create.

As informative as all of this is, I don't know if this is the issue we are dealing with or not. It seems as though even if the PAR is .91, then it would follow through all the way to final output.

I've ton a bunch of test renders at different settings over the last couple days. I haven't found a fix at all, but I have noticed these couple things:

If you do File/Export/FLV, the 400x300 works fine for me, no matter if I'm using CS3 or CS4.

If you want to export cue points for use with Flash, you MUST use the render queue - which means you can't simply export - which sucks, because the functionality of cue points is what some of us need.

Render queue always outputs black bars on top & bottom, unless I change it to 400x293 (instead of 400x300) but even then,

I will still get the bars in some online players.

The whole issue of PAR change from .9 to .91 is irrelevant because you can export FLV just fine, but you can't render FLV correctly.

If I simply nest the comp inside a 400x300 for rendering, I get a lower quality output, so that workaround is out of the question.

This points to a flaw in the way the program handles "Export" vs "Render" for this particular output. I wish they would put out a fix for this.

Unless you absolutely need cue points (as we do at my job), I would highly recommend File/Export/FLV because it seems to work the best in the way of final output, plus there is a lot less clicking involved.

The problem is that a 400x300 (4:3 ratio) frame aspect doesn't match the overall NTSC DV frame aspect (15:11, forget about Pixel Aspect for now since AE is taking it into account for you). Bear in mind that calling NTSC "4:3" is a rough approximation, not the real world aspect.

A true equivalent would be, for example, 400x293. If you use those dimensions for custom stretch in the Output Module, you won't get black bars.

It should be easier, I know.

I'd still recommend avoiding the File > Export path. The only reason why there's a FLV option there is because Flash authoring installs a simple export component for Quicktime compatible applications, and AE lists available Quicktime export components there. The Quicktime exporter will distort the content in this case and offer less options.

Good points. But yeah, the bottom line mystery is why the program outputs differently going to the same format. To be honest, I've been using the File/Export method for two straight years perfectly fine. Seems like in the render queue, you should be able to 'stretch' to anything you want - because, after all, not all content is going to be distributed within the confines of specific ratios... and this is especially true in our case, where we are outputting FLVs that go in custom Flash pages - which should ideally be able to be any size you want.

In our case, we actually do a bunch of FLV with Alpha vids that are built into pages - and those are weird dimensions that only serve to fit the exact range of how much the talent moves on cam. (ie: 350 x 340, etc.) Yet, those don't ever have black bars.

Well, I can puzzle about it all day, but I'll stick with the workaround until hopefully there's a patch or possibly a script by someone.

Yes, but I don't think distorting your output is what you want to get to your desired frame size. If you want a 400x300 output frame size without distortion, start with a frame that has the same overall format.

Basically, there are two possible outcomes when specifying a non-matching frame aspect for export: distorting or letterboxing.

But it's true, I agree it should be much easier to manage non-matching sizes and aspects when going to distribution formats through AME.

Bear in mind, however, that nesting the original comp in a 400x300 square pixel Comp and then rendering that should give better, not worse, quality than stretching in the Output Module. Nesting Comps and fitting aspect is the highest quality way. If you got bad results this, it's probably because of something else. "Circumstancial evidence", as lawers like to say

Also, launching the Adobe Media Encoder in standalone mode and feeding it a video file as a source should give finer control.

I am having the same trouble the lines are about 3 pixels top and bottom... But it makes no sense because the lines appear even if I render out same as source but simply change the size even with the lock on to make sure size is adjusted evenly... Any ideas on what I could be doing wrong?

It actually seems to be ok now, but what I am now trying to do is get an in between setting for Web Large Flash 9 and Web Medium Flash 9... Is the only element I should be adjusting to reduce pixelation the Bitrate Settings?

Well, pixellation can occur because of too much compression, or simply because you're enlarging the file beyond its' size.

The first is fixed by raising the bitrate, or using a more advanced encoding application that allows 2 pass encoding (like Adobe Media Encoder in standalone mode) or choosing a more efficient encoding scheme (like F4V/H264). The latter is fixed... by not doing it

Yes, you should be able to pick a "same as source" FLV preset and dial in a stretched size that is proportional to the Comp size (by locking the dimensions as you did). The most likely reason why you are getting pillarboxing (ie, black bars on the sides) is because your Comp surely uses non-square pixels (ie, NTSC DV, NTSC DV widescreen, HDV 1440x1080, etc) and FLV is always square pixels. You probably want to nest your non-square Comp into a Comp that has an equivalent size in square pixels. For example,

NTSC DV 720x480, PAR 0.9 = 648x480, square pixels.

NTSC DV Widescreen 720x480, PAR 1.21 = 872x480, square pixels.

HDV 1440x1080, PAR 1.33 = 1920x1080, square pixels.

You can then stretch down the size to an equivalent in the Render Queue's Output module.

You probably want to nest your non-square Comp into a Comp that has an equivalent size in square pixels.

My FCP timeline was DV, so I changed the sequence settings to Square and changed the dimension to PAL Sq. The screen dimensions jumped to 768 x 576 accordingly. I then set to Pro Res and exported as a QT movie with same settings. But CS4 Media Encoder still misread the screen size/PAR. It's claiming the file is 720x576. I have no idea why. Perhaps there is more to this QT/MediaEncoder clash than simply the new "correct" way CS4 reads PAR on non-square pixels.

768x576 is not a correct equivalent for PAL DV. It's not a Quicktime/AME clash. It's something that can be measured and demonstrated.

If you actually want to distort it to get rid of the blanking black bars (which is what your other application does), crop the black bars in the source tab of AME settings and then in the output tab, set the Crop Setting to "Change Output Size" (see screenshots below).

Note that when you do all this, a "Same as source" FLV will become 768x576 instead of 788x576. Good? It's up to you. Your PAL DV camera disagrees.

Firstly my 768x576 QT with square pixels is read by AME as 720x576, so when I crop as you say it becomes 702 x 576. Whatever. But I then can't work out how to then scale it down to a 4:3 web output size. I mean, to get access to the greyed out Resize Video tickbox I seem to have to unclick the crop button on the source tab, but then resize video doesn't scale the image down, it crops the image down?!?

All I want to do is crop the blanking black bars then scale down to 256x192. ...Unless dividing by 16 is inapplicable because of all this PAR and black border stuff I'm encountering.

And I still don't understand why it's an advantage to have the blanking black bars on standard web output. Isn't it more of an inconvenience for standard export situations?

It seems like you're doing something wrong on the FCP side. Besides changing the frame size, did you make sure you changed the pixel aspect as well in FCP's sequence or export settings? I just brought a 768x576-Square file exported from FCP into AME standalone, and it reports the frame size as 768x576.

In any case, don't even worry with this, as it's not the culprit for the black bars. I don't even know why you're exporting square pixels from FCP. This is just adding noise in the conversation. Simply use standard PAL DV files, which is what I had in mind in the case I posted above. AME will handle the non-square to square PAR transform.

But I then can't work out how to then scale it down to a 4:3 web output size. I mean, to get access to the greyed out
Resize Video tickbox I seem to have to unclick the crop button on the
source tab, but then resize video doesn't scale the image down, it crops the image down?!?

You mean like this Resize button in the Basic Video Settings?

Bear in mind, again, that 256x192 is a proportional scale down from 768x576. 262x192 would be the correct, proportional equivalent for PAL

Edit: Sorry, my bad. The "change output size " crop setting disables the Resize button, so it wouldn't work well in this case. If I crop the black bars, set size to 256x192 and leave the crop setting to "scale to fit", I don't get the black bars on the sides.

And I still don't understand why it's an advantage to have the blanking
black bars on standard web output. Isn't it more of an inconvenience
for standard export situations?

Sorry, I missed this bit.

It's not an advantage having them in the exported file. It's an advantage taking this into account.. As not doing so means incorrectly distorting the frame to fit. If you don't want them, crop them out. Which is one of the reasons why all encoding applications give such an important place to crop setttings (also, because of action/title safe of course).

I assumed that was similar to dumping it in a square pixeled comp in AE. Export as square pixel, then AME will scale down correctly.

If I crop the black bars, set size to 256x192 and leave the crop setting to "scale to fit", I don't get the black bars on the sides.

And neither do I. Thanks.

Bear in mind, again, that 256x192 is a proportional scale down from 768x576. 262x192 would be the correct, proportional equivalent for PAL

Ok. So do I go with 262? Robert Reinhardt's Sep 2007 table for optimal frame dimensions for Flash Video says 256x192 for 4:3 ratios. Is that incorrect because of this current PAR thing? Or have I misinterpreted something again?!? ...I simply want to follow the multiple of 16 best practice, but if it's ******** I'd love to be set straight.

Ok. So do I go with 262? Robert Reinhardt's Sep 2007 table for
optimal frame dimensions for Flash Video says 256x192 for 4:3 ratios.
Is that incorrect because of this current PAR thing? Or have I
misinterpreted something again?!? ...I simply want to follow the
multiple of 16 best practice, but if it's ******** I'd love to be set
straight.

Thanks so much for all your help, Adolfo

Well, "correct" is something that depends on the purpose and intention.

262x192 would match more accurately the final aspect of PAL content, after it's stretched out by a PAL TV .

But if you are, for example, targetting a mobile device with a 256x192 screen (or religiously want to keep with multiples of 16), then by all means use that size.

Note that since you also want to avoid the black bars, with a PAL source and 262x192 target size you don't need to do anything, while if you want 256x192, you'd have to crop the source slightly on the sides and scale to fit. It's up to you.

When I set the crop proportions to 4:3, AME auto crops 9px on the left and 8px on the right, as opposed to your 9 and 9.

Is one or the other more correct?

I noticed that as well. It could be related to the fact that PAL is actually 5:4, not 4:3 (not to mention that NTSC itself is not really 4:3, never mind...)

I would ignore the crop aspect lock. The amount of cropping in the source you need if you really want to go with an equivalent of the "old" square aspects (768x576 and smaller equivalents) is the difference between 788x576 and 768x576, ie 10 pixels on each side. Again, if you go with 788x576 and its' equivalents, you don't need to crop/fit anything.

Ok. So what it boils down to is Does the multiples of 16 thing really make a difference to web quality compression (small clips for a Flash website)?

If not, I don't care. I'm not precious about losing a few pixels at the edges or having it display slightly inaccurately. I'm just trying to work out what I need to learn for the future, rather than discover I've been using an unnecessary or inferior compression path.

Yes, keeping things in multiples of 16 is a common recommendation for Flash video, for both Sorenson Spark and On2 Vp6.

In fact, there are Flash video experts out there which recommend distorting the video slightly (as you're already doing) to get to the nearst multiple of 16.

Personally, I am not seeing such drastic differences when going with the "correct" frame aspects, which are not multiples of 16. But I am not a Flash encoding guru.

So, you have to decide between a small hit in qualiy by cropping and scaling to fit, or a small hit in quality by not honoring the multiples of 16 rule. I'd say trust your eyes on this. If it looks good in either or both ways, who cares?

But you're not saying that I can get a 262x192 export without black bars without cropping in AME, are you???

Yes, I am saying that. But... this is true as long as the black bars aren't there in the source video to begin with (ie, recorded by the camera). This is, if they appear in the AME's source tab (or in the original application, see screenshot below), and you don't want to have them, you'll have to crop them. This has been this way throughout the history of web video encoding.

Incidentally, the cropped & scaled 256 x 192 version of my PAL 5:4 timeline looked noticeably hazier than the 264x192 (uncropped but completely ignoring the multiples-of-16 rule of thumb). So for any other ignoramuses like me in the same situation, it looks like outputting PAL at a non-traditional websize (where possible) to get rid of black bars is better than cropping and scaling to a perfect 4:3 size.

But note that this is f4v tests only, NOT flv. ...I still haven't heard if the multiples-of-16 rule of thumb applies to the H.264 codec in f4v. Anyone?