Jump to content

Add DV, Atmos, DTS:X, HDR10+, HLG information to database


Recommended Posts

FrostByte
Posted
20 minutes ago, softworkz said:

As I had mentioned somewhere before (as that it will come), DV data is available from ffprobe since 5.0:

 

image.png.5e87c65ef7abea9fde5177230b581955.png

 

Just to let you know that it's not far away anymore..

I believe there is also a patch for HDR10+ that been posted a couple times in the forum.  

rbjtech
Posted (edited)
24 minutes ago, softworkz said:

As I had mentioned somewhere before (as that it will come), DV data is available from ffprobe since 5.0:

 

image.png.5e87c65ef7abea9fde5177230b581955.png

 

Just to let you know that it's not far away anymore..

Useful to know - thanks @softworkz - I'll check ffprobe v5 - as if it contains the Dolby Atmos and DTS sub-types as well and emby plan to use/hold this data, then this could make the Plugin largely unnecessary unless you want a specific type of formatting on your title entries for each track.

 

Edited by rbjtech
rbjtech
Posted (edited)

Hmm.. good to know it's 'moving' but I had a look at ffprobe v5 - there is still no 'side_data' for the Audio Tracks (ie no Atmos confirmation)  nor HDR10+ nor HLG details.   So it only has DV info .. :(

Considering DV has been out for years - I'd probably suggest we carry on with the Plugin as at this rate, there will be a new set of standards by the time ffmpeg get to Atmos and HDR10+ ... 🤣

 

Edited by rbjtech
Posted
29 minutes ago, FrostByte said:

I believe there is also a patch for HDR10+ that been posted a couple times in the forum.  

What kind of patch would that be?

We can already see this from the frame-attached side data:

image.png.2603a56dfba319cbe430902d25cf0d1a.png

 

We just don't know from this whether it's HDR10 (always the same data) or HDR10+ (dynamically changing)

Posted
32 minutes ago, rbjtech said:

Useful to know - thanks @softworkz - I'll check ffprobe v5 - as if it contains the Dolby Atmos and DTS sub-types as well and emby plan to use/hold this data, then this could make the Plugin largely unnecessary

Yes, it's probably not worth to put much effort into this. There are surely more interesting things for spending time on.

rbjtech
Posted
9 minutes ago, softworkz said:

Yes, it's probably not worth to put much effort into this. There are surely more interesting things for spending time on.

Vs manually crating the titles - this Plugin will be a lifesaver for many who want to accurately represent their collections ;)

I wrote a script to do it a while ago - using info from mediainfocli - but a Plugin is a great solution to make it more accessible - even if it just does update the titlename per track.

Posted
7 minutes ago, rbjtech said:

Vs manually crating the titles - this Plugin will be a lifesaver for many who want to accurately represent their collections

Who wants this in the title? And doesn't it negatively affect identification for meta data retrieval?

Though I'm in no way opposed to that plugin. I've just read this conversation and thought I should let you know about the progress, to avoid potential bad feelings about having worked on this unnecessarily 🙂 

Cheesegeezer
Posted (edited)
9 minutes ago, softworkz said:

Who wants this in the title? And doesn't it negatively affect identification for meta data retrieval?

The title is actually the only thing that we can change (the displayTitle actually), as emby uses the rest of the info for transcoding i believe.  The display title i'm pretty sure in the core for each Track, is a string builder of say for video "Resolution" + "Codec.Format" + "HDR.Format"(if available).  

9 minutes ago, softworkz said:

Though I'm in no way opposed to that plugin. I've just read this conversation and thought I should let you know about the progress, to avoid potential bad feelings about having worked on this unnecessarily 🙂 

No disrespect here... the plugin isn't a monumental brain teaser.  it's very simple in operation and it's something I wanted to try and do, to learn more about the mediaInfoCLI, and give myself a wee challenge.

What progress exactly are we talking about here... with ffprobe??.. so they can identify Dolby Vision from what you have shown and with Rich's testing now,  Atmos, X or other advanced tags for these formats are NOT available.

I love your negativity so please keep it coming, it's making me more motivated to complete this :D 

Edited by Cheesegeezer
  • Like 1
FrostByte
Posted
50 minutes ago, softworkz said:

What kind of patch would that be?

We can already see this from the frame-attached side data:

 

 

We just don't know from this whether it's HDR10 (always the same data) or HDR10+ (dynamically changing)

I don't know, something sooty234/Doofus posted awhile back.  Luke mentioned it may be possible.

 

Posted
2 minutes ago, Cheesegeezer said:

What progress exactly are we talking about here... with ffprobe??.. so they can identify Dolby Vision from what you have shown and with Rich's testing now,  Atmos, X or other advanced tags for these formats are NOT available.

When I work on this, I'll probably also make some modifications in ffprobe as long as certain codecs are supported already. So far I was just waiting for the DOVI stuff to be completed, because I knew that some were already working on it and they are much better into the subject. 

7 minutes ago, Cheesegeezer said:

I love your negativity so please keep it coming, it's making me more motivated to complete this :D 

In no way did I mean to be negative. I just wanted to safe you from possibly being disappointed about having done redundant work. 

Otherwise, I'm happy about every single new plugin that somebody contributes!

  • Like 1
Posted
17 minutes ago, FrostByte said:

I don't know, something sooty234/Doofus posted awhile back.  Luke mentioned it may be possible.

 

Thanks. This is already included in ffmpeg.

  • Like 1
CBers
Posted
59 minutes ago, softworkz said:

Who wants this in the title? And doesn't it negatively affect identification for meta data retrieval?

 

53 minutes ago, Cheesegeezer said:

