Jump to content

Javier Moreno

Members
  • Posts

    33
  • Joined

  • Last visited

  • Days Won

    7

Posts posted by Javier Moreno

  1. Hi David,

    We are trying to reproduce the problem, but unfortunately it is not happening in our systems. We just fixed a bug with the Move node than confused us a bit,  but it is not in  the Copy node and we can't reproduce it.

    If not yet, please could you try the same Workflow having both  folders in the system disk? (just to discard that  it is not related  with potential filesystem or network refresh latencies  )

    Any other detail you could think  to reproduce the problem?   

    Cheers,

    Javier 

  2. Do you mean the render speed? If it is HD it should render in a few seconds, or at 4k  less than one minute.   But I suppose  you may want to do some intermediate renders and adjustment iterations , as judging the optimal speed for something like  "sparkles" appearing and disappearing sounds to require realtime playbacks to evaluate it properly. It is not a case of applyng the effects and forget . Basically you will need to go trough  several "try and refine " iterations, rendering a realtime preview each time. 

  3. I would recommend  to experiment with a Noise and Glint effects. Animate the noise parameters, use a color grade to adjust contrast and pass the result to the Glint effect. Also compose with the original image. 

    But each software is going to produce a different result, if you like kiraKira I would recommend to  use it and then compose the results in Mistika.

  4. Hi Rakesh. Thanks for oyur honest review, it is very valuable feedback for us.

    About the clip replacement in Mistika, I am wondering if you could use this technique:

    1 - Hunt the replacement clip wherever it is. If you select  it in the media browser it will appear in the Source Monitor, or  if you prefer to select it in the Tiemeline then press Ctrl+C (Copy) to send it to the clipboard, which in Mistika just is the Source Monitor)

    2 - Put the Record Monitor (red bar) in the head of the clip to be replaced (or in any other in point you want it). Alternatively type the timecode for it directly.

    3 - Press SourceMonitor->Overwrite (the icon with a red clip going down into a green clip). Or directly use its hotkey (B) while having the pointer in the Source Monitor (hotkeys like this affect the marks of the panel where you have the pointer at that moment).  Whe  you do that, the new clip will we placed at the record monitor position while also overwriting whatever was in there. 

    The other icons near Overwrite are to insert (making space) or paste on top (similar result to a replace but you don't lose the original clip).  In all cases you can also use the yellow marks in the source monitor ( "i" and "o" hotkeys ) to define which part of the incoming clip you want to insert. Or just type its In / Out timecodes in there as you seem to prefer. 

    Regarding the interface, we are working in new capabilities to make it more scalable (for example to better support  4K GUI monitors). For example I think you could use a new scaling feature to mach the bottom screen of your laptop to the bottom part of the Mistika interface (menu panels in general), an let the upper screen for a clean view of the Timeline and Visual editor images. This scaling feature is still in development, but I belive a raugh version is already operative in your Mistika version (i suppose  you have 8.10, the one in our website ). It would work as follows: 

    1 - In Windows, define a single continuous desktop with one screen on top of the other

    2 - While in MistikaConfig-> General->AdvancedOptions,   select the Interface->Use Scaling button, and for Mon-1  select the scaling factor as neccesary to fit the Mistika botton panel in the bottom display of the laptop  (But do not activate "Two Monitors", as this proposal is a for a single (but elongated) monitor.

    This scaling feature is in development, in your version it can still have some refresh issues and some low res and aliasing at non integer scale factors in some widgets, but we hope to solve all this for next version 8.11.

    Please let me know if it works, I am curious. Sadly I do not have such wonderful laptop to try by myself. That  dual screen laptop seems to be a nice one!

    Javier

  5. For performance reasons some information like VectorPaint strokes, titles, morph, and data from 3rd party plugins are not saved in the .env file (which is a text file)  but in the PRIVATE folder of the project as binary data (which is faster). If you copy a project to other system you need to copy the whole project folder, not just the .env file.  

    • Like 2
  6. On 12/12/2019 at 12:20 PM, jan1 said:

    But taking just the plain 8K 60fps RED clip (the shark), I get a distinct 10fps advantage in playback rate on the Quadro card compared to the 2080. 

    That's an interesting test, thanks for the feedback.

    BTW for that particular format,  a key parameter is the Codecs-GPU frames. In general it  should be 1 for GeForce and 2 for the Quadro. (you could also try with 3, but I am afraid it could be a waste of memory) 

  7. On 12/12/2019 at 12:40 PM, jan1 said:

     The difference exists, but it requires extreme conditions to surface. 

    Well, it also depends on each client. The one case where Quadro is mostly preferred is  for client attended sessions, as  in those cases it is very desirable to have as much realtime playback performance and stability as possible.  

    • Like 1
  8. On 12/12/2019 at 12:30 PM, jan1 said:

    That means I'll have to quit Boutique instead of switching to Premiere or other software that may make extensive use of the GPU. At times as I conform I do keep multiple applications open.

    In a case like this you should reduce the memory related parameters ( Max cache memory, ring buffer, pipe units, render units, encode threads ).  That will free a lot of memory for other applications. 

     

    On 12/12/2019 at 12:30 PM, jan1 said:

    In this scenario there may be in fact a memory leak or software bug. 

     

    image.png.d0b7247a8161e96826407826a8231ded.png

    I totally agree, that memory curve is typical of memory leaks.  Otherwise it should look like a staircae . What is the exact  date of your Boutique version? 

    First thing I would recommend to render the source images to other format and test , as this test will show  if the memory leak comes from the decoder or from one of  the effects (in that case you would need to remove effects  one by one to see which one is causing it)

    Please if you don't mind  open a support case about the memory leak so developers can investigate it,  in that way it is much more efficient for them 

     

  9. In all those examples the bottleneck is the effect processing,  not the upload and download of images to/from GPU. So  the full duplex can not help on them  because at such low FPS speeds the PCie bus  is infrautilized anyway.  To take advantage of it you would need to build an example that is close to realtime, for example a more simpler stack that can deliver speeds  close to UHD 60p. In that scenery is where having  the Quadro can make the difference between realtime and non realtime.

    Also, if your storage is fast enough I  would recommend to use  uncompressed images like Mistika js format , exr raw or dpx. This is to avoid dependence on 3rd party codecs like Arri in a benchmark that  is supposed to be  about GPUs.

    Apart from this, one difference that should already be noticeable in your exanple is the advantage of the  double amount of GPU memory in the Quadro, as you said that using all of it.

     

    Even with that the GeForce has a much better performance / price ratio and it is  more than enough  in may cases,  there is no doubt about it. 

     

  10. Hi Jan,

     

    Depending on what you are doing Mistika will not return graphics memory buffers  (and neither buffers in RAM). This is made on purpose: In order to avoid memory fragmentation Mistika has its own memory manager , it will keep memory buffers and only reuse them with images of the same size.

     

    The collateral effect is that if your timeline contains images of different sizes or different  color spaces it will use more memory, but it is because the  performance is the priority by default.  If you need to reduce memory usage you can reduce related  parameters in mConfig (Max Cache memory,  ring buffer, pipe units, render units, ..). Alternatively restart mistika session from time to time depending on the content 

    Also please  keep an eye on task manager  about memory usage during playbacks . The memory use (both GPU and ram)  should only increase between clips with different needs, not between frames of a same clip (in that case we would be talking about a potential  memory leak / software bug)

    Please let us know the differences after testing with the other board. Your tests are very interesting.

     

     

  11. On 12/11/2019 at 4:22 AM, jan1 said:

     

    One thing I'm specifically looking for in this test - a way to see if Mistika can take advantage of the full duplex loading of the textures. Do you know if this test will stress this?

    It will use it if available, there is nothing to configure about it. To test it you can do a "complicated" playback (for example  a Comp3D  with some layers at a resolution that is near realtime in your system  but not realtime (this is easier to evaluate in UHD  60p modes), and make sure the disk speed is not the bottleneck. Then write down how many FPS you get on each case.  Use one GPU and then the other,  and in both cases  do one playback test to   the  GUI monitor and another one to the  SDI output,. The GUI playback may be similar for both models (as in that case there is not need to download images from the GPU), while the playback to SDI board should be faster on the Quadro, as it can download images for the SDI output at the same time that next frames are being uploaded. 

    Quote

    Also second question - if I have multiple GPUs in the system, is there a way of telling Mistika which GPU to use? I looked in mConfig and didn't see anything. I recall a support article mentioning this, but can't find it right now. I'm thinking of leaving one 2080TI in side-by-side to the Quadro RTX 6000 so it's easier to compare the two. Same question, can I tell Mistika to use one for the UI and the other one for all processing?

    I know Boutique is not multi-GPU enabled, which is fine. But can it be told which GPU to use if multiple are present?

     

    Regarding the GPU selection for Mistika , an  easy way to chose the GPU  is to connect the monitor to the GPU you want. By default Mistika will use the GPU connected to the display where it is launched.

     

    Another way is to  select the Boutique  icon and use the Nvidia or graphics processor applet in the control panel to define which GPU is used for that one. 

     

    Alternatively use right mouse button on the Boutique icon to open the contextual menu, there should be a menu to decide the graphics processor that is used. But this method requires to do it every time.

     

    Regarding the other question, Mistika can not use one GPU for GUI and one for processing directly.  But you can launch independent render jobs (rnd files) the other GPU , either by using "PathToMistika.exe/mistika.exe  -r  PathToRNDFile" command in a console running in  the other GPU ,  or by configuring a 3rd party render manager like Smedge to render jobs in the other GPU. (launch  Smedge in the other GPU by using the above techniques, or check Smedge documentation for more possible ways to configure this )

     

    • Like 1
  12. Mistika Boutique is agnostic in terms of the operating system and hardware brands. Most of the software is open-gl based, which should run at similar speed on Windows and Mac.

     

    However, there are some differences in these particular  codecs:

     

    - RED has launched a new Cuda decoder  for R3D files. Currently it only works with NVidia boards,  and Apple does not support it.  But R3D files still work on Mac with the traditional decoder based on CPU, so if you go the Mac route and you need R3D just  try to get a good CPU with as many cores as possible, and of the  highest clock speeds.

    - NVidia has also launched a hardware encoder for H264 & H265. But by now Apple does not support it, so it only works on Windows and Linux 

     

    Regarding Afterburner, we have not made any tests with it yet. In principle, Apple Prores formats are already   pretty fast in Mistika by just using  the CPU, as Prores playbacks  have  been troughly optimised in Mistika . With good CPUs they are already  realtime at  4K 60p, and also in some 8K 24p variants. But if we see that our clients start  requesting  this capability of course we will try to implement it in the future.

    Regarding your question about our tests on  Windows hardware , our developers and engineers typically test every  windows version  on Hp workstations (z820, z840, Z4 and Z8),  also using several models of Intel CPUs and different  NVidia boards. But it is also tested in other brands whenever we have opportunities.

    Regarding GPUs for Windows, the sweet spot seems to be the 1080ti for computers with no video boards,  and the P5000 ( or even P6000) for high end systems with video boards . RTX equivalents are also great , but they are similar in speed and are probably more expensive just  because they are newer. RTX have more capabilities for other markets like gaming and machine  learning, , but for the particular case of Mistika they don't come with significant advantages over the previous generation. In any case just check the cost factor  because it  is constantly changing.

    Regarding the computer brand, what we can say in general is that Mistika seems to be  equally stable in computers of  well known  brands,  but we have seen quite a few  support cases where custom-built computers were unstable due to using PSUs with not enough power or due to thermal issues. Those are the two main  aspects to check when not using a volume brand.

    Also, we maintain a document with recommended configurations here:

     

    https://support.sgo.es/support/solutions/articles/1000269519-recommended-configurations-for-mistika-boutique

     

    • Like 2
  13. Also, if it is about economics a good way to save money is to use 1080ti or a P6000 (even if second hand), as the RTX does not really provide performance gains for the particular case of video processing in Mistika, only in rare cases.  But If you want RTX , the RTX 5000 is probably the sweet spot.  It is close in performance to RTX 6000, although with less memory. 

    Personally, what I would do is to  check how much graphics RAM you use in your most complex timeline (after working for a while on it and passing trough all the Timeline). You can see that in the Task Manager (look for GPU options).  I think it s the best way to choose the right model if you are in doubt.

     

  14. Regarding NVidia I do not have documentation, but it is easy to see. Just play a complex timeline (for example at 4K with a Comp3D having  multiple layers and you will see)

     

    Apart from that, Quadro boards are recognized to be more stable and long lasting under heavy rendering over the time. We have barely seen any Quadro burned over the years, but many GeForce were fried.   In principle the price difference still does not compensate for this, as you can always buy the next GeForce when the previous one is burned, thus having the new model  and still saving money.  But if you work in client attended sessions or very tight agendas you may think differently. 

     

    • Like 1
  15. The  main differences are;

     

    - The amount of graphics memory. If your tiemeline does not need the etxra it does not make any difference,  but if it need it the Quadro will be much faster, as otherwise the GeForce will swap to system RAM or even crash at some point.

     

    - The Quadro upload and download textures in full duplex mode troufgh the PCIe bus, it can be upload image layers for next frame while  downloading the previous frame at the same time. This is specially important at high resolutions, and it makes a significant difference in realtime capabilitiesplayback 

     

     

    • Like 1
  16. Hi Jeff

     

    32 GB can be enough for most 4K workflows, but it depends on what you are doing.  For example color grading requries few RAM because it is just one effect, but complex finishing /VFX may requier a complex  stack of effects.  Specifically these are the points that are known to use a lot of RAM

     

    - R3D codecs are specially hungry in terms of RAM usage.  A common situation is that many users are doing 4K production but they are using 6K or 8K  raw camera files, which require up to 4 times more RAM.

     

    - Another situation is when using different resolutions in the same Timeline during the same session.  Using different resolutions is perfectly supported but it requires extra RAM. This is because in many cases Mistika will only reuse memory buffers of one particular size for images of the same size during the same Mistika session, ( otherwise the performance will be severily reduced due to memory fragmentation).

     

    What we recommed is to load the most complex timeline in terms of the above issues and keep the Task Manager open while you work. In this way you will know how much RAM are you using exactly.

     

    Regarding the performance settings, 0 means autoconfiguration  (but only for the "Parallel processing " sections).  If one of those setting s is 0  Mistika will assume the number of cores of your system for that settting,  except for the case of Render Units which is half of that number, as explained in the panel itself).  Also, the autoconfiguration will use  a limit of 24, because higher number of threads are inefficient in most cases (please note that many codec libraries also split each call into several threads, so you could easily saturate the system by going to high with these numbers).  However, the optimal number for each particular situation can only be found experimentally.

     

    Also, Mistika Boutique can only use one GPU (the one were you start the software). 

     

    Regards,

     

    Javier

     

    • Like 1
  17. yes it uses the render engine, but you can still have control:

    - If you need access to pixel values, insert a GLSL effect in  a display filter from Ultima or  Boutique (several workflow nodes have a display filter parameter ).  GLSL is a programming language (an evolution of GL )specialised in image processing,  so you can not write python code to process pixel information but i you could do it in GLSL 

     

    - Regarding the metadata you mention (resolution , fps, etc) a good part of it is stored in task node parameters that you can read, and also  change depending on the case.

     

    Some other metadata is not accessible as node  parameters but you could still read it and  change it, as a workflows project is just a  text file, and also the rnd, clip metadata (.clp files  for rendrded clips and .lnk for source media ) and display filters, as everything else  in Mistika (there are no binary databases , just text files) . Just importing media files in Mistika Boutique will read all the significant metadata from the source media files and it will  put it in ".lnk" text files in your project in a coherent manner ( a same script will work for all formats ) , so you could get it from there.

    However, for some of the cases I mention  you will also need Mistika Boutique, not only Mistika Workflows  

  18. On 6/18/2019 at 5:11 PM, hendrik said:

     And is there way to intercept it (the actual image data) with Python?

     

    Not directly in Python, but you could try the following (not sure if it works for your purposes):  First create a display filter in Mistika Boutique including  a GLSL effect, which can load a user script written in glsl language. Then apply that display filter  in a workflow node.  When executing  that node the image data will be passed to your GLSL code, which could do any  transformation to the image as desired. 

     

     

     

  19. Hi are you sending the audio trough  the Aja board or trough the  motherboard?

     

    To confirm If it is a codec issue or not , try to get some footage with any other codec (Prores, Avid mxf, ... ) and see if it also happens.

     

    Then, if  it is an issue of that specific   codec issue   I would recommend to open a support ticket and send a link to one of those files, so it can be further  investigated by Mistila developers 

    • Like 1
  20. Hola Manuel,

     

    Las carpetas a usar  las pregunta durante la instalación, no estás obligado a usar las que vienen predeterminadas.

    La carpeta de proyectos es donde Mistika crea cada proyecto (cada proyecto se guardará en una subcarpeta  de ese sitio). Y si que tiene gestor de proyectos, solo que este está ya dentro de Mistika , no en la herramienta de configuración (por lo que no sale en ese vídeo) . Cada proyecto puede contener muchos timelines diferentes e incluso subcarpetas que vayas creando para organizarlo. Es decir, en Mistika  un proyecto no es "un timeline" sino típicamente el nombre genérico de una producción completa que puede contener muchas versiones, pruebas, renders, referencias  a la media importada, etc.

    Por otra parte, la otra carpeta que se pregunta es para la media por defecto. Esto simplemente es para que cuando haces render (o una captura de video) ya te proponga un path por defecto bajo ese sitio, pero siempre lo puedes cambiar sobre la marcha. De hecho el "path builder" (accesible tanto desde la herramienta de configuración como desde las opciones del panel de render )  te permite definir presets con sintaxis a media, para definir donde y como quieres construir los path de directorios destino  y nombres de fichero de la media producida en los procesos de render. De esa forma no tienes  que definir el path en cada render, solo elegir el preset que quieres.

     

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.