We've given up on all mp4 generation with Nuke. The quality is always horrible, it is really slow and it only embedds it in a mov container which makes where it can play very limited where an mp4 container can play just about anywhere. One thing to note, the bitrate knobs are all in bits, not kilobytes, so you have to make that number really big to get anything of use.
We've instead moved to writing an intermediate jpg sequence out of Nuke so the color is already burned in and then use ffmpeg to write out all mp4 creation. Ffmpeg does have direct EXR read but it's lut support doesn't have shaper support and if the bbox and display window is different it breaks so we really can't use EXR with it. Another option I need to evaluate is if we could use OIIOtool's exr & ffmpeg support to go direct to mp4. On Mon, Feb 22, 2016 at 9:43 AM, Ryan O'Phelan <designer...@gmail.com> wrote: > Hi guys, > I'm using NS 9.0v8 on Windows 7. > I'm rendering an h264 (multipass) half-size edit right now. It's simply an > h264 previs chopped up in to 20 shots, with audio. It's about 90 seconds > long. There are some burn-ins, and one text node with a very simple > expression [expr [value frame]-240]. > > Strangely, when I render, the mouse blinks with an hour glass, and it's > taking much much longer to render than any other render that I've done in > the past. > > Any tips? > > Thanks, > Ryan > > On Tue, Jan 5, 2016 at 11:30 AM, Henrik Cednert <n...@irry.com> wrote: > >> Aaah. Personally I don't use comp containers. I never fancied that >> workflow and had performance issues with it when it came out. Still using >> the Hiero workflow here. >> >> -- >> Henrik Cednert >> cto | td | compositor >> >> Filmlance International >> Cell +46 (0)704 71 89 54 >> www.filmlance.se >> >> On 04 Jan 2016, at 19:07, Ned Wilson <nedwil...@gmail.com> wrote: >> >> Henrik, >> >> I’ve found that having comp containers in a timeline, especially a lot of >> them, like, more than 50, produces disastrous results. My workaround was to >> disable the comp container track, and to create a new track above it that >> just contains the rendered frames. >> >> I have gone back and forth with Foundry support on this since the Nuke >> Studio beta in 2014. It has been pretty frustrating with a lot of ‘we can’t >> duplicate this on our end’ and ‘send us footage that we can test with’. >> Disabling thumbnails is a decent work-around (thanks, Deke) and I think >> that combined with mine, it should ease your performance issues somewhat. >> >> -n >> >> On Dec 18, 2015, at 1:42 PM, Henrik Cednert <n...@irry.com> wrote: >> >> What Deke said! =) >> >> I did use those env var’s when troubleshooting this when we used Hiero, >> like two years back. Didn’t solve all my problems though, but it might have >> been a multilayered issue and that the thumbs only was one part of it. Will >> try those again after christmas and see how it goes. >> >> What puzzles me is how not every single programmer can be assigned to fix >> these fundamental flaws that’s been in the app from day one. And that time >> instead is spent on implementing new stuffs (…that eventually will be >> abandoned in a half working state). >> >> Sorry if I sound pessimistic in this thread. Guess it’s more a huge >> sadness then anything else. I know what nS could be and the potential >> that’s there. I just don’t understand why it’s not taken to those heights. >> =( If they don’t fix this and the other fundamental flaws in nX/nS10 i’d >> say it’s pretty much over. At least for me. Not that they or any one else >> cares, but still… >> >> Cheers >> >> -- >> Henrik Cednert >> cto | td | compositor >> >> Filmlance International >> www.filmlance.se >> >> On 18 dec 2015, at 21:04, Deke Kincaid <dekekinc...@gmail.com> wrote: >> >> Another thing you can do to speed things up is disable thumbnail >> generation. They are god awfully slow, especially on quicktimes. Also for >> whatever reason I think it still runs in the main thread so they have to >> all generate for all your bins before you can do anything. The caching of >> the thumbnails is really poor. Again, maybe bad memory but I it feels like >> it either regenerates them every time you open a session(whether they or >> cached or not) or for some reason it has to stat every single file in the >> main thread which takes equally as long. >> >> HIERO_DISABLE_THUMBNAILS >> HIERO_DISABLE_THUMBNAILS_CACHE >> >> Working on a long project in Hiero makes me beat my head against the >> table. I wish Resolve was scriptable. The NS timeline is fairly easy to >> automate but really slow to use and really horrible with quicktimes or you >> have Resolve which is super fast and it actually supports modern file >> formats but is completely manual. Both of them have horrible color >> management tools as you have to resort to the nodegraph in both to do any >> real color work. I wish there was something in between. >> >> >> On Thu, Dec 17, 2015 at 1:10 AM, Igor Majdandzic < >> subscripti...@badgerfx.com> wrote: >> >>> This reflects pretty much my experience so far. Thanks for this >>> conscience rundown. >>> >>> >>> Am 16.12.2015 um 08:23 schrieb Henrik Cednert: >>> >>> Yes. We use it, or rather try to use it, for long form and 45-60 min >>> episodicals. The quicker you accept that it's not usable for this the >>> better of you are. Sadly. They say that nS10 will improve this enormously >>> but today it's a disaster. It's been like this for day one and I and others >>> have loudly complained but without luck so far. Please send your experience >>> to support so they can log it and so that these issues are up voted. >>> >>> Some people have resorted to work in reels instead of whole timelines. >>> That's not something I'll ever do though. Wouldn't fit my working style and >>> would only mean. I would have 4 projects open at the same time, which >>> wouldn't help. >>> >>> A few of my "workarounds": >>> * only conform the VFX shots. Never conform the whole timeline. If >>> needed for review, conform a few shots before and after VFX. >>> >>> * never copy all cuts to the reference media. We export reference into >>> our comps but we only slice up the parts where there's VFX shots. NS chokes >>> with many cuts/items. Also play with different formats of your reference. >>> Noticed that codec of your reference and also the codec of the audio in it >>> can affect performance a lot. Not sure what's the best though. If you find >>> out, let me know. =) >>> >>> * save a lot because it crashes a lot. >>> >>> * also, even though it can take a good 10 minutes to restart it... Do it >>> regularly since a restart of it normally tends to give you 30-40 mins of >>> less lockups, until it have leaked and filled your memory again. >>> >>> * if there's something like 'Sudu purge' or other memory purge solution >>> for Windows, try that. Monitor your memory and see how it's used. Even with >>> 128 GB RAM it will eventually come to a halt but it'll give you a few more >>> minutes at least. >>> >>> Also, have a few spare keyboards handy. Have out of frustration hulk >>> smashed a few myself. The marketing of nS doesn't really reflect the >>> reality of it atm. =/ >>> >>> >>> Cheers >>> >>> -- >>> Henrik Cednert >>> cto | td | compositor >>> >>> Filmlance International >>> Cell +46 (0)704 71 89 54 >>> www.filmlance.se >>> >>> On 15 Dec 2015, at 18:45, Charles Bedwell < >>> <charles.bedw...@encorepost.com>charles.bedw...@encorepost.com> wrote: >>> >>> Is anyone out there having terrible performance issues with Nuke Studio >>> when in the timeline? >>> >>> I have done a conform on a show roughly 90 minutes in length and am >>> going through shots preparing notes, making comps, tagging, setting >>> reference media etc and every 1-2 minutes I'm getting about a 30 second >>> lockup. Just now after I had left the workstation untouched for an hour I >>> selected a shot and added a note and it locked up for a minute while I was >>> typing it out. >>> >>> I've noticed creating a comp from a clip can take an extended period of >>> time (many minutes) while a single core on the PC is at 100% with the other >>> 23 sitting idle. >>> >>> Is there anyone successfully using Nuke Studio for long form? I had >>> engineers from the Foundry visit a while ago looking at lookups when >>> creating comps but I never heard back from them. Disabling shot thumbnails >>> hasn't made any difference. There is no way anyone can work like this for >>> any length of time! >>> >>> Charlie >>> >>> >>> >>> >>> This e-mail and any attachments are intended only for use by the >>> addressee(s) named herein and may contain confidential information. If you >>> are not the intended recipient of this e-mail, you are hereby notified any >>> dissemination, distribution or copying of this email and any attachments is >>> strictly prohibited. If you receive this email in error, please immediately >>> notify the sender by return email and permanently delete the original, any >>> copy and any printout thereof. The integrity and security of e-mail cannot >>> be guaranteed. >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> >>> >>> _______________________________________________ >>> Nuke-users mailing listnuke-us...@support.thefoundry.co.uk, >>> http://forums.thefoundry.co.uk/http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >> >> _______________________________________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> >> _______________________________________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> >> _______________________________________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> >> _______________________________________________ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> > > > _______________________________________________ > Nuke-users mailing list > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >
_______________________________________________ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
