Kostya Shishkov <kostya.shish...@gmail.com> writes:
> On Fri, Oct 26, 2012 at 12:44:22PM +0100, Måns Rullgård wrote:
>> Kostya Shishkov <kostya.shish...@gmail.com> writes:
>>
>> > On Thu, Sep 20, 2012 at 12:05:11PM +0100, Måns Rullgård wrote:
>> >> Benjamin Larsson <benja...@southpole.se> writes:
>> >>
>> >> > libavcodec/a64multienc.c: In function ‘a64multi_encode_frame’:
>> >> > libavcodec/a64multienc.c:342:17: warning: ‘buf’ may be used
>> >> > uninitialized in this function [-Wuninitialized]
>> >> >
>> >> > The compiler has trouble to figure out that the if block
>> >> > if (c->mc_frame_counter == c->mc_lifetime) {
>> >> > never should be entered with both values being 0. So add
>> >> > an explicit check on one of the parameters.
>> >> > ---
>> >> > libavcodec/a64multienc.c | 2 +-
>> >> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >
>> >> > diff --git a/libavcodec/a64multienc.c b/libavcodec/a64multienc.c
>> >> > index c9d3b3c..9d3dca5 100644
>> >> > --- a/libavcodec/a64multienc.c
>> >> > +++ b/libavcodec/a64multienc.c
>> >> > @@ -304,7 +304,7 @@ static int a64multi_encode_frame(AVCodecContext
>> >> > *avctx, AVPacket *pkt,
>> >> > }
>> >> >
>> >> > /* lifetime reached so now convert X frames at once */
>> >> > - if (c->mc_frame_counter == c->mc_lifetime) {
>> >> > + if ((c->mc_frame_counter == c->mc_lifetime) && c->mc_lifetime) {
>> >> > req_size = 0;
>> >> > /* any frames to encode? */
>> >> > if (c->mc_lifetime) {
>> >> > --
>> >>
>> >> If this is correct, simpler would be to remove the if (c->mc_lifetime)
>> >> condition on the last line above. However, I do not think this is the
>> >> case, at least it is not equivalent to the current code. If the !pict
>> >> condition is true, mc_lifetime and mc_frame_counter can both be set to
>> >> zero (in a rather convoluted way). This happens if encode() is called
>> >> twice with a null pict parameter, which is normal to flush the delayed
>> >> frames at the end of an encoding. On the second call with null input,
>> >> the encoder will return a zero-sized packet. On the third, it finally
>> >> reports end. This seems somewhat strange, so it may well be an error.
>> >>
>> >> Assuming the final zero-length packet is incorrect, there is a simpler
>> >> solution to it all (untested):
[...]
>> > probably OK
>>
>> So can someone find out for sure? It could be that it's supposed to
>> output an empty packet at the end.
>
> No, A64 muxer creates and writes an empty packet at the end if needed itself.
That still leaves the matter of testing it.
--
Måns Rullgård
m...@mansr.com
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
