[Ffmpeg-devel-irc] ffmpeg-devel.log.20140427

[burek]

[03:23] <michaelni> ubitux, coverity found an issue in vf_curves.c (1206650)
[03:36] <cone-989> ffmpeg.git 03Michael Niedermayer 07master:6956b048d819: avfilter/vf_drawtext: fix resource leaks
[05:45] <cone-989> ffmpeg.git 03Michael Niedermayer 07master:09b16619d33d: ffmpeg_filter: fix pointer to local outside scope
[05:45] <cone-989> ffmpeg.git 03Michael Niedermayer 07master:bc3234062d08: avcodec/truemotion2: replace impossible condition by av_assert2
[05:45] <cone-989> ffmpeg.git 03Michael Niedermayer 07master:b4329605289e: avcodec/mjpegdec: Fix undefined shift
[05:58] <michaelni> ubitux, also CID1194399 (f_ebur128.c)
[06:01] <jamrial> the ebur128 test has been failing on msvc < 2013 for months now, btw
[11:32] <ubitux> michaelni: ok, will look at it in a moment
[11:53] <cone-415> ffmpeg.git 03Clément BSsch 07master:b2cfd1fde7a2: avfilter/curves: fix resource leaks.
[12:08] <ubitux> michaelni: there is no risk of reading more than one channel in swr with packed sample fmt, right?
[12:08] <ubitux> (i'm asking because i have a double *buf and i'm sending &buf to swr_convert)
[13:07] <michaelni> ubitux, the docs say " @param in        input buffers, only the first one need to be set in case of packed audio" so it would be a bug if it read more
[13:19] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:e20ebe491c17: avcodec/shorten: check bitshift
[13:55] <cone-415> ffmpeg.git 03Carl Eugen Hoyos 07master:ade5851be085: Try mov tags if the fourcc in V_MS/VFW mkv files cannot be found in bmp tags.
[13:55] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:7e7b668ef50c: Merge remote-tracking branch 'cehoyos/master'
[14:36] <cone-415> ffmpeg.git 03goodthanks 07master:c9cfd4583891: avformat/mpegtsenc: Allow DTS audio copy to TS streams
[14:45] <cone-415> ffmpeg.git 03Peter Ross 07master:bdab0c2d7643: avformat/mlvdec: process ff_get_wav_header return value
[14:45] <cone-415> ffmpeg.git 03Peter Ross 07master:9abf08f79fb3: avformat/mlvdec: print unsigned chunk size
[15:01] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:e9ad121ba532: Fix skiping typos
[15:04] <wm4> "skiping" is a typo in itself
[15:05] <wm4> oh I see
[15:05] <wm4> it was a trap!
[15:09] <cone-415> ffmpeg.git 03Carl Eugen Hoyos 07master:4abbea0243ec: lavf/mpeg.h: Remove an unused definition.
[15:09] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:e2a5557cbb7f: Merge remote-tracking branch 'cehoyos/master'
[15:11] <wm4> so... we don't have a float pixel format?
[15:12] <nevcairiel> not that i'm aware
[15:12] <nevcairiel> do you need one?
[15:12] <wm4> there was someone complaining about getting banding when decoding EXR images
[15:12] <wm4> because the decoder converts floats to ints
[15:12] <nevcairiel> i've never seen float image data outside of the GPU really
[15:13] <nevcairiel> into what kind of integer?
[15:13] <nevcairiel> with 16-bit you should probably get enough precision to avoid any kind of banding
[15:13] <wm4> yes, 16 bit
[15:14] <nevcairiel> maybe whatever he uses to view the image just doesn't dither, and rounds to 8-bit for display
[15:14] <nevcairiel> float isn't going to fix that
[15:14] <wm4> that user posted a patch that allows applying gamma to the image
[15:14] <nevcairiel> considering displays are typically 8 bit or tops 10 bit, 16 bit image data is plenty
[15:14] <wm4> so he's probably not totally clueless about this
[15:17] <nevcairiel> i dunno, 16-bit integer should be plenty to do gamma processing after
[15:19] <wm4> well, the floats are half-floats too
[15:19] <wm4> so I think this is more a problem that integers are unsuitable for high dynamic range stuff
[15:19] <nevcairiel> then 16-bit integer even has more precision
[15:20] <nevcairiel> I suppose if all that precision is in rather dark areas, it might be a bit problematic
[15:24] <nevcairiel> if someone wants to introduce floating point RGB... just don't use half-FP, its stupid to handle in C code, expand to full 32-bit FP ("float") :d
[15:28] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:466988ab7536: Fix dont and doesnt typos
[15:28] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:a5e20d9f4d5d: Fix teh typos
[15:28] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:9341e9497b11: Fix overriden typos
[15:28] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:3a5ca79b0c2c: fix bistream typos
[15:28] <nevcairiel> whats with typo-sunday
[15:30] <wm4> -  The bistream buffers no longer need to be explicitly freed.
[15:30] <wm4> +  The bitsream buffers no longer need to be explicitly freed.
[15:30] <wm4> shouldn't it be bitstream
[15:30] <nevcairiel> hehe
[15:30] <nevcairiel> it should
[15:32] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:ef312b8f0f47: Fix bistream typos
[15:33] <wm4> looks ok now
[15:33] <nevcairiel> there is a typo in the commit message, should be "Fix bitsream typos"
[15:33] <nevcairiel> :D
[15:33] <michaelni> darn ;)
[16:37] <cone-415> ffmpeg.git 03Peter Ross 07master:8bd6837e5105: avformat/mlvdec: remove unused MlvContext.buffer
[16:37] <cone-415> ffmpeg.git 03Peter Ross 07master:b3c0d010c3c7: avformat/mlvdec: close any additional .Mxx files
[17:01] <j-b> [tiff @ 0x7fbef8004a00] Color mode 6 is not supported    0B f=0/0 
[17:01] <j-b> Does this ring a bell?
[17:02] <j-b> ah, yeah
[17:02] <j-b> http://trac.ffmpeg.org/ticket/416
[17:10] <wm4> j-b: do people use vlc as image viewer?
[17:10] <j-b> No
[17:11] <j-b> but seriously, creating .tiff images that you can't even open? Good job...
[17:11] <wm4> hah
[17:11] <wm4> better than the other way around
[17:11] <j-b> No.
[17:11] <wm4> (generating files only ffmpeg can handle)
[17:38] <nevcairiel> encoders and decoders are typically entirely separate code =p
[18:10] <ubitux> michaelni: didn't you mean softfloat for exr?
[18:14] <michaelni> softfloat would probably be rather slow
[21:09] <cone-415> ffmpeg.git 03Lukasz Marek 07master:4930e529bfd3: lavd/fbdev_enc: fix not closed handles
[21:09] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:1ca21e1b767a: avcodec/tiff: parse subsample factors
[21:09] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:d03defa778bd: avcodec/tiff: Support yuv 420 and 444
[21:10] <michaelni> j-b, yuv420 tiff ixed
[21:10] <michaelni> Fixed
[22:16] <j-b> michaelni: lol :)
[22:24] <Compn> did i miss a funny ? 
[23:21] <cone-415> ffmpeg.git 03Michael Niedermayer 07master:1fc28cf1644e: avcodec/g729postfilter: avoid potential negative shift
[00:00] --- Mon Apr 28 2014