Recherche avancée

Sur d’autres sites (6598)

• sws_scale screws up last pixel row in smaller x264 mp4 encoding

  23 juillet 2012, par TheSHEEEP

  I am muxing pictures in the PIX_FMT_ARGB format into an mp4 video.

  All of it works well, except that the last pixel row of the outgoing image is screwed up, in most cases the last row is completely black, sometimes there are other colors, it seems somehow dependant on the machine it runs on.

  I am absolutely sure that the error must be in sws_scale, as I am saving the images before and after the scaling. The input images do not have the error, but after the sws_scale() I save the yuv image and the error is apparent.

  Here is an example :

  Original

  

  Yuvfile (after sws_scale)

  

  At the bottom of the Yuvfile, you will see the black row.

  This is how I do the scaling (it is after the official ffmpeg examples, more or less) :

  static int sws_flags = SWS_FAST_BILINEAR | SWS_ACCURATE_RND;
  
  
  
  if (img_convert_ctx == NULL)
  
  {
  
     img_convert_ctx = sws_getContext( srcWidth, srcHeight,
  
             PIX_FMT_ARGB,
  
             codecContext->width, codecContext->height,
  
             codecContext->pix_fmt,
  
             sws_flags, NULL, NULL, NULL );
  
     if (img_convert_ctx == NULL)
  
     {
  
        av_log(c, AV_LOG_ERROR, "%s","Cannot initialize the conversion context\n");
  
        exit(1);
  
     }
  
  }
  
  fill_image(tmp_picture, pic, pic_size, frame_count, ptr->srcWidth, ptr->srcHeight );
  
  
  
  sws_scale(img_convert_ctx, tmp_picture->data, tmp_picture->linesize,
  
          0, srcHeight, picture->data, picture->linesize);

  I also tried a number of different SWS_ flags, but all yield the same result.

  Could this be a bug in sws_scale or am I doing something wrong ? I am using the latest version of the ffmpeg libraries.

• Merge commit ’14b4e64eabc84c5a5e57c8ccc56bbeb95380823b’

  16 juillet 2014, par Michael Niedermayer

  Merge commit ’14b4e64eabc84c5a5e57c8ccc56bbeb95380823b’
  * commit ’14b4e64eabc84c5a5e57c8ccc56bbeb95380823b’ :
  
    g2meet : allow size changes within original sizes
  Merged-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavcodec/g2meet.c

• Transcoding with ffmpeg libfaac reduces the audio duration

  20 juillet 2012, par sky609

  I have to transcode a mpegts file : input.ts(H.264 and AAC)
  So I use the following command line :
  ffmpeg -y -i input.ts -acodec libfaac -vcodec copy out.ts
  But I find that the duration of output.ts's audio is shorter than that of the input.ts !

  If I do the following iterations, the output's audio will be shorter and shorter.

  ffmpeg -y -i out.ts -acodec libfaac -vcodec copy out-iter1.ts
  
  ffmpeg -y -i out-iter1.ts -acodec libfaac -vcodec copy out-iter2.ts
  
  ffmpeg -y -i out-iter2.ts -acodec libfaac -vcodec copy out-iter3.ts
  
  ffmpeg -y -i out-iter3.ts -acodec libfaac -vcodec copy out-iter4.ts
  
  ffmpeg -y -i out-iter4.ts -acodec libfaac -vcodec copy out-iter5.ts

  My ffmpeg's version is 0.6.6. libfaac's version is 1.28.

  input.ts's audio duration is 10.432 seconds. out-iter5.ts's audio duration is 10.56 seconds

  And I have also tried ffmpeg with version 0.11.
  And it makes the audio longer than the original input.

  So my question is : how to make sure the output's audio duration is same as the input's audio.
  Since libfaac will make the audio shorter, how can I compensate for it ?
  (For some reason I can't use -acodec copy directly.) Any suggestions ?