Waldorf & Statler

My feedback

  1. 11 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Premiere Pro » Import  ·  Flag idea as inappropriate…  ·  Admin →
    Waldorf & Statler supported this idea  · 
  2. 3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Premiere Pro » Formats  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Waldorf & Statler commented  · 

    Dear colleague,

    in my opinion the error is not a transcoding error,
    special an interpretation of the DNxHR 444 codec.

    DNxHR 444 is a YUV codec.
    YUV is usually a legal range codec, with DNxHR 444 the codec is definitely defined as legal.
    RGB is mandatory full range.
    But 444 is not just RGB.
    What is the same for RGB and 444 is the fact that there is information in full color and brightness for each pixel, but that does not mean that RGB = YUV.

    Since ADOBE, in contrast to all other manufacturers, is of the opinion that RGB = YUV and correspondingly full range, correct material is misinterpreted and loaded into ADOBE Tools.
    After that, the ********* is perfect, whether transcoded or not.

    Unfortunately, ADOBE hasn't changed that for years
    nor does it explain what your reasons are.

  3. 13 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    10 comments  ·  Premiere Pro » Formats  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Waldorf & Statler commented  · 

    The ticket was founded in 2018,
    now it's 2021 and nothing happens.
    What is the reason for this platform if nothing happens ?!
    A start would be to explain why you don't change it
    or to explain that one understands full range and legal rage differently.

    Waldorf & Statler supported this idea  · 
    An error occurred while saving the comment
    Waldorf & Statler commented  · 

    The codec is supported by ADOBE!
    But wrong!
    DNxHR is YUV Codec and accordingly works correctly
    as a legal range codec.

    ADOBE think, that 444 = RGB but this is wrong.

    You can convert from 4: 4: 4 without losses (pixel by pixel) to RGB
    but = that is not correct.

    The interpretation of some ADOBE managers, which can be seen as a full-range codec, is technically wrong and not professional.

    Greetings to those responsible for Lars Borg,
    why is your ProRes 444 interpreting correctly?

    The earth is not a disk, in our industry you work with many different tools, so you have to be able to rely on standards.

    Also, why do other tools correctly interpret Full or Legal? Why can't ADOBE products do that?

    Why can you set this as an artist for other tools?
    Why is that not possible with ADOBE products.

    We open tickets on the subject of being over 2 years,
    why is there no solution?

    An error occurred while saving the comment
    Waldorf & Statler commented  · 

    ADOBE hat das bis 12/2019 nicht hinbekommen

  4. 214 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    22 comments  ·  Premiere Pro » Playback  ·  Flag idea as inappropriate…  ·  Admin →

    Hi Taran and everyone subscribed to the thread,

    first of all: thanks for the incredibly detailed suggestion and the great conversation in the comments. While making such a change for the playback engine has a ton of implications and therefore isn’t done ad hoc, we’re certainly going to create a POC for it and will evaluate if there’s a way to put this into a production build for a test drive in an upcoming beta version.

    I’ll keep you posted.

    Cheers,
    Patrick

    An error occurred while saving the comment
    Waldorf & Statler commented  · 

    In my opinion it is important to know the different GOP structures. In my opinion, Long-GOP is for consumers and I-Frame is only for editors. We recommend our editors to convert long GOP files in the ADOBE media encoder into e.g. ProRes I-Frame only and to cut them with it.
    This is how it works with the fast search, e.g. with JKL.
    If you have previously generated a watch folder for such tasks, the job is very easy to do next to.

  5. 2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Premiere Pro » General  ·  Flag idea as inappropriate…  ·  Admin →
    Waldorf & Statler supported this idea  · 
    Waldorf & Statler shared this idea  · 
  6. 1,584 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    569 comments  ·  Premiere Pro » Formats  ·  Flag idea as inappropriate…  ·  Admin →

    Thanks for all the feedback. It’s pretty clear that we’ve got to look into the workflow using this format more closely, there are enough reports about gaps at this point to reopen this item. I’ll post more info about next steps shortly. In the meantime, a couple of questions are easy to answer:

    - The plugin is designed for Premiere Pro. It currently doesn’t provide support for After Effects.
    - It does work with AME, so if you want to use it for batch processing, that’s very doable
    - If you’ve started a project with Autokroma, there’s no easy way to transfer it to be running with the new plugin.

    Patrick

    Waldorf & Statler supported this idea  · 

Feedback and Knowledge Base