[MPlayer-users] small feature request: add git
joshf87 at live.com
Fri Feb 14 06:20:57 CET 2014
On 2/13/2014 17:41, Roger Pack wrote:
> On 12/19/13, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
>> Roger Pack <rogerdpack2 <at> gmail.com> writes:
>>>> that it could use git submodules and thus be able to
>>>> "freeze" the ffmpeg dir to certain "known working"
>>>> revisions. Then it would always compile instead of
>>>> allowing ffmpeg to (at times) break it.
>>> Or possibly add a file that indicates a known working
>>> revision of ffmpeg for that version of mplayer.
>> Could you explain what problem either of these "solutions"
>> would fix and particularly how it would fix them?
> The typical problem that occurs is this.
> I have some (patched) version of mplayer that I know works. I save
> off my diff and the SVN revision number.
> Then a few months later, I think "shoot I need to test that on this
> other platform" so I go to the new platform, plunk down my source, and
> try and get a working build, and...it doesn't work, since ffmpeg's
> version has since changed in a way that breaks the old one. So now I
> have to go back to a working build environment (if I still have it)
> and try and figure out which ffmpeg version matched at the time...I
> suppose I could try to checkout from ffmpeg based on timestamp, but
> that would require git fu beyond my knowledge. Unfortunately I've run
> into this particular frustration on several occasions, so it does
> occur "out there in the wild."
> MPlayer-users mailing list
> MPlayer-users at mplayerhq.hu
I save the FFmpeg revision in a file called 'snapshot_ffmpeg' which acts
the same as 'snapshot_version' after some modifications. The binaries
also display the FFmpeg revision. I prefer the output of FFmpeg's own
version.sh or you can simply use 'git rev-parse HEAD > somefile'.
More information about the MPlayer-users