Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Manni]

As a final note, you can already check today which playlist MC chooses by right-clicking the video and looking at the "Titles" menu. It'll offer a choice between all playlists, with the one it deems the "main" at the top.
A more automation-friendly way so you can read it via COM or MCWS or whathaveyou will be added in the future.

Great thanks, I didn’t know this. Will you add a custom field as well so we can display the path/name of the currently played playlist it at the top of the JRiver screen?

[mattkhan]

stating the obvious but the ideal for me is for MC to give me its main title selection via MCWS and for this to be right all the time. The former sounds like it is coming but the latter I'm less sure about. I certainly don't find myself choosing a different title v often (ever?) but then the fact there seem to be multiple different choices which are appear to be the same (based on the available metadata) makes me wonder which one is actually correct. It feels like looking at cases where different sort/filter algorithms give different results should be useful for that case.

@manni01 re the diff between libbluray and MC, unfortunately I have none of those titles so can't compare directly here. If you run with -vvv then you'll get some output from libbluray describing why it is making the choice it does. I'm also just adding an option which will dump the metadata to a yaml file too, sharing this should be sufficient to recreate the selection process without needing to have the same disc locally.

[Manni]

stating the obvious but the ideal for me is for MC to give me its main title selection via MCWS and for this to be right all the time. The former sounds like it is coming but the latter I'm less sure about. I certainly don't find myself choosing a different title v often (ever?) but then the fact there seem to be multiple different choices which are appear to be the same (based on the available metadata) makes me wonder which one is actually correct. It feels like looking at cases where different sort/filter algorithms give different results should be useful for that case.

@manni01 re the diff between libbluray and MC, unfortunately I have none of those titles so can't compare directly here. If you run with -vvv then you'll get some output from libbluray describing why it is making the choice it does. I'm also just adding an option which will dump the metadata to a yaml file too, sharing this should be sufficient to recreate the selection process without needing to have the same disc locally.

Sure, I’ll install the new version when it’s ready and will give you the info.

Heindrick, is it ok to post the info here or do you prefer we use another way?

Edit: wow, I made it to Junior Woodchuck. I’m thrilled

[Manni]

Just to confirm which playlists are selected by JRiver now that I can display the title thanks to Heindrick's info:

The Spy Who Loved Me 00803.mpls (vs 00804 libbluray)
Ghostbusters II 00514.mpls (vs 00003 libbluray)
Ghostbusters 2016 00514.mpls (vs 00001 libbluray)
Gladiator 00041.mpls (libbluray selects 01061.mpls, same length). There are two editions on the disc, so I think in this case JRiver is correct, as 00040 is the extended version (02:50:56) while 00040.mpls is the theatrical (01:34:59)
Halloween 2018 00801.mpls (vs 00800 libbluray)
Inferno 00507.mpls (vs 00001.mpls libbluray)
Logan Lucky 00009.mpls (vs 00008.mpls libbluray)

Knowing which title is playing makes it easier to measure the playlist selected by JRiver manually, so thanks for the tip

[Hendrik]

Turns out our dupe removal logic was running in such a way that it could ignore the sort order, so that in some cases a seemingly random title could be choosen out of a bunch of duplicates (thanks to hash maps not being strictly sorted). I changed that to also always prefer the one with the lowest number.

That should match libbluray logic more closely, which means also what LAV does, for example, since it gets the title list from libbluray.

In before screwing over your measurement file names again.

[Manni]

Turns out our dupe removal logic was running in such a way that it could ignore the sort order, so that in some cases a seemingly random title could be choosen out of a bunch of duplicates (thanks to hash maps not being strictly sorted). I changed that to also always prefer the one with the lowest number.

That should match libbluray logic more closely, which means also what LAV does, for example, since it gets the title list from libbluray.

In before screwing over your measurement file names again.

Great thanks for looking into this

I'll wait for the new MC build before measuring more playlists when the current build finds a different one

[mattkhan]

I have implemented a sort that matches my understanding of your description of how MC works, doesn't agree with the actual behaviour though so there must be something missing (or I implemented it incorrectly or it's just the bug you just mentioned).

If I filter to the top 10% of playlists by duration and then group by no of audio streams (based on the max BLURAY_CLIP_INFO.audio_stream_count in all the clips) then I invariably get multiple playlists, do you do any further sorting at this point (e.g. chapter counts, video format) or is it really just the 1st playlist in that list?

[Hendrik]

Its really implemented using a compare function, which compares two titles at a time to sort them, and it basically works like this:

- if the two titles are within 10% duration of each other, compare audio streams
- if audio streams match, or the duration was more then 10% apart:
- compare duration, if equal, compare audio streams, if equal, compare filenames

