Sorry, I forgot to look in my crystal ball to check type of your box.
You never asked and if i knew you were going to build something for me to test i would have said
[8.90.6] Audio out of sync from livetv
-
dazed -
March 27, 2018 at 1:18 PM -
Thread is Unresolved
-
Same problem here on Alfawise H96 Pro+ with 8.90.6. Audio out of sync and frame drops. I'm using vdr and vnsi.
-
When I enable HW decoding for h264 I experience frame drops (lots of them). Not so much with SW decoding or I haven't noticed.
-
Audio still out of sync and i swear there's a lot of skipped frames kodi4.log - Google Drive
I relaxed continuity check to avoid wrongly detected stream out of sync.
LibreELEC-S912.arm-9.0-devel-1522315907.tar
Same problem here on Alfawise H96 Pro+ with 8.90.6. Audio out of sync and frame drops. I'm using vdr and vnsi.
Try to test my devel version. I ported from kszaq kernel some tweaks to optimized video decoding.
For S905 boxes you can use:
-
I relaxed continuity check to avoid wrongly detected stream out of sync.
LibreELEC-S912.arm-9.0-devel-1522315907.tar
Try to test my devel version. I ported from kszaq kernel some tweaks to optimized video decoding.
For S905 boxes you can use:
Are these a continuation of the development of adamg?
-
This is GDPR-2 LE 8.90.6 devel version.
-
I relaxed continuity check to avoid wrongly detected stream out of sync.
LibreELEC-S912.arm-9.0-devel-1522315907.tar
This made it worse than the previous test build. Now when i start a channel the video is frozen for a few seconds while the audio continues to play. Then it just stutters trying to get back in sync
-
Have same problem but solved it disabling hw acceleration. Most of my streams are in hd 720 so no much of a problem but when playing streams from my connected vu+ in 1080 or 4k i have to enable HW acceleration again. Thought it was a problem just with my streams because run through VPN.
-
This made it worse than the previous test build. Now when i start a channel the video is frozen for a few seconds while the audio continues to play. Then it just stutters trying to get back in sync
Another fix in pts calculations:
-
Another fix in pts calculations:
I updated my existing 8.90.6 (adamg's dev) version, which has several a/v issues still (see adamg's release thread for details).
First results for this build of yours are positive: The (very annoying) sound stuttering seem to be resolved!
Video still stalls for some time at the start of some HD and SD streams, but no more sound stuttering...
Thank you afl1 for your efforts. Much appreciated!
Regards,
Atreyu
-
Another fix in pts calculations:
LibreELEC-S912.arm-9.0-devel-1522444424.tar
No video freeze this time but lots of skipped frames and audio drifts in and out of sync
EDIT: Just noticed if i don't have Fallback framerate set to 50hz in the PVR playback settings it doesn't auto switch resolution to 50hz itself. Here's a log from that fallback-framerate-off.log - Google Drive lots of frame skips and video stuutters almost constantly
-
dazed i also have to enable a fallback framerate for it to be set, i believe framerate is not detected or passed from the backend in my case (if i dont set fallback to 50hz framerate is detected as 0000). Same might be going on with your setup
-
if i dont set fallback to 50hz framerate is detected as 0000
Yeah PlayerDebug shows it as 1920x1080@0000
-
This is why i believe FR detection should be solved from the backend.
I might bother dvblogic with this later on,for now i'll go with the fallback setting..
-
This is why i believe this should be solved from the backend.
I don't think it is, i remember something similar to this happening with a previous build from kszaq this is why i have the fallback set to 50hz
-
Thats not surprising, its all based on the same. Still think fps is not passed from backend, but we will see when i get to that (minor for now)
-
Pls, stop this discussion. Fps is not a issue. Stream has continuity issues, and it uses minus values for pts/dts. I have to fix internal calculation as the decoder uses only 31bit values for pts/dts. There is used pts_overflow for converting real pts/dts to internal pts/dts. I still see in debug log incorrect calculation.
