Arch Linux

This affects parole media player (version 0.9.2-1), too, as it uses ffmpeg via gst-libav.

Running parole with "--gst-debug-level=1" prints the following repeatedly when using ffmpeg-1:3.4-1:

0:00:00.328109161 29520 0x7fabb0006770 ERROR libav :0:: Got unexpected packet size after a partial decode

After some time, parole pops up a dialog saying "The stream is taking too much time to load", offering to continue loading or abort it.

The error does not occur with the previous version of the package, ffmpeg-1:3.3.4-1.

EDIT: clarified package versions + parole error message

Same here - ffmpeg-1:3.3.4-1 fixes the problem.

Please do not report bugs against community packages to the "Packages: Extra" category, this is not a bug in ffmpeg itself...

kodi was never rebuilt against ffmpeg 1.3.4, in theory this shouldn't matter as the soname was not bumped, but possibly kodi does runtime checks the same way mpv does?

@Ide - I did rebuild it against 1.3.4 but there isn't a change in the behavior.

I have this issue on 2 arch boxes. Only fix is to downgrade. If any one needs me to test any fixes/patches, let me know.

I don't see why we should keep ffmpeg fully out of this loop, the change in ffmpeg that lead to this comes in via ffmpeg 3.4.x via https://github.com/FFmpeg/FFmpeg/commit/061a0c14bb5767bca72e3a7227ca400de439ba09
So either kodi needs to change something how the API is used with ffmpeg 3.4.x or its indeed a bug in the reconstruction code when using this compat API.

The symptoms are pretty much the same as https://trac.mplayerhq.hu/ticket/2329 which seems to have "broken" the compat API in terms of 100% backwards compatibility, mplayer
for AC3 decoding in mplayer this was fixed by svn diff -r 37945:37946 svn://svn.mplayerhq.hu/mplayer/trunk@37946

We should figure this out and possibly add a patch to kodi (plus obviously report the problem upstream).
Can you test running mplayer against the file that freezes?

@anthraxx - Using mplayer from myplayer-37916-2 or ffplay from ffmpeg-1:3.4, the playback is as-expected. The playback problems I see are only with kodi.

@ike - One on the kodi developers see no problems with ffmpeg 3.4 on his test machine. His hypothesis is that the problem is with our stuff. See: https://forum.kodi.tv/showthread.php?tid=322777

well without him running kodi 17 there is no guarantee that there is nothing with kodi 17. Can you compile a kodi from git with our settings and try again?

@anthraxx - Right you are... poor comparison. When I run kodi from git (18.0-ALPHA1 Git:20171021-d68e7e31b1) it plays the video without error (same result as fritsch got on his ubuntu machine). Therefore, we can conclude that kodi-17.4-6 and ffmpeg-1:3.4 is the problem.

@anthraxx re: IRC,

It seems to me that if ffmpeg works elsewhere, and kodi cannot use it probably because of a changed API, then the ffmpeg installation itself is not fundamentally buggy... and also as a bug for [extra] packages it cannot be assigned to maintainers of [community].
Which is not to say ffmpeg is being completely ruled out, and if other ffmpeg consumers have the same issue then of course we can assign those packages too.

Also ffmpeg did not change the major soname, but why should they do such bloat anyway...

...

Anyway good point that the ffmpeg maintainer might have useful insight into this regardless of whose bug it is.

As pointed out by wsnipex in the forum thread I referenced a few comments able, only ffmpeg 3.1 is supported for Krypton: https://github.com/xbmc/xbmc/commit/5ba6eb7cadc41d5eb86ef94e3661b833b62953ff

@graysky: ok that pretty much confirms what i though, it got fixed inbetween kodi 17.4 and 18, so its still an issue with latest kodi release which IMO kodi devs should figure out and backport. The linked commits shows frame buffer size related checks that are added. mplayer fixup commit shows similar thing for audio happening, while fixing by adding a check and "ignore" it.
So it should be figured out what kodi 18 does differently. Just because latest kodi HEAD works, should not mean that the kodi devs shouldn't care at all about their latest stable released versions. again: IMO they should find out what fixes this behavior on their side.