That way in the end we have the longest title (within 10%) with the most audio streams at the top of the list.

If you know how such compare functions work, they want you to return a number expressing the order, typically <0 (less), 0 (equal), >0 (greater)

Code: [Select]

// in cases where two titles are close in duration but have a different number of audio streams,
// let the number of audio streams trump maximum duration for looking for the more "important" title
if (nPercentDifference < 10)
nCompareValue = pPlaylist2->m_nNumAudioStreams - pPlaylist1->m_nNumAudioStreams;

if (nCompareValue == 0)
{
// sort order is decided first by duration, then number of audio streams, then alphabetic filename order
nCompareValue = nSeconds2 - nSeconds1;
if (nCompareValue == 0)
{
nCompareValue = pPlaylist2->m_nNumAudioStreams - pPlaylist1->m_nNumAudioStreams;
if (nCompareValue == 0)
nCompareValue = pPlaylist1->GetName().Compare(pPlaylist2->GetName());
}
}

return nCompareValue;

[mattkhan]

right ok thanks, that makes it v clear

[mattkhan]

@Manni you can try this one -> https://github.com/3ll3d00d/madmeasurer/releases/tag/0.8.0

if you run it like

Code: [Select]

madmeasurer.exe -d1 --include-hd --analyse-main-algos "w:\"

then it will dump a file named main_report.csv into a dir named report (under wherever you ran it for now) and this will list the main titles calculated for each implemented algorithm for each BD, the last column is the number of unique playlists found so if this is >1 then we have a disagreement amongst the different approaches.

The --describe-bd option will dump out some yaml that describes the structure of the disc as seen by libbluray (goes in a file in the BD folder), this should be sufficient to be able to remotely debug why such a decision was made.

Obviously the above might be useless if I get it to produce the same decision as MC but I'd implemented it already so might as well share it

[Manni]

Thanks Matt, will do.

Do you want me to add the --describe-bd or not?

[mattkhan]

Matt not Mark

I think the --describe-bd is useful if there is a difference between the various sorts as then we can try to work out which one it should be and why the sort doesn't pick that one, I suggest attaching the resulting yaml file(s) to an issue over at github

[Manni]

Matt not Mark

I think the --describe-bd is useful if there is a difference between the various sorts as then we can try to work out which one it should be and why the sort doesn't pick that one, I suggest attaching the resulting yaml file(s) to an issue over at github

Sorry just realized about Mark

OK will do that.

[mattkhan]

@Hendrik I still can't get that sort to agree on certain tracks

e.g. zootopia, MC picks a playlist that is 12s shorter than a couple of other tracks. The top listed tracks are 00800 00801 and 00802 so I would think it will be comparing these directly assuming you're iterating through the playlists.

using the logic you posted would see it compare audio tracks because durations are within 10%, they both have 5 streams so cmp == 0. It will then drop into the duration comparison and should then pick the longer track.

My version of your sort is doing this, my MC client is not, it picks the shorter track instead  ?

[Manni]

I'm scanning two or three shares and I'm getting lots of messages saying:

Updating main title from xxxxx.mpls to xxxxx.mpls

Is this to be expected?

It's also remeasuring a few titles, but I'm not sure why as on that share the JRiver main titles that didn't tally with your algo had been remeasured already.

EDIT: The first remeasured title is Pacific Rim Uprising, and it's measuring 00040.mpls when 00801.mpls was detected as the main playlist by both MPC-BE and JRiver.
00040.mpls is marked as "FPL_Main_Feature" by makemke, and 00801.mpls is deleted as identical, so I would have used 00040.mpls if I had made an mkv from that title.

EDIT: oh and I forgot I had to create a "report" folder in the madmeasurer folder otherwise it was returning an error.

[Hendrik]

My version of your sort is doing this, my MC client is not, it picks the shorter track instead  ?

The currently released version of MC will only compare tracks by minutes. I changed it to also look for seconds for the next one. So by that logic it should currently select 00800 i reckon, since its the lowest alphabetically there.

[Manni]

I've edited my post above, it looks like the new algo is working well.

After the 00040.mpls for Pacific Rim Uprising, it's remeasuring 00800.mpls for Red Sparrow, when the formerly main playlist was 00801.mpls.

[mattkhan]

Skyscraper is one example of an apparently spurious discrepancy

libbluray picks 00801
jriver picks 00040
makemkv picks 00801 and labels it SEG_MainFeature
mpc-be picks 00801

mpc-be picks that one because of its filesize check (i.e. 00801.mpls is 56 bytes larger than 00040.mpls) whereas jriver discards it because it considers the two playlists equal (based on duration, audio streams or whatever) and it has picked 00040 as the chosen one (just because it reads the files in order).

