Print

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

[mattkhan]

The background to these Qs is the is ongoing discussion over at avsforum with the HDR support in madvr, in particular the new cli tool for offline analysis of a film. This doesn't seem to play entirely nicely with the use of BD folder rips and it's not clear whether it is one or all of MC, LAV splitter or madMeasureHDR that is causing the measurement data to not be used reliably. There is some detail in the posts around https://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2954506-improving-madvr-hdr-sdr-mapping-projector.html#post57030428 but basically

- measurements generated by live playback => a measurement file in the BDMV/PLAYLIST directory named after the stream containing the main film
- measurements generated by offline analysis of index.bdmv => a measurement file named after index.bdmv

The measurement data is not used when you play the film in MC in either case. What does seem to work reliably is described in https://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2954506-improving-madvr-hdr-sdr-mapping-projector.html#post57030670

i.e.

- use madMeasureHDR.exe to analyse the index.bdmv
- play the index.bdmv in jriver to work out which playlist entry is the main film (which is now easy because a measurements file is dumped there)
- copy index.bdmv.measurements to PLAYLIST/<streamname>.measurements (overwriting the generated mpls.measurements file)

Now for the questions....

1) any plans to add support for this tool in a similar fashion to audio analysis? it would be a nice option
2) is it possible to get this working reliably with BD folder rips? madshi suggests he is just using whatever LAV Splitter Source tells him the file is.

btw, and as a minor curiosity, I noticed that the MC library entry points at index.bluray;1 which does not exist, the actual file is index.bdmv, and if I edit it to point at index.bdmv then it reverts it immediately to index.bluray;1 . Why does it do this?

[Hendrik]

Media Center typically doesn't actually play index.bdmv, it reads the Blu-ray playlists itself and then directly opens a specific playlist file, ie. one of the mpls files in the PLAYLIST directory.
The filename shown in the library reflects that fact, it points to the meta "Blu-ray structure", instead of any specific files. The ";1" at the end indicates that its an "aggregate" file, and not an actual file.

Note that menu playback will likely have real issues with this, because it of course can play any title on the disc.

[mattkhan]

right ok, thanks for the info.

I imagine this will be made to work seamlessly at some point but until then is that main movie playlist entry exposed anywhere in MC? I'm just thinking in terms of how to automate this process. I suppose worst case I can use MCWS to start playback then stop and then search for a measurements file.

[Hendrik]

No, that information is not stored anywhere.

Automatic integration of that process will also be hard up to impossible, since its an external tool that relies on system-wide installed DirectShow filters, something MC tries to generally stay far away from. So unless madshi produces a variant that one could run as a DirectShow filter in a custom graph (which I doubt he has plans for), that'll have to remain a manual process for the time being.

Maybe we can figure out how to identify HDR movies, so one could more easily script such a process.

Alternatively, if someone wants to give me a lecture on the math required to calculate the measurements file myself, that might also be an option. Or just flat out code to calculate it given a video frame. :p

[mattkhan]

well there is a description of the file format in https://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2954506-improving-madvr-hdr-sdr-mapping-projector.html#post57030812 but more than that is one for madshi

regarding the misdirection between index.bdmv and the main playlist, any chance you can comment on https://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2954506-improving-madvr-hdr-sdr-mapping-projector.html#post57031086 ? I thought it was LAV that does the bd playlist parsing, if so and madshi's cli tool is using LAV and it does accurately parse the main playlist file then I guess there should be some way for him to output to the matching file with the tools he is already using.

[Hendrik]

I suppose LAV could adjust which file it reports as current based on which playlist it actually ended up playing. However if playing in MC, MC selects the playlist, not LAV.

[mattkhan]

a way to close the gap automatically would be handy

even a simple hack like MC copying index.bdmv.measurements to PLAYLIST/<playlistname>.measurements before playback starts would do the job (though I realise you may not want to add such a hack!)

[madshi]

Alternatively, if someone wants to give me a lecture on the math required to calculate the measurements file myself, that might also be an option. Or just flat out code to calculate it given a video frame. :p

It's quite complex. First of all the video needs to be decoded, then you need to measure every pixel of every frame, implement some kind of scene detection algorithm based on the measurements, and then store all the results in the measurement file. If you do that on the CPU, it will take ages. If you want to do it on the GPU, it will probably require DirectCompute (at least for the histogram data). So it's not something that can be done in a couple of hours development time. Finding a good algorithm to reliably detect scene changes (without too many false positives) alone is already quite a challenge.

Is there any way we can optimize the file path LAV reports in such a way that it minimizes the possible variations of file paths/names for the same underlying movie? Of course it's very important that the same file path is only reported in case playback is really 100% identical. E.g. if playing the index file results in a couple frames more or less decoded than playing the movie's playlist, then it must still be reported as a different file, otherwise the pre-processed measurement file would do more harm than good! I may also have to talk to MPC-HC/BE devs. The ultimate goal probably needs to be that madVR can somehow identify which movie is being played, in such a way that as consistent as possible, and ideally identical between MC and MPC.

I guess it's a really complicated problem when talking about Blu-Ray discs. There can be multiple editions (theatrical vs extended), different seamless branches, different playlists with varying studio intros etc etc. It's oh so much easier when playing a simple MKV file, obviously...  <sigh>

[Hendrik]

LAV itself will only ever play a certain playlist, which should be uniquely identifiable by the name of the playlist filename.
But you're screwed of course if you're talking about actual Blu-ray disc playback with menus etc.

[madshi]

Does playback with menus end up in playing a specific playlist? If so, maybe LAV could report the playlist file name once it switches to that?

[Hendrik]

Everything that plays video/audio is a playlist, only some pure-BDJ things are without a playlist (and not very relevant), and playing a menu-based disc can result in a variety of playlists being accessed. I don't exactly know which playlist does what, so I can't confidently recognize the main movie at that point, but if we determine some way to communicate that the playlist changed just now, I could just fire such an event everytime it does.

[madshi]

That would help a lot. I could simply check for each reported playlist if I can find a matching measurement file.

[Hendrik]

The Blu-ray Navigator filter currently sends an EC_LENGTH_CHANGED everytime the title changed (so the player can update its stuff), maybe thats already enough for you to re-check the filename, once I implement that down the line, anyway.

You're still getting screwed when you have a multi-edition MKV file. Although they are rare, since its a bit hard to properly rip a multi-edition Blu-ray like that, they do exist. I only have one, because I was way too lazy to rip stuff that way most of the time.
I wonder how you deal with seeking though? Frame counts and timestamps can be a bit hard to correlate exactly.

[madshi]

So if I understand correctly, EC_LENGTH_CHANGED is already implemented and I could already check for that, and the only "missing" thing is that you don't report the changed playlist file path/name yet. Correct?

Seeking seems to work fine. I'm calculating floating point frame numbers based on runtime (not graph time) and fps, and I'm getting values that are very near to even numbers, e.g. 1.05, 1.98 etc. Of course there's always a risk that the timestamps in the m2ts file might be weird. In that case I might run into trouble. Not sure what to do then. But so far it seems to work well.

[Hendrik]

So if I understand correctly, EC_LENGTH_CHANGED is already implemented and I could already check for that, and the only "missing" thing is that you don't report the changed playlist file path/name yet. Correct?

Correct, that event fires today, at the correct time as well (well, sort of). Just the return from GetCurFile doesnt change.

The only limitation of the event is that the source filter can't exactly know how many frames are left in the decoder/renderer, so it would fire when it switches playlist, and right before it will deliver the first frame from the new playlist, but it could be possible that an old frame is still stuck in the decoder. There should be a seek (to reset the timestamp in the graph, a clever hack to reset timestamps to 0 on playlist change, and not do what DVD does and keep incrementing timestamps indefiniteyl) and a NewSegment call to indicate the actual arrival of the new frames.

[madshi]

That's fine, thanks! Could you notify me when you have a build out which has the GetCurFile changes? (It's probably not urgent.)