Forum Replies Created

Page 10 of 43
  • Michael Duff

    August 19, 2007 at 10:50 pm in reply to: New User Question

    are you using the render queue to output your files? you should always use it…don’t use File->Export. If you have the composition selected that you want to render go to the menu “Composition->Add to Render Queue”. then adjust the settings to suit.

    Does this answer your question?

  • Michael Duff

    August 17, 2007 at 12:46 am in reply to: Exporting problems/questions….

    yeah it probably would be quicker to render uncompressed because it isn’t doing the encode processes … but it is writing a larger file to disk … I don’t think the difference would be that much .. almost all of the render time is calculating blurs and compositions and such …

    i think it’s probably good habit to not make your encodes straight out of the AE render queue … imagine if you had a 1 minute promo and it was a 3 day render because of a really complex project … and you rendered it out for the web … then the client asks for it on DVD … .you have to wait another 3 days!

  • Michael Duff

    August 17, 2007 at 12:13 am in reply to: Exporting problems/questions….

    4 hours to render a 4.5 minute clip is not uncommon .. most of this time is AE calculating what you have done in the project… like effects, motion blur etc … when you are rendering you can expand the “Current Render Details” box in the render queue and see what elements are taking longest to render … compressing it to cinepak or whatever isn’t really taking that long …

    so, if you are not positively sure of what final output settings you want, I’d recommend rendering an uncompressed (or lossless codec like animation) … and then compressing this file down for the CD using a program like Compressor or Squeeze … this way you can do it a few times to get it right without having to wait the 4.5 hours everytime … If you still can’t get a file size/quality that you want then try asking in the “Compression Techniques” forum …

  • Michael Duff

    August 16, 2007 at 9:22 pm in reply to: a technical pixel aspect question

    “It’s been quite an interesting discussion. My only Q for now is didn’t you say initially that they requested for 1024×576? And that now this engineer that you’ve spoken to says that anamorphic 720 is preferred”
    -these are different people/companies … the engineer I contacted is not connected to the initial request for 1024

    “The workflow that I suggested, working entirely in square PAR until the render stage, where you nest the square PAR comp into a non-square comp should allow you to view 720 anamorphic on your broadcast monitor prior to rendering.”
    – ok … well I think in a round about kind of way we do agree … that working in square pixels is better due to the way plug-ins and render engines approach pixels …. but final output at 720 anamorphic is best because that is how it is ingested at the television station.
    And if we already have a 720 16:9 render on our system and need to send it to a broadcaster .. it is best to just leave it as is rather than going through that resizing process.

    Thank you so much for your help with this … one more question though 🙂 How are you getting the quotes from my post in? I can’t find any buttons to insert quotes … I’m just cutting and pasting … maybe cause I’m on Firefox?

  • Michael Duff

    August 16, 2007 at 7:56 am in reply to: a technical pixel aspect question

    Hi again…

    “It is 720 wide if it the 16:9 is broadcast as 4:3, center-cut. BUT when the 16:9 is broadcast as pure 16:9, then you will get the full glory of 1024 pixels wide.”

    – I just got off the phone to an engineer at one of our national broadcasters (SBS) … and he confirmed that EVERYTHING that is broadcast SD PAL is 720. Whether it is 16×9, 4:3, everything .. there is no such thing as a 1024 transmission. Everything that a broadcaster receives gets ingested as a type of MPEG-2 at 720×576 … it is only the PAR that determines the final aspect ratio.

    “The fact that they do in fact broadcast at pure 16:9 should preclude you from wanting to provide anything at 720, unless it’s anamorphic. But from your initial post, they have requested for 1024×576.”
    -From the point above I’d now only ever want to provide everything (16:9 or 4:3) at 720 anamorphic as that is how it is going to be ingested.

    He also suggested that working at 1024 would result in an incorrect image on your broadcast monitor, because the 1024 is getting down sampled to 720 through your output card(ie for us Blackmagic cards). And that if you send a 1024×576 image to a broadcaster it will lose an every so slight amount of quality in the down sample when it is ingested.

  • Michael Duff

    August 15, 2007 at 10:27 pm in reply to: a technical pixel aspect question

    yep ..
    1) I agree and understand this
    2) yes I a agree
    3) yep agreed

    “Item 2 should show how 1024 gets cut down in size for 4:3 distribution” – Just to clarify this point .. you mean “cropped” rather than “re-sized” .. .right?

    I understand that 720 anamorphic is the same as 1024 square.

    But what I’m saying is… the actual PAL signal that is sent out from your broadcaster is 720pixels wide regardless of how you have provided it. So if we work in 720 anamorphic, then upsize to 1024 square, then transmit at 720 anamorphic there has been a redundant re-size and therefore a slight loss of quality …

    btw, earlier you said you always work at 1024 … do you also always work at 768×576 for 4:3?

  • Michael Duff

    August 15, 2007 at 3:27 am in reply to: a technical pixel aspect question

    ok … this could be much simpler… just for a moment … forget about 16×9 4×3 letterbox pan scan and everything above tv.

    You have a photograph in photoshop that is 500×500 pixels. You scale it up 500% and then save it. Then open up that new larger image and reduce its scale by 500%. You have an image the same size as the original, but it is now of a lower quality. Agree?

    Essentially that is what we are doing if we work at 720, deliver at 1024 and then broadcast at 720.

    does that help?

  • Michael Duff

    August 15, 2007 at 2:41 am in reply to: a technical pixel aspect question

    thanks again for the fast reply … but I don’t think you understand what I’m getting at .. I am in no way referring to letterboxing. I am only talking about true 16:9 that will fill a widescreen TV (and therefore I understand the sides will be cut off on 4:3, but the sides getting cut off is not what I’m talking about). and I am also not talking about actually pan-scanning an image and cropping off the edges in production.

    “Let’s see if this makes sense. If part of the width is thrown away, then it must also be true that part of the height is thrown away. This is the case for letter-boxed broadcast of 16:9 over 4:3.”
    -No, because I am not talking about letterboxing. I’m only talking about resizing the horizontal. Going from being an anamorphic 720 image to a 1024 square pixel image and back again..

    “In short, you’d still have to provide a full 16:9; 1024×576, non-anamorphic or 720×576 anamorphic so that they can do what it is that they do.”

    Yes, we could provide either… but what I’m suggesting is that EVERYTHING goes to air at 720 pixels on the horizontal (as per the document i linked to above). So if we work in 720 and then upsize that to 1024 those extra pixels have been interpolated. So we provide the 1024×576 image but it is still actually getting broadcast out of the transmitter at 720×576 anamorphic. So there are now less pixels on the horizontal ie some have been removed in the broadcasting process.

    Does that make sense?

  • Michael Duff

    August 14, 2007 at 10:50 pm in reply to: a technical pixel aspect question

    sorry, i’m just not convinced … i’m not worried about fitting a 16:9 image into a 4:3 screen by means of letterbox or scaling … I’m only talking about true, fullscreen, pan-scan 16:9…. When it is actually sent out over the airways… from the broadcaster … the signal that is sent out (according to that document i quoted above) is just 720pixels… regardless of if it has a 4:3 or 16:9 pixel aspect ratio…

    so if we provide a 1024 square pixel image … and it is broadcast at 720 anamorphic, those extra pixels do not exist .. they must be thrown away.

    do you see what I’m getting at?

  • Michael Duff

    August 14, 2007 at 4:26 am in reply to: a technical pixel aspect question

    thanks … i’ve only just had a chance to respond to your response… i’m not sure I completely understand the engineering side of this ..i know this is now getting beyond the normal scope of AE..but if someone could clear this up for me I’d be a happy nerd…

    This is where I’m getting all my engineering facts from … the FreeTV Australia Operation Practice OP-29 and I’ve uploaded it to http://www.duff.tv/temp/FREETV.pdf

    so…

    This is what I am lead to believe:
    For 4:3 PAL TV there was(is) 720 pixels on the horizontal. Engineers wanted to have a bigger/wider format that would work on the same bandwidth … and therefore a 16:9 pixel aspect was created… ie. still 720pixels wide but an anamorphic image that is then visually corrected at the receiving television set.

    See Page15 1.2
    “The Active length is defined as a nominal 702 pixels which represents the nominal PAL active line length (a line blanking width of 12usecs)”

    And see Page 16 for a diagram.

    And then, because we use computers to do much of our video work we decided to work in 1024 so that it ‘looked’ correct on a computer monitor.

    So if I work in 720(1.79:1) … and then stretch it out to 1024 to distribute to these people … where did the extra pixels come from? they have been interpolated right? then when it gets sent to air as per my quote above it is getting sent at 720? so it is getting unstretched. and therefore pixels are being taken out? hence a loss in quality because some of those remaining pixels are not original pixels but the interpolated ones?

    does this make any sense?

Page 10 of 43

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy