Personal View site logo
Make sure to join PV on Telegram or Facebook! Perfect to keep up with community on your smartphone.
Please, support PV!
It allows to keep PV going, with more focus towards AI, but keeping be one of the few truly independent places.
DaVinci Resolve 9
  • 179 Replies sorted by
  • Well, I've acquired permission from the band to share the video footage with the forum in hopes that someone has a solution. This latest file cuts FCP out of the equation entirely. it is the 5DtoRGB ProRes 422HQ file, graded in Resolve and exported as individual 16bit TIFF images for each frame. I then used my newly-purchased Quicktime Pro (7) to export that TIFF sequence as an H.264 file via X.264 flavor of the codec.

    The TIFF images looked 100% accurate when played back in QT Pro (7), but the exported H.264 file is washed out when opened in QT.

    This is the same file that is uploaded here, AKA the "original" file.

    If someone with a few minutes could download it, and check it in QT/MpegStreamclip/VLC, that'd be awesome. The latter two programs seem to display it correctly.

    You will also notice that Vimeo jumps between "super washed out" and "kinda washed out" at random throughout the video.

    There is no sound.

    Password is: cpycpm

  • I'm just creeped out now. This is some seriously messed up stuff, whatever is going on. I'm working from an 8 Bit TIFF image sequence using Quicktime Pro (7). The TIFF sequence, of course, displays just fine, as does the H.264 file I create from it . . . but here's the catch-

    Only in windowed viewing. As soon as I go fullscreen, the color shifts and is incorrect. This must be the same issue that is causing the Vimeo encode to flipflop back and forth, whatever the "issue" actually is. I still have no idea.

    Attached is a comparison between windowed and fullscreen in Quicktime Pro (7). As I mentioned, these look like the two color modes that I see Vimeo switching between randomly.

    GOOD.jpg
    1911 x 552 - 84K
    BAD.jpg
    2560 x 757 - 119K
  • maybe some timecode references, cuz I see no glitches whatsoever on the vimeo video, and the color and gamma look totally fine.

  • Yep, I couldn't see any washed out parts or it switching either.

  • @B3Guy The Vimeo video you just posted looks good to me. I'm not technically skilled in grading and exporting etc, but my eye says you did it well. Also, it looks identical to the good "resolve" frame grab from your original Oct 8 post on this problem. Given a few people on here see the video as good on vimeo, maybe it's your monitor or computer that's causing it to look bad in certain situations. Maybe try watching on a friends computer to see how it looks.

  • Are you guys on Mac or PC? Just curious, because both myself and the band manager are seeing the same issues. But then, we are both on Mac. I am viewing on a Dell U3011 via MBP, as well as on a 27" 2011 iMac (separate machines), and the band manager has a MBP. Could it be location related? Both myself and the band are in Minnesota, USA. I know @shian is in Los Angeles (right?) . . .

    Here's my best theory as to what is happening . . . either QT has different versions of the file for fullscreen versus windowed playback . . . or in order to maintain playback framerate under heavy load (i.e. scaling up), it drops certain functions . . . either some sort of color profile on-the-fly correction, or a gamma on-the-fly correction.

    I am not certain, but based on my interaction with Vimeo support, I suspect that they utilize Quicktime in their re-encode process. They've told me to the effect of "check your file in Quicktime. Whatever it looks like in Quicktime is what it will look like uploaded".

    The plan moving forward is not what I would have hoped, but at this point I would rather have the video out there than fuss with it indefinitely. I've seriously tried pretty much every remotely relevant export file type from Resolve with essentially the same results once converted to H.264. So, I'm headed to YouTube. I'll also upload my best effort to Vimeo, and the band and I will get a larger group of people to QC it under password protection. If it proves to be some fluke anomaly with my personal machine, so be it.

  • @shian @vicharris @matt_gh2

    Thanks so much for the help and feedback, sorry if I'm beating a bit of a dead horse, but I've spent I don't know how many full-on days trying to troubleshoot this from every conceivable angle, to no avail. First snow of the season here in MN cheered me up a little bit this morning, though :-)

    1395874_691052740907792_942092170_n.jpg
    960 x 528 - 61K
  • @B3Guy We all hit snags with technology that make you want to kill someone. That's when you realize you care WAY more about image and sound quality than most. But that's why our images stand out as better and it's why we use the hack settings etc. Hope you get solution fast. Enjoy the snow. My current project's cinematographer has been pining for snow...but in MD here so we have to wait. Will tell her to vacation in MN! Your video looked great to me - look forward to final version. Rock on brother!

  • Yeah, not my best work, but I'm happy with it, considering I did four other videos for them that day, each on a time crunch while on the road (5 minutes to pile out of the bus and set up, time for one take, pile right back in and keep driving), but that's the band's strong suit if you ask me. They're crazy good live, even without their full/proper instruments, and these videos manage to showcase that attribute perfectly.

    I've subsequently done a paid shoot for them when they recorded a live in-studio for the Minnesota public radio station. The extra cash allowed me to hire a second camera and to rent some Zeiss Standard Speeds. There is NOTHING quite like real cinema glass. It just renders differently, and the result was amazing. Pair that with studio-quality live audio and Driftwood's Moon V7 of course, and ho.ly.crap. Best work I've ever done.

    So now you know why I'm itching to get this bug sorted out. I've got my best work on hold, waiting in the wings.

    Here's a sneak peek at the grade (ungraded/graded), pre-relight.

    Ungraded.jpg
    1637 x 924 - 125K
    Graded.jpg
    1637 x 924 - 122K
  • Vic and I are both in LA and on Macs

  • I just watched it on my phone(Motorola droid mini) and I couldn't see any changes in color or gamma other than a single quick change of exposure around the 5 second mark.

    Does your Mac have video hardware built into the processor as well as a discrete graphics card?

    My lenovo has a core I5 processor with the built in Intel hd4000(or something) graphics as well as a separate nvidia card. Sometimes it doesn't seem entirely consistent as to when it will use the superior hardware acceleration of the nvidia. Add to this being able to set custom gamma and rgb settings for the nvidia and the Intel units and it would be easy to see why a computer could be switching modes from windowed to full screen or even in the midst of playback depending on processor load.

    I don't know if the same could apply to your Mac but it might be worth a look.

  • @B3Guy

    I just downloaded the original file from vimeo and I think I am seeing some jumps in the saturation/gamma levels of the footage.

    Specifically at 2:53:12, 2:53:13 the sky becomes noticeably less blue. Sampling colors in AE confirms this sudden jump.

    Are certain that their aren't any matching changes in your original MTS file?

  • hi, @jpbturbo

    There are no color jumps in my original MTS file, and most versions of my video that I create do not have the jumps. The jumps come after uploading. The problem is 100% surely Quicktime related, but I don't know how to fix it. It does not matter what file type I export from Resolve (ProRes, TIFF sequence, Uncompressed RGB), once I convert it to H.264 Quicktime can no longer display the color correctly. It also does not matter what program I use to encode the H.264 (Handbrake, QT Pro, MPEG Streamclip), Quicktime still displays the color incorrectly and has a color shift between fullscreen and windowed playback modes.

    @shian yes, I do have an NVidia card. But that still does not explain why Vimeo's files are messed up. I'm about ready to take it back to them and tell them it is something on their end that they need to look into. I'd chase down Apple over the Quicktime issues, but I know already that's a dead end.

  • I am switching out the file with what will be my last upload. I'll let you all know when it is up. This file was exported from Resolve as a TIFF sequence, which was then encoded to H.264 with QTPro(7) and reunited with the audio.

    Reports on this files performance are identical to before:

    VLC: displays color correctly in all situations

    MPEG Streamclip: displays color correctly (playback choppy)

    Quicktime Pro (7): Colors desaturated in windowed mode, green color cast in fullscreen mode.

  • @B3Guy Is this Vimeo only or does it also happen on YouTube? If YouTube works and you like how it looks on YouTube, maybe ditch Vimeo. I did because the playback in Vimeo is often slow and delayed.

  • I'm headed that direction. Bummer, because I like their compression, and all of my previous videos look fabulous, with more detail at 1080p than I see in YouTube videos. I also like the more professional layout, where I get to control everything on the page and what videos it suggests afterwords.

    Edit: the file on the above video has been replaced.

  • Yeah, in theory Vimeo is better, but delayed playback was killer for me. If you go YouTube route, google how to control what your thumbnail is - there are tricks to basically select what you want as thumbnail. If you can live with Vimeo's occasional delayed playback and audio sync issues, remember that a lot of people on PV thought the video looked fine, so maybe just upload it and realize perfection is often impossible. It's a bitch having to make decisions like this, particularly as we strive so hard for quality with cams, hack settings, lenses, composition, talent performance, lighting, audio etc. Best of luck.

  • is "frame reordering" turned on? If so, you might want to try turning it off.... it'll make the file size bigger, but it may change things.

  • Actually, this one seems decent. Not 100% true to my grade, but it isn't green and it doesn't have the abrupt jumps or any sound synch issues. Check it out again anyone who has a free minute. As an added treat, the audio is there now ;-)

    I may revisit this again, but if it is indeed stable for most viewers, I'm gonna leave well enough alone for the time being and work on releasing the other 7 videos I have of theirs waiting to go through post.

  • It looks about the same to me as the previous version, where the changes in saturation or whatever were hardly noticeable.

    If I randomly came across the video online I probably wouldn't have thought anything of it.

  • @jpbturbo

    I am using x.264, and had previously been using whatever QT's "stock" h.264 encoder is.

    The band has uploaded to YT, and I guess it looks perfect to them. Haven't had a chance to check it out yet.

  • Are u not using mp4? You're a ColorGhear guy, use my settings. I stopped using h264 a long time ago. Straight H264 sucks.

    Export "movie to mpeg-4"

    image

    image

    Screen Shot 2013-11-13 at 7.59.46 AM.png
    635 x 109 - 17K
    Screen Shot 2013-11-13 at 8.02.00 AM.png
    597 x 564 - 72K
  • @Shian Great advice here - will implement on current project I'm about to edit. This is for using QT Pro? (? Settings here at 1280x720 - I'm assuming you can use for 1920x1080 as well?) Thanks

  • yup - I use 720p to save on vimeo weekly data cap