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

Roman Shaposhnik rvs
Mon Sep 8 23:22:58 CEST 2008

On Mon, 2008-09-08 at 22:12 +0200, Michael Niedermayer wrote:
> The point is that if one is browsing the doxygen doc be that local or one of
> the online ones the field would be documented.
> Not everyone reads the doxy because he wants to use libav* in his own program
> some might very well want to work on libav* itself.

Hm. Ok.

> > You've ok'ed this very hunk here:
> >     http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-August/051782.html
> > So does it mean that you can withdraw other OKed hunks? ;-)
> > 
> > Seriously, though -- I would like to NOT constraint the codec by the
> > initial stream that is given to it. If we do what you suggest than
> > decoding 1080i and 720p using the same instance of DV decoder
> > will not be possible. Or are you suggesting something else?
> does it actually work if 1080i and 720p are mixed?

the decoder does work. the rest of FFmpeg's machinery (and I mostly
mean ffmpeg.c) by that might not work. 

> and the table could of course be inited per picture or when a size
> change is detected.

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(). But the question
remains -- why? What does it really buy us?

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


More information about the ffmpeg-devel mailing list