This post was last modified: 2020-03-13, 20:59 by Not A Speck Of Cereal. Edit Reason: Updating post to add attachments

PC: Windows 10 Pro Workstation, i7, 64GB memory, plenty of HD
LRTimelapse version: 5.4
Screenshot of the preview and table portion: attached "Capture-PrevTable.JPG"
Screenshot of the video render dialog: attached "Capture-renderDialog.JPG"
"Show Log-File": attached "LRTL-log.txt"

Description:
-- Install v5.4.
-- Rendered video is choppy (same video was not choppy yesterday)
-- Re-installed v5.3.3 to check, new render, video is not choppy. Smooth clouds and boat movement
-- Reinstalled v5.4: new render, back to choppy.

Choppy definition: as if short exposure with long interval and no motion-blur setting applied.

Note #1: Capture-PrevTable.JPG: sequence has 2" exposures, 4" interval. The 2" shutter speed is enough for motion blur even without MB setting
Note #1: Capture-renderDialog.JPG: video render has motion blur setting of 4

All of the above mentioned videos were created with the same settings, with MB=4 on all. I decided to try the following test:
-- Reinstall 5.3.3
-- Render video same as before, but turn Motion Blur setting completely OFF
-- RESULT: video is not choppy

Video samples provided upon request (please recommend drop location, or I will drop 1080 versions to youtube).

This post was last modified: 2020-03-13, 21:07 by Gunther.

Is there a special reason that you are rendering in H.265? It's a consumer codec that is normally not well suited to be brought into video editing software for further editing.
Also maxing out the quality settings is mostly not the best idea. What happens if you use lower quality settings?

Generally it's a much better choice to use ProRes with LRTimelapse Pro.

Which player you are using? Did you try a decent one like VLC?

This post was last modified: 2020-03-13, 21:12 by Gunther.

Ok. I think I know what might have happened. In versions before 5.4, if you selected 444 color rendering with h.265, in fact the encoder was not doing 444 but 422. I've fixed this in 5.4. This means, that your player is most likely not able to render h.265 in 444 with max quality in real time.
Now the question remains, why are you using 444, max quality together with h.265 and are you using a player and hardware that is capable at all to play such footage. Please reconsider your settings and player.

Thanks, that pans out. I just rendered a video with all of the same settings, except I set the color sampling to 422. The result was smooth, non-choppy video.

I am choosing higher quality render settings because the output videos from LRTimelapse are themselves intermediate files, used in a larger video project assembled in the editor (DaVinci Resolve Studio).

I use Resolve in proxy mode, transcoding down files that are usable in the editor for this current hardware. But I want the quality of the source files (LRTimelapse produced videos, among others) to remain highest fidelity up to that point so as to not lose quality in generations between initial capture and final render.

Also: I hope to have a much better video card in the near future and would rather not have to go back and re-render the intermediate videos later. So I use high quality settings to future proof (have the highest quality videos for use on future hardware).

My next test will be to see if videos produced with a color sampling set to 444 will be usable in Resolve after transcoding.

Thanks for getting back to me. This issue is resolved for me.

Chris

In any case for your use case you should definitely render in ProRes not h.265.

Sent mobile...

This post was last modified: 2020-03-14, 01:51 by Not A Speck Of Cereal.

Hold the phone: it turns out that 422 does not pan out. My earlier confirmation test was only 1080. A 4K version is still choppy.

Something else much have changed.

I can take a project that is choppy with v5.4 and render it again with v5.3.3 without it being choppy, same settings, played back on the SAME hardware. Both videos produced with the same 4K 16-bit TIF intermediates**, rendered to 4K h.265, color sampling 422.

Notes:
1) I have been using h.265 for a long while without problems, all with the typically these same settings
2) My video card is not top notch, but it is NVIDIA Pascal architecture, which according to NVIDIA SDK docs supports 10-bit h.265/HEVC
3) And I can still produce a non-choppy 4K video using this SAME hardware and render settings (including h.265) -- I just have to roll back to v5.3.3

Thoughts on that?

** I just did a test with 4K 8bit JPGs (rather than 16bit TIFF), all render settings the same, and it's still choppy.

Like I said, h.265 was "broken" in versions before 5.4 - in a way that it didn't do 444 and it also didn't apply wide gamut if selected.
If you really need to use h.265, then apply "standard gamut" and 422 then you'll have the same behavior than in 5.3.3.

But I can only repeal myself: h.265 is a playback codec. Not an intermediary codec for further editing. If you want to bring your sequences to Davinci Resolve or other NLE, better use ProRes.