[FFmpeg-devel] [FFmpeg-cvslog] r15010 - in trunk: Changelog libavcodec/dv.c libavcodec/dvdata.h libavformat/dv.c libavformat/isom.c

Michael Niedermayer michaelni
Mon Sep 15 16:45:56 CEST 2008


On Mon, Sep 08, 2008 at 05:10:47PM -0700, Roman Shaposhnik wrote:
> On Tue, 2008-09-09 at 00:47 +0200, Michael Niedermayer wrote:
[...]
> > > But the question
> > > remains -- why? What does it really buy us?
> > 
> > If you want an academic application, nothing
> > If you want to use the code, its cpu and memory requirements do matter,
> > maybe not on an average desktop system that just decodes a single video,
> > but on some embeded hw the memory requirements likely do matter alot,
> > someone might try to use ffmpeg to encode and decode dv on a cammera ...
> 
> sure they might. but right now you're arguing over an extra 32Kb 
> of data. as for the memory requirement, long time ago I started
> with an idea to have a switch to trade speed for memory
> DV_CODEC_TINY_TARGET -- there doesn't seem to be a single case
> of somebody using it.

People probably expect CONFIG_SMALL to do that.


> 
> > besides if all tables are always there, they could as well be static tables
> > and not duplicated in each context.
> 
> That's a reasonable comment and I'd rather make them static, than
> lazy-loading, 

fine, then please do


> although that would make them lose any relationship with
> the DV specs. you wouldn't be able to tell where these numbers 
> originated from. Also, I can't really interpret the fact that
> you've originally approved this very hunk as anything else but
> you coming up with more and more hoops for me to jump through.
> Which, of course, doesn't really make me happy. I believe your
> next point about 12bit pcm is also yet another hoop.
> 
> > > > > > i cannot comment this because this is not correctly implemented
> > > > > > dv_audio_12to16() clearly belongs in a decoder not in the demuxer.
> > > > > 
> > > > > Well, the new code has nothing to do with 12bit pcm, and in fact,
> > > > > the comment should be removed (or updated?) since the audio
> > > > > doesn't have to be 12bit pcm in order to have "next" stereo channel.
> > > > > 
> > > > > What I don't understand though is your statement that dv_audio_12to16()
> > > > > belongs to a decoder. Which decoder?
> > > > 
> > > > the (currently non existing) 12bit audio DV decoder :)
> > > 
> > > There's nothing DV specific about 12bit pcm. If your comment is meant to
> > > indicate that I need to add 12bit pcm support to libavcodec/pcm.c and
> > > make DV demuxer simply return the raw data -- I would agree with you.
> > > But, once again, there's nothing DV specific about 12bit pcm audio.
> > 
> > What except dv uses this 12 bit float "PCM" format?
> 
> Personally I've seen it once in an Ogg. I also remember people telling
> me that it can be seen as a separate standalone stream in DV containers.
> But why do you ask? Even if it is only used by DV (as you seem to
> suggest) doesn't make it into a codec. It is no more a codec that
> something like PIX_FMT_GRAY16LE, which isn't all that much widespread
> either.

16bit pcm is a codec as well, see avcodec.h:
    /* various PCM "codecs" */
    CODEC_ID_PCM_S16LE= 0x10000,
    CODEC_ID_PCM_S16BE,
    CODEC_ID_PCM_U16LE,
    CODEC_ID_PCM_U16BE,
    CODEC_ID_PCM_S8,
    CODEC_ID_PCM_U8,
    ...

so calling the 12bit float "PCM" used in dv one does not seem wrong.
Besides iam not sure why you are so upset by me calling it 12bit dv audio
i cant call it 12bit pcm because this really is a incomplete description.
there are many things one could describe by 12bit pcm, and the 12bit float
numbers used in dv are likely not the first thing one would think of.
Or is there some standard that describes these 12bit floats?


> 
> Although, once again I don't want to argue with you: just tell me
> exactly what you want me to do.
> 
> Thanks,
> Roman.
> 
> P.S. At some unfortunate point in my career I had a manager with whom
> we were on the "just tell me exactly what you want me to do" basis. 
> They guy just had bad taste in software, nothing could be done about it.
> It wasn't particularly enjoyable experience. I left. But even in my
> wildest dreams I couldn't have imagined that an open source PL could
> be the same way. The point of the story is -- even with that guy
> I had to finish up the project that I worked on. So just tell me exactly
> what you want me to do so that I can be done with DVCPRO HD,
> replace my name in MAINTAINERS with yours and do something far more
> enjoyable.

You really sound depressing, and iam not even sure why exactly you so much
dislike ffmpeg or me. I dont think ive asked for any unreasonable changes
to the code.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080915/c3d52ae8/attachment.pgp>



More information about the ffmpeg-devel mailing list