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

[burek]

[00:00] <kurosu> kurosu: it was reviewed on libav, but nobody said ok to apply, despite several pings
[00:00] <kurosu> durandal_1707:
[00:00] <kurosu> to me they could be applied as is
[00:03] <durandal_1707> well i'm not asm expert (i'm little ignorant/lazy in that area) so i cant say its ok
[00:04] <kurosu> some are just bit flipping and moving data around
[00:04] <kurosu> apply_noise is quite more hairy, so probably a deeper look is needee
[00:04] <kurosu> *needed
[00:05] <kurosu> besides, michaelni often has an eye for doing things differently and better
[00:17] <cone-236> ffmpeg.git 03Paul B Mahol 07master:bd252ff6fae7: lavfi/smptebars: fix invalid writes
[00:20] <saste> ubitux, can you suggest an use for SW/SH in geq?
[00:20] <ubitux> saste: i forgot hsub/vsub was present in pad, so forget my comment
[00:20] <ubitux> stick with your code, don't mind me :)
[00:22] <saste> on the other hand I'm not even sure what's useful for in overlay
[00:25] <ubitux> no more green lines with smptebars \o/
[00:34] <ubitux> wow there is quite some literature about vignetting
[00:34] <ubitux> i guess i'll have more work to do on that filter
[00:35] <ubitux> well anyway, 'night
[00:50] <cone-236> ffmpeg.git 03Paul B Mahol 07master:77535bb3c376: bmpenc: get rid of BMPContext as it is unused
[00:51] <cone-236> ffmpeg.git 03Paul B Mahol 07master:08b31a72dbcf: xwdenc: remove unused code
[00:51] <cone-236> ffmpeg.git 03Paul B Mahol 07master:faf689c7ebc9: xbmenc: remove unused code
[01:11] <durandal_1707> what happened to uploading ftp server?
[01:12] <durandal_1707> the description is to upload to ftp://upload.ffmpeg.org
[01:12] <durandal_1707> but that is vlc server now and there is no way to upload nor there is directories where usual upload happens
[01:13] <durandal_1707> michaelni: where i can upload sample for fate?
[01:14] <michaelni> durandal_1707,  IIRC http://www.datafilehost.com/
[01:15] <durandal_1707> michaelni: is this ftp issue temporal?
[01:16] <michaelni> durandal_1707, i hope
[01:16] <michaelni> but i dont know what the problem is
[01:20] <cone-236> ffmpeg.git 03Stefano Sabatini 07master:e80bc76e9e0c: doc/filters: put separated geq variables in separate lines
[01:20] <cone-236> ffmpeg.git 03Stefano Sabatini 07master:c430eb2d58d2: doc/filters: fix erroneously truncated comment on a scale example
[01:22] <burek> hello all :)
[01:23] <burek> i was thinking about one thing, so i better ask for your opinion on that.. would it be possible that we re-use all those fate clients, that are already compiling stuff regularly, to create static builds automatically for all those arch/os combinations?
[01:24] <durandal_1707> and provide bandwitch for uploading?
[01:25] <burek> well, it's not quite a big requirement, since it might be schedulled to upload it once-a-day at 4-5 am
[01:26] <burek> i can provide a general web page for all those uploads, for further distribution to internet users
[01:26] <burek> just like there is one now for linux 3.x kernels
[01:27] <michaelni> if theres avolunteer to set all this up and maintain it and it actually works in practice
[01:28] <michaelni> then i guess its a good idea ...
[01:28] <burek> well, i just volunteered i guess :)
[01:28] <llogan> what did i miss?
[01:29] <burek> llogan, a minute before you got in
[01:29] <burek> [01:24:03] <burek> i was thinking about one thing, so i better ask for your opinion on that.. would it be possible that we re-use all those fate clients, that are already compiling stuff regularly, to create static builds automatically for all those arch/os combinations?
[01:29] <michaelni> one problem is though many fate clients are rather empty, i mean only the bare minimum to do fate
[01:29] <michaelni> no x264, no libthis no libthat
[01:30] <burek> i see
[01:30] <llogan> burek: thanks. interesting thought though.
[01:30] <michaelni> also mine are a bit tight on diskspace as i tried to put as many as i could on SSD
[01:31] <saste> burek, tomorrow i'll push the ffmpeg-all thing, your last chance to comment
[01:31] <durandal_1707> i hope generated files are on memory, otherwise you are wasting ssd
[01:32] <burek> uh saste, any url please?
[01:33] <burek> durandal_1707, yeah, ramdisk might help speed up the compilation too, beside sparing the ssd wearing
[01:34] <saste> burek: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/161081/focus=161838
[01:34] <burek> great, thanks, i'll read it now
[01:47] <durandal_1707> saste: how i can force rgb for lavfi and smptebars with ffmpeg?
[01:47] <durandal_1707> it seems it picks yuv, even i encode to bmp/png which is rgb
[01:49] <saste> durandal_1707, smptebars,format=rgba
[01:50] <burek> saste, that was a good work, i read all the messages
[01:50] <burek> the only thing i would suggest changing is using ffmpeg-full instead of ffmpeg-all
[01:51] <burek> but "all" is shorter and is ok too :)
[01:52] <durandal_1707> saste: does not help, do you know possible source of problem with color switch?
[01:53] <saste> durandal_1707, show your command
[01:54] <durandal_1707> -f lavfi -i smptebars
[01:56] <saste> durandal_1707, yes, what about -f lavfi -i smptebars,format=rgb24
[01:56] <saste> it helps here
[01:57] <durandal_1707> does not here, orange is still orange
[01:59] <cone-236> ffmpeg.git 03Andrew Van Til 07master:5ed9eebc24ad: rtsp/rtp_read_header: Use RTP_MAX_PACKET_LENGTH instead of 1500
[01:59] <cone-236> ffmpeg.git 03Andrew Van Til 07master:8df46c65cf99: rtpdec: Increase max rtp packet size to 8192
[01:59] Action: saste sleeps
[02:04] <Zeranoe> Have there been any updated on the bug I previously reported?
[02:06] <michaelni> Zeranoe, which bug ?
[02:06] <llogan> is there a trac ticket number?
[02:07] <Zeranoe> No i haven't created one yet, I just posted on the IRC about it yesterday, wondering if anyone had some quick information. I can create a ticket tonight if need be
[02:07] <Zeranoe> From yesterday: "There seems to be an issue with FFmpeg's moov atom support in 32-bit builds for large files. I think the issue might be here: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/mov.c;h=3c54ef3834bc5844261a404c445d92961d8f29da;hb=HEAD#l2611 in the mov.c file on line 2611"
[02:08] <Zeranoe> "FFmpeg errors that it cannot find the moov atom with large files on a 32-bit machine"
[02:10] <Zeranoe> iive: I got some results on that moov atom bug
[02:11] <iive> the suspected problem with large files?
[02:11] <iive> what is it?
[02:12] <michaelni> how can it be reproduced ?
[02:12] <Zeranoe> iive: There seems to be an issue with FFmpeg's moov atom support in 32-bit builds for large files. I think the issue might be here: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/mov.c;h=3c54ef3834bc5844261a404c445d92961d8f29da;hb=HEAD#l2611 in the mov.c file on line 2611
[02:12] <michaelni> we do malloc with these values
[02:12] <Zeranoe> michaelni: I'm not sure if it is a Windows only bug, but it gives a "moov atom not found" when trying to work with large files. It might be only 32-bit
[02:13] <michaelni> <michaelni> how can it be reproduced ?
[02:13] <iive> he have 5.4gb file and compiles ffmpeg with mingw under windows
[02:14] <michaelni> does this happen with any 5.4gb file ?
[02:15] <Zeranoe> michaelni, iive: I have to AFK for a bit but i will be back later.
[02:16] <cone-236> ffmpeg.git 03Paul B Mahol 07master:659672f3eeae: lavfi/afade: use standard options parsing
[02:16] <cone-236> ffmpeg.git 03Paul B Mahol 07master:a95e68386792: lavfi/noise: use standard options parsing
[02:16] <cone-236> ffmpeg.git 03Paul B Mahol 07master:2b26077c9553: lavfi/blend: use standard options parsing
[02:17] <iive> i suspected it might be something trivial, like mingw not providing proper large file support, failed configure check. but he had both defines present.
[02:17] <iive> i asked him to try a windows build from the download page too. hope he haven't forgot to test that too.
[02:29] <burek> hm, if anyone is familiar with "tinterlace" filter, please help: http://ffmpeg.gusari.org/viewtopic.php?f=11&t=883 (since I don't have a clue what the guy is asking about)
[02:49] <iive> does ffmpeg output any information about the loaded filters ?
[03:39] <Zeranoe> iive: What do you mean try a build from the download page?
[03:39] <iive> there are win32 builds of ffmpeg, try one of them.
[03:40] <Zeranoe> iive: I'm the one who compiles those builds?
[03:40] <iive> they are already built, i think.
[03:41] <Zeranoe> iive: The builds linked on the download page for FFmpeg?
[03:41] <iive> btw, is there a file you can share with e.g. michaelni ?
[03:42] <iive> if he is eager to download 5-6gb for a single bug.
[03:51] <michaelni> iam happy to create my own huge files if it "works" with any
[03:52] <michaelni> also is this 32bitz specific ? 
[03:53] <michaelni> i tried a ming64 build on linux with a created 5gb mov
[03:53] <Zeranoe> michaelni: Yes I've head it is, I wasn't the first to find the error but I'm working on it now
[03:53] <michaelni> didnt notice any errors
[03:55] <Zeranoe> The client provided a test file, let me upload that. Is it fine if you download it from my site?
[03:57] <Compn> yes thats fine
[03:57] <Compn> host it already :p
[03:58] <Zeranoe> Compn: Going to take a while to upload
[04:00] <Zeranoe> Apparently the issue happens when the FFmpeg build is also compiled with MSVC, so it leads me to think it might be FFmpeg's code.
[04:00] <llogan> iive: Zeranoe provides the ffmpeg builds for Windows that we link to on the ffmpeg download page
[04:03] <iive> oh...
[04:10] <iive> Zeranoe0: i'll be off. I'm sure the people here will look into the problem.
[04:11] <iive> you may want to limit your upload speed to 90% of your isp limit, to avoid flooding your connection.
[04:12] <Zeranoe> iive: Good tip, thanks for the help
[04:12] <Zeranoe> danget
[04:30] Action: michaelni falls asleep, will look at the bug/file tomorrow, Zeranoe ping me if i forget
[04:37] <llogan> Zeranoe: a bug report would be useful anyway since we are often forgetful and for reference
[09:13] <llogan> __gb__: i added Tushar Gohad as backup for Hardware Accelerated Video Encoding with VA-API
[09:15] <__gb__> hi llogan, thanks
[09:15] <llogan> michaelni: i turned off the bounce notifications for -user...so no more annoying bounce dumps.
[09:15] <llogan> (notifications for list owner)
[09:15] <llogan> __gb__: and your proposals were nice and detailed.
[09:16] <llogan> i haven't heard anything from Google yet. probably won't know until april 8.
[09:40] <wm4> __gb__: still no plans for Intel to support vdpau?
[09:50] <__gb__> wm4, no, why would this be needed?
[09:51] <wm4> __gb__: application developers would have to support only one API
[09:51] <nevcairiel> isnt vaapi this one api
[09:53] <wm4> AMD recently decided to support vdpau natively, so no
[09:54] <__gb__> vpdau doesn't match the desired set of features
[09:54] <wm4> then add an extension to its API
[09:54] <__gb__> amd decided to support what was available in Mesa/Gallium
[09:54] <nevcairiel> isnt there a vdpau backend for vaapi
[09:54] <__gb__> there is
[09:54] <wm4> nevcairiel: it's slow and crappy
[09:54] <cptspiff> maybe not, but it does actually, you know, work.
[09:54] <saste> __gb__, hey :)
[09:54] <__gb__> wm4, how slow, any data to share?
[09:55] <wm4> __gb__: I could make some tests
[09:55] <saste> __gb__, we don't know nothing from google until the evaluation result is announced (will happen on monday)
[09:55] <wm4> also, the vdpau API is actually better (especially on the video output side), and since both Mesa and AMD are going to support vdpau, it's irritating that Intel doesn't follow suite
[09:55] <__gb__> AMD also considered vaapi anyway, but I didn't follow up
[09:57] <__gb__> wm4, you could write vaapi to vdpau if you prefer
[09:57] <__gb__> I believe Fluendo has such a thing
[10:03] <wm4> they seem to have a gstreamer thing to use vdpau/vaapi/xvba from one API, but I didn't find anything else
[10:05] <llogan> ubitux: did you recieve any 3rd degree burns from IRC? (RE: consulting)
[10:05] <llogan> and how is it so damned late already?
[10:06] Action: llogan blames a broken mysql dump
[10:17] <cone-278> ffmpeg.git 03Stefano Sabatini 07master:d5f3a0c221aa: doc: move ffmpeg-codecs.texi content to separated file
[10:17] <cone-278> ffmpeg.git 03Stefano Sabatini 07master:2086c7e17345: doc: move ffmpeg-formats.texi content to separated file
[10:17] <cone-278> ffmpeg.git 03Stefano Sabatini 07master:a7990287aa65: doc: move ffmpeg-devices.texi content to separated file
[10:17] <cone-278> ffmpeg.git 03Stefano Sabatini 07master:a6cd26fc9331: doc: move ffmpeg-resampler.texi content to separated file
[10:17] <cone-278> ffmpeg.git 03Stefano Sabatini 07master:702e7438275a: doc: move ffmpeg-scaler.texi content to separated file
[10:17] <cone-278> ffmpeg.git 03Stefano Sabatini 07master:9b4d9d8795b0: doc: enable compilation of -all tool pages
[10:49] <cone-278> ffmpeg.git 03Stefano Sabatini 07master:495ed19b5bb0: cmdutils: remove error message from opt_default() in case of missing option
[12:46] <cone-278> ffmpeg.git 03Nicolas Bertrand 07master:5e46f6b5b7c7: img2: Add j2k file extension for JPEG 2000
[12:46] <cone-278> ffmpeg.git 03Nicolas Bertrand 07master:8c65264595d5: pixdesc/pixfmt: Add XYZ colorspace for XYZ 12-bit values
[12:46] <cone-278> ffmpeg.git 03Michael Niedermayer 07master:8e85b69d716b: Merge commit '8c65264595d5a82c56ae5043320e4b875a414229'
[12:47] <cone-278> ffmpeg.git 03Stefano Sabatini 07master:89d581f15e0d: doc/filters: fix old broken syntax of color source in overlay example
[12:47] <cone-278> ffmpeg.git 03Stefano Sabatini 07master:029cca6fb3ea: doc/filters: clarify example explanation
[13:00] <cone-278> ffmpeg.git 03Nicolas Bertrand 07master:28a807e28b45: libopenjpeg: Add support for XYZ colorspace, found in DCINEMA frames
[13:00] <cone-278> ffmpeg.git 03Michael Niedermayer 07master:29a4221ad380: Merge remote-tracking branch 'qatar/master'
[13:56] <durandal_1707> why pross-au is missing?
[14:10] <durandal_1707> michaelni: do you have idea how to fix that smacker audio regression?
[14:44] <michaelni> which smacker audio regression ?
[14:46] <durandal_1707> see bug tracker
[15:14] <michaelni> durandal_1707, searching for smacker on the timeline leads to 2426 which is closed/fixed 
[15:16] Action: michaelni really would prefer to spend more time working on ffmpeg than guessing what bug people refer to
[15:17] <durandal_1707> michaelni: i use timeline and than search for smacker and recently 2 bug was reported, one of which get fixed
[15:18] <durandal_1707> michaelni: http://ffmpeg.org/trac/ffmpeg/ticket/2425
[15:18] <michaelni> durandal_1707, thanks
[15:19] <durandal_1707> michaelni: how much time you lost? (I could help you on your ffmpeg related work)
[15:22] <michaelni> durandal_1707, iam trying to review and test the asm patches and ...
[15:34] <iive> btw, what happened with the moov atom bug in big files?
[15:35] <durandal_1707> it is reproduced on Windows only (minwg32?)
[15:35] <durandal_1707> guess one could create 5gb file with ffmpeg on unix
[15:36] <nevcairiel> i've never heard of complains about mov on windows, is this only for muxing or for demuxing?
[15:36] <durandal_1707> demuxing
[15:36] <nevcairiel> i'm sure someone would've complained to me then =p
[15:49] <wm4> so, what's the difference between AV_CH_LAYOUT_STEREO and AV_CH_LAYOUT_STEREO_DOWNMIX?
[15:51] <nevcairiel> the latter is supposed to indicate that 2 channels in the audio buffer contain a stereo downmix, its used in combination with a 5.1 flag for example, in a 8 channel buffer
[15:52] <nevcairiel> some formats encode crazy shit like that
[15:52] <wm4> oh, so they're just additional channels that contain the stereo part
[15:52] <nevcairiel> indeed
[15:52] <wm4> what are applications supposed to do with that?
[15:53] <nevcairiel> discard and play 5.1, or discard the 5.1 and play stereo, i imagine? :)
[15:53] <wm4> does libavresample handle this automagically?
[15:54] <nevcairiel> doesnt seem like it
[15:54] <iive> nevcairiel: it may be good idea to join #ffmpeg if you want to hear more complains. I've heard 2 different people complain about it.
[15:55] <nevcairiel> i'm fine just dealing with my users, which are all on windows, thanks :p
[16:06] <nevcairiel> ubitux: ebur128 fate tests fail after todays msvc compiler update :(
[16:07] <durandal_1707> have some compiler warnings?
[16:12] <nevcairiel> multithreaded compile makes reading hard, i'll do a local compile in a min
[16:26] <durandal_1707> hmm, so lavf http code is not getting fix, but mplayer one does?
[16:28] <wm4> "getting fix"
[16:28] <wm4> what
[16:28] <wm4> but yeah, mplayer's http code is still better
[16:28] <wm4> despite being a crapload of shit and rotting away :)
[16:28] <wm4> I guess the main difference is that mplayer's http code was actually _used_
[16:29] <durandal_1707> so instead of improving lavf code, just fix rotting code, and then rm it one day, and wonder why other ones is buggy in another day...
[16:29] <wm4> I should contribute some patches, but I kind have my hands full
[16:29] <wm4> did that patch for spaces in URLs get in yet? I think it was pushed and then reverted
[16:31] <wm4> commit 4a8fc1d83b1b55e1ac533644168018ebeec0c732
[16:31] <wm4> looks liek it wasn't fixed and re-applied...
[16:31] <durandal_1707> no http maintainer
[16:32] <wm4> mplayer's http code is actually kind of maintained (reimar recently fixed something)
[16:34] <cone-278> ffmpeg.git 03Paul B Mahol 07master:20343219d269: tty: make use of AV_OPT_TYPE_VIDEO_RATE
[16:34] <cone-278> ffmpeg.git 03Paul B Mahol 07master:8c43fd865486: tty: make use of AV_OPT_TYPE_IMAGE_SIZE
[16:59] <cone-278> ffmpeg.git 03Christophe Gisquet 07master:0b467a6e83bd: x264asm: fix cmp* number of arguments
[16:59] <cone-278> ffmpeg.git 03Christophe Gisquet 07master:37a9708391ae: x86: sbrdsp: implement SSE neg_odd_64
[17:17] <ungureanuVlad> i have a RTSP stream encoded with MPEG4 and when i try to save only one frame it says that warning: first frame is no keyframe...ffmpeg cannot check when the frame starts and from here should be the problem ?
[17:25] <durandal_1707> you simply cant save first frame if there if it is not key frame, becuase there is generally no way to produce anything useful
[17:26] <durandal_1707> what happened to that help patch?
[17:26] <ungureanuVlad> i'm not really intrested to save the 1st frame of the video, i want to save a frame from the video. need it for further processing
[17:28] <durandal_1707> ungureanuVlad: if this is question about using libav* api and about developing it ask it on #ffmpeg
[17:28] <durandal_1707> *and not about deve...
[17:29] <durandal_1707> also there is relevant mailing list if there is no help on #ffmpeg....
[17:46] <durandal_1707> ungureanuVlad: you are using latest version or?
[17:48] <ungureanuVlad> @durandal_1707 i am working on a RaspberryPI, latest from apt-get install. i tried to compile ffmpeg from source but the cross compile environment to set up did not work for me
[18:05] <cone-278> ffmpeg.git 03Paul B Mahol 07master:33b6d215fa4a: bintext: make use of AV_OPT_TYPE_VIDEO_RATE
[18:05] <cone-278> ffmpeg.git 03Paul B Mahol 07master:3d9a789b0da4: bintext: make use of AV_OPT_TYPE_IMAGE_SIZE
[18:05] <cone-278> ffmpeg.git 03Paul B Mahol 07master:4c76600a8c1d: rawdec: make use of AV_OPT_TYPE_VIDEO_RATE
[18:05] <cone-278> ffmpeg.git 03Paul B Mahol 07master:9f5bb4402136: rawvideodec: make use of AV_OPT_TYPE_VIDEO_RATE
[18:05] <cone-278> ffmpeg.git 03Paul B Mahol 07master:d343848de2f8: rawvideodec: make use of AV_OPT_TYPE_IMAGE_SIZE
[18:05] <cone-278> ffmpeg.git 03Paul B Mahol 07master:1d5b4f9fe981: img2dec: make use of AV_OPT_TYPE_VIDEO_RATE
[18:05] <cone-278> ffmpeg.git 03Paul B Mahol 07master:9a8f1e729588: img2dec: make use of AV_OPT_TYPE_IMAGE_SIZE
[18:17] <durandal_1707> who is creator of that gepmFF bizaro picture?
[18:34] <durandal_1707> michaelni: matroskaenc does not need to have additional pcm tags, be variants are natively supported
[18:35] <michaelni> durandal_1707, about smacker, is there any file that sounds better with the clip than without or some evidence that the clip should be there ?
[18:36] <durandal_1707> michaelni: good question, looks i will need to waste several days for complete elaboration
[18:37] <michaelni> iam asking because simply removing the cliping solves the bugs
[18:38] <durandal_1707> i know, but i did not inspected are overflows valid (eg flawed coded/encoder design)
[18:38] <durandal_1707> *codec
[18:38] <durandal_1707> it may be original decoder bug....
[18:39] <durandal_1707> but i don't have any proof
[19:17] <ubitux> nevcairiel: that failure is pretty weird
[19:17] <ubitux> you think it's a bug in the code, or msvc?
[19:20] <ubitux> btw, there is no clean solution to passthrough the http options from one demuxer to a sub-one, right?
[19:20] <ubitux> (i'm thinking of libquvi, but i think the same issue raised with hls)
[19:30] <nevcairiel> ubitux: i'm trying to figure out with which version of the compiler it exactly started to break, and if only 64-bit, maybe it will enlighten me somehow
[19:31] <nevcairiel> for some reason the number of tests also went down, not sure if thats because of the fail?
[19:34] <Compn> ubitux : the only other chained demuxer i can think of is dv-in-avi or ogg in avi
[19:46] <wm4> ubitux: why don't you write a blu-ray demuxer or so? you know, something useful
[19:48] <kierank> because there a is a "blu-ray" format right?
[19:49] <kierank> it's not a collection of different files
[19:50] <nevcairiel> wm4: why don't you contribute instead of trolling?
[19:50] <ubitux> wm4: don't we already have it?
[19:51] <ubitux> ok, it's actually a protocol
[19:51] <mateo`> wm4: libquvi support is useful :]
[19:51] <wm4> ubitux:  there's only a .ts demuxer
[19:51] <ubitux> mateo`: he knows, he implemented it himself in his mplayer fork
[19:51] <wm4> mateo`: libquvi support is sort of like trolling
[19:52] <wm4> it should be in ffplay.c/ffmpeg.c if anything
[19:52] <ubitux> wm4: it was requested, so i wrote it
[19:52] <ubitux> i can now ffprobe and ffplay youtube, so i'm happy
[19:52] Action: mateo` got trolled
[19:52] <mateo`> :D
[19:54] <nevcairiel> i wonder how often it breaks, considering youtube likes changing up things
[19:54] <ubitux> <+wm4> ubitux:  there's only a .ts demuxer // libavformat/bluray.c doesn't do what you want?
[19:55] <wm4> ubitux: no, this is probably exactly what I want... looks a bit underfeatured though
[19:55] <ubitux> i can't tell; never used it
[19:56] <ubitux> i don't have any bluray device
[19:57] <wm4> as for libquvi, if you really want it, you should implement it as redirection of some sort, not demuxer
[19:58] <wm4> I get the feeling that demuxers as abstraction are abused to get features into ffmpeg.c/ffplay.c (just like the concat and image demuxers) and this are abominations
[19:58] <ubitux> i could have used protocols but for probing it sucks
[19:58] <wm4> sorry if that comes over as trolling
[19:58] <ubitux> (my first version was actually a protocol, but didn't work well)
[19:59] <ubitux> wm4: i'd better have abuses in a dedicated shared module rather than adding it to an already more-than-hacky implementation "example"
[20:00] <wm4> if that keeps hacks away, why not trash the trashy thing a bit more
[20:00] <ubitux> what do you mean?
[20:00] <wm4> libquvi as a demuxer is obviously a hack
[20:01] <ubitux> i have no better solution
[20:01] <ubitux> it's not enabled by default
[20:01] <ubitux> it doesn't affect the core
[20:01] <ubitux> and it's shared between tools
[20:02] <wm4> how do I even open a URL as http now instead of resolving through libquvi?
[20:02] <ubitux> huh?
[20:02] <wm4> does that mean libquvi runs its scripts every time you open something and it happens to run the probe function?
[20:03] <ubitux> unless quvi_supported() makes internet accesses, it shouldn't change anything
[20:06] <wm4> using a protocol (like quvi://) might actually work, you'd have to wrap another protocol, but that's perhaps easier than in the demuxer
[20:06] <nevcairiel> ubitux: looks like the ebur problem wasn't caused by todays compiler update, but is generally broken with the 2012 version of the compiler, or so it seems
[20:06] <nevcairiel> there just never was a fate with that before
[20:07] <ubitux> wm4: yes, as i said i tried a protocol implementation, but the quvi:// is not nice; the autodetection of youtube url for instance is pretty handy
[20:08] <ubitux> nevcairiel: mmh ok
[20:11] <nevcairiel> how odd
[20:14] <wm4> ubitux: in general I don't really get why ffmpeg mixes some high level concepts (like turning a series of images into video) with a very low level API
[20:15] <nevcairiel> 2012 uses SSE floating-point calculations by default, while 2010 uses x87, if that could be it? /me tests
[20:15] <ubitux> wm4: because that's useful for generic usage
[20:15] <ubitux> what do you propose for the images?
[20:15] <ubitux> also, what is the problem?
[20:17] <wm4> nothing, forget it
[20:44] <llogan> heh. cinepak.
[20:49] <nevcairiel> ubitux: fate passes if i force x87 floating point... meh
[20:50] <ubitux> nevcairiel: maybe there is the use of undefined fp somewhere, which is possible 
[20:50] <ubitux> a forgotten /0 or something
[20:50] <nevcairiel> let me force strict fp and fp exceptions
[20:52] <nevcairiel> with strict fp it still passes with sse fp
[20:52] <nevcairiel> so it may indeed be some undefined fp somewhere
[20:57] <nevcairiel> now how do i get it to tell me where it is? ;)
[20:58] <ubitux> swear on your screen
[21:00] <llogan> durandal_1707: int v1cb_is_clobbered = 1, v4cb_is_clobbered = 1;;
[21:00] <llogan> is the double ; correct? (obviously I'm C-ignorant)
[21:00] <nevcairiel> its not
[21:01] <cone-278> ffmpeg.git 03highgod0401 07master:99186f1fd2ad: fix bug of finding CPU device
[21:02] <llogan> durandal_1707: also, "hight" typo (regarding cinepak). this concludes my worthless review.
[21:08] <nevcairiel> ubitux: ha i got it to throw an exception at my face, will gather details
[21:10] <nevcairiel> its a div by zero, fwiw
[21:12] <ubitux> nevcairiel: ow; where?
[21:13] <ubitux> relative_threshold = integ->sum_kept_powers / integ->nb_kept_powers;
[21:13] <ubitux> here maybe?
[21:13] <ubitux> that's the only non-check div i see
[21:13] <ubitux> erm well...
[21:14] <ubitux> wonder how that can div by zero
[21:15] <nevcairiel> hm great the stack trace brings me back somewhere in ffprobe, it catches those damn float exceptions too late
[21:16] Action: ubitux looking at all the divisions again
[21:20] <ubitux> i've just re-checked every div
[21:20] <ubitux> doesn't seem to be that
[21:22] <nevcairiel> i'll let you know if i can make it tell me where exactly it complains
[21:23] <Compn> cinepak encoder , strange license tho. is it public domain ?
[21:25] <nevcairiel> thats the MIT license
[21:25] <Compn> ah
[21:26] <cone-278> ffmpeg.git 03Diego Biurrun 07master:ae35d91d44c5: h261: Move ff_h261_rl_table_store declaration to header file
[21:26] <cone-278> ffmpeg.git 03Michael Niedermayer 07master:fa871b1bde42: Merge commit 'ae35d91d44c5e676af3d146bf8d05b241c467675'
[21:31] <cone-278> ffmpeg.git 03Diego Biurrun 07master:ed16c2dbf47c: h261: Remove H.261 loop filter from dsputil
[21:31] <cone-278> ffmpeg.git 03Michael Niedermayer 07master:3d73be071dfb: Merge commit 'ed16c2dbf47cdd7c48825b4da6e7036698e5dde1'
[21:37] <cone-278> ffmpeg.git 03Diego Biurrun 07master:66ac3dbf1e60: h261: Move function declarations to h261.h
[21:37] <cone-278> ffmpeg.git 03Michael Niedermayer 07master:e7c801d9d319: Merge commit '66ac3dbf1e60c27d0f1d779a424c0b33b7ca3780'
[21:51] <ubitux> i guess i'll have soon to update the coverage script
[21:53] <nevcairiel> ubitux: looks like it wasn't a div by zero afterall, the debugger tricked me ... the error comes from this: FILTER(y, x, PRE);  // apply pre-filter
[21:55] <ubitux> :/
[21:55] <ubitux> do you see anything suspicious here?
[21:58] <cone-278> ffmpeg.git 03Diego Biurrun 07master:b78f81c80339: h261: K&R formatting and prettyprinting cosmetics
[21:58] <cone-278> ffmpeg.git 03Michael Niedermayer 07master:04b0fd7e91b9: Merge commit 'b78f81c8033904e2e75add0c9a603df6df514a30'
[21:59] <nevcairiel> i'm still hoping it tells me somehow what kind of fpu exception it has
[21:59] <nevcairiel> Unhandled exception at 0x013AACA6 in ffprobe.exe: 0xC00002B4:  Multiple floating point faults (parameters: 0x00000000, 0x00000320).
[21:59] <nevcairiel> the message is hardly useful
[22:00] <ubitux> good luck
[22:00] <ubitux> (and thx for looking into it)
[22:06] <nevcairiel> hm, it throws an "inexact" fpu exception, wonder what the hell that means
[22:06] <nevcairiel> maybe it doesnt like the construct of a*b+c*d+e*f
[22:07] <ubitux> yes that's a very complicated op
[22:07] <ubitux> :))
[22:07] <cone-278> ffmpeg.git 03Diego Biurrun 07master:0404ec619d43: h261: cosmetics: Move functions to avoid forward declarations
[22:07] <cone-278> ffmpeg.git 03Michael Niedermayer 07master:473d1297427f: Merge commit '0404ec619d43f27b87c424aa1a572a6699fe6a31'
[22:15] <durandal_1707> wm4: was that rage quit?
[22:15] <wm4> ?
[22:15] <durandal_1707> because of libquvi hack?
[22:19] <durandal_1707> it is hack in same/similar way as image2 demuxer/muxer, but I don't think that meant that such kind of hack should be removed
[22:20] <durandal_1707> that is whole point of AVFMT_NOFILE flag
[22:21] <wm4> these things are only to help with ffplay/ffmpeg command line interface, and it shouldn't really e in a demuxer library IMHO
[22:21] <wm4> AVFMT_NOFILE is set for useful things too, like rtsp
[22:21] <nevcairiel> ubitux: i should just build in strict fp mode and forget about the issues <.<
[22:21] <wm4> durandal_1707: anyway, pointless discussion, nobody cares
[22:22] <ubitux> nevcairiel: you think that's a compiler bug?
[22:22] <nevcairiel> not sure
[22:22] <nevcairiel> what i know is that it only happens when sse2 fpu is used, and not in strict fp mode
[22:22] <ubitux> nevcairiel: have you checked if the floating values aren't too big?
[22:22] <ubitux> or maybe tried to reduce the floating precision of the constants?
[22:22] <nevcairiel> it didnt throw any overflow exceptions
[22:23] <ubitux> yes but "inexact"
[22:23] <nevcairiel> which is apparently normal
[22:23] <ubitux> maybe values are a bit large for accuracy
[22:23] <nevcairiel> fpu is often inexact
[22:23] <ubitux> yes
[22:23] <ubitux> but as it says "inexact" fpu exception... :)
[22:24] <kurosu> x87 means 32bits; I guess it also fails with a 64bits config ?
[22:24] <nevcairiel> like i said, it only fails with sse2 fpu, which is kinda implied on 64-bit
[22:25] <nevcairiel> and only one of the metadata values is off, only I
[22:25] <nevcairiel> all the others are correct
[22:25] <nevcairiel> not that i have any idea what they mean
[22:26] <cone-278> ffmpeg.git 03Diego Biurrun 07master:52cd84d4d4e3: h261: Move mvmap table to the only place it is used
[22:26] <cone-278> ffmpeg.git 03Michael Niedermayer 07master:37f080f6f6a8: Merge remote-tracking branch 'qatar/master'
[22:28] <nevcairiel> so it might as well be a compiler issue
[22:33] Action: ubitux just learned that "c ? a : b = 1" is c++ valid
[22:33] Action: ubitux shit bricks
[22:34] <ubitux> also, it's different from "(c ? a : b) = 1"
[22:37] <Kovensky> is (c ? a : b) even an lvalue
[22:37] <ubitux> yes...
[22:37] <ubitux> in c++ that is.
[22:38] <ubitux> "c ? a : b = 1" -> will do b = 1 if c, otherwise nothing
[22:38] <Kovensky> unsurprising
[22:38] <ubitux> if !c sorry
[22:38] <Kovensky> never trust = unless in the simplest of cases
[22:38] <ubitux> "(c ? a : b) = 1" -> will do a = 1 if c, otherwise b = 1
[22:39] <ubitux> http://www.forumlocal.ru/user/upload/file17652.png everytime.
[22:41] <ubitux> nevcairiel: mmh just thought...
[22:41] <ubitux> wouldn't that be another c99-to-c89 issue?
[22:41] <ubitux> maybe it didn't like very much the macro
[22:41] <nevcairiel> it works in older compilers
[22:42] <nevcairiel> and when i use x87 fpu
[22:42] <nevcairiel> so doubtful
[22:42] <ubitux> hm, right
[22:42] <ubitux> nevcairiel: what if the exceptions are false positives?
[22:42] <nevcairiel> actually i dont know if it works in older compilers, x87 fpu was default in the older one
[22:42] <ubitux> and the fate mismatch is simply because of c99-to-c89 issue?
[22:43] <nevcairiel> still wouldnt explain the x87 vs sse2 difference
[22:43] <ubitux> oh well, by "works" you mean the fate test pass i guess?
[22:43] <nevcairiel> yes
[22:43] <ubitux> mh ok
[22:46] <nevcairiel> considering only I is off, is there an obvious place i can add debug output to compare values between working/non-working versions?
[22:47] <ubitux> let me see..
[22:48] <ubitux> nevcairiel: check in the if (loudness_400 >= ABS_THRES) scope maybe
[22:48] <ubitux> abd look at integrated_sum/nb_integrated
[22:49] <ubitux> if you have a mismatch here (which is likely according to the test)
[22:49] <ubitux> check power_400 and loudness_400 in that scope
[22:53] <Zeranoe> michaelni: I posted a bug report about the moov atom issue: https://ffmpeg.org/trac/ffmpeg/ticket/2435
[22:54] <burek> michaelni, this might help speed up compilations on fate clients, if you have enough ram (and will save your ssd surface of constant writes/deletes of temp files, during the build): http://www.cyberciti.biz/faq/howto-create-linux-ram-disk-filesystem/
[22:59] <nevcairiel> ubitux: the onlything different is integrated_sum
[22:59] <nevcairiel> which makes no sense to me
[22:59] <michaelni> burek, i dont think my SSD is the bottleneck for compilation speed and i suspect i dont have enough ram to setup a ramdisk large enough for each virtual machine
[22:59] <nevcairiel> the histogram->energy its being fed from is static, isnt it?
[23:00] <ubitux> it's initialized at startup iirc yes
[23:01] <ubitux> maybe ETOOBIG?
[23:01] <nevcairiel> i'll check the values in the energy things
[23:01] <nevcairiel> otherwise the loop is being broken by the compiler
[23:04] <nevcairiel> ubitux: the freaking values in that histogram array are different <.<
[23:04] <ubitux> :D
[23:05] <nevcairiel> broken has like 0.00 and 1.17 alternating
[23:05] <nevcairiel> what an odd pattern
[23:05] <ubitux> ow.
[23:05] <nevcairiel> the right one has nicely incrementing values
[23:06] <nevcairiel> but..how
[23:06] <ubitux> magic
[23:08] <ubitux> nevcairiel: it's skipping one out of two values, or it's incrementing the position too much (+2 instead of +!)?
[23:09] <ubitux> +1*
[23:09] <nevcairiel> its completely messed up
[23:09] <ubitux> :D
[23:09] <durandal_1707> hmm that but that Zeranoe reported happens with MSVC too
[23:10] <ubitux> durandal_1707: s/but/bug/?
[23:10] <durandal_1707> yes, (i need to lelearn typing)
[23:10] <durandal_1707> *shit again
[23:11] <nevcairiel> ubitux: looks like every second value in that histogram table is wrong
[23:11] <nevcairiel> every other is right
[23:11] <nevcairiel> smells like bad loop vectorization
[23:12] <ubitux> nevcairiel: try to switch loudness and enery in the struct
[23:12] <nevcairiel> luckily msvc has pragmas for everything, so i'm trying to turn off loop vectorization for that loop
[23:12] <nevcairiel> yeah that fixed it
[23:13] <nevcairiel> let me try yours
[23:13] <durandal_1707> so first thing to do is to make sure unix is ok with big files
[23:13] <kurosu> michaelni, tested your pshufd suggestion; while in some cases, it saves some mova and is an obvious save, in that case it is just weird
[23:13] <ubitux> durandal_1707: sounds like a "long" related issue
[23:14] <ubitux> durandal_1707: long being 32 on windows
[23:14] <nevcairiel> ubitux: no luck with yours
[23:14] <ubitux> nevcairiel: ok :(
[23:14] <nevcairiel> so its a compiler bug afterall
[23:14] <kurosu> michaelni, I mean, maybe it goes through different units now, but that was like a 10 cycles win here
[23:14] <durandal_1707> ubitux: you want to say that int64_t is long on windows and thus int32_t ?
[23:14] <nevcairiel> int64 is int64
[23:15] <nevcairiel> the only difference is that long is not 64-bit
[23:15] <kurosu> michaelni: I guess I have some major catchup to do, because I would always preferred writing pure sse code instead of mixing sse/sse2
[23:15] <durandal_1707> nothing should use long at first place
[23:15] <ubitux> durandal_1707: check the zlib usage
[23:15] <ubitux> iirc zlib is using long in its prototypes
[23:17] <durandal_1707> ubitux: is there better header to define int64_t ?
[23:17] <durandal_1707> *isn't
[23:17] <ubitux> mmh?
[23:18] <durandal_1707> whatever, if you know exact line that causes failure, than say so
[23:18] <ubitux> i didn't look at the issue
[23:19] <ubitux> but my first guess is that the sample has a cmov atom
[23:19] <ubitux> and using the zlib with "long" might cause problem
[23:19] <ubitux> (cmov = compressed with zlib atoms)
[23:21] <nevcairiel> zlib is at least unsigned long, and that code uses just long
[23:22] <nevcairiel> but i'm a bit puzzled, wouldnt this mean the whole cmov atom is larger then what fits into a long in bytes, and it then tries to read that whole thing in memory for decompression?
[23:22] <nevcairiel> sounds...bad
[23:22] <ubitux> the cmov atom should be a few megabytes max
[23:22] <ubitux> it's a compressed moov
[23:23] <nevcairiel> but why the long problem then?
[23:23] <ubitux> as i said, it's just a random guess :p
[23:23] <ubitux> i don't know if the sample even has a cmov
[23:23] <nevcairiel> i can download it and debug it in msvc, unlikely that anyone else ever would
[23:23] <durandal_1707> file is bigger than 4.5 gb and so int32_t is not enough (and signdenss is irrelevant)
[23:24] <ubitux> i've started to download the file myself
[23:24] <ubitux> but +24h
[23:24] <durandal_1707> can our muxer write cmov?
[23:24] <nevcairiel> says about 1h for me
[23:24] <ubitux> durandal_1707: i don't think so
[23:25] <nevcairiel> its also odd that the 64-bit version apparently works
[23:25] <ubitux> nevcairiel: my isp likes jokes
[23:25] <nevcairiel> short of stuff like size_t or intptr_t, datatypes dont really change size on windows
[23:25] <ubitux> maybe it doesn't work on unix32 either
[23:27] <durandal_1707> ubitux: that would be only for underlying file system limitation
[23:45] <saste> ubitux: ping on overlay?
[23:46] <ubitux> saste: x/y expr eval ?
[23:46] <saste> ubitux, yes, i addressed some of your concerns
[23:46] <ubitux> ok, give me 15 min
[23:47] <saste> also there is the command patch, which is a bit more complicated than i hoped
[23:48] <michaelni> kurosu, there are 2 integer SIMD shuffle units and just one float shuffle unit on modern intel cpus AFAIK
[23:48] <ubitux> saste: the "enable" looks debatable; why did you put it in the same patch?
[23:49] <saste> ubitux, because i squashed them by mistake, and was too lazy to split them again
[23:49] <ubitux> (it's debatable in the sense that i would see such thing at a higher level; aka apply the filter in given ts/frames ranges)
[23:49] <kurosu> michaelni, good to know, because penalty of using float and int insns seem to remain hypothetica
[23:49] <kurosu> (together)
[23:49] <saste> otoh they share the same logic, so it still make sense that way
[23:50] <saste> i can spend 10-20 mins splitting the patches again if you insist
[23:50] <ubitux> it's not that i insist, but i'm just not very fond of this enable thing in itself
[23:51] <ubitux> and i don't want to be a jerk and block the whole patch because of this :p
[23:51] <saste> ubitux: enable is based on the logic of a similar option in drawtext
[23:51] <ubitux> i don't like it either in drawtext
[23:51] <ubitux> :)
[23:52] <saste> for example an user might want to display an overlay every X seconds
[23:52] <saste> you could program a (custom filter) to do that, but seems easy enough to do it in the filter itself
[23:52] <saste> especially considering that right now we can't easily add custom logic
[23:53] <saste> the better way is to pass command through STDIN or write a C custom filter
[23:53] <ubitux> we should think about improving that soon
[23:53] <saste> hopefully with scripting we'll fix this
[23:53] <ubitux> because this "apply filter in this range" really is a pain
[23:54] <ubitux> (and very common)
[23:54] <ubitux> that's why i'm not so fond of having it in the filter itself
[23:54] <ubitux> at least applying in a seperate patch will make it easier for later to remove it
[23:54] <ubitux> IMO :p
[23:54] Action: ubitux going to review for real
[23:56] <saste> ubitux: enable=between(t, 10, 20)
[23:56] <saste> not that painfull
[23:56] <saste> also consider that we have sendcmd
[23:56] <ubitux> yes, for filters supporting it
[23:56] <ubitux> i'd like to have it in at least half of the filters we have
[23:56] <ubitux> ...and not require them to have internal code for this
[23:57] <ubitux> in the filter, it should only require the implementation of a "passthrough" function
[23:58] <ubitux> (which could be set to a generic one for simple 1:1 filters)
[23:58] <ubitux> (or to a very simple function such as f() { foobar->var_values[VAR_N] += 1 ... } for more complex ones)
[23:58] <burek> michaelni, if you have enough ram, you could setup only 1 ramdisk and present it like a shared folder to all your vms
[00:00] --- Sat Apr  6 2013