Posts by Stereodude

    Yep - though I guess you're then in a world of Rec 601 vs Rec 709 vs Rec 2020 YCrCb conversions (as they are all different) if you play back a Rec 601 DVD and output it in Rec 709? (And that's ignoring gamut conversions - which you kind of can with 601/709 tolerably, but you can't with 709 vs 2020)


    Arguably taking stuff back to RGB rather than doing YCrCb.601 - > YCrCb.709 conversion in the YCrCb domain is a six and two threes?

    My understanding is that for HDR content there are flags in the HDMI stream to indicate the color space. I think that takes care of 709 and 2020 for folks with a HDR capable display. The source doesn't have to do any conversions, just enable the right flags in the output. I'm not sure how 601 is handled.


    There's going to need to be a lot of LE work done if people are expecting the RPi 4 to play pretty much everything and get reasonably correct results on all display types. That will require handling just about about every possible color space conversion, HDR to SDR tone mapping, and who knows what else.

    The Pi Devs have said 4:2:2 support is there - but it looked like they suggested the vertical subsampling for 4:2:0 meant that wasn't an option. If that is the case, then that means 4:2:2 12-bit will be the only HDR HDMI 2.0 output mode for 2160p50-60 supported I guess (as there is no 10-bit 4:2:2 defined for HDMI 2.0 - so 10-bit HDR HEVC content is output at 4:2:2 12-bit not 10-bit)


    For 2160p24-30 content you can run RGB or 444 and output HDR, without needing 4:2:2 (though 4:2:2 12-bit is valid at these frame rate resolution / combos as well, whilst there is no 4:2:0 support in HDMI 2.0 at <50p). For the bulk of HDR HEVC PQ content - which is 2160p23.976 movies an tv drama - RGB or 4:4:4 YCrCb output in 10-bit is a supported HDMI 2.0 mode and is fine.


    I guess if you render Kodi to YUV-space you'll need to have both Rec 709 and Rec 2020 RGB->YCrCb conversion implemented, unless you mind GUI rendered stuff being a bit out (are photos gui-rendered)

    Well, if the YUV 4:2:2 support on the Pi works anything like a PC everything will be done in RGB colorspace and then be converted to YCrCb right before it's output with a conversion of nebulous quality / correctness.


    Most BD & UHD-BD players output in YCrCb color space and play back YUV video content from files without a conversion to RGB and then back to YUV. It would be nice if the RPi 4 could do the same. Unfortunately the BD & UHD-BD players have all sorts of limitations on codecs and containers.

    If it doesn't support YUV4:2:x it won't be able to do 10-bit 2160p60. If it can only do 8-bit RGB 2160p60 HDR playback is going to be gimped.


    However, I don't know if the Videocore VI is capable of decoding YUV video, leaving it in YUV color space, and rending the Kodi GUI/OSD either directly into YUV color space or rendering it to RGB and converting it to YUV for blending and output so that the video can be passed unmolested without two color space conversions.

    Somehow I expected exactly this behavior.

    I never wrote a single word to you before and just tried to explain the situation to you above.

    You again decided being arrogant and insulting me.

    Look, I want to personally thank you for coming here and posting. Now no one will have to take my word for it that the CE developers are thin-skinned and unprofessional. I'm a little disappointed though. You swooped in and stole my glory by perfectly illustrating and demonstrating it.


    I will PM you some links to threads on a few other forums where I'd love for you to come and make similar demonstrations to backup my posts.

    Sorry the facts hurt you so badly that you had to venture over here, create an account, and try to spin the situation. Clearly I've struck a nerve. Thanks for providing a link so others can see a heavily edited thread showing how the CE developers treat users. Too bad they can't see all the innocuous posts that were deleted.


    At the end of the day the LE devs found the problem without telling me the C2 was crappy hardware. No one insisted the problem would be solved with NFS and that a Windows user should try to implement it.


    Oh, and lets not tell just half the story. Here's the thread on this forum showing on the LE devs handled the same basic report. The difference in how the the two projects responded will be very stark to any reader who reads both.


    It unfortunate that the CE team will benefit from the work of the LE team by inheriting the fix in the upstream Kodi codebase. Of course I wouldn't put it past you all to intentionally exclude it to spite me either.

    Frankly I don't believe you. Just more mud slinging. I have already satisfied myself that one of your complaints is false.
    I like LE and use the current Leia release on my RaspPi without issues, but this constant bad mouthing of CE from certain member of the LE team is just a bit pathetic.


    Shoog

    Well, I'm just a user, but the CE team is a perfect example of what's wrong with some open source communities. They don't take user reports of bugs seriously and are rude and unhelpful. When I reported a bug in CE on the Odroid C2 with network performance when they weren't deleting my forum posts they blamed the network protocol (SMB) and told me I was expecting too much of my hardware. I identified the same issue in LE. In contrast the LE team took my complaint seriously, identified the issue, and made test builds within hours that addressed the issue. I guess the issue wasn't my expectations after all...


    So you can cheerlead the CE all you want, but some of us know better.

    I tested today - CE 8.95.7

    Tested some UHD samples

    ok_Sony_4K_HDR_Camp, Sony Mont Blanc HDR UHD 4K Demo, Sony Swordsmith HDR UHD 4K Demo

    all with buffering issues running CE/KODI18 using wired Gb network

    Files playing without buffering issues running LE/KODI17.6

    Don't worry, head on over to their forum, make a post informing them of it, and they'll tell you that you're expecting too much from your hardware, and that you need to run NFS on your file server.

    I added a 2nd patch and updated the test builds here Index of /testing/825-smb-chunk-32k/


    So 32k version has now 2 patches.

    This one has dramatically improved the network speed. 8) Smooth .ISO Blu-ray playback is no issue now on both the Chromebox and the C2.


    The Chromebox gets to the simple menu in 2 seconds now after selecting the .ISO. The C2 takes 3 seconds. Huge improvement! ^^


    Thanks for not blowing me off and telling me it's just how SMB is and to use NFS instead. :thumbup:

    I build a 8.2.5 test version with a patch that wrxtasy suggested.


    You find it here Index of /testing/825-smb-chunk-64k/


    I started another build for Odroid C2 with the same patch, but when that is finished i am in bed, so that needs to wait until tomorrow morning.

    Thanks for the test build.


    I tried this on my Chromebox and it behaves the same as the official 8.2.5. Time to the simple menu after clicking on the .ISO is still 25 seconds and it can't play the Blu-ray smoothly.


    Edit: Here's a debug log with the video and SMB component enabled: http://ix.io/1kud


    I skimmed it. It seems to show the symptoms, but I didn't see a smoking gun.

    LibreELEC 8.2.5 seems to have some sort of issue playing back Blu-ray .ISO files over SMB shares. Neither my HP Chromebox or Odroid C2 can play them smoothly running it (bone stock LE 8.2.5 install). On both the time from clicking on the .ISO in the file menu until the simple menu is displayed is 25-28 seconds. After selecting the title to play the throbber thingy comes up in the middle of the screen, slowly counts up to 100 and then playback starts. However, within about 40 seconds playback starts stuttering with dropped frames / gaps in the audio / stutters & pauses in the video.


    In contrast the Raspberry Pi3 running LE 8.2.5 can play back the .ISO file fine. On it the simple menu pops up in about 14 seconds after clicking the .ISO. The Odroid C2 running wrxtasy's 32-bit 8.2.4.2 build of LE also can play them smoothly. With that HW/SW combo the simple menu pops up in 5 seconds after clicking the .ISO.


    The same .ISO will play fine on all of these from a USB flash drive. The simple menu pops up instantly and playback is smooth from USB. The server is a Windows 10 Pro box with a 10Gb SFP+ connection to the switch and 1GbE from the switch to the boxes (except the Pi which only negotiates 100Mbit). I can get >100MB/sec copying the ISO file from the server to other PCs. Likewise I can copy data over the default SMB shares to the Chromebox and the C2 at >100MB/sec.


    Forcing SMB 2 or SMB 3 from the LE menu didn't change the behavior with the C2. I didn't try that on the Chromebox.


    wrxtasy suggested there is an underlying problem that's affecting multiple LE Kodi platforms and to start a thread here. I can provide logs files for troubleshooting if someone tells me what to log/do and which of the log files are desired.

    To close the loop should anyone stumble across this thread in the future... This is a CPU limitation, not a disk I/O limitation. I recently received an Odroid C2 and it is only slightly faster than the RPi 3 in navigating the music library. eMMC vs. uSD makes no difference in the C2 in this regard. The Odroid C2 is only about as much faster as you'd expect for a 1.5gHz CPU vs. 1.2gHz. The Chromebox is slightly more twice as fast as the Odroid C2 (takes a little less than half the time for the artist or album list to appear).

    RPi hardware is a little fantastic miracle from a price/performance perspective and its ability to "hardware decode" 1080p video etc. but this is all about CPU and I/O from accessing the DB file. Your Chromebox has ~20x the CPU grunt of the RPi3 and probably uses higher spec/speed flash for the internal storage which is why it has no visible I/O issues. 50k FLAC files tells me you're really into your audio and quality.. so it's time to do the collection justice and get a second Chromebox (or similar).

    Yes, but the Chromebox has a fan. Is it the "disk" (SD card) I/O subsystem that's the bottleneck or the CPU? An Odroid C2 with eMMC solves the disk I/O subsystem side of the equation, but doesn't have that much more CPU grunt than an RPi3.


    For music, I don't use tv screen to browse on my Pi.

    I use yatse on an android tablet, much smoother and efficient.

    I use Yatse also. It is definitely much, much more responsive. It's pretty rare that I try to navigate the music library via a keyboard or remote, but I'd like to speed it up if possible for those times. However, an Android Tablet or phone has a similar CPU to the RPi3 yet is also much more responsive with the same music library database to parse...

    I'm running LE 8.1.1 on a Raspberry Pi 3 using a 64gB Samsung Evo+ U3. I have the SD interface overclocked to 83.333MHz.


    I have >50k FLAC files in my music library. I don't have any other libraries on it. The UI is fairly responsive until I start navigating my way into the music section. Then it's sluggish with waiting. Like when I pick artists I get the circular throbber as it's doing something for a few seconds before I get the list. Going up one menu level and back into artists results in a similar delay.


    LE on my Chromebox doesn't have anything like these pauses with the exact same music library.


    Is there anything that can be done to minimize these pauses like increasing disk caching or tweaking some parameters?