Hi, ----- Mail original ----- > 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 > > [...] > > 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. >
Please send a patch, if all works as before, with the case above being fixed, I can only think as it being beneficial. -- Ben _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel