Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2013

1 participants
62 discussions

ffmpeg-devel.log.20131030
by burek 31 Oct '13

31 Oct '13

[00:19] <llogan> michaelni: disabled by default [00:21] <llogan> i see cehoyos wants auto. i don't really care that much. [00:21] <llogan> i just prefer to manually enable most stuff [00:25] <michaelni> well iam not smarter now if one says yes and one no :) [00:25] <michaelni> ill leave it to you and carl to flame it out [00:26] <llogan> i have other things to do. you can auto it. [00:45] <BBB> ubitux it's ok to factor things after commit :) [00:45] <BBB> ubitux: but whichever way you prefer [00:57] <llogan> michaelni: tickets 3096, 3097, and 3098 are spam [00:58] <llogan> i already trained the bayes [01:03] <michaelni> llogan, removed [01:05] <llogan> michaelni: thanks [02:15] <cone-562> ffmpeg.git 03Michael Niedermayer 07master:e1848aa469b7: avcodec/mpeg12dec: forward errors when EXPLODE is set [07:34] <Zeranoe1> Is there a reason lto isn't enabled by default? Is it unstable? [09:40] <ubitux> saste: nicolas was fine to remove his name from the copyright holders in the decoding example i submitted; i added mine just because there were some; do you mind if i don't add yours? (i find a bit silly to provide copyrighted api examples) [09:40] <michaelni> has someone run benchmarks on lto ? compile time / runtime ? [09:42] <durandal_1707> lto? [09:42] <cone-863> ffmpeg.git 03Anton Khirnov 07master:5c0a09839c70: libopenjpegdec: return meaningful error codes [09:42] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:4427fe7e4bf6: Merge commit '5c0a09839c707f10e5dba59460e219e989c1da93' [09:43] <ubitux> durandal_1707: link time optim [09:47] <saste> ubitux, fine to remove my name [09:48] <ubitux> saste: ok, thanks [09:48] <ubitux> i'm going to add audio decoding [09:48] <ubitux> anyone has a sample that requires multiple decode for a single packet? [09:48] <saste> ubitux, fine with me, but keep in mind that the more examples we have, the more effort we need to spend on them [09:49] <ubitux> saste: maybe we can drop some [09:49] <ubitux> when this one is in [09:49] <ubitux> saste: also, this example is useful: it is easy to use, easy to valgrind-test, and allows to check both API modes [09:50] <durandal_1707> remove mp2 example it is useless [09:51] <ubitux> decoding_encoding? [09:51] <saste> what happened of the example posted in libav-devel? [09:52] <ubitux> they never push it [09:52] <durandal_1707> K&R [09:52] <ubitux> should we steal it? [09:52] <durandal_1707> if you are lazy [09:52] <saste> probably if it's useful [09:53] <saste> but same considerations as before [09:53] <saste> i can hardly do any relevant thing these days [09:53] <saste> this happens when you have a lot of code to maintain [09:56] <wm4> lol at that opencl discussion [09:57] <nevcairiel> why is that public API anyway [09:57] <nevcairiel> anyhow, i support the concept of certain parts of the API just not being stable yet, and not falling under API/ABI requirements [09:58] <beastd> We need a API/ABI incubator? [09:59] <saste> nevcairiel, note that the opencl API was always marked as experimental [09:59] <saste> if an user relied on that and we broke it, she can't complain [10:00] <nevcairiel> if that means its not required to be API compatible, thats fine [10:00] <saste> that or we wouldn't never had that API in the first place [10:02] <wm4> what I found funny is that the ffmpeg code was considered an (unmaintained) external snapshot by the devs, which they want to update now [10:05] <durandal_1707> what devs? [10:11] <av500> all devs [10:13] <durandal_1707> what all devs? [10:15] <durandal_1707> #include "h264data.h" // FIXME FIXME FIXME [10:24] <cone-863> ffmpeg.git 03Anton Khirnov 07master:b9589f5a770e: lavc: add error checking to apply_param_change. [10:24] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:558784f113f1: Merge commit 'b9589f5a770ec2357ab7920a5fabe8510b8601f9' [10:32] <wm4> durandal_1707: multicoreware [10:33] <cone-863> ffmpeg.git 03Anton Khirnov 07master:d4c12b8be4bd: oggparsetheora: K&R cosmetics, reformat [10:33] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:70737b83f06e: Merge commit 'd4c12b8be4bdd2ffddb3bd5e11773de4c4c46f68' [10:41] <cone-863> ffmpeg.git 03Anton Khirnov 07master:5e5fb21877d8: oggparsetheora: return meaningful error codes [10:41] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:0b9e480b8f3b: Merge commit '5e5fb21877d8da7b3b8a27bb4d6a070d210c152d' [10:53] <cone-863> ffmpeg.git 03Anton Khirnov 07master:4f2d8968c04e: oggparsetheora: check av_mallocz result [10:53] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:7fd7a10efde7: Merge remote-tracking branch 'qatar/master' [11:01] Action: ubitux realizes he still doesn't understand shit about how to decode properly audio with FFmpeg API [11:02] <nevcairiel> its not too different to video, except that you have to implement the partial buffer decoding thing properly, because its used for many formats [11:14] <ubitux> nevcairiel: it's a bit tricky to do properly [11:14] <ubitux> there is also that cap delay thing btw [11:26] <wm4> further lol at opencl discussion [11:27] <wm4> now improvement is stifled, even though most likely nobody uses the opencl headers [11:28] <nevcairiel> these arguments about mixing library versions are always fun, while in reality its most likely going to blow up anyway [11:29] <nevcairiel> if i add new stuff to a library and use that in another library, it would blow up if the user only updates one of them [11:29] <nevcairiel> well, the wrong one of them :p [11:30] <wm4> indeed, it would be nice if libav* would stop pretending to be independent of each other [11:51] <ubitux> we could have in each library a #define AVFORMAT_LAST_COMPATIBLE_AVCODEC_VERSION, AVFORMAT_LAST_COMPATIBLE_AVUTIL_VERSION, etc [11:52] <ubitux> or simply a hard check [11:52] <ubitux> in each of them [11:53] <wm4> how about a single, unified version number [11:53] <wm4> say, FFMPEG_VERSION [11:53] <wm4> hm needs AV prefix [11:53] <wm4> AV_FFMPEG_VERSION [11:54] <wm4> it would be incremented every time a version of a sub-library is changed [11:54] <av500> LIBAV_FFMPEG_VERSION [11:55] <wm4> and you could distinguish ffmpeg vs. libav by checking whether AV_FFMPEG_VERSION or AV_LIBAV_VERSION exists [11:55] <wm4> if a 3rd fork shows up, just get your guns [11:57] <Daemon405> [10:53] <+wm4> how about a single, unified version number [11:57] <Daemon405> i have been arguing for this for years [11:57] <Daemon405> neither side wants t [11:57] <Daemon405> it [11:57] <Daemon405> despite the fact that the libraries are essentially useless [11:57] <av500> a single version number for 2 different pieces of code? [11:57] <Daemon405> unless theyre from the same version [11:57] <wm4> because it would be the obvious, good thing to do? [11:57] <av500> lets call both 54 [11:57] <av500> ah you mean per project :) [11:57] <Daemon405> av500, no i mean the inter-library deps make independent library versioning retarded [11:57] <Daemon405> and useless [11:58] <av500> that yes [11:58] <Daemon405> its a major headache for downstream (me) [11:58] <wm4> you have 28 version number to care about [11:58] <av500> all these versions are useless [11:58] <Daemon405> it would be much nicer with a single unified version [11:58] <wm4> 14 for each fork [11:58] <Daemon405> for all of ffmpeg [11:58] <av500> true [11:58] <wm4> 7 compile versions, and 7 link versions [11:58] <Daemon405> literally every downstream says this [11:58] <Daemon405> every single one. [11:58] <nevcairiel> i don't [11:58] <nevcairiel> :D [11:58] <wm4> 7 because lavc, lavf, sws, swr, lavd, postproc are separate [11:58] <av500> if the linux kernel can be one version, so can libav/ffmpeg [11:58] <wm4> and lavu [11:59] <Daemon405> and lavr [11:59] <ubitux> i'd be fine with libffmpeg [11:59] <Daemon405> in practice the versions are useless [11:59] <Daemon405> since everything depends on everything [11:59] <Daemon405> and it clutters my coke with a billion huge version checks [11:59] <wm4> the versions also make it hard to write code that works everywhere [11:59] <Daemon405> yes [11:59] <nevcairiel> one could argue that if you only use avutil (for whatever silly reason you would!), you dont need to update as often :p [12:00] <Daemon405> 0 people do that [12:00] <wm4> what about mplayer compiled without lavc/lavf? [12:00] <wm4> (it supports that) [12:00] <nevcairiel> wait, arguments need to map to reality now? [12:00] <Daemon405> lol [12:00] <Daemon405> wm4, mplayer is not downstream [12:00] <Daemon405> it's same-stream [12:00] <nevcairiel> lol [12:00] <wm4> I was just providing the only existing and also absurd use case that exists for this [12:01] <ubitux> isn't vlc only using lavc or something? [12:01] <nevcairiel> at some point i did consider using avutil in a small project that didnt need lavf or lavc otherwise [12:01] <wm4> ubitux: pretty sure vlc supports all aspects of ffmpeg [12:01] <nevcairiel> but i gave up and just stole two functions that i wanted [12:01] <durandal_1707> wm4: aspects? [12:01] <Daemon405> i dont really understand the 'usefulness' of separate lib versions for everything [12:01] <wm4> durandal_1707: decoding, demuxing, etc [12:01] <Daemon405> in practice its pretty useless for lav* [12:02] <durandal_1707> i do not agree [12:02] <Daemon405> yes its been well established [12:02] <wm4> even if someone wants to use only part of it, they can configure it so at compile time [12:02] <Daemon405> the ffmpeg and lbav devs thing its Oh So Useful [12:02] <Daemon405> while literally every downstream hates it [12:02] <wm4> just like to can strip down lavc to contain only a h264 decoder etc. [12:02] <wm4> s/to/you [12:03] <durandal_1707> there was libavcore [12:03] <Daemon405> im not saying separate libs are bad [12:03] <av500> durandal_1707: bring libavcore back [12:04] <ubitux> can someone with a debian system (or whatever other distro splitting packages) check what packages are depending on what libraries? [12:04] <ubitux> so we can have an overview of that "every downstream" [12:05] <ubitux> siretart: could you do that? [12:05] <wm4> ask them whether they ever mismatch library versions [12:05] <wm4> well, mismatch or mix [12:06] <wm4> (using different sub-libs at compile or runtime) [12:06] <Daemon404> nobody does [12:06] <ubitux> the interesting part is to know if some project relies on libavcodec only and don't need libavformat for example [12:06] <Daemon404> people aways use it fro teh same release / clone [12:07] <wm4> ubitux: again, these can disable the unused parts at compile time [12:07] <wm4> or they use a shared system lib, in which case it doesn't matter [12:07] <Daemon666> iirc some only use libswscale [12:07] <ubitux> wm4: think packaging [12:07] <Daemon404> ubitux, in practice using lavc is not so fun [12:07] <Daemon404> the projects than *can* like vlc and ffms2 [12:07] <wm4> packaging, and? [12:07] <av500> I used lavc only in the past [12:07] <Daemon404> have to copy/paste the codec id mappings [12:07] <ubitux> wm4: think about a system where you don't have the libav* libraries, and you want to install a software which only depends on libavcodec for instance [12:07] <av500> worked for me [12:07] <av500> I just needed codecs [12:08] <av500> you cannot use only lavf though [12:08] <ubitux> wm4: in that situation, you wouldn't want to grab all the libraries [12:08] <av500> it pulls in lavc or is useless [12:08] <Daemon666> av500: what you used to demux? [12:08] <ubitux> but just libavcodec, and the app [12:08] <av500> Daemon666: my own sauce [12:08] <wm4> ubitux: even then you don't need separate lib versions [12:08] <Daemon404> ^ [12:08] <wbs> Daemon404: I'm so fucking tired of hearing you cry about the codec mappings. if you use an external non-lavf demuxer to demux, your demuxer should tell you that this one fourcc actually is h264 or whatever that is, using that demuxer's api. then you map that one demuxer definition of h264 to the lavc one [12:08] <av500> Daemon404: partly still do [12:08] <ubitux> wm4: sure [12:08] <wbs> Daemon404: seriously stoU it [12:09] <wm4> (in the unlikely caseyou want to reduce binary size by splitting ffmpeg intpo sub-.libs) [12:09] <ubitux> wm4: that is another point, i was wondering about a single lib [12:09] <av500> wbs: thats what I did [12:09] <Daemon404> wbs, i didnt say it was wrong [12:09] <Daemon404> i said its no fun [12:09] <av500> of course I mapped my H264 to CODEC_ID_H264 [12:09] <Daemon404> so calm down [12:09] <wbs> Daemon404: yes. stop nagging about it [12:09] <av500> etc.. [12:09] <Daemon404> im not nagging for anything [12:09] <Daemon404> i have requested no hange to accomodate it [12:09] <wbs> Daemon404: if you use an external demuxer, the external demuxer should take care about it. if not, why are you using a crappy external demuxer for it? [12:10] <Daemon404> i am *agreeing* with you [12:10] <Daemon404> jeez [12:10] <Daemon404> not fun != not correct [12:10] <wm4> (there are plently of better demuxers outside of lavf) [12:10] <wbs> wm4: I don't disagree with that [12:10] Action: av500 hugs his asf parser [12:11] <wbs> wm4: but "my external demuxer only says that this is RIFF <foo> and I need the lavf table mapping to tell me what lavc codec this corresponds to" gets tiresome [12:11] <Daemon404> wbs, so calm down... im saying youre right. [12:11] <wbs> Daemon404: yes. so stop bringing this topic up then [12:11] <Daemon404> when asking why people dont use lavc with ~lavf [12:11] <wm4> doesn't lavf export some fourcc tables anyway? [12:11] <Daemon666> wm4: what better demuxers than lavf have? [12:11] <Daemon404> er !lavf [12:11] <Daemon404> it is a legitimate response [12:11] <nevcairiel> you cna even get the RIFF tables from lavf these days [12:11] <Daemon404> peopel simply cant be arsed to [12:11] <wm4> Daemon404: e.g. many vlc demuxers [12:11] <wbs> wm4: yes, for riff stuff. for generic other containers, no [12:12] <wm4> even mplayer's sometimes perform better than lavf [12:12] <Daemon404> wm4, player's asf demuxer is much nicer [12:12] <Daemon404> mplayer* [12:12] <Daemon404> even tho its horrible too [12:12] <Daemon666> is just bugs nobody want to fix [12:12] <Daemon404> asf demuxer isnt bugs [12:12] <Daemon404> it needs a ground up rewrite [12:12] <Daemon404> from spec [12:13] <Daemon404> but nobody wants to [12:13] <Daemon404> =p [12:13] <wbs> Daemon404: and for the original topic, debian packages the libav* libraries in separate packages, so you can easily upgrade libavutil without upgrading every single one of the other ones [12:13] <wbs> whether you think that's good or not, that's up to you [12:13] <Daemon404> separate libs and packages are not necessarily separate versions [12:13] <Daemon666> Daemon404: iirc that spec is fake [12:13] <Daemon404> i have a copy of the one MS sends to its partners [12:13] <Daemon404> i doubt it's fake [12:13] <Daemon404> merely wrong [12:13] <wm4> an evil twin appeared [12:14] <wm4> I didn't notice at first [12:14] <wbs> no, but they don't force you to upgrade them in sync either, and you can have separate versions installed in parallel to work with binaries that use the old ABI [12:14] <Daemon404> wbs, thats more or less a fringe feature in my eyes. i so very arrely see it used [12:15] <Daemon404> even debian's use case doesnt make use of it really [12:15] <wbs> well if you don't see and understand it, that's your loss [12:15] <Daemon404> i certainly feel it though [12:15] Action: Daemon404 stares at his soup of version checks [12:16] <wm4> why don't we split every lavc decoder into its own so, and version it separately? [12:16] <wm4> even more fun for distros [12:16] <Daemon404> (supporting >1 version of libav/ffmpeg) [12:16] <Daemon666> wm4: make each demuxer/muxer/decoder/encoder/filter separate project? [12:16] <wm4> just separate libraries [12:16] <Daemon404> nice strawman [12:18] <Daemon404> i suppose this is kind of an atifically created issue [12:18] <Daemon404> due to the massive api churn [12:18] <Daemon666> wm4: it would be nightmare, only thing i want is separate build of libs, so adding new demuxer does not need to recompile all shit [12:18] <Daemon404> i dream of a day when libav* stops changing api for a while [12:18] <Daemon404> :D [12:18] Action: Daemon404 runs [12:18] <wm4> but then the API will stay horrible [12:19] <nevcairiel> you have not used truely horrible api then [12:19] <Daemon404> isnt that *why* it's changing [12:19] <wm4> yes [12:19] <Daemon404> one assumes it will be replaced by non horrbiel things [12:19] <Daemon404> and then top changing so often [12:19] Action: Daemon666 wonders what needs changing (besize libswscale) [12:19] <Daemon404> but thats just my dream. [12:20] <BBB> why do we have 2 daemons? [12:20] <BBB> that's awful for tab completion [12:20] <Daemon404> and id take a slightly bad and stable api over a constantly changing one any day [12:20] <Daemon404> BBB, one is paul [12:20] <BBB> aha [12:20] <nevcairiel> but we wont tell you which [12:21] <Daemon404> there's an entire cottage industry around libav* [12:21] <Daemon404> that is "using the cli" or "using the api" [12:21] <Daemon404> since it's so 'lovely' [12:21] <Daemon404> :D [12:41] <cone-863> ffmpeg.git 03Paul B Mahol 07master:62ef736f5a01: avcodec/motionpixels: use av_fast_padded_malloc() [12:41] <cone-863> ffmpeg.git 03Paul B Mahol 07master:c783bec6dc57: avcodec/mdec: use av_fast_padded_malloc() [12:41] <cone-863> ffmpeg.git 03Paul B Mahol 07master:2820562935e7: avcodec/4xm: use av_fast_padded_malloc() [12:41] <cone-863> ffmpeg.git 03Paul B Mahol 07master:1de8dfcbc494: avcodec/binkaudio: use init_get_bits8() [12:41] <cone-863> ffmpeg.git 03Paul B Mahol 07master:2508fa10c618: avcodec/xan: use init_get_bits8() [12:41] <cone-863> ffmpeg.git 03Paul B Mahol 07master:49c6f0ae15a0: avcodec/apedec: use init_get_bits8() [12:42] <cone-863> ffmpeg.git 03Paul B Mahol 07master:82e576046c6b: avcodec/wavpack: use init_get_bits8() [12:42] <cone-863> ffmpeg.git 03Paul B Mahol 07master:8e609eb475fe: avcodec/utvideoenc: use av_fast_padded_malloc() [12:42] <cone-863> ffmpeg.git 03Paul B Mahol 07master:268d0d6e6c89: avcodec/svq3: use av_fast_padded_malloc() [12:42] <Daemon666> its not fun any more [12:42] <Daemon999> tracking library interdependencies is hard => must be done by hand [12:42] <saste> we have micro to accomplish that, but hardly anyone remembers to update it properly [12:42] <saste> and nobody is tracking the interdependencies [12:43] <saste> that said, a unique progressive id can be created [12:43] <saste> but i don't know what would be the proper place where to put it [12:44] <saste> Daemon404, indeed i don't know which is the proper fdk-aac repository [12:44] <Daemon404> the one i linked [12:45] <saste> allright i'll trust you [12:45] <Daemon404> the one you have currently is wbs's personal repo [12:50] <Daemon666> huh, did not update png lib and now i lost all icons [12:50] <Daemon666> that is called stable api [12:52] <saste> ubitux, "private" in ffmpeg has a special meaning [12:53] <saste> it means "non-shared" [12:53] <ubitux> i'd use "specific" but ok [12:57] <saste> ubitux: http://ffmpeg.org/ffmpeg-codecs.html#toc-Codec-Options [12:58] <ubitux> ok ok [13:14] <beastd> yeah, the "private" options lingo sucks IMHO [13:14] <ubitux> saste: the decoding example i'm writing can probably replace the "demuxing" example [13:36] <ubitux> saste: "Also, some decoders might over-read the packet." [13:36] <ubitux> seriously? :) [13:36] <ubitux> (doc/examples/demuxing.c) [13:37] <nevcairiel> isnt that in there to explain why the padding is mandatory [13:38] <Daemon666> yes, decoders are free to overread, you must have 0(what about FFFF?) padded packet [13:38] <Daemon666> michaelni: why is my get_bits patch ignored? [13:38] <ubitux> oh, mmh ok [13:39] <saste> ubitux: 06b269dac [13:39] <ubitux> yeah i see that's nice [13:39] <ubitux> btw, we should follow that logic in src_movie [13:39] <Daemon666> nooooooooo, that hack should be finally fixed with new api [13:48] <michaelni> durandal666, which get_bits patch ? [13:50] <michaelni> there where several and most i applied broke fate [13:50] <michaelni> applied locally that is [13:51] <Daemon666> last one [13:53] <michaelni> breaks fate [13:54] <michaelni> also i do not understand what these patches are supposed to fix [13:54] <michaelni> make: *** [fate-vsynth1-dv-411] Error 1 [13:54] <Daemon666> michaelni: what fate test? [13:55] <michaelni> make: *** [fate-vsynth1-dv] Error 1 [13:55] <michaelni> not sure if these are the only ones as i didnt use make -k [13:55] <Daemon666> well all those codecs are broken as they call init_get_bits with 0 as size [13:57] <michaelni> your patch makes size=0 an error [13:58] <Daemon666> last one does not [13:58] <cone-863> ffmpeg.git 03Paul B Mahol 07master:387e76f9934c: avcodec/mdec: use dsp.bswap16_buf() [14:02] <michaelni> your patch corrupts bit_size when its 0 [14:05] <michaelni> also it no longer sets buffer to NULL when bitsize is negative [14:05] <michaelni> and i still dont know what this patch is trying to do [14:06] <michaelni> but iam spending hours debuging it for you [14:06] <Daemon666> because you still fail to find that get_bits1 crash when you set buffer to null [14:06] <Daemon666> and that happens when you do not check return code of init_get_bits [14:07] <michaelni> so why do you ignore my repeated questions about what this fixes ? [14:07] <Daemon666> on other case for 0 size it may loop forever if you do while(get_bits()) [14:08] <michaelni> while(get_bits) is not a good idea, its not robust [14:08] <michaelni> it will loop or crash when the padding isnt there or not zeroed [14:08] <Daemon666> yes, but do not blame me... [14:09] <Daemon666> anyway all init_get_bits that can have very big size for buffer should be updated to check for return code [14:11] <Daemon666> actually i fixed such nonsense in tta [14:29] <cone-863> ffmpeg.git 03Paul B Mahol 07master:65988b991659: avcodec/cook: fix deadlock by using get_unary() [14:29] <ubitux> saste: infinite loop at the end of demuxing [14:29] <ubitux> (demuxing.c) [14:30] <ubitux> these examples are all nicely broken in their own way [14:35] <saste> yes so the user will exercise his debugging skills [14:35] <saste> we get very few reports anyway, so i wonder if someone is actually using them [14:35] <saste> i tend to work on them just when the need arise, e.g. when i use or update the API [14:38] <cone-863> ffmpeg.git 03Clément BSsch 07master:0c6bb53bb28c: doc/examples/demuxing: reset got_frame. [14:40] Action: Daemon666 got trac internal error [14:41] <Daemon666> DatabaseError: database disk image is malformed [14:43] <Daemon666> who should i punish? [14:48] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:9f5b75f2416c: avcodec/flacdec: make while get_bits loop more robust by checking bits left [14:48] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:b0f8b5c8190a: avcodec/flvdec: make while get_bits loop more robust by checking bits left [14:48] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:719dbe86ea0e: avcodec/h261dec: make while get_bits loop more robust by checking bits left [14:48] <Daemon666> ubitux: titles of commit message do not need dot (.) at end [14:48] <ubitux> it shows if the message is truncated or not [14:49] <ubitux> Daemon666: wanna fight a nitpick battle with me? [14:49] <Daemon666> ubitux: you will lose [14:50] <Daemon666> michaelni: i do not like 9f5b75f2416c [14:53] <Daemon666> it this only me, or trac behaves strangely lattely [14:54] <Daemon666> it is gone [14:55] <michaelni> its the same issue probably that is reoccuring since a few months [14:55] <michaelni> once every few weeks or so [14:57] <Daemon666> who is maintainer and have any access to that machine? [14:57] <beastd> Daemon666: i am on it [14:59] <Daemon666> is hardware issue or something else? [15:00] <beastd> Daemon666: seems to be a software issue. but i was not able to track it down yet. [15:11] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:4b12930f79ed: avcodec/flacdec: use get_unary() simplify code [15:11] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:489c575bd6f8: avcodec/ivi_common: make while get_bits loop more robust by checking bits left [15:11] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:810f9c5eaac2: avcodec/ituh263dec: make while get_bits loop more robust by checking bits left [15:11] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:94a80e36d307: avcodec/intelh263dec: make while get_bits loop more robust by checking bits left [15:16] <beastd> Daemon666: Trac should be working again. [16:54] <Daemon666> how much is get_bits1 fast/slow compared to get_bits(,1)? [16:59] <kierank> Daemon666: not a confusing nick at all [17:18] <saste> can MOV fragmentation help with playback delay? [17:18] <saste> the idea is to reduce the size of the initial MOOV atom [17:19] <saste> with a big file it can be on the order of several MiB [17:19] <av500> on a slow connection? [17:19] <av500> yes, MOV is brilliant like that [17:20] <saste> but then I don't know how many players will be able to decode segmented MOV [17:22] <av500> mine wont :) [17:22] <saste> or it is just hopeless to have low delay playback with streamed MP4 content? [17:23] <av500> its not really streamed [17:23] <av500> its a download [17:23] <saste> but players will start to buffer just after the header has been downloaded [17:24] <saste> so the initial header size will add to the startup time [17:25] <av500> yes [17:25] <av500> of course the time to download the MOOV atom will delay plabayk start [17:26] <saste> any cure to that (fragmentation)? [17:26] <saste> or is it just "use a different technology"? [17:26] <av500> didnt know fragmented MOOV exists [17:26] <av500> it would be a way [17:27] <ubitux> saste: any comment on the rename? [17:27] <saste> ubitux, i'll comment on that tonight, i have to leave now [17:27] <ubitux> ok [17:27] <av500> saste: or do you mean DASH streaming? [17:27] <av500> with "fragmented" [17:27] <saste> but when i implemented that i was indeed thinking about a demuxing example [17:28] <saste> av500, possible [17:29] <av500> well, in DASH, fragments are only a few seconds long [17:29] <av500> so startup is fast [17:29] <av500> but its DASH, not just http://foo/bar.mp4 [17:29] <saste> how does it look like? [17:29] <av500> two different things [17:29] <saste> is that supported by ffmpeg? [17:29] <av500> an XML file [17:30] <av500> describing the pieces [17:30] <av500> yes [17:30] <saste> and what's more important, is that supported by most players? [17:32] <av500> plain MOV [17:33] <av500> DASH is not a file format [17:33] <av500> its a streaming protocol [17:34] <saste> well i'll have to do some research [17:34] <saste> bye [17:37] <ubitux> http://pastie.org/8443149 [17:37] <ubitux> any idea what this leak is about? [17:41] <durandal_1707> lazy incompetent programmer? [17:43] <nevcairiel> ubitux: sounds like the lockmgrs mutex was not freeed properly [17:57] <cone-863> ffmpeg.git 03Martin Storsjö 07master:0c5f839693da: lavf: Remove a now useless parameter to ffurl_register_protocol [17:57] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:7f019129e1bd: Merge remote-tracking branch 'qatar/master' [18:31] Action: durandal_1707 just got someone that use -sameq [18:35] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:44e8e82d347f: avcodec/get_bits: add skip_1stop_8data_bits [18:35] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:34087b05642a: avcodec/dxva2_mpeg2: Use skip_1stop_8data_bits() [18:36] <durandal_1707> heh [18:36] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:9c284a8e1935: avcodec/flvdec: Use skip_1stop_8data_bits() [18:36] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:711e981276d0: avcodec/h261dec: Use skip_1stop_8data_bits() [18:36] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:ddc6ed91873e: avcodec/intelh263dec: Use skip_1stop_8data_bits() [18:36] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:f4d312719747: avcodec/ituh263dec: Use skip_1stop_8data_bits() [18:36] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:c882b62d14f6: avcodec/svq1dec: Use skip_1stop_8data_bits() [18:36] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:9c7662aeba99: avcodec/svq3: Use skip_1stop_8data_bits() [18:36] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:f03153181640: avcodec/vaapi_mpeg2: Use skip_1stop_8data_bits() [18:44] <Daemon404> that is some.... [18:45] <Daemon404> "interesting" function naming [18:45] <Daemon404> generated via markov chain? [18:48] Action: kierank finally gets round to testing durandal_1707's smpte bars [18:48] <kierank> might even move to ffmpeg [18:56] <ubitux> from what? [18:57] <Daemon404> thats a silly question [18:59] <durandal_1707> ubitux: it is joke [18:59] <ubitux> :( [19:01] <Daemon404> it wasnt [19:01] <kierank> durandal_1707: i'm not joking [19:02] <kierank> depends how diverged swscale is to be honest [19:02] <ubitux> what divergence are you afraid of? [19:02] <kierank> I have a lot of changes to swscale [19:02] <ubitux> ah [19:02] <ubitux> ok :) [19:03] <kierank> they are a pretty big speed improvement for me but they don't work with all the yuv combinations [19:03] <ubitux> and you didn't submit patches :( [19:03] <kierank> because they break fate [19:03] <Daemon404> becase he threw out bunch of stuff [19:03] <durandal_1707> he meant avscale [19:04] <kierank> yes I threw out stuff for speed as well [19:04] <kierank> durandal_1707: i am not a libav die hard you know [19:09] <kierank> though I am trying to figure out how to use testsrc with yuv422p [19:10] <ubitux> ./ffmpeg -f lavfi -i testsrc,format=yuv422p -f null - [19:10] <ubitux> ? [19:12] <durandal_1707> i can change default from yuv420p to yuv422p [19:13] <kierank> ubitux: thanks [19:13] <kierank> i was trying -pix_fmt yuv422p [19:13] <durandal_1707> though testsrc only supports rgb [19:14] <ubitux> [auto-inserted scaler 0 @ 0x1cc3360] w:320 h:240 fmt:rgb24 sar:1/1 -> w:320 h:240 fmt:yuv422p sar:1/1 flags:0x2 [19:14] <ubitux> indeed [19:14] <kierank> i meant smptehdbars of course [19:14] <kierank> not testsrc [19:14] <ubitux> in that case it works :) [19:17] <kierank> i assume using vf_text requires a conversion to rgb [19:18] <kierank> drawtext of course [19:20] <ubitux> it's using drawutils, which is supposed to support yuv-like fmt [19:20] <ubitux> (see ff_draw_init) [19:27] <ubitux> ./ffmpeg -v verbose -f lavfi -i smptehdbars,format=yuv422p,drawtext=text=kierank -f null - [19:27] <ubitux> i don't see any auto inserted filter [19:45] <vitruvian> I need a little help... I'm trying to write in a raw socket within a protocol I made, just to test I did a small program to send a raw ethernet frame. But when I try to agregate that to ffmpeg sendto returns -1... failing [19:52] <durandal_1707> vitruvian: sendto is libc here [19:57] <kierank> ubitux: yeah seems to work [19:58] <durandal_1707> just needs aevalsrc [20:01] <vitruvian> can't I use sendto inside ffmpeg durandal_1707 ?! [20:02] <vitruvian> I mean... udp uses sendto, so I guess I can [20:13] <vitruvian> I have exactly the same structure at ffmpeg and other c implementation for raw socket... someone have a hint on why in ffmpeg sendto returns -1?! [20:19] <ubitux> BBB, wm4: i added a longer version of the sample from last time if you want; http://lucy.pkh.me/samples/vp9/etv5000.webm [20:20] <wm4> I'll downloading that [20:34] <wm4> ubitux: weird choice of source video, because it has all these black flashes [20:35] <ubitux> yeah but i like it because there are a lot of ± fast motions, and color fucks [20:35] <ubitux> wm4: the black flashes are the eyes blinking yes, and i think that's a pretty good use case actually [20:36] <ubitux> since vp9 is using multiple reference frames i wonder if the encoders deels properly with this :) [20:45] <{V}> vitruvian, did you check errno ? [21:04] <durandal11707> llogan: is dalu547 subsribed or not? [21:08] <llogan> durandal11707: what's the address? [21:09] <llogan> durandal11707: no. (and I assume you mean -user) [21:15] <durandal11707> yes, they write mail, do not subscribe, and when they do not get reply, send same message over and over again [21:18] <llogan> ...and if you cc or bcc them they reply directly to you instead of list [21:26] <vitruvian> {V}: I managed to find out, thanks a lot =] [21:26] <{V}> congrats :) [21:36] <vitruvian> Other thing... I need to send 1500 bytes over the network only (frame), but the buffer in X_write is 11000, I see udp implements a list but there is a way to shrink the buffer size? [21:38] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:18802942d1a2: avcodec/mpeg12dec: Use skip_1stop_8data_bits() [21:54] <cone-863> ffmpeg.git 03Reimar Döffinger 07master:4fab08c94f83: Optimize pure C unscaled yuv2rgb. [22:00] <Mista_D> If one wants to call DSP from ffmpeg to encode YUV to HEVC, where does he start? [22:03] <{V}> vitruvian, Mista_D, is this applicable "Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg" ? I don't mean to send you away, I just don't want you to feel ignored. [22:06] <Mista_D> {V}: Its more a developer related question than a user one, but I will try asking it in ffmpeg channel as well. Thank you. [22:07] <{V}> Mista_D, you intend to improve ffmpeg? "Discussions about the development of FFmpeg itself are ontopic here." [22:10] <Mista_D> {V}: Not sure yet, but it will involve buying a TI card in any case. [23:38] <cone-863> ffmpeg.git 03Michael Niedermayer 07master:cc0e47b55096: avcodec/jpeglsdec: check err value for ls_get_code_runterm() [00:00] --- Thu Oct 31 2013

