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

[burek]

[00:16] <Compn> >I don't think lavfi should be remove.
[00:16] <Compn> liaaaarrrrrrrrr
[00:17] <Compn> :P
[00:34] <ubitux> haha Compn :)
[02:16] <cone-223> ffmpeg.git 3Michael Niedermayer adcfc0535db8 7libavformat/mxfenc.c: mxfenc: fix av_log data type for dts paramater
[02:16] <cone-223> ffmpeg.git 3Michael Niedermayer fc6860a3ebae 7libavcodec/8svx.c: 8svx: remove unused variable
[02:16] <cone-223> ffmpeg.git 3Michael Niedermayer 106790a4e92f 7libavcodec/ffv1.c: ffv1: fix array data types
[03:18] <cone-223> ffmpeg.git 3Michael Niedermayer bd2613a32205 7libavcodec/rangecoder.c: rangecoder: fix "incompatible pointer type" warning
[03:18] <cone-223> ffmpeg.git 3Michael Niedermayer c5fdd0696ab5 7libavcodec/tiff.c: tiff: fix "assignment discards qualifiers from pointer target type" warning
[03:18] <cone-223> ffmpeg.git 3Michael Niedermayer b9a77198280f 7libavcodec/tscc.c: tscc: fix "assignment discards qualifiers from pointer target type" warning
[03:18] <cone-223> ffmpeg.git 3Michael Niedermayer 89074e9066d1 7libavcodec/wmalosslessdec.c: wmalosslessdec: remove unused variable
[05:32] <cone-223> ffmpeg.git 3Michael Niedermayer 43bbc3f477a2 7libavutil/xtea.c: xtea: give constants the correct type
[05:32] <cone-223> ffmpeg.git 3Michael Niedermayer f464b02d2214 7libavformat/mpegts.c: mpegts: fuzzy crc check for not so spec compliant files
[05:45] <cone-223> ffmpeg.git 3Pavel Koshevoy 9425dc3dba0b 7libavcodec/ppc/fmtconvert_altivec.c: Fix build failure on osx 10.5.8 ppc
[09:07] <cone-907> ffmpeg.git 3Clément BSsch f7c46d251c9a 7ffmpeg_opt.c libavformat/ffm.h libavformat/ffmenc.c: ffserver: fix seeking with ?date=...
[11:04] <cone-907> ffmpeg.git 3Clément BSsch 208a5d132282 7tests/Makefile tests/ref/fate/ffprobe_compact tests/ref/fate/ffprobe_csv tests/ref/fate/ffprobe_default tests/ref/fate/ffprobe_flat tests/ref/fate/ffprobe_ini tests/ref/fate/ffprobe_json tests/ref/fate/ffprobe_xml tests/test.ffmeta: fate/ffprobe: add some stream metadata.
[11:05] <ubitux> isn't the bot supposed to trim the affected files?
[11:06] <ubitux> would be nice to have an url to the git with a shortened hash too
[11:13] <cone-907> ffmpeg.git 3Paul B Mahol d7a473926504 7Changelog configure doc/general.texi libavcodec/Makefile libavcodec/allcodecs.c libavcodec/avcodec.h libavcodec/codec_desc.c libavcodec/tak.c libavcodec/tak.h libavcodec/tak_parser.c libavcodec/takdec.c libavcodec/version.h libavformat/Makefile libavformat/allformats.c libavformat/takdec.c libavformat/version.h tests/fate/lossless-audio.mak tests/ref/fate/lossless-tak: TAK demuxer, decoder and parser
[11:20] <ubitux> :)
[11:20] <durandal_1707> j-b: libav is switching decoders/encoders to planar audio sample formats so some sunny day VLC will fail to play anything remotely useful
[11:21] <j-b> durandal_1707: is there any actual use of using planar?
[11:22] <ubitux> simpler decoders, easier filtering sometimes?
[11:22] <durandal_1707> j-b: each decoder do not need to interleave stuff on its own....
[11:23] <j-b> ok. Still playback needs interleaving
[11:23] <j-b> durandal_1707: I guess we'll just reinterleave it
[11:25] <j-b> durandal_1707: all APIs decode_ do that
[11:25] <j-b> durandal_1707: all APIs decode_ do that?
[11:27] <durandal_1707> j-b: ???
[11:28] <j-b> durandal_1707: avcodec_decode_audio3, avcodec_decode_audio4, avcodec_decode_audio5, avcodec_decode_audio6 or whatever the new name is?
[11:29] <durandal_1707> j-b: no, it is decoder specific, it it sets SAMPLE_FORMAT_U8P/S16P/S32P ...
[11:30] <j-b> durandal_1707: ok. So I need to block to a version before that, right?
[11:32] <durandal_1707> version of what?
[11:34] <j-b> of libavcodec
[11:35] <durandal_1707> j-b: such sample formats are introduced long before coders started to use them....
[12:08] <nevcairiel> alac decoder already does it today
[13:21] <cone-907> ffmpeg.git 3Martin Storsjö e67b0f99520e 7libavformat/gxf.c: gxf: Include the right header for the avpriv_frame_rate_tab declaration
[13:21] <cone-907> ffmpeg.git 3Diego Biurrun 62ae37decde7 7libavdevice/timefilter.c: timefilter: De-doxygenize normal code comments and drop silly ones
[13:21] <cone-907> ffmpeg.git 3Justin Ruggles 5364327186fb 7libavcodec/adpcmenc.c: adpcmenc: ensure calls to adpcm_ima_compress_sample() are in the right order
[13:21] <cone-907> ffmpeg.git 3Justin Ruggles 37f701f1c396 7libavcodec/utils.c: avcodec: allow either planar or interleaved sample format when encoding mono
[13:21] <cone-907> ffmpeg.git 3Justin Ruggles 7b556be67353 7libavfilter/af_resample.c: af_resample: avoid conversion of identical sample formats for 1 channel
[13:21] <cone-907> ffmpeg.git 3Michael Niedermayer 43c157f4a46c 7: Merge remote-tracking branch 'qatar/master'
[13:23] <divVerent> s/deoxygenize/deoxydize/; s/deoxydize/reduce/ ;)
[13:37] <thresh> hello
[13:40] <cone-907> ffmpeg.git 3Paul B Mahol 7d7a473926504: TAK demuxer, decoder and parser * 3http://tinyurl.com/9fqd8ex3
[13:40] <thresh> ubitux: ^^
[13:42] <ubitux> thresh: why tinyrul?
[13:42] <ubitux> you could make a source.ffmpeg.org url
[13:43] <ubitux> with a trimed hash
[13:43] <thresh> wouldnt that be longer?
[13:43] <ubitux> does it really matter?
[13:43] <thresh> well, I used what's already available in irker without modifying it
[13:43] <ubitux> i'm not very fond of the tinyurl thing :(
[13:43] <ubitux> isn't it configurable?
[13:47] <TimNich> you can make your own tinyurl if you want
[13:49] <thresh> ubitux: looks like it isnt
[13:50] <ubitux> :/
[13:51] <thresh> let me try updating just in case
[14:05] <thresh> suggestions on colorscheme are also welcomed, btw
[14:05] <ubitux> colors are fine imo
[14:07] <thresh> ...and last test
[14:08] <cone-907> ffmpeg.git 3Paul B Mahol 7d7a473926504: TAK demuxer, decoder and parser * 3http://tinyurl.com/9fqd8ex3
[14:10] <ubitux> looks like it won't be the last
[14:11] <nevcairiel> personally i prefer bit.ly for shortening, its just shorter then tinyurl :P
[14:12] <thresh> please send patches to irker upstream :)
[14:13] <ubitux> i don't think it's worth shortening these urls
[14:14] <nevcairiel> also, the standard short-hash form is 7 chars. ;)
[16:04] <ubitux> michaelni: one of the main other races raised by helgrind is ff_h264_decode_mb_cabac writing a lot of stuff on the AVFrame s->current_picture.f
[16:04] <ubitux> do you see any simple fix for this?
[16:06] <ubitux> same in lavc/h264_pred.h:decode_mb_skip
[16:06] <ubitux> it seems there are a lot of write around this
[16:07] <ubitux> and since it's touching the private data, it leads to races
[16:48] <thresh> the 12 vs. 7 thing will be sorted soon-ish, irker upstream says
[16:48] <thresh> also, they'll fix the short hash generation in the commit links
[16:49] <thresh> so once they do that, I'll update videolan instance, and it'd be set to do just what you wanted
[17:10] <ubitux> thresh: thank you :)
[17:53] <divVerent> what am I doing wrong with libswscale
[17:53] <divVerent> when after converting yuv444p to yuv420, the chroma plane changes like this:
[17:53] <divVerent> http://rm.sudo.rm-f.org/img/uploaded/081e22f10498dbb69456b2a41eaf667a.png
[17:53] <ubitux> saste: i grep'ed all over my irc logs and couldn't find where you linked to the metadata in bufferref :(
[17:53] <divVerent> I fwrote() out the u plane right before and after calling into swscale...
[17:54] <divVerent> it's the fast bilinear resampler, BTW
[17:54] <divVerent> does the resampler even matter when not changing the size?
[17:56] <divVerent> also, what resampler SHOULD I be using
[17:56] <divVerent> when I convert yv12 to yuv444p, then want to screw with non subsampled chroma, then convert back to yv12?
[17:56] <divVerent> I want the yv12 -> yuv444p -> yv12 conversion to not change chroma at all when I do no changes in between
[17:57] <divVerent> nearest is no option, because that handles the pixels wrong that I did change
[17:57] <saste> ubitux: https://github.com/kuehnelth/libav/commits/geotiff-encoder
[17:57] <ubitux> oh i saw that link, but not the metadata thing
[17:58] <saste> ubitux: https://github.com/kuehnelth/libav/commit/b8e9baf7f93c1b8e6c9e897dbb23393e25e51a93
[17:58] <ubitux> yeah i saw it now :)
[17:58] <ubitux> i just looked at the url first :p
[17:59] <ubitux> saste: btw do you mind to dig a bit about the -help full formating patch? :x
[18:00] <saste> ubitux: i can already remove the "-" prefix
[18:00] <saste> other formatting can go into separate commits
[18:00] <ubitux> "lavfi: Keep frame-based metadata." "a year ago"  has it been submitted?
[18:00] <ubitux> saste: sure
[18:01] <saste> ubitux, never
[18:01] <ubitux> mmh.
[18:01] <saste> so it will need some rebasing, but seems ok overall
[18:01] <ubitux> no activity since a long while
[18:02] <ubitux> i'll try to pick it and make something out of it, eventually.
[18:02] <saste> i contacted the author, and he wrote that he has no time
[18:02] <ubitux> ok
[18:56] <michaelni> divVerent, are you downscaling something ? fast bilinear is just for upscaling
[19:15] <ubitux> saste: any idea what kind of convention we should follow in filter's metadata for the keys?
[19:15] <ubitux> like "<filtername>.<keyname>"
[19:15] <ubitux> "filter.<filtername>.<keyname>"
[19:15] <ubitux> "filter.<keyname>"
[19:15] <ubitux> ?
[19:15] <saste> ubitux: that's a good question
[19:15] <saste> also how can we avoid to meddle with external metadata?
[19:16] <saste> i suppose there is no way
[19:16] <ubitux> maybe we could write a function taking a AVFilter and key
[19:16] <saste> we could even think about keeping two different metadata dictionaries
[19:16] <saste> but i'm not sure i like it
[19:17] <ubitux> well maybe the AVDictionary can have a signature or something
[19:17] <saste> a meta-meta tag
[19:17] <ubitux> :D
[19:17] <saste> or just keep two different dictionary for the moment
[19:17] <ubitux> well we can just add a const char *id in the AVDictionary
[19:17] <saste> *dictionaries
[19:18] <ubitux> ah but i'm stupid it will require multiple dict
[19:18] <ubitux> then in the entry.
[19:18] <saste> multiple dictionaries could be an idea
[19:18] <ubitux> well it's a pain
[19:18] <saste> so you have metadata_dicts
[19:19] <saste> but yes it could be a pain
[19:19] <ubitux> looks overkill
[19:20] <ubitux> i'll go for "lavfi.<keyname>"
[19:20] <saste> X-Lavfi/foo=bar
[19:20] <ubitux> key="X-Lavfi/foo" ?
[19:20] <saste> yes, keep it simple for the moment
[19:20] <saste> doesn't solve the (theoretical) namespace conflict
[19:21] <saste> since you don't know what the user may write in the metadata
[19:21] <ubitux> i'll kill the first user who will want to put a key named "lavfi.silence_start" in the metadata of his file
[19:21] <ubitux> and anyway, it's a frame-level meta
[19:21] <ubitux> shouldn't even reach the file metadata
[19:21] <iive> don't forget filters could be inserted multiple times
[19:22] <iive> you need something to identify them uniquely 
[19:22] <saste> and the user may want to export the created tags (in the encoded file)
[19:22] <saste> so a simple solution may consist into having - for the moment - two dictionaries
[19:23] <ubitux> iive: it's a pain to extract in the common cases if you do that
[19:24] <iive> ubitux: hum? 
[19:24] <saste> in other words, at some point you have to decide if to put the metadata back to the file, or to drop it
[19:24] <saste> also, i think it would be useful to be able to *specify* a filter instance name
[19:24] <ubitux> iive: if you have a meta key like "filter.<random>.silence_start" if the user want to extract the value, it's harder than just av_get_dict("lavfi.silence_start")
[19:25] <saste> so you don't have to rely on the somehow unpredictable auto-assigned name
[19:25] <ubitux> mmh
[19:25] <saste> something like silencedetect/first_one=..., silencedetect/second_one=...
[19:26] <ubitux> well i think we need a simple injection first
[19:26] <ubitux> we'll try to overthink it after :p
[19:26] <saste> at that point you can tell (globally?) to the internal filters to always use a custom prefix for metadata entries, like X-Lavfi/...
[19:26] <saste> which is then discarded by the buffersink
[19:26] <saste> ubitux, yes get it working, get it correct, get it fast
[19:27] <saste> in this order ;-)
[19:27] <durandal_1707> are here any lavfi experts?
[19:28] <ubitux> eeeh we don't have a lavfi/utils.c :(
[19:29] <saste> durandal_1707, what's the problem?
[19:32] <durandal_1707> saste: i get segv in lavfi when samplerate changes midstream
[19:33] <saste> durandal_1707, yes you filed a ticket, right?
[19:33] <durandal_1707> yes
[19:33] <saste> i believed it was supported, but I may be wrong
[19:34] <saste> at least at some point we had "normalization" in the buffer source
[19:34] <saste> now i don't know how it is handled
[19:43] <cone-907> ffmpeg.git 3Anton Khirnov 778071a1420b4: pixfmt: add AV_ prefixes to PIX_FMT_* * 3http://tinyurl.com/98goofl3
[19:43] <cone-907> ffmpeg.git 3Michael Niedermayer 7ae77266fce26: Merge commit '78071a1420b425dfb787ac739048f523007b8139' * 3http://tinyurl.com/9g7dyrc3
[20:05] <ubitux> !
[20:05] <ubitux> oh it's the typo in old_pix_fmt.h
[20:05] <ubitux> michaelni: fate is gonna get red if you don't merge the typo fix :p
[20:07] <Daemon404> red is for rage
[20:07] <Daemon404> FATE SMASH
[20:07] <ubitux> :D
[20:17] <cone-907> ffmpeg.git 3Anton Khirnov 789715a3cf187: lavu: fix typo in Makefile * 3http://tinyurl.com/97fta693
[20:18] <ubitux> :)
[20:21] Action: beastd starts fate client again
[20:21] <Daemon404> i am still waiting for baptiste to approve my key
[20:21] <Daemon404> :V
[20:22] <ubitux> saste: any idea why avfilter_copy_buf_props() is never called with a classic ffprobe -f lavfi -i amovie=... -show_frames?
[20:23] <saste> ubitux, uhm... no
[20:23] <ubitux> ffmpeg -f lavfi -i amovie=... -f null - calls it correctly
[20:23] <ubitux> but ffprobe never
[20:23] <ubitux> i wonder how that's supposed to happen
[21:19] <cone-907> ffmpeg.git 3Anton Khirnov 7716d413c1398: Replace PIX_FMT_* -> AV_PIX_FMT_*, PixelFormat -> AVPixelFormat * 3http://tinyurl.com/95kjza43
[21:19] <cone-907> ffmpeg.git 3Michael Niedermayer 7ac627b3d38d3: Merge commit '716d413c13981da15323c7a3821860536eefdbbb' * 3http://tinyurl.com/8mbx7en3
[21:20] <nevcairiel> why are some hashes pink? :d
[21:21] <iive> i think that these that start with number are pink
[21:21] <nevcairiel> wut
[21:22] <Daemon404> no
[21:22] <Daemon404> i think it's if they are part of merges
[21:22] <iive> indeed, i'm wrong.
[21:22] <nevcairiel> and grey?
[21:22] <nevcairiel> :D
[21:32] <thresh> color change looks like a bug to me
[22:03] <cone-907> ffmpeg.git 3Anton Khirnov 78728b958ff1b: lavu: fix typo in Makefile * 3http://tinyurl.com/9htqjhw3
[22:03] <cone-907> ffmpeg.git 3Luca Barbato 70826d8513d14: segment: drop global headers setting * 3http://tinyurl.com/99pxe3p3
[22:03] <cone-907> ffmpeg.git 3Luca Barbato 7175d0d94da11: doc: initial nut documentation * 3http://tinyurl.com/8duknz53
[22:03] <cone-907> ffmpeg.git 3Luca Barbato 791f5f8756168: doc: remove a warning from filters.texi * 3http://tinyurl.com/9jgs9aq3
[22:03] <cone-907> ffmpeg.git 3Luca Barbato 7d19d01bf6281: doc: support the new website layout * 3http://tinyurl.com/8vgljly3
[22:03] <cone-907> ffmpeg.git 3Janne Grunau 7f101eab1be1a: x86: call most of the x86 dsp init functions under if (ARCH_X86) * 3http://tinyurl.com/8f728pk3
[22:03] <cone-907> ffmpeg.git 3Janne Grunau 7cb36febcbc59: x86: cavs: call ff_cavsdsp_init_x86() under if (ARCH_X86) * 3http://tinyurl.com/9kj7dhx3
[22:03] <cone-907> ffmpeg.git 3Janne Grunau 77e522859fc46: x86: vc1: call ff_vc1dsp_init_x86() under if (ARCH_X86) * 3http://tinyurl.com/8rx3lrv3
[22:03] <cone-907> ffmpeg.git 3Michael Niedermayer 752dc18d414f4: Merge remote-tracking branch 'qatar/master' * 3http://tinyurl.com/9hj6ewk3
[22:06] <llogan> saste: is there something obvious i missed when testing flite in ubuntu 12.04?
[22:06] <saste> llogan, no i realized what the problem was
[22:07] <saste> the guy told that he compiled a local static library
[22:07] <saste> if you have a dynamic lib, it is not required to specify the -lasound flag
[22:07] <saste> so this explains the failure
[22:07] <saste> the failure should be reproducible, with a static build of libflite
[22:08] <saste> i'm gonna to try that later if i find the time, and push it
[22:10] <Daemon404> google doesnt do a good job and telling me where to find libflite
[22:10] <Daemon404> the 3rd result is ffmpeg...
[22:11] <llogan> did you find it? http://www.speech.cs.cmu.edu/flite/download.html
[22:11] <Daemon404> yes
[22:11] <Daemon404> libflite -> flite
[22:12] <llogan> flite reminds me of a prank call to a friend telling him to report to work at Taco Bell at 7 am.
[22:21] <llogan> maybe i shouldn't have been sitting on my ass so long on that new site design...
[22:24] <saste> llogan, customizable skin?
[23:23] <ubitux> saste: i think i get it
[23:24] <ubitux> ffmpeg is always using avfilter to get buffers; those buffer have props, which are copied to a local AVFrame etc
[23:24] <ubitux> ffprobe is just getting a AVFrame directly from the lavfi device
[23:24] <ubitux> i think the lavfi device should set the meta
[23:26] <ubitux> mmh i'm missing a step.
[23:57] <ubitux> saste: it doesn't look simple to do the bufref->metadata to avpacket to avframe :p
[23:57] <ubitux> (in case of lavfi input device)
[23:57] <ubitux> (which looks like the only way to make ffprobe communicated with lavfi)
[23:57] <ubitux> :(
[23:58] <saste> ubitux, what's the problem?
[23:58] <ubitux> lavd/lavfi fills AVPackets
[23:58] <ubitux> so at that point
[23:58] <ubitux> how do you get the metadata from the bufferref
[23:58] <ubitux> up to the avframe?
[23:59] <saste> you need to copy that
[23:59] <ubitux> where?
[23:59] <saste> in the buffersink i suppose
[23:59] <ubitux> i'm not sure how that will help
[00:00] --- Tue Oct  9 2012