Jump to content

KnightsFan

Members
  • Posts

    1,351
  • Joined

  • Last visited

Everything posted by KnightsFan

  1. @GiM_6x transcoding 4k nx1 footage to h264 is many times faster than real time using hardware decoding and encoding on a gtx 1080, running ffmpeg. The 1080 is a high end card for sure, but its last generation consumer hardware. I think the problem is that editing software doesnt use hardware de/encoders to their fullest. Even resolve, which uses the gpu a lot, does most video decoding on the cpu, and then processes effects on the gpu. Thats why my 6 year old i7 struggles with real time editing. If resolvr used my gpu decoder, it would be buttery smooth.
  2. Sounds like a video vs data levels issue? You can specify whether cmimported clips in resolve use data or video levels, and you can also specify which your export uses. You can also specify which to use in VLC. Neither one is universally correct, just check how it looks on whatever platform you distribute on.
  3. @GiM_6x The XT3 can encode 4k60 at 100, 200, or 400 Mbps in HEVC 10 bit. The E2 encodes realtime 4k120 10 bit HEVC at 230 Mbps. That technology is already here for the prosumer market--whether Sony uses it is up to them. As for 8k, I don't know whether that XEVC list is actually for the A7s3, or just the family of formats that Sony's entire lineup will pull from. I think that real time 4k HEVC editing is not far off, and I think that part of the problem is just that our favorite software doesn't leverage existing hardware decoders yet, because as a "non-pro" codec there wasn't much incentive for developers. Resolve Lite doesn't officially support HEVC, and even Resolve Studio only added HEVC export very recently, and it's still slow and not very good. Meanwhile, I can use ffmpeg to generate proxies at significantly faster than 24 fps using my same hardware.
  4. Its a good sign that sony is making a good lineup of hevc codecs with 422 and 10 bit being favored. That 2k lossless version looks very interesting--its about time someone leveraged hevc to make a lossless acquisition format. I am still skeptical about which if any of these will be in the a7s3.
  5. Nice find! Interestingly, I did look at the article NoFilmSchool links to in my original search, but that chart is nowhere to be seen. That is actually the article from 2014 that mentions that that they have changed their testing methods. NoFilmSchool quoting C5D: "Here we tested usable dynamic range of the given cameras. With 14.1 stops the usable dynamic range of the A7S comes surprisingly close to the Arri Amira with its legendary Alexa sensor" C5D (probably edited) "We tested usable dynamic range of the given cameras. With 12 stops the usable dynamic range of the A7S comes surprisingly close to the Arri Amira (13.1 stops) with its legendary Alexa sensor"
  6. I feel your pain. Between Premiere unstability and Flash vulnerabilities, I have a strong distrust of Adobe myself. I use Resolve for editing these days. My biggest project is ~5,000 files / 500 GB and Resolve is handling it just fine. Each of the files actually is imported both in full res and a proxy, so there's closer to 10,000 imported files. Not sure how that scales against your needs...
  7. The article date is in the leftmost column. I think that they often use old test numbers (e.g. on the Fuji page, they include existing numbers from Sony for comparison, rather than re-test the Sony). I didn't find any Sony cameras where they claimed 14 stops, but I would not be surprised if they did on some very old articles. On this article (https://***URL not allowed***/lab-review-sony-a5100-video-dynamic-range-power/) from 2014, they mention a lot of changes to their testing in various updates. The a5100 was "updated" from 13 to 10.5 stops. If you find any, I'll add them to the list anyway. At the bottom of this 2014 article (https://***URL not allowed***/dynamic-range-sony-a7s-vs-arri-amira-canon-c300-5d-mark-iii-1dc-panasonic-gh4/) it says: "Note: We have at one point in 2014 updated our dynamic range evaluation scale to better represent usable dynamic range among all tested cameras. This does not affect the relation of usable dynamic range between cameras." So I would be be cautious comparing numbers from pre-2014 with modern numbers.
  8. Though, discussing C5D's past accuracy is slightly off topic. The real question is, if this test is bogus, what is the actual dynamic range of the Ursa 4.6k?
  9. C5D DR Tests.xlsx Feel free to check. I haven't added the 4.6k article from this topic yet.
  10. @sanveer Last time we talked about this, I actually did that. I looked up every single C5D article that mentioned a dynamic range and compiled them into a spreadsheet. Turns out the only discrepancy was with the A7s2. I contacted C5D about that, and was told which articles had used a 4k to 2k downscale. The 4k downscale increases DR on the A7s2 from about 10.6 to 12 stops. After that was cleared up, I couldn't find any other significant problems. Now, it appears that they always list the resolution and whether any downscaling was done.
  11. So those of you who think C5D's results are inaccurate, what do you think is causing that? Are they intentionally lying? Is the imatest software glitching out? They publish their methodology, and the images they use with imatest. Are the images fake? They've even gone out of their way to explain different ways of testing dynamic range (https://***URL not allowed***/canon-measured-15-stops-dynamic-range-c300-mark-ii/) and now they often publish at least two values, for SNR = 2 and SNR = 1. These are not subjective tests. You can very easily copy them--they explain the setup, the lens used, the exact ffmpeg command to extract i frames, and how to setup the software. If you cannot reproduce their results with the same setup, then publish your results and let us know. But until then you really have no authority to call BS. Do you really think they would go through the trouble to be the only site that conducts extensive, objective DR tests, and then make up their results? If so, it should be very easy to prove, instead of bashing them on internet forums.
  12. So it was recorded internally in ProRes or transcoded?
  13. Anyone know if the e2 was shot internally or not? Its a prores 422 file, i wonder if it was recorded internally or externally or transcoded.
  14. I can't say this test is at all conclusive. Neither camera clips, so you can't really see what the DR limit is on either camera. It looks like the Arri keeps the highlights a little lower on the waveform, but the Z cam's waveform shadows are also at a higher level so it could just be an exposure difference. The different field of view and angle make it hard to tell. I'm still going with "everyone exaggerates by 2 stops except Arri" so 15 for Z Cam is really more like 13 (as measured by Arri). I do think that the color on the Z Cam is phenomenal. The real conclusion is that the Z Cam's footage is really good enough for any cinematic purposes. @webrunner5 they are both UHD I can't say I agree. The Z Cam actually looks like it has less noise. Arri definitely has more chroma noise. However, the Z Cam's depth of field looks shallower, so they might have a faster lens and a lower ISO.
  15. I wanted to test an H.265 encoder where I can adjust parameters and see how they effect size and quality. I didn't publish all my tests, but I've actually tried dozens of combinations of settings, both from ffmpeg and Resolve, and also tried different ProRes and DNxHD encoders. The NX1 specifically has a hardware encoder from 2014 designed to run in real time, whereas I was more interested in how good H.265 could look if you give it, say, 68 second to encode a 3 second clip. Hardware encoders are often not as high quality because they have a more limited number of algorithms available, and can't be updated as the specification is changed. Since 2014, we have had several updates to the HEVC standard. The test you propose only compares the NX1's encoder vs. the Ninja's, not the possibilities of H.265 as a distribution codec (which was my interest). Furthermore, I do not own a Ninja. In fact, one of the main reasons I didn't invest in one is because, through my tests, I have not seen ProRes as a huge benefit.
  16. Exactly. Generally, you get less noise if you raise the gain by a stop while shooting, and then pull it down a stop in post, though you can lose highlight detail. Assuming that the "gain" is actually gain and not just metadata, like it is on most Blackmagic cameras.
  17. You know, I just used Resolve's H265 encoder and I can't see much difference compared to ffmpeg on the car scene I've been using. But I am 100% sure I got some really bad results on a Resolve project I exported not too long ago. Maybe that car scene is just really easy for H265--though to be fair, I downloaded it for these tests before I had seen it. Someday I'll have to borrow an Ursa and shoot my own tests. I'm also interested in finding out whether coming from a 444 source improves a 422 file vs. coming from a 422 source.
  18. Cool, less difference now, but ProRes still looks like it retains more detail. I've never liked the results from Resolve's H.265 encoder, though, and I think ffmpeg's generally produces better results. But clearly H.265 struggles a lot more with this busy scene than with the one I used.
  19. What encoders did you use? Your H.265 is 16 Mbps (Mine came out to 22), not 100. It's also 420 instead of 422, so that could be part of the chroma difference. But yes, with your settings the ProRes HQ certainly is much better!
  20. ProRes is built for editing speed, whereas H.265 was designed to maximize quality on low bitrate streaming, especially 4k and 8k. I knew that at some lower bitrate, H.265 would retain more data than ProRes, but I was surprised that it does so well with just 1/5 the data. Of course, it took 6x longer to encode! I would love to see your results, if you publish. Keep in mind that not all encoders are equal, and H.265 has a LOT of options. ProRes is easier in that regard, as you just pick from Proxy, LT, Normal, HQ, and XQ with predictable size and quality. Edit: the difference in detail is negligible between ProRes HQ (180 Mb/s) and the H.265 file. Also I didn't see any real difference between ProRes and DNxHD at equivalent bitrates.
  21. Spoilers for anyone who wants to do a blind test! It turns out that A is ProRes and B is H.265. As @Deadcode points out, B (H.265) has noticeably more detail. However, the ProRes file retains a tiny bit more of the chroma noise from extreme shadows the original video. As you can see in the 300% crop below, all that sparkly noise is simply gone H.265, and while the ProRes has some obvious blockiness, you can still faintly see the noise. This is of course a VERY extreme grade (see the curve from Resolve). With extreme grades the other direction, the ProRes looks better up until the VERY extreme, when its blockiness shows. As I said before, encoders have many options so this doesn't mean much for cameras. However, if you are uploading to a site with file size limits, H.265 is a good option. Also, as @OliKMIA pointed out, this is not a comprehensive test: it's 3 seconds of HD, and only looks at one scenario. This shot is quite stable, so the interframe flavor of H.265 that I used has an easier time. Shakycam will reduce the quality of H.265. Furthermore, the encode time on ProRes was significantly less: 11s vs 68s. I could have used a faster preset for H.265 which would speed up the encoding at the expense of quality (my guess is that cameras, tasked with real-time encoding, are not as good as the preset I used). On the other hand, I have a 2013 CPU. Perhaps newer CPUs with hardware encoding could narrow the gap? I'm not sure. If you want to look at the original files (before I turned them into 380 MB monsters!) One final note: I accidentally encoded both with AAC audio, so ~6kb of the file size of each is an empty audio track. ProRes: https://drive.google.com/open?id=102Ivc9Xa1Z7mPzCK8TgTqwh2GExMPOkZ H.265: https://drive.google.com/open?id=1NxMofYvrHcP6DHx5VECRwMNw8qA4KXOD
  22. @thebrothersthre3 I find them to be equal for all practical purposes, even with extreme grading (by extreme I mean waaay out of the realm of usefulness). There are differences, but neither seems more accurate. I haven't tried green screening, and that would be an interesting test, but I don't have a RAW camera so I'm limited in the scenarios I can test. And naturally it defeats the purpose of the test if I start with anything less than a RAW file. Interestingly, despite having a hard time making any substantive distinction between the two, when comparing the PSNR (peak signal to noise ratio), ProRes is higher than H.265 at this compression level. H.265 needs to get up to around 50% of the bitrate before the average PSNR is the same--and even then, the PSNR on I frames is higher than ProRes, but the PSNR on P and B frames is lower. That's to be expected. I could also push the preset to be even slower, or use two pass encoding for better results on H.265 as well. No, I did RAW -> Uncompressed RGB 444 And then Uncompressed -> H265 -> Uncompressed And also Uncompressed -> ProRes -> Uncompressed I did it this way so that I would not be limited by Resolve's H.265 encoder, and so that I could do PSNR tests from Uncompressed, without having to futz with debayering messing up the PSNR comparison. I did a short clip to keep the file size manageable at only 380 MB each. I originally did 4k, but I figured no one wanted to download that! If there is interest I am happy to do more extensive examples.
  23. I did a quick comparison between ProRes and H.265 encoding, and thought I'd share the results with everyone. I grabbed some of Blackmagic's 4.6k RAW samples and picked a 3 second clip. In Resolve, I applied a LUT and then exported as an uncompressed 1080p 10 bit RGB 444 file. This is my reference video. From this reference file, I encoded two clips. One clip is H.265, and the other is ProRes SQ, which I compared to each other and the reference video. The reference video (which I did not upload) was 570 MB. One of these files was created from the reference file using "ffmpeg -i Reference.mov -c:v libx265 -crf 20 -preset slower -pix_fmt yuv422p10le H265.mov". The file size is 7.81 MB (1.4% of the reference) The other file was created using "ffmpeg -i Reference.mov -c:v prores_ks -profile:v 2 ProRes.mov". The file size was 44 MB (7.7% of the reference, or ~5x the size of H.265) In order to keep the comparison blind, I then converted both the ProRes and H.265 files to uncompressed 10 bit 422. So you shouldn't be able to tell which is which from the metadata, file size, playback speed, etc. You can download these files (380 MB each) and do extreme color grades or whatever stress tests you wish, and compare the quality difference yourself. https://drive.google.com/open?id=1Z5iuNkVUCM9BgygGkYRXizzr6XnSXDK7 https://drive.google.com/open?id=1JHkmDKZU4qdS7qO_C0NwYH2xkey0uz7C I'd love to hear thoughts or if anyone would be interested in further tests. Keep in mind that there are different settings for H.265, so this test doesn't really have implications for camera quality. since we don't know what their encoder settings are. However, it could have implications for intermediate files or deliverables, especially to sites with file size limits.
  24. C5d puts the alexa at 14 using their SNR = 2 measurement. I agree. But you cant blame z cam when everyone from sony to blackmagic exaggerate their dr. Only arri has the godlike status that allows them to be honest and still sell products.
  25. It's actually been in and out of stock a few times at B&H.
×
×
  • Create New...