I was going to make some suggestions about Player via the Bug and Feature Request List page (https://dcpomatic.com/mantis/my_view_page.php), but it wouldn't let me in with my normal User Name and password. Do I have to sign up with a second account to access that page?
Anyway, I'm impressed with the Player. Excellent work, Carl and whoever else helps out. I've been putting off arranging with local cinemas to show my AVs because I couldn't test DCPs at home. My worries weren't helped by the comment from someone who regularly hires a cinema for showing Indian movies -- that twice he's had to pay for a second showing because the DCP didn't work (twice -- at $1200 a pop). Well... that convinced me to stick with Blu-ray. However, one cinema quoted me $350 extra to use Blu-ray; and another said only under exceptional circumstances. But now with this Player… if the DCP works in the cinema, I'll feel guilty if I don't make a decent donation.
Suggestion
The default size of the Player window on my 27" iMac is full screen (2560 x 1440). At that size, and with my 2013 processor, there are a lot of dropped frames. So I selected Decode at 1/2 resolution. That reduced the number of dropped frames, but they were still present. And of course, there was obvious pixellation.
I then chose Decode at 1/4 resolution. There were still dropped frames, and quite a bit of pixellation.
So I tried reducing the size of the Player window –- and below a certain size, the dropped frames went to zero. So there is an interaction between the Decode resolution, Window size, and dropped frames.
Like with Quicktime Player (which allows image size to be set to 100%, 50%), it would be useful to be able to set the image size in the Player to match the Decode size. I'm assuming by doing so, that you retain sharpness with no pixellation.
i.e. if I choose Decode at half resolution, and I then set the image size to 50% (540 pixels high for my 1080P content), I should get a nice sharp half-size image, and a reduction in dropped frames.
As it stands, I drag the bottom right handle of the window, and roughly size the image to 540 pixels high. If I could set it to exactly 540 pixels high, I'm sure that would decrease the number of dropped frames even further, because it must be quicker to scale by a factor of 0.5 than, say, 0.5764328.
Comments on the Player
Re: Comments on the Player
Hmm, I rarely work on highres screens with the player, but in general, the J2K decoding is the really heavy work, not the scaling to display window size. Maybe there is room for improvement without the need to follow your suggestion to reduce the display size. Maybe simply using integer scaling could improve playback performance. But maybe having a second display option - 'set display to decoding resolution' could be useful for the time being.
I think it hasn't been mentioned in detail before, some may have found this out by themselves:
When you play audio in the player, there are many dropped frames, because audio is the sync source and needs to be played contiguously. If the J2C decoder can't follow, the only way to keep up with the audio is to drop frames.
On the other hand, when you disable audio, the player will play ALL frames, no matter how slow it needs to be - you will see every single frame. Therefore, you will never see dropped frames when audio is disabled, even if the video is playing very slow. Maybe Carl can add a FPS performance indicator as well. I could be dropped frames when audio is played, and FPS when audio is not active.
I would also love to have a checkbox near the preview window, or keyboard shortcut to enable/disable audio quickly.
You can still choose decode resolution when not playing audio, this will speed up the playback of every frame and might bring you closer to realtime, depending on your hardware. So, there are options to choose from when testing your DCP.
I also noticed that sometimes having DCP-o-matic open in the background also causes severe performance loss in the player, even when it is not actively doing something. However, I can not always reproduce that behaviour. Maybe Carl has fixed that in newer versions.
- Carsten
I think it hasn't been mentioned in detail before, some may have found this out by themselves:
When you play audio in the player, there are many dropped frames, because audio is the sync source and needs to be played contiguously. If the J2C decoder can't follow, the only way to keep up with the audio is to drop frames.
On the other hand, when you disable audio, the player will play ALL frames, no matter how slow it needs to be - you will see every single frame. Therefore, you will never see dropped frames when audio is disabled, even if the video is playing very slow. Maybe Carl can add a FPS performance indicator as well. I could be dropped frames when audio is played, and FPS when audio is not active.
I would also love to have a checkbox near the preview window, or keyboard shortcut to enable/disable audio quickly.
You can still choose decode resolution when not playing audio, this will speed up the playback of every frame and might bring you closer to realtime, depending on your hardware. So, there are options to choose from when testing your DCP.
I also noticed that sometimes having DCP-o-matic open in the background also causes severe performance loss in the player, even when it is not actively doing something. However, I can not always reproduce that behaviour. Maybe Carl has fixed that in newer versions.
- Carsten
Re: Comments on the Player
Thanks, Carsten, for all the extra info on the effect of disabling audio. I'll give it go.