Skip navigation
Currently Being Moderated

Thin black bars on render to FLV

Jul 24, 2009 12:43 PM

This is weird, and it only started after the upgrade to CS4.

 

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?

 

Thanks!

Attachments:
 
Replies
  • Currently Being Moderated
    Jul 24, 2009 12:51 PM   in reply to jdlindallas
    I can't think of any reason that CS3 and CS4 would interpret the same footage output to the same dimensions as something different.

    Certainly not, but:

    We shoot standard NTSC 720x480

     

    Clearly explains it. All you need to know --> Pixel aspect and frame ratios.

     

    Mylenium

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 24, 2009 12:53 PM   in reply to jdlindallas

    This may have to do with the PAR updates introduced in CS4.

    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. 

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 28, 2009 12:21 PM   in reply to jdlindallas

    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.

    Adobe Media Encoder is putting the black bars to avoid distorting your content.

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Jul 28, 2009 8:37 PM   in reply to jdlindallas

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 20, 2009 7:42 PM   in reply to Adolfo Rozenfeld

    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?

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 20, 2009 8:30 PM   in reply to TomSynnott

    What size is your Comp? What are you stretching it to?

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 21, 2009 8:11 PM   in reply to Adolfo Rozenfeld

    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?

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 21, 2009 10:12 PM   in reply to TomSynnott

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 1, 2009 3:11 AM   in reply to Adolfo Rozenfeld

    your Comp surely uses non-square pixels 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.

     

    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.

     

    Posted on the thread over here too
    http://forums.adobe.com/message/2358594#2358594

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 1, 2009 9:25 AM   in reply to maltinghead

    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.

     

    Source.PNG

     

    Output.PNG

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 1, 2009 10:08 AM   in reply to Adolfo Rozenfeld

    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?

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 1, 2009 10:48 AM   in reply to maltinghead
    Firstly my 768x576 QT with square pixels is read by AME as 720x576,

    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

    resize.png

     

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 1, 2009 10:36 AM   in reply to Adolfo Rozenfeld
    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).

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 1, 2009 5:45 PM   in reply to Adolfo Rozenfeld

    Thank you!

     

    I don't even know why you're exporting square pixels from FCP.

    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.

     

    Thanks so much for all your help, Adolfo

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 1, 2009 6:50 PM   in reply to maltinghead

    ...One more little thing.

    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?

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 1, 2009 7:25 PM   in reply to maltinghead

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 1, 2009 7:34 PM   in reply to Adolfo Rozenfeld

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 1, 2009 7:54 PM   in reply to maltinghead

    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?

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 1, 2009 8:07 PM   in reply to Adolfo Rozenfeld

    Thanks.

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

    Edit: Oh, yes. You are. I must have been searching for 256x192 so hard I didn't realise 262 was black bar-less.

     

    And does the multiples of 16 rule apply to .f4v files too, or is H.264 a different beast?

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 1, 2009 8:42 PM   in reply to maltinghead

    Thanks.

    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.

     

    blanking.png

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 1, 2009 9:27 PM   in reply to Adolfo Rozenfeld

    Thanks

    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?

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points