Posts by ashlar

    hadesdevls I tested through USB key. One thing I could suggest: make the options clearer when one boots from it.
    I have a dedicated NUC (NUC11TNKI3) for this, so I prepared the key on a different, Windows 10, machine. Once I booted the NUC with usb key inserted, I was trying to understand what the different "Run/Run*/Installer/Live" options meant and it autostarted as Run almost immediately (a few seconds, really). Maybe it was on your github page, I don't know, but I found it alarming.

    The HDR10+ movie that was giving me trouble on CroqueMr build played fine, converted to Dolby Vision. And, generally speaking, everything seemed to work ok. I connect the NUC to a Denon X3800H AVR and that to an LG C1 (I mention this as I saw on your github that you keep track of hardware tested and you mentioned no AVR tested yet). Both Atmos and DTS-X played ok.

    I noticed the GPU was always or almost always sitting at 100% and headroom was most definitely not ample (and this on 24fps movies). Not something I'd be comfortable with if we were talking madVR profiles optimization. It looked like it could easily drop frames on "complicated" scenes.

    Considering my hardware should be a fair bit more powerful than the N100 which works fine for 24p content on CroqueMr, I wonder if I am missing something or if, simply, your builds are more targeted toward more powerful hardware (I come from a past where the last HTPC I used for media purposes had a RTX 4070, but I'd very much like to remain fanless).

    I had this issue once and I never managed to reproduce it. Could you run all your file that not work properly and share the log file please :) for HDR10+ I am on it the pipeline does not work as expected and I do not have my HDR10+ screen to properly fix it.

    I activated verbose logging for components I thought might be relevant. I'm gonna send you a download link by PM, as the log is quite long (verbose logging).

    I tried the same movie on Hades build, it gets converted to Dolby Vision and it does not show the same problem (screen blanking intermittently, once every... whatever it wants, I don't think it's always in the same places). The log runs for a little bit, enough for at least three or four "blanks" to happen. Hopefully you'll notice something in the log.

    ashlar For switching, the easy way is a drive for each build: Hades starts from a USB drive just as it does from an internal disk (the Windows installer writes one), so switching is choosing which drive to boot, and each one keeps its own settings and add-ons.

    Hmmm... ok. Thank you. Not the answer I was hoping for (and it reinforces my initial idea that having two different development paths would have been bad for testing) but let's see if I can work around it. Is there a way for me to have a USB key having the "full install"? Normally you use the Windows tool (but I have access to a Linux machine too) to create the USB key which installs on the internal disk. Is there a way to have the tool write to a different key? Like, I boot from an hades key built with Libre-ELEC USB-SD Creator, while having a second usb key in a different port. Does the installer allow me to select the second key as the install disk?

    A question for both devs, CroqueMr and hadesdevls: I am currently testing on the aforementioned hardware (NUC 11 i3) and the machine is not "in production" (I'm keeping my Ugoos as daily driver until I have a rocks solid alternative in the NUC).

    If I want to switch between your two versions, to check both them out... do I have to start from scratch every time I switch? I hope not as that would require an inordinate amount of wasted time and I have a single machine to test them on.

    Or can I simply place your release in .update and reboot?

    I made a small hotfix in rc1.1 for those who had issues on HDR10+ and DV to HDR10 expert conversion.

    Hi! Since you mention just HDR10+ and DV to HDR10 conversions I think I can safely report even though I'm still running the first RC you released yesterday. EDIT: in the meantime I updated to rc1.1 and nothing changed.

    I am getting a strange effect when invoking either the menu or the stream play info (using O). Basically nothing appears and there's a tiny "miniature thumb" of the portion that should appear, in the bottom left corner. I show it in this picture I took with my phone. This happens when playing a HDR10 UHD Remux. Dolby Vision conversion happens but the menu and play info are shown like that. Also subtitles don't seem to be working (or are being displayed in that miniature thumb in the corner, quite likely). Dolby Vision native content does not exhibit this problem.

    I'm also experiencing something strange with a HDR10+ Remux, this is its MediaInfo video section:

    Format                                   : HEVC
    Format/Info                              : High Efficiency Video Coding
    Format profile                           : Main [email protected]@High
    HDR format                               : SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible
    Codec ID                                 : V_MPEGH/ISO/HEVC
    Duration                                 : 2 h 19 min
    Bit rate                                 : 56.4 Mb/s
    Width                                    : 3 840 pixels
    Height                                   : 2 160 pixels
    Display aspect ratio                     : 16:9
    Frame rate mode                          : Constant
    Frame rate                               : 23.976 (24000/1001) FPS
    Color space                              : YUV
    Chroma subsampling                       : 4:2:0 (Type 2)
    Bit depth                                : 10 bits
    Bits/(Pixel*Frame)                       : 0.284
    Stream size                              : 55.0 GiB (91%)
    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: 1000 cd/m2
    Maximum Content Light Level              : 1000 cd/m2
    Maximum Frame-Average Light Level        : 400 cd/m2

    What I see happening is the picture constantly switching "on and off", intermittently. It doesn't appear to follow a specific time interval, let's say every few seconds. The TV loses the signal and then locks onto it once more, on and off.

    No conversion happens on this file, the TV is receiving a regular HDR10 stream (it's a LG C1, so not HDR10+ compatible). On an Ugoos AM6B+, using p3i T4c build, the movie is detected as HDR10+ and converted to Dolby Vision without problems.

    The system I'm testing this on is a NUC 11 with an i3 processor and 16GB of dual channel RAM.

    An extra, general, question: why is it that the rendering load appears higher on DV Profile 8 than on DV Profile 7 with FEL? Over 80% with Profile 8, around 50% with Profile 7 FEL, as measured by your "O" overlay.

    No not useless, I do not see any good use case, but that doesn't mean that no use case is relevant for that kind of conversion.

    And regarding your quote we were talking about LLDV not SDR to DV

    My bad. In any case, it's your decision. I cannot add anything to it. :)

    LLDV can be useful, of course. SDR to DV... I'm baffled by people wanting it. HDR10+ / HDR10 to DV, I'm in favour (and I believe HDR10 to DV already works and hopefully HDR10+ to DV will come).

    Thank you, I’ll continue testing. I think that although the standards allow both color representation options, for some reason all players output ITP in an RGB 8‑bit tunnel. This may be due to the need or desire to send the same ITP Full range signal to the TV so that the TV perceives it identically. Since both DV P7 with Ycbcr and DV P5 with ITP are presented in the same ITP Full range in the tunnel.

    Any further testing results? Is this good to go? :)

    Couldn't you all join efforts and work collaboratively towards a common goal? hadesdevls

    Having multiple builds to test, on a different development path seems to be a waste of resources. Both from a development point of view and, maybe more importantly, from a testing point of view.

    What do you think?


    I could try to send logs if that helps but all I can see is only a simple DV=0 or DV=1 mention in the log files not sure if that's too helpful

    First of all you have to activate debug logging (sorry, you might be aware of this but you never know). Then devs could then point you to activate different detailed logging options in settings, in order to get more information.

    I think that if Dolby Vision ever makes it into LibreELEC officially, it will probably be through an approach closer to my initial implementation, before R1.0.0 Beta1, with minimal changes to FFmpeg and other upstream dependencies. I believe such an implementation is possible, but it will take time. It might also be useful to maintain a much simpler build with just the bare minimum needed for DV support. Performance won't be as good, but it will help with the implementation.

    All absolutely understandable. For the time being I suppose the question becomes: how likely are you in the future to maintain your builds up to date with changes/new features from upstream? I think everybody understands there's no guarantee and, of course, no obligation. But before committing to a switch from existing working solutions, a reassuring answer on this would go a long way.

    I want to stress, though, that, at least for me, a "not likely as I've got better things to do" would be 100% ok. You've already done a lot.