![]() ![]() ![]() The command syntax usage for x264 and x265 varies between applications and even within versions in some cases, ffmpeg and mkvmerge, x264, x265 all have unique syntax. Would you be able to help with doing the same for h264 files? It seems some of these can benefit from changing the flags, but the ub820 ignore these changes. Transfer_characteristic: bt2020 and bt709, Would you be kind enough to share the links/documentations how these flags are defined and the arguments used? In particular the following: It is interesting to note that the players behave differently with some of the files, and it seems that other flags also play a part in affecting the playback. Initial testing with ub820/x700 has been encouraging, both players responding to the modified flags. Greetings ReciprocalUniverse, you're a genius.:thanks: I got the clue here I needed, thanks everyone, so here is the answer to you for changing to PQ/HLG.įfmpeg -i input -c copy -bsf:v hevc_metadata=colour_primaries=9:transfer_characteristics=16:matrix_coefficients=9 output ![]() So I'm still looking for the ffmpeg nomenclature, but in the big scheme the h.265 encoder Resolve uses is so bad I will only use it for a draft, in which case looks like maxcll/maxfall is just lipstick for a pig. The recording originates from the camera as 16 bit linear raw, and only x265 rendered from a DNxHR HQX intermediate retains player quality that respects the source file. Ffmpeg will copy the metadata to the stream and cause HDR playback but the quality I can't accept. It's an interesting phenomenon because mediainfo will show all the HDR metadata is there but it won't play in HDR. Mkvmerge will add it to the container but since bt709 transfer is already embedded in the h.265 stream that Resolve outputs, it wins. If I use x265, then yes, -max-cll "1419,520" goes in at the beginning, and a beautiful encode :) The disadvantage is the HDR metadata has to be added in after the encoding is finished, and the quality is bad. Resolve will output h.265 but not include HDR metadata. Thanks, but the only reason I'm adding back in ffmpeg HDR metadata to an h.265 encoded stream is because in this instance I'm not using x265. I suspect the "ffmpeg -color_trc" command only works on the mkv container? Mkvtoolnix and the tool mentioned above should support:Īppreciate if you could kindly explain how to do it. There is no 'transfer_characteristic HDR10+', colour-transfer-characteristics TID:n see: I doubt that ffmpeg can do what you want without reencoding the video. > are you even sure the tool you choose supports what you want?Ĭan't seem to get the ffmpeg command to write metadata to mp4 file. I don't think normal ffmpeg doesn't support this, and has a different syntax and only supports H.264 not H.265 content. I also tired the "ffmpeg -color_trc" command but was unable to get rid of the transfer_characteristics_Origina : BT.2020 (10-bit). > you would need to overwrite the flag in the streamĤ. The stream info is then shown as 'original'. The 'original' part is usually added by MediaInfo whenever the container and stream info differ. How to remove transfer_characteristics_Origina : BT.2020 (10-bit)? There is no 'transfer_characteristic HDR10+', mkvtoolnix and the tool mentioned above should support:Ġ: reserved, 1: ITU-R BT.709, 2: unspecified, 3: reserved, 4: gamma 2.2 curve, 5: gamma 2.8 curve, 6: SMPTE 170M, 7: SMPTE 240M, 8: linear, 9: log, 10: log sqrt, 11: IEC 6, 12: ITU-R BT.1361 extended colour gamut, 13: IEC 6, 14: ITU-R BT.2020 10 bit, 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, 17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG) colour-transfer-characteristics TID:n see: (2.8) What argument to use for writing metadata transfer_characteristic HDR10+ etc? No clue, haven't tried the tool, like I wrote. Is the info written to the raw video stream? Or just the mkv container? ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |