Posts by jernej

Quote from frakkin64

I presume something else is synchronizing audio/video and that it should check for corrupted frames.

Kodi is responsible for sync and yeah, I think code isn't optimal.

Quote from frakkin64

I assume for SW decoding (which works fine) it is just presenting raw video frames to V4L2 (since it is already decoded).

V4L2 is just for decoding and possibly deinterlacing. Rendering is done using either DRM planes (default) or GPU, but you're right in principle.

Quote from frakkin64

As it stands now, the workaround me is to just drop MPEG2 in the driver capabilities, and it takes about 50% CPU on all cores for a full 1080i video which is not a big deal.

Maybe an option can be added to disable HW decoding for specific codecs on the fly? I think that would be best.

Quote from jordixPI3

please, could you tell me how to?

Change is non-persistent. If you reboot the system, it's already gone.

Quote from frakkin64

Unfortunately it froze.

That's not that surprising. As I said, CEC and Cedrus doesn't have anything in common, except one shared clock.

In any case, I observed freezing problem already in the past on OrangePi 3 (non LTS), but not on the other boards. I went over many things several times, but I couldn't find anything important. Search continues...

Yes.

I found issue with CEC driver - arbitration lost event was not handled. Not sure how big an issue this is, but it surely is.

Here is my branch: https://github.com/jernejsk/LibreELEC.tv/commits/fixes

Note that there is still issue with ffmpeg6 transition: https://github.com/xbmc/xbmc/pull/23709

But that doesn't solve it. Video stream is corrupted. Not sure if it's possible to find a way to normally decode frames. Still, Kodi should deal with corrupted frames better...

Quote from frakkin64

I have never seen such an option with DRMPRIME. I think that is available with VA API? If it's possible would like to hear any tips about how to do that, didn't see anything in Player or System and I am at expert level, it would be a useful feature as Amlogic mainline also has MPEG2 HW decoding problems.

Sorry, I mixed up with other methods.

Quote from frakkin64

one I did to disable MPEG2_DEC capability in cedrus on h6

This one shouldn't be needed. Can't you specifically disable MPEG2 HW accel in settings (maybe expert view is needed)?

Quote from frakkin64

So far, after 22 hours of uptime there has been no freezing

what kind of changes do you have?

Any of you have serial console? I plan to build LE11 update with a lot of kernel debug functionality enabled. However, in order to be useful, it must output issues on serial in real time, so hopefully data is received before lock up.

Quote from jordixPI3

shoud i expect any feedback message after sending it?, do i need to re-enable CEC in settings?

No and no

Quote from frakkin64

[ 42.389083] cec-dw_hdmi: polling for LA 1 failed with tx_status=0x0030

[ 42.392601] cec-dw_hdmi: polling for LA 2 failed with tx_status=0x0030

[ 42.403417] cec-dw_hdmi: polling for LA 9 failed with tx_status=0x0030

Are you testing this on CEC capable device?

When you get frame processing timed out!, system shouldn't freeze/crash. That's why there is iommu, to prevent accessing non-allocated memory and thus corrupting memory. But then again, Cedrus might block one or more memory buses, which freezes the system regardless.

Disabling CEC doesn't solve issue #3 for you?

Is there a playback freeze or system crash? In any case, MPEG2 is easy to decode, so you can disable MPEG2 HW decoding. If you have a sample, I can take a look, but no promises. I found some workarounds for corrupted H264 streams, but not yet for MPEG2.

It's just with this patch: http://ix.io/4FbV I will send it for inclusion in upstream regardless since it makes code aligned with user manual. Regarding CEC, I was never too sure about https://github.com/LibreELEC/Libr…-on-error.patch Can you try to build without it? It gives those CEC warnings in dmesg.

LE11 test update in the same place.

Read https://wiki.libreelec.tv/support/update

Anyway, I'll prepare LE11 image since that ordering is current issue in LE12 development.

Please test update from http://jernej.libreelec.tv/test/h6-cedrus/

Note that this is development version of LE12, so there might be other bugs. If it doesn't work, I can still build LE11 update.

There is just one clock/reset fix, so Cedrus driver actually follow proper order now. It might or might not be the issue experienced here.

Quote from gadget_guy

just to clarify though, does changing that timing register with devmem take effect immediately? Or do i need to disable/re-enable the CEC option or something?

Yes, it directly writes to HW clock register. It switches CEC clock source from periph0(2x) clock to external 32.768 kHz crystal, but sadly not all boards have it. Still, there is no logic why it would help. In any case, I have also other ideas, for which I will make test images.