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

[Roman Shaposhnik]

On Tue, 2008-09-09 at 00:47 +0200, Michael Niedermayer wrote:
> > yeah, but is it really worth it? I mean if you make me jump through
> > this additional hoop -- I will, but I'm not sure this added 
> > complexity will be good for the code base. after all, singling out
> > just one table like this doesn't make much sense, the proper solution
> > would be to lazy-initialize every table that's part of:
> > dv_build_unquantize_tables() and dvvideo_init(). 
> 
> yes it applies to more tables than this.

Just tell me what am I supposed to do. Do you want DV codec to not
initialize any tables to begin with and have an if statement
in dvvideo_decode_frame() and dvvideo_encode_frame() that
would lazy initialize the missing ones? 

> > 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.

> 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, 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.

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.