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

[burek]

[00:42] <cone-737> ffmpeg.git 03Paul B Mahol 07master:e1c7892013d2: avcodec/vp9: use av_freep() for above_partition_ctx
[02:07] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:e3fc4481b6dd: avformat/vqf: check a few more bits in probe
[02:07] <cone-737> ffmpeg.git 03Ben Boeckel 07master:255302da7019: vorbis: handle special packets in the middle of a stream
[08:13] <HzD_Byte> ehlo
[11:32] <cone-80> ffmpeg.git 03Stefano Sabatini 07master:fe55c3197698: lavc/elbg: rename ff_ symbols to avpriv_, so they can be used in shared libs
[11:32] <cone-80> ffmpeg.git 03Stefano Sabatini 07master:8cd3685a3ff8: lavfi: add elbg filter
[11:40] <cone-80> ffmpeg.git 03Lukasz Marek 07master:f04fe23a5256: lavd/xv: fix memory leak
[11:41] <ubitux> saste: wow, it's slow :)
[11:42] <saste> ubitux, yes, i use it with elbg=l=8
[11:42] <saste> ubitux, considering that it is computing the "palette" at each step
[11:43] <saste> that is for each image
[11:50] <ubitux> saste: why isn't this the default when encoding to PAL8? :)
[12:01] <ubitux> saste: also, why isn't the filter outputing optimized PAL8?
[12:02] <saste> ubitux, you don't have a fixed palette
[12:02] <saste> so you would have to send a new palette for each frame
[12:02] <saste> not very efficient
[12:02] <ubitux> isn't PAL8 supposed to be a map in data[0] and pal in data[1]?
[12:02] <ubitux> saste: not very efficient, but a way to get HD GIF
[12:02] <saste> it would be cool to be able to extract and apply a user provided palette
[12:03] <saste> ubitux, patch welcome :)
[12:03] <ubitux> saste: i'm just wondering about the usefulness of the filter :p
[12:03] <ubitux> in its current state
[12:04] <saste> useful if you don't like images with too many colors, i suppose :)
[14:23] <saste> michaelni, ok to remove soc.txt?
[14:26] <michaelni> saste, sure
[14:30] <cone-80> ffmpeg.git 03Timothy Gu 07master:1062a7f40428: doc: remove soc.txt
[14:33] <michaelni> ubitux, probetest says: Failure of jacosub probing code with score=51 type=1 p=CAB size=16
[14:34] <michaelni> thats  tools/probetest 8192 500000
[14:43] <ubitux> michaelni: mmh i'll try not to forget
[14:43] <ubitux> i cant look at it right now
[14:43] <ubitux> and btw, thx for fateserver mirror
[15:04] <Compn> who would i contact about xvid gpl violations ?
[15:04] <Compn> squatters on xvid.org ?
[15:07] <Daemon404> xvid.org really is them
[15:07] <Daemon404> :/
[15:08] <Compn> it looks bad
[15:08] <Daemon404> its been like that for ages
[15:08] <Daemon404> xvid is long dead
[15:09] <Compn> who thought an inline search box on a website was a good idea ? 
[15:09] <Compn> like the first guy who came up with that idea
[15:09] <Daemon404> it's babby's first php site
[15:09] Action: Compn afraid to view source and find microsoft frontpage
[15:10] <Daemon404> lol
[15:10] <saste> TYPO3
[15:10] <saste> Compn, why do you care?
[15:11] <ubitux> sometimes easier to browse reading the source
[15:12] <saste> yes like in matrix
[15:12] <Daemon404> also the real cool kids used ms word to make websites
[15:12] <Compn> saste : care about gpl violations or care about their website ?
[16:28] <kierank> 2:14 PM <BugMaster|work> elenril: btw. remember I said about that libav drop first frames after recovery points in H.264. I was wrong. I tested it again few days ago and libav's avconv works exactly as expected producing same output as JM. On other hand ffmpeg fails big at this aspect (it show freezed frame for long period of time far beyond when
[16:28] <kierank> intra-refresh should be already finished. and show artefacts in case of output_corrupt flag at frames where it shouldn't) e
[16:28] <kierank> 2:15 PM <BugMaster|work> * even though it looks like to backport most of libav's patches to h264
[16:28] <kierank> michaelni: ^
[16:35] <michaelni> kierank, how can i reproduce that ?
[16:36] <kierank> ask bugmaster
[17:23] <wm4> have the mp3 probing problems been solved yet?
[17:23] <wm4> there are some mp3 (and also some mpeg) files that fail at probing with a high enough probescore
[17:36] <durandal11707> wm4: uploaded them to someone?
[17:39] <wm4> durandal11707: user handed me this: http://www1.datafilehost.com/d/eeb3e07c
[18:10] <wm4> durandal11707: can you reproduce?
[18:11] <wm4> (I can)
[18:19] <durandal11707> wm4: i'm doing something else, please do not be afraid of creating bug report
[18:34] <cone-874> ffmpeg.git 03Michael Niedermayer 07master:7561974dfee0: avformat/mmst: propagate error code from avio_put_str16le()
[19:24] <cone-874> ffmpeg.git 03Michael Niedermayer 07master:b52ae27edf39: avio_put_str16le: Print error message in case of invalid UTF8 input
[19:24] <cone-874> ffmpeg.git 03Michael Niedermayer 07master:269f5d902abf: avformat/aviobuf: return error from avio_put_str16le() for invalid input
[22:24] <cone-256> ffmpeg.git 03Michael Niedermayer 07master:9647c6deddfa: ffmpeg_opt: fix overriding values set by -target
[22:34] <ruggles> hi all. just wanted to point out a weird corner-case issue that is happening for ffmpeg with multi-threaded audio decoding.
[22:35] <ruggles> if the decoder outputs a valid frame (*got_frame = 1, ret = 0) with no data (nb_samples = 0) it can lead to an infinite loop (EAGAIN) in some cases due to not flushing buffersrc.
[22:36] <ruggles> that situation shouldn't happen in normal cases, but an alac decoder bug was triggering it with corrupt data
[22:36] <ruggles> i sent a patch to libav with the alac fix, but more generally that situation may need to be handled at a higher level
[22:50] <Compn> interesting
[22:52] <ruggles> it also depends on which filters are used and how many decoding threads. so it's a tricky bug. but it's definitely triggered by the empty frames, maybe in combination with something else.
[22:53] <ruggles> and it leads to infinite EAGAIN from avfilter_graph_request_oldest()
[23:05] <cone-256> ffmpeg.git 03Michael Niedermayer 07master:4abe6e415310: avformat/nullenc: mark null as VFPS
[00:00] --- Thu Nov 14 2013