FWIW, gst-libav (git master) seems to work fine with ffmpeg 2.7.1 (last release). (after fixing up the build system a bit and ignoring a new format id that causes problems)

If it's API compatible, I have no objections for one of the other. The split has forced both teams to improve downstream-listening and general API stability (unlike before the split). The situation is much better than years ago.

=> OK for me

++ from me too, ffmpeg seems to be the better maintained branch these days. It possibly would make sense to have some way to build with either, for example with a configure switch, will make it easier to compare them in the future if we care to switch again.

If you build an external ffmpeg/libav, you can already do that now without problems. Just in-tree is a bit ugly because of the git submodule stuff.

Goog to know about comment 4. My recent experience is that I had to fix a bug in libav and submit upstream for something already fixed fixed in ffmpeg. Upstream was responsive though.

Let's try for 1.5.3 then? Or better wait until 1.7?

I've been running with ffmpeg locally for a bit now, including build system stuff.

Let's do it for 1.5.3 then, I'll push the change tonight if nobody complains until then. On IRC it seemed like people don't care or are in favor of the change.

Regardless of any particular merits or one or the other, I think it makes sense to go where the momentum is and where the distros are going. It's not really our battle to fight unless there are very specific and persuasive reasons to stick to one or to other.

commit 97f58baecd660767c13b039a1c525b30c8b95d5f
Author: Sebastian Dröge <sebastian@centricular.com>
Date:   Tue Jun 30 12:05:46 2015 +0200

    Switch from libav v11.4 to ffmpeg n2.7.1
    
    ffmpeg seems to be the one of the two forks, which is most widely used by
    Linux distributions and in general. Also Google is using it for e.g. Chrome
    and has engineers working on finding and fixing security issues in it.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=751607

For me this breaks git-update because the existing submodule checkout is pointing to the old libav repo.

It would be nice if either the build system was able to detect that it needs a git submodule sync, or if there was some documentation warning developers of the
need to fix their gst-libav packages when doing a git pull.

Can you check what exactly is necessary for you here? Is
> git submodule sync
enough? Or more than that?

(In reply to Sebastian Dröge (slomo) from comment #11)
> Can you check what exactly is necessary for you here? Is
> > git submodule sync
> enough? Or more than that?

To fix my repo I did:

    git submodule sync
    git submodule update

Created attachment 307013 [details] [review]
Sync submodule if it still points to libav.org

So something like this... just need to remove the bashisms.

Can you confirm that this works for you? Also someone please sanity check :)

Review of attachment 307013 [details] [review]:

This will just happen if you run autogen.sh, which I expect people won't do on existing checkouts. Maybe you should instead create a new gst-libs/ext/ffmpeg submodule, so if the wrong one has been checked out, it just won't build.

Untested bashism-free version, with a subshell:
(cd gst-libs/ext/libav; git remote -v | grep -q ffmpeg.org) && git submodule sync

Note also that autogen.sh is autogenerated from common/autogen.sh.in via common/update-common -> common/update-autogen

So how should we do this? Seems like all solutions are ugly :)

Could put a check into configure(.ac) - which will in a git checkout automatically be re-generated in maintainer mode. And then just error out in configure and print the command?

*** Bug 752172 has been marked as a duplicate of this bug. ***