From: Mike Melanson <mike@mu...> - 2005-05-28 02:33:05
I synced FFmpeg again. The most notable improvement is that the VP3
decoder is *finally* correct, and notably faster. There has also been
work to get it decoding Theora data. To make it work with xine we would
need to get the Theora setup data sent over to the decoder.
Also, there is a decoder for a format called Fraps FPS1. Samples are
here (only v0 and v1 work presently):
Pressing issue directed towards dsalt: The last time I synced the tree
and updated the diff_to_ffmpeg_cvs.txt file, it was just over 400 lines
long. I was not keeping track of your changes over the last few weeks.
But the same file is now an order of magnitude larger, weighing in at
over 4000 lines. What on earth did you do? I see that revision 1.27
contains "Compile fixes for gcc >= 3.4" and accounts for 3800+ new lines
in the diff file.
With this many differences between our copy and the official copy, we
should just fork the tree. But we do not want to do that. The goal is to
keep our trees as similar as possible and keep changes to an absolute
So my big question: What do these changes do for us? And would they
benefit being the FFmpeg project by being rolled into the official tree?
From: Mike Melanson <mike@mu...> - 2005-05-28 02:42:58
Mike Melanson wrote:
> So my big question: What do these changes do for us? And would they
> benefit being the FFmpeg project by being rolled into the official tree?
Hmm, I just re-read your email to me from when I wasn't really paying
The function reordering is your call. If it's reverted, other changes will
need to be made wrt xine-lib's redefinition of inline so that we can avoid
the compile errors.
The __inline__ changes should *not* go upstream: they're workarounds for
redefinition of inline, and they may well not be needed now because of the
So there is function reordering. No wonder there is so much noise. That
needs to be fixed.