slow performance and only 3 sound channels

[createmedia]

Hi Carsten

Ok thanks for telling me the limitations and perhaps it would be a good idea to suggest a workflow with a QC path like you described.

I do have a big mystery though. The Microsoft wave extensive channel ID 7.1 test file has the side and rear identification announcement tracks in reverse order, i.e. the side channel announcement is on tracks 7 and 8 but the track id announcements come out of the Realtek soundcard and the creative speakers correctly.

The reverse order shows up in the edit software, Premiere Pro or Grass Valley Edius.

Bringing that file into Audacity confirms the wrong track order but the channel ID announcements come out of the correct speakers.

Checking the speaker wiring via the Realtek control panel test, the test samples come out of the correct speakers as per the on screen graphic.

In Audacity audio on channels 5 and 6 comes out of the rear speakers. Really weird.

The Fraunhofer AAC codec 5.1 test on the PC produces surround sound ID out of the side but not the rear speakers.

The CPU's are Dual E2697 they are actually dual 18 core water cooled, but I have them throttled back to dual 16 cores in the bios as my edit software limits at 64 logical cores.

Mike

[Carsten]

Strange about the audio. Well first, audio channel mapping can be very different for Home Video, cinema environments, etc.

To play e.g. a 7.1. DCP from DCP-o-matic through HDMI 8ch, I need to remap rear surround channels 11/12 to 7 and 8 in DCP-o-matic (which normally carry HI/VI-N). But that is expected behaviour.

Now - player performance - Actually I see the same thing on my Dual HexacoreHT machine - very low CPU utilization, choppy playback. It SHOULD be much better, because I have better performance on my Mac Book Pro with a single 4core HT 2.3GHz.

I think the problem is the viewport/window size. Try playing with the window size at different decoding resolutions, and you will notice that some (usually smaller) settings will give a much better playback performance, even if the J2K decoding resolution stays at full or half. There must be a bug somewhere in the playback window scaling or something. You would assume that 'Set Decode Resolution to match display' does exactly that - for a 1998/1080, set display size to 1998/1080 for full res decode, 999/540 for half res decode, 499/270 for quarter res decode. But that doesn't happen.
Rendering a 999/540 decode into a 999/540 display window could possibly solve the issue. You wouldn't think that a simple rescale costs that much performance, but maybe there is a bug somewhere.

Someone mentioned this earlier in another thread a few months ago, he would get better playback performance if he set the window size exactly to the DCP decoding resolution. However, without a numerical indicator, I did not understand what he meant or how he did it. Maybe he just tried until he saw some improvement. I think I suggested to Carl to implement this feature back then - 'set playback window to decoding resolution'.

Found it: viewtopic.php?f=2&t=1088&p=4225&hilit=decoding#p4225

Now, that is a bummer currently, but, at the same time, if the player manages choppy playback at 10% CPU load, if this can be fixed, we'll get a nice player...

- Carsten

[carl]

Installed the 08F version which is just the same, I can't detect any difference.

Just to clarify: you are seeing no difference in playback or encoding speed with that version?

[Carsten]

I'll give that one a try here, too...

Carl, can you imagine that the actual display window resolution could be relevant? What is happening if I set decoding resolution to full (e.g. 1998*1080), but set the window size very small, like 333*180 - is the player still decoding J2K at 1998/1080? Because, that is playing smoothly. When I change the window size with the mouse to arbitrary sizes, I sometimes seem to find proportions that play with no/fewer dropped frames, but when I change the size only slightly, dropped frames increase considerably.

What if you set the active pixel/playback area 1:1 to decoding resolution (or integer multiples/divisors)?


- Carsten

[createmedia]

Correct no change in playback with latest version

My screens are 1920 by 1200 dual display, GTX1080TI water cooled.

Daum Pot player is very happy with the video playback of the DCP MXF files in terms of decoding speed but produces a strange colour phase shift. A red sweatshirt comes out dull orange, VLC produces the correct colour but stalls completely and won't play.

Daum Pot Player will also play the audio channels MXF via the sound card but puts the side channels out on the rear speakers. It won't of course recognise channels 11 and 12.


From the Pot Player playback window

[Used Filter List]
(1) Built-in FFmpeg Source(MXF (Material eXchange Format))
(2) Built-in Video Codec/Transform
(3) Enhanced Video Renderer(Custom Present)

[Video Information]
Codec: mjp2 - Built-in FFmpeg Decoder(libopenjpeg, Thread Frame)
Input type: mjp2(24 bits)
Input size: 1998 × 1080(1.85:1)
Output type: NV12(12 bits)
Output size: 1998 × 1080(1.85:1)
Frame rate: 24
BitRate: Unknown


VLC plays the audio MXF but plays the centre channel on the side left speaker and plays the side channels on the rear speakers.



