Community Packages

Please read this before reporting a bug:
http://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#56065 - [kodi][gst-libav] Recent update of ffmpeg breaks video playback

Attached to Project: Community Packages
Opened by John (graysky) - Saturday, 21 October 2017, 12:15 GMT
Last edited by Ike Devolder (BlackEagle) - Sunday, 24 December 2017, 11:23 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Ike Devolder (BlackEagle)
Jan Steffens (heftig)
Maxime Gauduin (Alucryd)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 26
Private No

Details

Updating to ffmpeg-1:3.4-1 causes video playback from within kodi to freeze. Downgrading to ffmpeg-1:3.3.4-1 fixes the problem.

https://bbs.archlinux.org/viewtopic.php?id=231120

Affected versions:
ffmpeg-1:3.4-1
kodi-17.4-6
This task depends upon

Closed by  Ike Devolder (BlackEagle)
Sunday, 24 December 2017, 11:23 GMT
Reason for closing:  Implemented
Comment by Felix (darkthorn) - Saturday, 21 October 2017, 14:25 GMT
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
Comment by Klerik (klerik) - Saturday, 21 October 2017, 19:14 GMT
Same here - ffmpeg-1:3.3.4-1 fixes the problem.
Comment by Eli Schwartz (eschwartz) - Sunday, 22 October 2017, 00:20 GMT
  • Field changed: Attached to Project (Arch Linux → Community Packages)
  • Field changed: Summary ([ffmpeg] [kodi] Recent update of ffmpeg breaks video playback in kodi → [kodi] Recent update of ffmpeg breaks video playback)
Please do not report bugs against community packages to the "Packages: Extra" category, this is not a bug in ffmpeg itself...
Comment by Eli Schwartz (eschwartz) - Sunday, 22 October 2017, 00:24 GMT
  • Field changed: Status (Unconfirmed → Assigned)
  • Field changed: Category (Packages: Extra → Packages)
  • Field changed: Architecture (All → All)
  • Task assigned to Ike Devolder (BlackEagle)
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?
Comment by John (graysky) - Sunday, 22 October 2017, 01:01 GMT
@Ide - I did rebuild it against 1.3.4 but there isn't a change in the behavior.
Comment by Neal (meltdown) - Sunday, 22 October 2017, 03:01 GMT
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.
Comment by Levente Polyak (anthraxx) - Sunday, 22 October 2017, 10:30 GMT
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?
Comment by John (graysky) - Sunday, 22 October 2017, 11:34 GMT
@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
Comment by Levente Polyak (anthraxx) - Sunday, 22 October 2017, 12:17 GMT
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?
Comment by John (graysky) - Sunday, 22 October 2017, 13:33 GMT
@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.
Comment by Eli Schwartz (eschwartz) - Sunday, 22 October 2017, 14:21 GMT
@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.
Comment by John (graysky) - Sunday, 22 October 2017, 14:34 GMT
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
Comment by Levente Polyak (anthraxx) - Sunday, 22 October 2017, 14:34 GMT
@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.
Comment by Giacomo (clodio) - Sunday, 22 October 2017, 19:09 GMT
This bug also affects totem, downgrade to ffmpeg-1:3.3.4-1 fix the problem.
Comment by crackleware (aeyiera) - Sunday, 22 October 2017, 22:29 GMT
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.
Comment by Cedric Bellegarde (gnumdk) - Monday, 23 October 2017, 10:58 GMT Comment by Stanislav T (stas-t) - Monday, 23 October 2017, 11:02 GMT
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 :)
Comment by Stanislav T (stas-t) - Monday, 23 October 2017, 11:29 GMT
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).
Comment by Cedric Bellegarde (gnumdk) - Monday, 23 October 2017, 12:46 GMT
Fixed for webkit2gtk too.
Comment by Eli Schwartz (eschwartz) - Monday, 23 October 2017, 14:39 GMT
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.
Comment by Stanislav T (stas-t) - Monday, 23 October 2017, 14:48 GMT
Is it maybe a good idea to rebuild kodi with bundled ffmpeg 3.1 as well?
Comment by Levente Polyak (anthraxx) - Monday, 23 October 2017, 16:08 GMT
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.
Comment by Eli Schwartz (eschwartz) - Monday, 23 October 2017, 16:44 GMT
@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.
Comment by Stanislav T (stas-t) - Monday, 23 October 2017, 17:20 GMT
@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.
Comment by John (graysky) - Tuesday, 24 October 2017, 18:40 GMT
@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
Comment by Eli Schwartz (eschwartz) - Tuesday, 24 October 2017, 18:58 GMT
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.
Comment by Jan Steffens (heftig) - Tuesday, 24 October 2017, 20:21 GMT Comment by Ike Devolder (BlackEagle) - Wednesday, 25 October 2017, 16:55 GMT
kodi will be moved back to the ffmpeg version supported by kodi

Loading...