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

[Kevin Wheatley]

On Fri, Feb 20, 2015 at 2:14 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Fri, Feb 20, 2015 at 01:48:55PM +0000, Kevin Wheatley wrote:
>> Here is the kind of thing that this looks like... This is definitely
>> NOT a patch :-)
>
> i dont understand this patch

there are at least two of us.

> please explain why you use vos_data
> it can be the first packet and you seem to implement that case
> but it is not always the first packet and you seem to add alot of
> code to handle this. But if the data is in the dnxhd packets
> using that always and not vos_data seems much easier
> what am i missing ?

probably nothing, I've only tried to find a small change to the code,
and to localise the effect to the function so as to minimise the
effect of the change - I really don't have a full enough grasp of the
code base to do otherwise.

> or one could ask the other way around why vos data is set
> inconsistently, is there a case where setting it to the first packet
> does not work?


I'm simply showing how the current contents of vos_data can be used,
like you say it would be nice if it was always one or the other, but
for whatever reason the copy case puts the atoms in there, which is
why the current code without the patch generates incorrect atoms when
copy is used on DNxHD files as the code that writes the new atom
expects the bitstream, all I did was try a quick detection of what the
contents are and use them appropriately. to see if the files would
then be fixed.

In my case I'm unable to read the files in The Foundry's Nuke if I
'copy' them via ffmpeg because the atom was written incorrectly, but
with the diff applied then the copied files will load.

Kevin