Skip to main content
T
Trenton5EC4
Inspiring
November 4, 2023
Question

Accessing and Dealing with Pixel data in AEGP

  • November 4, 2023
  • 1 reply
  • 531 views

Perhaps its simply a misunderstanding in how things are supposed to function, but how exactly do you use render options suite and such when dealing with a worldH?

I understand this gives the source pixels and not the effects altered pixels. 

Essentially I have a function that pulls frames at 't' time, and I'm able to extract them for passing into another function.

I have a second function essentially doing the reverse that replaces pixels of a given itemH (in both cases its the compItem). This works sometimes?

However, when I try to access multiple frames by running my single frame function in a loop across the duration, it ends up leading to a crash. I assume this is probably memory or lifetime related, but I'm wondering if anyone has any suggestions regarding these issues, or suggestions regarding how to better get pixels from multiple frames.
Essentially I create a class using my itemH, and then in a loop I pull the images at different times using the 'frameAtTime' method.


Code links;
Item Class:
PyShiftAE/src/PyShiftAE/PyShiftCore.cpp at main · Trentonom0r3/PyShiftAE (github.com)
CompItem (Extends Item) and the method causing trouble;
PyShiftAE/src/PyShiftAE/PyShiftCore.cpp at main · Trentonom0r3/PyShiftAE (github.com)
Python bindings;

PyShiftAE/src/PyShiftAE/PyLink.cpp at main · Trentonom0r3/PyShiftAE (github.com)

On a side note-- would creating an "invisible" effect that is loaded/unloaded to a layer when a specific AEGP call is made be feasible/reasonable to work around this?


    This topic has been closed for replies.

    1 reply

    S
    Community Expert
    shachar carmiCommunity Expert
    Community Expert
    November 4, 2023

    dude... that's a lot of code to go through...

    let's go through the basics:

    1. are you relaseing the gotten buffers after you're done with them? otherwise AE won't release the memory.

    2. are you modifying the gotten buffers? becuase that's a big no no.

    3. perhaps you're accessing these buffers after you've already released them? because AE may have reused the bit of ram for something else.

    4. this also smells like buffer overrun. many of the crashes i enountered in AE where it crashes in some seemingly onrelated area or after the call to the plugin has returned, it turned out to be a buffer overrun.

    T
    Trenton5EC4Author
    Inspiring
    November 4, 2023

    From what I can tell, everything is released. Each call in has a call out.

     

    I think the issue may be related to call count per AE call? 

     

    If I access various items at once (ex, in a single command hook or idle hook call, I loop through frames) it crashes, but a single loop iteration runs fine.

     

    I think perhaps I need to restructure my code so that 1 call into AE = 1 AE action, so that anything running as a loop has to call the AEGP each time for the loop, instead of one AEGP call running the whole loop?

     

    In that case I'd have to maintain some sort of cache/state to revalidate comps/projects/etc?

     

    S
    Community Expert
    shachar carmiCommunity Expert
    Community Expert
    November 5, 2023

    there shouldn't be a limit on how many chackout requests you can make during one call. at worse, AE would return an error code saying it failed or ran out of ram.

    the only reason i can think of that would justify separating the buffer checkouts to different calls is if you want to reduce the time your call spends processing so it would not cause the UI to lag or hang.

    since i doubt the problem is the number of the requests, then separating them to different calls would keep the problem lurking in the shadows until it manifests at random times that are much harder to track...

     

    i suggest you start commenting out bits of your current code until you hit the one line that causes the crash. when you do find it, try reversing the commenting, meaming keeping that one line (and whichever minimal functionality around it that is required) to see if it's indeed that one line, of somethig else that interacts with it. why? because the checking out might not be the problem. perhaps some piece of mem writing down the line does the damage.

      Terms & ConditionsAccessibility statement
      Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices