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

Michael Niedermayer michaelni
Tue Sep 9 00:47:53 CEST 2008


On Mon, Sep 08, 2008 at 02:22:58PM -0700, Roman Shaposhnik wrote:
> 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(). 

yes it applies to more tables than this.


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

besides if all tables are always there, they could as well be static tables
and not duplicated in each context.


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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- 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/20080909/7038f210/attachment.pgp>



More information about the ffmpeg-devel mailing list