Posts by ArchNMy

    KlausiMaus this effect is called color banding. What I can also see is dithering (which is a counter mechanisms against color banding).


    This might be a problem of the TV or the source material, so it would be the best to check with a laptop or something if it is present there too.

    Hello,


    I didn't expect these builds to be prime time and nobody said they are. This is true, however they run really smooth and most things are working actually at least somehow. So kudos for these builds, looks really promising.


    Setup:

    • Odroid C2
    • currently C2-build from May 26th for arm (kernel: 5.1.0)
    • copied .kodi and .config from 3.14-stable build (however I also tested most things without this, IR being the exception)
    • from SD card

    Observations:

    • no hdmi output when cold booted; turning the TV off and on fixes this problem
    • HDMI audio works
    • CEC often doesn't work (currently doesn't at all)
    • IR produces double presses or often also queued (second) presses, meaning they are executed once a new button is pressed leading to unexpected behavior :D
    • aspect ratio for 720x576(16:9) PVR content is wrong (pixel ratio wrong)
    • software decoding for MPEG-2 and Xvid doesn't work (AVC does)

    Kwiboo and mike2002: Thank you for clarification. Indeed changing resolution to 720p makes the playback of SD Xvid content smooth. I will test mainline build later on, just to see if it is there too or not.


    Also because of that explanation I tested SW decoding H264 SD content and indeed this stutters as well, so the scaling is the problem.


    I was really not aware that scaling is so computationally intensive. Also weird that changing to lower refresh rate really doesn't improve matters.

    It would even help if someone can replicate this observation on RK3328. Meaning: jittery playback on Xvid/DivX content and smooth playback on H264/AVC+H265/HEVC content


    It would also help if someone has smooth playback with Xvid/DivX content on RK3328 (Rock64 preferred of course :)).

    The log doesn't tell me much. I only found this:

    Code
    DEBUG: ActiveAE::SyncStream - average error of 16.908025, start adjusting
    DEBUG: ActiveAE::SyncStream - average error 0.908025 below threshold of 30.000000
    NOTICE: CDVDVideoCodecFFmpeg::CDropControl: calculated diff time: 40000
    DEBUG: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:-33362.743167, adjusted:-33362.743167

    However this also occurs in the smooth h264 playback test run.


    Regarding the logs, I removed video location and title from the log (with place holders) and removed spam from plugin.video.youtube and service.upnext as well as jsonrpc (from Kore app).

    Okay, I tested 720p H264 software decoding and it plays flawlessly while peaking at around 150% (while usually being around 110%). I think that should rule out a CPU bottleneck.


    Will traverse the logs if I see anything suspicious while playing back DivX/Xvid content.

    Kwiboo: I suspected that it is software decoded, however the cpu usage doesn't exceed 70% (of 400%) so not even a single thread is completely used.


    The stutter is also continuous with no apparent spikes which leads me to think it has nothing to do with CPU performance limits. Also the stutter becomes way worse when setting the display refresh rate lower (for example 24Hz/25Hz which are the source frame rates for these cases).


    Deinterlacing turned off doesn't change the observed behavior.


    Do you have a Rock64 and if so do you see the same behavior on MPEG4/Xvid/DivX content?


    Edit: The jitter/framedrops/continuous stutter is also visible in the Kodi UI

    flyingernst: The stutter is more of a consistent frame drop or jitter. On 25Hz it looks like I'm watching slow motion while not really being slower. Also H264 and H265 as well as MPEG2 content plays fine for me regardless of bitrate or resolution.


    LE is installed on eMMC and loads content from SMB, so it doesn't seem to be the same issue.

    That explains at least something, but now we need to find out why the Video FFU and the IOMMU crash. Are there any devices attached to the Rock64? What PSU are you using?


    PS.: That download of 4K HEVC Big Buck Bunny takes forever ...

    eMMC should be fine as well as any memory amount that is available for Rock64 (1GB would be sufficient too). It would be worth a try playing a file from an HDD, but I doubt that eMMC is at fault here, if it is not broken.


    Are there any errors/warnings in dmesg?


    I am currently on a Rock64/2GB and everything except DivX/MPEG-4 content plays fine. I never tried 4K content tho.

    Hello,


    I didn't find a thread about this problem, so I open one.


    Setup:

    • Rock64
    • LE nightly 20190506 for Rock64 (also tested on 8.90.014)
    • LE installed on eMMC


    Observation:

    • MPEG-4 (Layer 2) videos stutter
    • stutter is continuous throughout playback and multiple times per second (is it called jitter then?)
    • MPEG2/H264/H265 content plays flawlessly
    • resolution doesn't matter
    • whole kodi UI is sluggish with DivX content playing in the background (not otherwise)
    • video is a bit behind audio

    Tested:

    • CPU is around 50% (from 400% possible) for the usual SD content
    • PRIME on/off doesn't matter (probably not accelerated anyway)
    • deinterlacing on/off doesn't matter (material isn't interlaced anyway)
    • changed framerates (also to match source framerate) and the slower it gets the worse the stutter is even if it matches the source framerate

    Kind regards,

    ArchNMy