[FFmpeg-devel] Gaining access to a encoder context in avformat?

[Michael Niedermayer]

On Fri, Feb 20, 2015 at 07:57:05AM +0000, Kevin Wheatley wrote:
> 
> 
> Sent on the go...
> 
> > On 19 Feb 2015, at 18:35, Michael Niedermayer <michaelni at gmx.at> wrote:
> > 
> > theres no encoder, the data could instead come from another mov
> > file or a binary encoder used by some user application with
> > libavformat
> 
> Michael,
> 
> Thanks for your response, I must be confused then. What I thought was based on the following.
> 
> I have say a set of image files that I want to encode as dnxhd in QuickTime, so ffmpeg sets up the encoder, and during each image's encoding the encoder needs some information such as if the movie is encoded with interlaced fields, and also the specifics of the resolution and bit rates there's a codec/compression Id associated with those settings. When writing the avid atoms, they also should have those same values encoded in them.
> 

> This is important as if instead of starting from image files we start from an existing movie with the atom present, we would not want to use values based on that atom, which is what s currently done, I wanted to find the dnxencoder structure to correctly populate the atom.

If you start with a existing movie and copy the packets one by one
there is no decoder and no encoder, so no dnxencoder structure

if you want to put some value in the avid atom which are stored in the
bitstream/packets of dnxhd and not in the generic data structures
like width/height would be then you have to extract these from the
dnxhd bitstream one way or another because thats the only thing thats
there in the memory of your machine. I dont know what exact information
you want/need from the dnxhd encoder ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150220/159cb466/attachment.asc>