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

[burek]

[01:33] <cone-414> ffmpeg.git 03Michael Niedermayer 07master:b3f44eafa5a8: avcodec/iff: warn about truncated input to decode_byterun() and clear remaining output
[01:33] <cone-414> ffmpeg.git 03Michael Niedermayer 07master:8fe06e7ae8ff: avformat/nistspheredec: check sscanf() success before using the result
[01:33] <cone-414> ffmpeg.git 03Jan Gerber 07master:200cfab8c4c2: remuxing .opus files to .webm codec->delay must be copied too
[01:33] <cone-414> ffmpeg.git 03Michael Niedermayer 07master:a165964f3c4b: avformat/sierravmd: Check avio_read return value
[13:11] <cone-64> ffmpeg.git 03Diego Biurrun 07master:8558595a5991: configure: Express atomics/thread deps through the dependency system
[13:11] <cone-64> ffmpeg.git 03Michael Niedermayer 07master:3b6e8634c3be: Merge commit '8558595a59913a4667f57d5a4658b1340f1a4354'
[13:18] <cone-64> ffmpeg.git 03Diego Biurrun 07master:e1b9de4fe15c: atomics: cosmetics: Restructure ifdefs for greater clarity
[13:18] <cone-64> ffmpeg.git 03Michael Niedermayer 07master:3f307d79d383: Merge remote-tracking branch 'qatar/master'
[15:32] <ubitux> i have a few h264 stream with 32 reference frames
[15:32] <ubitux> does this sound legit?
[15:32] <ubitux> (ffmpeg has a limit to 16)
[15:33] <Compn> ffmpeg has some bullshit limits
[15:33] <Compn> benchmark when changing limits to make sure it doesnt affect speed and then up it :)
[15:33] <Compn> i'm guessing it affects speed
[15:34] <ubitux> the code might not work at all with >16
[15:34] <Compn> only one way to find out
[15:34] <ubitux> it actually doesn't
[15:35] <Compn> oh ok
[15:35] <Compn> some other software plays such streams ?
[15:35] <Compn> quicktime ?
[15:36] <ubitux> doesn't seem so
[15:36] <kierank> the limit of 16 is in the spec
[15:36] <kierank> but i think there is no bitstream restriction
[15:36] <kierank> ubitux: are you sure it is not 32 reference fields
[15:37] <ubitux> i'm hiting the "too many references" message
[15:37] <ubitux> and sps->ref_frame_count is 32
[15:37] <kierank> where is this stream from
[15:37] <ubitux> encoded with an iphone i'd say but not sure
[15:38] <Compn> does it play and just throws messages ?
[15:38] <cone-64> ffmpeg.git 03Michael Niedermayer 07master:241eccd62898: avcodec/mpegvideo_enc: fix integer overflow with -skip_exp >= 2
[15:38] <cone-64> ffmpeg.git 03Michael Niedermayer 07master:34fe125f4bc8: avcodec/mpegvideo_enc: fix frame skipping with intra only codecs
[15:39] <ubitux> Compn: it can not be played; if i naively change the limit it decodes shit
[15:40] <Compn> so its either custom thing requiring a binary codec or its broken
[15:58] <ubitux> well probably a bug in the ios encoder
[15:58] <ubitux> can't find anything though
[16:11] <Compn> ubitux : did he use some 3rd party video capture app ?
[16:11] <Compn> did he rip it off his iphone with a 3rd party app ?
[16:43] <ubitux> Compn: 3rd party iphone app using the hw h264 encoder
[16:45] <Compn> yeah , that 3rd party app is doing it wrong
[16:46] <Compn> might be able to make a bsf to make the stream conform
[16:46] <Compn> if its not totally borken
[16:46] <ubitux> how can you be sure it's the 3rd party app?
[16:46] <ubitux> most of the video out of it are playable
[16:47] <ubitux> but once in a while, the encoder shits an unplayable brick
[16:48] <Compn> what country is 3rd party app made in ?
[16:48] <ubitux> not india
[16:48] <Compn> china ?
[16:48] <ubitux> no
[16:48] <Compn> how can i be sure? because iphones have millions of users , and they dont shit bricks
[16:48] <Compn> but 3rd party does
[16:49] <ubitux> well, some particular parameters might trigger the issue
[16:49] <ubitux> dunno
[16:50] <Compn> always blame the user
[17:13] <ubitux> the checks makes no sense btw
[17:13] <ubitux>     if (sps->ref_frame_count > MAX_PICTURE_COUNT - 2 ||
[17:13] <ubitux>         sps->ref_frame_count > 16U) {
[18:21] <cone-64> ffmpeg.git 03Michael Niedermayer 07master:632fdec9f4eb: avformat/nistspheredec: initialize header_size to -1
[18:52] <saste> what happened to hue=s=0?
[18:52] <cone-64> ffmpeg.git 03Michael Niedermayer 07master:b07a5e9b6be9: avformat/smacker: check for format mismatch more completely
[19:26] <cone-64> ffmpeg.git 03Stefano Sabatini 07master:70e74e007270: lavfi/hue: force table initialization for the first frame
[19:26] <cone-64> ffmpeg.git 03Stefano Sabatini 07master:028d8dd367f7: lavfi/hue: use av_clip_uint8() instead of av_clip_uint8_c()
[19:26] <cone-64> ffmpeg.git 03Stefano Sabatini 07master:d055a1395c23: lavfi/hue: show first decimal value of saturation
[23:11] <cone-64> ffmpeg.git 03Michael Niedermayer 07master:5ec3c7b7c118: avformat/pva: Make sure the first byte of pes_header_data has been initialized
[23:11] <cone-64> ffmpeg.git 03Michael Niedermayer 07master:eedd9148733f: avformat/pva: Make sure the header is large enough before reading the timestamp from it
[23:34] <cone-64> ffmpeg.git 03Mason Carter 07master:832e19063209: vc1: arm: Add NEON assembly
[23:34] <cone-64> ffmpeg.git 03Michael Niedermayer 07master:69278d94c482: Merge commit '832e19063209a5f355af733d1a45f5051f49ce33'
[23:42] <cone-64> ffmpeg.git 03Mason Carter 07master:b254490bdabb: vc1: arm: Add NEON no_rnd chroma MC
[23:42] <cone-64> ffmpeg.git 03Michael Niedermayer 07master:4fa91b88c618: Merge commit 'b254490bdabb21bd517c05b1a68717f9952ac8c4'
[23:51] <cone-64> ffmpeg.git 03Anton Khirnov 07master:dfc50ac85e9d: x86: mpegvideo: move denoise_dct asm to mpegvideoenc
[23:51] <cone-64> ffmpeg.git 03Michael Niedermayer 07master:ce612fc18638: Merge commit 'dfc50ac85e9d68a771b556297b7c411650206f3b'
[23:57] <cone-64> ffmpeg.git 03Luca Barbato 07master:027712e851da: jvdec: Return EOF on end of file
[23:57] <cone-64> ffmpeg.git 03Michael Niedermayer 07master:d2344afb90db: Merge commit '027712e851da4d124a842c9e2802f95d50582553'
[00:00] --- Sat Dec 21 2013