Problem—4K video with compressed clip speed via LG 4K TV playback

[Tom Watson]

I have a similar set-up. i9-9940, and have done many similar videos with sped-up portions of some clips. I have last years model LG OLED TV and have no problem playing 4K 10 bit HDR MP4 or MOV clips processed in Resolve Studio (always the latest version). So, I do know what you are trying to do can be done and do play on LG OLED TVs.

More info is needed to narrow down your problem:

1. Do any videos on your SSD play on the LG TV? Videos from another source? Videos played from a USB 3.0 Flash Drive?

2. Do the videos on your SSD play on any other device such as your computer and/or another TV?

3. Are you using the free version of Resolve, or the Studio version?

4. What bit depth video are you using and rendering?

5. Have you tried to render this video in MOV? If so, results?

The more info you can provide the easier it will be to find the problem.

There are many settings in Resolve that must be correct. The DaVinci website has some helpful videos for the basic settings that become critical when you move to 4K. There are a few good ones on You Tube, and a large number of videos that will lead you astray. Provide enough info, and there are some very talented people on this forum that can help.

[Jon Zanone]

Karl –

Instead of setting your quality to ‘best’, try selecting ‘Restrict to’ and type in 8000 or 10,000.

[Karl Buhl]

Tom: Thank you for your suggestions. I will test these scenarios and report back.

[Karl Buhl]

Jon: Thank you for your suggestion. I will test quality settings and report back.

[Karl Buhl]

Answers to questions & suggestions:

1. Do any videos play on the LG TV.

Yes. >MOST< of my 4K videos will play on the LG OLED-77C1AUB.AUS through an external SSD connected via USB. >ALL< of the fast-forward sequences fail at some point in the sequence. >SOME< of the normal-speed 4K video also fails during the normal course of playback (which, to me, suggests the TV processor is unable to process the bits coming in).

It doesn’t make any difference if the source device (into the USB port) is a thumb drive or and external SSD.

Also, I have tried different USB ports in the TV. No difference in performance.

2. Do the videos play on your PC?

Everything plays just fine on my Windows 10 PC—irrespective of whether the file is on an internal SSD or external SSD via USB. No problems. Smooth as butter.

(I do not have another TV to test on.)

3. Version of Resolve?

Paid Studio version.

4. Bit depth?

Bit depth = 10

5. Have you tried MOV?

Yes. The MOV file crashes much worse than the MP4 files.

I have tested several additional variations since my original post. (Everything below was rendered H.264 codec, 3840 x 2160 UHD—except the one Hi Res file as noted. All 29.97 frame rate.) Render speed in DaVinci = 10%.

“Failed” means that the video and audio failed to play back smoothly. It stammered, stuttered, paused, and generally “choked” (my terminology for all of the above).

1) MOV played back via thumb drive = fail.

2) MOV PB via external SSD = fail.

3) MP4 rendered “high” vs. “best” PB via thumb drive = fail.

4) MP4 rendered “high” vs. “best” PB via external SSD = fail.5) MP4 rendered Hi Res 1920 x 1080 = still failed!

5) MP4 restricted to 8,000 Kb/s = played back but severe pixelation (defeats purpose of 4K).

6) MP4 restricted to 10,000 Kb/s = played back but severe pixelation (defeats purpose of 4K).

I also attached the external SSD USB drive to my Surface Pro, and played the same video file on the SP via HDMI to the LG TV. The 42-second test clip appeared to play fine this way on the LG. Hmmm. Again points to the TV processor.

However, I don’t understand why it would choke on the fast-forward rendered segments. Rendered video is rendered video. Would there be more data in the fast-forwarded segments? I’m not an engineer, so I don’t know the answer to this question. The fast-forwarded segments are where the video ALWAYS fails.

Tom: If you (or anyone) wants to roll up your sleeves to test this, I can provide a link to download my ~ 42-second 4K test clip. You can test it on your PC, and then test it on your LG via a USB connection.

(Creative Cow will not allow me to add the link here.)

LG, working through a local repair business, is scheduled to send a new main board next week. I have a hard time believing that a new solid state board that passed LG’s QA went bad. However, the TV’s on-board processor does not appear to be up to the task. If that’s the case, the TV’s performance isn’t meeting it’s own specifications, which are available here:

Thanks to everyone applying brain cycles to this. I appreciate your help.

Karl

[Karl Buhl]

After clearing this with COW’s managing editor, here are two links if anyone wants to dig in further:

1. Link to my ~ 42-second test video. The first scene plays normally on the LG TV. When it gets to the fast-forward segment, then it fails (per the above descriptions). (Download link expires in 1-month.)

