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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
