Since I built a new NLE capable of easily handling HEVC, I decided to swith my Phantom 4 Pro to HEVC recording.
The picture quality is noticeably improved when viewed at 200% magnification.

My only question is will the extra power required to encode HEVC shorten flight time significantly or can I use HEVC 4K without much extra battery consumption?

One thing I did notice is that the remote display is slightly choppy and stuttery when HEVC recording is employed. Probably CPU on the drone is being used to its limits.

It's nice weather today again so I will try another flight and see how the display smoothness is.

'One thing I did notice is that the remote display is slightly choppy and stuttery when HEVC recording is employed. Probably CPU on the drone is being used to its limits. '

That will be caused by your display device, not by the encoder in the aircraft. It either encodes or it doesn't, there is no ''partial' encoding. More likely CPU on display at it limits.

And no, the HEVC encoding is not going to increase aircraft power consumption to any extent that you could measure or notice. BTW, the CPU in the aircraft takes no part in the video encoding, it is performed by an MPEG encoder engine on a chip.

Geebax Posted at 2-5 14:36
'One thing I did notice is that the remote display is slightly choppy and stuttery when HEVC recording is employed. Probably CPU on the drone is being used to its limits. '

That will be caused by your display device, not by the encoder in the aircraft. It either encodes or it doesn't, there is no ''partial' encoding. More likely CPU on display at it limits.

Interesting, because if I use h.264, my display on the CrystalSky is smooth, but when recording h.265, the display is choppy. I also had a couple of aircraft disconnections while operating at close range and recording h.265.

I have been trying H265 with my P4PV2 but I have been finding that when it starts on a new file after reaching the 4Gb file limit that the start of the next file is partly corrupted with my software making the image jump or just locking up.

No such problem with H264 which gives a smooth transfer from file to file.

Note the corruption in this video every five minutes or so.

https://youtu.be/imI8ssIcpgg

IM35461 Posted at 3-24 12:20
I have been trying H265 with my P4PV2 but I have been finding that when it starts on a new file after reaching the 4Gb file limit that the start of the next file is partly corrupted with my software making the image jump or just locking up.

No such problem with H264 which gives a smooth transfer from file to file.

I haven't encountered any corruption issues with HEVC recorded by my P4P 2.0. It's possible that the editing software doesn't handle it properly.

I know that for years, I put up wit glitches every 17 minutes with XDCam footage in Adobe CS3 where the audio  would glitch at the transition point between 4GB chunks. Later versions of Premiere didn't have this issue.

IM35461 Posted at 3-24 12:20
I have been trying H265 with my P4PV2 but I have been finding that when it starts on a new file after reaching the 4Gb file limit that the start of the next file is partly corrupted with my software making the image jump or just locking up.

No such problem with H264 which gives a smooth transfer from file to file.

I flew my P4P this afternoon for 11 minutes, enough to produce two clips and thus spanning.
I assembled the clips in Premiere and played it back. There is no glitch of any kind at the boundary. I am using firmware from June of last year though. But I am pleased to find that there isn't a glitch at the joint between two segments in a longer record session.

Mark Weiss Posted at 4-13 22:18
I flew my P4P this afternoon for 11 minutes, enough to produce two clips and thus spanning.
I assembled the clips in Premiere and played it back. There is no glitch of any kind at the boundary. I am using firmware from June of last year though. But I am pleased to find that there isn't a glitch at the joint between two segments in a longer record session.

If you feel like doing a test he is one of my files that has a problem at the start.

https://drive.google.com/file/d/1C_qREA5byK13_HAW_147FYzfWJxA4njK/view?usp=drivesdk

This is the third segment of the video and has had no editing

IM35461 Posted at 4-14 02:32
If you feel like doing a test he is one of my files that has a problem at the start.

https://drive.google.com/file/d/1C_qREA5byK13_HAW_147FYzfWJxA4njK/view?usp=drivesdk

Is this the original footage off the camera? I can see a flash or blink effect about a second or two into the preview on Google Drive. I have not seen anything like this from my P4P.
Okay, I've downloaded and looked at the footage in VLC Media player. The glitch appears to be some sort of buffer overrun, ie., recording media not fast enough to keep up with write rate, or possibly and encode error.
I've noted that the footage is 30 FPS. I've only recorded at 24 FPS myself because the bitrate is fixed and the fewer frames, the higher the quality per frame. It could be that the encoder in the P4P has problems with 30 FPS. It may be right on the edge and a few corrupted frames may be the result.

Mark Weiss Posted at 4-15 17:27
Is this the original footage off the camera? I can see a flash or blink effect about a second or two into the preview on Google Drive. I have not seen anything like this from my P4P.
Okay, I've downloaded and looked at the footage in VLC Media player. The glitch appears to be some sort of buffer overrun, ie., recording media not fast enough to keep up with write rate, or possibly and encode error.
I've noted that the footage is 30 FPS. I've only recorded at 24 FPS myself because the bitrate is fixed and the fewer frames, the higher the quality per frame. It could be that the encoder in the P4P has problems with 30 FPS. It may be right on the edge and a few corrupted frames may be the result.

That is an untouched file straight from the drone.

I will try one at 24fps rather than 30 to see if that helps.

Many thanks for testing it.

At these data rates, it's important to have the fastest media card available (fastest write speed), too. If the media can't keep up, or if the card is defective or not up to spec, it could cause corrupted frames like this too.

Mark Weiss Posted at 4-16 12:11
At these data rates, it's important to have the fastest media card available (fastest write speed), too. If the media can't keep up, or if the card is defective or not up to spec, it could cause corrupted frames like this too.

If the card is not fast enough, it simply stops recording. It does not produce corrupted frames. But yes, it is always best to have the fastest card.

I have tried the card recording at 4K60 H264 with no problems. Only H265 seems to do it

https://youtu.be/SnqNMFtadz4

IM35461 Posted at 4-18 20:43
I have tried the card recording at 4K60 H264 with no problems. Only H265 seems to do it

https://youtu.be/SnqNMFtadz4

The data rate is the same for either CODEC,so that SHOULD rule out the card as the source of corrupted images. We're probably looking at a possible processor latency issue, causing some frames to be incompletely encoded.