On the other hand makemkv skips 00040 because it had picked 00801 first and considers 00040 equal, i.e. same apparent behaviour but just reading files in a different order.

Both playlists point at the same underlying m2ts and I can see the extra bytes in the latter just comes from that playlist mentioning the same m2ts twice.

I guess this says that some level of disagreement is just going to be the norm.

[mattkhan]

@manni https://github.com/3ll3d00d/madmeasurer/releases/tag/0.10.0 has an option to put the jriver finder into minute resolution mode so hopefully that finds exactly the same titles as MC does today. FWIW I've quickly tested a couple of titles that previously differed and they do now agree.

[Manni]

Sounds good.

Is there a way to combine the algos so that the tool will measure the playlists selected by MPC-BE and JRiver?

[mattkhan]

Sounds good.

Is there a way to combine the algos so that the tool will measure the playlists selected by MPC-BE and JRiver?

you probably want

Code: [Select]

madmeasurer.exe --main-by-jriver-minute-resolution --no-main-by-libbluray --main-by-mpc-be -m <shares>


[Manni]

you probably want

Code: [Select]

madmeasurer.exe --main-by-jriver-minute-resolution --no-main-by-libbluray --main-by-mpc-be -m <shares>


Fabulous

Thanks

[Hendrik]

Skyscraper is one example of an apparently spurious discrepancy

libbluray picks 00801
jriver picks 00040
makemkv picks 00801 and labels it SEG_MainFeature
mpc-be picks 00801

Either you or me must have weird versions of discs or a weird MakeMKV, because for me it selects 00040 just like MC does (and labels it FPL_MainFeature too).
libbluray does indeed select 00801, but it appears that libblurays logic will prefer the last playlist of equal-everyhting else, instead of the first. For some reason it doesn't delete it as duplicate. (Edit: found the reason, see next line).

Looking into it in more detail, I think 00040 is on my disc at least also the correct one to use, since 00801 lacks some playback marks. Thats not really important for title playback, but menus use them, so one would think thats the one to use.

I should probably add that status overlay for BD Menu playback that some people have been asking about, that way there is no doubt which one is the correct playlist anymore - even if you cannot automate that.

[mattkhan]

it appears that libblurays logic will prefer the last playlist of equal-everyhting else, instead of the first.

yes libbluray seems to come up with different results to everything else because of the fact it picks a new title if the comparison is <= 0 as opposed to picking the 1st "good" one it finds.

I should probably add that status overlay for BD Menu playback that some people have been asking about, that way there is no doubt which one is the correct playlist anymore - even if you cannot automate that.

I think that would be v useful

[Manni]

I agree that knowing the track selected with menus would be very useful to clear any doubt.

I have a question for Hendrick regarding subtitles.

When playing the main movie (not selecting through Menus) with MC, the forced subs are not played if subs are off.

For example, with The Revenant, you have to select the second Eng subs track to only get forced subs displayed on screen (the first track seems to be for hard of hearing). It's a good title to test as you have forced subs in the opening sequence.

Is there a way to get what you get with a standalone player when playing the main title, or is this only achievable when using the menus to start playback? Unfortunately I couldn't test with menus for that title as for some reasons menus end up on a black screen after the first video played, before you reach any menu.

I understand that this is not possible with mkvs, but when playing BD Folders, assuming the correct playlist is selected, isn't there a way to get the forced subs to play automatically?

Thanks!

[Hendrik]

Blu-ray structures have no way to signal such information, so no.

[Manni]

Blu-ray structures have no way to signal such information, so no.

Ok thanks for the quick reply. One more reason to use the menus.

[Manni]

you probably want

Code: [Select]

madmeasurer.exe --main-by-jriver-minute-resolution --no-main-by-libbluray --main-by-mpc-be -m <shares>


Just to say that this seems to be working very well. I'm using this to measure the second half of my collection, and while it most of the time measures only one main playlist, it occasionally measures two. For example, with The Martian Extended Edition, it measures both 00800.mpls (JRiver's pick) and 00801.mpls (MPC-BE pick).

So thanks again and well done!

I'll report in github rather than here is there is any title for which it misses one or the other selection, unless it looks like it might be a JRiver issue, though there is no point doing this until the next build is available. I noticed that a 5xx track was still selected occasionally, but I assume this will be resolved in the next MC build.

[Hendrik]

25.0.24 is now available which includes the mentioned changes to title selection.

[Manni]

25.0.24 is now available which includes the mentioned changes to title selection.

Great, thanks for letting us know

[Manni]

One question for Matt: if this new build works as expect, does it mean that we only need the --main-by-jriver now and not the minute-resolution one as well?

[mattkhan]

One question for Matt: if this new build works as expect, does it mean that we only need the --main-by-jriver now and not the minute-resolution one as well?