https://karlbuhl.filemail.com/d/phutbtifquzyqlt

2. Link to specifications for the LG OLED-77C1AUB.AUS:

https://www.lg.com/us/tvs/lg-oled77c1aub-oled-4k-tv

Thanks again to all those helping me analyze this.

[Tom Watson]

Karl,

It appears you have gone through a similar diagnosis as I would do. The results point to a issue with your LG OLED TV.

If you send a link to download the video, I will test it on my LG OLED TV. That should tell us whether or not there is a problem with the video itself.

I have two LG TVs, the OLED and a regular TV, so I can test on both.

Another thing you can try is to render the video in HEVC (H.265) and see how that plays. HEVC does require a lot more effort by your computer to render, but the video data stream in the rendered video is much smaller and easier for a device to play back. If you do that, set your bit rate to at least 20,000 Kbps for quality purposes.

I agree. Rendered video is rendered video. Fast forwarded segments should only stress the rendering process. My computer always slows down when processing the speed change areas.

[Tom Watson]

Karl,

I started the file download, but it is very slow so will take some time.

[Paul Carlin]

I can’t see the video (download is too slow), but I would assume that it has very fast changing imagery. An efficient codec relies on many adjacent frames being very similar to each other. It takes advantage of this and creates intra-frames that only contain the “differences” that have occurred since the last I frame. I frames are whole frames (think JPEG frames). Since your video has very different images on each frame for a long sequence of images (I assume), this is creating havoc in the codec as it can’t reliably recreate the intra-frames given the limited bandwidth available to it.

A multi-pass encode will do a first pass where it finds these “clumps” of demanding video compression and on the second pass it can then intelligently prepare for the data burst that is coming in the future by preserving some of the bandwidth ahead of time. It allows the encoder to better balance the data needs across the entire video. You should always use multi-pass when quality is the priority (vs. render time).

You may want to play with the Key Frames Every x frames setting. Try every 1 frame. These are the I frames, and if your videos is nothing but I frames, then you don’t have intra-frames. The file may be too big in the end (or it may sacrifice spatial compression to make up for the increased temporal compression), but you can try different settings to see if this helps. You can also try disabling Frame Reordering, as this will disable B frames. However, this contradicts the nature of your fast changing video, so I doubt this will be an improvement as you want to take advantage of the ability to reorder the frames for playback efficiency.

Under Entropy Mode, try CAVLC if you think the TV processor is the issue. CAVLC requires considerably less processing to decode than CABAC.

And set the render speed to Maximum. There is no advantage to lowering this other than if you plan on using the computer for other things while rendering.

[Tom Watson]

Karl,

The video also sputters on my LG OLED.

The problem is in your render settings. In checking the video MediaInfo, it shows that you have rendered at a bit rate of 399Mb/s.

You need to change some settings:

Encoding profile: Change Main to Main10

Quality: set to Restrict to 40000Kbps

Rate Control: set to VBR High Quality

In Advanced settings set data level to Auto

I would not limit your render rates as that is only necessary when your computer chokes and crashes.

Give this a try and let us know. I am off to a wedding rehearsal shoot and will be gone until this evening PDT.

Here is the Media Info for your file:

General
Complete name : E:\Documents\downloads\4k test.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)
File size : 1.94 GiB
Duration : 41 s 642 ms
Overall bit rate : 399 Mb/s
Encoded date : UTC 2021-09-01 20:22:03
Tagged date : UTC 2021-09-01 20:22:03
Writing application : Lavf58.45.100

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L5.1
Format settings : 1 Ref Frames
Format settings, CABAC : No
Format settings, Reference frames : 1 frame
Format settings, GOP : M=1, N=30
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 41 s 642 ms
Bit rate : 399 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 (30000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 1.606
Stream size : 1.93 GiB (100%)
Encoded date : UTC 2021-09-01 20:22:03
Tagged date : UTC 2021-09-01 20:22:03
Color range : Limited
Color primaries : BT.709
Matrix coefficients : BT.709
Codec configuration box : avcC

Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 41 s 642 ms
Duration_LastFrame : -1 ms
Bit rate mode : Constant
Bit rate : 196 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 998 KiB (0%)
Default : Yes
Alternate group : 1
Encoded date : UTC 2021-09-01 20:22:03
Tagged date : UTC 2021-09-01 20:22:03

Other
ID : 3
Type : Time code
Format : QuickTime TC
Duration : 41 s 642 ms
Frame rate : 29.970 (30000/1001) FPS
Time code of first frame : 01:20:17;14
Time code, striped : Yes
Language : English
Default : No
Encoded date : UTC 2021-09-01 20:22:03
Tagged date : UTC 2021-09-01 20:22:03