because those are taken from the input file characteristics and passed along. If you used a yuv4mpegpipe, there is header information, and thus no need to enter those characteristics like framerate, resolution etc. The benefit of a raw pipe is it's the most compatible with everything - it "looks" like raw data. You need to specify the resolution, because it's a RAW pipe. If something works with the vdub external encoder through stdin - it will definitely work directly without vdub. But you're not using that, you 're using the original convert.exe ) (BTW - It's not "Wilbert's Imagemagick" program - he just made the avisynth adaptation of it. Post your console log, what error messages are you getting? Run taskmanage while you are debugging this and monitor your memory usage ![]() ![]() ffmpeg and convert definitely work with UHD, 4K, and higher. ![]() The same HEVC encoder set (or any other encoder set for that matter) in Virtualdub will accept any supported resolution using the "-" stdin which is why I'm confused that convert.exe and ffmpeg.exe are not allowing me to do my higher resolution files since they both accept stdin and why it's making me give it an output resolution since it sees the input resolution through the pipe. At least it will open the files if there aren't too many frames and I can cut the psd files in half and make multiple avi which I can append in Virtualdub and use the external encoder to encode the final file if I have to. x264 was slow also trying to do these large resolution files before and although if I try to open too big of a file in Gif Movie Gear, I will run out of memory. MY PC isn't fast enough and doesn't have enough memory to do 8K anyway but it does 4K fast enough. I know there were large Tiff files back then but nobody was using them in video files since videos larger 128x96 - 352x288 were hard to find. I guess that Wilbert's Imagemagick program is just way too old to support very high resolutions. I've still been trying to get convert.exe and ffmpeg to work but although ffmpeg claims to support a bunch of ultra high definition files, I'm not getting any encodes higher that 1920x1200 to work. (Not sure if libx265 / x265 has it yet, but x264 has -tcfile-in to encode VFR directly) ![]() MKV and MP4 containers do, however support native VFR - you would need to mux in a timecodes if you wanted VFR. But you can do the equivalent of VFR in CFR terms by inserting duplicate frames - the functional equivalent of an increase in frame on screen time (of course, that's less efficient, even with b-frames in HEVC or AVC). Vdub doesn't support VFR because of it's AVI/VFW heritage. Variable frame delays in gif are essentially "VFR" in video. Ok, if you need to do other manipulations, of course you can't pipe directly to ffmpeg and encode the final format Then Virtualdub to set the framerate, maybe put transitions between frames, add audio if it's a music video, test the way it plays and make sure that I haven't missed anything like black on the edge of a white background where there was transparency that I didn't get covered before encoding to x265. Some animations I need one frame to stay open longer than the next (say I'm using text that can't be read in 5 seconds). psd (all the layers of my animation, usually less than 100, sometimes only 10 or 15), GMG to set the speed of the animation, catch any mistakes and fix with live edit in Photoshop. Now you've gone and taken all the fun out of it I use Photoshop to create the.
0 Comments
Leave a Reply. |