Clip freeze at start

Hello,

For the story: For a theater company, I am moving a show from QLab/MadMapper to Millumin Demo, to see which one we'll use for next shows.

My problem is: when I launch a clip it freeze around 0.5 seconds on the first frame then the clip runs normally. I've tested several file size, from 100MB to 2GB, and with optimized or not videos but the problem is still there. 

Any idea about this problem?

Thanks

Comments

  • Hello @xenatis,

    Millumin is automatically preloading movies, so they starts instantaneously :
    - What is your mode : 32 or 64-bits ? (see Prefererences, probably 64-bits)
    - What codec do you use ? You should use Photo-JPEG.
    - Did you check that your drive is quickly enough to playback all your files ?
    - Did you change the "start-point" of your movie ?

    Best. Philippe
  • Hello,

    - 64bits mode
    - Codec: every file is in Photo-JPEG, converted from "Apple ProRes 422 (HQ)" by Millumin
    - Drive is SSD : "APPLE SSD SM512E Media"
    - Start point for all movie at 00:00:00








  • Hello @xenatis,

    This is strange : nothing seems bad here.
    Could you send us a minimal project via Dropbox or WeTransfer (with only one media if possible) to contact@millumin.com ? Thank you, we'll study this issue.

    Best. Philippe
  • It is happening on both my machines now too.
    Everything was in HapQ or Hap Alpha, now I am converting to ProRes as HAP is suddenly "experimental".
    Will have to re-render ALL my clips before I can see if that helps. 
    A simple show that would previously play 6-8 layers of 5172x1200 at 60 fps is now choking on 3-4 layers and goes from 60 to 12 fps, really bad and impossible to use for a job.
    I don't know if it's 10.10.5 or Millumin, but I wish I could have it like it was this whole year since HAP came out.
    I load the same shows I did already and the problem is there on both machines - glitches and low frame rate, then settles to half the normal framerate. Will spend my weekend reinstalling OSX as this is useless for shows now.
    BTW, why is HAP now "experimental"? The combination of HAP and Millumin made it the best combination for high framerate, high rez video, why screw with it now? 
  • Also, Hap-Alpha to ProRes444 conversion removed the alpha on all my clips and now they are all black. 
    There is no way I will be able to run 8 layers of PhotoJPEG in high resolutions, with some alpha channels and at 60 fps.
    Please bring back support for HAP or something else that uses the GPU, as the Photo JPEG is just too primitive and old to do what we were already able to do.
    As Millumin is the end of my chain, I adjust everything to it, from creating content in AE or C4D, always making sure it will be pixel perfect and with a supported codec and framerate. 
    I also added PCIe drives to both systems hoping to go for even more layers than before (please see attached photo) but I can't even play my old shows properly now.
    I remember I used PhotoJPEG last year before HAP 64 came out and it was horrible. Image quality is better, but frame rates are pathetic and I don't want to go back to those shows where I have 20-23 fps and it all looks like it is going to get stuck any minute.
    Please bring back HAP support as it was for those of us who want to use it and who invested in Nvidia cards just for this purpose.
    20150821145339.jpg
    1280 x 723 - 225K
  • Hello @alenmecan,

    Nothing have been changed with HAP support : HAP can be used in 32-bits mode, but if there a few minor issues in 64-bits so we cannot recommand it for now. We need to investigate such minor issues (in few cases, bad compositing, small delay before start) and learn where it comes from (OSX, Millumin, the codec, OpenGL, ...). Please read this thread for more information.
    Keep in mind that Vidvox published HAP support in 64-bits very recently (8 months ago).

    In brief : if you're not affected by such minor issue and you're happy with HAP in 64-bits, you can keep it.
    Of course, performance of HAP in 64-bits are better of Photo-JPEG or ProRes, that's why you see such a difference.
    We hope to fix the minor issues soon, and HAP in 64-bits is very important to us.

    The problem of Xenatis is different, and we're already in contact with him for a solution. We'll update this post regarding our progresses.

    Best. Philippe
  • Thank you for this explanation,
    s there a way to go back to 10.10.2, and that version of Millumin with Hap64 from January?
    It is lot easier for me to install the OSX and drivers than to re-render everything - also PhotoJpeg is too much for my projects, it is CPU only and there is no such CPU!
    The Xenatis problem I also have and it is weird that it happens not on all layers - usually the largest file is the one that has this glitch. 
    Sometimes if you have a same video file left and right, one will have the glitch and will be out of sync.
  • Hello @alenmecan,

    We didn't change the Hap64 support since its release. However, it seems that latest Yosemite version caused glitches with Hap64 : nothing sure for sure, and we need to investigate.
    There must be a method to go back on a earlier version of Yosemite directly, but reinstallation is probably better.

    Xenatis is different : he doesn't have glitches but a small delay before its video starts. We'll update this post regarding our progresses.

    Best. Philippe
  • Hello @xenatis,

    In the last version (1.61), we fix a bug between loops and OSX Yosemite (and also improved loop playback).
    Please update, it should fix your problem.

    For the record, @alenmecan solves its problem by reinstalling its Hackintosh.

    Best. Philippe
  • This problem still exists in the beta or release version of Millumin V2. It doesn't matter which codec is used (H264, ProRes Proxy, PhotoJPEG....)

    It seems it has something to do with the caching/buffering of OSX VTDecoderXPCServise. For the first time of decoding it takes some time to buffer the first frames. If some seconds are already decoded and are buffered (when jump back in the last column), the clip starts immediately.

    I checked the "force movie preload" option, but this has no effect on the problem.

    Is there some other solution right now?

    best Regards
    Daniel

  • I forget, the problem is not the freeze of the following clip. There is a freeze of the current clip, which freezes until the next clip could be played. So maybe it would be a solution to play the current clips as long as the next clip is really ready to play?
  • Hello @dangrau,

    Millumin optimizes movie preloading (in the dashboard as well as in the timelines). So movies can start in a spurt.
    Let's check some things :
    - What are the recommandations listed after your hit the "Optimize" button ? If some, execute them.
    - Do you have the issue with latest Millumin V2+ beta (2.20.e) ?
    - Do you have audio inside your movies ? If so, do you have the problem if you play your audio through Mac's built-in speakers ?

    If the problem persists and for better ticket management, please send us your project (only the .millumin file) and the description of your setup (version of macOS, Mac model, graphic card model) to our email support : contact / millumin
    After our investigations, we'll update this thread accordingly.

    Best. Philippe
  • Hi Philippe,

    With the latest beta 2.20.e it works like a charm!

    Great job!


    best regards
    Daniel
Sign In or Register to comment.