Just picked up a Z9S, overall very impressed. On the latest firmware. However, noticed a few little annoyances: 1) The first time I play a newly added HDR MKV file it doesn't output it as HDR2020; the output is tagged as SDR709 (also no badges displayed). It only plays correctly the second time round (After the badges are populated). Is there any magic to do with filenames etc which will make it correctly trigger HDR output mode? 2) The OSD text for fast forward etc is super-annoyingly located - it is just at the vertical halfway position for the 2.35 bars on most movies, so with a 2.35 masking screen it is half cut off. Any way to either remove completely, or move to another location, the OSD text in the player? 3) I can't quite work out what is going on with subtitles, it seems very often subtitles are auto enabling for MKV files. Do I need to do "something" to the files to stop this? I think I've got all the settings appropriately configured.
There's no filename magic to perform, as long as you have the Zidoo HDR set to <Auto>, the device will output the file as is - it passes through - there's no "triggering" in the Zidoo - the file itself is either encoded at HDR levels or not and it just squirts out the HDMI at the levels it was encoded at, unless you have HDR > SDR set, the Zidoo does nothing to the file. (HDR > SDR performs the tone map in the device rather than the display, remaps BT.2020 to Rec.709 and removes the SEI) It's the display device that must be triggered and this is done by metadata within the file - the HDR SEI (supplemental enhancement info) message. If the file has this message encoded correctly the Zidoo does nothing extra to it, it simply passes to the display device which then decides what to do with it. I've never seen the behaviour you describe, but I can only assume there's something wrong with the SEI message in the file. Badges are not displayed until played because the scraper doesn't include MediaInfo but the player does and passes that info back to HT2 after playback. Maybe send an email to service@zidoo.tv with regards the OSD position - I have a masking screen too although I can't say I've ever used fast forward or rewind - only pause and I use the Play/Pause RS232 command for that (#PLA) and that has no OSD, unlike discete pause (#PAU) which does. As for subtitles, if they still show up after turning them off, I'd assume they are flagged as forced - check in MediaInfo and remove the flag with MKVToolnix if required.
Thanks for the reply. I haven't had time to test the other points in depth, but have spent a long time testing this of HDR playback intermittency. All my files are MKV UHD disc rips. It doesn't seem related to first play after a long set of tests - it seems to be about 1 in 3 playback attempts of the same movie the Zidoo does not detect that the content is HDR2020. I can see this is the case as in the info screen the failed times it clearly says the output is 709 instead of 2020. For what it is worth it appears to also happen if you enable the tone mapping in the Zidoo - when it isn't detecting HDR2020 the image is all washed out. I'm using the same piece of content over and over, and have disabled auto resume so it is playing from the beginning each time. Repeatably about 1 in 3 attempts there is no HDR playback (which of course results in very washed out colours as the video is still 2020 colourspace, but the display interprets it as 709 as that is how it is being tagged by the Zidoo) I've tried every combination of settings I can, and nothing seems to affect this. It is very annoying. PS we have similar screens it seems, I've also got a Screen Research unit with masking. I'm driving mine automagically from a Lumagen processor (using a raspberry Pi to drive the screen controller) which is another reason for trying to get rid of the seek overlays - they get detected and open up my masks! I'll email Zidoo to see if they can be moved or removed.
That was a really strange one - so not only was the Zidoo not passing the SEI to the display, it was also interpreting the video as Rec.709.. Anyway, glad it's sorted. Good old factory reset... And nice to see someone else with a Screen Research - don't come across that very often I use a Crestron system to control mine but have no feedback from the system to tell me the aspect ratio of the video to set the screen - so does that cope with say a 2.40:1 letterbox in a 1.78:1 encode as you get in a BD remux? And how do you deal with multi aspect presentations (Dunkirk springs immediately to mind)?
Yes, it was very odd. Gone now though it seems. Mine is is an ETC with top / bottom masking (room is constrained width wise). I quite like it, though in honesty I'm probably sat a little too close and the weave is apparent in some bright scenes. I guess you are in the UK given the PMC/REL combo? The Lumagen deals with remuxes fine so long as the source has bars that are black-ish. It initially was too picky about the bars but I worked with the guys at Lumagen a bit and now the detection is very robust. Usually takes a second or two to lock on, which for me with a slow-synching JVC usually means the masks are in motion before the image hits the screen. I have a preset to disable the mask movement for the few titles with variable aspect ratios. It also doesn't currently deal with odd ratio titles that are greater than 2.4:1 (such as Lalaland). As an aside; am I expecting too much for UHD rips such as Billy Lynn to play glitch free over SMB? NFS is terrible, but SMB is only just not working it seems.
Mines top & bottom mask too - I never understand why people rave on about CIH screens when a CIW screen gives a much much bigger 1.78:1 image for the same 2.40:1 image... Mad! Mine's Solidpix though, so no weave. And you've heard of PMC too - awesome A friend of mine is a dubbing mixer and when I was looking for speakers he gave me a demo in a dubbing theatre that was tuned by a company called Munro Acoustics with PMC IB1 fronts and Wafer rears (on Bryston amps) - I was sold! I like the idea of AR detection and the way I deal with variable AR is simply to electronically mask to 2.40 (or 2.2 in a few cases) and set the masks accordingly since the DOP will always frame for 2.40 as well... I hate variable AR particularly when you're used to a masked screen - drives me mad. I haven't got Billy Lynn so I'm not sure, but the vast majority of my rips remain as full fat remuxes (I re-encode stuff I'm not hugely bothered about after watching the first time) and so far the Z9S hasn't missed a beat (these at 4K23 though, not 4K60). I stream over SMB - originally tried NFS since that's what I'd used in the past and had issues with it - as I remember that was with a Dune rather than the Zidoo, but SMB has worked perfectly for me since.
I thought I replied to this, sorry to have left you hanging. I frequently work in Pro audio and PMC are extremely well known there. Great kit. For what it is worth, the HDR missed detection has returned after a few days use. Not power cycled yet, but it is super annoying me now. Box has almost earned a return trip to Amazon...
This is where an HDFury Vertex becomes the handiest tool in the box because you can see exactly what any box is spitting out with regard to HDR SEI, resolution, framerate, colour space and bit depth - so in an instance like this it points exactly to what device is at fault. What HDR mode do you have the Zidoo set to?
I have the same problem of HDR not triggered with a handful of mkv file, I wish there is a manual selection either on Zidoo or my projector (xgimi lune 4k) for selecting HDR / SDR chroma.
Check those handful of MKV files with MediaInfo to see if the HDR metadata (HDR SEI message) is actually there and correct. All the Zidoo does is pass through the SEI message (assuming you have HDR <auto> set*) - the video itself is either mastered at HDR levels (luminance and colour space) or not - it's not a case of the source "triggering" HDR, the video simply is mastered "in" HDR. Whether the display applies the correct gamma (luminance) and colour space to decode this correctly depends on the presence and values in the SEI message. From what you describe, I'd expect the MKVs that don't trigger the display in HDR mode either do not have this data, or it's in a format that the projector can't understand. * Note that if SDR mapping HDR is set, the SEI message is usually (but bizarrely not always!) overridden with DML max/min of 0,4000 and MaxCLL and MaxFALL of 0,0. This should still trigger HDR in the display device however since although the SEI message is mostly zeros, it's still there and as such the display should interpret this as HDR.
Thanks Markswift... Unfortunately I have no idea what the correct HDR metadata is supposed to look like...please take a look at the following and give some guidance (these three files are supposed to be HDR but look pale and washed out when played back) many thanks: file 1: Format : HEVC Format/Info : High Efficiency Video Coding Format profile : Main 10@L5@Main HDR format : SMPTE ST 2086, HDR10 compatible Writing library : x265 1.9+3-548a45bbf223:[Windows][ICC 1600][64 bit] 10bit Encoding settings : wpp / ctu=32 / min-cu-size=16 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=0 / subme=0 / merange=57 / no-rect / no-amp / max-merge=2 / temporal-mvp / early-skip / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / fast-intra / no-open-gop / no-temporal-layers / interlace=0 / keyint=250 / min-keyint=23 / scenecut=0 / rc-lookahead=5 / lookahead-slices=6 / bframes=3 / bframe-bias=0 / b-adapt=0 / ref=1 / limit-refs=0 / no-limit-modes / no-weightp / no-weightb / aq-mode=1 / qg-size=32 / aq-strength=0.00 / cbqpoffs=0 / crqpoffs=0 / rd=2 / psy-rd=2.00 / rdoq-level=0 / psy-rdoq=0.00 / no-rd-refine / no-signhide / deblock / no-sao / no-sao-non-deblock / b-pyramid / cutree / no-intra-refresh / rc=abr / bitrate=22500 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30 Default : Yes Forced : No Color range : Limited Color primaries : BT.2020 Transfer characteristics : PQ Matrix coefficients : BT.2020 non-constant Mastering display color primaries : BT.2020 Mastering display luminance : min: 0.0001 cd/m2, max: 10000 cd/m2 Maximum Content Light Level : 10000 cd/m2 Maximum Frame-Average Light Level : 180 cd/m2 File 2: Format/Info : Advanced Video Codec Format profile : High@L4.1 Format settings : CABAC / 4 Ref Frames Format settings, CABAC : Yes Format settings, Reference frames : 4 frames Codec ID : V_MPEG4/ISO/AVC Duration : 2 h 4 min Bit rate : 7 789 kb/s Width : 3 840 pixels Height : 1 600 pixels Display aspect ratio : 2.40:1 Frame rate mode : Constant Frame rate : 23.976 (24000/1001) FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.053 Stream size : 6.78 GiB (61%) Writing library : x264 core 148 r2744 b97ae06 Encoding settings : cabac=1 / ref=1 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=19 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=4 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=7789 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=62500 / vbv_bufsize=78125 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00 Default : Yes Forced : No File 3: Format : Matroska Format version : Version 2 File size : 11.9 GiB Duration : 2 h 13 min Overall bit rate mode : Variable Overall bit rate : 12.8 Mb/s Encoded date : UTC 2017-11-17 19:31:28 Writing application : mkvmerge v17.0.0 ('Be Ur Friend') 64-bit Writing library : libebml v1.3.5 + libmatroska v1.4.8 Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4.1 Format settings : CABAC / 4 Ref Frames Format settings, CABAC : Yes Format settings, Reference frames : 4 frames Codec ID : V_MPEG4/ISO/AVC Duration : 2 h 13 min Bit rate : 7 796 kb/s Width : 3 840 pixels Height : 1 608 pixels Display aspect ratio : 2.40:1 Frame rate mode : Constant Frame rate : 23.976 (24000/1001) FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.053 Stream size : 7.26 GiB (61%) Writing library : x264 core 152 r2851 ba24899 Encoding settings : cabac=1 / ref=1 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=4 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=7796 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=62500 / vbv_bufsize=78125 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00 Default : Yes Forced : No
Ok, so firstly what you're looking for is what's shown in the last 7 lines of file 1: Color primaries : BT.2020 Transfer characteristics : PQ Matrix coefficients : BT.2020 non-constant Mastering display color primaries : BT.2020 Mastering display luminance : min: 0.0001 cd/m2, max: 10000 cd/m2 Maximum Content Light Level : 10000 cd/m2 Maximum Frame-Average Light Level : 180 cd/m2 So in fairness, I'd expect that file to trigger HDR in the projector based on that info. However, I think it's possible that that info is just encoded in the file header rather than an SEI message (which is more fundamentally entrenched in the video stream), so that could be the issue. Files 2 & 3 are a bit different... They don't have the HDR info but more importantly, are encoded in 8-bit AVC (advanced video codec). The codec isn't the issue, but it is telling as to what has happened. This means they can't be wide colour gamut HDR files since that requires 10-bits per pixel. Basically it looks like someone has encoded a 10-bit HEVC HDR file into an 8-bit AVC file which just results in a dull video file that won't be decoded correctly by the display, hence the issue you see. If you can post file 1 somewhere (dropbox?) and message me a link, I can take a look at it and tell exactly what the problem is.
