I'm pretty sure the huffyuv version is encoded as YV12 and I'm pretty sure when it's opened in a player and decoded via directshow it's decoded as YV12. I think you're correct but I'm not sure who's fault it is. And as it is not yet possible to restrict what input MagicYUV accepts, and it doesn't do any colorspace conversion of the input, it probably actually compressed YUY2 (instead of YV12). The file becoming bigger for MagicYUV from huffyuv source in fast recompress is due to (I believe) the fact, that huffyuv tends to ouput YUY2 even if it is compressed YV12. When viewing the huffyuv encode with MPC-HC, ffdshow reports the output as NV12 (as it usually does when decoding YV12 with MPC-HC). I even encoded it again using the "force input colorspace option" and setting it to YV12 and the file size after encoding (from the original video) still remained unchanged. Maybe the huffyuv version isn't YV12, although as best as I can tell it is. Someone will have to explain the speed/compression changes for me. Input and output file sizes were exactly the same. Huffyuv (ffdshow variant, adaptive huffman tables enabled), 4 min 38 sec, CPU 55%, 5897MBĪnd with huffyuv as the source, huffyuv slowed down too. Lagarith, (no mulltithreading), 5 min 29 sec, CPU 55%, 5404MB With huffyuv as the source Lagarith slowed down quite a bit. Lagarith, (mulltithreading enabled), 4 min 54 sec, CPU 65%, 5404MB With huffyuv as the source MagicYUV was faster. MagicYUV, (mulltithreading enabled), 4 min 02 sec, CPU 70%, 6683MB This time multithreaded mode was a little faster than single threaded mode for MagicYUV and Lagarith. I then opened it directly with VirtualDub and re-compressed it (fast recompress). The 5897MB file took about 1 minute to move, so obviously hard drive speed wasn't a bottleneck. I took the second huffyuv encode and put it on the same drive as the original MKV. I ran most of the above encodes twice to check them, given the next results weren't what I expected.Īs an experiment I thought I'd take Avisynth and ffmsindex out of the equation and reduce the CPU usage (hopefully) required for decoding. Uncompressed YV12, (Avisynth/ffmsindex/VirtualDubMod/Direct Stream Copy), 4 min 14 sec, CPU 65%, 20572MB MagicYUV, (no mulltithreading, enabling it slowed encoding speed by 2 or 3 fps), 4 min 23 sec, CPU 97%, 5823MB Lagarith, (no mulltithreading, enabling it slowed encoding speed by 2 or 3 fps), 4 min 7 sec, CPU 90%, 5451MB Huffyuv (ffdshow variant, adaptive huffman tables enabled), 4 min 1 sec, CPU 80%, 5897MB Huffyuv (ffdshow variant), 4 min 23 sec, CPU 85%, 9542MB Encoding the first 15 to 30 seconds indicated multithreaded mode was slower for both Lagarith and MagicYUV so I disabled it. Output written to the first partition of a RAID-0 volume to take hard drive speed out the equation as much as possible. Uncompressed RGB, 30 seconds, CPU 45%, 4.3GBĥ minute, 1920x1040 MKV with Avisynth/ffmsindex/VirtualDub (fast recompress). Uncompressed YV12 (Avisynth script/Direct Stream Copy), 15 seconds, CPU 45%, 2.1GB copying the largest file (990.8MB) from the location of the source file to the same location as the output files took around 6 seconds. MagicYUV, 17/12 seconds, CPU 60%/83%, 586.8MBįor a hard drive speed reference. Huffyuv (ffdshow variant, adaptive huffman tables enabled), 16 seconds, CPU 62%, 587.2MB Huffyuv (ffdshow variant), 16 seconds, CPU 62%, 990.8MB CPU usage is a fairly rough average anyway. Without and with multi-threading enabled. For Lagarith and MagicYUV there's two time and CPU usage figures. Total time as displayed by VirtualDubMod. Recompressing a 3min, 49sec 704x384 AVI with VirtualDubMod (fast recompress).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |