Re: [FFmpeg-trac] #5799(undetermined:new): Memory psudo-leak when FF_API_CODED_FRAME enabled

2016-09-25 Thread FFmpeg 
#5799: Memory psudo-leak when FF_API_CODED_FRAME enabled
-+-
 Reporter:  DeHackEd |Owner:
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
  Version:  git-master   |  undetermined
 Keywords:  cc oom   |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-

Comment (by oromit):

 Didn't test, but judging from a quick git blame it might be once since
 d6604b29ef544793479d7fb4e05ef6622bb3e534

--
Ticket URL: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac

Re: [FFmpeg-trac] #5799(undetermined:new): Memory psudo-leak when FF_API_CODED_FRAME enabled

2016-09-25 Thread FFmpeg 
#5799: Memory psudo-leak when FF_API_CODED_FRAME enabled
-+-
 Reporter:  DeHackEd |Owner:
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
  Version:  git-master   |  undetermined
 Keywords:  cc oom   |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-

Comment (by cehoyos):

 Is this a regression?
 Sorry, my dvb providers do not send Closed Captions, and the filter is
 very new.
 (I am willing to test myself if you can provide a long sample.)

--
Ticket URL: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac

Re: [FFmpeg-trac] #5799(undetermined:new): Memory psudo-leak when FF_API_CODED_FRAME enabled

2016-09-25 Thread FFmpeg 
#5799: Memory psudo-leak when FF_API_CODED_FRAME enabled
-+-
 Reporter:  DeHackEd |Owner:
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
  Version:  git-master   |  undetermined
 Keywords:  cc oom   |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-

Comment (by oromit):

 CLI without any external inputs:

 ./ffmpeg -f lavfi -i testsrc2 -vf mestimate -c:v mpeg2video -f null -

--
Ticket URL: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac

Re: [FFmpeg-trac] #5799(undetermined:new): Memory psudo-leak when FF_API_CODED_FRAME enabled

2016-09-25 Thread FFmpeg 
#5799: Memory psudo-leak when FF_API_CODED_FRAME enabled
-+-
 Reporter:  DeHackEd |Owner:
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
  Version:  git-master   |  undetermined
 Keywords:  cc oom   |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-

Comment (by oromit):

 This is caused by the following line:
 
https://github.com/FFmpeg/FFmpeg/blob/5a70e56f2/libavcodec/mpegvideo_enc.c#L1738

 which ends up here:
 https://github.com/FFmpeg/FFmpeg/blob/5a70e56f2/libavutil/frame.c#L331

 Which in turn appends the new side data in this function:
 https://github.com/FFmpeg/FFmpeg/blob/5a70e56f2/libavutil/frame.c#L617

 So what is happening here is that inside of the coded_frame, all side data
 is just endlessly appended, until av_frame_new_side_data eventually runs
 out of memory to realloc all that side data.

 A simple fix might be calling av_frame_unref(s->avctx->coded_frame) before
 av_frame_copy_props in mpegvideo_enc.c.

--
Ticket URL: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac

Re: [FFmpeg-trac] #5799(undetermined:new): Memory psudo-leak when FF_API_CODED_FRAME enabled

2016-09-25 Thread FFmpeg 
#5799: Memory psudo-leak when FF_API_CODED_FRAME enabled
-+-
 Reporter:  DeHackEd |Owner:
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
  Version:  git-master   |  undetermined
 Keywords:  cc oom   |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-
Changes (by cehoyos):

 * keywords:  cc => cc oom


--
Ticket URL: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac

Re: [FFmpeg-trac] #5799(undetermined:new): Memory psudo-leak when FF_API_CODED_FRAME enabled

2016-09-25 Thread FFmpeg 
#5799: Memory psudo-leak when FF_API_CODED_FRAME enabled
-+-
 Reporter:  DeHackEd |Owner:
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
  Version:  git-master   |  undetermined
 Keywords:  cc   |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-

Comment (by DeHackEd):

 Closed Captions are mandatory for the issue to manifest.

 Given the nature of the bug, in theory any SIDE_DATA would suffice but
 this is the only way I tested it.

--
Ticket URL: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac

Re: [FFmpeg-trac] #5799(undetermined:new): Memory psudo-leak when FF_API_CODED_FRAME enabled

2016-09-19 Thread FFmpeg 
#5799: Memory psudo-leak when FF_API_CODED_FRAME enabled
-+-
 Reporter:  DeHackEd |Owner:
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
  Version:  git-master   |  undetermined
 Keywords:  cc   |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-
Changes (by cehoyos):

 * keywords:   => cc


Comment:

 Is this also reproducible if the input stream does not contain Closed
 Captions?

--
Ticket URL: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac

Re: [FFmpeg-trac] #5799(undetermined:new): Memory psudo-leak when FF_API_CODED_FRAME enabled

2016-08-26 Thread FFmpeg 
#5799: Memory psudo-leak when FF_API_CODED_FRAME enabled
-+-
 Reporter:  DeHackEd |Owner:
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
  Version:  git-master   |  undetermined
 Keywords:   |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-

Comment (by DeHackEd):

 Very well. I also simplified the command-line a bit. I resize the video so
 that the encoding process will go faster.

 {{{
 $ cat w*.ts | ffmpeg-stock -f mpegts -i - -c:v mpeg2video -s 320x240 -b 5M
 -map 0:v -f mpegts -y /dev/null
 ffmpeg version N-81456-g5006627 Copyright (c) 2000-2016 the FFmpeg
 developers
   built with gcc 4.4.7 (GCC) 20120313 (Red Hat 4.4.7-17)
   configuration: --disable-filters --enable-
 
filter='acrossfade,adelay,adrawgraph,aecho,aevalsrc,aeval,afade,aformat,aloop,anull,amerge,amix,anull,anullsrc,anullsink,aresample,asetps,asetrate,asplit,blackdetect,blend,channelmap,channelsplit,chorus,extrastereo,concat,crop,cropdetect,delogo,deshake,detelecine,drawbox,drawtext,fade,field,format,framestep,framepack,interlace,interleve,null,nullsink,nullsrc,overlay,pan,pp,pullup,psnr,setfield,setpts,scale,settb,split,spp,telecine,volume,volumedetect,yadif'
 --disable-demuxers --enable-
 
demuxer='aac,ac3,asf,avi,concat,dts,dv*,eac3,flv,g*,h264,hevc,hls,image2,m4v,matroska,mjpeg,mov,mp3,mpegps,mpets,mpegtsraw,mpegvideo,ogg,pcm*,rawvideo,rtsp,wav,webm*'
 --disable-muxers --enable-
 
muxer='ac3,apng,af2,avi,dash,dv,eac3,flv,h264hevc,hls,mat*,mjpeg,md5,mov,mp3,mp4,mpeg*,ogg,opus,pcm*,rawvideo,wav,webm*'
 --disable-encoders --enable-
 encoder='mpeg2video,mpeg1video,ac3*,adpcm*,pcm*,aac,mjpeg,libfdk_aac,libx26*'
 --disable-decoders --enable-
 
decoder='aac,aac_fixed,ac3,ac3_fixed,adpcm*,bmp,dvaudio,dvsub,eac3*,gif,gsm,flv,ffv*,hevc,h26*,mjpeg,mp*,opus,pcm*,png,ppm,snow,theora,text,vc1,vp8,vp9,wmc*'
 --enable-libx264 --extra-cflags='-gdwarf-2 -I/home/sean/src/GIT/x264
 -march=core2' --extra-ldflags='-L/home/sean/src/GIT/x264 -lstdc++'
 --enable-gpl --extra-ldflags=-ldl --enable-libfdk-aac --enable-nonfree
 --disable-vdpau --disable-outdevs --disable-hwaccels --disable-indevs
 --disable-lzma --disable-bzlib --disable-zlib --disable-libx265
   libavutil  55. 29.100 / 55. 29.100
   libavcodec 57. 54.100 / 57. 54.100
   libavformat57. 48.100 / 57. 48.100
   libavdevice57.  0.102 / 57.  0.102
   libavfilter 6. 55.100 /  6. 55.100
   libswscale  4.  1.100 /  4.  1.100
   libswresample   2.  1.100 /  2.  1.100
   libpostproc54.  0.100 / 54.  0.100
 [h264 @ 0x1a58ee0] SPS unavailable in decode_picture_timing
 [h264 @ 0x1a58ee0] non-existing PPS 0 referenced
 [h264 @ 0x1a58ee0] SPS unavailable in decode_picture_timing
 [h264 @ 0x1a58ee0] non-existing PPS 0 referenced
 [h264 @ 0x1a58ee0] decode_slice_header error
 [h264 @ 0x1a58ee0] no frame!
 [h264 @ 0x1a58ee0] SPS unavailable in decode_picture_timing
 [h264 @ 0x1a58ee0] non-existing PPS 0 referenced
 [h264 @ 0x1a58ee0] SPS unavailable in decode_picture_timing
 [h264 @ 0x1a58ee0] non-existing PPS 0 referenced
 [h264 @ 0x1a58ee0] decode_slice_header error
 [h264 @ 0x1a58ee0] no frame!
 [h264 @ 0x1a58ee0] SPS unavailable in decode_picture_timing
 [h264 @ 0x1a58ee0] non-existing PPS 0 referenced
 [h264 @ 0x1a58ee0] SPS unavailable in decode_picture_timing
 [h264 @ 0x1a58ee0] non-existing PPS 0 referenced
 [h264 @ 0x1a58ee0] decode_slice_header error
 [h264 @ 0x1a58ee0] no frame!
 [h264 @ 0x1a58ee0] SPS unavailable in decode_picture_timing
 [h264 @ 0x1a58ee0] non-existing PPS 0 referenced
 [h264 @ 0x1a58ee0] SPS unavailable in decode_picture_timing
 [h264 @ 0x1a58ee0] non-existing PPS 0 referenced
 [h264 @ 0x1a58ee0] decode_slice_header error
 [h264 @ 0x1a58ee0] no frame!
 [h264 @ 0x1a58ee0] SPS unavailable in decode_picture_timing
 [h264 @ 0x1a58ee0] non-existing PPS 0 referenced
 [h264 @ 0x1a58ee0] SPS unavailable in decode_picture_timing
 [h264 @ 0x1a58ee0] non-existing PPS 0 referenced
 [h264 @ 0x1a58ee0] decode_slice_header error
 [h264 @ 0x1a58ee0] no frame!
 [h264 @ 0x1a58ee0] SPS unavailable in decode_picture_timing
 [h264 @ 0x1a58ee0] non-existing PPS 0 referenced
 [h264 @ 0x1a58ee0] SPS unavailable in decode_picture_timing
 [h264 @ 0x1a58ee0] non-existing PPS 0 referenced
 [h264 @ 0x1a58ee0] decode_slice_header error
 [h264 @ 0x1a58ee0] no frame!
 [h264 @ 0x1a58ee0] SPS unavailable in decode_picture_timing
 [h264 @ 0x1a58ee0] non-existing PPS 0 referenced
 [h264 @ 0x1a58ee0] SPS unavailable in decode_picture_timing
 [h264 @ 0x1a58ee0] non-existing PPS 0 referenced
 [h264 @ 0x1a58ee0] decode_slice_header error
 [h264 @ 0x1a58ee0] no frame!
 [h264 @

Re: [FFmpeg-trac] #5799(undetermined:new): Memory psudo-leak when FF_API_CODED_FRAME enabled

2016-08-26 Thread FFmpeg 
#5799: Memory psudo-leak when FF_API_CODED_FRAME enabled
-+-
 Reporter:  DeHackEd |Owner:
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
  Version:  git-master   |  undetermined
 Keywords:   |   Resolution:
 Blocking:   |   Blocked By:
Analyzed by developer:  0|  Reproduced by developer:  0
-+-
Changes (by cehoyos):

 * keywords:  coded_frame leak =>


Comment:

 Please provide the command line that allows to reproduce the issue
 together with the complete, uncut console output to make this a valid
 ticket.

--
Ticket URL: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac

[FFmpeg-trac] #5799(undetermined:new): Memory psudo-leak when FF_API_CODED_FRAME enabled

2016-08-25 Thread FFmpeg 
#5799: Memory psudo-leak when FF_API_CODED_FRAME enabled
-+-
 Reporter:  DeHackEd | Type:  defect
   Status:  new  | Priority:  normal
Component:   |  Version:  git-
  undetermined   |  master
 Keywords:  coded_frame  |   Blocked By:
  leak   |  Reproduced by developer:  0
 Blocking:   |
Analyzed by developer:  0|
-+-
 Summary of the bug:
 How to reproduce:
 {{{
 % ffmpeg -i verylargefile.ts -c:v mpeg2video -c:a ac3 -b:a 384k -muxrate
 4.50M -b:v 3.75M -maxrate:v 3.75M -minrate:v 1.00M -bufsize:v 1000k -flags
 ildct -vf interlace -s 640:480 -f mpegts -map 0:0 -map 0:1
 udp://239.255.255.1:1234
 }}}
 Git version 500662784341373d625af629cad94826beca3bc8 tested

 Valgrind reports the following stack trace consuming memory for each
 frame:
 {{{
 ==19806== 195,744 bytes in 8,156 blocks are still reachable in loss record
 694 of 731
 ==19806==at 0x4A05588: memalign (vg_replace_malloc.c:727)
 ==19806==by 0x4A05623: posix_memalign (vg_replace_malloc.c:876)
 ==19806==by 0xC98A99: av_mallocz (mem.c:97)
 ==19806==by 0xC8A2F9: av_buffer_alloc (buffer.c:48)
 ==19806==by 0xC92195: frame_copy_props (frame.c:636)
 ==19806==by 0x6A2E04: ff_mpv_encode_picture (mpegvideo_enc.c:1738)
 ==19806==by 0x7178EE: avcodec_encode_video2 (utils.c:1961)
 ==19806==by 0x459049: do_video_out (ffmpeg.c:1176)
 ==19806==by 0x459FA0: reap_filters (ffmpeg.c:1367)
 ==19806==by 0x45E59B: main (ffmpeg.c:4114)
 }}}

 The memory allocation will be cleaned up eventually on shutdown --
 valgrind will not report a true memory leak -- but while ffmpeg is running
 memory usage will grow over time. Very long runs (well over 24 hours) will
 consume gigabytes of RAM.

 Editing libavcodec/version.h to force FF_API_CODED_FRAME to 0 appears to
 fix the issue.

--
Ticket URL: 
FFmpeg 
FFmpeg issue tracker
___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-trac