The title is actually the only thing that we can change (the displayTitle actually), as emby uses the rest of the info for transcoding i believe.  The display title i'm pretty sure in the core for each Track, is a string builder of say for video "Resolution" + "Codec.Format" + "HDR.Format"(if available).  

Sorry, am I missing something, but I thought this FR was for information to be added, not the names of the files being renamed?

I for one don't want my files renamed, otherwise I could do that another way before it even gets into Emby, but rather the badges showing in the information showing against each item to include more upto date information.

Confused 😕
 

  • Agree 2
rbjtech
Posted
7 minutes ago, CBers said:

 

Sorry, am I missing something, but I thought this FR was for information to be added, not the names of the files being renamed?

I for one don't want my files renamed, otherwise I could do that another way before it even gets into Emby, but rather the badges showing in the information showing against each item to include more upto date information.

Confused 😕
 

We arn't renaming anything - we just want to update the displaytitle value to say something better than '4K HEVC HDR'  (when it is infact a DV7 file) or TrueHD (when it is infact a THD File with Atmos) - as examples

Now this info CAN be in the MKV title field - and if it is - and you have configured Emby to use it - then Emby will display it.

The idea of the plugin is to simply replace the 'display title' (usually got from the MKV) with a copy that mediainfoCLI has CONSTRUCTED.

We arn't modifying anything atm - and even if we did, it would just be the mkv HEADER containing the new track titles, not the name of the MKV itself...

Posted

By "the title" they mean the display title of the track not the title of the film/item.

  • Like 1
  • Thanks 1
rbjtech
Posted
1 minute ago, ebr said:

By "the title" they mean the display title of the track not the title of the film/item.

Correct - thanks Eric !

CBers
Posted
12 minutes ago, rbjtech said:

We arn't renaming anything - we just want to update the displaytitle value to say something better than '4K HEVC HDR'  (when it is infact a DV7 file) or TrueHD (when it is infact a THD File with Atmos) - as examples

Now this info CAN be in the MKV title field - and if it is - and you have configured Emby to use it - then Emby will display it.

The idea of the plugin is to simply replace the 'display title' (usually got from the MKV) with a copy that mediainfoCLI has CONSTRUCTED.

We arn't modifying anything atm - and even if we did, it would just be the mkv HEADER containing the new track titles, not the name of the MKV itself...

 

12 minutes ago, ebr said:

By "the title" they mean the display title of the track not the title of the film/item.

 

10 minutes ago, rbjtech said:

Correct - thanks Eric !

Not entirely sure that's what the original requester, @FrostByte, was after, but I could be wrong.
 

rbjtech
Posted (edited)
4 minutes ago, CBers said:

 

 

Not entirely sure that's what the original requester, @FrostByte, was after, but I could be wrong.
 

Agree it's not - but until ffmpeg/ffprobe can get all the required info, and emby add the necessary fields to accommodate it - then it's not going to happen.

This is a partial solution where you get to see the details you desire - but you can't use them further - for filtering etc.  They are just for displaying info.

image.png.4f7506942569d9b6a16c05b566d29beb.png

It's automatically creating the detail shown by the Red Arrows.

Edited by rbjtech
CBers
Posted
1 minute ago, rbjtech said:

Agree it's not - but until ffmpeg/ffprobe can get all the required info, and emby add the necessary fields to accommodate it - then it's not going to happen.

This is a partial solution where you get to see the details you desire - but you can't use them further - for filtering etc.  They are just for displaying info.

 

This should be in the core though.
 

rbjtech
Posted
Just now, CBers said:

This should be in the core though.
 

It won't be until ffmpeg/ffprobe officially support it. 

Atmos is already 10 YEARS old - Dolby Vision is 8 YEARS old ..

If ffmpeg hasn't updated in all that time - I suspect it's probably not at the top of their priority list ... ;)

This is just a Plugin to help you to identify what's what and what to expect when you hit the play button.   If it says DV7 - then I expect the 'Dolby Vision' indicator on my TV to display as such, and if THD Atmos - I expect my AVR to do the same.  

CBers
Posted
4 minutes ago, rbjtech said:

It won't be until ffmpeg/ffprobe officially support it. 

Dibn't @softworkz say above that they already can?
 

rbjtech
Posted
Just now, CBers said:

Dibn't @softworkz say above that they already can?
 

For DV only - it can't do it for HDR10+,HLG,THD Atmos,E-AC3 Atmos, DTS:X,DTS HRA etc..

Cheesegeezer
Posted (edited)
15 minutes ago, CBers said:

This should be in the core though.
 

Keep up me ole Corn Beef!! lol

the core cannot provide these tags yet as they are using ffprobe (which doesn't have the feature set to extract this data) Softworkz was saying that Dolby Vision is available in ffprobe 5.0, however it doesn't display any advance audio codec formats is True-HD with Atmos or DTS:X, etc.

This plugin uses MediaInfo.exe and can provide this level of detail on both video and audio tracks.

Also if we alter the codec information, Emby wont understand this when deciding if it needs to transcode or not and may fall back to transcoding every file to be on the safe side.

 

@ebr is this correct

Edited by Cheesegeezer
Cheesegeezer
Posted

This forum is full of doom and gloom folk, no wonder no one wants to contribute and the core team can't be arsed with implementing feature requests if this is all they get.

  • Agree 3
Posted
41 minutes ago, CBers said:

Not entirely sure that's what the original requester, @FrostByte, was after, but I could be wrong.

No it isn't.  Apparently, you've missed the intermediate discussion.  They are talking about a stop gap solution Cheese is working on in a plug-in.

CBers
Posted
8 minutes ago, ebr said:

No it isn't.  Apparently, you've missed the intermediate discussion.  They are talking about a stop gap solution Cheese is working on in a plug-in.

So that should be in a separate thread then.

 

Guest
This topic is now closed to further replies.
×
×
  • Create New...