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

[burek]

[01:33] <durandal_1707> does super2sai actually works?
[01:36] <durandal_1707> rgb565 as input certainly looks wrong
[01:38] <durandal_1707> hmm i can trivialy segv this filter
[01:52] <saste> durandal_1707: damn, command?
[01:53] <durandal_1707> rgb555 and rgb565 do not work as intended
[01:54] <durandal_1707> ffmpeg -i ../fate-suite/dxtory/dxtory_mic.avi -vf format=rgb555,super2xsai /tmp/out.pam
[01:57] <saste> yes something weird happened
[01:58] <saste> i'm sure i tested those cases before committing it... maybe it's a regression
[01:58] <saste> durandal_1707: would you mind creating a ticket?
[02:07] <sandsmark> all decoders return -1 on failure, which is returned to apps as an EPERM error?
[02:08] <sandsmark> the read_header's at least
[02:10] <Compn> isnt that in the docs ?
[02:10] <Compn> if not it probably should be :)
[02:10] <sandsmark> shouldn't they return AVERROR_INVALIDDATA instead?
[02:11] <durandal_1707> saste: bgr24 have same issue as rgb555
[02:11] <sandsmark> getting EPERM for invalid data is confusing
[02:11] <durandal_1707> patch welcome
[02:11] <sandsmark> [16:50:39] <sandsmark> http://sprunge.us/ZgRY does this patch make sense, or have I misunderstood something?
[02:11] <sandsmark> I'm just wondering if it is the right thing
[02:16] <saste> durandal_1707: i see, and we miss a regression test
[02:16] <michaelni> sandsmark, i think some of these should be AVERROR_EOF
[02:17] <durandal_1707> ^beat me
[02:17] <sandsmark> ah
[02:17] <sandsmark> yes
[02:17] <sandsmark> michaelni: but I'm right that it shouldn't just return -1?
[02:17] <durandal_1707> ^ yes
[02:17] <sandsmark> oki
[02:17] <michaelni> and a git format-patch (with commit message & author) is more welcome than one without, iam a lazy person
[02:18] <sandsmark> ofc
[02:18] <sandsmark> I didn't even compile-test it, I just wanted to know if my reasoning was sane first :P
[02:25] <durandal_1707> hmm, why libavfilter cant have AV_RN24/AV_WN24 ?
[02:25] <durandal_1707> it fails when linking....
[02:26] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r0922633f92 10ffmpeg/doc/fate.texi: 
[02:26] <CIA-119> ffmpeg: fate.texi: fix typo in title
[02:26] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:26] <CIA-119> ffmpeg: 03David Hill 07master * r266771f991 10ffmpeg/configure: 
[02:26] <CIA-119> ffmpeg: configure: fix SLIBNAME_WITH_MAJOR for openbsd (and bitrig in the next commit)
[02:26] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:26] <CIA-119> ffmpeg: 03David Hill 07master * r2ad8ac886b 10ffmpeg/configure: 
[02:26] <CIA-119> ffmpeg: configure: support Bitrig OS
[02:26] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:31] <durandal_1707> hmm this super2xsai issue looks more strange
[02:33] <sandsmark> michaelni: http://sprunge.us/bLYb
[02:35] <durandal_1707> issue happens when input and/or output pixel format differs from one supported by super2xsai, otherwise: it may still work, broken output, segvault happens
[02:36] <Daemon404> oooo segvault
[02:36] <Daemon404> teh segment vaults right at you
[02:36] Action: Daemon404 disappears
[02:36] <durandal_1707> vail
[02:39] <durandal_1707> perhaps filters use each others buffers?
[02:48] <CIA-119> ffmpeg: 03Martin T. H. Sandsmark 07master * ra5c1a0c070 10ffmpeg/libavformat/asfdec.c: 
[02:48] <CIA-119> ffmpeg: asfdec: fix returned error codes
[02:48] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:48] <sandsmark> \o/
[02:48] <sandsmark> michaelni: <3
[02:48] <michaelni> sandsmark, i skiped the avi part as the EOF case looked wrong
[02:48] <sandsmark> hmm, ok
[02:49] <sandsmark> I'll look at it again tomorrow
[02:49] <michaelni> ok, i need to sleep as well :)
[02:49] <michaelni> thx for the patch btw
[02:50] <sandsmark> goodnight :)
[04:56] <CIA-119> ffmpeg: 03Paul B Mahol 07master * r0f73ac3fc8 10ffmpeg/libavcodec/vqavideo.c: 
[04:56] <CIA-119> ffmpeg: vqavideo: pass context to remaining av_(d)log
[04:56] <CIA-119> ffmpeg: Finally get rid of all superfluous strings from av_log messages.
[04:56] <CIA-119> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[10:29] <ubitux> michaelni: hard question: do you remember the two samples you used for de3ae185a4b168ffb79c8d966bc89a4f174e2d54 ?
[10:30] <ubitux> that code looks really complicated while it seems it could be very simple (especially with the new api i was talking about); but maybe i'm missing something
[11:23] <michaelni> ubitux, 4 years ago :)
[11:24] <michaelni> looking at the samples archive for SSA/ASS i see
[11:24] <michaelni> http://samples.ffmpeg.org/Matroska/subtitles/
[11:24] <ubitux> i didn't find much stuff on samples.mphq/subs 
[11:24] <michaelni> http://samples.ffmpeg.org/sub/fribidi/
[11:25] <ubitux> fribidi... ok
[11:25] <ubitux> :D
[11:25] <ubitux> great thx.
[11:25] <michaelni> ./Matroska/mewmew/mewmew-vorbis-ssa.mkv
[11:26] <michaelni> ./Matroska/matrix/subs/matrix_reloaded-SSA-Dutch.zip
[11:26] <ubitux> right, i'll try with those
[11:26] <michaelni> i think these are all that i can quickly find that match SSA/ASS
[16:13] <CIA-119> ffmpeg: 03Nicolas George 07master * r69bf775e9f 10ffmpeg/libavutil/bprint.c: bprint: implement vsnprintf for win32.
[16:43] <durandal_1707> is it possible to put #if under #define?
[16:44] <Daemon404> what do you mean?
[16:44] <Daemon404> like an #if inside a macro?
[16:51] <durandal_1707> Daemon404: yes
[17:24] <expresspotato> hi - does anyone know what happened to libavformat/avio.h:int url_buffering_data(ByteIOContext *s,int size);  ?
[17:26] <durandal_1707> expresspotato: look at git log -p
[17:31] <expresspotato> bash-3.2# git log -p > git.log
[17:31] <expresspotato> bash-3.2# cat git.log | grep url_buffering_data
[17:32] <expresspotato> Hmm, it didn't come up with anything for me
[17:51] <CIA-119> ffmpeg: 03Paul B Mahol 07master * r225489f19b 10ffmpeg/libavcodec/mjpegdec.c: 
[17:51] <CIA-119> ffmpeg: mjpegdec: remove superfluous "mjpeg "
[17:51] <CIA-119> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[17:51] <CIA-119> ffmpeg: 03Paul B Mahol 07master * r8ce0c7d264 10ffmpeg/libavcodec/g729dec.c: 
[17:51] <CIA-119> ffmpeg: g729dec: align codec declarations
[17:51] <CIA-119> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[17:51] <CIA-119> ffmpeg: 03Paul B Mahol 07master * r79c39a98cf 10ffmpeg/libavcodec/Makefile: 
[17:51] <CIA-119> ffmpeg: Add truehd decoder line.
[17:51] <CIA-119> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[17:52] <CIA-119> ffmpeg: 03Paul B Mahol 07master * r1b129c2abc 10ffmpeg/libavcodec/flashsv2enc.c: 
[17:52] <CIA-119> ffmpeg: flashsv2enc: align codec declarations
[17:52] <CIA-119> ffmpeg: While here constify enums for .pix_fmts.
[17:52] <CIA-119> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[18:58] <burek> did anyone manage to compile ffserver (or anything in ffmpeg that is network related, like udp/http protocols, etc) statically for linux 32/64 bit?
[19:04] <Daemon404> statically with which libs?
[19:05] <Compn> just static http support i guess
[19:05] <Daemon404> what problems are happening?
[19:05] Action: Compn guesses linking problems
[19:06] <Compn> Daemon404 needs to hang around support channels more often
[19:06] <burek> well
[19:06] <burek> i get some issues with dlopen
[19:06] <Daemon404> i cnat rememver
[19:06] <burek> and I'd like to build it statically with as much features as I can
[19:06] <Daemon404> is dlopen part of libc?
[19:06] <burek> I think yes, it is
[19:06] <CIA-119> ffmpeg: 03Paul B Mahol 07master * rddece75bc8 10ffmpeg/libavcodec/png_parser.c: 
[19:06] <CIA-119> ffmpeg: png_parser: use designated initializers
[19:06] <CIA-119> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[19:06] <Daemon404> burek, yeah glibc is shit
[19:06] <Daemon404> i use a uclibc toolchain
[19:07] <Daemon404> for that
[19:07] <Daemon404> want me to try?
[19:07] <burek> so, back to the lab I guess :) task: learn more about toolchains :)
[19:07] <burek> well, if you have some spare time, but I would prefer if there was a tutorial I can read
[19:07] <burek> not to take your free time
[19:07] <Daemon404> http://japland.org/tools/linux/poky-uclibc-x86_64-x86_64-static-toolchain-1.2%2bsnapshot-20120507.tar.xz
[19:07] <Daemon404> ^im using this
[19:07] <Daemon404> ill try it
[19:08] <burek> thanks a lot :)
[19:08] <Compn> dalias wrote his own libc replacement
[19:08] <Daemon404> as everyone loves to point out
[19:08] <Compn> (mplayer devel)
[19:08] <Compn> hee
[19:08] <Daemon404> but ive had issues with it
[19:12] <ubitux> dalias wrote musl
[19:12] <ubitux> (http://www.etalabs.net/musl/)
[19:12] <Daemon404> ubitux, i know.
[19:12] <ubitux> i was just completing what Compn was saying :)
[19:12] <ubitux> Daemon404: did you try the sample aspect ratio stuff?
[19:12] <Daemon404> ive been on calls all morn
[19:13] Action: Daemon404 is cloning ffmpeg right now
[19:13] <ubitux> haha
[19:13] <Daemon404> i hosed my workstation yesterday
[19:13] <Daemon404> rm -rf dir /*
[19:13] <Daemon404> ^ rouge space
[19:13] <Daemon404> because linux is sitll 1995 in terms of system recovery
[19:13] <funman> use a virtual machine, copy the raw disk image for backup
[19:14] <funman> i see that being done but don't do it myself ^^
[19:14] <Daemon404> funman, i generally use a chroot
[19:20] <Daemon404> burek, http://japland.org/tools/linux/ffserver.xz
[19:20] <Daemon404> static uclibc ffserver for x86_64
[19:21] <Daemon404> (i havent tested it)
[19:21] <burek> cool
[20:13] <burek> is there any way to get some usefull output from gdb and ffmpeg (not ffmpeg_g) because those users that just install distro's binary don't have ffmpeg_g
[20:13] <burek> this is the segfault output of 0.10.x ffmpeg: http://ketas.si.pri.ee/ffmpeg-segfault-gdb2.log
[20:21] Action: llogan is getting tired of approving nabble user messages
[21:18] <ubitux> hey saste :)
[21:18] <ubitux> i looked quickly at libexpat for the case of sami
[21:18] <ubitux> it failed very quickly (that was to be expected)
[21:19] <ubitux> there might be a way to workaround parsing error so i'm going to have a deep look
[21:19] <durandal_1707> why avcodec_find_best_pix_fmt is nowhere used?
[21:19] <ubitux> saste: but what i'm worried about is the demuxer part, where i have to extract small dumps, but well that might be possible anyway
[21:29] <saste> durandal_1707: because it's borken
[21:29] <saste> avcodec_find_best_pix_fmt2() should be used instead
[21:30] <saste> also note that it currently cause an hard lavc dep in lavfi, so it should be really moved to lavu
[21:30] <saste> once the imgconvert mess is resolved once and for all
[21:35] <durandal_1707> saste: what mess?
[21:35] <saste> durandal_1707: check libavcodec/imgconvert.c
[21:36] <saste> most of that info is duplicated or should be moved to libavutil, where it actually belongs
[21:36] <saste> problem is that we still don't know how to properly deal with colorspaces
[21:36] <saste> much info has been moved to libavutil/pixdesc
[21:37] <saste> and some info in pixdesc really belongs to libsws
[21:38] <durandal_1707> so why it is status quo
[21:39] <saste> why? a fork behind i was working on that, then stuff got messed up and nobody else cared enough
[21:40] <saste> i wonder if we could just move functions to lavu, but i need to check it
[21:40] <saste> iirc there is some constraints for which we can't move it there
[21:41] <durandal_1707> i ask because i try to fix bug where worse pix_fmt is taken...
[21:42] <saste> durandal_1707: using avcodec_find_best_pix_fmt2() or _fmt()?
[21:42] <saste> fmt() is borked and should never be used
[21:42] <durandal_1707> first one as used by current code
[21:44] <durandal_1707> http://ffmpeg.org/trac/ffmpeg/ticket/1426
[21:46] <saste> durandal_1707: i suppose the code was never properly tested for the new pixel formats
[21:47] <saste> in particular there are many fields which were never added in PixFmtInfo
[21:47] <saste> that's one of the reason because having that information split between imgconvert and pixdesc is not a good idea
[21:53] <saste> durandal_1707: what i mean is that when people add a new pixel format they often discard to fill the corresponding fields in pix_fmt_info
[22:25] <Daemon404> B/g 30
[22:25] <Daemon404> woops
[22:52] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * rbb850480e1 10ffmpeg/libavcodec/ (ljpegenc.c mjpegenc.c mjpegenc.h mpegvideo.h mpegvideo_enc.c): 
[22:52] <CIA-119> ffmpeg: mjpegenc: support slice multithreading
[22:52] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:10] <durandal_1707> saste: there is nothing missing for yuv420p and/or yuv444p
[23:20] <ubitux> saste: i already found 2 sources of failure with libexpat & sami
[23:20] <ubitux> http://msdn.microsoft.com/en-us/library/ms971327.aspx#showcases_and_a_sami_document_sample
[23:21] <ubitux> reference example fails at least on:
[23:21] <ubitux> 1) <STYLE>...</Style>
[23:21] <ubitux> 2) non closed tags
[23:21] <saste> ubitux: ah that's too broken...
[23:21] <saste> no hope to deal with it sanely i suppose
[23:22] <ubitux> yeah, somehow
[23:22] <ubitux> we might have more luck with RT
[23:22] <saste> what's that?
[23:22] <ubitux> http://service.real.com/help/library/guides/ProductionGuide/prodguide/htmfiles/realtext.htm
[23:27] <saste> in theory you should add exceptions to the parser, but i'm not sure that libexpat devs would like that
[23:28] <ubitux> well
[23:28] <ubitux> or we could just write a small piece of code to do that :))
[23:29] <ubitux> michaelni: can we drop the is_intra_only() hack with CODEC_CAP_INTRA_ONLY?
[23:30] <michaelni> yes, probably
[23:33] <ubitux> that's a nice patchset you have there
[23:36] <saste> ubitux: do you want to comment on setnsamples?
[23:37] <ubitux> saste: nop no more comment from me if it works :p
[23:51] <durandal_1707> channelsplit filter have some issues when i tried it, somehow flac codec in matroska worked but others codecs did not ...
[23:52] <ubitux> what's the point of channelsplit?
[23:53] <ubitux> you can do everything you need with pan filter anyway
[23:53] <durandal_1707> two split audio stream with multiple channels into multiple streams ....
[23:53] <ubitux> mmh?
[23:54] <ubitux> ah, to* yeah
[23:54] <ubitux> then do it with -map_channel or pan filter
[23:54] <durandal_1707> look at doc, it come from qatar, i'm avfilter noob
[23:54] <ubitux> i know what channelsplit is for
[23:55] <ubitux> you can just do it already for a long time with our filters
[23:56] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r948e97a2cc 10ffmpeg/libavformat/pcmdec.c: 
[23:56] <CIA-119> ffmpeg: pcmdec: use av_assert()
[23:56] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:57] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r9d87c8e6f8 10ffmpeg/libavformat/rawdec.c: 
[23:57] <CIA-119> ffmpeg: rawdec: use av_assert()
[23:57] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:57] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r01a14ce042 10ffmpeg/libavformat/riff.c: 
[23:57] <CIA-119> ffmpeg: riff: use av_assert
[23:57] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:57] <durandal_1707> if it does not provide any new functionality over pan it could be probably removed then ....
[00:00] --- Fri Jun 15 2012