[soc]: r1393 - in dirac/libavcodec: dirac.h diracdec.c diracenc.c
Author: marco Date: Fri Sep 21 22:40:48 2007 New Revision: 1393 Log: copy files to prepare splitting up dirac.c Added: dirac/libavcodec/dirac.h - copied unchanged from r1392, /dirac/libavcodec/dirac.c dirac/libavcodec/diracdec.c - copied unchanged from r1392, /dirac/libavcodec/dirac.c dirac/libavcodec/diracenc.c - copied unchanged from r1392, /dirac/libavcodec/dirac.c
marco <subversion@mplayerhq.hu> writes:
Author: marco Date: Fri Sep 21 22:40:48 2007 New Revision: 1393
Log: copy files to prepare splitting up dirac.c
Added: dirac/libavcodec/dirac.h - copied unchanged from r1392, /dirac/libavcodec/dirac.c dirac/libavcodec/diracdec.c - copied unchanged from r1392, /dirac/libavcodec/dirac.c dirac/libavcodec/diracenc.c - copied unchanged from r1392, /dirac/libavcodec/dirac.c
It seems one commit email in which I make the changes to these files is missing, or I am crazy (not very unlikely). I hope someone wants to look at this commit, especially the inline functions in dirac.h, to see if I split up this file properly. Now it is still easy to revert some changes using svn copy :-) Thanks, Marco
On Fri, Sep 21, 2007 at 11:11:09PM +0200, Marco Gerards wrote:
marco <subversion@mplayerhq.hu> writes:
Log: copy files to prepare splitting up dirac.c
Added: dirac/libavcodec/dirac.h - copied unchanged from r1392, /dirac/libavcodec/dirac.c dirac/libavcodec/diracdec.c - copied unchanged from r1392, /dirac/libavcodec/dirac.c dirac/libavcodec/diracenc.c - copied unchanged from r1392, /dirac/libavcodec/dirac.c
It seems one commit email in which I make the changes to these files is missing, or I am crazy (not very unlikely).
I just resent that mail to myself, it is 394k big and thus likely held by the mailing list software. In any case, this was not the way to go. r1393 is pointless, creating identical copies of files makes no sense. Instead, create the new files with 'svn copy', make your modifications, then commit the changed files. You can do this separately for encoder and decoder to limit the size of the commit. Diego
Diego Biurrun <diego@biurrun.de> writes:
On Fri, Sep 21, 2007 at 11:11:09PM +0200, Marco Gerards wrote:
marco <subversion@mplayerhq.hu> writes:
Log: copy files to prepare splitting up dirac.c
Added: dirac/libavcodec/dirac.h - copied unchanged from r1392, /dirac/libavcodec/dirac.c dirac/libavcodec/diracdec.c - copied unchanged from r1392, /dirac/libavcodec/dirac.c dirac/libavcodec/diracenc.c - copied unchanged from r1392, /dirac/libavcodec/dirac.c
It seems one commit email in which I make the changes to these files is missing, or I am crazy (not very unlikely).
I just resent that mail to myself, it is 394k big and thus likely held by the mailing list software.
Oh, right...
In any case, this was not the way to go. r1393 is pointless, creating identical copies of files makes no sense. Instead, create the new files with 'svn copy', make your modifications, then commit the changed files. You can do this separately for encoder and decoder to limit the size of the commit.
Sorry for that, I thought this was the way to go. Now I know this for next time... Although my main concerns are with if I made the split correctly as in code wise. Thanks, Marco
On Mon, Sep 24, 2007 at 03:14:40PM +0200, Marco Gerards wrote:
Diego Biurrun <diego@biurrun.de> writes:
On Fri, Sep 21, 2007 at 11:11:09PM +0200, Marco Gerards wrote:
marco <subversion@mplayerhq.hu> writes:
Log: copy files to prepare splitting up dirac.c
Added: dirac/libavcodec/dirac.h - copied unchanged from r1392, /dirac/libavcodec/dirac.c dirac/libavcodec/diracdec.c - copied unchanged from r1392, /dirac/libavcodec/dirac.c dirac/libavcodec/diracenc.c - copied unchanged from r1392, /dirac/libavcodec/dirac.c
It seems one commit email in which I make the changes to these files is missing, or I am crazy (not very unlikely).
I just resent that mail to myself, it is 394k big and thus likely held by the mailing list software.
Oh, right...
In any case, this was not the way to go. r1393 is pointless, creating identical copies of files makes no sense. Instead, create the new files with 'svn copy', make your modifications, then commit the changed files. You can do this separately for encoder and decoder to limit the size of the commit.
Sorry for that, I thought this was the way to go. Now I know this for next time...
Although my main concerns are with if I made the split correctly as in code wise.
Well, if your patch was not 394kB, maybe somebody would review it... Diego
Hi On Mon, Sep 24, 2007 at 04:08:30PM +0200, Diego Biurrun wrote: [...]
Although my main concerns are with if I made the split correctly as in code wise.
Well, if your patch was not 394kB, maybe somebody would review it...
well, true its big but how would you have split the files without the patch becoming as large as the files you split? its not possible ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle
On Mon, Sep 24, 2007 at 04:16:08PM +0200, Michael Niedermayer wrote:
On Mon, Sep 24, 2007 at 04:08:30PM +0200, Diego Biurrun wrote: [...]
Although my main concerns are with if I made the split correctly as in code wise.
Well, if your patch was not 394kB, maybe somebody would review it...
well, true its big but how would you have split the files without the patch becoming as large as the files you split? its not possible ...
First split off the encoder, then the decoder or vice versa. Doing this in separate commits halves the size of the diff. Diego
Hi On Mon, Sep 24, 2007 at 03:14:40PM +0200, Marco Gerards wrote:
Diego Biurrun <diego@biurrun.de> writes:
On Fri, Sep 21, 2007 at 11:11:09PM +0200, Marco Gerards wrote:
marco <subversion@mplayerhq.hu> writes:
Log: copy files to prepare splitting up dirac.c
Added: dirac/libavcodec/dirac.h - copied unchanged from r1392, /dirac/libavcodec/dirac.c dirac/libavcodec/diracdec.c - copied unchanged from r1392, /dirac/libavcodec/dirac.c dirac/libavcodec/diracenc.c - copied unchanged from r1392, /dirac/libavcodec/dirac.c
It seems one commit email in which I make the changes to these files is missing, or I am crazy (not very unlikely).
I just resent that mail to myself, it is 394k big and thus likely held by the mailing list software.
Oh, right...
In any case, this was not the way to go. r1393 is pointless, creating identical copies of files makes no sense. Instead, create the new files with 'svn copy', make your modifications, then commit the changed files. You can do this separately for encoder and decoder to limit the size of the commit.
it may be pointless but it does no harm ...
Sorry for that, I thought this was the way to go. Now I know this for next time...
Although my main concerns are with if I made the split correctly as in code wise.
after a quick 10min look it looks ok ... one thing i spoted where that there are non static things in there without a ff_ prefix but with just a dirac_ prefix these could break an application which tries to link to both ffmpeg and the official dirac [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates
Michael Niedermayer <michaelni@gmx.at> writes: Hi, [...]
Although my main concerns are with if I made the split correctly as in code wise.
after a quick 10min look it looks ok ...
Great, thanks for this effort :-)
one thing i spoted where that there are non static things in there without a ff_ prefix but with just a dirac_ prefix these could break an application which tries to link to both ffmpeg and the official dirac
Yes, you are right. At the same time I split the file, I introduced this namespace for non-static symbols. I do not think the dirac_* names collide with those of the reference implementation, but I can not guarantee they won't. What would be a better prefix? dirac_ff_* or even ff_*? Or just leave it as it is, until people start complaining? Personally I do not care much about the prefix and will change it to whatever you like. Thanks, Marco
Hi On Mon, Sep 24, 2007 at 04:37:07PM +0200, Marco Gerards wrote:
Michael Niedermayer <michaelni@gmx.at> writes:
Hi,
[...]
Although my main concerns are with if I made the split correctly as in code wise.
after a quick 10min look it looks ok ...
Great, thanks for this effort :-)
one thing i spoted where that there are non static things in there without a ff_ prefix but with just a dirac_ prefix these could break an application which tries to link to both ffmpeg and the official dirac
Yes, you are right. At the same time I split the file, I introduced this namespace for non-static symbols. I do not think the dirac_* names collide with those of the reference implementation, but I can not guarantee they won't.
What would be a better prefix? dirac_ff_* or even ff_*? Or just leave it as it is, until people start complaining? Personally I do not care much about the prefix and will change it to whatever you like.
please use ff_dirac_* [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I count him braver who overcomes his desires than him who conquers his enemies for the hardest victory is over self. -- Aristotle
participants (4)
-
Diego Biurrun -
marco -
Marco Gerards -
Michael Niedermayer