Yes you can remove the minute-resolution one now

[Manni]

Yes you can remove the minute-resolution one now

Great, thanks for the confirmation.

I'll run some checks and will report back if there is anything worth reporting

[jmone]

HI Matt - moving the conversation over from AVS.  I take it that with your tool, it will:
- Identify the correct MPLS that MC Will use
- Generate a measurement file for that MPLS
- On playback (both with Menus or Title) madvr will use that measurement file against on each HTPC (so we have have different target settings based on the ability of the HTPC and the Display).  If I have that correct then   - If so I'm not sure what extra Flo's tool does in such a setup.

Also what version of madVR should we use for this measurement (I'm using V40 as that is what was in Flo's post but I don't think it is the latest).

Thanks
Nathan

[mattkhan]

Yes that is correct

Flo's tool changes the data in the measurement file according to the algorithm of their design, I haven't used it myself but I believe it is basically a different way to handle tonemapping making use of knowledge of the future to minimise the probability of any glitches in output caused by, e.g., scene changes. tbh I haven't noticed any issues using madvr directly (n7 projector) so I haven't bothered using their tool. I use the latest test build btw (86?)

For your case, where you want different settings per client, I think you would have to change the madvr config to use a local measurements folder and then process the original content using their tool n times (once per client that wants optimised settings).

[jmone]

So I've got it all working with Title Playback (Thanks!). 

...but it does not seem to work with Menu Playback, defaults back to dynamic measurements.  Is this expected?

Thanks
Nathan

PS - I'll just stick with your tool for now as the measurement file will work across multiple different HTPC/Screen setups.

[Hendrik]

I don't think madVR implemented the required stuff for this to work with Menu playback yet.

[Manni]

I don't think madVR implemented the required stuff for this to work with Menu playback yet.

No I asked Madshi recently and although he confirmed it’s on his to do list, he hasn’t had the time to implement measurement files with BD Menus support yet.

[jmone]

Thanks gents, I'll measure all the files now anyway and lets see what later version bring.  It's going to take a week anyway as it is taking an hour(ish) per MPLS.

[mattkhan]

That seems v slow, what card are you using?  Or somewhat slow network connection to the file server perhaps?

[jmone]

GTX1660Ti (running about 33%) but my i7-8700K us getting hammered by madMesaureHDR.exe... 100% (all cores) all day and I've only done 6 movies so far!!!

Edit - Discs are local to the box (in a pool) and they don't look that busy.  Bottle neck is the CPU and the 8700K is no slouch

[mattkhan]

I have a 1060 with a i7-4790 (so much older CPU) connected to a file server via a teamed LAN port, this is 15-20min per film. IIRC there are some settings that can affect performance here though I do not remember what they are.

[jmone]

Don't you hate when you forget stuff!  Anyway this is my cmd line at present:

madmeasurer.exe -d1 -vvv --main-by-jriver --mad-measure-path "C:\Users\natha\AppData\Roaming\J River\Media Center 25\Plugins\madvr" -m  "M:\Media\Discs"

If you could remember the /gofast switch that would be great as it is well over an hour per movie for me!

[mattkhan]

it's not a switch on my tool. IIRC it uses 32bit LAV and people generally find that D3D11 Native is the fastest mode to use, it does print this when it starts though like

Code: [Select]

Measuring video file "w:\Aquaman\BDMV\PLAYLIST\00089.mpls" using D3D11 (native).

what does yours say?

[jmone]

just -

Code: [Select]

Measuring video file "M:\Media\Discs\10 Cloverfield Lane\BDMV\PLAYLIST\00800.mpls"...

[jmone]

Just changed my (non MC) Lav config to D3D11 and will restart.

[jmone]

That looks better.  CPU is now 33% and I've now got some GPU Video Decode going (it was 0 before)!

[jmone]

Just did the first one in 15mins!  
Thanks Matt.

[jmone]

Thanks for all the help.  The util generated 110 Measurement files which is a bit lower than I thought as I have 180 UHDs so far.  We use BD Menus a fair bit so I hope madshi finds the time at some point.

[Manni]

Thanks for all the help.  The util generated 110 Measurement files which is a bit lower than I thought as I have 180 UHDs so far.  We use BD Menus a fair bit so I hope madshi finds the time at some point.

You might want to make this request to madshi in the "improving HDR tonemapping in HDR" thread on AVS. I don't know if anyone apart from me has made this request to him. Knowing that I'm not the only one might bump the item up his to do list a bit.

The only way to use/test measurements files is to switch to main title playback, which means that we lose the automatic selection of the correct default forced subtitles in many cases. That's for me the main downside of not using BD menus when playing the movie itself.