Jump to content

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


FrostByte

Recommended Posts

FrostByte
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.  

Link to comment
Share on other sites

rbjtech
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
Link to comment
Share on other sites

rbjtech

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
Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

rbjtech
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.

Link to comment
Share on other sites

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 🙂 

Link to comment
Share on other sites

Cheesegeezer
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
Link to comment
Share on other sites

FrostByte
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.

 

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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
Link to comment
Share on other sites

CBers
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
Link to comment
Share on other sites

rbjtech
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...

Link to comment
Share on other sites

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

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

rbjtech
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 !

Link to comment
Share on other sites

CBers
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.
 

Link to comment
Share on other sites

rbjtech
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
Link to comment
Share on other sites

CBers
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.
 

Link to comment
Share on other sites

rbjtech
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.  

Link to comment
Share on other sites

CBers
4 minutes ago, rbjtech said:

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

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

Link to comment
Share on other sites

rbjtech
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..

Link to comment
Share on other sites

Cheesegeezer
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
Link to comment
Share on other sites

Cheesegeezer

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
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

CBers
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.

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...