Mike

[Carsten]

As long as this is not solved in DCP-o-matic player, try e.g. Steroscopic player, or Dolbys Cineasset Player demo.

There must be something weird with your audio devices. You can buy cheap USB-5.1/7.1 audio interfaces, I think they will work better.

I guess, sooner or later, we need a playback audio matrix in player.

- Carsten

[Carsten]

Decoding 'at' 1998/1080, playback at roughly 740/400 - zero dropped frames with audio on a MacBook Pro 4coreHT 2.3GHz i7.
So, what is actually going on when full res decode is chosen, but playback window is smaller?

- Carsten

Bildschirmfoto 2018-11-26 um 23.35.40.png

[Carsten]

Oh wow, but it looks as if the recent (2.13.6x/7x) player versions show significant issues with playback vs. playhead position. Very unreliable when playing back different parts of a clip. Don't even know how to describe the behaviour. Sometimes playhead is sticking, image frozen, etc.

Seen in 2.13.72 and 2.13.68 on Sierra. One thing I always notice is that the playhead jumps to the end whenever I enter or exit full screen mode.

Aside from that, I notice something like a play-ahead caching in 2.13.72 - when stopped, CPU activity is high for a while, and upon playback, a few seconds I see smooth playback at full decode resolution. Then it drops back into stuttering. Looks as if the player is buffering a number of frames into memory.

Now, for anyone just chiming in, I don't expect a 2.3GHz 4coreHT notebook to play DCP at full res. I'm just wondering why it seems to do nicely with some display settings, and worse with others. Just now, for no apparent reason, I played the full Star Wars trailer at half decoding resolution with audio without a single dropped frame on this machine. And it was clearly NOT quarter res, I can easily see that around titles. So, Carl may be on a good track there, but it seems to need some further tweaking.


- Carsten

P.S. - Carl, please forgive me for whining about the playhead sticking and jumping on full screen switches. 2.13.72 is doing something damn right. My 2012 notebook CPU temp goes up to 100degrees, my CPU clock jumps from 1.5GHz idle to 3.1GHz turbo. And it plays at half decoding resolution with audio without any dropped frames at near full screen display size.
Now the only issue left is that I can't play a full length feature that way without the CPU desoldering itself...

I don't get half that playback performance in 2.12.13 - but the CPU is still running hot.

[createmedia]

Ok the only player that works for me is DCP Player from digitAll its a pay one $49 but it works perfectly in real time but with one little error message as below. https://www.digitall.net.au/dcpplayer/

Stereoscopic player produces a color phase shift playing MXF files on the desktop as does pot player.

I point DCP PLayer at the ASSETMAP HTML file in the main folder and it plays the file with audio. The second time I load the same ASSETMAP I get an error FAILED(hr=0x800700e) in pMC->RUN() and it needs closing before trying another film.

On a right click its default decoder is Morgan DirectX 9 and it uses the second (bizarre) 16 core CPU at 50% load. Switching to Morgan Direct X 10 reduces the CPU Load to 31%. It rises back to 50% if I switch the decoder to display in 10Bit.

Now back to the desktop audio in DCP Player I get L,C,R correct LFE correct, RL=SR, BR=SR, BL=SL entirely consistent with earlier results but at least all channels work.

I will have to try a USB sound card.

[Carsten]

Some players decode J2K/mxf 'accidentally' - then typically missing the necessary XYZ->RGB display color conversion. They simply assume all video files are sRGB/rec709 based.
These players also usually do not parse the CPL, but simply play the raw MXF files. That may be useful for a simple encoding test, but, not much more.
VLC does a good color conversion though. It is meant to decode DCPs (CPL), but the decoding performance currently is very bad. It is still very useful for e.g. single image grabs ('video snapshot') from DCPs, as VLC performs them with proper XYZ->RGB conversion and at real source resolution (it will e.g. deliver a 4k PNG from a 4k DCP).

Digitall's DCP Player is based on the Morgan Player. It has an impressing J2K decoding performance. I use it on an older i3 notebook and it does nicely there, although I think it doesn't tell you wether it's missing frames or reduces decoding resolution. But it simply works.

Unfortunately, they do not seem to put much further development into it, wondering what will happen when SMPTE DCPs become more prominent.
For now, it is not a bad solution. DCP-o-matic player still has quite a few features more, but the best J2K decoding performance is not one of them, as it is based on OpenJPEG (which is a reference implementation, not a performance optimized one). It is still impressing how much improvement Carl was able to squeeze out of it over the last year. The trouble is, you stepped in too late to notice them

I am pretty sure, though, that the issue with your multicore machine can be sorted out, and DCP-o-matic player can be used. There is no reason why you shouldn't keep all cores busy during decoding. Did you try the player without having DCP-o-matic main in the background?



- Carsten