[FFmpeg-devel] IRC shit smearing
Sat Jan 16 02:46:59 CET 2010
A reply to a IRC discussion:
<Compn> Dark_Shikari : so now that h264 is split, are you going to speed up
some functions? :P
<mru> slicing a file randomly into a smaller bits and glueing them back
together with #include isn't exactly what Dark_Shikari had in mind
<mru> or am I wrong
<Dark_Shikari> he took a fat goose, chopped it up into bits
<Dark_Shikari> and stitched it back together
<Dark_Shikari> but it doesn't do much to hide the fact that the old bird is
ive removed the svq3 #include people didnt like at the begin of the cleanup
and h264.c is now nicely split into C files that are compiled to seperate
object files like it should be.
the nasty h264_mvpred include in h264.h is a quick workaround for a
Considering that, i think you guys are a little overshooting here. We never
had a problem in the code in any way compareable to what is being raised,
dark shikaris architectural problem is still waiting for some clarification
of what that is supposed to be.
Short of multithreading, a few minor optimizations and a few bugs iam not
aware of an issue.
That said, what mru did with the #ifdefs is uhm, not so hot either.
Also i welcome your guys contributions in terms of code as well as comments
much more than this kind of shit smearing about my hard work behind my back.
Dark_Shikari & mru If you have suggestions for improvment of what i do
my email address is in the from line of this email, if not then i dont
think you have to do this kind of shit smearing.
<Dark_Shikari> lol, mru
<Dark_Shikari> I love michael's response about dts
<Dark_Shikari> It could be set in the AVPacket that avcodec_encode_video()
will one day
iam glad i could entertain you, iam trying my best
<mru> AVFrame already has pts
<mru> we should just add dts and be done with it
that would be wrong, an AVFrame represents a raw bitmap thus there is no
decode step and also no decode timestamp.
<mru> that'll break api of course
no, it wouldnt,
<Dark_Shikari> of course
may i request you 2 read the code you flame about once in a while
theres no problem adding fields to AVFrame we have added plenty.
<mru> wait, that's the wrong end
<Dark_Shikari> I guess it's just that all current encoders except x264
<Dark_Shikari> a) don't reorder frames
<Dark_Shikari> b) are shit
<Dark_Shikari> and so don't return dts.
The reason why theres no dts returned is thats it isnt needed
Or if you think iam wrong you could somewhere on some place behind my back
say why the dts is needed. Just dont tell me directly as i might fix the
issue and you then had one less to complain about behind my back.
ahh and everyone who now thinks "how did this leak to michael, how can we
prevent this from happening again"
Think for a moment why exactly you are trying to prevent the maintainer
to hear about critique about his code on a IRC channel related to the project
tgat contains his code? Who is this helping?
Surely not ffmpegs quality
are you so much a coward to not be able to tell your critique to me?
or do you want the problems you flame about to stay there? because if
you succeed in keeping the critique hidden from me chance are the problems
wont be known or corrected or you might plain belive theres a problem where
there is none.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> ... defining _GNU_SOURCE...
For the love of all that is holy, and some that is not, don't do that.
-- Luca & Mans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel