2023-11-21, 21:54
I re-encode my video files using ffmpeg to transcode to hevc before putting them into my kodi library. This has never been an issue before but I went to play an item on nvidia shield running kodi and the video basically kept seeking and the sound would come in and out. Checking the file by playing it on a local computer with vlc I had no issues and playing the file through my plex server I had no issues, it only ran into issues when direct playing in kodi. After some trouble shooting I was able to pinpoint the issue happened when using ffmpeg 5.1.4. I can run down how I was able to identify that was the issue if needed but can confirm that same command with same hardware and videocard drivers with hwaccel on the transcoding generates a file that works properly on kodi when run with ffmpeg 5.1.3 but when its run using 5.1.4 kodi has an issue playing the file. In an additional test I was able to generate the file that kodi doesnt play properly and then simply use ffmpeg 5.1.3 to copy the streams from that file using ffmpeg -i bad.mkv -c copy good.mkv whose output plays properly properly in kodi.
The issue with these files was first seen on kodi running on an nvidia shield device, but then I was also able to replicate the issue within kodi running on a linux desktop (opensuse tumbleweed, the same system I use to reencode my video files).
Looking at logs during playback it seems like the audio and video are being seen as out of sync and the system is trying to resync them which is the jumping video and audio that I see when trying to play the bad file. This only seems to happen with files generated using ffmpeg 5.1.4. Has anyone else seen this type of behavior.
Example of what I see in the logs when this occurs:
With a bunch of large audio sync errors showing before stream stalled and timout waiting messages and then a bunch of the audio sync error messages again.
The output between a good and bad file where the good was generated in my example command above are essentially the exact same except I dont start receiving the timeout waiting for buffer and large audio sync errors with the good file.
Is this a bug with kodi, is it a bug with ffmpeg, I have rolled my system back to before ffmpeg 5.1.4 was released on my os for the time being but was wondering if other people had experienced this issue and have any idea how to resolve the issue without having to stagnate at an older version of ffmpeg.
The issue with these files was first seen on kodi running on an nvidia shield device, but then I was also able to replicate the issue within kodi running on a linux desktop (opensuse tumbleweed, the same system I use to reencode my video files).
Looking at logs during playback it seems like the audio and video are being seen as out of sync and the system is trying to resync them which is the jumping video and audio that I see when trying to play the bad file. This only seems to happen with files generated using ffmpeg 5.1.4. Has anyone else seen this type of behavior.
Example of what I see in the logs when this occurs:
Code:
2023-11-21 14:38:47.336 T:24235 info <general>: CDVDVideoCodecFFmpeg::CDropControl: calculated diff time: 41727
2023-11-21 14:38:50.419 T:24236 info <general>: CVideoPlayerAudio::Process - stream stalled
2023-11-21 14:38:50.425 T:24235 warning <general>: OutputPicture - timeout waiting for buffer
2023-11-21 14:38:50.516 T:23793 warning <general>: ActiveAE - large audio sync error: -6456.957751
With a bunch of large audio sync errors showing before stream stalled and timout waiting messages and then a bunch of the audio sync error messages again.
The output between a good and bad file where the good was generated in my example command above are essentially the exact same except I dont start receiving the timeout waiting for buffer and large audio sync errors with the good file.
Is this a bug with kodi, is it a bug with ffmpeg, I have rolled my system back to before ffmpeg 5.1.4 was released on my os for the time being but was wondering if other people had experienced this issue and have any idea how to resolve the issue without having to stagnate at an older version of ffmpeg.