Handbrake encoded DV files not playing as DV

[kaledi 41]

I've noticed that some DV files re-encoded by Handbrake are not correctly flagging DV playback correctly - tested on Fire TV Max and Shield TV pro (2019).

It appears that the current version of Handbrake is adding multiple references to HDR into the HDR format field (visible in mediainfo). 

If I demux the DV metadata out and reinfect it in, the field is looks normal and the file correctly flags the playback device to play DV.

I don't know if this is a bug in Handbrake (I'll ask in their forums), and don't know technically what this means, and whether a simple fix can be applied to emby,  but I suspect there will be a lot of such encodes out there.

I can post a couple of sample files to help.

[rbjtech 5284]

..looks familiar .. 

Emby uses ffprobe for detection - so unless ffprobe recognises as DV, then emby will possibly not think it is DV ..

ffprobe -v error -show_format -show_streams <mediafile.mkv>

This is what a correct DV 8.1 file should look like - 

[SIDE_DATA]
side_data_type=DOVI configuration record
dv_version_major=1
dv_version_minor=0
dv_profile=8
dv_level=6
rpu_present_flag=1
el_present_flag=0
bl_present_flag=1
dv_bl_signal_compatibility_id=1
[/SIDE_DATA]

 

[kaledi 41]

Familiar and frustrating!

Let obtain the same information as you have above.  How do I do this.  If I run the command line you have (with the relevent file path and name) ffmprobe runs correctly, but I don't get the same information as you.

[RanmaCanada 496]

 

[rbjtech 5284]

11 hours ago, kaledi said:

Familiar and frustrating!

Let obtain the same information as you have above.  How do I do this.  If I run the command line you have (with the relevent file path and name) ffmprobe runs correctly, but I don't get the same information as you.

What info does it show ?   The 'side data' is in the middle of it somewhere, there is a syntax to get just that bit but for a one off looking for it manually is fine.. 

[kaledi 41]

I know, familiar, and frustrating!

For anyome else experiencing something similar, I've found that demuxing and remuxing these files solves the issues and all media I've trued  has played perfectly since.

Specifcally, I've used Dolby Vision tool to demux the base layer and DV layer, remux them back together and add audio and subtitles from the original  file using mkvtoolnix.

A bit of a pain, but as I said at the top , it has worked for every file for me.  I even had a couple that were causing emby to playback errors causing a re-encode on the server.

[rbjtech 5284]

I continue to believe it's a bug in handbrake - as none of the tooling from mkvtoolnix nor a flat remux from ffmpeg has issues.       If they follow suit, and we get a new 'standard' then fine - emby will need to follow - but at the moment, handbrake need to fix it, not emby imo.

[kaledi 41]

yes, I agree.  Just wanted to provide a work around (that has worked for me) for folk.