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

[burek]

[01:46] <CIA-18> ffmpeg: 03Nicolas George 07master * rada8d485c0 10ffmpeg/libavutil/audioconvert.c: 
[01:46] <CIA-18> ffmpeg: audioconvert: prefer 5.X over 5.X(side).
[01:46] <CIA-18> ffmpeg: This is the logical consequence of commit ab539d9e:
[01:46] <CIA-18> ffmpeg: 5.X(back) is more common than 5.X(side).
[01:46] <CIA-18> ffmpeg: Signed-off-by: Nicolas George <nicolas.george at normalesup.org>
[01:46] <CIA-18> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:15] <teratorn> given an AVInputFormat how can I get a corresponding AVOutputFormat for the same format?
[03:17] <CIA-18> ffmpeg: 03Kostya Shishkov 07master * r0e288b8c52 10ffmpeg/libavcodec/avcodec.h: 
[03:17] <CIA-18> ffmpeg: deprecate codec IDs that won't ever be used
[03:17] <CIA-18> ffmpeg: Signed-off-by: Anton Khirnov <anton at khirnov.net>
[03:18] <CIA-18> ffmpeg: 03Loren Merritt 07master * r2f7f2e4b41 10ffmpeg/libavutil/x86/x86inc.asm: 
[03:18] <CIA-18> ffmpeg: Update x86inc.asm to latest x264 version, and add AVX symmetry.
[03:18] <CIA-18> ffmpeg: We keep INIT_AVX (for backwards compatibility). 3arg AVX ops with
[03:18] <CIA-18> ffmpeg: a memory arg can only have it in src2, whereas SSE emulation of
[03:18] <CIA-18> ffmpeg: 3arg prefers to have it in src1 (i.e. the mov). So, if the op is
[03:18] <CIA-18> ffmpeg: symmetric and the wrong one is memory, swap them.
[03:18] <CIA-18> ffmpeg: 03Luca Barbato 07master * r07b172fe8f 10ffmpeg/ (doc/APIchanges libavutil/avstring.h libavutil/avutil.h): 
[03:18] <CIA-18> ffmpeg: avstring: Add locale independent implementations of toupper/tolower
[03:18] <CIA-18> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[03:18] <CIA-18> ffmpeg: 03Kostya Shishkov 07master * r19900d60fd 10ffmpeg/libavcodec/avcodec.h: 
[03:18] <CIA-18> ffmpeg: move 8SVX audio codecs to the audio codec list part on the next bump
[03:18] <CIA-18> ffmpeg: Signed-off-by: Anton Khirnov <anton at khirnov.net>
[03:18] <CIA-18> ffmpeg: 03Ronald S. Bultje 07master * rc435653627 10ffmpeg/libswscale/x86/ (scale.asm swscale_mmx.c swscale_template.c): swscale: write yuv2plane1 MMX/SSE2/SSE4/AVX functions.
[03:18] <CIA-18> ffmpeg: 03Reimar Döffinger 07master * rba04ecfdac 10ffmpeg/ (4 files in 2 dirs): 
[03:18] <CIA-18> ffmpeg: avstring: Add locale independent implementations of strcasecmp/strncasecmp
[03:18] <CIA-18> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[03:18] <CIA-18> ffmpeg: 03Reimar Döffinger 07master * rbb3244dee2 10ffmpeg/ (14 files in 4 dirs): (log message trimmed)
[03:18] <CIA-18> ffmpeg: Replace all usage of strcasecmp/strncasecmp
[03:18] <CIA-18> ffmpeg: All current usages of it are incompatible with localization.
[03:19] <CIA-18> ffmpeg: For example strcasecmp("i", "I") != 0 is possible, but would
[03:19] <CIA-18> ffmpeg: break many of the places where it is used.
[03:19] <CIA-18> ffmpeg: Instead use our own implementations that always treat the data
[03:19] <CIA-18> ffmpeg: as ASCII.
[03:19] <CIA-18> ffmpeg: 03Martin Storsjö 07master * r3607ed70d5 10ffmpeg/ (7 files in 3 dirs): 
[03:19] <CIA-18> ffmpeg: Remove leftover includes of strings.h
[03:19] <CIA-18> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[03:19] <CIA-18> ffmpeg: 03Martin Storsjö 07master * r2461284630 10ffmpeg/libavformat/network.c: (log message trimmed)
[03:19] <CIA-18> ffmpeg: openssl: Only use CRYPTO_set_id_callback on OpenSSL < 1.0.0
[03:19] <CIA-18> ffmpeg: Since 1.0.0, this function is deprecated. A new function,
[03:19] <CIA-18> ffmpeg: CRYPTO_THREADID_set_callback is available, but if not set at all,
[03:20] <CIA-18> ffmpeg: it uses the address of errno as thread id, which should be
[03:20] <CIA-18> (35 lines omitted)
[03:41] <Zeranoe> This patch: http://git.videolan.org/?p=ffmpeg.git;a=commit;h=7b7b220cf709f193e5e79b5fc83b51196aab7cf6 inaccurately disables pthread even if it is found and uses w32thread instead, based off of the target os. I feel a check for pthread should always be made first, and if it is NOT found, then use w32thread only if the target os is mingw32. anyone have any thoughts for this?
[03:51] <Compn> i thought it was done on purpose, but i'm not paying attention
[03:51] <Compn> michaelni : ping
[03:56] <Zeranoe> I believe it does, but i don't think its wise to disable pthread simply because a target os of mingw32 is detected, I use pthread and a target os of mingw32. Just my thoughts though, i'm open to other ideas
[03:58] <michaelni> what are the advantages / disadvantages of the 2 on mingw ?
[04:00] <michaelni> also martin (wbs), whos commit this is, is in here, would be interresting to hear his oppinon as well
[04:02] <Zeranoe> I myself believe pthread to be more stable. I don't think w32threads needs to be removed, I just don't think that making it the default because of the target_os being mingw32 is needed. I would rather not have to --disable-w32threads. I think a check for pthreads first, if pthread is found then use it, if it isn't found then check for mingw32 as the target_os and if so then enable w32thread.
[04:04] <Zeranoe> I see no downsides to doing it that way, if a windows user is trying to compile without pthread it will fall back to w32thread and if pthread is found then use it because the user would have to have custom built it themself, therefor probably want to use it above w32thread
[04:04] <michaelni> if you prefer that and wbs has no argument for the other way around then iam happy to apply a patch
[04:05] <michaelni> but i cant test 
[04:06] <michaelni> which is why i prefer a patch over trying to blindly hack on configure
[04:06] <Zeranoe> I can come up with a patch if you like
[04:06] <Zeranoe> I would like to hear wbs's thoughts as well.
[04:27] <CIA-18> ffmpeg: 03Michael Niedermayer 07master * r728e6d979b 10ffmpeg/libavformat/avio.c: 
[04:27] <CIA-18> ffmpeg: avio: print a warning from ffurl_alloc() if no protocols are allocated.
[04:27] <CIA-18> ffmpeg: Fixes Ticket618
[04:27] <CIA-18> ffmpeg: Based on code by teratorn
[04:27] <CIA-18> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[14:56] <CIA-18> ffmpeg: 03Stefano Sabatini 07master * r80abfbea9d 10ffmpeg/ffprobe.c: ffprobe: introduce print_val() macro, ease readability
[14:56] <CIA-18> ffmpeg: 03Stefano Sabatini 07master * rd2d6bade5c 10ffmpeg/ffprobe.c: 
[14:56] <CIA-18> ffmpeg: ffprobe: implement and use print_time and print_ts macros
[14:56] <CIA-18> ffmpeg: Help readability.
[14:56] <CIA-18> ffmpeg: 03Stefano Sabatini 07master * r13665c8767 10ffmpeg/ffprobe.c: 
[14:56] <CIA-18> ffmpeg: ffprobe: refactor value_string() to accept an unit_value struct
[14:56] <CIA-18> ffmpeg: The new design allows to specialize the format for continuos time values
[14:56] <CIA-18> ffmpeg: and discrete values. In particular, allows to print integer values like
[14:56] <CIA-18> ffmpeg: "12" rather than "12.000".
[14:56] <CIA-18> ffmpeg: Prettify, simplify parsing for integer values.
[15:02] <CIA-18> ffmpeg: 03Derek Buitenhuis 07master * re347519877 10ffmpeg/libavcodec/libutvideo.cpp: (log message trimmed)
[15:02] <CIA-18> ffmpeg: libutvideo: Don't try and output original_format
[15:02] <CIA-18> ffmpeg: The original format field in Ut Video's extradata
[15:02] <CIA-18> ffmpeg: should not be used to determine the output format.
[15:02] <CIA-18> ffmpeg: Cases can occur where the original format differs
[15:02] <CIA-18> ffmpeg: from the actual current format, and thus should
[15:02] <CIA-18> ffmpeg: not be used as the output format. Instead, rely
[15:02] <CIA-18> ffmpeg: 03Derek Buitenhuis 07master * rbc74c4712d 10ffmpeg/libavcodec/libutvideo.cpp: 
[15:02] <CIA-18> ffmpeg: libutvideodec: remove impossible pix_fmt case
[15:02] <CIA-18> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:23] <CIA-18> ffmpeg: 03Michael Niedermayer 07master * r5ca392d119 10ffmpeg/tests/Makefile: 
[15:23] <CIA-18> ffmpeg: fate: add --timeout=60 --contimeout=60 to fate-rsync
[15:23] <CIA-18> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:55] <j-b> michaelni: pingie
[15:59] <michaelni> j-b, pongie
[16:00] <j-b> michaelni: I've fixed all the samples permission for the incoming
[16:00] <j-b> please check
[16:05] <michaelni> j-b, i tried to upload something random but its not working
[16:05] <michaelni> lftp upload.ffmpeg.org:/upload> put blank.webm
[16:05] <michaelni> put: Access failed: 550 Can't change directory to /upload: Permission denied (blank.webm)
[16:05] <j-b> no
[16:05] <j-b> you should upload to incoming/
[16:06] <michaelni> our bugreports.html needs to be fixed then
[16:06] <j-b> standard incoming servers on ftp are named incoming/ :)
[16:06] <michaelni> of course
[16:10] <michaelni> j-b, seems to be working now
[16:10] <michaelni> thx
[16:12] <michaelni> j-b well mostly working
[16:13] <michaelni> mkdir: Access failed: 550 Sorry, anonymous users are not allowed to create directories (test)
[16:13] <michaelni> and download only works through the web, no ftp
[16:14] <j-b> download is only for devs, no?
[16:14] <michaelni> its only for devs
[16:15] <michaelni> so no bug issue
[16:15] <michaelni> big
[16:15] <j-b> creating subdirectories, i'll look at it
[16:15] <michaelni> thx, otherwise it might become messy over time
[16:25] <Compn> michaelni : so you can upload and download from incoming now? :)
[16:35] <michaelni> Compn, yes
[16:49] <Daemon404> in case i do nto ge ta reply on the ML: are the CODEC_CAP_* flags documented anywhere?
[16:49] <Daemon404> not get*
[16:50] <Daemon404> seems i was misinformed/mistaken about what the point of CODEC_CAP_DR1 is.
[17:06] <Kov|meiya> Daemon404: I know only of CODEC_CAP_DR1; IIRC it means that you support using a potentially overriden get_buffer / release_buffer, which can be used by a library client to implement direct rendering
[17:08] <Daemon404> so it's useless if it slows things down marginally to implement it, as ive been told.
[17:33] <Compn> michaelni : if you could, send a mail to devels explaining how to access incoming again :)
[17:34] <Compn> i guess i could
[17:39] <j-b> win 4
[17:39] <j-b> oops
[17:53] <michaelni> Compn, please send if you think people lost the last one 
[17:53] <michaelni> Daemon404, if you need a full picture copy in addition then dr1 is not usefull
[17:55] <Daemon404> yes i've gathered that now.
[18:03] <Daemon404> michaelni, splitting that one patch made 8 patches :V how lovely.
[18:04] <ubitux> is there an easy way to decode + apply a filtergraph with ffmpeg but not output anything, just like -y /dev/null + setting a format etc
[18:04] <ubitux> ?
[18:04] <michaelni> -f null ?
[18:05] <ubitux> oh ok the dummy output is ignored then, perfect thx
[18:26] <ubitux> Daemon404: do you mind reformating to K&R your code?
[18:26] <Daemon404> which bit?
[18:26] <ubitux> at least keep the '{' on the same line
[18:26] <Daemon404> well.
[18:26] <Daemon404> i looked arounf the libavcodec source
[18:27] <Daemon404> and say { on a separate line
[18:27] <Daemon404> and went with it.
[18:27] <Daemon404> i usually write in the latter style
[18:27] <ubitux> i wonder where you found such style
[18:27] <ubitux> almost all the code use "if (...) {\n" form
[18:28] <Daemon404> i dont remember tbh
[18:28] <ubitux> i don't care much about the spacing, but i think most of the developers will appreciate some consistency with the { } in the code base
[18:28] <Daemon404> indeed
[18:28] <Daemon404> i can submit one last patch to do that
[18:28] <ubitux> it's not urgent
[18:28] <Daemon404> since i already submitted a butt-load
[18:29] <ubitux> get done with your stuff, you'll do that later
[18:29] <Daemon404> or i could wait till i submit the encoder.
[18:29] <ubitux> i can do it for you, but i need to know when you have no more pending work on that file
[18:29] <ubitux> anyway, bbl
[19:26] <Daemon404> is reimar on irc?
[19:27] <av500> dont think so
[19:32] <Daemon404> that's a shame
[19:32] Action: Daemon404 lieks this real-time talkign business
[19:33] <michaelni> Daemon404, 3,6,7 LGTM but dont apply without 2 it seems
[19:33] <iive> he used to, but now claims it eats too much of his time, so he avoids it altogether 
[19:34] <Daemon404> michaelni, i have to run for an hour or so now
[19:34] <Daemon404> but you can safely apply them without 2
[19:34] <Daemon404> can you handle the merge conflicts? otehrwise itll have to wait till im home
[19:35] <michaelni> ill let you fix it up later :)
[19:35] <michaelni> no hurry
[19:38] Action: Daemon404 brb
[21:02] <Daemon404> michaelni, still around?
[21:12] <michaelni> yes
[21:12] <michaelni> Daemon404, how can i help ?
[21:12] <Daemon404> is it worth me  resending those 3 patches to the ML, or  can i just post them here?
[21:13] <Daemon404> (3,6,7)
[21:14] <michaelni> pasteit or something will do or a url or git repo
[21:15] <Daemon404> k
[21:25] <Daemon404> michaelni, patch 3, then, 6, then 7
[21:25] <Daemon404> aply fine
[21:25] <Daemon404> (git am -3)
[21:25] <Daemon404> apply*
[21:45] <CIA-18> ffmpeg: 03Derek Buitenhuis 07master * rf44f093d60 10ffmpeg/libavcodec/libutvideo.cpp: 
[21:45] <CIA-18> ffmpeg: libutvideodec: Fix name of extradata member
[21:45] <CIA-18> ffmpeg: The frameinfo size member of the Ut Video extradata
[21:45] <CIA-18> ffmpeg: was erroneously thought to be the number of stripes.
[21:45] <CIA-18> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[21:45] <CIA-18> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:45] <CIA-18> ffmpeg: 03Derek Buitenhuis 07master * r1ff1b5f7f6 10ffmpeg/libavcodec/libutvideo.cpp: 
[21:45] <CIA-18> ffmpeg: libutvideodec: Width and height don't need to be unsigned
[21:45] <CIA-18> ffmpeg: Width and height, as used in utvideo_decode_frame, do not
[21:45] <CIA-18> ffmpeg: need to be unsigned, and it could cause sign-compare
[21:45] <CIA-18> ffmpeg: warnings later on.
[21:45] <CIA-18> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[21:45] <CIA-18> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:45] <CIA-18> ffmpeg: 03Derek Buitenhuis 07master * rb580ab6b8b 10ffmpeg/libavcodec/libutvideo.cpp: 
[21:45] <CIA-18> ffmpeg: libutvideodec: Fix typo
[21:45] <michaelni> Daemon404, it works for you maybe but i get
[21:45] <michaelni> Repository lacks necessary blobs to fall back on 3-way merge.
[21:46] <Daemon404> O_o
[21:46] <Daemon404> sec then.
[21:46] <Daemon404> ill spin a new patchset
[21:48] <Daemon404> michaelni, here;
[21:48] <Daemon404> http://japland.org/tools/linux/0001-libutvideodec-Make-buf_size-local.patch
[21:48] <Daemon404> http://japland.org/tools/linux/0002-libutvideodec-Remove-CODEC_CAP_LOSSLESS.patch
[21:48] <Daemon404> http://japland.org/tools/linux/0003-libutvideodec-Check-if-the-decode-initializes-correc.patch
[21:49] <Daemon404> 3, 6, and 7, respectively
[21:59] <michaelni> Hi Tjoppen, are there any MXF patches/git trees that are ready to be merged ?
[22:00] <michaelni> Georg Lippitsch asked in Re: [FFmpeg-devel] [PATCH] MXF index table based seeking
[22:00] <michaelni> if there are news about his patch
[22:03] <CIA-18> ffmpeg: 03Derek Buitenhuis 07master * r70cf7bb958 10ffmpeg/libavcodec/libutvideo.cpp: 
[22:03] <CIA-18> ffmpeg: libutvideodec: Make buf_size local
[22:03] <CIA-18> ffmpeg: Since buf_size is only used in this one function, there
[22:03] <CIA-18> ffmpeg: is no reason for it to be part of UtVideoContext.
[22:03] <CIA-18> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[22:03] <CIA-18> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:03] <CIA-18> ffmpeg: 03Derek Buitenhuis 07master * r61d303c780 10ffmpeg/libavcodec/libutvideo.cpp: 
[22:03] <CIA-18> ffmpeg: libutvideodec: Remove CODEC_CAP_LOSSLESS
[22:03] <CIA-18> ffmpeg: Remove the CODEC_CAP_LOSSLESS flag, as it doesn't make
[22:03] <CIA-18> ffmpeg: any sense for a decoder to use it.
[22:03] <CIA-18> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[22:03] <CIA-18> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:03] <CIA-18> ffmpeg: 03Miroslav SlugeH 07master * rdf9c1cfb48 10ffmpeg/libavformat/ (Makefile rtpdec.c rtpdec_formats.h rtpdec_g726.c): 
[22:03] <CIA-18> ffmpeg: libavformat: add support for G726 audio decoder in RTP and RTSP streams
[22:04] <CIA-18> ffmpeg: Fixes Ticket611
[22:04] <cbsrobot> thats wired - I'm trying to encode some prores files and everthing seems fine
[22:04] <CIA-18> ffmpeg: libutvideodec: Check if the decode initializes correctly
[22:04] <CIA-18> ffmpeg: Actually check the return value of DecodeBegin, to make
[22:04] <CIA-18> ffmpeg: sure that it has encountered no errors.
[22:04] <CIA-18> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[22:04] <CIA-18> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:04] <cbsrobot> but as soon as i put a scale filter in between the image gets green
[22:04] <cbsrobot> like  w:720 h:576 fmt:yuv420p -> w:360 h:576 fmt:yuv422p10le
[22:04] <Tjoppen> michaelni: sorry, I've been busy with other things
[22:05] <cbsrobot> is it possible the swscale from yuv420 -> yuv422p10 is broken ?
[22:05] <Tjoppen> I also suspect it requires handling essence containers properly
[22:05] <Tjoppen> at least for seeking. that can probably wait a bit I suppose - it didn't work properly before anyway
[22:06] <Tjoppen> basicall, it'll only be able to seek properly if all essence is in one big partition, meaning mxfenc's output isn't properly seekable
[22:13] <michaelni> cbsrobot, i see some strange behavor with prores but not green
[22:13] <michaelni> ill fix what i see and we will see then if there are other things left
[22:14] <cbsrobot> michaelni: thanks - I'll investigate a bit further
[22:16] <michaelni> proresenc wont work with changed with ATM, ive fixed it locally
[22:19] <maister> Had some issue with RGB15 -> 24 in swscale. Result was slightly darker, and the source explain why. If I use libswscale directly, is there a way to manually provide the conversion functions?
[22:19] <Daemon404> does libavcodec have somethign similar to bits_read?
[22:20] <Daemon404> aka if i want to read 6 bits
[22:20] <Daemon404> a function to read N bits
[22:23] <iive> getbits i think
[22:23] <michaelni> get_bits()
[22:24] <cbsrobot> michaelni: can you access videolan.org/incoming ?
[22:24] <michaelni> maister, sws_setColorspaceDetails() might work
[22:24] <Daemon404> hmm
[22:24] <Daemon404> looks like i need to learn GetBitContext
[22:25] <michaelni> videolan.org, no idea
[22:25] <michaelni> Daemon404, probably you just need init_get_bits()
[22:25] <Daemon404> ok
[22:25] <cbsrobot> you were talkin to j-b about ffmpeg.org/incoming or videolan.org/incoming ?
[22:25] <michaelni> ffmpeg.org
[22:26] <cbsrobot> ah its upload.ffmpeg.org/incoming
[22:26] <j-b> videolan.org/incoming has never had samples
[22:26] <j-b> streams.videolan.org/incoming has.
[22:27] <cbsrobot> ftp.videolan.org/incoming can receive files
[22:27] <j-b> sure, this was never for samples.
[22:27] <cbsrobot> oups sorry
[22:27] <michaelni> burek, does the log bot work and send mails ?
[22:28] <michaelni> iam asking because i didnt see any
[22:28] <burek> well, its just a matter of setting up a cron and mail :)
[22:28] <cbsrobot> j-b can you delete the tiff-* files then ?
[22:28] <burek> i can do it now, but i wanted to see if the bot is stable :)
[22:28] <j-b> cbsrobot: I am not stupid enough to use master machine for development...
[22:28] <michaelni> burek, no hurry
[22:28] <michaelni> i was just curious
[22:28] <burek> ok, ill send mail now, just to test
[22:28] <cbsrobot> j-b of course - just saying
[22:28] <burek> brb
[22:29] <Daemon404> im a bit confused as to how to call init_get_bits()
[22:29] <Daemon404> im assuming i cant just pass it avpkt->data
[22:33] <cbsrobot> michaelni: I just uploaded following files to incoming:
[22:34] <cbsrobot> tiff-RGB-48bpp-lzw-LE.tif       tiff-RGB-96bpp-lzw-LE.tif       tiff-RGBA-128bpp-lzw-LE.tif     tiff-RGBA-64bpp-lzw-LE.tif
[22:36] <larsenmik> !help
[22:36] <maister> I see reference to MMX2 in swscale sources, is that SSE2?
[22:36] <larsenmik> anyone please help I try for join 2 video with ffmpeg but i got trouble
[22:38] <iive> maister: no, that is mmxext