[FFmpeg-devel] [PATCH] avformat/apngdec: transmit all the chunks between consecutive fcTL ones.

[Benoit Fouet]

Hi,

Le 24/11/2014 17:54, James Almer a écrit :
> On 24/11/14 12:12 PM, Benoit Fouet wrote:
>> In order to support multiple IDAT of fdAT chunks following an fcTL one,
>> transmit all the chunks between two fcTL ones (or between fcTL and IEND
>> one).
> Using one of the samples from https://people.mozilla.org/~dolske/apng/demo.html
>
> $ ./ffmpeg -i chompy2.png chompy2.mp4 -loglevel debug

Just to be sure: the problem you have is present whther or not this 
patch is, right?

> [...]
>
> Input #0, apng, from 'chompy2.png':
>    Duration: N/A, bitrate: N/A
>      Stream #0:0: Video: apng, rgba, 166x120, 14.58 fps, 10 tbr, 90k tbn, 90k tbc
> Output #0, mp4, to 'chompy2.mp4':
>    Metadata:
>      encoder         : Lavf56.15.100
>      Stream #0:0, 0, 1/10240: Video: mpeg4 ( [0][0][0] / 0x0020), yuv420p, 166x120, 1/10, q=2-31, 200 kb/s, 10 fps, 10240 tbn, 10 tbc
>      Metadata:
>        encoder         : Lavc56.13.100 mpeg4
> Stream mapping:
>    Stream #0:0 -> #0:0 (apng (native) -> mpeg4 (native))
> Press [q] to stop, [?] for help
> *** dropping frame 8 from stream 0 at ts 5
> *** dropping frame 10 from stream 0 at ts 7
> *** dropping frame 12 from stream 0 at ts 9
> *** dropping frame 14 from stream 0 at ts 11
> [output stream 0:0 @ 0000000000317a20] EOF on sink link output stream 0:0:default.
> No more output streams to write to, finishing.
> frame=   16 fps=0.0 q=2.3 Lsize=      64kB time=00:00:01.60 bitrate= 328.6kbits/s dup=0 drop=5
> video:63kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.433775%
> Input file #0 (chompy2.png):
>    Input stream #0:0 (video): 21 packets read (288248 bytes); 21 frames decoded;
>    Total: 21 packets (288248 bytes) demuxed
> Output file #0 (chompy2.mp4):
>    Output stream #0:0 (video): 16 frames encoded; 16 packets muxed (64794 bytes);
>    Total: 16 packets (64794 bytes) muxed
> 23 frames successfully decoded, 0 decoding errors
>
> I fixed this by using time_base instead of r_frame_rate in decode_fctl_chunk, but i'm not sure
> if that's correct either because it's changed after reading every frame, and in this one apng
> file the last frame has a different delay_den and delay_num values than in every previous frame.

That was the part I'd have loved to get some feedback on.
I have no preference whatsoever on which solution we use for frame 
duration, but it seems rather clear with the issue you get that the one 
I've put in place is not the right one :-)

-- 
Ben