1 0

ffmpeg.log.20131030
by burek 31 Oct '13

31 Oct '13

[01:34] <everald> Hello. I want to record video and audio from a USB video frame grabber device. [01:34] <everald> ffmpeg -threads 2 -f alsa -i hw:1,0 -f video4linux2 -i /dev/video0 myvid.mp4 [01:35] <everald> seems to do it except 1-2 seconds into the recorded stream, there is a skip (loss of video) and from thereon audio is not in sync anymore either. [01:35] <everald> Any suggestions? [01:36] <everald> Also, the above uses about 120% cpu, perhaps I should choose a lighter codec? But I don't understand enough, and it seems ffmpeg chooses the codec or something from the file suffix, too, which messes up my attempts. [01:36] <everald> Also, it would be nice to use an encoding that allows me to play the file before recording is finished. [01:37] <everald> Also, suggestions for a suitable front end are welcome (VLC is the only program I got running with both video and audio, but it didn't allow me to set deinterlacing (gave some error msg, or menu was greyed out)). [01:42] <everald> http://pastie.org/8441479 [02:09] <llogan> everald: that's not ffmpeg [02:10] <llogan> we didn't make that so we can't support it here [02:11] <llogan> http://trac.ffmpeg.org/wiki/UbuntuCompilationGuide [07:35] <Jerky> Hi everyone, ffmpeg -r 1/15 -i img%1d.png -r 30 test.mpg doesn't working, why? -r = 1/15, and -r = 30, so why there is no 1 image every 15 seconds? [07:36] <Jerky> "ffmpeg -r 1/15 -i img%1d.png -r 30 test.mpg" [07:59] <hendry> hmm, I'm getting Undefined constant or missing '(' in 'auto', Unable to parse option value "auto" [07:59] <hendry> only place I use "auto", is in `-threads auto` [09:17] <relaxed> hendry: threads are auto by default [09:17] <relaxed> for libx264 [09:49] <hendry> relaxed: ok, I've made that assumption and just removed them https://github.com/kaihendry/recordmydesktop2.0/commit/b09fa9e1a0494d3f817a… [10:01] <relaxed> the setting used to be -threads 0 [10:27] <hendry> relaxed: -threads auto worked for me until a recent upgrade [11:28] <vl4kn0> Hi, let's say I've got two videos that are exactly the same except one is in worse quality than the other. Is it possible to set a constant value for either qscale, qmin, qmax, crf... In order to convert both videos to have exactly the same quality? [11:28] <zap0> quality is subjective. [11:29] <zap0> you want #art #philosophy [14:13] <dreamhawk> Is it possible to add #EXT-X-KEY:METHOD=AES-128 +URI-line while ffmpeg segments m3u8 ? [14:28] <dreamhawk> Nobody knows? Ffmpeg + hls #EXT-X-KEY? :) [14:36] <zap0> if you say so. [14:41] <spaam> yes? [14:41] <spaam> it worked last year IIRC [14:42] <dreamhawk> What do i have to type to make ffmpeg add it ? I've googled for long time and re-checked manual several times.. [14:45] <spaam> ah you want to encrypt it.. that i dont know. only for decode [14:47] <dreamhawk> spaam: not encrypt really, another script has to do that i think, but to enable encrypted playback, the #EXT-X-KEY:METHOD=AES-128,URI="" has to be in the m3u8-file. I could add it manually, but since it is live-encoding ffmpeg rewrites the m3u8 from time to time, and then it disappears [14:48] <spaam> ffmpeg can decrypt files if the m3u8 file have that EXT-X-KEY thing. [14:49] <dreamhawk> spaam: i do not want to decrypt :) [14:51] <dreamhawk> ffmpeg creates like, allow-cache, targetduration, media-sequence, version. there must be some way to define method too [15:11] <oooxff> any body here ? [16:14] <jarr0dsz> hi everyone i tried compressing mp4 with amazing results i cannot hardly believe! from 130kb to 20kb [16:14] <jarr0dsz> i added -vcodec libx264 -crf 20 -acodec mp2 but are there any implications? is there some directive api site for ffmpeg to review what these commands do? [16:14] <jarr0dsz> the size was still the same [16:16] <JEEB> the mp2 audio encoder is the only weird part, I would guess even libavcodec's aac encoder is better than that one? [16:16] <jarr0dsz> anyone can help me understand those commands? [16:16] <jarr0dsz> JEEB im not sure im very new user i found it on wiki post and just tried [16:17] <jarr0dsz> perhaps i can better ask how to minimize size of .mp4 file optimal without loosing to much quality? [16:17] <JEEB> -c:v or -vcodec just sets the video encoder to libx264, pretty much the best thing you can use right now [16:17] <JEEB> -crf sets the constant rate factor rate control for value 20, this is closest to what one could call "constant quality" within the things we have available nowadays [16:18] <JEEB> lower value leads to more file size and possibly better quality, higher value leads to more compression and possibly worse quality. You just pick the highest value that still looks good to you. [16:19] <JEEB> also since generally the video track takes most of the size, you might as well just copy the audio track from input unless it's huge [16:19] <JEEB> -c:a copy [16:19] <JEEB> you can also set -preset for the speed VS general compression ratio [16:19] <jarr0dsz> JEEB i combine 2 videos + the audio streams with this command ffmpeg -i stream1.mp4 -i stream2.mp4 -filter_complex "[0:v]setpts=PTS-STARTPTS, pad=iw*2:ih[bg]; [1:v]setpts=PTS-STARTPTS[fg]; [bg][fg]overlay=w; amerge,pan=stereo:c0<c0+c2:c1<c1+c3" -vcodec libx264 -crf 20 -acodec mp2 output.mp4 [16:19] <JEEB> http://mewiki.project357.com/wiki/X264_Settings#preset [16:20] <JEEB> oh, if you're doing something for the audio then you naturally can't just copy it :P [16:20] <jarr0dsz> its like 5 times compression from the orginal 2 flv files its amazing [16:20] <JEEB> s/for/to/ [16:28] <yairgo> I'm trying to segment a file for hls, the segments will play in chrome on my ubuntu laptop if I hit them individually, but if I try to hit them with my iPad individually they will not play. can anyone help me out here? I can put a gist on github with all of the different commands I've tried to use if needed [17:08] <Ulfalizer> got video recording working in my emu, but the video and audio streams drift out of sync after a while. still pondering what the best synchronization strategy is. how common is it for encoders to not return PTS values? [17:31] <Paradisal> hello [17:31] <Paradisal> I want to decode speex files using ffmpeg? [17:32] <Paradisal> is there any code sample about it? [17:32] <Paradisal> I saw libspeex's function's in FFmpeg, but i don't know how to use it [21:10] <Xx_pk_XX> Hello. Does anyone know if it is possible to find out if some sequence of frames is in a video? What I need to do is find in lot of videos exact times of commercials. Commercial is always same (same audio/video), and I need to know when commercial starts in video. It doesn't matter how I will do it - by sound comparison, image comparison etc. I didn't find anywhere a possibility to do something like that. Is it even possible? [21:11] <Xx_pk_XX> I have even tried cutting video into frames, and than using java I was comparing images. But it was either very slow, or too much inexact [21:15] <llogan> Xx_pk_XX: you're the third person to ask for such a feature in a week. i can only think of one way you can do it with ffmpeg alone but only if the desired frame or audio packet are *exactly* the same in both sources [21:16] <llogan> using framemd5 muxer or such [21:16] <llogan> http://ffmpeg.org/ffmpeg-formats.html#framemd5 [21:16] <Xx_pk_XX> third? wow... [21:17] <llogan> consider making a feature request on the bug tracker, or even better submitting a patch [21:17] <Xx_pk_XX> ah well, I'm not sure if it will be exactly same, but thanks, I will try it out [22:07] <Mista_D> What's the first step in effort to call DSP from ffmpeg? [00:00] --- Thu Oct 31 2013

1 0

ffmpeg-devel.log.20131029
by burek 30 Oct '13

30 Oct '13

[00:13] Action: Compn has idea for ffmpeg website banner with drone flying in the sky [00:14] <Compn> http://farm9.staticflickr.com/8150/7318030594_62ec2381cf_z.jpg [00:14] <Compn> possibly with droney [01:00] <llogan> i suppose i could have reverted instead... [06:22] <Zeranoe1> Can FFmpeg with with reentrant? [07:26] <ubitux> huh audio example doesn't reconstruct packets either [07:26] <ubitux> broken examples finally reported [09:22] <ubitux> kierank: i don't understand what you suggest in the vp9 4x4 [09:23] <ubitux> m4 is 64 bits [09:25] <kierank> It's 128 bits, no? [09:25] <nevcairiel> if its sse, it should be [09:26] <ubitux> mmh i assumed it was 64 because all my ops rely on this being 64 [09:26] <nevcairiel> in sse those names map to the xmm registers [09:27] <ubitux> mmh [09:27] <ubitux> i guess i could do simplify that then [09:27] <ubitux> since this code does not work with mmx anyway [09:28] <ubitux> but then the number of xmm registers is wrong in the prototype [10:01] <saste> how is -faststart still relevant nowadays? [10:01] <saste> which players are affected by that? [10:01] <saste> at least with ffplay/vlc i see no difference in playback startup time [10:01] <ubitux> some flash players and httpd with no range request [10:01] <ubitux> i guess [10:02] <saste> thanks [10:17] <durandal_1707> remove unused function from vp8 ? when ? [10:19] <ubitux> ? [10:28] <saste> Doom9 Forums Compromised [10:28] <saste> why do we have such a news on our page?? [10:28] <durandal_1707> because of Compn [10:28] <durandal_1707> Compn: you did not sent it for review [10:29] <durandal_1707> i'm for removing that [10:30] <durandal_1707> ah it is already done [10:32] <cone-828> ffmpeg.git 03Anton Khirnov 07master:c9a13a289d0e: lavc: remove old unused audio conversion functions. [10:32] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:6bf4edec27de: Merge commit 'c9a13a289d0e1607387854127476813a1ee3d34b' [10:33] <nevcairiel> michaelni: the old audio api was not part of the public API, its header not installed .. do things really use that? [10:33] <durandal_1707> michaelni just have nostalgia for that code [10:34] <durandal_1707> same for libmpcodecs [10:35] <saste> why wasn't it ifdeffed? [10:35] <durandal_1707> it is awkward to support old stuff when even examples do not work with current code [10:35] <durandal_1707> examples should be part of fate [10:38] <cone-828> ffmpeg.git 03Paul B Mahol 07master:66518f6feb95: avcodec/cook: use av_freep() [10:38] <durandal_1707> afaik applications already need to be updated... [10:41] <saste> but yes it was not even public API [10:41] <saste> and i doubt it is much tested [10:41] <durandal_1707> but people use it like mplayer [10:42] <saste> michaelni, when do you schedule to drop that API? [10:42] <saste> keeping all APIs indefinitively is not realistic [10:43] <saste> anyway keeping it for the new release is senseful [10:43] <nevcairiel> we just had a new release :D [10:43] <michaelni> nevcairiel, i dunno, there are some hits by google to some random pieces of code using it [10:44] <nevcairiel> should at least put a deprecation tag on it so people know to migrate [10:44] <michaelni> yes [10:45] <michaelni> saste, i dunno, i guess we can remove it when someone posts a patch that removes it and there is consensus on its removial on ffmpeg-devel [10:45] <saste> or drop it at the next bump [10:45] <durandal_1707> michaelni: you ever had contact with people that actually tried to use new release with old api stuff? [10:45] <michaelni> or there is some strong technical need to remove it [10:45] <saste> if we want to help projects misusing internal API [10:46] <durandal_1707> technical need: it doesnt help anyone at all [10:47] <saste> but i don't mind, i'll probably send a drop-at-the-next-bump patch later [10:47] <durandal_1707> if you do not forget [10:47] <saste> what should i forget? [10:47] <durandal_1707> to drop it at next bump [10:48] <saste> you missed the cheesy humor in my reply [10:50] <michaelni> durandal_1707, yes i got mails from people who tried to build olf code with new ffmpeg [10:58] <durandal_1707> michaelni: me too, and does keeping above help them? [11:05] <saste> talking about serious stuff, what's the name of the new release? [11:05] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:e36231969af5: avcodec/audioconvert: deprecate API [11:07] <durandal_1707> saste: the 2.2 one? [11:09] <saste> no the 2.1 one [11:12] <durandal_1707> saste: isn't in on web? [11:13] <saste> ah ok [11:13] <saste> "Fourier", cool [11:14] <cone-828> ffmpeg.git 03Anton Khirnov 07master:feeafb4adabd: lavf: do not export av_register_{rtp,rdt}_dynamic_payload_handlers from shared objects [11:14] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:d3e13250a030: Merge commit 'feeafb4adabd5c17de1738ed9962e40892b20edb' [11:28] <ubitux> http://pastie.org/pastes/8439685/text [11:28] <ubitux> is it me or the installed libs are extremely weird? [11:28] <ubitux> +sizes [11:39] <saste> what's so weird? [11:40] <saste> encoder options are arcane... [11:41] <ubitux> saste: .a is 116M, .so 7M for libavcodec [11:41] <Daemon404> saste, only only in the src =p [11:41] <ubitux> similar for the others [11:42] <Daemon404> those all look correct [11:42] <ubitux> ok [11:44] <saste> Daemon404, how do you explain that? [11:45] <Daemon404> expain what? [11:45] <saste> the difference in size [11:45] <Daemon404> debug info, actually linking it [11:45] <Daemon404> etc [11:45] <saste> isn't debug info contained in .so files as well? [11:46] <ubitux> also it seems to be grabbing the lib installed on my system somehow [11:46] <ubitux> something is fishy :( [11:47] <saste> for example b_strategy [11:48] <saste> it is used only by the mpeg encoders, with values (0, 1, 2) which are not documented anywhere [11:48] <Daemon404> saste, just symbols afaik [11:48] <saste> and used by other libs (libxvas and libx264) to bind wildly related stuff [11:50] <saste> and the git blame for that code obviously shows K&R cosmetics [11:51] <durandal_1707> what K&R did? [11:52] <saste> the revision before was a split [11:52] <ubitux> try with -w, but in case of line breaks you're doomed [11:53] <durandal_1707> Kidnap & Ransom [12:06] <cone-828> ffmpeg.git 03Anton Khirnov 07master:cd43ca0443a2: lavfi: do not export the filters from shared objects [12:06] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:325f6e0a97c9: Merge remote-tracking branch 'qatar/master' [12:07] <saste> michaelni, any hope to have an explanation of b_strategy and b_sensitivity? [12:13] <michaelni> b _strategy is used by 3 different encoders [12:18] <michaelni> you could use the description from x264 --b-adapt probably [12:18] <michaelni> 0:disabled, 1:fast, 2:optimal [12:19] <saste> michaelni, libx264, libxavs, mpegvideo encoders [12:19] <saste> ok, will see what i manage to do [12:23] <ubitux> BBB: any reason we should prefer the mmx registers over the xmm ones since we are using ssse3? [12:24] <nevcairiel> sometimes it makes sense to use mmx when your data is too small for xmm [12:24] <nevcairiel> no idea if thats the case here [12:37] <durandal_1707> nice, now i can not call filters directly [12:39] <cone-828> ffmpeg.git 03Derek Buitenhuis 07master:069ceea7da66: timefilter: Fix typo in allocation failure message [12:48] <BBB> ubitux: usually mmx instructions are slightly faster than xmm, so if you don't use the space, mmx is better [12:49] <ubitux> i see, ok [12:49] <BBB> ubitux: see http://www.agner.org/optimize/instruction_tables.pdf [12:50] <BBB> but usually best to just try and see [12:50] <BBB> if it can be done in xmm using full register width, that's usually better, unless it involves tons of shuffling and moving data around [12:51] <saste> mateo`, can you have a look at some of these: http://ffmpeg.org/trac/ffmpeg/tags?q=%27osx%27&ticket=on [12:51] <Daemon404> it's too bad pengvado's brain was never dumped to a pdf (re: asm) [12:53] <BBB> yeah that would be useful sometimes [12:53] <BBB> I'm still wondering why I'm pretentious [12:53] <BBB> but I'll worry about that later [12:54] <mateo`> saste: i don't have time at the moment, but i'll take a look at it after doing a proper review of the iSight patch [13:03] <ubitux> so, libvpx still has no threaded encoding? [13:04] <ubitux> mmh... how long did it take last time i encoded 40 sec of video? [13:04] <ubitux> 7-8 hours? [13:05] <durandal_1707> in perfect scenario you would with threading lower that to 1 hour [13:09] <saste> mateo`, sure [13:09] <cone-828> ffmpeg.git 03Derek Buitenhuis 07master:a483aae7d8bc: h264: Check all allocations [13:12] <BBB> ubitux: someone needs to send them a patch I think [13:12] <BBB> I'll add frame-mt sometime soon to ffvp9 [13:15] <durandal_1707> what about slice-mt? [13:15] <durandal_1707> 'slice' [13:15] <BBB> tile [13:15] <BBB> I'll do that too, but later [13:15] <BBB> frame-mt is more important [13:15] <BBB> as long as we don't support effective er, we're useless for realtime purposes [13:15] <BBB> and then tile-mt isn't very useful [13:30] <ubitux> BBB: they don't plan to make a decent encoder? [13:30] <ubitux> because, isn't it the only one encoder available? [13:31] <durandal_1707> writing anything decent is hard [13:31] <ubitux> well, i mean usable [13:32] <ubitux> if it takes days to make a few minutes encode, no one is going to use it [13:33] <durandal_1707> writting usable lossy encoder is much harder [13:34] <ubitux> oh i didn't say it was easy ofc [13:35] <durandal_1707> i could speculate more about reasons, but i find that ugly [13:55] <ubitux> do we have a hwaccel doing encoding? [13:56] <nevcairiel> no(t yet) [14:00] <ubitux> anyone working on such thing? [14:00] <ubitux> or interested to? [14:02] <nevcairiel> i might, and luca expressed some interest as well [14:03] <nevcairiel> but for myself, it'll be next year [15:26] <durandal11707> K&R needs concentration [15:29] <durandal11707> huh isn't code in lavc/mdec doing simply swap with loop, instead of using dsp [15:29] <saste> wm4: do you want to review my sws filter patch? [15:29] <saste> otherwise i think i'll commit it, if i don't change mind [15:33] <durandal11707> Don is reseting the history [15:42] <saste> michaelni, if I set bf=-1 it will crash the mpeg4 encoder [15:42] <saste> bf=-1 is actually useful only to let libx264 to leave the default value [15:44] <saste> ffmpeg -i matrixbench_mpeg2.mpg -codec:v mpeg4 -an -bf -1 -y out.mp4 [16:07] <saste> bb73cda2 => fix libx264, breaks everything else [16:07] <ubitux> yes but who cares about other codecs anyway? [16:20] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:6103faaa51d2: matroskaenc: fixed display width / height calculation for stereo mode [16:20] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:ce55e667facb: avcodec/mpegvideo_enc: check that max_b_frames is not negative [16:30] <saste> michaelni, thanks [16:45] <wm4> saste: where is it? [17:27] <wm4> are there any webm vp9 samples around? [17:40] <Daemon404> wm4, in FATE [17:40] <Daemon404> in the wild? havent seen any [17:43] <wm4> I see [17:43] <kierank> Daemon404: yotube [17:43] <kierank> youtube* [17:43] <Daemon404> iirc youtube wasnt doing vp9? [17:44] <kierank> yes they were [17:44] <Daemon404> 'were'? [17:44] <Daemon404> as in they stopped? [17:46] <wm4> vp9 over dash, it's like a dream come true [17:47] <Daemon404> does this dream involve whips and leather [17:48] <wm4> and lawyers, yes [17:56] <ubitux> wm4: i generated one with libvpx [17:56] <ubitux> do you want it? [17:56] <wm4> ubitux: sure [17:56] <wm4> I actually just want to test demuxing [17:56] <ubitux> http://lucy.pkh.me/samples/vp9/ [17:57] <wm4> and the fate samples are naturally extremely short [17:57] <ubitux> this one is 40 sec [17:58] <ubitux> i'm currently generating a slighty longer one [17:58] <ubitux> but it will take a few days [17:58] <ubitux> :) [17:59] <wm4> this one worked nicely [18:01] <wm4> which surprises me, because my demuxer accidentally doesn't pass extradata to the decoder [18:01] <nevcairiel> vp9 has extradata? [18:01] <wm4> apparently not :) [18:03] <Daemon404> 'a few days' [18:03] <Daemon404> sounds usable [18:03] <ubitux> well [18:03] <ubitux> it's 5k frames after all [18:03] <ubitux> :D [18:04] <ubitux> 5k frames, 5 days [18:04] <Daemon404> [17:03] <@Daemon404> sounds usable [18:04] <ubitux> ;)) [18:04] <wm4> and I can't find the webm/vp9 spec [18:04] <Daemon404> ahahahahahahahahaHAHAHAHAH [18:04] <JEEB> > vp9 > spec [18:04] <JEEB> ahoy! [18:04] <wm4> I expected this reaction [18:04] Action: JEEB gives wm4 a friendly hug [18:05] <ubitux> well you've become pretty demanding [18:05] <ubitux> remember when all codecs needed to be reversed? [18:05] <ubitux> @_@ [18:05] <wm4> lol [18:05] <Daemon404> sure [18:05] <Daemon404> just dont have google sell it to me as 'open' [18:06] <nevcairiel> its only not open if such a document exists, but is not published [18:06] <nevcairiel> if it doesnt exist, you have no reason to complain [18:06] <nevcairiel> you get the same info they work off =P [18:07] <Daemon404> http://guru.multimedia.cx/chrome-droppings/ [18:09] <Compn> wm4 : i think BBB didnt write a spec. there is only code [18:09] <Compn> not that it was his codec in the first place :) [18:09] <Compn> ehe [18:09] <wm4> at least webvtt in webm had some specs [18:10] <wm4> and webvtt is a google thing too [18:10] <nevcairiel> its a trivial format, not sure what webm specs it needs [18:10] <nevcairiel> no extradata, no nothin' [18:10] <Daemon404> [17:10] <+wm4> and webvtt is an abomination [18:10] <Daemon404> ftfy [18:11] <wm4> well I'm sure surprised how little hevc and vp9 need from the demuxer [18:11] <wm4> webvtt and opus are so complicated in this respect [18:12] <nevcairiel> hevc will need dealing with extradata, although if everything is muxed sanely you just need to copy it 1:1 [18:12] <Daemon404> thats not a safe assumption [18:12] <Daemon404> esecially for 'pro' stuff [18:12] <nevcairiel> and of course there is the open intra refresh problem and seeking, but that was never solved for h264, so doubtful thats going to change much :P [18:13] <nevcairiel> of course there will be some oddball format that invents their own extradata [18:13] <nevcairiel> but for the mainstream things, ts/mkv/mp4, its easy [18:13] <Daemon404> nut! [18:14] <Daemon404> ubitux, does vp9 actually have a real release yet [18:14] <Daemon404> because they fucked that up and changed stuff due to bugs [18:14] <wm4> isn't nut = "use ffmpeg internals lol" [18:20] <smarter> Daemon404: the closest thing to a release is http://git.chromium.org/gitweb/?p=webm/libvpx.git;a=shortlog;h=refs/heads/s… [18:20] <Daemon404> we all saw how that turned out... [18:20] <smarter> if you care about encoding, you should use master for now [18:21] <Daemon404> well i was going to run it on a more powerful box [18:21] <Daemon404> because 1k frames per day is insane [18:25] <smarter> use --cpu-used=1 if you don't already [18:25] <Daemon404> what exactly does that o [18:25] <Daemon404> do [18:25] <smarter> it's the speed setting [18:25] <Daemon404> ive never touched vp9 before this very instant [18:25] <smarter> 0 is the slowest/best [18:25] <smarter> 5 is the fastest/worst quality [18:25] <Daemon404> right im more interested in 0 [18:26] <Daemon404> all the current hevc encoders are crap, may as well add vp9 into the mix [18:26] <smarter> 1 should be ~5% worse than 0 and much faster [18:27] <smarter> I use this command-line, but I think some flags are now no longer needed because the default became more sane: "./vpxenc ~/samples/parkjoy.y4m -o /dev/null --good --cpu-used=1 --target-bitrate=16000 --end-usage=vbr --auto-alt-ref=1 --fps=30000/1001 -v --minsection-pct=5 --maxsection-pct=800 --lag-in-frames=16 --kf-min-dist=0 --kf-max-dist=360 --min-q=4 --max-q=60 --arnr-maxframes=5 --arnr-strength=3 -p 2 --codec=vp9" [18:29] <Daemon404> i was going to test with a bunch of real world sources [18:29] <Daemon404> broadcasts, masters, etc [18:30] <smarter> have fun :p [18:31] <Daemon404> side note: this is for personal curiosity, not profession [18:31] <Daemon404> al [18:31] <Daemon404> 301KB/s [18:31] <Daemon404> woooo fast [18:40] <cone-828> ffmpeg.git 03Stefano Sabatini 07master:61c1f2cb1e7e: doc/muxers: add definitory line for the MOV/MP4/ISMV muxer [18:40] <cone-828> ffmpeg.git 03Stefano Sabatini 07master:9fa0dccca649: lavc: extend documentation for the "bf" option [18:40] <cone-828> ffmpeg.git 03Stefano Sabatini 07master:d4ac3e593481: lavc/mpegvideo_enc: fix typo [18:51] <saste> what's the status of the internal aac encoder? [18:52] <saste> do you support the claim in https://trac.ffmpeg.org/wiki/AACEncodingGuide [18:52] <saste> fdk_aac > libfaac > aacenc? [18:52] <Daemon404> saste, that is correct [18:52] <Daemon404> right now [18:52] <Daemon404> that epic bug tracker thread i still ongoing [18:52] <Daemon404> and nothing has been pushed [18:52] <Daemon404> is* [18:52] <saste> so it seems [18:55] <wm4> saste: can you hint me where the swscale filter posts are? [18:56] <saste> wm4: [FFmpeg-devel] [PATCH] swscale: Support setting filters through AVOptions [19:11] <nevcairiel> anyone know how well ffmpeg interleaves ts streams? [19:16] <burek> llogan, im not sure, i'll check.. probably the devel machine ran out of electr. power [19:18] <burek> it's highly unreliable :( i need to migrate it to another, but i need to find some spare time to do so.. [19:21] <llogan> burek: convert it to gasoline/petrol [19:24] <burek> +1 :) [19:37] <ubitux> did something happen with the consulting page or whatever? [19:37] <ubitux> i had 4 consulting requests in 4 days [19:37] <ubitux> first time i see this [19:38] <ubitux> <@Daemon404> ubitux, does vp9 actually have a real release yet // i'm not following libvpx development at all [19:42] <cone-828> ffmpeg.git 03Clément BSsch 07master:8d55362fd0d4: avformat/avisynth: re-add trailing \n. [19:48] <cone-828> ffmpeg.git 03Luca Barbato 07master:dcd3eda6cb88: configure: Move gcc-only -W option where it belongs [19:48] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:df69af4ee1bc: Merge commit 'dcd3eda6cb8884beeb67ef5eb61b4bb6b01d29ea' [19:56] <cone-828> ffmpeg.git 03Luca Barbato 07master:e78913052263: configure: Provide an hardened toolchain option [19:56] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:6c5f17e738a5: Merge commit 'e78913052263af80855590659fb0f705e8f13c8a' [19:58] <saste> ubitux: same happened to me [19:58] <ubitux> saste: ok :) [19:58] <saste> it is called the autumn wakeup [19:59] Action: saste saste is doing (very little) boring paid work [19:59] <kierank> because it's the end of DST? [20:01] <saste> kierank, probable, less time to do outdoor fun stuff [20:03] <nevcairiel> nonsense, just gotta start earlier! [20:06] <cone-828> ffmpeg.git 03Derek Buitenhuis 07master:327c439f811a: timefilter: Handle memory allocation failure [20:06] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:42bf156e132b: Merge commit '327c439f811a89d774db9a86f72951d295193e5f' [20:08] <cone-828> ffmpeg.git 03Derek Buitenhuis 07master:25c7db7cc99d: avio: Check for memory allocation failure of private data [20:08] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:e166b82dd483: Merge commit '25c7db7cc99d74fe6fb56a6fd52c9b5f1591e448' [20:21] <wm4> saste: I hope my "review" isn't too negative... [20:23] Action: saste is used to too negative review [20:24] <wm4> btw. what is eval.h included for? [20:25] <saste> wm4, av_strtod [20:25] <wm4> ok [20:26] <wm4> why is that needed instead of just strtod()? [20:32] <saste> indeed it is probably unneeded [20:33] <saste> but it was in michael's patch, and I didn't think about it [20:36] <wm4> depends on michael's reply then [20:37] <cone-828> ffmpeg.git 03Anton Khirnov 07master:4eb49fdde8f8: lavf: remove unreliable timestamp guessing heuristic [20:40] <ubitux> BBB: i'd like to work on 8x8 before applying 4x4 [20:41] <ubitux> we can probably factor some things, and it's easier to move things around randomly when it's still not upstream [20:41] <ubitux> the optim is not worth being pushed right now for overall decode anyway [20:41] <wm4> huh, that commit has no merge record? [20:42] <ubitux> wm4: it's re-applied [20:42] <wm4> oh [20:42] <ubitux> wm4: it wasn't merge (see merge commit message) [20:42] <ubitux> now that the abi is solved, i guess it can be applied [20:43] <michaelni> wm4, my reply ? where what ? [20:43] <michaelni> wm4, yes, nevcairiel sugested id just apply and wait [20:44] <michaelni> IIRC [20:45] <wm4> michaelni: about the swscale filter as avoption patch [20:46] <michaelni> iam fine with any form of *strtod for it [20:46] <ubitux> http://pastie.org/8440873 lol [20:46] <saste> wm4, yes there is no point into using av_strtod I think [20:47] <wm4> michaelni: well, about more general issues too [20:48] <michaelni> what issues ? [20:49] <wm4> well, read my mail... [20:53] <michaelni> ok read it, what should i do now ? [20:53] <wm4> well, do we really need the change? [20:53] <michaelni> iam not sure [20:54] <wm4> or maybe at least the syntax should be extended to support common cases? [20:54] <wm4> *use cases [20:54] <michaelni> there could be support for things like gauss(1.2) [20:55] <michaelni> there could be support for things like combining vectors per convolution gauss(1.2)|shift(123), shouldnt be hard to implement but iam also dont want to overdesign this [20:57] <michaelni> sws_convVec() <-- for convolution [20:59] <cone-828> ffmpeg.git 03Anton Khirnov 07master:8b64c2ba0382: lavc: add a dummy field to AVStream to preserve ABI compatibility for avconv [20:59] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:249cc58c3ada: Merge commit '8b64c2ba0382892cad9e1a5ba601696d4cbb4d04' [21:11] <saste> wbs, willing to review libfdk_aac docs? [21:37] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:15b1b0887466: avutil/opt: fix flags check on non x86 [21:45] <cone-828> ffmpeg.git 03Anton Khirnov 07master:c872d310cd9c: avconv: stop accessing AVStream.parser [21:45] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:0460b9bb3e34: Merge commit 'c872d310cd9c605e5f994ad8ac79dc72303c0d29' [21:50] <Zeranoe1> Can FFmpeg be run with reentrant? [21:58] <michaelni> what do you mean by "with reentrant" ? [22:00] <Zeranoe1> I guess is it possible to do re entrance with FFmpeg? [22:01] <michaelni> you can call a decoder while another decoder works yes [22:02] <cone-828> ffmpeg.git 03Diego Biurrun 07master:9510d7689e23: fate.sh: Allow non-fast-forwards when updating sources [22:03] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:a8fe8d4fe986: Merge commit '9510d7689e236f6a4748795604fba427c130d0ad' [22:03] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:0999b1db3c1a: tests/fate.sh: run git reset only when fetch succeded [22:03] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:7f4fd72f81b7: tests/fate: fix fate on branches different from origin/master [22:12] <saste> cc1: warning: unrecognized command line option "-Wno-maybe-uninitialized" [22:12] <saste> uh? [22:14] <ubitux> this was moved to gcc specific case today iirc [22:14] <ubitux> so if you don't have gcc that's normal i'd say [22:15] <ubitux> or maybe that's a really old gcc? [22:15] <nevcairiel> the option is pretty new in gcc, too [22:15] <nevcairiel> 4.7 i think [22:15] <ubitux> ah? ok [22:15] <ubitux> well the warning shouldn't be disabled anyway [22:15] <nevcairiel> imho its more wrong then right [22:16] <nevcairiel> gcc doesnt do a very good job tracking that [22:16] <ubitux> better have 9 false positive and 1 true match, than no issue found [22:16] <ubitux> also as you said it's recent, and meant to be improved i suppose [22:16] <nevcairiel> since we need the off option, it must be default enabled in some way [22:23] <ubitux> nevcairiel: looking at your benchmark, it's fun how vc1 is so slow [22:24] <ubitux> even though there are quite some optim available [22:24] <nevcairiel> well, its not threaded [22:24] <cone-828> ffmpeg.git 03Derek Buitenhuis 07master:58d13cea307e: h264: Check all allocations [22:24] <ubitux> aah, that's it then [22:24] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:845086149b15: Merge commit '58d13cea307e776664dae711608b358dd4b84fff' [22:25] <nevcairiel> although i disabled mt for mpeg4 as well [22:25] <nevcairiel> still does 400 fps [22:26] <ubitux> maybe a scale filter comes into play or sth? [22:26] <nevcairiel> nah its just that slow [22:26] <ubitux> ok, fun :p [22:26] <nevcairiel> was tested with my own software, it doesnt auto-insert stuff [22:26] <ubitux> ok :) [22:28] <nevcairiel> i dont usually use the vc1 decoder, i use microsofts binary decoder because its 5x faster [22:28] <nevcairiel> but i thought for the benchmark it wouldnt hurt [22:42] <cone-828> ffmpeg.git 03Ingo Brückl 07master:8fbb0979da8e: build: remove pointless condition [22:42] <cone-828> ffmpeg.git 03Michael Niedermayer 07master:6b312143793b: Merge remote-tracking branch 'qatar/master' [22:51] <cone-828> ffmpeg.git 03Anssi Hannula 07master:f86387b6c2b1: lavf/spdifdec: fix demuxing of AAC in IEC 61937 [23:09] <Compn> nevcairiel : vc1 binary 5x faster than ffvc1 ? [23:09] <Compn> is the binary threaded ? [23:09] <nevcairiel> among other things, yes [23:10] <Compn> comparing threaded binary to threaded ffvc1 wonder what speed diff is [23:10] <nevcairiel> there is no threaded ffvc1 [23:10] <Compn> ah [23:10] <Compn> one of the codecs that wasnt threaded ? [23:12] <Compn> http://trac.ffmpeg.org/ticket/1885 [23:12] <Compn> i see [23:12] <kierank> oh ffv1 isn't intra [23:32] <michaelni> what is preferred for iSight, autodetect or disabled by default ? [00:00] --- Wed Oct 30 2013

1 0

ffmpeg.log.20131029
by burek 30 Oct '13

30 Oct '13

[00:29] <pzich> hrm, I'm trying to generate a poster frame from a video using an image sequence export, but the colors seem to vary between the image and the first frame of the video, is there a good way to get these colors to match more closely? http://imgur.com/a/Dss8H [00:30] <klaxa> i blame color conversion [00:30] <klaxa> jpeg isn't YUV is it? [00:32] <pzich> http://pastebin.com/hKjadagB [00:32] <pzich> I was also trying using yuvj420p for the poster frame, but that didn't seem to have helped [00:32] <pzich> ah, yes, the console bits [00:36] <pzich> http://pastebin.com/3sNf7Lpu * [00:45] <pzich> I think the video is coming out a bit washed out, so I may try to correct that to the jpeg instead of the other way around [05:17] <Zeranoe1> Is there any way to determine the length of a media file with FFmpeg/ffprobe? [05:18] <hellangel> Zeranoe1, try ffmpeg -i <filepath> [05:20] <Zeranoe1> perfect, duration. How accurate is that? [05:20] <hellangel> no clue really, i googled that [05:20] <hellangel> im having issues with avconv and streaming sound, if anyone might be able to help: http://moestaverne.com/media/stuff/avconv.txt [13:22] <plm> Hi all [13:22] Last message repeated 1 time(s). [13:22] <spaam> hi all [13:22] Last message repeated 1 time(s). [13:22] <durandal_1707> hi all [13:23] Last message repeated 1 time(s). [13:26] <ubitux> hi all [13:27] Last message repeated 1 time(s). [13:29] <saste> all, hi [13:29] <ubitux> saste the nonconformist [13:31] <zap0> Hello y'all [14:36] <pjetr> quick question: can I convert SWF's to any other video file? [14:37] <pjetr> and hello and everything :) [14:44] <zap0> maybe. [17:22] <Erneston> hello [20:26] <StFS> Hi. Anybody on Ubuntu 13.10 having problems with libx264 vcodec? I'm getting a segfault [20:34] Action: llogan downloads 13.10 [20:40] <StFS> llogan: http://pastie.org/8440859 [20:42] <llogan> StFS: !fork [20:42] <llogan> that's a fake ffmpeg and it is not supported here. [20:43] <llogan> a step-by-step guide to compile ffmpeg on Ubuntu: http://trac.ffmpeg.org/wiki/UbuntuCompilationGuide [20:43] <llogan> (I haven't tested it on 13.10 yet) [20:43] <StFS> hmm.. ok [20:44] <llogan> if you want to continue to use that crappy buggy junk then you'll have to ask for help at #libav [20:45] <StFS> ok thanks :) [20:58] <batbat_> hello [20:59] <batbat_> hello, anybody there? [21:01] Last message repeated 1 time(s). [21:01] <batbat_> hello [21:02] Last message repeated 2 time(s). [21:47] <ericgudmundson> I guys, I have a quick question. I just updated my ffmpeg and when I use a udp stream I start to get errors after a little while saying that a reference frame is not present any one else seeing this? [21:47] <ericgudmundson> Or that the reference 4 >=2 [21:49] <llogan> ericgudmundson: does the output look ok? did the older ffmpeg do this too? [21:51] <ericgudmundson> No the older ffmpeg does not do this. The output looks nothing like it. Unfortunately we are using the libraries in a propitiatory system and we were using 0.9 and it works fine. the move to 2.0 is when the problem became prevalent. One of my coworkers did run it with the ffmpeg program and it came up after 6 hours where ours comes up after 30 minutes [21:51] <ericgudmundson> It does ruin the stream that is being encoded. [21:53] <ericgudmundson> let me see if I can get the exact command he ran the test with. [21:53] <llogan> could be a regression [21:54] <ericgudmundson> That is what I was thinking. have you seen anything like that the error is [h264 @ 0x2f9cc00] cabac decode of qscale diff failed at 79 14 [21:54] <ericgudmundson> [h264 @ 0x2f9cc00] error while decoding MB 79 14, bytestream (73877) [21:55] <ericgudmundson> and this is usually accompanying it :[h264 @ 0x2f0a2e0] Reference 2 >= 2 [21:56] <llogan> if i did i don't remember [21:56] <ericgudmundson> okay thank you [21:57] <llogan> a git bisect would be useful to determine if it is a regression, but that may be time consuming if it takes 6 hours per test [21:59] <ericgudmundson> okay I will give it a try. Thank you for your help [22:01] <llogan> but enough information for others to reproduce would be useful too [22:01] <llogan> regressions are considered important (but i have no idea if this is a regression) [22:05] <batbat_> hello, anybody there? [22:05] <llogan> yes [22:05] <llogan> there is always someone here [22:06] <ericgudmundson> K thank you [22:06] <batbat_> hi fake od man, I can't get re-enrolled to the mailing list, maybe my hotmail addy is blocked [22:07] <llogan> hotmail has been acting badly lately [22:07] <batbat_> @ fake, what shall I do [22:07] <llogan> they are possibly assuming that the ffmpeg mail server is "bad" [22:07] <llogan> you can contact hotmail about it. not much i can do as far as i know [22:08] <llogan> you can try a more sane email service [22:08] <batbat_> yes, hotmail is not so good [22:09] <llogan> tell them to take ffmpeg.org off of their "421 RP-001" [22:10] <ericgudmundson> llogan, I have found the command that we used to test with : ffmpeg -i udp://232.X.X.X:PORT?sources=172.31.2.22 -vcodec yuv4 -acodec pcm_s16le -f mpegts -y /dev/null [22:10] <ericgudmundson> The input audio is AC3 if that is any help [22:10] <llogan> does it do the same with a local version of the same file? [22:10] <batbat_> "421 RP-001" I don't know what that is, but maybe I will send an email to hotmail@hotmail, lol [22:11] <llogan> http://mail.live.com/mail/troubleshooting.aspx#errors [22:11] <ericgudmundson> We don't have a local copy of the same file. [22:12] <ericgudmundson> But That would be one way that we could test the problem' [22:13] <batbat_> "421 RP-001" OK [22:18] <batbat_> Have sent message to "something is broken" at outlook [22:19] <llogan> thanks, but did you not see my private chat to you? [22:19] <batbat_> outlook:- Thank you for taking the time to send us your thoughts. We do use your comments to improve Outlook. [22:41] <batbat_> llogan, you still here? [22:43] <batbat_> hullo [22:46] Last message repeated 1 time(s). [22:48] Last message repeated 1 time(s). [22:49] Last message repeated 1 time(s). [22:49] <batbat_> llogan, you still here? [23:04] <batbat_> hello [23:05] Last message repeated 2 time(s). [23:07] Last message repeated 3 time(s). [23:07] Last message repeated 2 time(s). [23:07] <klaxa> you better stop spamming or you will be banned because of it [23:07] <batbat_> not spamming [00:00] --- Wed Oct 30 2013

1 0

ffmpeg-devel.log.20131028
by burek 29 Oct '13

29 Oct '13

[00:34] <llogan> dur..how do i add a comment to my message body that isn't part of the patch? with git send-email [00:34] <mathstuf> llogan: git format-patch --cover-letter ? [00:37] <cone-911> ffmpeg.git 03Mickaël Raulet 07master:3c3ece24ea1e: hevc : cosmetic changes(cherry picked from commit 7308c0ccf13f18cebe4851e6dcd6b5c0b09be1dd) [00:37] <cone-911> ffmpeg.git 03Mickaël Raulet 07master:3106cbd32118: hevc: more cosmetic(cherry picked from commit 9697abe41daa234602915f85bf6b1c0ca0252cff) [00:37] <cone-911> ffmpeg.git 03Mickaël Raulet 07master:2707cca78f70: hevc: cosmetic change(cherry picked from commit 3b57513b3f39c04337801fb9d159c7ca8dfa9deb) [00:37] <cone-911> ffmpeg.git 03Mickaël Raulet 07master:c1882e801d64: hevc: clean up mvs(cherry picked from commit 955317c09b877a513d3fcfcd1615909b2f4f651c) [00:37] <cone-911> ffmpeg.git 03Anton Khirnov 07master:2f77894cccec: hevc: better mt implementation [00:37] <cone-911> ffmpeg.git 03Mickaël Raulet 07master:0ddd3c5ba634: hevc: add decode hrd (cherry picked from commit ab4061dff796b1dd2bc884101226aab48c2c875e) [00:38] <llogan> mathstuf: ah, thanks. I was reading "send-email" in the docs when it was actually "format-patch"...tired. [00:38] <mathstuf> and send-email doesnt complain when it gets --cover-letter either :/ [00:39] <mathstuf> i should send a patch to git to dump out a message when that happens [00:40] <llogan> i have some sort of disability when it comes to git [00:41] <mathstuf> there are simple parts and...not so simple parts (hand-editing {add,checkout,reset} -p hunks, splitting a patch in rebase -i, and more, but those aren't really hit upon day-to-day) [00:43] <wm4> mathstuf: btw. do you want to try to implement metadata update for mp3 too? [00:43] <mathstuf> i can take a look [00:44] <wm4> it would help with some web radios [00:44] <wm4> oh btw., didn't you ask where ICY info comes from [00:44] <wm4> it's from http.c [00:45] <mathstuf> i guess the popular formats for internet radio are mp3, aac, and maybe some apple thing for that end of the internet? [00:45] <wm4> yeah [00:45] <wm4> not sure what aac radio uses [00:45] <mathstuf> i get ICY from somafm [00:46] <mathstuf> havent done a dumpstream on it to see if theres anything in that part of the stream [00:46] Action: mathstuf tests [00:51] <mathstuf> nope, nothing from soma at least [01:02] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:72d1f668c40c: Changelog: add 2.1 [01:02] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:f11a917ac012: MAINTAINERS: update which releases i maintain [01:02] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:b85bf3423c47: doc/APIchanges: add 2 missing hashes & versions [01:02] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:d041f1251347: avdevice/pulse_audio_enc: remove double ; [01:15] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:0fef19b15ad9: doc/RELEASE_NOTES: update for 2.1 [01:27] <mathstuf> wm4: well, i can test flac, mp3, and opus in mpd as well [01:40] <cone-911> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/heads/release/2.1': unknown revision or path not in the working tree. [01:40] <cone-911> Use '--' to separate paths from revisions [01:40] <cone-911> refs/heads/release/2.1:HEAD: doc/RELEASE_NOTES: update for 2.1 [01:42] <mathstuf> hmm, so flac streaming has ICY info in it [01:42] <mathstuf> ogg doesnt [01:43] <mathstuf> mp3 and opus also have ICY [01:47] <mathstuf> ok...wtf? [01:47] <mathstuf> cant get any sound from mplayer or mpv [02:02] <mathstuf> whatever...looks like mpd only puts tags into ogg/vorbis streams anyways [02:02] <mathstuf> (yay curl >.> ) [02:14] <cone-911> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.1': unknown revision or path not in the working tree. [02:14] <cone-911> Use '--' to separate paths from revisions [02:14] <cone-911> refs/tags/n2.1:HEAD: doc/RELEASE_NOTES: update for 2.1 [09:15] <durandal_1707> why examples still use AUDIO_INBUF_SIZE ? [09:16] <ubitux> examples are broken [09:17] <durandal_1707> thus useless [09:44] <cone-911> ffmpeg.git 03Stefano Sabatini 07master:6baf9c4406bc: cmdutils: fix expected signature for show_colors() function [09:49] <durandal_1707> s/useless/harmful [09:57] <saste> ubitux: string variable interpolation, why did you work on that? [09:57] <saste> also, any progress on that? [09:57] <saste> why was it rejected? [10:04] <durandal_1707> as far i see it wasn't, just incomplete [10:06] <ubitux> saste: i worked on it for segment format mainly [10:06] <ubitux> to be able to set a custom output format name [10:06] <durandal_1707> ffmpeg.org down ?!?!? [10:07] <saste> durandal_1707, so it seems [10:07] <ubitux> durandal_1707: http://www.downforeveryoneorjustme.com/ffmpeg.org [10:07] <saste> now it's up (I had to wait a few seconds) [10:08] <saste> ubitux, that's my use case as well [10:08] <saste> ubitux, then what happened? [10:08] <ubitux> dunno, i didn't care anymore i guess [10:08] <cone-911> ffmpeg.git 03Justin Ruggles 07master:211ca69b13eb: lavr: check that current_buffer is not NULL before using it [10:08] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:b96dddd34403: Merge commit '211ca69b13eb0a127a9ef7e70ddaccdab125d1c5' [10:08] <saste> do you have a link to the mailing-list, what should i look for [10:08] <saste> ? [10:08] <ubitux> mmh [10:08] <ubitux> just a min [10:10] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2012-February/120446.html [10:11] <ubitux> next or prev msg probably [10:11] <saste> ubitux, merci [10:11] <ubitux> :) [10:12] <ubitux> saste: see printf("%s\n", av_stringinterp_interpolate(si, "%(filename)_%(ts1)-%(ts2)_%(nokey)%(ext)")); [10:12] <ubitux> in the example/main() [10:12] <saste> ok [10:13] <mraulet> michaelni: I added profile indication warning when there is no profile indication in the bitstream [10:18] <cone-911> ffmpeg.git 03Vittorio Giovara 07master:fc06ee6ee377: mmvideo: fix uninitialized variable use in mm_decode_intra [10:18] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:893063781926: Merge commit 'fc06ee6ee377cc3b512dff8f02057e26311bc4da' [10:21] <durandal_1707> saste: did you found equivalent of splitplanes/components? [10:22] <saste> durandal_1707, no, there is any? [10:22] <durandal_1707> looks like lavfi have to many filters for you to remmember all of them... [10:23] <durandal_1707> *too [10:23] <saste> i suppose i could find some hack to use geq or lut, even if not very efficient [10:24] <durandal_1707> why you can't leart how to use grep? [10:24] <durandal_1707> *learn [10:25] <durandal_1707> saste: you need it for something specifically or? [10:25] <saste> extractplanes? [10:27] <durandal_1707> you find it useful? [10:28] <saste> durandal_1707, could be, i never personally used most of the stuff i wrote [10:28] <saste> was just curious [10:32] <durandal_1707> if you never use it, why you wrote it then? [10:34] <durandal_1707> i wrote extractplanes for sole reason of that undocumented hack in img2 (de)muxer [10:37] <cone-911> ffmpeg.git 03Vittorio Giovara 07master:529a9893d769: avframe: mark source frame const in _ref and _clone [10:37] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:078dab551d53: Merge commit '529a9893d769f381b72785c500662be2020da5fe' [10:45] <cone-911> ffmpeg.git 03Anton Khirnov 07master:4db81f081743: hevc: add irap checks (cherry picked from commit 3d3bbe35541a308937d0fe72b20a1c29d1c4100d) [10:45] <cone-911> ffmpeg.git 03Anton Khirnov 07master:cb148e56dc15: hevc: refactor pic_arrays and set_sps (cherry picked from commit a6686c6d83b50c0962269f2c487f4f0c57e0df79) [10:46] <cone-911> ffmpeg.git 03Mickaël Raulet 07master:a21839149cdd: hevc: add profile idc warning (cherry picked from commit 15f7a481fd19529b13631bfff5b3d65bfe5729d5) [10:53] <cone-911> ffmpeg.git 03Anton Khirnov 07master:ddc589ce98c2: avconv: drop a now useless variable [10:53] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:ed49e91fd704: Merge commit 'ddc589ce98c2bba1e59318b5b0224717325eac46' [11:01] <cone-911> ffmpeg.git 03Paul B Mahol 07master:79ef4b19bfca: FATE: add bitexact sws flags to the fieldorder test [11:01] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:bdd3a746775f: Merge commit '79ef4b19bfcab8b984682a53bb8561e5c8324731' [11:21] <cone-911> ffmpeg.git 03Anton Khirnov 07master:94603feb1b3a: h264_ps: when parsing a VUI fails, only abort when explode is set [11:21] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:ac3fa95e73e5: Merge commit '94603feb1b3ad01a821a1a1cef1570b13f471821' [11:32] <cone-911> ffmpeg.git 03Anton Khirnov 07master:0b357a8095e7: AVOptions: do not range check flag options. [11:32] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:f0e43e60cd09: Merge commit '0b357a8095e72b092cc5c2aacc2f806db75ecae3' [11:45] <cone-911> ffmpeg.git 03Luca Barbato 07master:de6061203e2d: configure: Disable -Wmaybe-uninitialized by default [11:45] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:c985966a1059: Merge commit 'de6061203e2d509579ab110fb1873aade34320f5' [11:55] <durandal_1707> nice, more and more hardly tested stuff get comitted [11:58] <ubitux> what are you refering to? [11:59] <durandal_1707> anything from Merge.... [11:59] <ubitux> i don't like much that warning drop [12:03] <cone-911> ffmpeg.git 03Luca Barbato 07master:074931488639: h263: Return meaningful errors [12:03] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:d57a6fe6abda: Merge commit '0749314886390f6ec81d45e0ba424fcb36c945cf' [12:03] <michaelni> ubitux, feel free to revert [12:03] <durandal_1707> there is no no-maybe-uninitialized on clang only no-uninitialized [12:04] <ubitux> rhaa and again luca trying to remove assert [12:04] <ubitux> ...and he get reviewed by cosmetic guy #3 for h264 code :( [12:05] <durandal_1707> i assume cosmetic guy #0 is Don [12:06] <ubitux> i started counting at #1, but yeah [12:07] <durandal_1707> but lavfi counts from #0 so should you too [12:08] <ubitux> :) [12:15] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:aaaf2dc023d3: h263: Check init_get_bits return value [12:15] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:a66ee3dc87c5: Merge commit 'aaaf2dc023d31f30eeec874f24b50f44b9295185' [12:25] <cone-911> ffmpeg.git 03Luca Barbato 07master:53151723e377: avio: K&R formatting cosmetics [12:25] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:0436ffc294ba: Merge commit '53151723e377b9c43f876e20d7f27a17993256c8' [12:27] <cone-911> ffmpeg.git 03Anton Khirnov 07master:f354f30836a3: error resilience: check error_concealment, not err_recognition. [12:27] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:528f5cdd2cf1: Merge commit 'f354f30836a3148275ce60d19bbc581310249ad2' [12:29] <saste> will cosmetics ever end? [12:31] <ubitux> they're 3 full time on it now [12:32] <saste> what when they will end? [12:35] <ubitux> maybe they'll start merging commits from ffmpeg to reindent them [12:35] <ubitux> ...or maybe they will change or create another convention [12:45] <cone-911> ffmpeg.git 03Anton Khirnov 07master:23a211cbba0b: lavc: change all decoders to behave consistently with AV_EF_CRCCHECK. [12:46] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:84f972f9944a: Merge commit '23a211cbba0b7c9ee694040031b2e5da1be54a00' [13:06] <cone-911> ffmpeg.git 03Anton Khirnov 07master:97de206b44a4: lavc: disable CRC checking by default [13:06] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:252f56636ca0: Merge commit '97de206b44a48da726807cc3e7b9448a8112760b' [13:13] <cone-911> ffmpeg.git 03Vittorio Giovara 07master:5c439b41d048: avfilter: have avfilter_get_by_name return const for next bump [13:13] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:a1ce060c5191: Merge commit '5c439b41d0489412c0a4cf6dfb98915251677b8e' [13:21] <cone-911> ffmpeg.git 03Vittorio Giovara 07master:884c7a6eb86a: avfilter: fix const use of avfilter_next [13:21] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:054e4bab83b7: Merge commit '884c7a6eb86a9bc05abafc058b279018ded7de5f' [13:26] <cone-911> ffmpeg.git 03Martin Storsjö 07master:f2521563d1a0: g722dec: Change bits_per_codeword to the right option type [13:27] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:683ab5fec994: Merge commit 'f2521563d1a0c3e2a21892f59f3327b82b3db7fc' [13:37] Action: durandal_1707 wants to remove libmpcodecs [13:53] <cone-911> ffmpeg.git 03Anton Khirnov 07master:2ba68dd044ca: lavf: remove unreliable timestamp guessing heuristic [13:53] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:feba750dcd49: Merge commit '2ba68dd044ca8fc591139c05563840f546a9c0c0' [13:57] <ubitux> michaelni: http://lists.libav.org/pipermail/libav-devel/2013-October/052452.html [13:57] <ubitux> it seems to fix one [13:57] <nevcairiel> michaelni: to be fair, the field removed from AVStream is from a section of AVStream that explicitly states above that its not part of the API [13:58] <nevcairiel> so anyone that used it was wrong :d [13:58] <durandal_1707> API != ABI [13:58] <michaelni> IIRC ffmpeg & avconc access these fields when i last looked [13:59] <nevcairiel> then they are doing it wrong [14:00] <ubitux> how can avconv access it and still build without changes? [14:00] <nevcairiel> probably one of the other fields in that section [14:01] <nevcairiel> fwiw, i had that block of code disabled in my repository for a long time because it broke some files [14:01] <michaelni> ubitux, avconv accesses fields after the removed field [14:01] <nevcairiel> not sure if thats still the case today [14:02] <ubitux> michaelni: ah, ok [14:03] <michaelni> nevcairiel, do you have a file that is happier without the block ? [14:04] <michaelni> i sure would prefer to get rid of it ... [14:04] <nevcairiel> then just do it and fix any samples that are broken afterwards properly [14:05] <nevcairiel> if any even show up [14:05] <nevcairiel> i wonder if i still have those files, it was quite some time ago [14:07] <durandal_1707> michaelni: you merged err_detect change again [14:07] <durandal_1707> also what about that flags option thing that remove range checking? [14:08] <durandal_1707> all those things change behaviour, making our 'beloved' (l)users 'happy' [14:09] <michaelni> durandal_1707, ill post a patchset about cleaning up err_detect, i just need to write and test it first [14:10] <michaelni> but my opinion is that crc testing should not be enabled by default when its slow [14:11] <michaelni> and i suspect this affects more than hevc [14:15] <durandal_1707> changing default values is never good [14:16] <durandal_1707> if users want speed they can change it [14:18] <michaelni> durandal_1707, comment noted but i suspect this is not what the majority of the developers or users wants [14:19] <durandal_1707> and it is certainly bad way to show that your e-penis is bigger than someone else. disabling crc checking is not performance boost - you are not improving code by making it faster, you just stopped calling it [14:19] <durandal_1707> if you are so worried about performance why it was not 0 from start? [14:20] <cone-911> ffmpeg.git 03Anton Khirnov 07master:a1c5cc429d99: lavc: don't set AVFrame.pts to random numbers in decoders. [14:20] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:17e47ec8be20: Merge commit 'a1c5cc429d99216406170eac7e8352860076d3e8' [14:21] <durandal_1707> expect now posts like: ffmpeg lossless decoder is not lossless/bit-exact [14:22] <nevcairiel> crc checks dont change that [14:22] <durandal_1707> other decoders check it always [14:23] <durandal_1707> but only here, suddenly, it get disabled [14:23] <durandal_1707> without even small notice in Changelog [14:23] <durandal_1707> but that is already known story, why would you ever care about sane API [14:24] <michaelni> durandal_1707, like i said ill post a patchset to clean it up, everyone can comment then and we can discuss until everyone is happy [14:25] <michaelni> my oppinon is that defaults should be what makes the majority of users happy [14:25] <michaelni> and that can mean that sometimes for a codec a CRC check should be done by default and sometimes it should not [14:26] <michaelni> for some decoders the CRC checks are important for detecting errors and doing error concealment [14:26] <michaelni> for hevc it just slows things down [14:26] <michaelni> (from an end users point of view) [14:29] <ubitux> can someone on libav side tell them to stop doing this shit? http://pastie.org/8437239 [14:34] <durandal_1707> they will tell: do not merge it. [14:34] <av500> do not merge it [14:34] <av500> :) [14:35] <durandal_1707> ubitux, you should allow kids to learn K&R [14:44] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:6c82c87dbbc0: ac3dec: fix outptr increment. [14:44] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:269b3c8799f4: Merge remote-tracking branch 'qatar/master' [16:31] <durandal_1707> ubitux: how was in school? [16:31] <ubitux> huh? [16:31] <ubitux> you mean my cosmetics teaching? [16:35] <durandal_1707> psss! there are sleepers here [16:38] <ubitux> - v= ff_mpeg4_default_non_intra_matrix[i]; [16:38] <ubitux> + v = [16:38] <ubitux> + ff_mpeg4_default_non_intra_matrix[i]; [16:38] <ubitux> lol [16:38] <ubitux> i forgot that one [16:39] <durandal_1707> 'v' should be in separate line [16:42] Action: durandal_1707 working on #3089 [17:13] <durandal_1707> michaelni: why init_get_bits work for size == 0? [17:14] <durandal_1707> it appears that may cause that get_bits1 always return 1 even if there are no bits left [17:15] <durandal_1707> if size is 0, there should no bit !=0 be returned at all [17:15] <durandal_1707> why such an oversight from programmer? [17:18] <durandal_1707> i have patch here already, that causes segv if s/< 0/<= 0 [17:24] <durandal_1707> same happens if bit size is < 0 [17:28] <durandal_1707> that points to unrelated bug [17:34] <durandal_1707> looks like there is another overread... [17:51] <ubitux> oh, spi donation, that is a cool thing [17:52] <durandal_1707> if you actually get something donated [17:53] <durandal_1707> and if one never check return code of init_get_bits(8) crash happens [17:54] <durandal_1707> i expected sane implementation would not crash but just returns 0 [18:02] <ubitux> 2.2 titanium? [18:04] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:c00686518c0b: avcodec/h263dec: fix handling of AV_EF_EXPLODE [18:04] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:162126bb174c: avutil/opt: check flags validity in write_number() [18:05] <durandal_1707> 2.2 -> Clement [18:06] <ubitux> o_o [18:06] <ubitux> wut? [18:07] <durandal_1707> we are not allowed to put our names? [18:08] <ubitux> oh, you are also named Clément? @_@ [18:09] <durandal_1707> nope [18:10] <durandal_1707> if you insist it can be Paul [18:11] <ubitux> :) [18:25] <durandal_1707> is it alowed to set pointer to NULL + X ? even if pointer is never tuched after that [18:26] <nevcairiel> technically its invalid to even have a pointer to a forbidden memory address [18:26] <nevcairiel> not that it will ever cause issues [18:28] <durandal_1707> buffer_end is used by some decoders: h263 and mpeg12 [18:30] <durandal_1707> ah, but it is NULL + 0 [18:30] <durandal_1707> so just setting buffer to NULL causes crash [18:44] <durandal_1707> hmm, perhaps it only crash for get_bits1 [18:52] <llogan> burek: why have your ffmpeg builds stopped on 2013-10-25? [18:55] <durandal_1707> michaelni: i added check in get_bits1 if buffer is null, but perhaps using stub buffer is better, as that avoid check [19:06] <michaelni> get_bits/get_bits1 is speed critical code, why do you want to add a check in it ? [19:07] <michaelni> nevcairiel, its allowed to have a pointer to at least 1 element after an array, like its commonly used with end pointers [19:08] <nevcairiel> well ok, i was thinking more of total random stuff =) [19:11] <durandal_1707> michaelni: i found nice trick and wrote 'hack' [19:11] <durandal_1707> michaelni: btw, iirc there are code that use get_bits(gb, 1) [19:24] <llogan> someone asked me on twitter if ffmepg 1.1.7 builds with Visual Studio 2013. I have no clue. Anyone have an idea? [19:25] <nevcairiel> master does [19:25] <nevcairiel> thats all i can tell you [19:25] <llogan> ok, good enough for me. thanks. [19:35] <wm4> hm the documented ogg maintainer (David Conrad) doesn't seem to be too active [19:35] <wm4> so I suppose it won't happen he will be around to ok mathstuf's ogg metadata update patches [19:36] <wm4> how does it go from there? [19:37] <durandal_1707> in past, just nothing [19:38] <durandal_1707> if you care for ogg you could review it [19:41] <wm4> durandal_1707: so should I just post a bunch of replies containing just "ok"? [19:41] <durandal_1707> if you actually review code, do i need to explain what that means? [19:42] <durandal_1707> there is also some doxy ... [19:55] <Compn> wm4 : if there is no maintainer, michaelni reviews patches before committing. but its always great if someone else does a review too... [19:56] <durandal_1707> so get_bits1(gb) is faster than get_bits(gb, 1) ? [20:00] <durandal_1707> kierank: so you pay people before they do work? [20:00] <kierank> i have a proper contract [20:00] <durandal_1707> do you have place for me? [20:01] <kierank> ? [20:01] <kierank> you're taking a random guy's word [20:01] <kierank> and all these super secret companies [20:02] <durandal_1707> i agree, you are lucky if you get 50% now and 50% after [20:04] <kierank> legally (IANAL) that guy has made a public promise but the supporting companies may not have [20:06] <kierank> also the fact these companies are secret makes it an imbalanced marketplace [20:07] <durandal_1707> imbalanced in what sense? [20:08] <kierank> you don't know the value of the goods (yadif) to the company [20:09] <kierank> like is it for an ipod encoder software thats £20 or is it for a crazy expensive five figure equipment [20:09] <durandal_1707> so it should all be open like source code is? [20:09] <kierank> what should be open? [20:10] <kierank> if you are hidden behind a shell you don't know what the net value of lgpl yadif is [20:10] <durandal_1707> that secret company say we use it for that and that and gross is that and that [20:10] <kierank> in practice you sign an nda but yes [20:10] <durandal_1707> then pick what x264 did [20:11] <kierank> there's no problem doing the one time payment for relicensing as long as you know who is funding it and how much utility it gives them [20:14] <cone-911> ffmpeg.git 03Peter Ross 07master:69a042ee95c6: mpegts: demux synchronous SMPTE 336M Key-Length-Value (KLV) metadata [20:15] <kierank> wow klv metadata :) [20:15] <kierank> Compn won't like that [20:29] <llogan> is that changelog worthy? [20:37] <ubitux> yay almost done with 2x2 [20:44] <ubitux> BBB: ping :) [20:47] <durandal11707> ubitux: you dissapointed me [20:47] <ubitux> ah? :( [20:48] <durandal11707> talking with dark side [20:48] <ubitux> well i didn't want that shit to reach ffmpeg [20:48] <wm4> darkside? [20:48] <durandal11707> worse shit reached already [20:48] <ubitux> and anyway, i'm supposed to contribute if i want to make a complain [20:48] <durandal11707> indeed [20:48] <ubitux> so i'm stopping for now [20:51] <ubitux> oh i can simplify even further.. [20:53] <durandal11707> michaelni: that amv test is fucking retarded [20:53] <durandal11707> and decoder [20:55] <durandal11707> michaelni: all what my code does it change that 0 behaviour [20:56] <durandal11707> that means amv decoder is in ugly state [20:56] <ubitux> BBB: patch on the ml [20:56] <durandal11707> shit, same happens with jpegs and mjpeg [20:57] <nevcairiel> ubitux: why is there idct twice in the name? I'm sure there must be some sense in there [20:58] <ubitux> because it can be idct+idct, idct+iasdt, iadst+idct, iadst+iadst [21:01] <durandal11707> anything that use mjpeg broke [21:01] <durandal11707> ubitux: benchmark numbers? [21:01] <ubitux> durandal11707: yeah i should :p [21:22] <ubitux> durandal11707: done [21:25] <durandal11707> and what is gain overall? [21:25] <durandal11707> you can post it here [21:27] <ubitux> no difference [21:27] <ubitux> which is expected [21:28] <durandal11707> perhaps you use wrong sample? [21:28] <ubitux> i use a ~40sec 1080p sample [21:28] <ubitux> anyway, it's only idct idct 4x4 [21:28] <ubitux> there is 8x8, 16x16 and 32x32 to do [21:29] <ubitux> and probably the iadst combinations [21:29] <durandal11707> you can do them faster now or? [21:29] <ubitux> now? [21:29] <ubitux> like in a few minutes? [21:30] <ubitux> i did the simplest one :p [21:31] <durandal11707> well it should be somethinkg like 1st: 8h -> 2nd: 6h -> 3th: 3h -> 4th: 1h -> 5th: 5 minutes [21:33] <ubitux> :D [21:46] <durandal11707> michaelni: mjpeg calls init_get_bits8 with bit_size = 0 [21:46] <durandal11707> should it not error out if size is 0, eg just return 0? [21:46] <durandal11707> and emulate /dev/zero [22:22] <Compn> kierank : what does klv metadata have to do with me? :) [22:22] <kierank> Compn: UAVs [22:23] <llogan> they'll have the metadata location of your beard at all times [22:23] <Compn> nooooooooooooooo [22:23] <llogan> here...use this beard net [22:23] <llogan> it has a painting of a "coldchin" on it so they won't know it's you [22:25] <Compn> how quickly 'academic research' turns into 'military weapon' :( [22:26] <Compn> also, 1millionth feature request to play and record video at the same time. this time from an rc plane pilot who wants to fly via video [22:26] <Compn> without pipe'ing video or nonsense like that [22:27] <Compn> vlc had 20 sec lag, so user couldnt use it effectively for realtime flight [22:27] <llogan> ubitux: hurry up and apply it so i can add "more optimizations" in my HEVC 'n VP9 decoding news patch [22:27] <durandal11707> that is sf [22:28] <Compn> michaelni : feature request for ffplay, add encoding support . or alternatively, add sdl output to ffmpeg [22:28] <Compn> should be easy... [22:28] <Compn> probably is not [22:28] <durandal11707> direct that to trac.ffmpeg.org [22:28] <Compn> ok [22:29] <Compn> whats it called? sdl outdev ? [22:29] <durandal11707> man ffmpeg-devices [22:31] <Compn> oh its already got one [22:31] <Compn> ffmpeg -i INPUT -vcodec rawvideo -pix_fmt yuv420p -window_size qcif -f sdl "SDL output" [22:32] <Compn> wow neat , ffmpeg -i INPUT OUTPUT -f xv display [22:33] <durandal11707> now you can see your beard at once [22:38] <cone-911> ffmpeg.git 03Stephen Hutchinson 07master:bd97ba72dc6f: avisynth: Introduce USING_AVISYNTH macro [22:38] <cone-911> ffmpeg.git 03Stephen Hutchinson 07master:1549122d2698: avisynth: Change most of the comments to /* */ from // [22:38] <cone-911> ffmpeg.git 03Stephen Hutchinson 07master:2c18bfe6af84: avisynth: Cosmetics [22:38] <cone-911> ffmpeg.git 03Stephen Hutchinson 07master:d10d60be6882: avisynth: Compact AvxSynth's avoidance of 2.6's colorspaces. [22:38] <cone-911> ffmpeg.git 03Stephen Hutchinson 07master:da9852670c69: avisynth: Don't declare structs anonymously [22:38] <cone-911> ffmpeg.git 03Stephen Hutchinson 07master:df6279e73701: avisynth: Remove a couple of useless AviSynthContext casts [22:38] <cone-911> ffmpeg.git 03Stephen Hutchinson 07master:cf31c1d4f835: avisynth: Remove outdated undef block [22:38] <cone-911> ffmpeg.git 03Stephen Hutchinson 07master:c7f9aab80142: avisynth: Use AV_* prefixes for video and audio IDs [22:38] <cone-911> ffmpeg.git 03Stephen Hutchinson 07master:7ac67583c3a8: avisynth: Switch a couple of AVERROR_UNKNOWNs to AVERROR(ENOMEM) [22:38] <cone-911> ffmpeg.git 03Stephen Hutchinson 07master:ac9529ceec19: avisynth: Simplify a stray av_log message [22:38] <cone-911> ffmpeg.git 03Stephen Hutchinson 07master:f87a2e1272b6: avisynth: Factor out a couple of returns [23:01] <llogan> my shitty tests shows native vp9 slower to decode, but i don't know what i'm doing [23:01] <durandal11707> send patch [23:02] <llogan> yeah, sure. let me just whip up that 32x32 for you in a minute [23:33] <BBB> ubitux: ok will review hopefully tonight [23:33] <BBB> ubitux: looked good on a quick glance earlier today [23:55] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:f0b26bf0f56e: avcodec/dvdec: dont try to decode ac when theres no input [23:55] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:e510171f31b9: avcodec: fix old codec ids [23:55] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:f1f0b01c4700: avformat/gxf: fix old codec id [00:00] --- Tue Oct 29 2013

1 0

ffmpeg.log.20131028
by burek 29 Oct '13

29 Oct '13

[00:53] <Samizdat> evenin [00:54] <Samizdat> If anyone who has hefty resources, a few GB of RAM, a feg GHz clock speed, good bandwidth, etc. and wishes to help me test a YouTube live stream download, I'd appreciate it. [00:54] <Samizdat> Just let me know, and I'll give you a download URL customized to your IP (which you'll need to supply me). [00:55] <Samizdat> Vienna via Brooklyn - the Delphi Chamber Orchestra at 720p (I'll even provide the 1080p live download link, if you think you can handle it) [01:01] <Samizdat> Here, I'll make it simple for you -- suspicion runs high these days, and I understand this, as mine does too -- http://shoutkey.com/pasture+ will show you the download link -- but you'll have to change the YOUR-IP-HERE part to, well, you know. [01:02] <sacarasc> What is this for? [01:04] <Samizdat> Take your modified URL, get yourself a shoutkey 24-hour URL, and further modify it thusly: http://coblitz.codeen.org/shoutkey.com/YOUR-MODIFIED-SHOUTKEY-HERE -- what this will do is avail you of Princeton's Large File Transfer Service, further enhancing speed. [01:06] <Samizdat> sacarasc: I don't have the resources to perform a decent 640p capture, let alone a 720p, but I wish to know if YouTube can supply one. [01:08] <Samizdat> oh, one last thing -- you Linux bugs probably have something even niftier than my lowly Windows Net Transport, which provides 2-threaded downloading. WXDownload Fast provides at least 5-threaded, but I've had bad results with that particular program. [01:10] <Samizdat> Hmm, that last post was a mistake. ffmpeg can handle the (properly modified) URL above, using the following command line: ffmpeg -i "http://shoutkey.com/YOUR-MODIFIED-SHOUTKEY-HERE" -v 0 yourfile.ts [01:12] <Samizdat> You can leave out the -v 0 part, but you'll have a very verbose output in your Command Prompt (or terminal). [01:14] <Samizdat> The live YouTube concert in question is at http://www.youtube.com/watch?v=0csF4V944Os , and two hours gone, so I don't know how much time you'll have, but it won't be forever. [01:17] <Samizdat> Corrected command line: ffmpeg -i "http://coblitz.codeen.org/shoutkey.com/YOUR-MODIFIED-SHOUTKEY-HERE -v 0 yourfile.ts [01:17] <Samizdat> Whew. [01:18] <Samizdat> I'll probably never see any feedback on this, but there it is, something new (perhaps) you didn't know before. [01:22] <Samizdat> P.S. -- with VLC version 2.1.0 Rincewind, simply play the YouTube watch URL, switch to playlist view (if you don't use playlist view by default), select (highlight) the playing item, right-click, sroll to "Information," left-click, and copy the Location URL, the one ffmpeg will use to make a .ts file from a number of segments. [01:22] <Samizdat> Alrighty then. [01:22] <Samizdat> Enjoy! [01:22] <Samizdat> Hopefully the Cards are either ahead, or tied at zero. [01:22] <Samizdat> I do dislike the Sox. [01:23] <Samizdat> Adios [03:28] <buu> So uh, if I compile ffmpeg then run make install, I get libavutil.a; but how do I get libavutil.so? [03:28] <buu> Or is it hiding someplace? [03:39] <Guest12270> Hi, can someone help me with direct show screencast command line commands [04:13] <buu> Ok seriously [04:13] <buu> How do I get .so files out of this thing? [04:55] <Plorkyeran> --enable-shared when running configure [04:56] <Plorkyeran> but that's usually the default... [06:08] <pzich> anyone have recommendations to get good, compact webm videos? I'm pretty happy with the profiles for libx264, but am not familiar with what's available for webm [15:11] <ThinkTank> Hi guys/girls. I'm working on a hobby project to create a simple CCTV application to show multiple 1080p camera streams on a flat screen tv. My problem is that i'm getting frame dropping when I have 5< streams. Any suggestions? CPU dosen't seem to be working that hard 50-60% [15:12] <durandal_1707> ThinkTank: what library you use? [15:13] <ThinkTank> Haven't chosen one yet. Just trying ffplay x 8 [15:13] <durandal_1707> ffplay is not library [15:14] <durandal_1707> ffplay is toy [15:16] <ThinkTank> I thought it was just bare metal on top of ffmpeg [15:16] <durandal_1707> ffplay use libsdl [15:17] <ThinkTank> ah [15:17] <ThinkTank> I thought it used opengl to render the video [15:17] <ThinkTank> my mistake [15:18] <Jimx-> question - I'm writing a project that will depend upon ffmpeg libraries. my project is multi-platform, and admittedly I am inexperienced with how dependencies such as this are handled on non-windows systems. should I use ffmpeg as a git submodule/etc? [15:19] <Plorkyeran> on linux people will want to use the copy of ffmpeg packaged by their distro [15:20] <Plorkyeran> on other platforms I'm a fan of git submodules for ffmpeg due to the general lack of API stability [15:20] <Jimx-> that's what I figured, I wouldn't want them to build it if they can just get it through a package manager, though I don't know quite how to handle includes and such [15:20] <Plorkyeran> as it makes pinning to a specific rev pretty useful [15:21] <Plorkyeran> whatever build system you're using should support using pkg-config to get all of the information you need to include/link the libs [15:21] <Plorkyeran> if it doesn't, use a better build system~ [15:22] <ThinkTank> durandal_1707: What do you suggest that I use for testing performance? [15:22] <Jimx-> ah, yea. like I said I'm a windows developer normally so my experience with proper tools is severely lacking. a slight bit in the dark, I'm glad I ended up asking [15:23] <Jimx-> thank you for the info [15:29] <plm> Hi all [16:16] <dreamhawk> Hello [16:17] <dreamhawk> quick question, how can i combine output-dir + seq%04d.ts ? like /tmp/stream/seq%04d.ts [16:17] <dreamhawk> Hope you understand what i want to do :) [16:18] <spaam> output-dir/seq%04d.ts [16:18] <spaam> done [16:19] <spaam> can you tell us what do you mean? [16:19] <dreamhawk> Nope, i get 1 file named seq%04d.ts, i want files like seq0000.ts, seq0001.ts, seq0002.ts etc [16:24] <dreamhawk> saste: im just trying to do 1 ffmpeg cmd :) . "ffmpeg -y -i stream -vcodec copy -acodec copy -b:v 800k -flags -global_header -map 0:1 -map 0:2 -hls_list_size 20 -hls_time 10 -hls_wrap 8 -segment_list /tmp/hls/stream.m3u8 /tmp/hls/files/seq%04d.ts" [16:24] <dreamhawk> without the "" . [16:26] <saste> dreamhawk, -f hls [16:26] <saste> ? [16:26] <saste> and trust me when i say !pb dreamhawk [16:27] <dreamhawk> saste: that is the line i am executing. no other script behind. [16:29] <saste> this team read the text, or no one can help [16:29] <saste> *time [16:30] <dreamhawk> saste: don't see colors on irssi ;). I will save the output. [19:05] <Guest12270> Can someone help me with directshow screencasting commands? [19:10] <llogan> durandal_1707: do you have an answer for this guy? http://ffmpeg.org/pipermail/ffmpeg-user/2013-October/018182.html [19:11] <llogan> Guest12270: https://trac.ffmpeg.org/wiki/How%20to%20grab%20the%20desktop%20%28screen%29… [19:11] <Guest12270> I already seen that [19:12] <Guest12270> not enough information to make it happen to my liking [19:12] <llogan> not enough information to make answer [19:14] <Hydrant> hi everyone, I'm attempting to do a screencast and figure out what I record isn't very sharp (the text gets fuzzy after a second or two)... I am recording 1280x720 and would expect that playback on my own system will look as sharp as the original screen rather than blurry [19:14] <Hydrant> ffmpeg -video_size 1280x720 -framerate 25 -f x11grab -i :0 output.flv [19:14] <Hydrant> that is the command I'm using on this first attempt [19:15] <durandal_1707> llogan: tell him to look at code if he does not want to pay for consulting [19:16] <llogan> durandal_1707: you can provide an answer [19:17] <durandal_1707> llogan: certainly, i can, but do I want? [19:19] <llogan> i did it for you [19:19] <llogan> with a shitty worthless answer [19:19] <Guest12270> What I need is to set directshow video source option to 30 FPS, audio codec to True audio(TTA), and output to mkv [19:20] <Guest12270> So far my guesses is: ffmpeg -f dshow -r 30 -i video="UScreenCapture":audio="Stereo Mix" -vcodec libx264 -crf 0 -preset slow -acodec tta -ac 8 -ar 192000 -ab 36864000 out.mkv [19:20] <durandal_1707> llogan: sorry, but answer is far from trivial, as question [19:22] <llogan> ok [19:23] <Guest12270> also have additional question about stereo mix and pixel formats [19:52] <llogan> Guest12270: what are your questions? where is the ffmpeg console output? [20:08] <Guest12270> My question is correct commands for screencasting by setting directshow video source to 30 frames per second, video codec to lossless h.264, audio source as stereo mix, audio codec as true audio(TTA) at 8 channel, 192000Hz, bitrate at 8*192000*24, and finally output to mkv [20:10] <Guest12270> and additional question include what pixel format provides best quality and how many channels of audio stereo mix provides [20:12] <Guest12270> and no console output since I didn't believe my guesses were correct in audio codec area [20:16] <pzich> do I need to blow away the 2pass log if I'm batch 2-passing files, or does it take care of that? [20:22] <llogan> Guest12270: the default pixel format will provide best quality. i can't answer anything else without console output [20:22] <llogan> pzich: you don't need to do anything [20:23] <pzich> llogan: cool, that's what I thought, but it's good to hear confirmed [20:31] <Guest12270> what console output do you want? [20:31] <Guest12270> options for the direct show devices? [20:32] <Guest12270> or list of direct show devices? [20:32] <llogan> you haven't tried your command yet? [20:35] <Guest12270> nope [20:36] <Guest12270> I only tried listing directshow devices and their options [20:41] <Guest12270> I think UScreenCapture and Stereo Mix as directshow devices are all that's required to answer my questions. [20:41] <Guest12270> and I can't copy and paste command prompt for some reason [20:46] <Guest12270> http://tinypic.com/view.php?pic=2h36hvm&s=5#.Um6_EhCFfjs [20:46] <Guest12270> is that what you wanted? [21:13] <llogan> it at least shows that you're using ffmpeg [21:40] <FunnyLookinHat> Anyone here done webm / libvpx encoding? I can't get it to output a nice-looking 1080p video for the life of me... -vcodec libvpx -s 1920x1080 -crf 10 looks like crap [21:42] <sacarasc> I thought -crf was libx264 only? *shrug* [21:42] <JEEB> I think they mapped it into something random for libvpx? [21:42] <FunnyLookinHat> Ah great. [21:42] <FunnyLookinHat> heh [21:42] <JEEB> and naturally the range of values is completely different [21:42] <FunnyLookinHat> This list crf but yeah... no go: http://trac.ffmpeg.org/wiki/vpxEncodingGuide [21:43] <JEEB> I think they added a kind-of-similar-to-CRF mode for vp9 into libvpx finally [21:43] <JEEB> but yeah, most probably it's the range of values that's different [21:43] <JEEB> so if it looks bad, push it lower? [21:44] <FunnyLookinHat> Yeah - I'll do that... :0 [21:45] <FunnyLookinHat> Thanks JEEB ! [21:45] <JEEB> vp8 will probably not have that really CRF-like mode tho [21:45] <JEEB> and the one for vp9 is two-pass it seems [21:45] <JEEB> so it first checks the whole clip, and then encodes it with the selected parameter [21:46] <FunnyLookinHat> Yeah - well I got something somewhat useful by just setting an extremely high bitrate... I'll try to match up to whatever h264 has in terms of bitrate and call it a day :) [21:47] <JEEB> sounds good enough I guess [21:48] <FunnyLookinHat> For testing and such it is :) [21:49] <JEEB> FunnyLookinHat, I guess you'll want to use 2pass bit rate based encoding for libvpx then :) [21:49] <FunnyLookinHat> Yeah definitely [21:49] <JEEB> libvpx stuff for vp9 kind of looks interesting, smarter got some kind of AQ done and such [21:49] <JEEB> and the constant quality mode kind of interests, too [21:55] <llogan> i don't think anyone knows how to encoder for VP8 [21:55] <llogan> *encode [21:56] <JEEB> and I'm not learning, mostly because it's clear that libvpx will be mostly pushing vp9 now, which at least isn't years late into the race [21:57] <JEEB> I'm also keeping an eye on the HEVC side's common suspects as far as encoders go [21:57] <llogan> ja ja ja [00:00] --- Tue Oct 29 2013

1 0

ffmpeg-devel.log.20131027
by burek 28 Oct '13

28 Oct '13

[00:57] <ubitux> BBB: rounding with pmulhrsw done, working on eob [00:57] <BBB> cool [00:57] <ubitux> i'll probably go to sleep soon though [00:57] <BBB> ok [00:57] <BBB> you understand the eob thing is not for the memset, but for the actual whole idct, right? [00:57] <ubitux> yeah sure [00:57] <BBB> ok [00:58] <ubitux> speaking of this [00:58] <BBB> just to be sure ;) [00:58] <ubitux> is there some other behaviour about that memset? [00:58] <ubitux> i mean, is there other special cases or checking for eob for the memset is enough? [01:00] <ubitux> i think i'll go to sleep. [01:00] <BBB> checking for eob should be enough [01:00] <ubitux> ok [01:00] <BBB> (for smaller memsets) [01:00] <BBB> e.g. if eob == 1, movd [block], zeroreg is enough [01:00] <BBB> if eob <= 3, movd [block], zeroreg and movd [block+idctsize*2], zeroreg is enough [01:00] <BBB> etc. [01:01] <ubitux> is libvpx doing those optim? [01:07] <BBB> ubitux: to a lesser extend, I think [01:07] <BBB> ubitux: you can check, I believe they do dc-only and full 4x4 [01:07] <BBB> they don't do a half 4x4 [01:08] <ubitux> ok [01:08] <BBB> I don't know if it's worth it, maybe I'm stupid and it isn't [01:08] <ubitux> btw, just made the "(a*x + b*y + round) >> shift [01:08] <BBB> but when I measured it, it was a situation that happened relatively often [01:08] <ubitux> ..." macro [01:08] <BBB> ah good [01:08] <ubitux> 2x at once [01:08] <BBB> I'll compare it to mine ;) [01:08] <BBB> mine does 2x also :-p [01:08] <ubitux> it was previously doing only one [01:09] <ubitux> but i'm guessing it can be faster with the // ? [01:09] <ubitux> anyway, it's still in https://github.com/ubitux/FFmpeg/compare/vp9-asm [01:10] <BBB> / is c/c++/java only [01:10] <BBB> // [01:10] <BBB> but for assembly, ; may help, right [01:11] <ubitux> ._. [01:11] <ubitux> i mean in parallel [01:11] <ubitux> :p [01:11] <ubitux> my brain is off, i don't get jokes anymore [01:12] <BBB> no you're right this is faster [01:12] <BBB> it decreases latency effect [01:12] <BBB> loren/jason usually refer to it as "pairing" [01:12] <ubitux> ok :) [01:13] <BBB> rest looks good, nice work... some stuff can be improved later for use in 8x8 or avx or xmm or whatnot, but this is a good start [01:14] <ubitux> i'm undecided about the macro [01:14] <ubitux> so it's inconsistent right now :p [01:14] <BBB> line 133-134 movd, not movq [01:14] <ubitux> ah, right [01:15] <ubitux> semantic of "mova" is "movq aligned"? (i'm using it for registers) [01:15] <BBB> sort of [01:15] <ubitux> (it seems to generate a movq anyway) [01:15] <BBB> mova = movq for mmx [01:15] <BBB> mova = movdqa doe xmm [01:15] <BBB> doe=for [01:15] <BBB> mova is one of those macro things to share code between xmm/mmx/ymm [01:15] <BBB> e.g. VP9_MULSUMSUB [01:16] <BBB> but it's ok for now, I wouldn't worry too much about it [01:16] <ubitux> ok [01:16] <BBB> if it works, it's fine, and we'll update it as we work on it for 8x8/16x16/32x32/etc [01:17] <BBB> right now it's mmx only so it's ok [01:17] <ubitux> it seems to work yes [01:17] <ubitux> :p [01:17] <BBB> I mean there's some other things also, like constants being mmx-sized and aligned (instead of xmm), naming being slightly generic ("round", "t2" and "t3") but that's all fine, we can modify that later [01:17] <BBB> pw_2048 is better than pd_round already [01:18] <BBB> I care mostly that the code works, esp. for assembly [01:18] <BBB> and this works [01:18] <BBB> so it's fine [01:18] <BBB> the vp8 code wasn't perfect either [01:18] <BBB> but it was quite good [01:19] <ubitux> i'll write the eob case and send for review [01:19] <ubitux> or maybe you want to wait for the whole code at once? [01:41] <BBB> ubitux: up to you, either way is fine (because either way it'll be a speedup) [02:34] <cone-769> ffmpeg.git 03Michael Niedermayer 07master:f3d0642d35fa: avutil/utils: check that size_t is unsigned [02:34] <cone-769> ffmpeg.git 03Michael Niedermayer 07master:1e5271a9fd6d: avformat/utils: do not override pts in h264 when they are provided from the demuxer [09:22] <cone-911> ffmpeg.git 03Stefano Sabatini 07master:d61617a52349: lavu/parseutils: add av_get_known_color_name() [09:22] <cone-911> ffmpeg.git 03Stefano Sabatini 07master:4e268285aaff: cmdutils: add -colors option [10:01] <cone-911> ffmpeg.git 03Anton Khirnov 07master:346e09638cc1: avcodec/error_resilience check error_concealment, not err_recognition. [10:01] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:3b56f665b1cd: avcodec/flacdec: also do crc check when er compliant is set [10:29] <cone-911> ffmpeg.git 03Guillaume Martres 07master:7b0f61a93604: FATE: update HEVC tests [11:18] <michaelni> mraulet, smarter, should i update hevc* to the latest patch from anton? [11:18] <michaelni> it seems anton didnt include all changes from openhevc/hevc_upstream [11:19] <mraulet> I have to [11:19] <mraulet> I am checking the sequences with one patch [11:19] <mraulet> it seems to not fail [11:19] <mraulet> the bugs on trac [11:21] <michaelni> ok so i will wait for you to update openhevc/hevc_upstream and then cherry pick all new changes from there [11:21] <michaelni> thanks! [11:21] <mraulet> opnhevc/ffmpeg/master [11:21] <mraulet> *openhevc [11:22] <mraulet> when is the release? [11:25] <michaelni> i was considering to do it today but i still need to test a few things and if there are issues it could be delayed [11:26] <michaelni> today night at the earliest [11:26] <michaelni> if some issues than could be in a few days [11:31] <michaelni> also i can wait if you / hevc needs more time [11:45] <cone-911> ffmpeg.git 03Anton Khirnov 07master:83d96e9a19ba: Changelog: add entry for HEVC support. [11:45] <cone-911> ffmpeg.git 03Yusuke Nakamura 07master:f7f88018393b: hevc: Search start code in decode_nal_units(). [11:45] <cone-911> ffmpeg.git 03Yusuke Nakamura 07master:afa93d198aaf: hevc_parser: Set pict_type, key_frame and output_picture_number. [11:45] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:10386710fd8e: Merge commit 'afa93d198aaf2cc661c4df6d4095cd030265d30a' [12:08] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:09ef98f1ae3c: avcodec/hevcpred_template: Fix integer overflows [12:18] <cone-911> ffmpeg.git 03Timothy Gu 07master:21f22908c6ae: MAINTAINERS: add my name for Launchpad [12:27] <ubitux> BBB: eob seems to never be 0 [12:27] <ubitux> also, it seems to be relatively high sometimes [12:27] <ubitux> last, it seems some completely zero blocks have eob != 1 [12:27] <ubitux> is all of this expected? [12:34] <ubitux> http://lists.libav.org/pipermail/libav-devel/2013-October/052388.html "refactor the code" :') [12:36] <nevcairiel> thats the new name for mixing cosmetics and functional changes [12:37] <ubitux> K&R isn't hype anymore [12:43] <ubitux> and again, those random line breaks make the code completely unreadable [12:43] <ubitux> i still didn't find were are the functionnal changes after staring at the diff for 5 minutes [12:44] <ubitux> but well, 2.7k lines of diff. [12:44] <ubitux> well, it's certainly just a joke [12:44] Action: ubitux moves on [12:45] <cone-911> ffmpeg.git 03Stefano Sabatini 07master:d3aa04b1500f: doc/protocols/rtp: apply misc fixes [12:46] <ubitux> BBB: anyway, i find this a bit curious: http://pastie.org/8434352 [13:02] <cone-911> ffmpeg.git 03Timothy Gu 07master:43041a7b4aa2: doc/encoders: add libshine doc [13:09] <saste> ubitux, how's going the web job? [13:12] <saste> do we have the equivalent of splitplanes/components? [13:12] <ubitux> not started, scheduled for end of next month [13:12] <saste> ubitux, ok [13:12] <kierank> nevcairiel: 80 chars is pointless [13:12] <saste> i'll probably add a goodies section if i find the right inspiration [13:13] <ubitux> hehe [13:13] <BBB> ubitux: what is a complete zero block? [13:13] <saste> ubitux, PHP or JS is fine? [13:13] <saste> uh my grammar is particularly bad today [13:13] <ubitux> BBB: see the pastie; block[0..16] = 0x0000 [13:14] <ubitux> saste: i think it will just be static [13:14] <BBB> how do you print them? [13:14] <saste> ubitux, boring :( [13:15] <ubitux> BBB: http://pastie.org/8434401 [13:15] <ubitux> on etv.webm [13:15] <saste> git co -b lavfi-reconfiguration [13:15] <saste> let's see if i manage to do something about that... [13:15] <ubitux> saste: yay :) [13:16] <BBB> ubitux: what clip? [13:16] <ubitux> etv.webm [13:16] <ubitux> do you still have it [13:16] <ubitux> ? [13:16] <BBB> etv? [13:16] <BBB> not sure... [13:16] <BBB> weird [13:16] <BBB> I don't think that should happen [13:16] <ubitux> enter the void [13:17] <ubitux> the 1080p sample i sent you a while ago [13:17] <BBB> hm... [13:17] <BBB> right [13:17] <ubitux> which i generated with your libvpx example [13:17] <BBB> ok so it shouldn't happen [13:17] <BBB> not sure why it does [13:21] <ubitux> BBB: http://lucy.pkh.me/samples/vp9/ [13:22] <BBB> ty [13:22] <BBB> still not sure how that could happen [13:23] <ubitux> bug/inefficiency in the encoder? [13:26] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:0aba920d617d: avcodec/tiff: Fix use of uninitialized off variable [13:26] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:d5ad4e4a2f12: avcodec/tiff: remove TIFF_LONG special case [13:26] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:46143d255589: avcodec/tiff: factorize offset init code [13:27] <saste> who remembers why we don't have AVFilterLink.type? [13:28] <BBB> ubitux: no, you can not encode an eob without a non-zero coeff before it [13:28] <BBB> ubitux: so this is physically impossible :-) [13:28] <BBB> ubitux: so I'm very curious what's going on [13:29] <BBB> ubitux: it's certainly possible to code 16 zeros, but eob is halfway the block so that's not what's going on either [13:29] <BBB> or maybe the eob value is broken... [13:29] <BBB> it worked for 32x32 though [13:38] <ubitux> saste: so, what's this @xref{} ? [13:38] <ubitux> (cross reference?) [13:38] <saste> ubitux, where? [13:39] <ubitux> the patch you just applied [13:39] <ubitux> +@xref{libshine} for a fixed-point MP3 encoder, although with a lower quality. [13:40] <saste> it should be @ref [13:52] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:7eda2e524b8e: avcodec/vc1_parser: check ff_vc1_parse_frame_header*() return value [13:52] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:2c7c2a53b942: vcodec/vc1dec: remove dead code [13:59] <BBB> oh I think I got it [13:59] <BBB> funny [14:01] <BBB> ubitux: nice bug [14:01] <BBB> ubitux: (my bug, not yours) [14:01] <ubitux> maybe we should have some code in the C reference to use that eob [14:08] <BBB> ok fixed [14:09] <BBB> ubitux: maybe... I'd rather just write fast simd and ignore the c [14:09] <BBB> anyway, bug fixed [14:09] <BBB> will send a patch [14:13] <BBB> patch sent [14:16] <wm4> what's the policy for API additions in ffmpeg? [14:17] <kierank> wm4: you can do it if libav doesn't have it [14:17] <kierank> </troll> [14:19] <ubitux> BBB: yeah but when writing simd it's cool to have a reference; imagine someone wants to write arm simd, it might be better to use C as reference than intel one [14:26] <ubitux> BBB: and so, why the eob has "invalid" value when skip is defined? it's the previous block decode value? [14:31] <BBB> ubitux: right, it's not written to if skip=1 [14:31] <ubitux> BBB: can you push? [14:33] <BBB> to where? [14:34] <ubitux> upstream? [14:34] <BBB> I don't know if my ssh key still works, I generally let michael push, much easier [14:35] <michaelni> you key should work but if you prefer i can push, i just need to know what to push [14:35] <michaelni> youR [14:49] <ubitux> [FFmpeg-devel] [PATCH] vp9: skip itxfm_add if the whole block has no coefficients. [14:49] <ubitux> this one ^ [14:52] <ubitux> BBB: what about changing the code in inter_reconn as well? [14:58] <ubitux> michaelni: maybe too fast :p [15:01] <BBB> ubitux: not necessary [15:01] <BBB> ubitux: the whole block is under if (!b->skip) [15:01] <BBB> ubitux: you wrote it :) [15:01] <ubitux> ah :)) [15:03] <cone-911> ffmpeg.git 03Benedict Endemann 07master:696aa74b1ab3: lavfi/overlay: correct small error in intersection detection [15:07] <saste> ubitux, what's the problem with xref? [15:08] <cone-911> ffmpeg.git 03Ronald S. Bultje 07master:cd86eb265f36: avcodec/x86/videodsp: fix a bug in a %if statement where we used '%%' instead of '&&'. [15:08] <cone-911> ffmpeg.git 03Ronald S. Bultje 07master:960490c0b20d: avcodec/x86/videodsp: Small speedups in ff_emulated_edge_mc x86 SIMD. [15:08] <cone-911> ffmpeg.git 03Ronald S. Bultje 07master:efc5a54cab8a: vp9: skip itxfm_add if the whole block has no coefficients. [15:20] <ubitux> saste: i don't know, i'm wondering what it is [15:29] <saste> ubitux, silly, texi2pod doesn't generate it [15:30] <saste> that's why we removed them at some point [15:32] <cone-911> ffmpeg.git 03Stefano Sabatini 07master:5b53dd0803ba: doc/encoders: replace @xref with @ref command [15:33] <ubitux> memset(s->counts.coef, 0, sizeof(s->counts.coef) + sizeof(s->counts.eob)); [15:33] <ubitux> yay. [15:33] <ubitux> :) [15:34] <nevcairiel> i'm no expert, but that looks funky [15:34] <BBB> that looks broken :) [15:35] <BBB> I guess it works b/c eob is right after coef? [15:35] <ubitux> yes [15:35] <BBB> (not as guaranteed by the c standard; just b/c of luck) [15:35] <BBB> yeah we should probably split that [16:13] <ubitux> BBB: if eob=4, the 4th value could be anywhere in block[2, 5 or 8]? [16:13] <ubitux> (zigzag placement always?) [16:13] <BBB> see vp9_default_scan_4x4 [16:14] <BBB> 0,1,4,5 [16:14] <BBB> so apparently eob=4 is still ok [16:14] <BBB> I didn't see that before [16:15] <ubitux> it's always following that scan? [16:15] <ubitux> i can't be in the situation where it's a col scan? [16:15] <ubitux> the col scan will only happen with idct+iadst i suppose? [16:16] <ubitux> col/row scale with idct+iadst/iadst+idct? [16:16] <ubitux> scan* [16:16] <ubitux> or that's totally unrelated? [17:09] <BBB> ubitux: row/col scan is adst/dct or dct/adst [17:09] <BBB> ubitux: dctx2 is always default scan [17:10] <ubitux> ok [17:10] <ubitux> i'm done with the dc only, i think [17:10] <BBB> cool [17:10] <BBB> will you do 2x2 also? [17:11] <ubitux> probably [17:25] <ubitux> BBB: is it ok to have multiple RET? [17:26] <ubitux> or it's somehow doing macro magics? [17:29] <ubitux> BBB: i pushed the dc-only one [17:29] <ubitux> https://github.com/ubitux/FFmpeg/compare/vp9-asm#diff-f5653acbc04f21d22eaa6… [17:33] <BBB> multiple RET is fine [17:34] <ubitux> ok [17:34] <BBB> ubitux: having movq m1/2/3, m0 is kind of ugly; maybe have VP9_STORE take the input registers [17:34] <ubitux> oh good idea [17:34] <BBB> and movq m0, [blockq] -> movd, not movq [17:34] <ubitux> arh :D [17:34] <BBB> or maybe pinsrw [17:35] <BBB> movd is fine I think [17:39] <BBB> oh it's pextrw, not pinsrw, anyway, movd is fine [17:52] <ubitux> BBB: does "pairing" works with 4? :p [17:52] <ubitux> or i should interleave 2 by 2? [17:54] <BBB> I don't think 4 has any additional advantage over 2, usually [17:55] <BBB> if you have enough registers, no reason to not do it [17:55] <BBB> but it's totally up to you [18:09] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:4307026243c0: avformat/utils: make "first_dts not matching first dts in the queue" message more informative [18:09] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:d9bc251d3978: ffmpeg_filter: Fix non jpeg yuv in jpeg support [18:17] <ubitux> BBB: m0 dup removed [18:17] <ubitux> branch up-to-date [18:17] <ubitux> looking at the 2x2 now [18:20] <ubitux> so, <= 4? [18:21] <ubitux> 0, 1, 4, 5 is the 2x2 top left block, should be good [18:36] <BBB> ubitux: exactly [18:40] <durandal_1707> michaelni: i assume maxsize in ffv1 enc is supposed to measure raw size of uncompressed video [18:41] <durandal_1707> if that is true, calculation is not correct for many pixel formats [18:42] <durandal_1707> i think there is/should be function from lavu that can calculate this [18:56] <ubitux> BBB: will this 2x2 really time saving? [18:56] <BBB> I think it should [18:56] <BBB> most importantly because you can do pmulhrswx2 for each 1d idct, instead of pmulhrsw + the long vp9_pmulsumsub thingy [18:57] <ubitux> mmh [18:57] <ubitux> ok [18:58] <BBB> it's not as much a win as dc-only, but that's because dc is a very special case [18:58] <ubitux> we're gonna get a huge load of asm just for this 4x4 [18:58] <ubitux> i wonder how big the other are gonna be :)) [18:58] <BBB> check the binary size of x86/vp9dsp.o versus the c version [18:58] <ubitux> also, i suppose we'll have to do the adst combination as well [18:58] <BBB> (do it, for fun, in vp8) [18:59] <ubitux> yeah, a bit smaller :) [18:59] <ubitux> -rw-r--r-- 1 ubitux ubitux 34K Oct 27 18:59 libavcodec/vp8dsp.o [18:59] <ubitux> -rw-r--r-- 1 ubitux ubitux 29K Oct 27 18:59 libavcodec/x86/vp8dsp.o [18:59] <ubitux> (stripped) [18:59] <BBB> my point is, it's not 10x as big [18:59] <BBB> even though e have mmx, mmx2, sse2, ssse3, sse4 [18:59] <BBB> here, we only do ssse3 [18:59] <BBB> so it's fine [19:00] <ubitux> yeah ok :) [19:03] <ubitux> not sure i'll get done with 2x2 tonight [19:03] <ubitux> :( [19:58] <cone-911> ffmpeg.git 03Paul B Mahol 07master:292902ea9ff1: avfilter: add mergeplanes filter [19:58] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/0.10:c08127c5e692: avformat/utils: do not override pts in h264 when they are provided from the demuxer [19:59] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/0.11:b89e5b138f01: avformat/utils: do not override pts in h264 when they are provided from the demuxer [19:59] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/0.7:1049328cf013: avformat/utils: do not override pts in h264 when they are provided from the demuxer [19:59] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/0.8:115efdefc5f4: avformat/utils: do not override pts in h264 when they are provided from the demuxer [19:59] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/0.9:b6f5a54fddeb: avformat/utils: do not override pts in h264 when they are provided from the demuxer [19:59] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/1.0:65daa390f87f: avformat/utils: do not override pts in h264 when they are provided from the demuxer [19:59] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/1.1:4c17e20ff05a: avformat/utils: do not override pts in h264 when they are provided from the demuxer [19:59] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/1.2:93d720b040bf: avformat/utils: do not override pts in h264 when they are provided from the demuxer [19:59] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/2.0:f51483491749: avformat/utils: do not override pts in h264 when they are provided from the demuxer [20:07] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:2ef1e62c8dcf: correct the AVOption documentation for AV_EF_CAREFUL [20:07] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:fc7be7ddf3de: avcodec/avcodec.h: Add documentation for the AV_EF_* defifines [20:10] <ubitux> defifines [20:10] <ubitux> is that cute defines? [20:10] <durandal_1707> fail [20:11] <ubitux> cool to see doc though :) [20:11] Action: wm4 wonders when ffmpeg will fix its terrible build system [20:11] <durandal_1707> with something like waf? [20:11] <ubitux> :D [20:11] <ubitux> wm4: still refering to the sdl? [20:12] <ubitux> or something else? [20:12] <nevcairiel> there are no good build systems :p [20:12] <ubitux> btw, isn't the recently added rpath problematic after make install? [20:13] <ubitux> like, leaking some random path in installed binaries [20:13] <wm4> ubitux: if an update removes or adds a file, the build will mysteriously fail, unless you run make clean before [20:13] <ubitux> ah the dependency thing [20:14] <ubitux> i'm a bit annoyed about that thing yes [20:14] <ubitux> wm4: for adding a file it's normal [20:14] <ubitux> and you don't need to make clean [20:14] <ubitux> when removing it's problematic [20:14] <ubitux> because the file reference exists in the dependency files [20:15] <wm4> anyway, "it randomly fails and after make clean it works" [20:15] <ubitux> (and somehow they're not updated properly after a configure?) [20:15] <cone-911> ffmpeg.git 03Derek Buitenhuis 07master:6ef30976e00a: timefilter: Handle memory allocation failure [20:15] <cone-911> ffmpeg.git 03Derek Buitenhuis 07master:52aed19307ee: avfiltergraph: Properly handle memory allocation failure [20:15] <cone-911> ffmpeg.git 03Derek Buitenhuis 07master:d206fd996bda: avio: Check for memory allocation failure of private data [20:19] <wm4> amazing, 1e5271a9fd fixed some ever-broken ts samples [20:48] <ubitux> BBB: afaict you can skip do the pmulhrsw x2 only for the first 1d idct [20:48] <ubitux> because second one has values for the whole 2x4 values of the block [20:49] <ubitux> oh mmh wait [20:49] <ubitux> yeah sorry forget it you're right [20:50] <ubitux> 'forgot the transpose :) [20:54] <cone-911> ffmpeg.git 03Michael Niedermayer 07release/2.0:1fa7ad2e20db: ffmpeg_filter: Fix non jpeg yuv in jpeg support [20:58] <BBB> ubitux: lol :) indeed [20:59] <ubitux> yeah well i hope to get done with this in a few days [20:59] <BBB> ubitux: the gains for the larger (e.g. 16x16) are bigger [20:59] <BBB> because imagine you're doing 8 coeffs per iteration [20:59] <BBB> e.g. 8x16 [20:59] <BBB> that means you have to loop twice [20:59] <BBB> per 1d [20:59] <BBB> right? [20:59] <BBB> if you do a 8x8 topleft only, you don't have to loop [20:59] <BBB> you only do that one iteration [21:00] <BBB> (that only goes for the first 1d, but still) [21:00] <BBB> so more gains yay [21:00] <ubitux> yeah ok :) [21:00] <ubitux> gtg [21:00] <ubitux> cya, and thx for the help :) [21:01] <BBB> bye [21:25] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:2886d6cbb71b: avcodec/takdec: also do crc check when er compliant is set [21:25] <cone-911> ffmpeg.git 03Anton Khirnov 07master:c7027ce9eac0: avcodec/options_table: disable CRC checking by default [21:25] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:b1348eb68b43: avcodec/options_table: set err_detect to careful by default [21:29] <cone-911> ffmpeg.git 03Paul B Mahol 07master:75b2bbe21d93: libavfilter/vf_noise: relicense to LGPL [22:10] <cone-911> ffmpeg.git 03Lukasz Marek 07master:e5b3b75669fc: lavd/pulse_audio_enc: fix timestamp calculation [22:10] <cone-911> ffmpeg.git 03Lukasz Marek 07master:4fb3aa491b47: lavd:pulse_audio_enc: fix array compared against 0 [22:10] <cone-911> ffmpeg.git 03Lukasz Marek 07master:7f5e75eea940: lavd/pulse_audio_enc: more stream validation restrictive [22:10] <cone-911> ffmpeg.git 03Lukasz Marek 07master:b04af34600d0: lavd/fbdev_enc: more stream validation restrictive [22:36] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:e797bd9dc771: Revert "avcodec/options_table: set err_detect to careful by default" [22:36] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:69d39cb90c24: Revert "avcodec/options_table: disable CRC checking by default" [22:36] <cone-911> ffmpeg.git 03Michael Niedermayer 07master:758b6d39f685: avcodec/hevc: calculate checksum only if AV_EF_EXPLODE is set [22:52] <cone-911> ffmpeg.git 03Lukasz Marek 07master:b387a24cb4ad: lavd/fbdev_enc: remove unused variables [23:14] <cone-911> ffmpeg.git 03Marton Balint 07master:dbe6f9f2c233: lavc: add support for CODEC_CAP_DELAY in subtitles [00:00] --- Mon Oct 28 2013

1 0

ffmpeg.log.20131027
by burek 28 Oct '13

28 Oct '13

[02:21] <norbert_> hi folks, I'm using ffmpeg to record the desktop, an area of 1280x720, at 25 fps [02:21] <norbert_> for some reason it's framedropping, even though CPU usage for dual core is only at 50% (of 200%) using recording [02:21] <norbert_> I don't need the audio [02:21] <norbert_> what I'm using is: ffmpeg -an -f x11grab -r 25 -s 1280x720 -i :0.0+46,118 -vcodec ffvhuff -crf 0 output.avi [02:22] <sacarasc> What's your disk usage looking like? [02:22] <norbert_> iotop shows about 30 M/s [02:23] <norbert_> 99.99% IO> now and then [02:23] <norbert_> interesting [02:23] <norbert_> so that's the problem then [02:23] <norbert_> I need a non-raw codec? [02:23] <klaxa> ffvhuff is not raw ;) [02:24] <klaxa> you could try libx264 with -qp 0 [02:24] <klaxa> and -preset ultrafast [02:24] <norbert_> I don't have 264 compiled here [02:24] <klaxa> that should put more strain on the CPU, but le-- oh [02:24] <klaxa> well what codecs DO you have available? and would compiling x264 be an option? [02:24] <norbert_> I think most Linux distros don't have 264, not even Ubuntu [02:24] <klaxa> because right now, it's the best option [02:24] <klaxa> um... i think most have [02:26] <norbert_> maybe the static build at http://ffmpeg.gusari.org/static/32bit/ has it, let me check [02:26] <klaxa> oh right, those usually have it [02:26] <klaxa> but no x11grab i think [02:27] <norbert_> Unknown input format: 'x11grab' [02:27] <norbert_> right [02:27] <klaxa> you could do some weird piping, but that might reduce performance heavily [02:27] <klaxa> not too sure how well pipes play in this [02:28] <norbert_> any idea why such static builds do not include x11grab? [02:28] <klaxa> actually i don't know [02:28] <klaxa> i know too little about X and ffmpeg to answer that question [02:28] <norbert_> ok [02:28] <klaxa> it will probably have to do something with shared libraries and runtime stuff [02:29] <klaxa> x11grab accesses the pixels over a shared memory segment with X [02:29] <klaxa> as far as i understand [02:29] <norbert_> do you know a nice configure string I can use to get the ffmpeg I need with both x11grab and libx264? [02:31] <norbert_> I don't think Ubuntu has x264 support either, last time I used Ubuntu it didn't [02:31] <norbert_> Debian doesn't either, and I'm on Mint so Mint doesn't either [02:32] <norbert_> Unknown encoder 'libx264' [02:33] <buu> --enable-libx264 enable H.264 encoding via x264 [no] [02:33] <norbert_> yeah, and --enable-x11grab [02:33] <norbert_> default [no], yeah [02:34] <norbert_> weird "libx264 is gpl and --enable-gpl is not specified." [02:34] <norbert_> I'd expect that to say not gpl, and --disable-gpl [02:34] <klaxa> well the configure line i use for my custom build is: [02:34] <klaxa> --enable-gpl --enable-nonfree --enable-libass --enable-libfdk-aac --enable-libvorbis --enable-libx264 --enable-librtmp --enable-libvpx --enable-libopus --enable-shared --enable-x11grab --enable-pic [02:35] <klaxa> i think that covers pretty much everything i need and use [02:35] <klaxa> x264, vpx, ass, aac, vorbis, opus, x11grab [02:35] <klaxa> and well rtmp if i ever need it [02:35] <norbert_> looks good [02:35] <norbert_> it's running [02:38] <klaxa> oh hmm... libpulse maybe too if that's needed as an input dev? :x [02:38] <norbert_> libfdk_aac seems a bit weird in there [02:38] <norbert_> I guess I could compile it from: git clone --depth 1 git://github.com/mstorsjo/fdk-aac.git [02:38] <norbert_> but it's not in the apt repos [02:39] <norbert_> well, I'm not recording audio, so libpulse isn't necessary [02:39] <norbert_> so I guess I can remove the AAC audio encoder as well [02:40] <klaxa> sure [02:55] <norbert_> hm... it says: ./ffmpeg: error while loading shared libraries: libavdevice.so.55: cannot open shared object file: No such file or directory [02:56] <norbert_> even though "libavdevice53 is already the newest version." [02:56] <norbert_> it seems that ffmpeg from git is relying on 55, while my system has 53 [02:58] <norbert_> I'm not going to recompile more than ffmpeg, so this isn't working [02:58] <norbert_> I need to try another video codec that my system's ffmpeg supports [03:00] <norbert_> klaxa: something else I could try instead of ffvhuff (or libx264) to lower the IO load? http://pastebin.com/Rky6dS2G [03:16] <Stelpa> hullo! i am trying to set up a twitch.tv stream on linux using this great lil script (https://github.com/wargio/Twitch-Streamer-Linux) and it's ALMOST working, but its segfaulting, after an error that says "Incompatible pixel format 'bgra' for codec 'libx264', auto-selecting format 'yuv420p'" [03:17] <Stelpa> a separate script i tried also gave a libx264 error [03:17] <Stelpa> why would libx264 not be working properly? [03:17] <sacarasc> Can you paste the full output to a pastebin? [03:18] <Stelpa> sacarasc, absolutely, gimmee one second [03:21] <Stelpa> this is the complete output of the program, sacarasc. it's not a really complicated program, but i assume it's just the end part that'll be of use, since the rest is just setup messages (after i start streaming i'm supposed to be able to set audio sources in the mixer, but i can't really do that because of the segfault... the script just ends itself as if i ended it manually) [03:21] <Stelpa> http://pastebin.com/82fXajMX [03:26] <Stelpa> my avconv is a very recent version (october 11th build) [03:28] <sacarasc> You were asked to do the command outside of the script, but anyway, avconv is not from ffmpeg, but from libav. Go to #libav for help with it. [03:29] <Stelpa> oh [03:29] <Stelpa> i see, sorry :X [03:29] <Stelpa> i dont really know how to do it separate from the script [03:29] <Stelpa> i'm kinda a noob at this [03:29] <Stelpa> but i'll try at libav [03:30] <Stelpa> i assumed that avconv was part of ffmpeg [03:30] <Stelpa> sorry :X [03:30] <Stelpa> bye! [03:35] <Ulfalizer> av_rescale_q(a, b, c) computes a*b/c, right? [03:38] <norbert_> yes av_rescale_q(a,b,c) is a function that will rescale a timestamp from one base to another. It basically computes a*b/c but this function is required because that calculation could overflow. AV_TIME_BASE_Q is the fractional version of AV_TIME_BASE. They're quite different: AV_TIME_BASE * time_in_seconds = avcodec_timestamp and AV_TIME_BASE_Q * avcodec_timestamp = time_in_seconds (but note that AV_TIME_BASE_Q is actually an AVRational obj [03:38] <norbert_> ect, so you have to use special q functions in avcodec to handle it). [03:38] <norbert_> (from http://dranger.com/ffmpeg/tutorial07.html ) [03:57] <Ulfalizer> ok, thanks [03:59] <Ulfalizer> currently trying to make sense of ffmpeg.c. i'm not sure what the best practice for dealing with a/v synchronization in a "generic" way (like for output-example.c) is, so that's what i'm trying to glean. [04:00] <Ulfalizer> it's for an emulator movie recording feature. i have video working (via an add_video_frame() function), but not sure how to deal with a/v synchronization if i add a corresponding add_audio_frame(). [04:00] <Ulfalizer> just in case you have any input :) [04:02] <Ulfalizer> could set PTS values on both video and audio frames, but i don't know if all encoders respect those for audio frames [04:03] <Ulfalizer> i'm not sure how syncing on just the sample rate with video PTS values only would work. seems like it'd be tricky to get exactly right. [04:05] <norbert_> I personally know nothing about it [04:05] <Ulfalizer> ok, i'll keep digging then :) [05:09] <COBadger> I'm looking for an FFMPEG expert to help me structure a system to create small clips from .mp4 and AVCHD .mts files, then combine them into high-quality .mp4 output files. Can someone point me in the right direction? [07:38] <Ulfalizer> does mpeg have timestamps for the audio stream too, or is the timing purely based on sample rate there? [07:38] <Ulfalizer> i.e., is the audio PTS inferred from the number of samples that have been played? [09:50] <seece> hi i'm trying to stream h264 in a mpegts through rtp to ffplay, but it segfaults [09:50] <seece> here's what happens: http://pastebin.com/raw.php?i=CuE7FGZg [09:51] <seece> any advice? [11:40] <zth_studiocomp> i want to change a videofile from 50fps to 25fps, but peserve the quality. how would i go about doing that? [11:40] <zth_studiocomp> preserve* [11:41] <Apic> Sounds pervert! [11:42] <zap0> zth_studiocomp, why would quality change? [11:42] <JEEB> because if he's using a non-intra format he'd have to re-encode :) [11:42] <zth_studiocomp> zap0, absolutely no clue! but it did. $ ffmpeg -i test.mov -r 25 outfile.avi <- that's what i did [11:42] <JEEB> yes [11:42] <JEEB> welcome to ffmpeg defaults [11:43] <zth_studiocomp> JEEB, thanks i guess ;) [11:43] <JEEB> ffmpeg -i test.mov -r 25 -c:v libx264 -crf 23 -preset medium -c:a copy out.mov [11:44] <zth_studiocomp> JEEB, thank you very much! [11:44] <JEEB> uses the libx264 H.264 encoder, uses the CRF rate control, which is closest to "constant quality", sets the medium preset (speed vs compression) which is also the default [11:44] <JEEB> and copies the audio [11:44] <JEEB> you should encode short parts (A few thousand frames) with this crf and see if it looks good enough for you [11:44] <JEEB> if it does, raise it [11:44] <JEEB> if it doesn't, lower it [11:44] <JEEB> find the highest crf value that is good enough looking for you :) [11:44] <JEEB> and that's it [11:45] <JEEB> then encode the whole thing with that [11:45] <zth_studiocomp> JEEB, thanks a bunch! so i should take note of the crf i use for the future encoding? [11:46] <JEEB> yes, and you probably will want to use a different CRF value for SD and HD content, as SD content is more often upscaled to a higher resolution during playback, so it might need a higher quality level. That said, it's all up to your eyes :) [11:47] <JEEB> 23 is the default crf value for x264, and then you go up or down or use it as-is depending on how the end result looks :) [11:50] <zth_studiocomp> JEEB, thank you very much for your help. i will get to work! :) [11:54] <JEEB> shouldn't be too hard :) [14:06] <Jaken> Hello, How can I broadcast audio on Linux? I'd like to broadcast a music-track. [16:01] <zybil> hi [21:19] <Mattias> So, I got this script for streaming with ffmpeg to twitch.tv. Here it is: http://pastebin.com/fGX2wzMX Now, I got a new line, 100mbit up and down. But if I try to change to full outres at 19200x1200, the stream "lags", I tried with 15 fps and it doesn't help either. I've also tried upping the maxrate to 100mbit, no change. above 1mbit doesn't seem to make a diffrence. How can I optimize this script for my [21:19] <Mattias> connection and send the full resolution while streaming? Not possible? [21:19] <Mattias> the outres in the paste works fine, about half the size of inres I think [21:20] <Mattias> I guess the tweaks to get this to work has to do with the encoding parts [21:21] <Mattias> This will stream all from fps games with fast moving frames to dwarf fortress which has hardly any changes on screen [21:50] <Mattias> JEEB: If you are experienced in this area of ffmpeg, please let me know when you see this :) (the 5 lines above this one) [21:52] <klaxa> Mattias, what's your CPU load during that? [21:53] <Mattias> klaxa: haven't checked, testing now [21:55] <cbsrobot> Mattias: try ultrafast, instead of fast [21:57] <Mattias> ok, got stuff setup, time to try, both with fast and ultrafast :) [21:57] <fazias> better test first to save to disk I think? [21:58] <fazias> ie. offline test, to see if you have bottlenecks [21:58] <fazias> like whats the maximum fps x11grab can do. [21:59] <klaxa> x11grab should be able to do way more fps than you can save [21:59] <klaxa> because of either too slow disks or too slow CPU [21:59] <Mattias> ssd disk [21:59] <Mattias> well, the actual game isn't on the ssd :P just the operating system [22:00] <fazias> lets just say I had problems with keeping high enough fps with i7-3770k@4,5ghz nvidia gtx480 and I was playing Heroes of newerth which does run on a very shitty computer [22:01] <fazias> input res 2560x1600 does also have alot to do with that, yeah [22:01] <Mattias> I have a gtx 670, with a very recent i5 cpu at 4ghz~ [22:01] <Mattias> 1920x1200 inres, and outres [22:01] Action: Mattias has downgraded from an old first gen i7 :P [22:02] <fazias> graphically heavy game + x11grab = problems, was my experience [22:02] <Mattias> http://www.twitch.tv/mattiasjp <-- here is the stream, right now the maxrate is at 1mbit [22:02] <Mattias> game limits to 20fps when I'm not focusing it [22:03] <Mattias> wops, tabbed wrong :D [22:03] <Mattias> anyways, 100% cpu :/ [22:03] <Mattias> seems to run smoothly today. testing ultrafast now [22:03] <Mattias> ultrafast + 10mbit maxrate limit now [22:05] <Mattias> ok, now it's "lagging" on the stream, and 1 cpu is at 100% and the rest avg on 50% [22:05] <Mattias> seems all on 50% ~ now [22:06] <Mattias> testing 1mbit up again [22:07] <Mattias> ugh, that looks terrible :P [22:09] <Mattias> cbsrobot: ultrafast makes a lot of boxy artifacts [22:09] <Mattias> trying at 3mbit now, still boxes, and 10mbit seems is too much for the PC, even though I have the bandwidth for it :/ [22:10] <Mattias> trying fast at 3mbit again [22:12] <Mattias> still lags, hm, boxes without lag, or nice stream with lag :P tough choice [22:21] <cbsrobot> Mattias: Did you read: http://trac.ffmpeg.org/wiki/StreamingGuide ? [22:22] <Mattias> cbsrobot: yes, a long time ago when creating this script [22:23] <klaxa> you can do ultrafast with a lower crf [22:23] <klaxa> oh wait... [22:23] <klaxa> nvm [22:23] <klaxa> different quality... thing [22:25] <Mattias> testing the other settings from that page again [22:25] <Mattias> maybe they work better for my new connection [22:25] <asherawelan> I am using ffmpeg to push an mp3 stream to a web sockets server, and I'm told i need to increase the chunk size - i've looked at the -chunk_size flag, but not sure what value to give it. It seems the decoder on the server I'm streaming to needs more information to decode? Any advise? [22:26] <asherawelan> Current command: ffmpeg -re -i talking_heads.avi -chunk_size 64k -f mp3 http://127.0.0.1:8081; [22:26] <Mattias> cbsrobot: actually, my "script" is added on that page, since I've added it, the third example [22:26] <Mattias> very long time ago [22:27] <cbsrobot> maybe you find some info that could help you [22:27] <cbsrobot> f.ex. -tune zerolatency [22:27] <cbsrobot> or stuff like that [22:31] <Mattias> everything I change keeps making it worse now :P [22:31] <Mattias> VBV underflow [22:32] <Mattias> llogan: already have, scroll up [22:33] <llogan> i arrived after you pasted it [22:33] <Mattias> the underflow was because I accidently did (1mbit)*0.2 [22:33] <Mattias> now it's 10mbit * 0.2 [22:34] <Mattias> http://pastebin.com/fGX2wzMX llogan basically trying to optimize this for streaming. to get 1920x1200 outres to stream flawlessly (I have 100mbit up and down, shouldn't be any problem) [22:42] <Mattias> Stream Configuration Quality: Acceptable [22:42] <Mattias> Last Checked: less than a minute ago [22:42] <Mattias> er, wrong copy :( [22:42] <Mattias> Max keyframe interval is currently at 6.224 seconds. Please set it to 2 seconds. <-- what influences this in my command above? [22:42] <Mattias> twitch.tv complains about this [22:46] <Mattias> and it also wants a constant cbr now O.o [22:48] <Mattias> great, got it to excellent. no warnings from twitch. I set it to 2 seconds with the -g switch [22:54] <sacarasc> -g I think, Mattias, but I'm not sure. [22:58] <Mattias> sacarasc: yeah, it was -g :) now to get rid of the "lag", no idea what causes it [22:58] <Mattias> frame=12670 fps= 30 q=31.0 size= 524214kB time=00:07:02.96 bitrate=10152.9kbits/s is the output I get [22:59] <Mattias> I set it to min/max at 10mbit [22:59] <Mattias> is the bitrate too high for my cpu to handle? [23:00] <Mattias> testing at 5mbit now [23:16] <Mattias> works much better at lower outres, no idea what's causing the bad framerate at higher outres [23:31] <Mattias> seems I can't have higher outres than 854x480, otherwise it lags.. [23:39] <Mattias> found https://github.com/wargio/Twitch-Streamer-Linux going to try it now :P [23:44] <llogan> looks like that script uses -b twice and -qscale [23:45] <llogan> Mattias: i never did see a console output from you. are you even using ffmpeg? [23:46] <Mattias> llogan: yeah, ffmpeg with libx264 the full command is in that paste I did. It sends the encoded video directly to twitch.tv [00:00] --- Mon Oct 28 2013

1 0

ffmpeg-devel.log.20131026
by burek 27 Oct '13

27 Oct '13

[01:30] <cone-822> ffmpeg.git 03Michael Niedermayer 07release/0.10:558c1f35fa09: avcodec/h264: reduce noisiness of "mmco: unref short failure" [01:30] <cone-822> ffmpeg.git 03Michael Niedermayer 07release/0.11:d49761b39643: avcodec/h264: reduce noisiness of "mmco: unref short failure" [01:30] <cone-822> ffmpeg.git 03Michael Niedermayer 07release/0.9:ff3e385d849e: avcodec/h264: reduce noisiness of "mmco: unref short failure" [01:30] <cone-822> ffmpeg.git 03Michael Niedermayer 07release/1.0:946815aa0974: avcodec/h264: reduce noisiness of "mmco: unref short failure" [01:30] <cone-822> ffmpeg.git 03Michael Niedermayer 07release/1.1:a4b705b4cbb5: avcodec/h264: do not trust last_pic_droppable when marking pictures as done [01:30] <cone-822> ffmpeg.git 03Michael Niedermayer 07release/1.1:8e72a8d1c278: avformat/mp3dec: perform seek resync in the correct direction [01:30] <cone-822> ffmpeg.git 03Michael Niedermayer 07release/1.1:5bce35d9581c: avcodec/h264: reduce noisiness of "mmco: unref short failure" [01:30] <cone-822> ffmpeg.git 03Michael Niedermayer 07release/1.2:a8b6721bedce: avcodec/h264: do not trust last_pic_droppable when marking pictures as done [01:30] <cone-822> ffmpeg.git 03Michael Niedermayer 07release/1.2:833dce3818e3: avformat/mp3dec: perform seek resync in the correct direction [01:30] <cone-822> ffmpeg.git 03Michael Niedermayer 07release/1.2:9195ef6f65cb: avcodec/h264: reduce noisiness of "mmco: unref short failure" [01:30] <cone-822> ffmpeg.git 03Stefano Sabatini 07release/2.0:17d169ce0f07: doc/Makefile: fix man pages uninstall path [01:30] <cone-822> ffmpeg.git 03Michael Niedermayer 07release/2.0:cd7d575e90ce: avcodec/h264: do not trust last_pic_droppable when marking pictures as done [01:30] <cone-822> ffmpeg.git 03Michael Niedermayer 07release/2.0:b7154758de3f: avformat/wavdec: Fix smv packet interleaving [01:30] <cone-822> ffmpeg.git 03Michael Niedermayer 07release/2.0:94c7ee4d9e03: avformat/mp3dec: perform seek resync in the correct direction [01:30] <cone-822> ffmpeg.git 03Michael Niedermayer 07release/2.0:782331be1eb2: avcodec/h264: reduce noisiness of "mmco: unref short failure" [01:58] <cone-822> ffmpeg.git 03Michael Niedermayer 07master:3c9dd93faa9f: h264: make flush_change() set mmco_reset [02:30] <cone-822> ffmpeg.git 03Michael Niedermayer 07master:780669ef7c23: avcodec/jpeg2000dec: non zero image offsets are not supported [02:46] <cone-822> ffmpeg.git 03Kieran Kunhya 07master:4d6ee0725553: libavutil: x86: Add AVX2 capable CPU detection. [02:46] <cone-822> ffmpeg.git 03Kieran Kunhya 07master:865b70bc5d1c: Add AVX2 capable CPU detection. Patch based on x264's AVX2 detection [02:46] <cone-822> ffmpeg.git 03Michael Niedermayer 07master:a66570440215: Merge commit '4d6ee0725553a43ba88d6f8327ebcf8f1c5ae8d4' [02:46] <cone-822> ffmpeg.git 03Michael Niedermayer 07release/1.1:69603724750b: h264: make flush_change() set mmco_reset [02:46] <cone-822> ffmpeg.git 03Michael Niedermayer 07release/1.2:720e2d4143b5: h264: make flush_change() set mmco_reset [02:47] <cone-822> ffmpeg.git 03Michael Niedermayer 07release/2.0:1d0e58372885: h264: make flush_change() set mmco_reset [03:01] <BBB> ubitux: DEFINE_ARGS is just to define the GPRs (i.e. things like dst, stride) [03:01] <BBB> ubitux: r0, r1 etc.is the "common" names therefore, and we can alternatively name them using DEFINE_ARGS first, second [03:01] <BBB> first will refere to r0, second to r1, etc [03:01] <BBB> e.g. DEFINE_ARGS dst, stride makes dst r0, stride r1, etc. [03:02] <BBB> ubitux: so you can refer to them by name instead of register, similar to how you do it in C [03:02] <BBB> ubitux: STORE_DIFFx2 is to unpack a series of bytes, unpack to words, add the diff, pack, store [03:03] <BBB> ubitux: VP9_MULTIPLY_SUMSUB looks good, I have a slightly alternative version that does approximately the same thing, I can share that later (it's a litle more interleaved, but essentially identical in function) [03:04] <cone-822> ffmpeg.git 03Alex Converse 07master:adea4512c608: aacdec: Fix calls to avpriv_report_missing_feature(). [03:04] <cone-822> ffmpeg.git 03Alex Converse 07master:4e326ec76991: fate: aac: Add test for AAC-ELD [03:04] <cone-822> ffmpeg.git 03Michael Niedermayer 07master:8c508a035428: Merge commit 'adea4512c6087280702e2423de55cea050e20a98' [03:04] <cone-822> ffmpeg.git 03Michael Niedermayer 07master:7e19c549bafa: Merge remote-tracking branch 'qatar/master' [03:10] <BBB> ubitux: looks mostly good, but you don't need the second transpose (that's a fix from vp8 to vp9; see rants from jason about that in vp8) [03:11] <BBB> ubitux: also store_diff, you should be able to use m0, m1, m2 and m3 instead of your current more random ordering (tranpose does the swap for you) [09:37] <ubitux> BBB: oh ok, i was doing the second transpose because i wasn't understanding the way the store was working [09:37] <ubitux> and yeah store diff args are broken for now, it was purely random [09:38] <ubitux> BBB: i understood DEFINE_ARGS as a "redefine function's argument names" [09:39] <ubitux> about interleaving the content of the MULTIPLY_SUMSUB, i assume it's because it's faster? [09:39] <ubitux> well, i should be done by today hopefully [10:39] <cone-25> ffmpeg.git 03Lukasz Marek 07master:c6c70c2bf76c: lavd/pulse_audio_enc: add another default to stream name [10:39] <cone-25> ffmpeg.git 03Lukasz Marek 07master:c4281705492a: lavd/pulse_audio_enc: avoid vars in for() [10:39] <cone-25> ffmpeg.git 03Michael Niedermayer 07master:0feecb62abab: Merge remote-tracking branch 'lukaszmluki/master' [12:27] <cone-25> ffmpeg.git 03Michael Niedermayer 07master:6889b78fe038: doc/issue_tracker: add 2 missing issue types [12:27] <cone-25> ffmpeg.git 03Michael Niedermayer 07master:fcd08b777059: avformat/md5enc: add format, version and column headers [12:32] <BBB> ubitux: well vp8 does the second transpose, but vp9 doesn't need it (it inverts the order of the 1d idcts, so it's transpose;1d;transpose;1d, like what h264 and any other video codec in the world does, instead of vp8's 1d; transpose; 1d; transpose) - but the transpose before the first 1d is integrated with the coeff reader so simd doesn't have to do it (i.e. it's free) [14:02] <cone-25> ffmpeg.git 03Marton Balint 07master:060c42bc3dff: ffplay: update and extend documentation for channel and stream switching [14:02] <cone-25> ffmpeg.git 03Marton Balint 07master:2d059d8de1b4: ffplay: factor out picture freeing code [14:02] <cone-25> ffmpeg.git 03Marton Balint 07master:04de0e04c5d0: ffplay: use av_frame_get_pkt_pos instead directly accessing pkt pos [14:02] <cone-25> ffmpeg.git 03Marton Balint 07master:44758b4d17f6: ffplay: add support for libswresample options [14:02] <cone-25> ffmpeg.git 03Michael Niedermayer 07master:444ce03f0f15: Merge remote-tracking branch 'cus/stable' [14:17] <ubitux> BBB: ok [14:17] <ubitux> BBB: infinitely faster like SWAP then @_@ [14:20] <BBB> indeed ;) [14:24] <BBB> I'm really wasting too much time on irrelevant stuff sometimes... [14:24] <BBB> anyway [14:24] <BBB> (see email to list) [14:25] <ubitux> :) [14:26] <cone-25> ffmpeg.git 03Lukasz Marek 07master:99a4c86a32dc: configure: link with built libs when pc-uninstalled is used [15:16] <cone-25> ffmpeg.git 03Michael Niedermayer 07master:41efb8d9a75f: avcodec/x86/cabac: include get_cabac_bypass_sign_x86() under #if !BROKEN_COMPILER [15:16] <ubitux> ah shit i've constructed them in reverse.. [15:55] <ubitux> BBB: it seems i need to reverse all the word post idct before the add [15:55] <ubitux> any idea how i could avoid this? [15:55] <BBB> ? [15:55] <BBB> no you don't [15:55] <BBB> you mean you're looking at them in a debugger and they seem inversed? [15:55] <ubitux> yes [15:55] <BBB> that's just your debugger [15:56] <BBB> :-p [15:56] <ubitux> well, they're inverted in comparison to the content i'm adding to [15:56] <ubitux> reg + reg [15:56] <BBB> show me the code? [15:56] <ubitux> one is in the wrong order [15:56] <BBB> and the gdb output [15:57] <cone-25> ffmpeg.git 03Michael Niedermayer 07master:e0b2bdd37a01: avcodec/h264_parser: heuristically detect non marked keyframes [15:57] <ubitux> code is mostly unchanged from yesterday; [15:57] <ubitux> then in the store it reaches: [15:57] <ubitux> => 0xb03d91 <ff_gdb_break+21>: paddw mm6,mm3 [15:57] <ubitux> 69: $st3 = -nan(0xfffeffff00000000) [15:57] <ubitux> 66: $st6 = -nan(0x7e007e007f0080) [15:57] <ubitux> and it should be the other way around for one of the 2 reg [15:58] <ubitux> st6 is the current destination, 16bit padded with 0 [15:58] <ubitux> st3 is the result of the second idct [15:59] <ubitux> just updated my branch [15:59] <BBB> you didn't remove the second transpose [16:00] <BBB> ah now it's gone [16:00] <ubitux> BBB: i did, just updated :p [16:01] <BBB> so what is st3 and st6? [16:01] <BBB> and why are the coeffs inverted between the 2d idcts? [16:02] <BBB> that doesn't seem right [16:02] <ubitux> so st3 is the line 0 out of the 2nd idct [16:02] <ubitux> and st6 is the first line of the dest buffer, 16b padded [16:02] <BBB> you haven't loaded the dst buffer yet [16:02] <BBB> that happens in STORE_DIFFx2 [16:03] <ubitux> yes i'm talking about the exec in STORE_DIFFx2 [16:03] <BBB> ah ok [16:03] <ubitux> which i'm tracing [16:03] <BBB> can you show the disassembly for the whole function? [16:03] <ubitux> sure [16:04] <BBB> I still think you inverted the coeffs between the 2 1d idcts [16:04] <BBB> t2/t3 [16:04] <BBB> that might well explain this, since they are merely different in sign [16:05] <ubitux> BBB: http://pastie.org/8432471 [16:05] <ubitux> BBB: i needed to do that to get correct result, will recheck [16:08] <ubitux> yeah, it doesn't do the correct mult if i don't toggle them [16:09] <BBB> how do you know it's incorrect? [16:09] <BBB> look, I know for sure that the order should be identical between the two 1ds :) [16:09] <BBB> I don't know which one is wrong, but I'll check ;) [16:10] <ubitux> i'm comparing the outputs after each idct [16:10] <ubitux> i have a C trace in parallel [16:10] <BBB> ok... I'll check also [16:10] <BBB> not sure [16:10] <BBB> weird [16:12] <ubitux> i checked the resulting registers after the 2 idct, they're correct, just reverted [19:11] <ubitux> BBB: mmh i think i didn't notice it because my test case had 2 lines full of zero [19:11] <BBB> ? [19:11] <BBB> notice what? [19:11] <ubitux> the bug i have [19:12] <BBB> oh so it's fixed? [19:12] <ubitux> didn't notice earlier in the writing of the function [19:12] <ubitux> not yet but i'm tracing it [19:12] <ubitux> the input block of my test case has 2 lines of zero and the code worked with that input [19:12] <ubitux> but trying with another input, i get differences [19:12] <BBB> ok [19:12] <ubitux> i think i know what i messed up [19:13] <BBB> :) [19:19] <kurosu_> some times, it's nice to extract the idct code into a stand-alone, and feed it purely vertical coeffs, then purely vertical ones. [19:20] <ubitux> last i did such thing, i messed up my prng [19:20] <ubitux> i had some non visible cycles [19:20] <ubitux> and all kind of weird regular zeros in the output [19:20] <ubitux> i thought it was buggy, while it was in fact perfectly correct :)) [19:28] <cone-25> ffmpeg.git 03Michael Niedermayer 07master:d2db1bb7dea1: avformat/http: dont fail with unknown Content-Encodings [19:43] <BBB> there's this code in x86util.asm which I don't understand [19:43] <BBB> %elif cpuflag(3dnow) [19:43] <BBB> movq %1, %2 [19:43] <BBB> psrlq %1, 32 [19:43] <BBB> punpckldq %1, %2 [19:43] <BBB> %endif [19:44] <BBB> what is 3dnow about that, and why is there no else clause? [19:45] <BBB> and there's all these macros that are only used in 1 place [19:45] <BBB> this is so sadly unmaintained... :/ [19:59] <ubitux> default output for display $st[0-9] in gdb sucks so much it's insane [20:00] <ubitux> why the default are so much broken in that debugger... [20:00] <ubitux> no wonder after years of coding i still prefer printf over gdb for any C debugging [20:14] <mathstuf_> ubitux: lldb is supposed to be better [20:35] <ubitux> i'll consider then [20:35] <ubitux> anyway, found my bug [21:16] <durandal_1707> nice, more breakings from dark side [21:40] <ubitux> yay it works [21:41] <BBB> ubitux: cool [21:41] <BBB> ubitux: don't forget to write a dc-only (and possibly a 2x2) version [21:41] <BBB> these are simpler but will provide further speedups [21:42] <BBB> i.e. eob == 1 and eob <= 3 [21:42] <ubitux> let me first clap my hands in joy [21:42] <ubitux> BBB: can you detail those cases? [21:43] <BBB> if eob == 1, only block[0] is filled in [21:44] <durandal11707> new release, when? [21:44] <BBB> this is a special case, because all residual values will have the same value [21:44] <BBB> so you only need 2 multiplications [21:44] <BBB> basically out[n] (for any n) = pmulhrsw(pmulhrsw(block[0], 11585x2), 11585x2) [21:46] <BBB> ubitux: and once you know out[n], just pshufw that over the register, and add it to each dst[0-3]+stride[0-3] [21:46] <BBB> ubitux: that's all [21:46] <BBB> ubitux: (i.e. much less instructions, and thus faster) [21:47] <BBB> ubitux: the 2x2 is eob <= 3 and is halfway in between, block[0, 1 and 4] are != 0, so you do a 1d idct only for the top half of the block [21:48] <BBB> ubitux: n. of instructions is halfway between dc-only and the full (which you just wrote) [21:49] <ubitux> ok, i'll consider this [21:50] <ubitux> BBB: do you have a trick for the final rounding? [21:50] <michaelni> durandal11707, soon [21:50] <ubitux> BBB: since i'm adding 8 to the 4 reg [21:50] <ubitux> i'm guessing this could be put somewhere else transparently [21:53] <BBB> ubitux: pmulhrsw :) [21:53] <BBB> ubitux: and just don't use STORE_DIFFx2, just write your own, that's fine [21:54] <ubitux> why i shouldn't use it? [21:55] <BBB> ubitux: pmulhrsw(x, 2048) is the same as +8>>4 [21:55] <BBB> so just use that [21:55] <ubitux> ah [21:55] <ubitux> mmh [21:55] <BBB> so it's one instruction instead of two [21:55] <BBB> and you're already ssse3 so that's not an issue [21:55] <ubitux> ok [21:56] <ubitux> BBB: while i'm at it, any idea why there was a DEFINE_ARGS and lea instead of just calling STORE_DIFFx2, lea, STORE_DIFFx2? [21:56] <ubitux> (in vp8, i copied that part) [21:57] <BBB> just so the reg has a name [21:57] <BBB> but really there's no reason [21:57] <BBB> so don't feel obliged to use it [21:57] <ubitux> ah, okay [21:57] <BBB> vp8 isn't perfect [21:57] <BBB> it was pretty good, but it was also the first asm I ever wrote [21:57] <BBB> so it's certainly got some beginner's issues [21:58] <ubitux> ok :) [21:59] <cone-25> ffmpeg.git 03Vittorio Giovara 07master:b284e1ffe343: mem: do not check for negative size [21:59] <cone-25> ffmpeg.git 03Michael Niedermayer 07master:3fcc2684e49b: Merge commit 'b284e1ffe343d6697fb950d1ee517bafda8a9844' [22:04] <cone-25> ffmpeg.git 03Anton Khirnov 07master:834259528b6c: fft-test: add a missing #include [22:04] <cone-25> ffmpeg.git 03Michael Niedermayer 07master:c78a41698558: Merge remote-tracking branch 'qatar/master' [22:08] <ubitux> BBB: is the eob relevant only for 4x4? [22:11] <iive> eob as end of block, indicating the last non-zero coefficient? [22:18] <llogan> burek: gusari seems to be having issues [22:19] <llogan> BBB: did you post anything about katmai? i haven't seen it bu tit might be laziness on my part [22:19] <llogan> *but it [22:19] <llogan> see [22:22] <llogan> burek: nevermind. now it's back. sorry for the noise. [22:23] <burek> llogan, thanks [22:23] <burek> i just investigated and killed a spammer :/ [22:23] <burek> they never sleep :S [22:24] <llogan> i probably have 5 spammer pelts from the forum [22:24] <llogan> but nobody buys these [22:24] <burek> thats a hosting machines with a lot of websites on it [22:25] <burek> and a lot of newbee webadmins.. [22:25] <burek> you just reported that at the perfect time [22:25] <burek> for me to catch the spammer in the action :) [22:25] <burek> thanks again :beer: :) [22:25] <llogan> beer... i had too much last night and it's early here... [22:27] <burek> :) [22:31] <michaelni> ubitux, did you had any reason why you didnt apply "Clément BSsch (4.9K) [FFmpeg-devel] [PATCH] build: make sure probed tools don't wait for stdin input." ? [22:32] <ubitux> i remember there was a comment, and so i didn't bother look again at the issue [22:32] <ubitux> it looked relevant at first, but i didn't allocated time for it so far, sorry [22:33] <ubitux> feel free to push if you think it's ok [22:34] <michaelni> i thought but it doesnt work anymore :( [22:35] <ubitux> ah? well i guess i need to look again [22:36] <ubitux> but not now, as you can see i'm having a lot of fun with asm recently :] [22:37] <michaelni> sure, no hurry [22:43] <BBB> ubitux: no, all of them [22:43] <BBB> ubitux: also, eob > 0 (by definition) [22:43] <BBB> ubitux: so the !!eob is sort of silly (it's always 1) [22:44] <ubitux> you were talking about eob < 3 [22:44] <BBB> ubitux: <= [22:45] <ubitux> and so !!eob was required [22:45] <BBB> ? [22:45] <BBB> why don't you assert(!!eob == 1) in there [22:46] <BBB> or assert(!!eob); [22:46] <BBB> (just for fun) [22:46] <ubitux> im not following you, we might not be talking about the same thing [22:46] <BBB> I guess... what did you mean? [22:46] <ubitux> i was refering to the memset(block, 0, size * (!!eob)) i did in another commit [22:47] <BBB> right, that's not necessary [22:47] <BBB> !!eob is always 1 [22:47] <ubitux> !!eob, but not eob [22:47] <BBB> right [22:47] <ubitux> so you can't size * eob [22:47] <BBB> right [22:47] <ubitux> but maybe that's not what you suggest? [22:47] <ubitux> :D [22:48] <BBB> no not really [22:48] <BBB> just replace that with the original code [22:48] <BBB> what I suggest is this: [22:48] <BBB> if (eob == 1) { special code } else if (eob <= 3) { special code } else { your current assembly code } [22:49] <BBB> this if can be done in the c code in x86/vp9dsp_init.c [22:49] <BBB> special code for eob == 1 does this: mm0 = pshufw(pmulhrsw(pmulhrsw(block[0], 11585x2), 11585x2), q0000) [22:49] <ubitux> ah, sure [22:49] <BBB> then do STORE_DIFFx2 with that mm0 [22:49] <ubitux> okay :) [22:49] <BBB> for eob <= 3, it's a little harder [22:50] <BBB> also, you only need 1 or 2 movd [mem], zeroreg instead of 4 [22:50] <ubitux> i'm rewriting the store thing currently, trying to put the pmulhrsw trick in [22:50] <BBB> cool [22:50] <ubitux> i'll look at the eob thing after [22:50] <BBB> ok cool [22:51] <BBB> it's not urgent, it's not a bug [22:51] <BBB> it's just another speedup possibility [22:54] <BBB> are your coefficients now correct? [22:54] <BBB> (i.e. same for both 1d dimensions) [22:56] <ubitux> BBB: yes everything is correct [22:56] <ubitux> it passes fate etc [22:56] <ubitux> and yes i could put them in the correct order now ;) [22:56] <ubitux> my branch is up-to-date if you want to hf with it :p [23:00] <BBB> so ... if the arguments to a macro are always the same [23:00] <BBB> feel free to remove the arguments [23:01] <BBB> (e.g. in my 32x32, I just have a macro called IDCT32_1D) [23:01] <BBB> (with no arguments) [23:01] <BBB> oh actually, that's a lie, I have one argument, but you don't need that [23:01] <ubitux> i thought we could do some factoring :( [23:01] <BBB> up to you [23:02] <BBB> if you think it can be improved, then that's totally fine [23:02] <BBB> if you don't thik this will change, it may be cleaner to remove [23:02] <BBB> up to you [23:02] <ubitux> i need to know how the other function will look like [23:03] <BBB> which one? [23:05] <ubitux> any other simd idct [23:05] <BBB> well you asked me to not put my code up so I didn't ;) [23:06] <ubitux> haha yeah [23:06] <ubitux> let me get done with that first one first :) [23:06] <BBB> right [23:27] <ubitux> BBB: did you finish it btw? [23:30] <BBB> no, I rarely have free time in an environment that allows concentration for this kind of stuff [23:30] <BBB> I continuously have screaming kids around me [23:30] <BBB> it's virtually impossible to get any coding done :/ [23:31] <ubitux> teach them simd [23:31] <ubitux> if i could somehow learn it, they certainly can as well [23:32] <BBB> they're kind of young maybe [23:32] <BBB> the youngest can't walk yet [23:32] <BBB> I don't think he's quite ready for simd [23:33] <ubitux> don't underestimate them [23:34] <ubitux> anyway, i like this a lot, but it's as time consuming as reversing code [23:34] <ubitux> i hope to get faster somehow :p [23:35] <BBB> you'll get faster [23:35] <ubitux> assuming i can hardly get slower, sure [23:35] <BBB> it's a skill, you're still learning :) [23:35] <BBB> don't feel bad [23:35] <BBB> you're doing fine [23:36] <BBB> try to work on avx-readiness [23:37] <BBB> that's one thing that's fun for future [23:37] <BBB> basically whenever you do mova mX, mY; think avx [23:37] <BBB> avx allows 3-register instructions [23:37] <BBB> like punpcklbw m0, m1, m2 [23:37] <BBB> think of that as mova m0, m1; punpcklbw m0, m2 [23:37] <BBB> so m0 is a dest only, and m1 and m2 are both unmodified sources [23:37] <BBB> in avx, that's a single instruction [23:37] <kierank> mova mX, [foo] as well [23:38] <BBB> right [23:39] <ubitux> ow [23:39] <BBB> examples: line 101, 108, 121 [23:39] <ubitux> yeah i don't like those [23:39] <BBB> lol :) [23:39] <BBB> anyway [23:39] <ubitux> especially L101 [23:39] <BBB> right [23:39] <BBB> so avx doesn't work with mmx, so it won't affect your code [23:40] <BBB> but it does work with xmm, so if you want to do the 8x8 after this, it's very relevant [23:40] <ubitux> unfortunately, i might have one of the rare i7 without avx [23:40] <ubitux> :D [23:40] <BBB> so do I [23:40] <BBB> kierank has a test machine [23:40] <BBB> obe2 or so [23:40] <ubitux> i have a remote one [23:40] <kierank> i need to get one with avx2 [23:40] <ubitux> i think it has avx [23:40] <BBB> ah cool [23:40] <BBB> the new macbook pro has avx2/haswell [23:41] <BBB> so I'm thinking of getting that one [23:41] <kierank> I have a machine but nowhere to colo it :( [23:41] <ubitux> yeah my remote one has avx [23:41] <ubitux> not avx2 though [23:45] <ubitux> BBB: btw, i'm really happy i could use SWAP : [23:51] <BBB> thank pengvado, I think he designed all the original stuff in x86inc.asm [00:00] --- Sun Oct 27 2013

1 0

ffmpeg.log.20131026
by burek 27 Oct '13

27 Oct '13

[14:21] <dive> Hi, I can't seem to get -threads to work (enable-pthreads is in configure): [14:21] <dive> ffmpeg -i "$INFILE" -threads 8 -b 1500k -vcodec libtheora -acodec libvorbis -ab \ [14:21] <dive> 160000 -g 30 "$OUTFILE" [14:22] <dive> but my cpu still shows only one core being used [14:41] <fazias> how about testing some other video codec to see if it has threads, quick google showed me that theora might not support more than one thread [14:41] <dive> ah [14:41] <dive> could be [14:41] <dive> I'll give it a shot after this one [14:43] <fahadash> Non-monotomous DTS in output stream 0:1; previous: 7, current: 6544; changing to 7617. This may result in incorrect timestamps in the output file. [14:43] <fahadash> What does it mean ? [14:43] <fahadash> I am trying to convert a wmv into mov using ffmpeg -i file.wmv file.mov [14:46] <dive> fazias, you are correct - converting to mpeg uses more than a single core [16:31] <zybil> hi [21:14] <EvanDotPro> so, i have what is presumably a corrupt mp4 file (well, several) that has been "undeleted" by testdisk after an accidental delete... however i can't get anything to decode it, and i'm not sure if it's a complete loss or if there should be a simple way to "repair" these files. [21:14] <EvanDotPro> here is what ffprobe is giving http://evan.pro/caps/84286a.png [00:00] --- Sun Oct 27 2013

1 0