I was examining some original videos alongside those changed in the editor with ffprobe and noticed what seems to be an incorrect colorspace change by the editor... For normal files from the camera, the color space in the header is bt.709 for hd video and above, which is correct (or at least allowed for 4k if not optimal). With HDR10+ experimental turned on, it's:
The issue here is that even though you *can* use it, smpte170m is the deprecated colorspace that was used for broadcast NTSC tv with a slight variant for PAL and is much smaller than bt709 let alone the luminance range of PQ HDR10 even if it was just inverse tonemapped from 709.
So it looks like either the editor is converting down to a smaller space which will limit output color quality by a decent amount (but at least isn't tagged wrong), or it's incorrectly setting the obsolete colorspace on video that wasn't transformed which will mess up colors on anything that honors the stream flags, which is pretty much anything good... Although some players probably ignore it and assume bt709 for anything over 480p.
Also, dropping the bpc to 8 with hevc seems silly; the codec was designed for 10bpc video and main10 is generally more efficient than main. Even so, 8bpc is sufficient for bt.709 so the down-conversion isn't necessary.
This seems like something Samsung might want to look into since it makes doing anything with the editor undesirable if you want video with decent colors.
I should add that without hdr10+ turned on, 4k video out of camera is also 8bpc hevc but this isn't necessarily incorrect since it's flagged bt709. Same with .heic images which sorta eliminates any reason for using them vs. jpeg given the compatibility issues.
A third note is that when I was still subscribed to Adobe Creative Cloud, I tried saving a timeline from Premiere Rush and it produced the same incorrect conversion, so this may be some firmware issue with the hardware encoder ASIC causing it to ignore flags from certain sources. I checked and H.264 has the same issue
1) I'm not sure the player in-phone is actually using HDR10+ metadata, because it appears broken. When extracted, the AverageRGB values and max(MaxSCL[]) fluctuate rapidly, and cause huge amounts of flickering when converted to Dolby Vision L1 only metadata; Dolby Vision L1 only without the colorist trims and other important features that make it a better dynamic HDR format emulates most of HDR10+ features. In comparison, when the HDR10+ in a movie like the Alien directors cut is converted in the same way everything plays back great as Dolby Vision (better than plain HDR10). I'm guessing the full HDR10+ generation algorithm smooths this data between frames to avoid this and the camera doesn't since it's created in realtime, but that's only a guess because despite supposedly being open for implementers and being willing to sign an NDA it's impossible to get the official HDR10+ spec or software to verify against; they just don't respond to inquiries.
2) OpenCamera can shoot video with various Log curves which is appropriate for grading as HDR10, and the bitrate can be set to much higher values than the built in camera ever records at (150Mb/s 1080p for example). This works with no issues even saving to MicroSDXC so there's no hardware limitation. For editing purposes on computer it would be nice to have these features added to the "pro video" mode of the camera at least. Something similar to SLog2 / 3 would be great for grading 4k to HDR, since 4k SDR video is rarely seen in practice, but even HLG would be nice so playback is HDR by default on actual 4k devices, which the phones aren't. Currently the only option is HDR10+ shooting but this does a direct SMPTE2084 conversion with unknown parameters.