This bug also affects totem, downgrade to ffmpeg-1:3.3.4-1 fix the problem.

i had an issue with avdec_h264 element used from gst-launch-1.0 invocation. @darkthorn already noticed this. gst-libav is 1.12.3-1. downgrading ffmpeg to 1:3.3.4-1 fixed it.

https://bugzilla.gnome.org/show_bug.cgi?id=789193

After downgrading ffmpeg to 1:3.3.4-1 both totem and kodi started working for me, but mpv is failing which is expected according to @eschwartz.

For kodi there is a solution used in archlinuxarm where kodi is bundled with the proper ffmpeg version:
https://archlinuxarm.org/packages/aarch64/kodi-c2/files/PKGBUILD

However this doesn't solve the problem for other ffmpeg based players. OTOH I assume that sticking to the older ffmpeg version is against normal Arch Linux policy which makes the problem even tougher.

EDIT: Might be a lesser problem depending on how fast dependants are upgraded :)

Can confirm that upgrading gst-libav to version 1.12.3+1+ge87c20d-1 fixed the problem with Totem playback with ffmpeg 1:3.4-1. Tested for AVI (mpeg4/ac3) and MP4 (h264/aac).

Fixed for webkit2gtk too.

gst-libav has temporarily disabled the system libav: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/gst-libav&id=8a8edd02aa6cbfe9e11227b3884c8f80dcc300a4

So any video players using ffmpeg via gstreamer will now work, hopefully the gnome bug will be resolved soon and we can go back to the system ffmpeg.

Is it maybe a good idea to rebuild kodi with bundled ffmpeg 3.1 as well?

yeah until we figure a patch for this API behavior change, or we get kodi 18, that seems to be the reasonable thing to do.

@stas-t

I don't see the need, kodi master officially supports ffmpeg 3.4 as of https://github.com/xbmc/xbmc/commit/4f3875f4492ebaacf12b83a006cef71a3fcaa1b4 so it would be better to figure out which changes to backport, whereas gst-libav does not have any fixes available -- see the linked bugreport.

Note that archlinuxarm is still using a PKGBUILD based on our package, from before we moved *away* from a bundled ffmpeg in  FS#55675  and you cannot really bring that as a comparison.

@eschwartz: sorry, I didn't check  FS#55675  before.

But the reasons why I mentioned bundled ffmpeg are:
* what @graysky pointed to: https://github.com/xbmc/xbmc/commit/5ba6eb7cadc41d5eb86ef94e3661b833b62953ff
* kodi 18 is not officially stable and switching to it completely may bring other sorts of issues

EDIT: corrected last sentence about kodi 18. Backporting the fix is reasonable of course.

@all - I'm still not clear on the driving force to switch the to system ffmpeg ( FS#55675 ). If it was to allow offline builds, it doesn't achieve that goal due to other packages getting downloaded at compile (crossguid, dvdcss, dvdread, and dvdnav). The switch to external ffmpeg also pulls down additional MBs of ffmpeg deps that the internal build did not need. I updated the referenced FS.

As to a path forward with this specific breakage, the kodi forum post I referenced contains some thoughts of one of their developers regarding a backport, which is pretty blunt. My vote would be to return to the internal ffmpeg as a fix.

@eschwartz - Yes, Arch ARM offers several different kodi builds, they are a bit different from each other. I have done my best to keep kodi-rbp[1] in parity with our PKGBUILD.

1. https://github.com/archlinuxarm/PKGBUILDs/blob/master/alarm/kodi-rbp/PKGBUILD

The driving force was "system libs are nice". If system libs break API and we cannot figure out how to fix that, bundled libs can be tolerated (but should be downloaded in the source array). I guess that ticket was just not fully handled. ;)

And yes, we get that upstreams which recommend vendoring everything are uninterested in looking at backporting things they don't want to support to begin with.

https://trac.ffmpeg.org/ticket/6775

kodi will be moved back to the ffmpeg version supported by kodi