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

[Michael Niedermayer]

On Fri, Feb 20, 2015 at 12:35:59PM +0000, Kevin Wheatley wrote:
> Please excuse my newbie knowledge of the code base BTW...
> 
> I've just done a simple test
> 
> ffmpeg -color_range mpeg -i test_charts/test_encoding.tif -c dnxhd -vb
> 115M  /quicktimes/ffmpeg_test.mov
> 
> During this the vos_data contains...
> 
> 00 00 02 80 01 01 80 A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 04 38 07 80 00 04 38 00 00 38 88 ...
> 
> Which looks to me like the start of the VC3/DNxHD bit stream and in
> this case the code puts valid data in the header atoms.
> 
> If I then
> 
> fmpeg -i quicktimes/ffmpeg_test.mov -c copy quicktimes/ffmpeg_test_copy.mov
> 
> the vos_data instead contains
> 
> 00 00 00 18 41 43 4C 52 41 43 4C 52 30 30 30 31 00 00 00 01 00 00 00
> 00 00 00 00 18 41 50 52 47 41 50 52 47 ...
> 
> which is the  start of the Avid atoms from the incomming Quicktime.
> 
> So I could peak into the stream and 'guess' based on the content being
> 0x00, 0x00, 0x02, 0x80, 0x01  that we are encoding and can trust the
> contents, else I could search through looking for the atom via the
> string "ARESARES" and then having located it I could assume to use
> that. The only oddball case is if it is not found, at that point the
> code needs to know if it is interlaced as well as the avid codec
> identifier, or maybe that is the point at which we 'give up' and fail
> with unsupported?

if you need to put 2 bits from a fixed location of the "first" packet
into some avid atoms its probably easiest to read them straight out of
the first packet into some new field in a struct and then use that
when writing the atoms.

IIUC theres no generic field in AVStream, AVCodecContext or elsewhere
that holds this information. If there is, setting this field from the
encoder/demuxer and using it would be the more correct path

extracting the data from vos_data seems trickier

It would also be possible to add a first_packet field where vos_data
is and always initialize it to the first packet and use that instead

I sure do not fully know all the details of the issue so i might be
missing something

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.
-------------- 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/aa6103e0/attachment.asc>