• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5

Colour issues when uploading to Vimeo

Offline
#1 robnelson4
I'm noticing a massive colour shift when I upload clips to Vimeo. Prior to September last year (2017) that wasn't a problem and I was able to export clips from LRTimelapse and directly post on Vimeo without issue or degradation. I went back and forth with Vimeo on the issue and will include their response below. Here is an example of the issue, the thumbnail image renders with proper colours but once the clip starts everything is washed out. 


This looks fine
[Image: http://www.robnelson.ca/wp-content/uploa....45-AM.png]

But then when it plays it looks like this:

[Image: http://www.robnelson.ca/wp-content/uploa....29-AM.png]


[font=helvetica, arial, sans-serif][font=arial, sans-serif][font=arial, sans-serif][size=small]Dana (Vimeo Support)[/size]
[size=small]Dec 18, 10:13 AM EST[/size]
Hi Rob,

Thanks for your patience. I just heard back from our lead transcode engineer about this issue.

Unfortunately, the reduction in gamma on Vimeo is expected for this type of source file. Despite have a color space of bt2020, your input has a 8 bit of color depth; therefore our transcoder is defaulting to a limited color range. This is resulting in the drop in color you've experienced. At this time, our system can only produce full color range playback files for 10 bit source files. 

He also noted that your color properties are tagged incorrectly (possibly by your editing software). Other players (such as Quicktime) are likely ignoring the tags and playing back your video as expected.  The only solution here would be to correctly tag the file, and possibly use a bit depth of 10, if you'd prefer to use the bt2020 color space going forward. 

I apologize that we were unable to resolve this issue for you, but If you have any questions, please don't hesitate to ask. Thank you. 
Sincerely,
Dana C.

[/font][/font][/font]


[font=helvetica, arial, sans-serif][font=arial, sans-serif][font=arial, sans-serif][size=small]Dana (Vimeo Support)[/size]
[size=small]Dec 14, 1:58 PM EST[/size]
Hi Rob,

Thanks for getting in touch, and my apologies for the trouble here. My name is Dana, and I'm the Video Support Manager here at Vimeo. 

The color variation you've encountered seems to be deriving our transcoder. It seems to be having an issue accurately reproducing your video's color space (Rec2020) and bit depth (8). I've opened a ticket with our engineering team for further investigation, and I'll be sure to provide an update as soon as I hear back.  In the meantime, I would recommend trying to upload a 10-bit video using the Rec2020 color space, if possible. 

In regards to the horizontal lines issue, it sounds like you might be running into a decoding issue in your browser. I've performed some tests, and concluded that our encoded files play correctly in other players. For background, each browser (Safari, Chrome, Internet Explorer, etc.) uses a different technology to decode videos. As a result, videos may look or sound different from browser to browser (the frequency also depends on your hardware and CPU) Unfortunately, this is unrelated to Vimeo, but if continue to run into that issue, please take note of the browser you are using at the moment— there may be a bug in Chrome or Safari that is causing those lines to appear. If that's the case, we'd be happy to file a ticket with Google or Apple to address the issue.

Thanks again for sending over this report. I'll keep you posted on any updates I receive from our engineering team regarding the color variation issue.
Sincerely,
Dana C.
[/font][/font][/font]




[font=helvetica, arial, sans-serif][font=arial, sans-serif][font=arial, sans-serif]Is there a way to export a clip from LRTimelapse that can be uploaded to Vimeo without this issue?[/font][/font][/font]
Offline
#2 Gunther
I've done some tests and unfortunately I can confirm that Vimeo has those issues when uploading MP4 / h.264 videos from LRTimelapse. I see them appear fine in the preview but when hitting "play", they play back faded.
It doesn't seem to be related to the browser (tried Firefox, Chrome, Edge on W10).
Uploading H265 or Prores footage from LRTimelapse works without any issues.
So for those that want to directly update clips from LRT to Vimeo and have the LRT Pro license, I recommend encoding in H265 until Vimeo has fixes those problems.
I'm sorry, but currently I don't see any workaround that I could do to circumvent this Vimeo compatibility issue with the h.264 files from ffmpeg.
As I already said: most of the time this shouldn't be an issue, because mostly you would not upload the master clips from LRT to vimeo, but join them in a video editing program to a film then export from the video editor and upload that to vimeo.
Subscribe to: LRTimelapse Newsletter, Youtube Channel, Instagram, Facebook.
Offline
#3 robnelson4
Thanks for looking into this Gunther!
Offline
#4 djoubert
Actually, I was facing the same issue,
before to find this post with the workaround proposed by Gunther,
I saw that it was correct with H264 BT.709 and not correct with H264 BT.2020.
Trying to apply the work around, it seems to me that H265 / BT.2020 is not correct ?
only with Prores BT.2020 I got a good result.
If these tests can help to get the issue fixed at Vimeo level ( I submitted a request )
Dominique
Offline
#5 koda
Hi, I am a developer familiar with both ffmpeg tools and Vimeo encoding practices.
After an extensive review, there seem to be a few problems with how files are encoded with LRTimelapse.

1. The files are tagged with BT.2020 CONSTANT ([font=Courier New]-colorspace 10[/font]) instead of the classic and more widespread NON-CONSTANT ([font=Courier New]-colorspace 9[/font]) variant. There is a clear distinction between the two in how luminance and colors are actually handled, the equations for these two colorspaces are very different (the reccomendations could be easily called with two different names -- I think they are defined in the same recommendation only because they use the same coeffients, but the functions and equations differing).

Unfortunately the CONSTANT variant is completely unsupported by ffmpeg: both are treated as if it they were the NON-CONSTANT variant, which produces the wrong results as we have experienced. I can only guess that most sites and other players use ffmpeg for ingestion or decoding, so they don't distinguish between the two, while Vimeo does, trying to apply the correct conversion functions defined within the file. The thumbnail looks "correct" only because the image server hasn't been updated yet with the new color conversion software, but that will soon change.

2. The H.264 file is encoded at 8 bit: this bitdepth is simply too small to be able to represent the amount of colors defined in the BT.2020 recommendation. While some range of colors of the BT.2020 NON-CONSTANT can be fit in a 8 bit file, it certainly does not work when the BT.2020 CONSTANT color space is used instead. I believe that  the HEVC/H.265 and PRORES files work exactly because of this: they are encoded at 10 bit.

3. This sort of reiterates the first point but it should be known that all the color options ([font=Courier New]colorspace[/font], [font=Courier New]color_trc[/font], [font=Courier New]color_prim[/font]) in ffmpeg are best-effort tools only and should only be used to tag the final file: the color conversion of the default scaler is not accurate and the filter system makes the conversion unpredictable and unreliable.

4. ok, this is unrelated to the color issue, but while I was providing feedback I thought of adding it: it would be nice if LRTimelapse used a different $PATH than [font=Courier New]/usr/local/bin/[/font] since it unexpectedly overwrote the one I had installed. I would suggest maybe using [font=Courier New]/opt[/font] and then calling it with its full path.

In conclusion, I don't think there is anything to be changed on the Vimeo side, but I'd be happy to hear everyone's feedback about any conversion problem.
Offline
#6 Gunther
Hi Koda, thank you for your feedback. I've tried with NON-Constant setting, then Vimeo produces too saturated colors when uploading MP4 in BT2020. Standard BT709 looks fine (Both look fine in Premiere Pro).
I'm open to work with you on even better ffmpeg settings with higher compatibility - let me know your ideas. Please contact me directly via email to support(at)lrtimelapse(dot)com.
Subscribe to: LRTimelapse Newsletter, Youtube Channel, Instagram, Facebook.
Offline
#7 koda
I think the users are reporting that color in their videos looks too desaturated, so it seems correct that it looks more saturated when using the right colorspace. Don't forget that when using 8 bit for a wide gamut color space (bt2020 or p3) some color shift is to be expected. Do you have a sample generated by LRTimelapse in bt2020 non-constant that you think is problematic?

In any case, I believe that the remaining issues are due to #3, ffmpeg doesn't support proper color conversion by default (and implementing it is definitely non trivial). If it's possible to bring in another dependency, you could try using a different rescaler, such zscale: this filter uses zimg, a very good color correct conversion library which I really recommend. Alternatively if you do want to preserve the option of using bt2020 for h264, you could simply use 10 bit h264 when bt2020 is selected. The latest version of x264 supports encoding in both bit depths on the fly.


If I can help, let me know which route you decide to go and if you face any issues I'll get in touch with you off thread.
Offline
#8 Gunther
I've sent you an email with the examples.
And I've just released LRT5.0.5, where I've set non-constant as default when rendering.
Subscribe to: LRTimelapse Newsletter, Youtube Channel, Instagram, Facebook.
Offline
#9 djoubert
Hi,
Thank you to Gunther with the help of Koda to try to find a solution
Unfortunately I just tried the 5.05 release and uploaded to vimeo, the result is different ( not better than with previous release / color more saturated ) The result is not correct... far from my local view and far from youtube view...
As I said I submitted the issue to Vimeo, and their feedback is that the application doesn't provide the right information " This is not a bug of our encoding system, this occurs because we are very accurate to define colours related to the information from your file ...more accurate than some other applications..." ( my translation from their french answer which is itself from a translating robot...)
I got much more information , I just requested them to provide me with the original english text. I will then add it in this post.
Hoping that will help to find a solution. Lrtimelapse rendering even for a sequence is helpfull for me
Dominique
Offline
#10 Gunther
Yes, I know. If you want to upload directly to Vimeo, please select Standard Gamut (BT.709) in the render dialog.

Posted mobile via Tapatalk...
Subscribe to: LRTimelapse Newsletter, Youtube Channel, Instagram, Facebook.

...also check out: