Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2015

1 participants
62 discussions

ffmpeg-devel.log.20151005
by burek 06 Oct '15

06 Oct '15

[00:02:09 CEST] <BBB> durandal_1707: it makes sense to do whatever you like doing [00:02:30 CEST] <BBB> durandal_1707: if you dont care for what you write, then youre gonna give up pretty soon - look at all unoptimized code paths in swscale [00:03:00 CEST] <BBB> (in the end, everyone uses opengl shaders to view video, and only some big datacenter bigcorps care about sw conversion, and they really only care about yuv420p10le to yuv420p) [00:03:09 CEST] <BBB> hence swscale most paths are unoptimized [00:03:42 CEST] <iive> I thought swscale uses runtime code generation [00:03:57 CEST] <nevcairiel> only in the fastmmx path [00:05:47 CEST] <BBB> and only for the fast_bilinear scaling type (which is not default) [00:05:50 CEST] <BBB> and only for horizontal scaling [00:07:56 CEST] <kierank> yuv420p10le to yuv420p --> they do? [00:08:01 CEST] <kierank> iirc that conversion is in c [00:08:06 CEST] <kierank> or it might be vice versa [00:08:36 CEST] <kierank> in some future universe we can get rid of fast_bilinear and other junk from the early 2000s [00:08:40 CEST] <JEEB> durandal_1707: have you made any tests with the latter revisions of zscale btw? [00:08:51 CEST] <JEEB> s/zscale/zimg/ [00:09:10 CEST] <nevcairiel> a fresh universal scaling lib would be nice, but most things that coem to be hardly support enough formats to be able to replace swscale [00:09:32 CEST] <JEEB> yeah [00:09:40 CEST] <durandal_1707> guy is removing/readding code [00:09:58 CEST] <JEEB> yeah, he seems pretty active [00:11:03 CEST] <kierank> JEEB: https://github.com/buaazp/zimg? [00:11:38 CEST] <wm4> removing useless features? what heresy [00:11:42 CEST] <wm4> wrong url [00:12:04 CEST] <wm4> https://github.com/sekrit-twc/zimg/ [00:15:04 CEST] <kierank> interesting [00:17:37 CEST] <JEEB> yeah. funny enough I kind of dislike the guy due to him being an obnoxious troll for most of the internet history I've known him, but this stuff is actually being useful. [00:18:04 CEST] <BBB> nevcairiel: https://xkcd.com/927/ [00:20:24 CEST] <jamrial> ^FLIF [00:21:05 CEST] <nevcairiel> if their claims for FLIF hold true, it might actually not be that bad [00:21:54 CEST] <nevcairiel> current implementation not withstanding [00:24:41 CEST] <atomnuker> at least it's currently doing the right thing instead what every other new image format does [00:25:27 CEST] <atomnuker> "encode an image as <insert video codec> keyframe and you have a new format" [00:26:54 CEST] <wm4> atomnuker: don't forget the part where you slightly modify the original codec, so you can't share any code [00:27:15 CEST] <wm4> ...and then add animations on top of the new image format [00:28:25 CEST] <BBB> and alpha [00:28:26 CEST] <BBB> and rgb [00:28:31 CEST] <BBB> in a completely incompatible and incoherent way [00:29:07 CEST] <atomnuker> that reminds me of APNG and MNG [00:35:50 CEST] <nevcairiel> BBB: and preferably in 3 different ways [00:42:48 CEST] <cone-754> ffmpeg 03Marton Balint 07master:80b6cc4214a8: concatdec: fix metadata memleak on error [00:42:49 CEST] <cone-754> ffmpeg 03Ganesh Ajjanagadde 07master:7c6dd90eed48: ffplay: more robust mutex creation [01:00:29 CEST] <cone-754> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:1175bbd14fe3: ffserver: fix line wrapping on function decls [01:00:30 CEST] <cone-754> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:3388bcced450: ffserver: unify exit path in _write_index() [01:00:31 CEST] <cone-754> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:8a9089948f02: ffserver: wrap around too-busy message text [01:00:32 CEST] <cone-754> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:d8c714cb241b: ffserver: wrap around bandwidth exceeded msg text [01:00:33 CEST] <cone-754> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:84b4998dbdbd: ffserver: fix up rate units in server messages [01:02:09 CEST] <BBB> nevcairiel: and a fourth, which is only function on april 1st! [01:03:16 CEST] <JEEB> :D [02:06:28 CEST] <J_Darnley> I've been tinkering around with assembly from that stereo filter patch for so long I've forgotten what I set out to test. [06:54:22 CEST] <kurosu> durandal_1707, so you can follow BBB's advices, even for the coeff storing [06:54:29 CEST] <kurosu> ah [06:55:00 CEST] <kurosu> durandal_1707, so you can follow BBB's advices, even for the coeff storing [06:55:40 CEST] <kurosu> I don't know how often the call is made (once per frame? line?) [06:56:02 CEST] <kurosu> so maybe reloading them everytime isn't a big penalty [06:57:00 CEST] <kurosu> but what you store on the stack, could be an array in the asm file (like the ex_*) [06:57:27 CEST] <durandal_1707> func is called once per slice [06:58:13 CEST] <kurosu> which approximately image height / threads I guess [06:58:19 CEST] <kurosu> is [06:58:29 CEST] <kurosu> probably fine [06:59:21 CEST] <kurosu> my solution was 96B * number of anaglyphs (didn't count, looks close to 20) [06:59:30 CEST] <kurosu> not huge, but still [07:01:07 CEST] <kurosu> on the other hand, your coeffs are 17 bits (16 magnitude and sign) [07:01:29 CEST] <kurosu> do they have to be like that? or could they be 16bits? [07:02:06 CEST] <kurosu> because really, pmulld instead of pmaddwd sounds like a waste [07:41:30 CEST] <cone-444> ffmpeg 03Reynaldo H. Verdejo Pinochet 07master:fe95b0eb8fdf: ffserver: avoid leaking pathname at exit [10:44:47 CEST] <durandal_170> can I use avx2? [10:58:05 CEST] <rcombs> is someone stopping you? [11:08:48 CEST] <cone-617> ffmpeg 03Henrik Gramner 07master:8bb376cf6b4a: checkasm: Fix the function name sorting algorithm [11:08:48 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:f83ead7691ad: Merge commit '8bb376cf6b4ab8645daedb8becaa7163656436a4' [11:16:50 CEST] <cone-617> ffmpeg 03John Stebbins 07master:f56a08559334: matroskaenc: Don't write a track language tag [11:16:51 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:4064d688e7f2: Merge commit 'f56a08559334b7eb6b3fedbc0cc741887f6067ae' [11:17:32 CEST] <cone-617> ffmpeg 03Henrik Gramner 07master:2c3dbff1d89b: avutil/avstring: Inline some tiny functions [11:17:33 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:a7322bd97f2e: Merge commit '2c3dbff1d89bbf8300c121c06524c014cb6e0915' [11:19:21 CEST] <cone-617> ffmpeg 03Anton Khirnov 07master:f3202871598f: d3d11va: check for malloc failure [11:19:22 CEST] <cone-617> ffmpeg 03Anton Khirnov 07master:bb198c4997d5: d3d11va: make av_d3d11va_alloc_context() available at all times [11:19:23 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:ac830e9b489b: Merge commit 'f3202871598f59b570b31b01cfeb64b8fedbd700' [11:19:24 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:0cd8170dd2b5: Merge commit 'bb198c4997d5036f3bf91de51e44f807115677d0' [11:19:59 CEST] <cone-617> ffmpeg 03Vittorio Giovara 07master:4c160fa23996: dcadec: Always initialize return variable [11:20:00 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:fecf775624c0: Merge commit '4c160fa23996c05efcd952ccfac2359311d8a1bc' [11:23:53 CEST] <cone-617> ffmpeg 03Vittorio Giovara 07master:cab63a8b594c: dv: Mark internal frame reference as const [11:23:54 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:d0186a4ec4c4: Merge commit 'cab63a8b594cdc365bb2581a12b3ac8e6dd480b2' [11:26:07 CEST] <kierank> JEEB: professional edition? [11:26:10 CEST] <kierank> of that zimg [11:26:21 CEST] <cone-617> ffmpeg 03Vittorio Giovara 07master:1da2a20763ae: dvbsubdec: Fix function return type [11:26:22 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:fbd71bba8583: Merge commit '1da2a20763ae9ca579d5fd20763065871ddf6311' [11:27:27 CEST] <cone-617> ffmpeg 03Vittorio Giovara 07master:4628443ca353: h263: Drop uninitialized variable use from log message [11:27:28 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:78d9658a4d04: Merge commit '4628443ca3534060888dd0015b229337eac13fd2' [11:28:40 CEST] <cone-617> ffmpeg 03Vittorio Giovara 07master:10aa6f9db44e: h264: Use the correct argument context in debug log [11:28:41 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:f85e460078d8: Merge commit '10aa6f9db44e96977e7155fdc3e62619e0e00a15' [11:29:28 CEST] <cone-617> ffmpeg 03Vittorio Giovara 07master:b8b13acd70a1: hevc: Simplify logical check [11:29:29 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:c9b35246191f: Merge commit 'b8b13acd70a1c1b6c044f967d78cb82f1a53887b' [11:33:08 CEST] <cone-617> ffmpeg 03Vittorio Giovara 07master:abe9adfb3156: rangecoder: Use AV_RB16 instead of bytestream_get_be16 [11:33:09 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:cae02106b706: Merge commit 'abe9adfb31566c415fd830a8d4977c79512d4385' [11:33:55 CEST] <cone-617> ffmpeg 03Derek Buitenhuis 07master:eae58428bd19: avcodec: Do not lock during open for codecs marked as having threadsafe init [11:33:56 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:45ab078e35a4: Merge commit 'eae58428bd199f7d4670bf471f56ed204430878e' [11:34:21 CEST] <cone-617> ffmpeg 03wm4 07master:65db4899fa87: mmaldec: refactor to have more context per MMAL input buffer [11:34:22 CEST] <cone-617> ffmpeg 03wm4 07master:39f01e346cab: mmaldec: be more tolerant against MMAL not returning decoded output [11:34:23 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:827d4b794282: Merge commit '65db4899fa8790049bec3af16ecdb75dd81051fd' [11:34:24 CEST] <cone-617> ffmpeg 03Hendrik Leppkes 07master:329a0e419e6e: Merge commit '39f01e346cab464ef6c0d4ec58cc13b7123e60d8' [11:53:48 CEST] <TimNich> Daemon404: Looks like your libav thread lock commit got merged& [11:54:14 CEST] <JEEB> kierank: I don't know if there's one, but that could explain his activity around it [11:54:53 CEST] <wm4> TimNich: he also posted a ffmeg patch for this, which was applied before [11:55:42 CEST] <nevcairiel> ever commit gets merged, the real question is if its contents get applied [11:55:44 CEST] <ubitux> durandal_170: do you test your simd with odd width and unaligned frames? (like padded by one pixel on the left) [11:55:46 CEST] <nevcairiel> every* [11:55:52 CEST] <TimNich> wm4: and said the libav shouldnt be merged& [11:56:07 CEST] <nevcairiel> please dont assume that I dont know what I'm doing =p [11:56:48 CEST] <wm4> nevcairiel: what do you think about switching to cherry-picking? [11:56:55 CEST] <nevcairiel> nothing [11:57:07 CEST] <nevcairiel> it doesnt allow a script to identify which commits are still missing [11:57:24 CEST] <TimNich> nevcairiel: well I wasnt assuming its contents got merged, but I was wondering and havent looked to see yet... [11:57:45 CEST] <nevcairiel> maybe you should before starting to rant on irc :) [11:59:12 CEST] <nevcairiel> merging cannot "skip" commits, they have to be merged - the only option is to simply empty them and not merge any content [11:59:37 CEST] <TimNich> hardley a rant, simply an observation since Daemon404 had said not to merge, o a heads up to him to make sure it was still OK [12:00:10 CEST] <TimNich> Ahh& [12:01:31 CEST] <nevcairiel> there is plenty empty merges, usually because the change is already applied in ffmpeg (usually the same way, but sometimes differently) [12:04:39 CEST] <TimNich> I always found that seeing what had gone into the merge was cumpersome, but Ive just found out that Sourcetree shows you, unlike gitk ;( [12:05:04 CEST] <nevcairiel> the web thing can also show it somewhat ok'ish [12:05:44 CEST] <TimNich> Oh. useful to know, thanks. [12:05:57 CEST] <wm4> what does sourcetree show gitk doesn't? [12:06:53 CEST] <nevcairiel> an interface that doesnt make you barf? [12:06:54 CEST] <nevcairiel> :D [12:07:25 CEST] <TimNich> In gitk if I click on a merge it just says Merge branch 'master' of [12:08:19 CEST] <nevcairiel> yeah gitk seems to fail at showing the actual local diff of a merge [12:08:40 CEST] <TimNich> but sourcetree cannot diff random commits.. [12:08:49 CEST] <wm4> gitk shows a 3-wqy diff [12:08:51 CEST] <wm4> *way [12:09:33 CEST] <nevcairiel> when i'm in the master branch, and i click on a merge commit, it would be nice to be able to see the actual changes this merge brought in [12:09:42 CEST] <nevcairiel> you know, like "git diff" can do [12:09:56 CEST] <TimNich> So Ive often wondered at the contents of a merge becasue of gitks limitation [12:09:58 CEST] <nevcairiel> unless there is a hidden button in gitk, it seems to not be able to [12:10:22 CEST] <TimNich> Im glad its not just me then... [12:12:14 CEST] <TimNich> wm4: 3-way diff? [12:12:28 CEST] <nevcairiel> 3-way diffs are stupid to read [12:13:00 CEST] <TimNich> I only have 2 eyes, so cannot cope with 3-wy [12:13:04 CEST] <TimNich> *way [12:13:49 CEST] <nevcairiel> 3-way diff is what it shows on the web thing by default as well, ie. http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=d0186a4ec4c4391906bf7d… [12:13:54 CEST] <nevcairiel> the diff shown is the 3-way [12:14:11 CEST] <nevcairiel> but you can get the actual interesting diff by clicking "diff 1" in the file list above it [12:15:08 CEST] <wm4> btw., is there a way to make git merge insert the difference between the 2 branches on a conflict? [12:15:33 CEST] <nevcairiel> difference? I always get the content from both branches in these <<<<< blocks [12:15:59 CEST] <wm4> like a diff [12:16:00 CEST] <nevcairiel> often I consult the libav git web thing to see what the actual change was, so if you mean that somehow. [12:17:40 CEST] <nevcairiel> https://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_how_confli… [12:17:43 CEST] <nevcairiel> thats all there is [12:17:54 CEST] <nevcairiel> an extra line with the original from the other side [12:25:30 CEST] <cone-617> ffmpeg 03Michael Niedermayer 07master:c0152ebb9e05: avcodec/mmaldec: Use av_assert0() instead of assert() [12:43:59 CEST] <cone-617> ffmpeg 03Christophe Gisquet 07master:9139a7e84f75: dnxhddec: cleanup frame header parsing [12:44:00 CEST] <cone-617> ffmpeg 03Christophe Gisquet 07master:4e7cba1d8a9c: dnxhd: profile flags [12:44:01 CEST] <cone-617> ffmpeg 03Christophe Gisquet 07master:52256860d6e3: dnxhdenc: do not select 4:4:4 profiles [12:58:31 CEST] <cone-617> ffmpeg 03Christophe Gisquet 07master:1f4ff53aea7c: dnxhddec: Introduce DNXHD_VARIABLE [12:58:32 CEST] <cone-617> ffmpeg 03Christophe Gisquet 07master:3a6a432b58fa: isom: add support for DNxHR codec family [12:58:33 CEST] <cone-617> ffmpeg 03Jeremy James 07master:118a3cd2c5e2: dnxhd: add decoder support for DNxHR [13:19:14 CEST] <cone-617> ffmpeg 03Christophe Gisquet 07master:66db504f038a: dnxhd: add CID 1270 [13:19:15 CEST] <cone-617> ffmpeg 03Jeremy James 07master:6f1ccca4ae3b: dnxhd: add better support for CIDs 1270 to 1274 [13:30:54 CEST] <jermy> michaelni: I've got some longer samples for DNxHR, but not sure what might be required to get something suitable for FATE [14:05:38 CEST] <michaelni> fate samples should be short ideally [14:06:02 CEST] <kierank> BBB, atomnuker: hdd problems on avdev [14:06:06 CEST] <kierank> can you backup your stuff [14:06:09 CEST] <kierank> I will replace the hdd [14:06:53 CEST] <michaelni> jermy, maybe they can be shortened? but i wasnt just asking for fate but more generally [14:10:34 CEST] <jermy> Do you want a couple of frames of each - otherwise I've got a tarball if you are more in a position to extract a little. Content was shot by a colleague so isn't a problem licence-wise [14:11:52 CEST] <michaelni> for fate ideally would be very few frames + patch, more generally if not for fate then anything is fine [14:28:16 CEST] <BBB> kierank: I have no issues with you just deleting it [15:01:39 CEST] <BBB> Gramner: ah there you go, that patch on libav-devel is what I meant (except I dont understand configure at all) [15:02:06 CEST] Action: Daemon404 waves from NY [15:18:31 CEST] <BBB> Daemon404: isnt it much nicer here than in britland? [15:18:48 CEST] <Daemon404> it's all relative [15:18:58 CEST] <BBB> so einsteinian [15:19:23 CEST] <Daemon404> harr harr [15:19:54 CEST] Action: durandal_170 writting simd for tak decorrelation [15:20:40 CEST] <BBB> durandal_170: youre really getting into it - cool! [15:21:08 CEST] <durandal_170> what have 32 byte mmsize? [15:21:26 CEST] <kierank> Daemon404: it is raining here [15:22:13 CEST] <BBB> durandal_170: avx2 [15:22:30 CEST] <BBB> durandal_170: for your stereo3d patch, its mostly ok now, try to not use three-operand instructions if you dont have to [15:22:32 CEST] <durandal_170> and how to use it? [15:22:35 CEST] <BBB> durandal_170: its slower on pre-avx hardware [15:22:40 CEST] <BBB> since it requires an extra movdqa [15:22:49 CEST] <BBB> so if you movu m0, [data] [15:22:54 CEST] <BBB> dont pshufb m10, m0, [bla] [15:23:03 CEST] <BBB> (well you can, for the first N-1) [15:23:09 CEST] <BBB> but for the last one, just use pshufb m0, [bla] [15:23:14 CEST] <BBB> that saves a movdqa on pre-avx [15:23:31 CEST] <BBB> and saves a vex instruction (longer opcode) on >=avx [15:24:04 CEST] <BBB> durandal_170: and interleave your adds so you decrease dependencies [15:24:12 CEST] <BBB> durandal_170: so instead of padd m10, m[1-5] [15:24:28 CEST] <BBB> do paddw m0, m1 - paddw m2, m3, paddw m4, m5 [15:24:30 CEST] <BBB> and so on [15:24:44 CEST] <BBB> so each instruction is independent of the previous one, which increases parallel pairing on modern cpus [15:24:55 CEST] <BBB> and the psrldq should be done in the end for all 3 together so they can pair also [15:25:03 CEST] <BBB> psrld, I mean [15:25:10 CEST] <BBB> rest is good! [15:25:22 CEST] <BBB> very nice work [15:25:50 CEST] <durandal_170> BBB: so how to do 8 pixels at once with avx2? [15:25:52 CEST] <BBB> has anyone told you you use a lot of registers and can probably tune that down? [15:26:18 CEST] <BBB> (its ok for now, but as you understand this stuff more intimately, youll want to learn to use less registers, possibly even try to make it work on 32bit :D) [15:27:11 CEST] <BBB> durandal_170: I dont have avx2 hardware so its not something Ive played with a lot, its basically the same instructions, just m%d holds twice as much data and you have lane separation which is a bloody pain [15:30:46 CEST] <durandal_170> so basically what should it look like? Line separation? [15:34:41 CEST] <BBB> lane separation [15:35:13 CEST] <BBB> imagine I load 8 bytes of data (movh) into a xmm register m0, and do punpcklbw m0, m1 where I just did pxor m1, m1 so m1 is zero [15:35:30 CEST] <BBB> I now get m0[0],0,m0[1],0,m0[2],0, etc. [15:35:31 CEST] <BBB> right? [15:35:45 CEST] <BBB> now do the same with a ymm register on avx2 [15:36:15 CEST] <BBB> I actually dont get (m0[x],0) over x=0-15, whereas I do get that for x=0-7 for xmm [15:36:43 CEST] <BBB> instead, I get (m0[x],0) over x=0-7 for the low half of the ymm register (just like xmm), and then the same over x=16-23 over the high half of the ymm register [15:36:57 CEST] <BBB> so its like as if the ymm register is actually two xmm registers, and I ran punpcklbw over both of them [15:37:02 CEST] <BBB> this complicates a lot of things [15:37:07 CEST] <BBB> some things still work, others don't [15:37:10 CEST] <BBB> shuffling is a pain, basically [15:37:29 CEST] <durandal_170> but there are v instructions [15:37:44 CEST] <BBB> x86inc.asm wraps all of that for you [15:37:50 CEST] <BBB> vpunpcklbw == punpcklbw [15:37:52 CEST] <BBB> its the same thing [15:40:05 CEST] <durandal_170> so doing stereo3d in avx2 would give any speedup? [16:01:39 CEST] <J_Darnley> durandal_170: it should give a speedup if you don't spend too much on dealing with the split-lanes complication. [16:02:13 CEST] <J_Darnley> But I'm in the same boat as BBB, I don't have an avx2 cpu, so I haven't played with it that much [16:03:20 CEST] <BBB> durandal_170: avx2 should speed up the simd about 2x, since you do twice as much data [16:03:28 CEST] <BBB> durandal_170: but not all simd works out of the boat [16:03:40 CEST] <Daemon404> avx2 is really useful for big companies, and noone else [16:03:41 CEST] Action: Daemon404 runs [16:03:55 CEST] <BBB> so pessimistic [16:04:02 CEST] <BBB> Daemon404: why do you work for a big company again? [16:04:30 CEST] <Daemon404> i dont think i'd call us properly big ;p [16:04:42 CEST] <Daemon404> anyway im just syaing not many consumers have avx2 yet [16:04:52 CEST] <Daemon404> not even a lot of companies [16:05:10 CEST] <Daemon404> my gripe is people who write tons of avx2 code [16:05:12 CEST] <Daemon404> and nothing lower [16:05:19 CEST] <Daemon404> so asm is practically useless for most [16:05:21 CEST] <J_Darnley> :) [16:05:22 CEST] <Daemon404> (whats up x265) [16:06:11 CEST] <J_Darnley> I'm waiting for money and a CPU that combines AVX2 and XOP's integer FMA [16:07:02 CEST] <kierank> Daemon404: i can see their point [16:07:14 CEST] <kierank> focus on the now and forget the past [16:07:22 CEST] <Daemon404> kierank, then why do they write for xp support [16:07:26 CEST] <Daemon404> and 32bit xp at that [16:07:32 CEST] <kierank> iono [16:07:51 CEST] <J_Darnley> I thought I read that they dropped XP by requiring some feature in Vista [16:08:21 CEST] <J_Darnley> (maybe that was someone else) [16:08:29 CEST] <Daemon404> doubtful for x265 [16:11:31 CEST] <kierank> can swresample (or avresample) do exact resampling so n samples in and m samples out [16:37:24 CEST] <Daemon404> ...wut... the cabac states had a tablegen added last year? [16:37:34 CEST] <Daemon404> is it going to be "controversial" if i move those to the codec context [16:37:37 CEST] <Daemon404> theyre not very large [16:38:47 CEST] <wm4> lol [16:39:21 CEST] <wm4> what did the commit adding these say? [16:39:35 CEST] <Daemon404> let's see [16:39:41 CEST] <nevcairiel> screw tablegen [16:39:50 CEST] <Daemon404> cabac: Allow hardcoding CABAC table. [16:39:54 CEST] <Daemon404> entirety of teh commit message [16:40:28 CEST] <nevcairiel> no reasoning, no reason for keeping [16:40:33 CEST] <Daemon404> ;) [16:40:57 CEST] <wm4> lol [16:41:10 CEST] <wm4> who needs commit messages [16:41:48 CEST] <iive> you may ask the author. [16:42:19 CEST] <Daemon404> that's not a reasonable way of mamanging a codebase [16:42:29 CEST] <Daemon404> the author may not even be around anymore, necessarily [16:43:12 CEST] <RiCON> <+J_Darnley> I thought I read that they dropped XP by requiring some feature in Vista <- they do require numa, but it's configurable at build [16:44:27 CEST] <iive> it is basic politeness to ask. if you don't get answer, then you can say that the author is not around anymore. [16:44:52 CEST] <Daemon404> iive, i think youve completely missed the point: the reason should be in the commit message [16:45:34 CEST] <TheRyuu> ^ x1000 [16:47:44 CEST] <JEEB> that indeed [16:47:56 CEST] <JEEB> if there is a reason, it should be noted for posterity [16:51:49 CEST] <iive> have you looked what the patch does? [16:52:08 CEST] <wm4> maybe we should have a policy for commit messages [16:52:24 CEST] <BBB> lets vote on the policy [16:52:32 CEST] <wm4> you know, just some formal requirements [16:52:55 CEST] <J_Darnley> You need to write a policy before you can vote on it. [16:52:56 CEST] <BBB> (guys, weve tried this for ages, some people just write really poor commit messages. point it out when it happens, but we cant fix the past - lets not dwell on it) [16:53:03 CEST] <JEEB> true that [16:53:10 CEST] <iive> no really, this patch just moves code around. [16:53:11 CEST] <Daemon404> BBB, i tried that [16:53:19 CEST] <wm4> I tend to feel silly for pointing out commit message issues [16:53:25 CEST] <Daemon404> i literally got accused of being a "bullshit libav reviewer" [16:53:33 CEST] <wm4> (feels similar to putting too much weight on cosmetic issues) [16:53:54 CEST] <iive> it seems that the old code generates the table at runtime. I assume that the code allows the table to be generated at compile time? [16:54:04 CEST] <Daemon404> iive, we know what it does [16:54:08 CEST] <Daemon404> thats not what we want [16:54:12 CEST] <Daemon404> we want to know WHY it does this [16:54:15 CEST] <Daemon404> and why it was added in 2014 [16:54:19 CEST] <Daemon404> for no gain [16:54:36 CEST] <Daemon404> this is not a hard concept to grasp [16:55:02 CEST] <iive> i think that the hardcoded vs dyngen of tables have been bashed to dead... [16:55:58 CEST] <wm4> right now we just want to fix the awful locking [16:56:03 CEST] <wm4> which causes real world problems [16:56:54 CEST] <TheRyuu> <+J_Darnley> I thought I read that they dropped XP by requiring some feature in Vista <---btw you can drop xp support very easily with the subsystem linker option (which I think exists in binutils/ld as well) [16:59:46 CEST] <RiCON> it is easy, just forget to pass "-DWINXP_SUPPORT=ON" [17:08:51 CEST] <Gramner> (@BBB) and saves a vex instruction (longer opcode) on >=avx [17:08:58 CEST] <Gramner> all instructions are vex-encoded in avx [17:09:11 CEST] <Gramner> ant rhey all use 3-operande, even if src1 and dst are identical [17:09:14 CEST] <iive> wm4: what locking do you have in mind? is it one that avoids concurent table generation? [17:09:54 CEST] <wm4> iive: there is a global, non-recursive lock in lavc and/or lavf [17:10:03 CEST] <Gramner> and vex-encoded instructions are only one byte longer than legacy instructions in very few cases, not worth caring about [17:10:38 CEST] <BBB> Gramner: hes writing xmm code [17:10:48 CEST] <BBB> Gramner: so three-operand vs. two-operand costs a vex isntr [17:12:24 CEST] <Gramner> yes of course, in legacy code 3-operand results in an extra mov [17:13:19 CEST] <Gramner> on modern hardware the extra moves doesn't cost anything other than increased cache usage though, since they're eliminated in the register renaming stage [17:13:23 CEST] <BBB> and in avx it costs a vex instr [17:13:31 CEST] <Gramner> every instruction in avx code is vex [17:13:48 CEST] <BBB> right, so doing paddw m0, m1 is better than paddw m0, m1, m2 [17:13:51 CEST] <BBB> in avx [17:14:27 CEST] <Gramner> no, becasue the first gets assembled as vpaddw m0, m0, m1 [17:14:47 CEST] <BBB> in xmm/avx? [17:14:50 CEST] <Gramner> yes. and it's the same length as legacy paddw m0, m1 [17:15:00 CEST] <BBB> rly? [17:15:04 CEST] <BBB> I didnt know that [17:15:05 CEST] <BBB> how crazy [17:15:06 CEST] <Gramner> very few instructions are longer when vec envoded [17:15:07 CEST] <BBB> why? [17:15:19 CEST] <BBB> ok nevermind that then [17:15:22 CEST] <BBB> I stand corrected [17:15:25 CEST] <nevcairiel> because it doesnt like mixing vex and legacy, clearly [17:15:36 CEST] <BBB> but but but but but but but [17:15:38 CEST] <BBB> mind blown [17:15:50 CEST] <Gramner> if you want to jmp between avx and avx2 or whatever it's easier to just use vex encoding everywhere [17:16:33 CEST] <Gramner> x86inc does that automagically since every instruction that has both legacy and vex encoding is a macro in x86inc [17:16:44 CEST] <J_Darnley> And that is what x264asm does for you when you INIT_* for avx or newer [17:16:49 CEST] <Gramner> (and yes, thats a _lot_ of macros) [17:17:46 CEST] <Gramner> which is why yasm was slow as hell in earlier version. it used a hash table to store macros but we essentialy turned that hash table into a linked list [17:18:08 CEST] <Gramner> so i made a lone line patch to yasm that incresed the hash table size and made it run 20x faster [17:18:17 CEST] <Gramner> one line* [17:19:48 CEST] <BBB> I remember that [17:20:04 CEST] <bofh__> oh, so *that's* why that change made x86inc fast again [17:20:16 CEST] <bofh__> always wondered. [17:20:47 CEST] <Gramner> yes, pengvado also made a change to x86inc that reused variables instead of creating new local variables (variables used the same hash table) [17:21:14 CEST] <Gramner> that change isn't needed with newer yasm versions, but it doesn't hurt either so we'll keep it for now [17:21:22 CEST] <wm4> I hope yasm uses a dynamic hash table size now [17:21:48 CEST] <bofh__> also iirc in vex-mode using a v* instruction with 2-operand form results in at least one assembler throwing an error instead of doing the logical thing and encoding it as a 3-op 1 with op2==op3. [17:22:07 CEST] <Gramner> it doesn't, but it's kind of irrelevant. setting it to a "large" value results in what, a few 100 kB of extra memory usage? [17:22:24 CEST] <bofh__> what matters is does it stay in L1, mostly [17:22:56 CEST] <bofh__> or at least does the hot subpart stay in L1 [17:23:59 CEST] <atomnuker> kierank: I'm fine too, just delete my stuff [17:24:06 CEST] <Gramner> the difference between L1 and L2 is tiny compared to parsing through a size 500 linked list or whatever like it used to is probably not even a noticable difference [17:25:08 CEST] <BBB> linear search [17:25:09 CEST] <BBB> hm.... [17:25:18 CEST] <BBB> do you remember these goog interview questions? [17:25:24 CEST] <BBB> actually every company has them nowadays [17:34:09 CEST] <Gramner> goog questions is like, algorithms and data structures. (and writing string manipulation functions in c, which is what I failed on when I applied there a few years ago. doing anything with strings in c is horrible compared to high level languages) [17:40:04 CEST] <durandal_170> is there any good avx2 example? [18:06:58 CEST] <BBB> durandal_170: what do you mean with good? x264 has some avx2 code, theres some code in hevc/vp9 decoders in ffmpeg [18:15:57 CEST] <kierank> you can write some v210 avx2 if you need to start somewhere =p [18:33:39 CEST] <durandal_170> BBB: for start simple pxor like in blend [18:34:01 CEST] <BBB> ? [18:34:09 CEST] <BBB> I dont understand [18:34:16 CEST] <BBB> your avx2 code will be identical to your ssse3 code [18:34:31 CEST] <BBB> x86inc.asm does a lot of magic so the disassembly will look entirely different [18:34:34 CEST] <BBB> but the source code is identical [18:34:41 CEST] <BBB> just INIT_YMM avx2 instead of INIT_XMM ssse3 [19:18:34 CEST] <bofh__> things I was hoping to never see in the wild but just did: ADTS in RIFF WAV [20:05:13 CEST] <cone-617> ffmpeg 03Ganesh Ajjanagadde 07master:1d4af04adf99: avutil/attributes: add av_warn_unused_result [20:28:00 CEST] <jamrial> why are so many fate clients failing the screenpresso test with a "file not found" error? [20:28:04 CEST] <jamrial> the sample has been in the fate suit for days, they should have synced it by now [20:28:50 CEST] <nevcairiel> maybe syncing is broken on them [20:29:04 CEST] <nevcairiel> they all seem to be michaels, fwiw [20:29:13 CEST] <nevcairiel> weell, most of them [20:43:23 CEST] <michaelni> seems some of my boxes rsync from the wrong server, they should be good on the next commit/run [20:44:07 CEST] <nevcairiel> do we have two that provide the fate suite? [20:44:16 CEST] <michaelni> yes [20:44:54 CEST] <michaelni> its on fate.ffmpeg.org too [20:45:01 CEST] <nevcairiel> i always just do make fate-rsync, wherever that gets it from [20:45:18 CEST] <nevcairiel> and whereever i uploaded samples to is apparently the same box :D [20:46:04 CEST] <michaelni> i have a explicit rsync command in my script and that used fate. i dont remember that i choose that intentionally so i probably didnt [20:46:40 CEST] <michaelni> maybe was a typo that i copied to all boxes :) [20:52:48 CEST] <jamrial> it was not just your machines, though. also ubitux's and someone called jeremy [20:59:26 CEST] <nevcairiel> maybe the second box should get a cronjob to sync its own repository over from the main one [22:31:00 CEST] <cone-617> ffmpeg 03Ganesh Ajjanagadde 07master:4802b8368a70: ffplay: log SDL error messages [22:31:01 CEST] <cone-617> ffmpeg 03Ganesh Ajjanagadde 07master:b67c1ab58cb1: ffplay: more robust condition variable creation [22:31:02 CEST] <cone-617> ffmpeg 03Ganesh Ajjanagadde 07master:4c2bfabc3a82: ffplay: use correct context for av_log [22:42:43 CEST] <cone-617> ffmpeg 03Michael Niedermayer 07master:8deb1fdac84e: avformat/omadec: Fix { typo [22:51:29 CEST] <cone-617> ffmpeg 03Ronald S. Bultje 07master:cb912b452192: vp9: fix msvc build by using 6 GPRs on 32bit if stack!=aligned. [00:00:00 CEST] --- Tue Oct 6 2015

1 0

ffmpeg.log.20151005
by burek 06 Oct '15

06 Oct '15

[01:17:56 CEST] <IRCMonkey> Hey, is there a way with ffmpeg for it to output a warning about dropped frames or lag during a stream? [02:38:37 CEST] <NapoleonWils0n> hi all [02:38:57 CEST] <NapoleonWils0n> does ffplay have a cache option like mplayer, eg -cache 8192 [02:43:04 CEST] <c_14> afaik no [02:44:51 CEST] <NapoleonWils0n> cheers was getting buffer under run with alsa [02:45:16 CEST] <NapoleonWils0n> have to change the buffer size on alsa thx mate [02:59:43 CEST] <IRCMonkey> Hey, is there a way with ffmpeg for it to output a warning about dropped frames or lag during a stream? [03:43:17 CEST] <IRCMonkey> Um, is anyone around to answer my question that I've posted? [04:12:43 CEST] <fahadash> Can we input a video file and save only audio portion of it as mp3 ? [04:20:24 CEST] <TD-Linux> fahadash, ffmpeg -i video.webm -vn audio.mp3 [04:20:41 CEST] <TD-Linux> (or whatever other audio format you want) [04:30:50 CEST] <fahadash> I found this article http://linuxpoison.blogspot.com/2010/04/how-to-extract-audio-from-video-fil… [04:30:53 CEST] <wyatt8740> anyone know if I can tell ffmpeg to seek to a given time in a pipe? I am trying to pipe video in from glc-play (a tool to play back videos recorded with glc-capture), and don't want to start ffmpeg encoding until 5 seconds into the video. I know I can do this with two runs, but I'd prefer to do it in one. Any ideas? [04:31:02 CEST] <fahadash> Well explained, saying same thing you said. Thank you TD-Linux [04:31:18 CEST] <c_14> wyatt8740: just use -ss [04:31:22 CEST] <wyatt8740> c_14: tried [04:31:24 CEST] <wyatt8740> didnt work [04:31:36 CEST] <c_14> Should [04:31:38 CEST] <c_14> What's your command? [04:32:10 CEST] <wyatt8740> I was attempting to play it back as I encoded for testing purposes, so my command was glc-play glc-capture-2.glc -y 1 -o - | ffmpeg -i - -ss 00:05:00 -f nut -vcodec rawvideo - | ffplay - [04:32:25 CEST] <wyatt8740> and my error: EOF before video frames [04:32:26 CEST] <wyatt8740> pipe:: Invalid data found when processing input [04:32:32 CEST] <fahadash> Sometimes I wish that some of the other projects were as cool as ffmpeg [04:32:54 CEST] <wyatt8740> also, 'glc-play glc-windwaker-2.glc -y 1 -o - | ffplay -ss 00:05:00.000 -' doesnt work [04:32:59 CEST] <wyatt8740> just plays the video without seeking [04:33:19 CEST] <wyatt8740> says 'pipe:: could not seek to position 300.000' [04:33:26 CEST] <wyatt8740> yknow, because its in a pipe [04:33:38 CEST] <fahadash> You need a "delay" :P [04:33:43 CEST] <wyatt8740> yes [04:33:45 CEST] <wyatt8740> yes I do [04:33:59 CEST] <wyatt8740> and that's what I'm asking for :p [04:35:41 CEST] <c_14> cat file | ffmpeg -ss 60 -i - out.mkv <- works for me [04:35:53 CEST] <wyatt8740> I can't cat the file because it's not a raw video file [04:36:07 CEST] <c_14> It's still just a normal pipe. [04:36:20 CEST] <wyatt8740> yes it is, and if you see what I just said it didn't work [04:36:43 CEST] <c_14> It does for me. What version are you running? [04:36:52 CEST] <wyatt8740> 2.7.2 [04:37:57 CEST] <wyatt8740> and again: [nut @ 0x7f5b10000920] EOF before video frames [04:37:57 CEST] <wyatt8740> pipe:: Invalid data found when processing input [04:38:06 CEST] <wyatt8740> because I'm trying to preview my seek [04:38:37 CEST] <wyatt8740> so if anyone knows a container that works for piping that works out better than nut, let me know [04:39:06 CEST] <wyatt8740> also says 'Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used)' [04:39:36 CEST] <c_14> try mpegts? [04:39:37 CEST] <wyatt8740> oh wait [04:39:42 CEST] <wyatt8740> 00:05:00 is 5 minutes [04:39:43 CEST] <wyatt8740> not 5 seconds [04:39:48 CEST] <wyatt8740> let me try this :\ [04:39:59 CEST] <wyatt8740> aand that worked [04:40:01 CEST] <wyatt8740> i'm a moron [04:40:05 CEST] <wyatt8740> thanks :D [04:41:43 CEST] <fahadash> "Lets try this" would have been the last words of any human after the extinction of human race [04:42:00 CEST] <fahadash> would be* [05:01:19 CEST] <wyatt8740> FFmpeg was actually my first experience with the command line in any meaningful way and was the gateway for me to linux/unix and open-source/free software :) [05:01:38 CEST] <wyatt8740> All I originally wanted was a video encoder for my ipod but I ended up with so much more. [05:12:18 CEST] <wyatt8740> and yet I am still learning how the CLI tool works -_- [05:12:39 CEST] <wyatt8740> (6 years later) [05:58:43 CEST] <pinPoint> the video and audio input always come first before any other codec specs in ffmpeg right? [05:59:42 CEST] <c_14> The options go in front of the file they modify. [06:02:07 CEST] <pinPoint> but input is first right? [06:03:00 CEST] <c_14> If an option is supposed to be applied to the output, it goes after the inputs and before the output. [06:03:10 CEST] <klaxa> general syntax: ffmpeg [input options] -i <input> [output options] <output> [06:03:10 CEST] <c_14> If it's supposed to be applied to the input, it goes before the input. [06:03:11 CEST] <pinPoint> ok [06:03:19 CEST] <pinPoint> so like this: ./ffmpeg -i phfx_com.mov i audio.m4a c:v prores_ks -profile:v 4 -pix_fmt yuv444p10 output.mov [06:03:28 CEST] <klaxa> looks correct [06:03:47 CEST] <c_14> You're missing a '-' before the c:v [06:03:48 CEST] <klaxa> maybe set an audio codec if you don't want to use the default [06:03:52 CEST] <klaxa> ah [06:03:56 CEST] <klaxa> missed that [06:03:56 CEST] <pinPoint> yes [06:05:02 CEST] <pinPoint> like this. ==> ./ffmpeg -i phfx_com.mov i audio.m4a -c:v prores_ks -profile:v 4 -pix_fmt yuv444p10 -c:a aac -strict -2 -b:a 256k output.mov [06:05:40 CEST] <klaxa> if it is already in aac, maybe you might just want to copy the audio [06:05:57 CEST] <klaxa> but afaik the native aac encoder has gotten some improvements? [06:06:16 CEST] <pinPoint> it works fine actually. sound is good [06:06:33 CEST] <pinPoint> but yes.. it might be a .wav input or .mp3 [06:09:35 CEST] <pinPoint> klaxa: so remove -c:a aac -stric -2 -b:a 256k and replace with -a copy? [06:09:46 CEST] <klaxa> with -c:a copy [06:09:48 CEST] <klaxa> but yes [06:23:10 CEST] <pinPoint> ok [11:01:14 CEST] <ravenlock> Hi. I've a question regarding the usage of FFmpeg in commercial software. [11:01:21 CEST] <ravenlock> I've read the following: https://www.ffmpeg.org/legal.html [11:01:53 CEST] <ravenlock> but am hoping to gather a few comments from your team if possible. [11:03:27 CEST] <JEEB> neither GPL or LGPL do not stop you from using it in commercial software, although GPL might not be viable for closed source cases due to its "release all sources" nature [11:04:38 CEST] <JEEB> LGPL FFmpeg is of the usual LGPL kind. "Give the user the exact sources for the LGPL software, Let the user replace the library if he or she really wants to (in other words, with shared linking you don't do much else, with static linking you release object files so that the user can link his own FFmpeg into it) [11:04:38 CEST] <JEEB> more or less like that [11:04:44 CEST] <JEEB> IANAL and all that of course [11:05:23 CEST] <ravenlock> closed source is our desire (commercial I suppose was moot) [11:06:19 CEST] <ravenlock> as I read the license compliance, I felt we were essentially in the clear, but there is one stipulation that concerns me in particular [11:06:44 CEST] <ravenlock> #13 Remove any prohibition of reverse engineering from your EULA. [11:07:28 CEST] <ravenlock> would you consider this mandatory? must we prevent customers from reverse engineering our closed source application? [11:08:46 CEST] <Mavrik> ? [11:08:49 CEST] <ravenlock> and JEEB .. would you be a FFmpeg dev? (I'm not familiar with the FFmpeg community) [11:08:59 CEST] <Mavrik> ravenlock, it explicitly says you MUST NOT prevent your customers from reverse engineering. [11:09:42 CEST] <ravenlock> yes, I see that. :) [11:09:54 CEST] <ravenlock> however... the page also has the caveat: "It is not the only way to comply with the license, but we think it is the easiest. There are also a few items that are not really related to LGPL compliance but are good ideas anyway." [11:10:10 CEST] <ravenlock> so... is #13 just "a good idea" [11:10:12 CEST] <ravenlock> or required? [11:10:31 CEST] <Mavrik> LGPL requires it. [11:10:35 CEST] <Mavrik> Of course, ask your lawyer. [11:10:46 CEST] <Mavrik> But your EULA must not speak for LGPLed code. [11:11:00 CEST] <ravenlock> strangely.... our corp lawyers refuse to comment for fear they will be liable. o_0 [11:11:17 CEST] <Mavrik> Why the fuck do you have them then? [11:11:23 CEST] <ravenlock> hahaha [11:11:27 CEST] <ravenlock> I don't write that check. [11:11:33 CEST] <Mavrik> Anyway, see http://programmers.stackexchange.com/a/163667 :) [11:11:36 CEST] <ravenlock> I've asked the same question [11:13:02 CEST] <ravenlock> ok. thanks. that post seems.... enlightening [14:06:46 CEST] <sovernace> c++ pointed me here. Any basic tutorials for a novice at c++ to learn ffmpeg and make a well made game streaming software? [14:06:58 CEST] <sovernace> Browsing the website now.. [14:08:13 CEST] <Mavrik> hmmf. [14:08:31 CEST] <Mavrik> FFmpeg is written in C and there's nothing much else than the examples in doc/ folder and doxygen documentation. [14:19:55 CEST] <sovernace> So... learn C? and c++ is all the sudden saying not to use h.264 because thats high latency. ffmpeg and h.264 are two different encoding methods, right? [14:21:00 CEST] <sovernace> I found http://ffmpeg.gusari.org/viewforum.php?f=25&sid=5ac333fe17b563a10c965905d08… ... [14:25:21 CEST] <iive> ffmpeg is framework, that support a lot of codecs. h264 is one of the codecs. [14:26:43 CEST] <iive> there is x264 that is encoder implementation. it also supports a number of options to lower the latency (aka disable bi-direction frames, look-ahead and other stuff that increases compression) [14:33:59 CEST] <sovernace> I just... dont know how to use any of this yet. I ran into trouble with my ide trying to figure out why i'm getting undefined references for things in windows.h for capturing the image of my screen [14:34:31 CEST] <blue112> Hi here. [14:34:39 CEST] <blue112> I'm getting a segfault when calling sws_getContext [14:34:43 CEST] <blue112> What could be the problem ? [14:35:23 CEST] <BtbN> You're calling it wrong. Or you found a bug in swscale. Or you did something that corrupted the heap/stack. Or your ram is broken. Or something miscompiled libswscale. [14:35:38 CEST] <blue112> Hm, probably the corruption thing. [14:35:56 CEST] <blue112> Because it doesn't crash every time, maybe 4 time out of 53 [14:35:57 CEST] <blue112> 5* [14:36:19 CEST] <BtbN> Use your favourite debugger to track it down. [14:36:44 CEST] <blue112> I don't know how to debug correctly a program on Windows [14:37:41 CEST] <DHE> does valgrind run under windows? inconsistent crashes like that often suggest valgrind can help track it down [14:37:55 CEST] <blue112> valgrind would help, yeah. I'm checking if it runs on windows. [14:38:09 CEST] <blue112> First google link "Is there a good Valgrind substitute for Windows?" [14:38:13 CEST] <blue112> Doesn't sound like it does. [14:39:47 CEST] <blue112> I'm checking drmemory [15:13:22 CEST] <blue112> I got a WARNING: prefetching unadressable memory in avcodec. unpon calling avformat_find_stream_info [15:14:16 CEST] <blue112> That's all I got [15:18:06 CEST] <iive> prefetch never segfaults, you can give it invalid address and it would just ignore it. [15:18:29 CEST] <blue112> iive, ok, so why does my sws_getContext sometime segfaults ? [15:19:41 CEST] <iive> if it does crash on prefetch, you might have found a CPU bug. [15:20:29 CEST] <iive> also, avformat is file reading/writing ... quite far away from swscale. [15:20:39 CEST] <blue112> iive, I don't think it crashes on prefetch. I though there was some memory corruption, so I've check with a memcheck tool. But no problem other than this unadressable prefetch. So, if there's no memcorruption, why does it crashes on getContext, which sounds like a benign operation to me ? [15:22:49 CEST] <iive> run it under gdb and when it crashes, do a backtrace [15:23:26 CEST] <iive> if it happens at random, there is a good chance some function got unaligned buffer when it expects it to be aligned. [15:23:52 CEST] <iive> e.g. you might have allocated buffer with malloc, instead of av_alloc [15:23:57 CEST] <blue112> iive, actually, it runs perfectly on Linux. It crashes on windows. [15:23:57 CEST] <iive> stuff like that. [15:24:16 CEST] <blue112> Hm, I have no malloc, only av_malloc [15:24:26 CEST] <iive> i think on windows memalign hack is enabled by default... [15:24:54 CEST] <blue112> when it doesn't crash on sws_getContext, it does on sws_scale [15:25:36 CEST] <iive> you'll have to debug it. [15:25:49 CEST] <blue112> gdb doesn't seems to be able to read symbols from my PE file [15:25:50 CEST] <blue112> :( [15:28:18 CEST] <iive> if you compile with visual studio, run it with its debugger. [15:29:56 CEST] <blue112> iive, I compile it with visual studio tools, cl and link, from a makefile. How do I start the debugguer then? [15:30:11 CEST] <iive> i have no idea... [15:47:32 CEST] <Prelude_Zzzzz> hey everyone good day [15:48:01 CEST] <Prelude_Zzzzz> can anyone help me... with ffmpeg encoding.. my image is looking pretty good but on scene changes it get lots of pixelation and then it cleans up 1 second later [15:48:24 CEST] <Prelude_Zzzzz> any way to make the system be smart and not cause any pixalation on scene change ? [15:52:31 CEST] <iive> Prelude_Zzzzz: that's what you get at fixed bitrate. you can either use quality base encoding (e.g. libx264 -crf 18 gives you quality similar to mpeg2 quant=2 maximum quality) OR use two pass encoding (if you want the best quality for a given size). [15:53:18 CEST] <iive> if you are capturing and streaming, then setting vbv buffer may easy the spikes by keyframes. [20:05:29 CEST] <Foloex> hello world [20:06:06 CEST] <Foloex> I'm trying to use the concat demuxer as specified here: https://ffmpeg.org/ffmpeg-formats.html#concat [20:07:01 CEST] <Foloex> I get errors with inpoint and outpoint, saying "unknown keyword ..." [20:08:26 CEST] <Foloex> Does any of you has a complex script file using most of the api presented in the link I provided ? [20:10:19 CEST] <Foloex> it seems like concat only accepts "file" keywords [20:14:01 CEST] <YaMoonSun_> Firstly, good morning, secondly, give me a moment and I'll read that real quick [20:15:10 CEST] <Foloex> YaMoonSun_: good evening, sure, no rush [20:18:51 CEST] <Foloex> by the way, here is a more concrete howto of concat: https://trac.ffmpeg.org/wiki/Concatenate [20:19:42 CEST] <YaMoonSun_> So you're trying to combine videos essentially? [20:20:04 CEST] <Foloex> yes, but using subpart of videos [20:20:41 CEST] <YaMoonSun_> Implying just a clip from each video instead of combining the two full sized video streams? [20:20:47 CEST] <Foloex> yes [20:22:30 CEST] <Foloex> the issue is that the "inpoint" and "outpoint" keyword provided by the api are not recognised when used in a script [20:22:31 CEST] <YaMoonSun_> I'm fairly certain that you just have to create a mylist.txt file that contains all the file locations as well as their start (-ss) and ending times (-to) [20:22:56 CEST] <Foloex> only "file" "duration" and "ffconcat version 1.0" seem to be recognised [20:23:27 CEST] <YaMoonSun_> Can copy/paste the terminal or command prompt into a pastebin? [20:24:39 CEST] <Foloex> http://pastebin.com/cs6gZ7qA [20:25:52 CEST] <Foloex> what I pasted should be the equivalent of "ffmpeg -i input.mp4 -ss 23 -to 4:39.7 -c copy output.mp4" [20:26:37 CEST] <c_14> Foloex: your version of ffmpeg is probably too old [20:26:40 CEST] <YaMoonSun_> That never worked for me personally, I had to do -ss 00:00:23 -to 00:04:39.700 [20:26:44 CEST] <c_14> inpoint/outpoint are relatively new [20:26:59 CEST] <YaMoonSun_> Also, -c copy copies both audio and video codecs? [20:27:02 CEST] <c_14> (but it looks like they're bugged in current git) [20:27:25 CEST] <Foloex> c_14: in the doc it says "The concat demuxer was added to FFmpeg 1.1" [20:27:34 CEST] <Foloex> I have ffmpeg version 2.6.4 [20:27:35 CEST] <c_14> The demuxer, sure. But not all the options. [20:28:24 CEST] <Foloex> then it says "You can read about it in the documentation." with a link pointing to https://ffmpeg.org/ffmpeg-formats.html#concat [20:28:50 CEST] <c_14> So? 2.6.4 is old [20:30:15 CEST] <Foloex> ok, so I'll install 2.8 from source and hope it works ? [20:31:02 CEST] <c_14> You can try that, but I think they're currently bugged. I'll have to test later. [20:31:30 CEST] <Foloex> (I installed it on debian through the deb-multimedia repository) [20:33:32 CEST] <Foloex> c_14: thanks [21:29:53 CEST] <brontosaurusrex> whats the max that lame encoded file lenght would vary from original? [21:30:03 CEST] <brontosaurusrex> length* [21:34:47 CEST] <Foloex> wow, the speed difference between 2.6.4 and 2.8 is impressive [21:36:50 CEST] <Foloex> 2.8 gets "inpoint" and "outpoint" \o/ [21:37:18 CEST] <Foloex> it's all good now [21:37:39 CEST] <Foloex> c_14, YaMoonSun_ : thanks [21:38:06 CEST] <YaMoonSun_> Nice, glad you got it taken care of man [00:00:00 CEST] --- Tue Oct 6 2015

1 0

ffmpeg-devel.log.20151004
by burek 05 Oct '15

05 Oct '15

[00:17:21 CEST] <cone-286> ffmpeg 03DHE 07master:76e3f8242d60: libavformat/hlsenc: Use of uninitialized memory unlinking old files [02:57:13 CEST] <cone-286> ffmpeg 03Rodger Combs 07master:a2b8b163004e: lavf: add chromaprint muxer [03:16:22 CEST] <jamrial> did videolan.org ssl certificate just expire? [03:17:40 CEST] <atomnuker> >Expires on 04/10/16 [03:17:43 CEST] <atomnuker> doesn't seem so [03:18:20 CEST] <jamrial> i just got a warning, and the cert says expires on 10/3/2015 [03:27:11 CEST] <DHE> it was issued just over 30 days ago... surprisingly clean number... [03:34:40 CEST] <jamrial> atomnuker: sorry, i was talking about git.videolan.org [06:52:40 CEST] <rcombs> jamrial: yup, looks expired to me as well [06:53:10 CEST] <rcombs> looks like they've replaced the cert but haven't installed it on the git server yet [06:53:24 CEST] <jamrial> good to know it's not just me, then [06:54:31 CEST] <jamrial> j-b: ^ [07:00:44 CEST] <rcombs> pointed out in #videolan [07:00:51 CEST] <rcombs> a look is apparently being taken [07:27:14 CEST] <rcombs> fixed [07:33:59 CEST] <jamrial> yep [10:30:24 CEST] <nevcairiel> mmm my schannel tls module can create a connection and verify the certificate if requested .. reading and writing actual data to/from the socket are overrated, right [10:57:53 CEST] <rcombs> heh [10:57:59 CEST] <rcombs> nice :D [11:09:08 CEST] <nevcairiel> why MS never made a slightly higher level API, i will probably never know [11:09:26 CEST] <nevcairiel> the worst part is that client and server modes need to use quite different code paths [11:09:31 CEST] <nevcairiel> but i dont need server mode [11:09:35 CEST] Action: nevcairiel skips [11:10:30 CEST] <rcombs> huh, funky given that all the other libs make it pretty similar [11:10:51 CEST] <nevcairiel> this API is 100 times more low level than any of the others [11:11:08 CEST] <nevcairiel> here http://pastebin.com/4hJBPirX [11:11:17 CEST] <nevcairiel> look how much shit establishing a connection needs [11:11:25 CEST] <rcombs> if you get that working we should add autodetection in configure for a cert file on linux, and turn on verification by default [11:12:36 CEST] <rcombs> &ew [11:17:11 CEST] <nevcairiel> I'm also simply ignoring all the ca file options for now [11:17:15 CEST] <nevcairiel> as well as the listen mode [11:17:23 CEST] <nevcairiel> finish the one mode I would use myself first =p [11:18:27 CEST] <rcombs> good plan [11:19:43 CEST] <nevcairiel> personally i dont care for cert validation, i dont have a way to give feedback to the user, so i would probably always turn it off again [11:20:09 CEST] <nevcairiel> i should test what MSs URL reader does with an invalid cert [12:39:16 CEST] <ubitux> rcombs: chromaprint is distributed with a .c [12:39:19 CEST] <ubitux> .pc* [12:39:26 CEST] <ubitux> you could have use require_pkg_config [12:39:36 CEST] <wm4> but cehoyos [12:39:37 CEST] <ubitux> now it's forever require :( [12:39:53 CEST] <ubitux> well, now it will be considered a regression :) [12:40:13 CEST] <wm4> no, it's been in the tree only for a day [12:52:00 CEST] <nevcairiel> wee it works [12:52:26 CEST] <nevcairiel> http://pastebin.com/w43hxTaH not long at all, noo [12:56:25 CEST] <wm4> wonderful [13:18:03 CEST] <cone-754> ffmpeg 03Kyle Swanson 07master:4f721bfd4612: avfilter/ebur128: add dualmono measurement option [13:18:03 CEST] <cone-754> ffmpeg 03Clément BSsch 07master:513fcd4167d4: avfilter/ebur128: use AV_OPT_TYPE_BOOL for video option [13:20:47 CEST] <durandal_1707> BBB: I have issues with anaglyph function in stereo3d, can this be done at all? [13:21:01 CEST] <BBB> let me see [13:24:32 CEST] <BBB> durandal_1707: yeah thats not so hard, whats the issue with it? [13:25:06 CEST] <BBB> durandal_1707: I guess horizontal stuff isnt very cool, but its not super-hard, you basically have to convert the buffers from 8 pixels to 8 rs, 8 gs and 8 bs, and then do stuff with that [13:34:32 CEST] <cone-754> ffmpeg 03Ching Yi, Chan 07master:5d926d547388: avformat/flacdec: support fast-seek [13:38:58 CEST] <BBB> durandal_1707: the magic instruction (in ssse3) is pshufb, Id load 3 registers (data, data+8 and data+16) which is 8 pixels of data (or maybe half of that, since youre currently working in dwords), and then pshufb them into orientation to have 4/8 rs, 4/8 gs and 4/8 bs, multiply then with appropriate coefficients, and then pshufb them back to rgb order [14:00:04 CEST] <durandal_1707> BBB: what to use to get dwords back to bytes? [14:02:26 CEST] <kierank> packusdw, packuswb or sometime shuffle iirc [14:03:06 CEST] <J_Darnley> packusdw is sse4 [14:03:36 CEST] <J_Darnley> check the 16-bit yadif code I wrote if you want to emulate it. [14:04:24 CEST] <J_Darnley> (assuming your values are in 0-INT_MAX range [14:04:37 CEST] <kierank> iirc there is a macro [14:14:20 CEST] <BBB> packssdw works [14:14:45 CEST] <BBB> packssdw+packuswb [14:14:48 CEST] <BBB> packssdw is sse2 [14:16:02 CEST] <J_Darnley> As I understand it, it should work if you don't have a value over 0x7fff [14:20:56 CEST] <BBB> 0x7fffffff [14:21:39 CEST] <BBB> (INT_MAX) [14:22:19 CEST] <J_Darnley> but it saturates to the signed word range... oh wait, this is going to be packed again to bytes so who cares [14:22:52 CEST] <BBB> right, it doesnt matter in this case [14:23:32 CEST] <BBB> I also still wonder if 32bit intermediates is overkill [14:23:37 CEST] <BBB> but well leave that for some other time :) [14:50:50 CEST] <nevcairiel> re: schannel, if someone is curious about a full patch for testing or something https://github.com/Nevcairiel/FFmpeg/commit/33271e6db717a3bf80e524da7d1c82b… [14:51:02 CEST] <nevcairiel> i briefly tried to implement listen mode, but it didnt work, so i gave up for now [14:54:22 CEST] <wm4> what is listen mode? [14:54:46 CEST] <nevcairiel> you can open a listening socket [14:54:50 CEST] <nevcairiel> and connect from another machine [14:55:23 CEST] <nevcairiel> ie. this works ffmpeg -i file -f mpegts -listen 1 tcp://<your ip>:1234/ .. and on second machine do ffmpeg -i tcp://<ip>:1234/ [14:55:31 CEST] <nevcairiel> just with tls encryption [14:55:43 CEST] <wm4> sounds very useful (not) [14:55:59 CEST] <nevcairiel> the basis is probably not too bad, its a cheap way to stream live media over the network [14:56:06 CEST] <nevcairiel> if you need tls for that is another question [14:57:15 CEST] <nevcairiel> you can use it the other way around as well, open a listneing socket on some remote machine, and push content there, possibly for further processing, and once its done it could push it back [14:57:24 CEST] <nevcairiel> in theory you could do some fun things with little effort [14:57:27 CEST] <nevcairiel> but again, meh tls [15:06:55 CEST] <nevcairiel> Anyway my main goal was to enable reading of https urls, which i solved [15:07:06 CEST] <nevcairiel> some users keep complaining, and i cba to bundle gnutls or openssl [15:07:51 CEST] <wm4> heh [15:08:02 CEST] <wm4> yeah, that seems like a good thing [15:13:55 CEST] <BBB> wm4: Id like the #if HAVE_THREADS patch in, we have specific hooks in each AVCodec to only initialize the threading bits if threading is enabled, so its clearly considered a feature important enough to obfuscare each AVCodec instance in our codebase [15:13:59 CEST] <BBB> wm4: is that ok? [15:14:39 CEST] <wm4> which patch? [15:14:59 CEST] <wm4> the one about compiler warnings? [15:15:02 CEST] <BBB> yes [15:15:47 CEST] <BBB> (you objected to the concept of fixing that specific warning) [15:15:52 CEST] <wm4> I still don't get the point (at all), but I won't block it [15:16:23 CEST] <BBB> ok, ty [15:25:57 CEST] Action: Compn quotes developer policy and runs [15:26:04 CEST] <Compn> run for the hills! [15:30:59 CEST] <BBB> hm, theres no hevc maintainer in MAINTAINERS [15:31:08 CEST] <BBB> I guess nobody wants it [15:42:41 CEST] <cone-754> ffmpeg 03Henrik Gramner 07master:ec85153f252c: checkasm: Fix compilation with --disable-avcodec [15:58:24 CEST] <durandal_1707> so I need to do rgbrgbrgbrgb -> rrrrggggbbbb [16:00:08 CEST] <durandal_1707> BBB ^ [16:04:07 CEST] <Gramner> pshufb [16:05:58 CEST] <nevcairiel> pshufb is the only good way to do 3 component shuffling, f'ing odd counts [16:06:29 CEST] <durandal_1707> yes but what arg to use? [16:07:08 CEST] <kierank> you can read the doc and work it out [16:07:38 CEST] <RiCON> nit: ffmpeg -protocols with different sort using librtmp http://j.fsbn.eu/PXde.png (left with ffrtmp, right with librtmp) [16:09:15 CEST] <wm4> I would have expected left to be librtmp? [16:09:25 CEST] <RiCON> oh, external libraries always get sorted after [16:09:30 CEST] <wm4> yeah [16:09:32 CEST] <RiCON> so it's probably intended [16:09:54 CEST] <RiCON> and yeah, left is librtmp, typo [16:09:57 CEST] <wm4> yeah, I think it's registration order [16:15:31 CEST] <durandal_1707> ok I think I got order [16:17:02 CEST] <RiCON> nevcairiel: trying schannel, seems to compile and work fine with mpv [16:18:42 CEST] <JEEB> oh, native tls? [16:19:38 CEST] <wm4> fun, lots of native APIs lately (libass is fontconfig free, now ffmpeg will be openssl free) [16:21:13 CEST] <durandal_1707> if I have rrrrggggbbbb how to extract gggg? [16:21:32 CEST] <durandal_1707> or bbbb? [16:21:34 CEST] <nevcairiel> could shift it to the front and read 32-bit or something [16:21:44 CEST] <nevcairiel> no idea if there is a smarter way [16:22:02 CEST] <J_Darnley> A better question: where do you want to extract it to? [16:22:42 CEST] <durandal_1707> to another register so I can add and multiply [16:22:55 CEST] <J_Darnley> Is that a SIMD register then? [16:23:02 CEST] <durandal_1707> Yes [16:23:40 CEST] <J_Darnley> Perhaps a shift to low and unpack, or pshufd and unpack [16:24:09 CEST] <J_Darnley> I think AVX has some more interesting blending instructions [16:27:09 CEST] <J_Darnley> I'm starting to wonder whether I should gather various separate instruction references from across the web into one place. [16:27:49 CEST] <J_Darnley> I, for one, can't remember many of the things added after SSE2 [16:28:26 CEST] <JEEB> I think they have just made the reference manual longer and longer [16:28:43 CEST] <JEEB> and then there's some kind of interactive reference thing which might have been java [16:28:53 CEST] <J_Darnley> They cerainly have, and its split A-M and N-Z [16:29:21 CEST] <J_Darnley> I saw an online JS-based intrinsics reference [16:29:26 CEST] <JEEB> :o [16:29:32 CEST] <JEEB> that makes more sense than the Java applet [16:29:40 CEST] <J_Darnley> https://software.intel.com/sites/landingpage/IntrinsicsGuide/ [16:29:48 CEST] <JEEB> wow [16:29:50 CEST] <nevcairiel> does it use asm.js? :P [16:29:50 CEST] <JEEB> finally [16:29:54 CEST] <J_Darnley> It showed my just how inane it was [16:30:06 CEST] <J_Darnley> So many ways to load a dword [16:30:36 CEST] <J_Darnley> Fortunately you can search for an exact instruction name. [16:30:40 CEST] <nevcairiel> keep note that its intrinsics, so a bunch map to the same instruction [16:31:04 CEST] <JEEB> yeah [16:35:27 CEST] <Gramner> https://www-ssl.intel.com/content/dam/www/public/us/en/documents/manuals/64… [16:35:28 CEST] <J_Darnley> If I knew any javascript I would probably steal that page and use it for actual assembly instructions. [16:37:03 CEST] <Gramner> also https://software.intel.com/sites/default/files/managed/07/b7/319433-023.pdf for future stuff [16:37:16 CEST] <J_Darnley> OMG! There's a third volume! [16:38:04 CEST] <Gramner> third volume is for os design iirc [16:38:10 CEST] <J_Darnley> oh [16:38:20 CEST] <J_Darnley> that's a little better [16:38:25 CEST] <Gramner> and virtual machine things [16:43:29 CEST] <RiCON> ffrtmpcrypt can only use openssl? [16:44:38 CEST] <nevcairiel> apparently [16:44:40 CEST] <nevcairiel> dont ask me why [16:44:59 CEST] <J_Darnley> Because nobody wrote anything else? [16:45:12 CEST] <J_Darnley> All you streaming nuts were satisfied? [16:45:18 CEST] <nevcairiel> ah it can also use gmp [16:45:31 CEST] <nevcairiel> but yeah it needs some magic that does dh exchanges [16:45:36 CEST] <nevcairiel> that uses openssl or gmp [16:45:48 CEST] <nevcairiel> or gmp/gcrypt, whatever [16:51:06 CEST] <RiCON> only "mainstream" use of rtmpe i can remember is crunchyroll [16:52:22 CEST] <JEEB> a lot of places use it since it's the least irritating thing that comes down as some kind of "DRM" [17:11:38 CEST] <nevcairiel> i dunno, isnt it just weak encryption with a key exchange built into the protocol? you dont even need a crypt key or something to decrypt it, you just ask the server .. might as well use rtmps [17:17:58 CEST] <nevcairiel> (in other news, schannel even works on xp) [17:22:56 CEST] <durandal_1707> I get segv when trying to multiply with coefficients [17:36:36 CEST] <J_Darnley> durandal_1707: post the code [17:36:54 CEST] <J_Darnley> in the mean time I will guess: something isn't aligned [17:38:39 CEST] <durandal_1707> I'm supposed to movd instead to pmulld directly [17:39:40 CEST] <J_Darnley> huh? [17:42:07 CEST] <durandal_1707> movd coeffs to mX [17:43:18 CEST] <durandal_1707> how to concat rrrr +gggg+bbbb? [17:43:43 CEST] <J_Darnley> shift + or [17:54:17 CEST] <cone-754> ffmpeg 03Ganesh Ajjanagadde 07master:59594b11f962: Changelog: add note on ffplay dynamic volume control [17:54:18 CEST] <cone-754> ffmpeg 03Ganesh Ajjanagadde 07master:c3e8de1c248f: ffplay: more robust thread creation [18:14:16 CEST] <BBB> durandal_1707: segfault is probably because arguments are not aligned [18:14:23 CEST] <BBB> durandal_1707: if theyre 16byte aligned, you can multiply directly [18:15:24 CEST] <durandal_1707> BBB: I can't get red plane to work correctly [18:15:47 CEST] <durandal_1707> just doing red plane for now [18:18:19 CEST] <durandal_1707> can [x][] be accessed from asm? [18:29:10 CEST] <durandal_170> BBB: https://github.com/richardpl/FFmpeg/blob/stereo3d/libavfilter/x86/vf_stereo… [18:31:44 CEST] <BBB> what is [x][]? [18:32:36 CEST] <durandal_1707> matrix [18:32:50 CEST] <durandal_1707> NxM size [18:33:31 CEST] <BBB> what code re you thinking of specifically? [18:33:54 CEST] <BBB> if its a matrix of int16_t bla[20][3], yeah, sure, you can open that in assembly [18:34:18 CEST] <BBB> if its int16_t *bla[3]; each filled with int16_t x[something], its a little different, but still doable [18:34:40 CEST] <BBB> the first is a simple dereference, the second needs two levels of dereferences [18:34:50 CEST] <Gramner> something something AoS vs SoA [18:35:28 CEST] <durandal_1707> just asking, unrelated to stereo3d [18:35:38 CEST] <BBB> why do you shuf followed by unpack/zerp-extend? [18:35:42 CEST] <BBB> pshufb can zero-extend for you [18:36:04 CEST] <BBB> pshufb m0, bytearray[0,-1,-1,-1,3,-1,-1,-1,6,-1,-1,-1,9,-1,-1,-1] [18:36:11 CEST] <BBB> will create dword reds zero-extended [18:36:26 CEST] <BBB> and then 0369->147A or 258B to get G/B [18:36:41 CEST] <BBB> -1 means zero it instead of take byte[idx]" [18:37:02 CEST] <BBB> how large are the coefficients? [18:37:13 CEST] <BBB> if theyre 16bit, you should use pmaddwd, not pmulld [18:38:14 CEST] <durandal_1707> they are bigger than that sometime [18:39:01 CEST] <BBB> oh, unfortunate, ok [18:45:29 CEST] <jamrial> durandal_1707: you wrote 20 for xmm regs by mistake in that file above [18:46:12 CEST] <cone-754> ffmpeg 03Ganesh Ajjanagadde 07master:26e8895b7395: all: add _DEFAULT_SOURCE locally wherever needed [18:47:02 CEST] <durandal_1707> jamrial: iknow, but thats not problem [18:48:48 CEST] <cone-754> ffmpeg 03Ganesh Ajjanagadde 07master:2cbaa078d18a: avcodec: use HAVE_THREADS header guards to silence -Wunused-function [19:01:26 CEST] <durandal_1707> BBB: so nothing obvious why I do not get red plane? [19:01:47 CEST] <BBB> oh havent checked that yet :) [19:01:50 CEST] <BBB> will do in a bit [19:10:28 CEST] <durandal_1707> I now get red something but it looks like mults and adds messed up something [19:12:00 CEST] <cone-754> ffmpeg 03James Almer 07master:b70566d6ca7b: avcodec/alacdec: split off decorrelate_stereo and append_extra_bits as alacdsp [19:21:33 CEST] <BBB> durandal_1707: your shufs are weird [19:22:04 CEST] <BBB> durandal_1707: I think you want 3 shufs for rgbrgbrgbrgb -> r000r000r000r000 and g000g000g000g000 and b000b000b000b000 [19:22:26 CEST] <BBB> durandal_1707: and then after packuswd/wb that back to rrrrggggbbbbxxxx, you need another shuf to get back to rgbrgbrgbrgb(xxxx) [19:22:33 CEST] <BBB> and then you can write out 4 pixels/12 bytes [19:22:49 CEST] <BBB> durandal_1707: and once it works for 4 pixels, you can adjust it to pair in twos and do 8 pixels at a time [19:35:20 CEST] <durandal_170> BBB: i did some changes, use same link, i hope its more obvious now, bug is still there [19:36:57 CEST] <BBB> why is m8/m9/m10 all initialized from ana_matrix_rd? [19:37:16 CEST] <BBB> and why movd? [19:38:13 CEST] <BBB> so, I think your ana_matrix conversion in 8/9/10 is all wrong [19:38:29 CEST] <BBB> so lets say that you load data in m0, right? [19:38:44 CEST] <durandal_1707> yes [19:38:55 CEST] <BBB> so 1/2/3 is now r000r000, g000g000 and b000b000 [19:39:07 CEST] <BBB> or, well, r[dword], g[dword] and b[dword] [19:39:41 CEST] <BBB> so dont you want to multiply r by an _array_ of ana_r[0], g by an _array_ of ana_r[1] and b by an _array_ of ana_r[2]? [19:40:16 CEST] <BBB> so, offsets are in byte, so do movd m8, [ana_matrix_rq+0], movd m9, [ana_matrix_rq+4] and movd m10, [ana_matrix_rq+8] [19:40:31 CEST] <BBB> and then splat them in the register so they cover the whole register size, not just the first bit [19:40:35 CEST] <BBB> pshufd m8, m8, q0000 [19:40:39 CEST] <BBB> pshufd m9, m9, q0000 [19:40:44 CEST] <BBB> and pshufd m10, m10, q0000 [19:41:08 CEST] <BBB> that changes m8=r[dword] into m8=r[dword],r[dword],r[dword],r[dword] [19:41:11 CEST] <BBB> in all 16 bytes of the register [19:41:15 CEST] <BBB> instead of just the first4 bytes [19:42:01 CEST] <rcombs> ubitux: brew's package doesn't install the .pc for whatever reason :/ [19:42:16 CEST] <ubitux> ah, that's unfortunate then [19:46:12 CEST] <durandal_1707> BBB: works! [19:46:35 CEST] <BBB> \o/ [19:46:40 CEST] <BBB> now try the same for g/b [20:02:40 CEST] <durandal_1707> if I want to shift to combine RGB what instruction to use? [20:20:32 CEST] <BBB> pshufb again [20:20:43 CEST] <BBB> you packuswb to get rrrr, gggg and bbbb [20:21:09 CEST] <BBB> you can combine them together by using packusdw red, blue and packusdw green, green [20:21:21 CEST] <BBB> and then packuswb red/blue, green [20:21:38 CEST] <BBB> and then pshufb to orient correctly from rrrrggggbbbb to rgbrgbrgb [20:29:59 CEST] <durandal_1707> BBB: I did it but its not bitexact, numbers are of by one or two [20:37:46 CEST] <durandal_1707> I think I need clamping and not saturation [20:42:17 CEST] <J_Darnley> what's the difference? [20:42:40 CEST] <J_Darnley> anyway see the CLIP* macros [20:43:35 CEST] <J_Darnley> durandal_1707 ^ [20:44:58 CEST] <BBB> durandal_1707: how are they different? [20:45:35 CEST] <BBB> durandal_1707: now comes the fun part - debugging assembly [20:45:37 CEST] <BBB> its quite fun [20:45:47 CEST] <BBB> durandal_1707: gdb, stepi, disass, breakpoint, etc. [20:45:49 CEST] <BBB> all your friends [20:45:59 CEST] <BBB> and info all-registers or print $xmm0 [20:46:00 CEST] <BBB> etc. [20:50:06 CEST] <durandal_1707> also when using threads md5 changes [20:50:07 CEST] <BBB> gtg, later [20:50:25 CEST] <BBB> you may have an overwrite because you write 16 bytes [20:50:28 CEST] <BBB> but only 12 bytes is useful [20:50:37 CEST] <BBB> maybe try movq+movd instead of movu, and a shift in between [20:50:41 CEST] <BBB> psrldq [20:50:44 CEST] <BBB> bye [20:57:22 CEST] <durandal_1707> that did it [20:58:26 CEST] <durandal_1707> Should I use stack instead of reading coeff over and over again? [21:03:49 CEST] <jamrial> you have 16 xmm regs available (assuming this is x86_64). don't you have any of them free to store the coeffs? [21:08:51 CEST] <durandal_1707> there are 18 coeffs [21:17:46 CEST] <durandal_1707> jamrial: perhaps one or two [21:18:19 CEST] <durandal_1707> but what to use for stack? [21:18:24 CEST] <kurosu> some insns accept memory operands (ie an address instead of a reg) [21:18:59 CEST] <kurosu> but this situation is unusual, so it might be related to how your algorithm lays out data [21:19:29 CEST] <kurosu> but then, I haven't seen it, and it's maybe completely normal [21:22:59 CEST] <kurosu> ok, ana_convert => normal [21:24:08 CEST] <kurosu> so, yes, if they are dynamic, maybe have an aligned buffer part of the dsp struct or something, where the dsp is free to put data, eg by calling a function specific to setting the coeffs according to the dsp expectations [21:25:09 CEST] <kurosu> ie pass ana_matrix_r,g,b to that func, it fills said buffer in the dsp, and call that dsp with the coeff buffer of the dsp struct instead of directlt ana_matrix_r/g/b [21:25:45 CEST] <RiCON> nevcairiel: Re: rtmpe: this works (?) -> http://sprunge.us/TYAK?diff [21:26:36 CEST] <nevcairiel> i guess [21:26:48 CEST] <nevcairiel> the check never accounted for having something else than openssl and gnutls [21:27:29 CEST] <RiCON> compiled and worked with at least one crunchy video [21:33:58 CEST] <nevcairiel> i cant test, i dont have gmp/gcrapt [21:34:02 CEST] <nevcairiel> -a+y [21:45:42 CEST] <cone-754> ffmpeg 03Paul B Mahol 07master:0c2b37fed43e: avfilter: add displace video filter [22:04:30 CEST] <J_Darnley> durandal_1707: I'm reading through the stereo filter patch you sent [22:28:36 CEST] <kurosu> durandal_1707, do you absolutely need int and 16 bits of precision in your coeffs? because you could get down to 15, and be able to use pmaddwd (16bx16b + 16bx16b -> 32b) [22:29:30 CEST] <kurosu> that'd make the asm ok on sse2, and allow twice more computations per insn [22:30:16 CEST] <kurosu> then again, the movd+pshud seems like a pity, it would be so much better if the tables were unrolled [22:32:11 CEST] <kurosu> it really seems like you should pass the output format (ANAGLYPH_*) as a parameter [22:32:47 CEST] <kurosu> then have the asm sets the proper address in its own arrays from it [22:33:29 CEST] <kurosu> like table + (array size for a mode) * mode [22:36:56 CEST] <durandal_1707> kurosu: own arrays? [22:51:30 CEST] <J_Darnley> Is there a spec or reference with decimal values for the coefficients? [23:03:43 CEST] <durandal_1707> J_Darnley: just divide by 65536 [23:04:58 CEST] <durandal_1707> what gain would be storing shuffed coeffs on stack? [23:10:09 CEST] <cone-754> ffmpeg 03Michael Niedermayer 07master:46f3015f3525: avcodec/tta: Un-break build without threads [23:25:42 CEST] <cone-754> ffmpeg 03Rodger Combs 07master:854972b53dc7: libavformat/tls_securetransport: fix argument evalulation order UB [23:31:39 CEST] <durandal_1707> yasm supports >16 registers? [23:39:27 CEST] <durandal_1707> BBB: can't I use avx and its 32 registers? [23:39:39 CEST] <BBB> I believe avx512 has 32 regs [23:39:48 CEST] <BBB> avx only has 16 32byte registers (on 64bit) [23:45:59 CEST] <durandal_1707> I see no support for such in ffmpeg yet [23:47:26 CEST] <nevcairiel> no avx512 support yet, no [23:49:44 CEST] <BBB> your hardware doesnt support it anyway [23:49:46 CEST] <BBB> so its ok [23:50:35 CEST] <BBB> durandal_1707: and did some initial review of your patch - not bad, but lots can be improved, good job on a first try, thats a pretty tough function [23:50:46 CEST] <BBB> durandal_1707: btw do you like this type of work? [23:53:34 CEST] <durandal_1707> its nice to speed up code [23:57:08 CEST] <durandal_1707> it would make more sense to write gbrp simd in swscale [23:58:01 CEST] <BtbN> I wonder if OpenCL would make sense for some stuff in swscale [23:58:11 CEST] <nevcairiel> go away =P [23:58:37 CEST] <nevcairiel> swscale would need a cleaner architecture so you could plug scalers in more easily [23:58:55 CEST] <BtbN> easy, just put every conversion into lavf! [00:00:00 CEST] --- Mon Oct 5 2015

1 0

ffmpeg.log.20151004
by burek 05 Oct '15

05 Oct '15

[00:37:29 CEST] <p8r> Hi, playing a stream with ffplay I do get audio dropouts and the message "ALSA lib pcm.c:7905:(snd_pcm_recover) underrun occurred". Can I raise ffplay's audio playback buffer or is there other ways of working around it? [00:48:58 CEST] <klaxa> alsa underruns are something i never got fixed [00:49:12 CEST] <BtbN> foreverska, could you pastebin the output of nvidia-smi? [00:49:42 CEST] <BtbN> nvenc is entirely X independend. It also works headless. Only the nvidia module has to be loaded. [00:50:48 CEST] <foreverska> http://pastebin.com/kwz5PWuY [00:52:11 CEST] <maduro> hi all, I can't seem to get ffmpeg above ~15% cpu usage (on a 40 core/160gb EC2 instance) when transcoding prores to x264 - all cores are used, but they sit at ~15% usage, with one much higher - where's the bottleneck? [00:52:14 CEST] <BtbN> Looks fine, should just work. [00:52:51 CEST] <BtbN> Could you also paste your ffmpeg commandline and and output(With -v verbose)? [00:54:39 CEST] <foreverska> http://pastebin.com/pA30ABvQ [00:56:14 CEST] <c_14> maduro: pastebin your commandline and output [00:56:50 CEST] <dekcuf> maduro: did you compile yasm? [01:00:41 CEST] <maduro> http://pastebin.com/LSZguVcu - i terminated it early since it's a ~52 min run [01:00:50 CEST] <foreverska> Based on it's blurb about my cards I'm finding posts from last year saying GeForce isn't supported in linux, that's not still true is it BtbN [01:01:04 CEST] <maduro> dekcuf: i installed the binaries from the debian-multimedia repo [01:07:32 CEST] <c_14> maduro: it's probably the scale fliter, iirc it doesn't thread well [01:08:17 CEST] <maduro> c_14: i see, is there anything that can be done about it? [01:10:19 CEST] <BtbN> foreverska, hm? Everything that's Kepler or newer works. [01:10:34 CEST] <BtbN> There are a few exceptions, but Desktop GTX cards aren't. [01:11:05 CEST] <c_14> maduro: Besides rewriting the filter api/code so it threads better? Cutting the input files into chunks, running separate ffmpeg processes and then concatting them. [01:12:53 CEST] <maduro> c_14: would it be possible to do that one (long-ass) line, using -map, -filter_complex, and multiple inputs/outputs? [01:13:09 CEST] <maduro> do that one/do that in one [01:14:06 CEST] <BtbN> foreverska, [ GPU #0 - < GeForce GTX 660 > has Compute SM 3.0, NVENC Not Available ] [01:14:14 CEST] <BtbN> NVENC is available starting from SM 3.5 Cards. [01:14:20 CEST] <BtbN> So your card actualy does not support it. [01:14:37 CEST] <BtbN> Missed that paste, sorry [01:14:50 CEST] <foreverska> Oh... that's disappointing. [01:16:18 CEST] <c_14> maduro: No, you'd need n ffmpeg processes processing n chunks and then one process at the end that combines them [01:16:35 CEST] <maduro> c_14: ok, ty [01:17:15 CEST] <foreverska> well what is this libmfx thing I need then? Maybe I can get my processor's gpu to take up the good fight [01:22:24 CEST] <BtbN> That stuff was painfull the last time i tried it. You have to patch your kernel and stuff [02:50:22 CEST] <DHE> maksbotan: that HLS error has been fixed and committed to the git version of ffmpeg [02:51:33 CEST] <fred1807> canI get the direct link to this audio stream? http://www.bbc.co.uk/radio/player/bbc_6music [04:12:03 CEST] <Matviy> I'm using ffmpeg to convert x264 to x265, is there a way to force the encoding process to always convert at a specific framerate, and dynamically adjust the other paramaters to achive that framerate? [04:13:00 CEST] <Matviy> Like, if the CPU is free, it will use a lower preset to achive a lower KBPS, at 30fps. But if CPU utilization is high, it will raise the preset, higher kbps, but still 30fps [04:20:39 CEST] <c_14> no [05:41:14 CEST] <pinPoint> sounds like some coding is needed for that to work [06:47:53 CEST] <Matviy> I'm trying to encode with VP9, and it's going at ~5fps using <10% of my CPU. Is this normal? I can't seem to find a way to speed it up [06:49:21 CEST] <Matviy> I read some forum posts that suggest splitting my video into NUMBER_OF_CORES pieces, and running parallel instances of ffmpeg, wtf... [06:49:33 CEST] <pinPoint> heh [06:49:49 CEST] <pinPoint> just curious, what is teh code you parse? [06:50:25 CEST] <Matviy> Code? [06:51:19 CEST] <pinPoint> ffmpeg command line [06:54:51 CEST] <Matviy> ffmpeg.exe -i C:\original.mp4 -c:v libvpx-vp9 -minrate 750K -maxrate 750K -b:v 750K -c:a libvorbis -threads 36 output.webm [06:55:15 CEST] <Matviy> (I do have 36 cores) [06:56:00 CEST] <Matviy> h265 encodes at ~150fps ~30% cpu usage, vp9 goes at like 5fps 5% usage [06:56:37 CEST] <pinPoint> what about using libvpx and take out -threads 36 [06:57:23 CEST] <c_14> libvpx is vp8, not vp9 [06:57:43 CEST] <pinPoint> ok take threads 36 out then [06:57:56 CEST] <c_14> Also, I think you need to set -tile-columns to something for multithreaded encoding with libvpx-vp9 [06:59:04 CEST] <Matviy> removing the threads makes it slower by half [06:59:06 CEST] <YaMoonSun> ffmpeg -i "Original.mp4" -c:v libvpx-vp9 -b:v 650k -c:v libvorbis -b:a 128k "Output.webm" [07:03:42 CEST] <YaMoonSun> Pretty sure that VP8 and VP9 encoding only utilize once core when encoding, and there's a difference between threads and cores I believe. [07:06:23 CEST] <c_14> The vp9 encoder has threading support. It's not very good, but it's there. [07:06:59 CEST] <Matviy> Tried setting the -title-columns, doesn't make a difference. CPU usage caps at 10% no matter what [07:07:21 CEST] <c_14> Like I said, it's not very good. [07:07:51 CEST] <Matviy> :( Would that be an issue with all vp9 encoders everywhere? Or just ffmpeg? [07:07:57 CEST] <Matviy> I'm guessing they all use the same SDK [07:08:02 CEST] <c_14> There is only one vp9 encoder (afaik) [07:08:37 CEST] <YaMoonSun> Should see how many threads each core has and then reassign the number of threads you're using. [07:08:57 CEST] <c_14> That doesn't make sense. [07:09:18 CEST] <c_14> Unless you're talking about Hyperthreading, in which case it doesn't matter (mostly). [07:09:24 CEST] <YaMoonSun> Not much in life does, but we make it work anyways. [07:09:42 CEST] <Matviy> How is google trying to push vp9 without good multi-threading support [07:09:44 CEST] <Matviy> i dont even [07:09:59 CEST] <pinPoint> not for long... with Open Alliance in the way [07:10:01 CEST] <c_14> Matviy: google doesn't want you to encode vp9. They just want you able to watch vp9 on youtube. [07:10:18 CEST] <pinPoint> I can try vp9 on my side. got a 6core cpu I can test against on the hackintosh [07:10:29 CEST] <YaMoonSun> They're allowing vp9 on youtube now? I thought they only take x264 and libvpx? [07:10:44 CEST] <Matviy> I want to upload VP9 because i pay .09 per GB. I can save 50% by using HEVC/VP9, but youtube doesn't allow h265 upload [07:10:50 CEST] <pinPoint> v10 is already in the way no? [07:11:04 CEST] <pinPoint> you give them a file and they make many versions of it including v9 [07:11:20 CEST] <YaMoonSun> Resolution? [07:11:40 CEST] <pinPoint> I have seen 2700p [07:12:48 CEST] <YaMoonSun> Ah, was directed @ Matviy [07:12:51 CEST] <YaMoonSun> 2700p, lol, shit [07:12:57 CEST] <YaMoonSun> Excuse my language [07:13:23 CEST] <Matviy> 720p is what I'm uploading. [07:17:39 CEST] <YaMoonSun> Ah, well damn dude, how long is the media file? [07:17:40 CEST] <pinPoint> yeah, I'm watching a vp9 sampe go at fps 4 at best. The cpu is barely cranking... my fans are low [07:17:47 CEST] <pinPoint> sample* [07:20:39 CEST] <YaMoonSun> I'd upload it using vp8 @ 1600k [07:20:49 CEST] <YaMoonSun> .09 isn't that much [07:21:11 CEST] <pinPoint> or mp4/h264 and high bitrate, let google its nonsense in the background [07:21:23 CEST] <pinPoint> let google do its* [07:21:32 CEST] <YaMoonSun> It's not nonesense =/ [07:22:33 CEST] <Matviy> @pinPoint, Seems like the correct solution really is to split the file and run multipe encoding processes, lol [07:26:12 CEST] <YaMoonSun> Doesn't -threads 0 give you the max? [07:26:44 CEST] <pinPoint> mine does not. :/ [07:27:01 CEST] <YaMoonSun> Huh, maybe I should try things before I type them =p [07:27:28 CEST] <pinPoint> i think libvpx/vpx-v9 is just slow for now. [07:29:01 CEST] <YaMoonSun> Yeah, it maxed out one core for me. [07:29:41 CEST] <YaMoonSun> I just got it to use three cores =0 [07:30:07 CEST] <YaMoonSun> Should check speccy or what have you to see how many threads your CPU has. [07:30:35 CEST] <Matviy> On intel, Threads = (physical cores * 2) [07:31:00 CEST] <YaMoonSun> You're using what processor? [07:31:24 CEST] <YaMoonSun> I did -threads 4 and I got it up to 85% CPU vs 25% [07:32:01 CEST] <Matviy> I'm using the c4 AWS instance, which has 36 vCPU's [07:32:14 CEST] <Matviy> Intel Xeon E5-2666 v3 (Haswell) [07:32:27 CEST] <Matviy> There isn't a spec page for it on intel because it's a custom processor made for AWS [07:32:50 CEST] <YaMoonSun> I don't think ffmpeg was written with that processor in mind, but could be wrong. [07:53:06 CEST] <TD-Linux> Matviy, indeed you need -tile-columns in order to get parallel encoding [07:53:23 CEST] <TD-Linux> (or split up your video into segments. this is what youtube does internally) [08:01:40 CEST] <Matviy> @TD-Linux, may i ask how you know about Youtube? :D [08:02:16 CEST] <pinPoint> the boss [08:02:18 CEST] <pinPoint> :) [08:06:29 CEST] <pinPoint> c_14: would you say prores and prores_aw are the same? [08:08:46 CEST] <TD-Linux> Matviy, it's obvious if you look at their dash encodes [08:08:58 CEST] <pinPoint> youtube-dl [08:10:46 CEST] <pinPoint> Matviy: http://pastebin.com/Z1Eery8F TD-Linux [08:48:17 CEST] <Matviy> I'm so confused [08:48:53 CEST] <Matviy> Using normal paramaters, i get 10% CPU usage, 850kbps, and the conversion speed is ~25fps. Great [08:49:12 CEST] <Matviy> If i set "-quality realtime" [08:49:23 CEST] <Matviy> I'm suddenly converting at 200FPS [08:49:28 CEST] <Matviy> Still 10% CPU usage [08:49:39 CEST] <Matviy> Still 850kbps (i deliberatly chose 850) [08:49:44 CEST] <Matviy> Same file size [08:50:20 CEST] <Matviy> That doesn't make sense. If the quality is lower, why is the rate still 850kbps. What is all that extra data? [08:50:35 CEST] <Matviy> If the quality is the same, how am i converting at 8x the speed with the same CPU usage [08:51:33 CEST] <TD-Linux> so encoding faster changes the quality per bit [08:52:06 CEST] <TD-Linux> realtime changes VP9's deadline to go really fast. it doesn't control bitrate or target quality [08:53:16 CEST] <Matviy> Would using realtime decrease the quality? [08:54:02 CEST] <TD-Linux> yes. if you're getting the same bitrate, then the quality is worse [08:56:06 CEST] <TD-Linux> rather than using -quality realtime, you can use -cpu-used (-speed in ffmpeg?) to set a performance level between 0 and 7 [08:56:21 CEST] <TD-Linux> there was a comparison done recently on the effect on quality: https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecoding-performance… [09:03:14 CEST] <Matviy> Thanks TD, i think my issue is that i can't get it to use more than 1 CPU [09:03:34 CEST] <Matviy> I thought "-cpu-used" was my ticket to success, apparently not. [09:11:30 CEST] <xerox> (also asked on #x264 because I think I'm using *that* wrong, but) what am I doing wrong? http://pastebin.com/raw.php?i=kSMQ7XM2 [09:12:04 CEST] <YaMoonSun> Can I use ffmpeg to export every frame in my video as a .jpg? [09:12:13 CEST] <xerox> YaMoonSun: yeah I think so [09:13:51 CEST] <xerox> I wonder if it's enough to use the -r option with the inverse of the frame rate [09:15:27 CEST] <xerox> YaMoonSun: how about http://superuser.com/a/729351 maybe you don't even need the -r [09:20:21 CEST] <YaMoonSun> Currently using a scene filter via vlc to do it, when I ask for 1 jpg per frame it glitches and ruins all my photos. [10:36:56 CEST] <Skilly> is it desired that -scodec copy -acodec copy -vcodec copy doesn't keep the names of the streams it copies? [11:07:44 CEST] <anYc> Hi, I reencode an h264 stream into a MKV and avcodec_encode_video2 sometimes returns a packet with an I frame before a B frame with a lower PTS, e.g., I: PTS=5 DTS=1, B: PTS=4 DTS=2, P: PTS=6 DTS=3. Does someone have an idea what I might doing wrong or is this valid behavior? [11:07:49 CEST] <anYc> corresponding code and output: http://pastebin.com/rxqNWkyz [11:11:25 CEST] <anYc> (I also removed my code that overwrites the DTS after avcodec_encode_video2 but this doesn't change the imho odd behavior) [11:13:20 CEST] <anYc> I also checked that the the input frames are ordered by PTS before I give them to avcodec_encode_video2 [11:19:56 CEST] <ayusun> Hi, I have a doubt regarding license of ffmpeg. Can I ask it here? [11:33:24 CEST] <ayusun> anybody here? [12:17:40 CEST] <ayusun> hi [12:18:57 CEST] <durandal_1707> just ask [12:26:43 CEST] <ayusun> JavaCv uses apache license while FFMpeg uses GPL/LGPL license. So if I use JavaCv to build a program that uses FFMpeg wrapper, what sort of license will I be using(if I ever try to release that work) may be for commercial use? [12:27:42 CEST] <ayusun> If I use it for commercial purpose, do I have to make anything open sourced? [12:28:36 CEST] <ayusun> A page on FFMPEG says that https://www.ffmpeg.org/legal.html [12:29:26 CEST] <ayusun> that I have to do few things that are listed there, So do I have to do those things even If use JavaCv over FFMPEG? [12:35:55 CEST] <ayusun> The point 9 in the page of FFMpeg says that "Add "This software uses code of <a href=http://ffmpeg.org>FFmpeg</a> licensed under the <a href=http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html>LGPLv2.1</a> and its source can be downloaded <a href=link_to_your_sources>here</a>" to every page in your website where there is a download link to your application." [12:36:35 CEST] <ayusun> what if my application is a web application and has jsp page which deals with the video [12:37:02 CEST] <ayusun> and there is no download link of my application. Where and how will I write it? [12:58:36 CEST] <durandal_1707> You should provide source for ffmpeg you use [13:09:45 CEST] <sopparus> anyone with an amd card who tried encoding with opencl? does it help performance? quality is not that important to me, only need speed [13:10:30 CEST] <durandal_1707> there is no code for encoding with opencl [13:10:47 CEST] <durandal_1707> Only for filtering [13:16:19 CEST] <sopparus> ah ok, thanks [13:16:43 CEST] <sopparus> so no way I could use my amd card then? [13:19:18 CEST] <durandal_1707> there are hw encoders in ffmpeg [13:22:59 CEST] <sopparus> yeah, but intel only? [13:23:03 CEST] <sopparus> from what I can fin [13:23:03 CEST] <sopparus> d [13:23:09 CEST] <sopparus> possibly nvidia too [13:27:42 CEST] <Mavrik> You'll probably have to use something non-ffmpeg for AMD I guess. [18:31:00 CEST] <maksbotan> DHE: nice, thanks! [18:48:52 CEST] <iH2O> how can I replace the audio of a .flv file by a .mp3 file of the same duration [18:53:50 CEST] <Mavrik> pass both files as an input (-i twice), use "-c copy" as codec and then use "-map" parameter to map video track from flv and audio track from mp3 to output. [18:58:43 CEST] <iH2O> thank you [19:11:00 CEST] <Renari> Does anyone know if there's a way to make ffmpeg overlay frames in a gif to reduce file size? (all the things I've tried output all of each frame rather than the difference). [19:12:28 CEST] <YaMoonSun> Maybe add -framerate 1/3 at the beginning of the command, not absolutly possitive though [19:15:27 CEST] <Renari> I don't want to lower the frame count rather I want the gif to use mostly transparent pixels. [19:33:10 CEST] <Mavrik> Renari, you mean you want a proper intra-coded video format not GIF. [19:42:26 CEST] <Renari> Mavrik, thanks but it seems imagemagick supports what I want with it's optimizetransparency flag. [19:48:44 CEST] <Mavrik> Yeah, I'm rather sure ffmpeg doesn't. [19:48:51 CEST] <Mavrik> Also stop using GIFs for use-cases where you need a video format. [20:01:34 CEST] <wolfman2000> Afternoon. I am aware of the compilation guide on https://trac.ffmpeg.org/wiki/CompilationGuide/MSVC, but I feel it is outdated. Allegedly, FFmpeg should be compilable on visual studio due to snprintf working correctly. Is there an updated guide explaining how WITHOUT using ./configure && make which doesn't work by default with the normal command line? [20:03:41 CEST] <Mavrik> Uh. [20:03:57 CEST] <Mavrik> How would you compile it without configuring it first? [20:04:04 CEST] <wolfman2000> Mavrik: cmake [20:05:19 CEST] <Mavrik> Sadly that's not how it works. [20:05:40 CEST] <ln-> eww, cmake [20:07:14 CEST] <wolfman2000> ln-: I'm curious as to what your beef with cmake is, but we can take it off channel if necessary. For now, let's confirm something else. Mavrik: are you officially sure that no one could write their own configure script to generate an appropriate config.h file? cmake or otherwise? [20:07:54 CEST] <Mavrik> wolfman2000, the thing is, configure script from ffmpeg isn't an autotools standard script [20:08:09 CEST] <Mavrik> It's a rather horrible piece of bash and while, yes, someone could port it. [20:08:23 CEST] <Mavrik> It's significantly more work than just installing msys. [20:08:32 CEST] <Mavrik> It'll also keep breaking as git master is updated. [20:08:47 CEST] <wolfman2000> do not tempt me. ;) [20:09:20 CEST] <Mavrik> I guess you could generate config.h once with msys and commit it if you need it for automated compilation. [20:09:26 CEST] <Mavrik> Also. [20:09:29 CEST] Action: Mavrik slaps ln-. [20:09:50 CEST] <wolfman2000> alright, let's take a different approach instead. http://ffmpeg.zeranoe.com/builds/ The page I linked to contains a number of builds for ffmpeg. However, they are all GPL. Is there a similar website out there but with LGPL builds? [20:10:28 CEST] <JEEB> just use msys(2) or cygwin to configure and run make :P [20:10:51 CEST] <JEEB> not exactly rocket science and msys2 and cygwin both have package managers [20:11:03 CEST] <JEEB> also the lack of LGPL builds might be because usually only corporations want them [20:11:24 CEST] <JEEB> or people otherwise doing closed source stuff [20:11:24 CEST] <wolfman2000> JEEB: the (few) windows developers for a separate project like staying in visual studio. mingw support currently...doesn't work [20:11:47 CEST] <wolfman2000> also, said project wants to stay MIT compatible. GPL would...well, force GPL if I understand the licensing terms right [20:12:18 CEST] <JEEB> your source code would be still MIT, but the binary would become GPL. since MIT is compatible with GPL, that shouldn't be an issue [20:13:14 CEST] <JEEB> the sources of the combined package with GPL'd FFmpeg would become GPL, but your project in general would be MIT [20:13:27 CEST] <JEEB> the same thing happens with, say, ffms2 [20:13:52 CEST] <JEEB> where the thing itself is less limited but if built with a GPL FFmpeg the combined package should also be available as GPL [20:14:44 CEST] <JEEB> but to be honest, if you just want to build FFmpeg with MSVC just setting up the build system for that on one machine isn't too bad IMHO :P You don't need mingw to build it, you just need a shell and make [20:15:04 CEST] <JEEB> which will then run MSVC's compiler and linker [20:15:37 CEST] <wolfman2000> then let's make sure I'm not unintentionally breaking policy. Previously, we enabled GPL building for general distribution. Source code stays MIT, binaries were GPL, license files...slightly disorganized mess, but working on it. For taking the engine to, say, a commercial game, just build without --enable-gpl and --enable-nonfree and we're good. Any flaws in my thinking? [20:16:08 CEST] <JEEB> enable-nonfree in general means you can't distro it at all, so you can forget about that altogether [20:16:21 CEST] <wolfman2000> we don't have --enable-nonfree enabled normally [20:17:12 CEST] <JEEB> but yes, that is the general idea. the GPL-licensed package does not affect your general license. and the MIT license is GPL-compatible so it's possible to link it with GPL stuff. [20:17:30 CEST] <JEEB> so just have your sources available as both with the binary, and FFmpeg as with GPL. [20:17:40 CEST] <JEEB> and if someone builds it with LGPL FFmpeg then it will matter even less [20:18:09 CEST] <JEEB> not sure if I'm explaining it well, but basically even if a binary of yours ends up being GPL, your whole project isn't [20:18:42 CEST] <wolfman2000> source code is available on github. We state our code is MIT, all third party libraries we use are respective of their licenses. Trying to use submodules more, but that's in a test branch. [20:18:43 CEST] <JEEB> you still have to release sources for it under GPL, but that shouldn't be an issue I think? [20:18:47 CEST] <Mavrik> Maybe it's better to think in terms of what GPL says. [20:18:59 CEST] <JEEB> (for that binary, basically) [20:19:49 CEST] <wolfman2000> just explain the "so just have your sources available as both with the binary" part a little better and I should be good [20:19:55 CEST] <JEEB> https://github.com/FFMS/ffms2/blob/master/COPYING [20:19:59 CEST] <JEEB> something like this :P [20:20:42 CEST] <JEEB> wolfman2000: if you have a binary release with GPL FFmpeg, then the user who receives that has the right to get the source code for that binary release as per GPL [20:20:57 CEST] <JEEB> which is what is meant with "that release binary becomes GPL" [20:21:11 CEST] <JEEB> that doesn't change your general license of course [20:21:29 CEST] <JEEB> so if someone uses the library for closed source and LGPL FFmpeg is used, there is no issue with that [20:21:48 CEST] <JEEB> (of course the LGPL license has to be followed) [20:23:53 CEST] <wolfman2000> all users can get our source code on github. We do not make any patches to ffmpeg. [20:23:55 CEST] <JEEB> but really, building an LGPL FFmpeg shouldn't be that hard with the MSVC compiler/linker :) but yes, you will not get rid of the reason to configure with a shell interpreter and running the build with ye olde make :) [20:24:09 CEST] <JEEB> wolfman2000: whether or not you have patches doesn't matter [20:24:46 CEST] <JEEB> LGPL = sources for the LGPL thing exactly, and the capability of the user to switch the library should he or she want that [20:25:23 CEST] <JEEB> which basically means not much extra with shared linking and with static linking you'd have to share the object files [20:26:00 CEST] <wolfman2000> so binary GPL is fine, request for code is already handled as long as github doesn't break down, and.........there's an actual distinction with static vs sharing I'm not aware of, isn't there? [20:26:15 CEST] <JEEB> with GPL there really isn't [20:26:27 CEST] <JEEB> with LGPL you just have to follow the general idea of "letting the user replace binary" [20:26:35 CEST] <JEEB> which I noted there regarding static linking [20:26:44 CEST] <JEEB> which is why almost nobody does static linking with LGPL components [20:27:26 CEST] <wolfman2000> okay, there may be some things to improve on in the end. [20:28:51 CEST] <JEEB> but yeah, building with GPL FFmpeg makes the _binaries_ created there unusable in closed source or other cases where LGPL is required [20:29:03 CEST] <JEEB> otherwise it has no effect on your primary project [20:30:01 CEST] <wolfman2000> that was mostly what I wanted to confirm. as far as cmake vs bash configure......well, consider that a challenge for the future. :) [20:30:34 CEST] <JEEB> not sure how a cmake configuration would make anything simpler :/ [20:30:46 CEST] <JEEB> you would still have to run cmake in a command line and have the cmake tool available [20:31:04 CEST] <wolfman2000> JEEB: we already do require cmake. [20:31:08 CEST] <wolfman2000> even for windows [20:31:33 CEST] <JEEB> yes, but I just don't see it any different :P it's a requirement for FFmpeg's build system (whatever OS or compiler etc. you're building it with) [20:31:58 CEST] <JEEB> you can run configure and make from cmake if you really want to, which would then become things in your MSVS project or whatever [20:32:07 CEST] <wolfman2000> windows users can use the GUI, which means no terminal needed. You know not all windows developers care to use terminal commands. [20:32:37 CEST] <wolfman2000> some just love their Visual Studio too much [20:33:03 CEST] <JEEB> well, as I said nothing stops you from calling those binaries and you can have other ways of making sure they have those [20:33:06 CEST] <JEEB> also you need yasm [20:33:11 CEST] <JEEB> for the hand-written assembly [20:33:38 CEST] <wolfman2000> JEEB: --disable-asm is available. ;) [20:33:46 CEST] <JEEB> you really don't want to use it lol [20:33:55 CEST] <JEEB> esp. on x86(_64) [20:34:01 CEST] <JEEB> it really kills your performance in a lot of places [20:34:15 CEST] <wolfman2000> I never tested it. I currently require yasm or nasm to be available before building ffmpeg with my project. [20:34:18 CEST] <JEEB> on ARM it *might* be less of an issue since there's just less asm [20:34:34 CEST] <JEEB> but in general it's never good idea to disable it [20:35:11 CEST] <JEEB> anyways, if you're going to do it with cmake I recommend you just wrap FFmpeg's build system with it rather than make a new one. the new one's bound to fail at some point :P [20:35:24 CEST] <JEEB> just make it make sure that the user has specific binaries available in PATH and that should be it [20:35:39 CEST] <wolfman2000> again, trying to not require windows users to need msys [20:36:05 CEST] <JEEB> you literally need a couple of binaries and you need cmake and yasm already :P [20:36:22 CEST] <JEEB> you are definitely not winning much by trying to play around FFmpeg's build system [20:36:51 CEST] <JEEB> or well, playing around it is more or less OK, but in the way where you use it underneath [20:37:05 CEST] <JEEB> I know you can do it with cmake because lachs0r does his cross-compilation of mpv with cmake :P [20:37:22 CEST] <wolfman2000> Remind me to have a meeting with him then [20:37:25 CEST] <JEEB> which basically builds everything required with their original build systems underneath [20:38:00 CEST] <JEEB> and if you really want to have them be lazy you could even automate download of the shell interpreter, make and yasm from the cmake script :P [20:38:28 CEST] <wolfman2000> lazy is one thing. invasive is another. :P [20:39:21 CEST] <JEEB> basically my bottom line is that you really don't want to replace FFmpeg's build system since that's going to kill you real quickly regarding compatibility. but you *can* wrap it. [20:39:38 CEST] <JEEB> and that should be less breaking [20:40:28 CEST] <wolfman2000> ...alright. Guess what I have to figure out then is how to get configure scripts to work in mingw without cmake errors. [20:44:40 CEST] <JEEB> looking at lachs0r's thing he seems to at least be utilizing a module called ExternalProject [20:44:57 CEST] <JEEB> you can poke him more on #mpv if you want to [20:45:02 CEST] <JEEB> https://github.com/lachs0r/mpv-build-cmake/blob/master/CMakeLists.txt [20:45:57 CEST] <wolfman2000> JEEB: I'm familiar with externalproject_add. What was throwing me off was HOW to run it cleanly with......huh? I don't recognize the ${EXEC} command. [20:47:07 CEST] <wolfman2000> but if it does what I think it does, that may have solved some of my issues. [20:52:10 CEST] <wolfman2000> ...okay, maybe not. I'll figure something [21:14:59 CEST] <foreverska> Anyone have experience with AMD's encoder? [21:20:05 CEST] <foreverska> Also edge case solution: Has anyone ever paired a GTX card with an A10 processor and used both NVENC and VCE at the same time? [22:08:28 CEST] <IRCMonkey> Hello, is there a way for ffmpeg to output a warning if frames are dropping during a stream? [22:49:10 CEST] <YaMoonSun> Is there an issue extracting jpeg images from .mkv files? I made a bat file that says ffmpeg -i "Where are you.mkv" -r 30 "Where Are You Now"-%4d.jpeg and it outputs one image. [22:49:53 CEST] <c_14> Does it output -0000.jpeg ? -%4d.jpeg? [22:49:56 CEST] <klaxa> hmm... does %4d work? [22:50:08 CEST] <klaxa> i always use it as %04d [22:50:21 CEST] <c_14> ^I think you have to [22:50:25 CEST] <YaMoonSun> Yeah, it worked last night on some lightning storm videos. [22:50:32 CEST] <YaMoonSun> They were in .mov though [22:51:57 CEST] <YaMoonSun> http://pastebin.com/89JsbdhZ [22:52:27 CEST] <c_14> There's no % [22:52:46 CEST] <YaMoonSun> There is in the .bat [22:52:57 CEST] <c_14> There isn't in that line [22:53:19 CEST] <YaMoonSun> So I have to do it manually because the .bat file is being a.. lousy. [22:53:21 CEST] <YaMoonSun> Thanks [22:53:24 CEST] <YaMoonSun> Smh [22:53:32 CEST] <c_14> Might need to escape the '%' in bat files [22:53:34 CEST] <c_14> *shrug* [22:54:23 CEST] <YaMoonSun> Worked via cmd without a .bat [22:54:25 CEST] <YaMoonSun> So weird. [22:57:37 CEST] <YaMoonSun> Some really awesome fan art in that video, nice to actually be able to see it (y) [00:00:00 CEST] --- Mon Oct 5 2015

1 0

ffmpeg-devel.log.20151003
by burek 04 Oct '15

04 Oct '15

[01:14:12 CEST] <J_Darnley> When gcc is calculating the "arguments" to an asm block, does it follow the standard array rules? [01:15:04 CEST] <J_Darnley> As in: A is defined to be an array of int16_t [01:15:19 CEST] <Compn> DHE : bleh , that code is all hard to read :P [01:15:32 CEST] <Compn> not your patch, but the file [01:15:33 CEST] <J_Darnley> A + 32 would be the start plus 64 bytes, right? [01:17:40 CEST] <DHE> Compn: I give my patch the WorksForMe rating. but I didn't test it with the subtitles as I don't have any [01:24:30 CEST] <J_Darnley> Of course it does. Why would it do anything else. [01:28:23 CEST] <Compn> DHE : you moved the av_freep inside a bracket, i assume this move is correct but .... worries me (i am not a programmer as well) [01:35:08 CEST] <DHE> Compn: I pulled the malloc in as well. The alternative was to allocate memory that might go unused and that seemed silly [01:35:40 CEST] <DHE> allocation was in the first hunk [01:41:02 CEST] <J_Darnley> 2 inline uses of constants down... [02:02:22 CEST] <BBB> Gramner: is pinsrw slower than movd? [02:07:46 CEST] <atomnuker> I give up, there [02:07:59 CEST] <atomnuker> is no way to get matched up samples [02:08:46 CEST] <BBB> what are you trying to do? [02:08:57 CEST] <atomnuker> measure SSIM of two audio streams in lavfi [02:09:26 CEST] <atomnuker> problem is there's no way to get them matched up well enough [02:10:58 CEST] <atomnuker> so I'm thinking I might have to resort to actually using lavc to decode the streams and then try to match them up [02:11:57 CEST] <durandal_1707> match up means what? [02:12:13 CEST] <atomnuker> time-wise [02:13:07 CEST] <atomnuker> you don't want to have one stream delayed by some tens of miliseconds because then you can only measure long term harmonic content at best [02:14:21 CEST] <atomnuker> just mixing the streams using amix will result in an echo, and that echo is different for each encoder (aac, opus, mp3) [02:14:34 CEST] <BBB> lol [02:14:38 CEST] <BBB> that is so hard [02:14:42 CEST] <durandal_1707> you mean shift one stream by some numbers of samples? [02:14:58 CEST] <BBB> Im surprised theres no scripts to help you do that [02:14:59 CEST] <BBB> or filters [02:15:05 CEST] <BBB> also, ssim & hm ... [02:15:12 CEST] <BBB> I didnt know you could use that for audio [02:15:40 CEST] <atomnuker> that's the easy part, as long as they're matched up I'm getting nice results [02:16:01 CEST] <atomnuker> I should try decoding them to wavs and using audacity to match them up [02:17:14 CEST] <durandal_1707> huh what audacity uses for matching up? [02:17:37 CEST] <atomnuker> nothing, you have to do that manually [02:18:08 CEST] <durandal_1707> with what? [02:18:13 CEST] <atomnuker> seek to the nearest non-zero sample and cut off anything before [02:18:37 CEST] <BBB> cant you just use various offsets and use the one with max ssim? [02:18:42 CEST] <BBB> like a motion search [02:19:06 CEST] <atomnuker> shit, I totally forgot I could just use the same thing AAC-LTP uses [02:19:27 CEST] <DHE> Compn: any other concerns? [02:20:35 CEST] <jamrial> BBB: for position 0 it most likely is slower [02:22:12 CEST] <durandal_1707> atomnuker: don't kill the code, I want to use it :) [02:25:44 CEST] <atomnuker> not poisoning anything, just a small static autocorrelation function is all that's needed to get the offset :) [02:34:53 CEST] <TD-Linux> atomnuker, you're trying to use SSIM on audio? [02:36:21 CEST] <TD-Linux> your results will be 100% nonsensical anyway [02:39:58 CEST] <atomnuker> huh, why? [02:41:21 CEST] <atomnuker> TD-Linux: http://www.researchgate.net/publication/4333525_Audio_quality_assessment_us… [02:41:45 CEST] <atomnuker> seems to follow subjective results well enough to be more useful than PSNR [02:43:37 CEST] <TD-Linux> atomnuker, ugh, SSIM has weights that are tuned from image perception [02:43:58 CEST] <TD-Linux> it might do better than PSNR but that's just totally random chance (PSNR is also nearly useless for audio quality comparison) [02:44:02 CEST] <TD-Linux> PEAQ is a lot better [02:45:26 CEST] <TD-Linux> ah I see they at least retrained it in that paper, but still no comparison to PEAQ? [02:48:17 CEST] <atomnuker> you know, screw this, I'm making my own metric [02:49:14 CEST] <atomnuker> I'll dig up some stuff I did using libfftw3 [02:50:55 CEST] <atomnuker> I guess finding the peaks of well matched up frames and measuring the difference in the noise around them should be a good metric [02:52:31 CEST] <TD-Linux> atomnuker, how much science are you after? you might want to ask jmspeex [02:54:01 CEST] <durandal_1707> autocorrelation should be easily done with lavc fft [02:57:25 CEST] <atomnuker> TD-Linux: enough science to be good enough to tell 320kbps vs 50kbps mp3 would be good enough as a starting point [02:57:52 CEST] <atomnuker> since the peaks especially around the mid frequencies are the last thing to go they're a good reference point [02:59:02 CEST] <atomnuker> It sounds logical to me at 2 am, surely it'll work [03:00:14 CEST] <TD-Linux> yeah, I guess? or you could instead download afsp with pqevalaudio from ftp://ftp.tnt.uni-hannover.de/pub/audio/AFsp/ [03:00:47 CEST] <TD-Linux> (warning: nonfree software) [03:11:12 CEST] <atomnuker> TD-Linux: just tested that [03:11:30 CEST] <atomnuker> for one it's barely sensitive enough to detect 128kbps vs 530kbps aac [03:11:54 CEST] <TD-Linux> that's because there's little audible difference [03:12:18 CEST] <atomnuker> for two it's showing that 20kbps file actually has a higher score than a 40kbps file [03:12:26 CEST] <atomnuker> and believe me the difference is day and night [03:12:37 CEST] <TD-Linux> well yeah that's true. [03:13:00 CEST] <TD-Linux> good luck on your better metric :) there is a reason that people don't use objective tests much in audio [03:13:14 CEST] <TD-Linux> opus was developed mostly only with listening tests [03:19:43 CEST] <atomnuker> TD-Linux: yeah, it's probably better to let loose some ABX crazies to tune encoders [03:20:32 CEST] <atomnuker> they'll never accept a machine which can detect warm analogue tube sound anyway [03:21:49 CEST] <TD-Linux> I'm failing to parse what you're trying to say there [03:24:25 CEST] <Compn> DHE : nope! :) [03:24:50 CEST] <Compn> curious what the /0 filename stuff is about [03:24:56 CEST] <Compn> i know p is set to /0 [03:24:59 CEST] <Compn> but uhh [03:25:05 CEST] <Compn> no clue. it baffles me [03:25:14 CEST] Action: Compn plays games instead of learning c [04:06:09 CEST] <BBB> atomnuker: just write a script that automatically posts to hydrogenaudio and parses comments [04:06:25 CEST] <BBB> atomnuker: maybe a little higher latnecy than what youre used to, but ... [04:32:25 CEST] <rcombs> atomnuker: if removing silence at the beginning is good enough, you could try lavfi's silenceremove filter? [09:33:17 CEST] <cone-286> ffmpeg 03Vicente Olivert Riera 07master:3f1f6053013d: configure: address a copy-paste typo [09:33:17 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:59b55619b6ed: Merge commit '3f1f6053013d0015e9f115a91a11744807649a07' [09:53:22 CEST] <cone-286> ffmpeg 03Vittorio Giovara 07master:1aa24df74c05: lavu: Deprecate AVFrame.error[] [09:53:23 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:5fa5e73e81f1: Merge commit '1aa24df74c052a73175c43e57d35b4835e537ec8' [11:57:54 CEST] <cone-286> ffmpeg 03Michael Niedermayer 07master:85c92789b604: avcodec/h264_ps: Fix copying oversized pps&sps data [12:20:58 CEST] <cone-286> ffmpeg 03Rodger Combs 07master:9825a24e5b1c: lavf/utils: avoid giving up probing early with long subtitle events [12:27:28 CEST] <cone-286> ffmpeg 03Vittorio Giovara 07master:9a3202a98b2e: Screenpresso SPV1 decoder [12:27:29 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:4d2160c99a00: Merge commit '9a3202a98b2e095b54dd784c3e01a09a676fc3fa' [12:32:44 CEST] <cone-286> ffmpeg 03Luca Barbato 07master:8ae1d87a2440: build: Add support for known custom allocators [12:32:45 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:98ca981a238c: Merge commit '8ae1d87a2440cea0564efe2a6c9c223478a05f44' [12:42:26 CEST] <cone-286> ffmpeg 03Alexandra Khirnova 07master:d0a3e89d41b0: dcadec: make a number of samples per subband per subsubframe a named constant [12:42:27 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:a11741c29393: Merge commit 'd0a3e89d41b05f9ed0e7401c352b60ed4f4d1ed5' [12:43:33 CEST] <cone-286> ffmpeg 03Luca Barbato 07master:74942685cb45: hls: Check av_opt_set_dict return value as well [12:43:34 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:4e67382d7298: Merge commit '74942685cb457c01937686892878403a409baf27' [12:43:51 CEST] <cone-286> ffmpeg 03Yu Xiaolei 07master:eb02387add35: x264: Expose the NV21 input support [12:43:52 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:f5af92edb921: Merge commit 'eb02387add350f2b34a3e61539fe25ec6213eb18' [12:46:07 CEST] <cone-286> ffmpeg 03Derek Buitenhuis 07master:380146924eca: x264: Add option to force IDR frames [12:46:08 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:cda503a1b92c: Merge commit '380146924ecad2e05e9dcc5c3c2e1b5ba47c51e8' [12:47:29 CEST] <cone-286> ffmpeg 03Joseph Artsimovich 07master:bfe1cd80ebea: dnxhddata: Fix 10-bit DNxHD quant matrices [12:47:30 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:ed11e8966c12: Merge commit 'bfe1cd80ebeab58cbc1c91ac766a96fce8e4ec1e' [12:47:40 CEST] <cone-286> ffmpeg 03Jeremy James 07master:cc320296ab43: dnxhddata: Fix cid 1260 luma and chroma tables [12:47:41 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:092d22ea755a: Merge commit 'cc320296ab438dfe3178f0e1f775af955fe6c064' [12:48:47 CEST] <cone-286> ffmpeg 03Jeremy James 07master:1fb63d6f43c3: dnxhddata: Deduplicate dnx100 tables [12:48:48 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:6411ac68865d: Merge commit '1fb63d6f43c348e9c990fa6f7c1bd43f22bc2389' [12:49:32 CEST] <cone-286> ffmpeg 03Christophe Gisquet 07master:e54d7e4e8ef7: dnxhddata: Deduplicate cid 1256 chroma table [12:49:33 CEST] <cone-286> ffmpeg 03Hendrik Leppkes 07master:6b849211bc2a: Merge commit 'e54d7e4e8ef7d778e2ddc5a60bf7307ed55d6333' [13:06:35 CEST] <cone-286> ffmpeg 03Rodger Combs 07master:14221b2dd913: lavf/hls: allow subtitles to be read despite incomplete handling [13:38:05 CEST] <durandal_1707> BBB: do you see way how to simd atadenoise code? [13:57:39 CEST] <BBB> hm... [13:58:01 CEST] <BBB> so atadenoise averages a pixel over multiple frames at the same source position up to a threshold of N pixel diff? [13:59:34 CEST] <BBB> yes that can be simded, its not exactly trivial but it can be done [14:00:37 CEST] <BBB> so the absdiff is quite simple, assume ssse3 for now, just punpcklbw with a zero, psubw to get diff, pabsw to get absdiff, pcmpgtw to get threshold [14:00:54 CEST] <BBB> and then mask against that before adding to sum (pandn) [14:01:10 CEST] <BBB> then the division is harder, look into FASTDIV on how to do multiply-directed divisions [14:01:28 CEST] <BBB> assuming r/l are low, you should be able to do something [14:04:36 CEST] <BBB> https://chromium.googlesource.com/webm/libvpx/+/master/vp8/encoder/temporal… is an example of how to do a division without using a / [14:04:40 CEST] <BBB> durandal_1707: ^^ [14:06:09 CEST] <durandal_1707> r+l+1 is lower than 256 [14:06:33 CEST] <durandal_1707> thanks [14:06:53 CEST] <BBB> ok, so this wont be the simplest simd ever, but I think you should have some starting points now :) [14:07:18 CEST] <BBB> so obviously you wouldnt do this per pixel over each buffer, rather youd do it per block or per line or so over each buffer [14:07:22 CEST] <BBB> since otherwise simd doesnt help [14:07:25 CEST] <BBB> but the rest is fairly easy [14:40:15 CEST] <cone-286> ffmpeg 03Ganesh Ajjanagadde 07master:0493e42eb2f9: avcodec/x86/hpeldsp_rnd_template: silence -Wunused-function on --disable-mmx [14:44:15 CEST] <BBB> so should some of these unused variable with e.g. pthreads disabled be placed under #if HAVE_THREADS? [14:44:18 CEST] <BBB> or is av_unused ok? [14:44:36 CEST] <nevcairiel> whatever seems better in the context [14:44:50 CEST] <nevcairiel> jsut adding ifdefs for a variable def seems overkill [14:45:02 CEST] <nevcairiel> but if you can move the var under an existing one, that might work [14:45:25 CEST] <BBB> I meant more for init_thread_context, update_thread_context in each codec [14:45:29 CEST] <BBB> theres usually a bunch of functions [14:45:41 CEST] <BBB> ganesh patches mark them as av_unused [14:45:47 CEST] <BBB> Im wondering if #if HAVE_THREADS is better [14:50:13 CEST] <nevcairiel> av_unused wouldnt catch a function that becomes truely unused [14:54:44 CEST] <cone-286> ffmpeg 03Michael Niedermayer 07master:de2f5316991e: configure: Change screenpresso_decoder to select zlib instead of dep [15:10:11 CEST] <cone-286> ffmpeg 03Henrik Gramner 07master:99982524f93a: checkasm: Remove use of deprecated av_set_cpu_flags_mask() [15:10:52 CEST] <BBB> what is -Waddress [15:11:01 CEST] <BBB> it sounds creepy [15:11:29 CEST] <Gramner> wad dress? [15:13:03 CEST] <BBB> oh Ive seen it, I actually thing its a sensible warning [15:32:21 CEST] <BBB> nevcairiel: so& ganesh commit? [16:05:26 CEST] <cone-286> ffmpeg 03Paul B Mahol 07master:13090895cf1c: avfilter/vf_tinterlace: add mergex2 mode [16:34:20 CEST] <cone-286> ffmpeg 03Carl Eugen Hoyos 07master:7c94cfa262ad: lavc/options_table: Add option flags to the truncated flag. [16:36:11 CEST] <cone-286> ffmpeg 03Carl Eugen Hoyos 07master:64508b9af240: configure: Remove --disable-avutil which has no effect from help output. [17:51:25 CEST] <cone-286> ffmpeg 03Ganesh Ajjanagadde 07master:8dc6e92c3dc6: ffplay: more robust mutex, condition variable handling [18:43:42 CEST] <kurosu> for some reason, I received from the ml "Message has implicit destination" when I ran git send-email (which uses gmail and msmtp) [18:44:10 CEST] <kurosu> anyone has an idea why that would happen? [18:44:37 CEST] <Daemon404> did you use bcc instead of to? [18:44:41 CEST] <Daemon404> thats the only time i've sen it [18:44:42 CEST] <Daemon404> seen* [18:47:04 CEST] <kurosu> git send-email decided that by itself [18:47:21 CEST] <kurosu> probably it failed at using the alias file I just created [18:47:35 CEST] <Daemon404> ah [18:47:39 CEST] <Daemon404> i always explicitly use --to [18:48:03 CEST] <kurosu> git send-email --to=ffmpeg out/ [18:48:20 CEST] <kurosu> alias file: "ffmpeg: ffmpeg-devel(a)ffmpeg.org" [18:48:28 CEST] <Daemon404> seems like bad behavior to silently fail or act weirdly [18:49:32 CEST] <kurosu> well, I've just setup that system in order to fix some stuff, but I made that from memory, so I might have failed with that setup, as it works @home [18:50:39 CEST] <Daemon404> all right-y [18:53:56 CEST] <kurosu> oh, that might be because I setup aliases for msmtp rather than git send-email [19:01:33 CEST] <kurosu> and now it seems to have replied to the old patch series mail [19:01:38 CEST] <kurosu> looks weird here [19:27:28 CEST] <cone-286> ffmpeg 03Ganesh Ajjanagadde 07master:254c64c574df: cmdutils: silence unused warnings under --disable-swscale, --disable-swresample [19:30:16 CEST] <kierank> bah, avdev box won't boot [19:30:21 CEST] <kierank> will have to look on monday [19:30:40 CEST] <durandal_1707> is there instruction to do paddw + psrlw at once? [19:32:52 CEST] <jamrial> durandal_1707: Gramner mentioned in a reply to your maskedmerge patch that pmulhrsw (ssse3 instruction) may be used for that [19:32:55 CEST] <Gramner> durandal_1707: pmulhrsw if the added value is equal to 1<<(shift-1) [19:33:42 CEST] <Gramner> pmulhrsw is "treat the sixteen-bit words in registers A and B as signed 15-bit fixed-point numbers between 1 and 1 and multiply them together with correct rounding." [19:34:26 CEST] <Gramner> so only works if you don't need more than 15 bit precision, but that's often enough [19:42:04 CEST] <durandal_1707> what to use to divide with 255? [19:42:35 CEST] <Gramner> 128. i have a table i wrote down some time ago, one sec [19:43:27 CEST] <Gramner> http://pastebin.com/rYJZWXtV [19:58:14 CEST] <durandal_1707> what to use to negate mm register? [19:59:00 CEST] <Gramner> pxor dst, dst; psubw dst, src [20:05:07 CEST] <jamrial> if you're using ssse3, you can probably use psign [20:06:33 CEST] <durandal_1707> is there instruction to divide by byte number? [20:07:40 CEST] <jamrial> and for sse2, if you don't have a free reg to clear with pxor as Gramner mentioned, pmullw src, [pw_m1] also works [20:21:25 CEST] <durandal_1707> I want to divide by 255, is this possible? [20:35:05 CEST] <BBB> durandal_1707: no [20:35:21 CEST] <BBB> durandal_1707: you have to convert it to fastdiv (*X>>16), which may not be exactly the same [20:41:56 CEST] <BBB> kierank: ah crpa [20:42:05 CEST] <BBB> I was getting used to it already :) [20:42:36 CEST] <kierank> bit annoying, it pings but port 22 is closed [20:43:12 CEST] <cone-286> ffmpeg 03Ronald S. Bultje 07master:db7786e8ffa2: vp9: sse2/ssse3/avx 16bpp loopfilter x86 simd. [20:43:13 CEST] <cone-286> ffmpeg 03Ronald S. Bultje 07master:26ece7a511f8: vp9: 16bpp tm/dc/h/v intra pred simd (mostly sse2) functions. [20:43:14 CEST] <cone-286> ffmpeg 03Ronald S. Bultje 07master:061b67fb50e2: vp9: 10/12bpp SIMD (sse2/ssse3/avx) for directional intra prediction. [20:43:16 CEST] <kierank> might have to setup kvm on it [20:46:06 CEST] <durandal_1707> BBB: what to use for: A < B ? X : Y; [20:48:11 CEST] <Gramner> in SIMD? maybe pcmpgtw; pand; pandn; por [20:48:44 CEST] <Gramner> don't think I ever did a conditional SIMD move, so there might be a better way [20:50:51 CEST] <Gramner> XOP and AVX-512 has vector cmov instructions [20:59:19 CEST] <jamrial> i wonder if intel NIHd XOP with their relevant AVX2 and AVX-512 intructions, or if it was all already planed when the former was announced [20:59:25 CEST] <jamrial> vector cmov, fused multiply-add, the new shift instructions [20:59:33 CEST] <jamrial> same purpose, different instructions [21:01:34 CEST] <jamrial> not like it matters much now. XOP is deprecated and will not be featured in Zen [21:27:43 CEST] <cone-286> ffmpeg 03Paul B Mahol 07master:9762554dd0e9: avfilter/vf_blend: add x86 SIMD for some modes [21:27:51 CEST] <Gramner> most likely part NIH, part the fact that instruction sets are planned many years before products using them before they're actually release, part the fact that amd and intel doesn't communicate ever (see the FMA3/4 clusterfuck for a concrete example of the latter) [21:29:08 CEST] <Gramner> also intel most likely don't give a fuck because they know amd has to adapt to them in the end anyway. amd64 was probably the only exception [21:29:40 CEST] <nevcairiel> amd64 was a different time, too [21:49:19 CEST] <cone-286> ffmpeg 03Carl Eugen Hoyos 07master:d89820002a7f: lavf/shortendec: Autodetect raw Shorten streams. [21:55:24 CEST] <BBB> pmovmskb can be helpful for early branch termination [21:56:14 CEST] <nevcairiel> isnt that one of those insstructions you should avoid [21:56:15 CEST] <BBB> durandal_1707: but as gramner said, pcmpgtw is typically your friend, and then indeed pand/pandn and por [21:56:31 CEST] <BBB> durandal_1707: or if its a conditional add, pcmpgtw, pand and then paddw [22:00:51 CEST] <iive> nevcairiel: i've heard it is quite slow on AMD [22:01:43 CEST] <cone-286> ffmpeg 03Michael Niedermayer 07master:fd9a528523d0: avfilter/vf_blend: Fix argument types, fix segfault in asm [22:01:44 CEST] <cone-286> ffmpeg 03Ganesh Ajjanagadde 07master:8d1226e623b2: configure: silence preprocessor noise from dependency generation [22:27:23 CEST] <cone-286> ffmpeg 03Paul B Mahol 07master:e306e43633a2: avfilter/vf_stereo3d: rewrite in preparation for SIMD [22:39:11 CEST] <durandal_1707> how to unpack bytes to ints? [22:39:48 CEST] <nevcairiel> dont think there is a 8->32 expansion, could use two steps 8->16->32 [22:42:29 CEST] <cone-286> ffmpeg 03Carl Eugen Hoyos 07master:32a6d37a6bbd: lavf/mlpdec: Simplify mlp/thd probe function. [22:44:40 CEST] <Gramner> pmov(s|z)xbd in SSE4 [22:47:34 CEST] <Gramner> what are you doing that requires 32-bit precision with 8-bit inputs? [22:48:12 CEST] <durandal_1707> anaglyph coefficients [23:10:50 CEST] <BBB> durandal_1707: if at all possible, try to reduce to 16bit if you can, shuffling is considered the most expensive and unnecessary part in most x86 sim [23:10:51 CEST] <BBB> d [23:12:48 CEST] <durandal_1707> how many are there mm registers? [23:13:27 CEST] <Gramner> 8 [23:14:57 CEST] <Gramner> 8 mmx registers. 8 xmm/ymm registers in x86-32, 16 xmm/ymm registers in x86-64 [23:15:39 CEST] <Gramner> and 32 xmm/ymm/zmm registers with AVX-512 (probably x86-64 only as well) [23:15:57 CEST] <J_Darnley> did x86-64 not also boost mmx to 16? (but why would you use them) [23:16:57 CEST] <durandal_1707> there are 18 anaglyph coefficients [23:17:18 CEST] <Gramner> no, mmx is considered legacy [23:17:39 CEST] <durandal_1707> perhaps better to do it in opencl [23:17:44 CEST] <Gramner> they were afaik considering dropping it in amd64 but ended up keeping it [23:18:02 CEST] <J_Darnley> ah [23:18:21 CEST] <kierank> durandal_1707: swscale has simd with more than that [23:18:22 CEST] <kierank> so it's doable [23:18:33 CEST] <Gramner> early pre-release 64-bit windows versions also banned the use of mmx iirc [23:18:36 CEST] <J_Darnley> it was probably a good thing keeping it back then [23:20:01 CEST] <Gramner> hoestly we would probably have been better off today if they had dropped it, but that would have made a lot of software slower initially when ported to 64-bit which would have made people less likely to upgrade so it's understandable that they kept it [23:20:40 CEST] <Gramner> the mmx instructions eat up a lot of valuable short opcodes [23:21:22 CEST] <Gramner> so x86 vector instructions are crazy long. instruction decoding uses tons of energy because of that [23:22:05 CEST] <cone-286> ffmpeg 03Ganesh Ajjanagadde 07master:c4c389aa146a: avcodec/apedec: fix bug introduced in commit d3e5fbb1406995e07fccbff3ca8c1e24f57a1f7b [23:22:23 CEST] <Gramner> there's also a whole bunch of useless 1-byte opcodes that nobody uses ever but need to be kept for backwards compatibility [23:23:41 CEST] <J_Darnley> I just barely remember programming back then. It was as if the cpuid function didn't exist. People didn't seem to create software with runtime function selection. [23:24:12 CEST] <J_Darnley> s/function/instruction/ [23:25:38 CEST] <wm4> haha this webm is generated by lavf [23:25:41 CEST] <wm4> cascasing failures [23:25:47 CEST] <wm4> *cascading [23:29:25 CEST] <J_Darnley> > TestClip\ webm.webm.webm [23:29:58 CEST] <J_Darnley> is that like file.zip.zip.zip? [23:31:54 CEST] <wm4> so I expect there will be a patch that specifically fixes demuxing of this file [23:32:04 CEST] <wm4> while it will continue not to work with other demuxers [23:32:20 CEST] <nevcairiel> should figure out the muxing problem first [23:33:50 CEST] <nevcairiel> interestingly seeking works fine in my demuxer [23:34:45 CEST] <wm4> nevcairiel: I wonder what it does [23:35:43 CEST] <nevcairiel> worst case, go to the earliest key frame it finds and decode from there [23:35:56 CEST] <wm4> ah [23:36:23 CEST] <wm4> that works for me too [23:36:43 CEST] <wm4> but it's a bit slow [23:37:16 CEST] <wm4> ah, the seek index is correct [23:37:19 CEST] <nevcairiel> on my high-end system its noticeable, but still only one second or so when seeking in the last third of the movie [23:37:41 CEST] <wm4> so the seek index for track 1 has only 1 entry [23:37:51 CEST] <wm4> all the other seek entries are for the subtitles [23:38:04 CEST] <wm4> (I wonder why there's no index for the audio track then) [23:38:26 CEST] <nevcairiel> thats normal [23:38:44 CEST] <jamrial> because nobody added it to the muxer [23:38:55 CEST] <nevcairiel> thats also how mkvmerge works, fwiw [23:39:00 CEST] <nevcairiel> videos of course get one, like normal [23:39:14 CEST] <nevcairiel> subtitles get an index to be able to find them more easily, since they can be rather sparse [23:39:18 CEST] <jamrial> yeah, afaik audio seekpoints are added on audio only files [23:39:26 CEST] <wm4> takes several seconds on my i5 skylake [23:39:32 CEST] <nevcairiel> this allows features like showing subtitles which started before the seekpoint [23:39:38 CEST] <wm4> are you sure you're decoding starting from the first packet? [23:40:08 CEST] <nevcairiel> dunno [23:40:12 CEST] <nevcairiel> would have to debug into the seeking [23:40:42 CEST] <nevcairiel> it goes to the closest Cue point, and then forward to the closest key frame [23:41:10 CEST] <nevcairiel> (closest cue before the requested seek) [23:42:37 CEST] <wm4> hm, also, what ffplay does (didn't test) suggests it just decides to decode starting from an arbitrary packet? [23:43:14 CEST] <wm4> can't reproduce though [23:46:56 CEST] <wm4> actually I can [23:51:46 CEST] <cone-286> ffmpeg 03Christophe Gisquet 07master:f827a170052e: blockdsp: reindent after parameter removal [23:51:47 CEST] <cone-286> ffmpeg 03DeHackEd 07master:e06114fed3af: libx264: copy A53 closed captions from source [00:00:00 CEST] --- Sun Oct 4 2015

1 0

ffmpeg.log.20151003
by burek 04 Oct '15

04 Oct '15

[00:07:11 CEST] <djems54> Hi, how best ffserver stream between two ffservers? The idea is to be able to multiply the number of ffserver to support a greater load [00:26:58 CEST] <pinPoint> do the projects from google summer of code get added into ffmpeg eventually? [00:27:11 CEST] <c_14> For the most part, yes. [00:29:14 CEST] <pinPoint> I had an idea couple weeks ago. I live in an area where over the air tv is not available via antenna. Maybe 2 channels. I was thinking of putting a computer in another city, 1hr away, with an antenna capturing channels and sending them over the internet. On my side I would use some sort of receiver to tap into the broadcast and watch tv. [00:30:11 CEST] <pinPoint> after seeing the project from S.O.C that is looking like what I've wanted to do [00:30:27 CEST] <c_14> Which project? [00:31:05 CEST] <pinPoint> the one on the front page of ffmpeg.org [00:32:29 CEST] <c_14> The network protocol one? [00:32:34 CEST] <pinPoint> ya [00:33:00 CEST] <c_14> Well, the single-client part works [00:33:08 CEST] <pinPoint> just don't know how one would change the channel remotely from far away. If the computer can see many channels [00:33:26 CEST] <pinPoint> it is a wild idea, like what Aereo had going. [00:33:31 CEST] <iive> there are other solutions that might work better [00:33:49 CEST] <pinPoint> yeah, there is a box that streams to the web. I saw it somewhere [00:34:15 CEST] <iive> check sat-ip , or the linux program tvheadend [00:37:43 CEST] <pinPoint> iive: how does sat-ip work exactly? [00:38:29 CEST] <iive> it's more like a protocol. i haven't used it, but i've heard about it. [00:38:35 CEST] <iive> check wikipedia [01:36:48 CEST] <pinPoint> according to https://ffmpeg.org/ffmpeg-codecs.html#ProRes there are 2 prores encoders. I thought there was three prores, prores_aw and prores_ks [01:37:32 CEST] <pinPoint> or is it because prores_aw is the same as prores that makes it two? [01:48:36 CEST] <c_14> I think prores is an alias of one of the others [03:07:23 CEST] <mertin2> Can someone help me with this? I'm trying to convert a bunch of [03:07:23 CEST] <mertin2> images to video. My files are named 0_img.png, 1_img.png, [03:07:23 CEST] <mertin2> 2_img.png, ... 99_img.png. I'm trying to follow the wiki tutorial [03:07:23 CEST] <mertin2> but I think the provided command doesn't like that some images are [03:07:25 CEST] <mertin2> 0_img.png instead of 000_img.png, for example. [03:08:47 CEST] <mertin2> The command I'm using is ffmpeg -framerate 1/5 -i %03d_img.png -c:v libx264 -r 30 -pix_fmt yuv420p out.mp4 [03:09:23 CEST] <c_14> You'll have to use glob, or rename the input files [03:11:26 CEST] <mertin2> hmm that gave me "'*.png': Invalid argument" [03:11:39 CEST] <c_14> Did you use -pattern_type glob ? [03:11:55 CEST] <c_14> Might have to add -f image2 [03:11:57 CEST] <mertin2> yes [03:12:01 CEST] <mertin2> ffmpeg -framerate 1 -pattern_type glob -i '*.png' -c:v libx264 -pix_fmt yuv420p out.mp4 [03:12:01 CEST] <drv> %d_img.png should work (instead of %03d) [03:12:12 CEST] <c_14> Oh, yeah. It should [03:12:30 CEST] <mertin2> yes, working! [03:12:36 CEST] <mertin2> can you explain why? [03:12:47 CEST] <c_14> %d? [03:12:48 CEST] <drv> the %03d means "format number with 3 digits, pad with 0s" [03:12:58 CEST] <drv> %d is just a plain number without any padding [03:13:31 CEST] <mertin2> what ensures that it prcoess the files in the desired order? 0,1,2,...,99 ? [03:14:44 CEST] <c_14> 9 + 1 = 10; 10 + 1 = 11 [03:14:46 CEST] <c_14> etc [03:15:57 CEST] <c_14> starts at 0 and increases until it can't find the next number anymore (unless you use -start_number in which case it starts there) [03:16:38 CEST] <mertin2> ok, thanks [03:31:15 CEST] <mertin2> if I want to extract an image for every frame in a video, I could follow the instructions for "Output one image for every I-frame"? [03:31:24 CEST] <mertin2> (I'm not sure what an I_frame is) [03:31:35 CEST] <c_14> ffmpeg -i video out%03d.png [03:31:37 CEST] <c_14> etc [03:32:43 CEST] <mertin2> ah, many more "Frames" than "I-frames" [03:40:18 CEST] <razzledazzle> hello guys, what filter might be necessary to process videos that have rotation metadata? also are filters required for decoding? [03:40:39 CEST] <c_14> If you use recent versions of ffmpeg, none. [03:41:07 CEST] <razzledazzle> I'm compiling a minimal ffmpeg binary [03:42:24 CEST] <razzledazzle> I've excluded a lot of filters and it works with regular videos, but the ones with the rotation side data echo error "error opening filters", I've tried the rotation filter which doesn't work, I'm not sure what is needed for this [03:43:20 CEST] <razzledazzle> now I've included all the filters and it works nicely, but I'd like to cut down on most of them [03:46:27 CEST] <c_14> It should just be the rotate filter. [03:51:16 CEST] <n0tmE> merlin, have you tried video filter? https://trac.ffmpeg.org/wiki/FilteringGuide, search for PICT_TYPE_I [03:51:30 CEST] <n0tmE> sorry, *mertin [03:57:21 CEST] <razzledazzle> c_14: I tried the rotate filter, it didn't work [04:01:19 CEST] <c_14> Ah, right. Duh. It also uses transpose, hflip and vflip depending on the angle. [04:01:47 CEST] <razzledazzle> I'll include them and try now :) [04:03:33 CEST] <razzledazzle> c_14: but the resulting video is in resolution 640x480, which when played gets rotated to 480x640, is the encoder really doing all that? [04:04:02 CEST] <c_14> hmm? [04:04:35 CEST] <razzledazzle> I'll do some pasting [04:08:39 CEST] <razzledazzle> c_14: I don't think its doing any rotation, http://pastie.org/private/pwaiji8ngzu76iqh0dik6g [04:09:57 CEST] <c_14> Right, because of the displaymatrix side data of -90 degrees [04:11:09 CEST] <razzledazzle> yes, I don't know why it needs filters at all [04:39:02 CEST] <razzledazzle> c_14: only needed transpose :D [04:39:16 CEST] <c_14> Because of the 90 degree angle, sure. [04:40:19 CEST] <razzledazzle> but why? rotation should only be the reponsibility of the player yes? even the encoder is not doing any kind of transformation [04:40:59 CEST] <c_14> Because nobody likes unrotated video. If you don't want ffmpeg to rotate the video add -noautorotate [04:42:43 CEST] <razzledazzle> it works as intended now, I'm only curious, that too does look like an option that might be needed someday [07:54:13 CEST] <spiderkeys> Hi all, I'm trying to wrap an H264 stream in an MP4 container and am trying to get as low a latency as possible. Right now, I'm seeing latencies of around 180ms using the following: http://pastebin.com/hYT7p5FX [07:54:28 CEST] <spiderkeys> Are there any obvious ways to improve the latency on the receiving end? [07:55:02 CEST] <spiderkeys> sorry, as the server doing the wrapping, not the receiving [09:54:05 CEST] <xerox> hi. original: http://pastebin.com/raw.php?i=V9r6aL7q my encode: http://pastebin.com/raw.php?i=cGufaNyp a number of questions: should I have the same ReFrames? why does GOP disappear? why does the frame rate change? should I use some option to get the same fps settings in the output? [11:18:20 CEST] <orione1> hi [11:23:07 CEST] <orione1> i'm trying to transcode avi files to mp4/webm and show them into html video tag during transcoding with no luck. Maybe the way is in this guide: https://trac.ffmpeg.org/wiki/StreamingGuide but i can understand how to put server response in html tag [11:26:48 CEST] <choki> Hi there, any chance I can create such video without definitions foreach image? http://superuser.com/questions/833232/create-video-with-5-images-with-fadei… [11:27:24 CEST] <choki> The reason is, I've lot of images and writing for each image a single filter seems to be wrong. [13:47:59 CEST] <ChocolateArmpits> Does anyone what is this in any greater detail ? http://aomedia.org [13:48:23 CEST] <ChocolateArmpits> >The initial project will pursue a new, open royalty-free video codec specification and open-source implementation based on the contributions of members [13:54:59 CEST] <iive> ChocolateArmpits: that's an old news: http://lwn.net/Articles/656288/ [14:00:26 CEST] <grublet> but we already have vp8/opus/webm [14:00:30 CEST] <grublet> why another [14:05:03 CEST] <ChocolateArmpits> iive: 2 days i hardly old [14:05:17 CEST] <iive> ChocolateArmpits: 2 days and one month [14:05:28 CEST] <RobotsOnDrugs> grublet: perhaps this https://imgs.xkcd.com/comics/standards.png [14:05:30 CEST] <ChocolateArmpits> iive: oh dog I live in the past [14:05:37 CEST] <iive> :P [14:05:38 CEST] <ChocolateArmpits> I forgot it's October already [14:05:57 CEST] <iive> yeh, september went out so quickly [14:07:22 CEST] <RobotsOnDrugs> lol the first comment on that lwn page has exactly what i thought of [14:22:02 CEST] <grublet> RobotsOnDrugs: that comic was precisely what i had in mind [14:22:55 CEST] <grublet> i guess free market capitalist ideaology applies to communal software as well [14:36:16 CEST] <girlz_baby> hi [14:36:32 CEST] <durandal_1707> hi [14:36:50 CEST] <girlz_baby> durandal r u a botm [17:52:53 CEST] <foreverska> I'm trying to compile with libnvenc but I get unknown option [18:07:42 CEST] <BtbN> There is no libnvenc. What are you actualy trying to do? [18:09:27 CEST] <foreverska> Enable Nvidia encoding for h264 [18:12:28 CEST] <BtbN> The configure option for that is --enable-nvenc, if that's what you have trouble with? [18:13:13 CEST] <foreverska> It seems to like that. Just have to finish linking the decklink API before I'll know for sure. [18:13:45 CEST] <BtbN> Could have just looked at --help [18:14:01 CEST] <foreverska> lol in my defense --help has a LOT of options [18:14:11 CEST] <BtbN> | grep nvenc [18:14:28 CEST] <foreverska> lol yea... [18:14:30 CEST] <BtbN> I think nvidia is also in the description [18:48:55 CEST] <foreverska> is qsv a decent boost compared to CPU? [19:39:47 CEST] <_0x5eb_> hi, is there a way to get the list of codec-specific options with ffmpeg executable? [19:41:26 CEST] <DHE> ffmpeh -h full # and go find the codec you want [19:41:32 CEST] <DHE> fix obvious typo [19:42:15 CEST] <_0x5eb_> DHE, great thanks a lot! [19:43:59 CEST] <_0x5eb_> so I guess that if a codec is no listed, there is no chance that it supports any private option, right? [19:44:08 CEST] <Mavrik> Well. [19:44:23 CEST] <Mavrik> Look at <codec>.c or <codec>enc.c in libavcodec source to be sure [19:44:34 CEST] <c_14> ffmpeg -h encoder=blah; ffmpeg -h decoder=blah [19:46:30 CEST] <_0x5eb_> Mavrik, c_14: thanks, so both confirm that there is no private option for libschroedinger [21:29:44 CEST] <foreverska> Shoot, it's reporting that I don't have any NVENC capable devices. I have two GTX660s, that can't be true [22:36:36 CEST] <foreverska> I've installed the latest drivers and jacked around with my xorg many times and I still get "No NVENC capable devices found" when I have twin GTX 660s sitting here. [00:00:00 CEST] --- Sun Oct 4 2015

1 0

ffmpeg-devel.log.20151002
by burek 03 Oct '15

03 Oct '15

[01:16:48 CEST] <DHE> Fixing #4900 wasn't too hard actually... testing it, then I'm submitting to the list [01:22:21 CEST] <cone-099> ffmpeg 03Carl Eugen Hoyos 07master:ac7b1f742324: lavfi/mandelbrot: Output RGB0 instead of RGBA. [01:26:59 CEST] <J_Darnley> What is the point of this fate-source test? Won't that just always fail when ever someone adds something? [01:30:56 CEST] <J_Darnley> Oh it is isn't very helpful when it says "see somefile.err for details" but that file is empty. [01:31:57 CEST] <J_Darnley> Oh [01:32:08 CEST] <J_Darnley> that's the new license header check [02:08:59 CEST] <atomnuker> a pic32f running at 70 Mhz can decode mp3s [02:09:13 CEST] <atomnuker> an ARM compared to that is a supercomputer [02:09:36 CEST] <atomnuker> yet mobile phones nowadays ship and use hardware decoders for a few audio formats [02:10:55 CEST] <atomnuker> I doubt many manufacturers actually measure if this saves battery life, they just do it because it's become a de-facto standard [02:19:01 CEST] <cone-099> ffmpeg 03Michael Niedermayer 07master:94d50b5d00ce: avformat/rtmpproto: Fix 2 more cases of the 2nd packet size being wrong [02:20:02 CEST] <wm4> atomnuker: maybe even to simplify firmware [03:33:27 CEST] <cone-099> ffmpeg 03Carl Eugen Hoyos 07master:da767f06f50f: lavf/rawdec: Autodetect raw TrueHD streams. [03:41:55 CEST] <cone-099> ffmpeg 03James Almer 07master:acdd6725065b: x86/audio_convert: fix clobbering of xmm registers [04:53:27 CEST] <cone-099> ffmpeg 03Christophe Gisquet 07master:562ba4a827ce: blockdsp: remove high bitdepth parameter [07:37:34 CEST] <qrtt1> hello, good evening (from +8) [09:22:35 CEST] <qrtt1> I compile the seek_print.c, and try to run it, then get the "seek:stream:min_ts:ts:max_ts:flags". Is there an example to use it ? [09:40:23 CEST] <durandal_1707> atomnuker: how is assim going? [09:40:59 CEST] <durandal_1707> gonna write apsnr? [10:38:37 CEST] <cone-132> ffmpeg 03Paul B Mahol 07master:1d7d8244943c: avfilter/af_rubberband: add process_command() [11:20:56 CEST] <durandal_1707> so is it ok to push tinterlace patch? [12:40:35 CEST] <wm4> nevcairiel, michaelni__: so are you ok with my videotoolbox patches? [12:45:22 CEST] <durandal_1707> is it ok to push maskedmerge asm? [13:13:00 CEST] <michaelni__> wm4, iam no videotoolbox dev so no objection from me. about the h264 patch, the 1 << 16 is a bit big, i hope that could be made smaller but no real objection either [13:14:44 CEST] <wm4> michaelni__: it's relatively bug, but I didn't find a real upper bound, other than the 16 bit per-sps/pps length fields in the mp4-style extradata, so I went with that [13:14:48 CEST] <wm4> *big [13:15:04 CEST] <wm4> also the SPS/PPS structs are allocated dynamically, so I'm thinking it's not so bad [13:17:24 CEST] <michaelni__> to find a good upper bound someone probably would have to calculate it from the h264 spec ... not really fun work [13:20:53 CEST] <michaelni__> but my feeling says that it should be alot smaller than 64k [13:21:21 CEST] <J_Darnley> durandal_1707: is your latest patch on the ml? [13:22:56 CEST] <durandal_1707> J_Darnley: no, I have some changes locally [13:23:51 CEST] <J_Darnley> Did you get anywhere with using newer than sse2 instructions? [13:28:51 CEST] <J_Darnley> If you didn't and your changes are the changes mentioned on the ML in reply to other people's comments then I think the patch was okay to push. [13:30:21 CEST] <durandal_1707> I didnt tried newer instructions [13:30:58 CEST] <durandal_1707> J_Darnley: do you see easy way to add them? [13:31:35 CEST] <durandal_1707> for example instruction that do mul and shift at once [13:31:47 CEST] <J_Darnley> No but them I'm not very good at using the "fancy" instructions. [13:33:04 CEST] <J_Darnley> The only one I can immediately tell you how to use is pmovzxbw which Henrik mentioned. [13:33:53 CEST] <J_Darnley> Even then I'm not sure its worth it. [13:59:50 CEST] <Daemon405> michaelni__ / wm4 / nevcairiel - any opinion on my locking patch? Luca is going to push the version I sent to libav soon (i wasn't aware until today). [14:00:01 CEST] <Daemon405> i would like to stop him if there's any concerns [14:00:16 CEST] <nevcairiel> i'll give it another look [14:00:20 CEST] <Daemon405> plus ffmpeg's version is quite different, and we should push that + skip the merge of the libav one [14:06:10 CEST] <wm4> Daemon405: took another look (at luca's new libav patch), seems ok [14:07:22 CEST] <Daemon405> wm4, peek at ffmpeg's too [14:07:23 CEST] <Daemon405> it differs [14:07:28 CEST] <Daemon405> due to the locking functions in ffmpeg [14:07:31 CEST] <Daemon405> and that recursive open func [14:07:50 CEST] <Daemon405> mostly to double check. [14:08:53 CEST] <nevcairiel> looks fine to me [14:09:13 CEST] <nevcairiel> next up, going through all the codecs and flag threadsafe if appropriate? =p [14:09:21 CEST] <nevcairiel> most of them probably are [14:12:12 CEST] <Daemon405> nevcairiel, yes [14:12:17 CEST] <Daemon405> i have h264 and aac threadsafe locally [14:12:25 CEST] <Daemon405> and it's been tested at work for a few days without issue [14:12:44 CEST] <Daemon404> eventually the lock can be killed [14:12:45 CEST] <Daemon404> i hope. [14:12:57 CEST] <nevcairiel> maybe, maybe not [14:13:08 CEST] <nevcairiel> depends on external libraries being not so crazy [14:13:21 CEST] <Daemon404> pthread_once bruh [14:13:32 CEST] <nevcairiel> that still assumes the library is somewhat sane [14:13:32 CEST] <nevcairiel> :D [14:13:36 CEST] <Daemon404> lol [14:13:42 CEST] <Daemon404> how would they even break that? [14:13:56 CEST] <nevcairiel> closing context deletes global state, what do i know [14:13:58 CEST] <nevcairiel> they find a way [14:14:18 CEST] <Daemon404> oh. [14:14:20 CEST] <Daemon404> you made me sad. [14:14:40 CEST] <nevcairiel> (although that particular example would just crash today as well) [14:14:49 CEST] <nevcairiel> when used in parallel [14:15:03 CEST] <Daemon404> it *might* crash [14:15:09 CEST] <Daemon404> ;) [14:16:25 CEST] <wm4> hm, ffmpeg always locked? [14:16:29 CEST] <wm4> even for thread-safe codecs [14:16:34 CEST] <nevcairiel> so did libav [14:16:38 CEST] <nevcairiel> but yes [14:17:07 CEST] <wm4> oh right, libav also does [14:17:16 CEST] <wm4> so I wonder what other hidden thread-unsafe things there might be [14:17:24 CEST] <nevcairiel> all the flag did was suppress the error if no lockmgr was available [14:17:40 CEST] <nevcairiel> which is kind of a weird idea [14:18:01 CEST] <Daemon404> wm4, very few codecs have that flag right now [14:18:09 CEST] <Daemon404> and theyre all simple ones [14:18:11 CEST] <Daemon404> should be pretty safe [14:18:20 CEST] <Daemon404> nevcairiel, yeah [14:18:49 CEST] <wbs> nevcairiel: it was only added as a fix for the case when one codec internally opens another one, which failed previosuly (due to the engangled thread counter), but was skipped with this flag [14:19:11 CEST] <Daemon404> wbs, ffmpeg has some separate func for that too [14:19:15 CEST] <wm4> well looks ok to me then [14:19:17 CEST] <Daemon404> ff_open_recursive or something [14:19:23 CEST] <wbs> Daemon404: I see [14:19:41 CEST] <Daemon404> wbs, btw while lookign at this, i noticed libav does not use atomics for the entangled trhead counter [14:19:44 CEST] <Daemon404> probably should [14:19:48 CEST] <Daemon404> i can backport that fix i gues [14:19:49 CEST] <Daemon404> s [14:20:34 CEST] <nevcairiel> i always forget the rules, isnt a volatile int supposed to be accessed atomicly on x86 anyway? [14:20:40 CEST] <nevcairiel> (i know, other platforms) [14:20:47 CEST] <kierank> nevcairiel: from what I understand it is legal to put an sps/pps in the previous ts packet [14:20:56 CEST] <Daemon404> nevcairiel, one arch isnt good enough [14:20:59 CEST] <Daemon404> also i forget too [14:21:19 CEST] <nevcairiel> kierank: why not, it just screws up the parser right now :d [14:21:43 CEST] <wm4> I think volatile barely means anything on x86 [14:21:53 CEST] <wm4> you are encouraged to use weak atomics instead [14:22:15 CEST] <wm4> volatile has a special meaning wrt. signals and also longjmp [14:24:58 CEST] <nevcairiel> apparently reads of native-sized elements are just always atomic, screw volatile [14:27:10 CEST] <DHE> volatile was meant to inform the compiler that it should not cache variables in registers or make assumptions that they won't change outside its knowledge. [14:27:32 CEST] <DHE> in theory anyway... with threading, etc being normal I don't know how much that still stands [14:27:44 CEST] <wm4> nevcairiel: btw. your opinion about my videotoolbox patch? [14:29:29 CEST] <atomnuker> durandal_1707: not much point in apsnr since tiny_psnr is useless for making quality comparisons, which is what I'm interested in [14:30:09 CEST] <nevcairiel> wm4: all i know is that I would like to hurt apple for building something thats different to everything else in the world ... again [14:30:45 CEST] <wm4> isn't it wonderful [14:31:10 CEST] <wm4> (but to be honest, this whole mp4 and evne h264 sps/pps thing is crap in the first place) [14:32:02 CEST] <Daemon404> BBB, ping when around, re: date for dinner. [14:32:06 CEST] <BBB> pong [14:32:13 CEST] <Daemon404> ohai [14:32:22 CEST] <Daemon404> PM [14:35:40 CEST] <ubitux> 14:24 <@nevcairiel> apparently reads of native-sized elements are just always atomic, screw volatile // on every arch? iirc using the atomic gcc builtin do not generate the same code on arm (even read) [14:35:59 CEST] <ubitux> (what about mips & friends?) [14:36:07 CEST] <nevcairiel> mips has no friends [14:36:20 CEST] <ubitux> :D [14:36:27 CEST] <ubitux> btw, helgrind doesn't like unprotected read [14:37:10 CEST] <ubitux> but well, we've already thousands of "errors" in that spirit [14:37:18 CEST] <BBB> helgrind doesnt find real bugs [14:37:20 CEST] <BBB> :-p [14:37:48 CEST] <nevcairiel> wm4: i think you could limit the max size of the sps/pps fields quite a bit though, its never possible to be that large [14:38:10 CEST] <nevcairiel> use 1024 or something, thats already way larger then possible [14:38:26 CEST] <ubitux> BBB: it does [14:38:38 CEST] <J_Darnley> A quick patch policy question: [14:38:38 CEST] <J_Darnley> I want to create a new header file for assembly constants. Using this in the existing files will require adding one line and removing some now redundant others. [14:38:38 CEST] <J_Darnley> A quick search tells me that I will touch 41 files in libavcodec alone. Should I commit each file separately, them all together, or group them slightly (perhaps by codec)? [14:38:38 CEST] <ubitux> BBB: but it hides them too [14:38:47 CEST] <BBB> yikes [14:39:14 CEST] <ubitux> J_Darnley: squash them [14:39:50 CEST] <J_Darnley> All into one patch you mean? [14:40:07 CEST] <ubitux> yeah, it's simpler [14:40:14 CEST] <wm4> nevcairiel: looking at the standard, this seems a bit conservative, though I find that part hard to read [14:40:33 CEST] <nevcairiel> the only "hard" part is that there are variable length codes in the sps/pps [14:40:35 CEST] <ubitux> (but feel free to split) [14:40:54 CEST] <nevcairiel> but even those have somewhat of a upper limit, otherwise the ffmpeg parser just fails on them [14:42:09 CEST] <wm4> michaelni__: do you give an ok for an upper limit of 1024 bytes for sps/pps NAL units? [14:47:15 CEST] <michaelni__> wm4, sure [14:47:35 CEST] <nevcairiel> apparently the exp-golomb codes use up to 31 bits max, so even if i count 4 bytes for every variable-length code, thats still way big [14:47:45 CEST] <wm4> then I'll push these patches with the data fields changed to 1024 [14:48:03 CEST] <wm4> nevcairiel: to me it looks like these scaling matrices can have 480 values in total [14:48:13 CEST] <nevcairiel> lets see [14:49:55 CEST] <nevcairiel> guess that could be the case [14:50:16 CEST] <nevcairiel> would be one odd scaling list to code all values in 31 bit symbols, but i guess [14:50:22 CEST] <nevcairiel> make it 4k then for paranoia [14:50:41 CEST] <wm4> I'm content with this [14:50:55 CEST] <michaelni__> +1 [15:08:07 CEST] <cone-712> ffmpeg 03Derek Buitenhuis 07master:abaa12263e08: avcodec: Don't lock during open if the codec has threadsafe init [15:13:51 CEST] <BBB> Gramner: do you also feel like reviewing my other intra pred simd patch (dc/tm/h/v)? [15:14:00 CEST] <BBB> Gramner: that one is a lot simpler so it shouldnt take terribly long [15:19:27 CEST] <BBB> Gramner: and lastly, thanks for review! [15:19:36 CEST] <BBB> (youre the only one reviewing my crazy asm patches :/) [15:41:37 CEST] <durandal_1707> looks like dcaenc and ffdcaenc disappeared from internet [15:42:39 CEST] <nevcairiel> someone naming their standalone thing ffdcaenc was total fail anyway [15:42:50 CEST] <nevcairiel> i always thought he was walking about the ffmpeg version [16:15:01 CEST] <BBB> durandal_1707: internetarchive? [16:25:48 CEST] <durandal_1707> dcaenc page is still available but not with google results [17:04:12 CEST] <Daemon404> does ffmepg github no longer sync? [17:07:04 CEST] <durandal_1707> I think michaelni manually pushes [17:07:16 CEST] <Daemon404> what happened to the sync script? [17:07:35 CEST] <Daemon404> and maybe make it a git post-push hook? [17:45:57 CEST] <cone-712> ffmpeg 03Paul B Mahol 07master:160556c9ad16: avfilter/vf_maskedmerge: add SIMD for maskedmerge with 8 bit depth input [18:12:14 CEST] <cone-712> ffmpeg 03Christophe Gisquet 07master:7e4070d2e70b: dnxhddec: initialize with mb-aligned dimensions [18:12:15 CEST] <cone-712> ffmpeg 03Christophe Gisquet 07master:c7e14a279fa7: dnxhddec: use dequantization formula from specs [18:12:16 CEST] <cone-712> ffmpeg 03Christophe Gisquet 07master:74ef5449a6fb: dnxhddec: init scantable once permutation is set [18:15:46 CEST] <durandal_1707> 200fps -> 600fps [18:17:53 CEST] <BBB> librtmpf! [18:17:56 CEST] <BBB> I KNEW IT! [18:18:09 CEST] <BBB> muhahahahahhahahahahahahha [18:18:24 CEST] <BBB> this whole bullcrap rant I did a few years ago when librtmp came about [18:18:58 CEST] <BBB> durandal_1707: btw nice job on your first simd! (I should say something nice every time I rant) [18:21:13 CEST] <wm4> BBB: well, the lavf rtmp code isn't really beautiful either (why the fuck does it mux to flv) [18:21:31 CEST] <BBB> Im sure it isn't [18:21:52 CEST] <BBB> and Im also quite sure that reimplementing it from scratch outside lavf A) doesnt fix it and B) isnt right [18:22:24 CEST] <wm4> don't know, what are its goals? [18:22:36 CEST] <BBB> maybe the goals are wrong and we should delete the code [18:22:47 CEST] <BBB> x264 was done outside ffmpeg and it did quite well for itself [18:23:03 CEST] <wm4> I mean rtmpf's [18:23:13 CEST] <Daemon404> where are you guys seeing this [18:23:20 CEST] <wm4> ML [18:23:28 CEST] Action: Daemon404 didnt see it [18:23:31 CEST] <BtbN> What even is rtmfp? [18:23:43 CEST] <wm4> "I am working on a new library that will implements the RTMFP protocol's client part. " [18:23:49 CEST] <wm4> so maybe it's a new protocol? [18:23:56 CEST] <Daemon404> o there it is [18:24:29 CEST] <Daemon404> https://en.wikipedia.org/wiki/Real_Time_Media_Flow_Protocol [18:24:46 CEST] <Daemon404> basically a udp rtmp [18:25:35 CEST] <Daemon404> also he stated why it was separate [18:25:38 CEST] <wm4> sounds "great" [18:25:40 CEST] <Daemon404> business reasons [18:25:41 CEST] <Daemon404> afaict [18:26:08 CEST] <wm4> why isn't there a streaming protocol that actually works [18:28:57 CEST] <kierank> there is [18:28:59 CEST] <kierank> it's called udp [18:29:24 CEST] <kierank> I can understand separate libs if the libs have functionality not available in the ffmpeg API [18:29:57 CEST] <BtbN> so far rtmp did a good job for me. [18:30:16 CEST] Action: kierank is going to write a paper soon about why rtmp sucks [18:30:22 CEST] <wm4> kierank: udp/ip? that's too low level to be called a streaming protocol at all [18:30:35 CEST] <kierank> just send mpegts over udp [18:30:37 CEST] <kierank> ...done [18:30:41 CEST] <kierank> add rtp header if you wish [18:31:18 CEST] <BtbN> That can't prioritize I frames though [18:31:20 CEST] <durandal_1707> what is ABS instruction in sse2 [18:31:36 CEST] <kierank> BtbN: yes it can with DSCP [18:32:11 CEST] <wm4> what about seeking [18:32:39 CEST] <kierank> there's an rtp protocol for that [18:33:09 CEST] <kierank> the only thing it lacks is proxy server support [18:33:11 CEST] <kierank> but meh tcp [18:39:00 CEST] <Compn> kierank : your paper does not have to be long "rtmp sucks" . :) [18:43:01 CEST] <J_Darnley> durandal_1707: there isn't one [18:43:38 CEST] <J_Darnley> uh well, I assume you mean equivalent of C's abs() [18:44:27 CEST] <J_Darnley> Look at what I did in removegrain, I used many in there [19:12:49 CEST] <wm4> videotoolbox is weird, it still refuses the decode a specific mkv sample via hardware [19:12:55 CEST] <wm4> but if you allow sw decoding, it works [19:13:11 CEST] <wm4> (of course the sample works perfectly fine on other OSes with the same hw) [19:14:04 CEST] <wm4> and it fails already at decoder creation, so it has something to do with extradata [19:14:47 CEST] <J_Darnley> durandal_1707: in your blend SIMD you can use paddusb and psubusb to add and subtract with saturation. [19:15:46 CEST] <cone-712> ffmpeg 03wm4 07master:069190f7078e: avcodec/h264: keep SPS and PPS bitstream data [19:15:47 CEST] <cone-712> ffmpeg 03wm4 07master:16aac9a35919: avcodec/videotoolbox: fix decoding of some h264 bitstreams [19:19:09 CEST] <BBB> durandal_1707: pabsw is a ssse3 instruction [19:19:44 CEST] <BBB> durandal_1707: so ABS is a compat thing for sse2 [19:19:53 CEST] <BBB> durandal_1707: we have multiple of these types of macros in x86util.asm [19:20:20 CEST] <BBB> durandal_1707: its totally ok to not care and just say my code is ssse3 btw, dont feel force to use these macros unless sse2 compat is a requirement for you [19:24:32 CEST] <jamrial> BBB: it's worth having an sse2 version if the only change needed is using any of the ABS macros [19:25:03 CEST] <BBB> sure, but it can always be done later as a separate patch [19:26:59 CEST] <durandal_1707> J_Darnley: done [19:38:36 CEST] <andrewrk> did everybody see FLIF in the news today? [19:38:44 CEST] <andrewrk> pretty intriguing [19:39:06 CEST] <wm4> we laughed at the source code [19:39:21 CEST] <wm4> (let's say they're not really following good practices) [19:45:48 CEST] <jamrial> durandal_1707: see https://github.com/jamrial/FFmpeg/commit/40fc73db28cd9a0fd4aff4284b23a3f535… [19:45:57 CEST] <jamrial> what i'm doing here is making the function access most linesize, width and height arguments directly from stack [19:46:19 CEST] <jamrial> that way the function can work with only 7 gprs [19:46:54 CEST] <jamrial> you can do the same with the blend stuff you sent a few minutes ago. but again you need to make the pointers the first couple arguments for those [19:48:35 CEST] <andrewrk> wm4, if the DSP is sound it should be fine [19:48:39 CEST] <andrewrk> bad source code can be fixed [19:48:42 CEST] <andrewrk> easy [19:49:39 CEST] <wm4> well, at this quality level, I wouldn't be surprised if it's not actually lossless [19:49:43 CEST] <wm4> but yeah, we'll see [19:50:11 CEST] <andrewrk> what's actually the problem? [19:50:17 CEST] <andrewrk> I'm looking at it right now [19:50:36 CEST] <andrewrk> it looks pretty straightforwar [19:50:42 CEST] <andrewrk> *straightforward [19:51:30 CEST] <andrewrk> I guess more c++ than this crowd (including me) would care for [19:55:27 CEST] <atomnuker> goddamnit [19:55:38 CEST] <atomnuker> max_samples isn't respected for multiple input filters [19:56:32 CEST] <atomnuker> any other way to force filtering only N amount of samples per frame? [19:56:39 CEST] <wm4> andrewrk: no, it's awful beyond that [19:57:13 CEST] <wm4> but yeah, maybe the algorithms are fine (apart from the fact that it uses patented algorithms, despite claiming otherwise) [19:58:16 CEST] <durandal_1707> atomnuker: see what sidechaincompress does, also amerge IIRC [20:06:00 CEST] <Daemon404> [18:51] < andrewrk> I guess more c++ than this crowd (including me) would care for <-- mixing c/c++ strings, using a vector of strings for stuff, pollutes the global namespace with generic names [20:06:11 CEST] <Daemon404> mixes_snake_case_andCamel_case [20:06:16 CEST] <Daemon404> (within teh same func names) [20:06:21 CEST] <Daemon404> in general it's all over the place [20:06:46 CEST] <andrewrk> ehh that stuff isn't really a big deal [20:06:58 CEST] <Daemon404> there's one part where it just copypastes the same code 3-4 times in a row because "it seems to fix it" [20:07:09 CEST] <andrewrk> especially mixing case convention. who cares? the CPU doesn't [20:07:25 CEST] <andrewrk> ok that last thing is suspicious. [20:07:32 CEST] <Daemon404> look at its commit log. [20:07:37 CEST] <Daemon404> also i certainly care that it has an actually usable library interface [20:07:52 CEST] <Daemon404> and has actual checks for failure [20:09:01 CEST] <Daemon404> VLAs initialized with user provided sizes [20:09:44 CEST] <Daemon404> asserts used instead of ifs [20:09:49 CEST] <Daemon404> (im just looking over random files atm) [20:09:59 CEST] <andrewrk> I care about that too, but the guy admits it's work in progress [20:10:14 CEST] <Daemon404> also the format is not patent free [20:10:16 CEST] <Daemon404> as the page claims [20:10:20 CEST] <andrewrk> yes that is a big problem [20:10:58 CEST] <Daemon404> there's a difference between WIP and complete lack of any standard IMO [20:11:03 CEST] <Daemon404> but i guess i have different standards [20:11:26 CEST] <Daemon404> im also very iffy on the whole "hey lets make yet another new lossless image format" thing [20:11:42 CEST] <Daemon404> history shows: compression gains simply are not enough to drive adoption. [20:12:45 CEST] <Daemon404> next thing i notice: a library that prints to stderr (bad) [20:13:28 CEST] <Daemon404> skeptical would be the right word for me. [20:13:32 CEST] <andrewrk> fair enough [20:13:46 CEST] <andrewrk> I get the impression that the author is in a "research" phase and plans to make a cleaner and more optimized version once that phase is done [20:13:56 CEST] <Daemon404> youve never worked in academia have you [20:14:02 CEST] <Daemon404> that 2nd phase never happens [20:14:03 CEST] <andrewrk> actually I have [20:14:04 CEST] <Daemon404> you cant publish that [20:14:27 CEST] <Daemon404> (ok, extremely rarely, it does) [20:17:23 CEST] <Daemon404> (and i'd be thrilled to be wrong here, fwiw) [20:17:31 CEST] <andrewrk> :) [20:19:29 CEST] <Daemon404> also it could be worse [20:19:34 CEST] <Daemon404> could be another lossless audio codec :D [20:20:22 CEST] <andrewrk> ha [20:40:05 CEST] <J_Darnley> Wait a minute... what's not "another lossless audio codec"? [20:41:31 CEST] <jamrial> J_Darnley: FLIF, another lossless image format [20:41:50 CEST] <J_Darnley> oh yay! *thumbs up* [20:44:57 CEST] <J_Darnley> Of course half the comments on HN are "but its GPL!" [20:45:33 CEST] <Daemon404> there are already two bugs open for that [20:45:43 CEST] <Daemon404> i must say though, gplv3 is a dead sentence for a library [20:45:58 CEST] <J_Darnley> I reality that is probably true. [20:46:08 CEST] <wm4> not as bad as AGPL [20:46:12 CEST] <wm4> (yes there are such libs) [20:46:41 CEST] <J_Darnley> That is a thread where they should enforce their "no negative comments" policy more strictly. [20:46:42 CEST] <Daemon404> J_Darnley, well especially if you want browser adoption [20:50:01 CEST] <Daemon404> anywyay, biggest deal: it's patent encumbered (and claims otherwise) [20:53:42 CEST] <wm4> surely there's some very similar coding that performs about the same, and that isn't encumbered? [20:55:00 CEST] <Compn> when do png patents expire? :P [21:01:36 CEST] <DHE> is there any system for what patches get accepted/reviewed first? (I ask because I have two that I feel are being neglected, but I'm new to the project so...) [21:01:57 CEST] <Daemon404> reply with a ping [21:02:21 CEST] <DHE> is there an appropriate time to wait before pinging? it's only been a day [21:02:33 CEST] <Compn> 2 weeks is usually the thing [21:02:48 CEST] <Compn> if its security or important issue, then ping immediately of course [21:03:10 CEST] <Compn> DHE : whats thread title? ask us to review your patch :) [21:06:21 CEST] <J_Darnley> How high can the constant A go in this type of x86 memory argument: [r0 + A * r1 + B] [21:06:36 CEST] <jamrial> a week is enough to ping [21:07:00 CEST] <DHE> Compn: [PATCH] libavformat/hlsenc: Use of uninitialized memory unlinking old files [21:08:03 CEST] <DHE> I don't think it's exploitable or likely to crash the app because of the structure of the struct involved, but it will make a mess of your terminal [21:08:33 CEST] <jamrial> J_Darnley: 8 i think [21:09:24 CEST] <J_Darnley> Thanks. I better finish this function and see whether yasm complains about 32 [21:12:52 CEST] <DHE> so probably not security, but definitely a pretty big "oh sh--" [21:17:17 CEST] <BBB> J_Darnley: 1,2,4 or 8 [21:19:53 CEST] <J_Darnley> thanks [21:27:36 CEST] <BBB> J_Darnley: btw I really like the idea of constants in yasm style (instead of in c), maybe requiring yasm/nasm in x86 isnt a bad idea (x264 does that also) [21:30:52 CEST] <Gramner> compiling with inline assembly but without yasm seems like a really odd use case and if you compile without yasm you obviously don't care about performance at all so no harm in disabling inline asm too [21:33:38 CEST] <BBB> right [21:33:50 CEST] <BBB> Gramner: any more comments on the intra pred simd or loopfilter simd, or ok to commit? [21:33:59 CEST] <BBB> Gramner: and can I somehow trick you in reviewing h/v/tm/dc asm also? [21:34:08 CEST] <Gramner> currently doing the latter [21:34:14 CEST] <BBB> \o/ [21:34:17 CEST] <BBB> youre awesome [21:34:18 CEST] <BBB> thank you [21:36:17 CEST] <Gramner> i haven't looked at the new versions of the already reviewed ones you posted but if you addressed my comments then feel free to push them [21:40:12 CEST] <cone-712> ffmpeg 03Michael Niedermayer 07master:14f6c4356b4a: avformat/flvdec: accept sizes if they are off by 11 [21:50:56 CEST] <wm4> michaelni__: should I write and submit a patch to dynamically allocate the sps/pps data? [21:54:27 CEST] <BBB> accept sizes if they are off by 11 [21:54:50 CEST] <BBB> Im seriously questioning that commit message [21:54:59 CEST] <wm4> packet sizes [21:55:06 CEST] <michaelni__> wm4, iam slightly tending toward, no, to avoid any risks of double frees when it gets copied around [21:55:11 CEST] <wm4> BBB: because the rtmp protocol produced garbage [21:55:25 CEST] <wm4> michaelni__: yeah, it's messy [22:18:41 CEST] Action: rcombs throws together a chromaprint "muxer" because why not [22:19:17 CEST] <BtbN> A play-to-cups muxer would also be extremely usefull. [22:19:31 CEST] <BtbN> 60 Pages per second printer required though [22:19:50 CEST] <rcombs> chromaprint is an audio fingerprinter [22:20:05 CEST] <rcombs> muxer works like crcenc [22:22:30 CEST] <Daemon404> sounds nefarious [22:38:10 CEST] <J_Darnley> WTF? How can I possibly create a linking error by adding a function to a completely different file? [22:40:54 CEST] <atomnuker> durandal_1707: can I safely assume that the number of samples per frame will remain constant except for the very last sample? [22:46:07 CEST] <rcombs> wm4: whoops `git add` is hard [22:48:29 CEST] <JEEB> `git status` is your friend [22:49:27 CEST] <nevcairiel> atomnuker: in general? not on every audio codec, no [22:50:09 CEST] <rcombs> you can in BRSTM files! [22:50:58 CEST] <wm4> atomnuker: are you asking this in context of lavfi? [22:51:48 CEST] <atomnuker> wm4: yep [22:52:08 CEST] <wm4> atomnuker: the API user can pass it whatever he/she/it pleases [22:52:15 CEST] <atomnuker> the problem is that a paper I read suggests to use a standard overlap for SSIM [22:52:34 CEST] <nevcairiel> we have a audio queue for things that require constant frame size, i thinkj [22:52:45 CEST] <wm4> and some codecs in fact produce variable length frames [22:52:58 CEST] <wm4> (which also causes the framepool to realloc on every frame... whatever.) [23:11:01 CEST] <Gramner> BBB: I got a bit bored of just reading asm so I rewrote some of your ipred code to make it twice as fast. I hope you don't mind [23:11:10 CEST] <BBB> lol [23:11:21 CEST] <J_Darnley> hehheh [23:11:33 CEST] <BBB> was my dc that bad? [23:11:50 CEST] <BBB> (unless you wrote avx2) [23:11:56 CEST] <Gramner> it was the h actually [23:11:59 CEST] <Gramner> ans no, sse2 [23:12:02 CEST] <Gramner> and* [23:12:37 CEST] <BBB> pshufb? [23:12:42 CEST] <BBB> hm, sse2 [23:13:05 CEST] <J_Darnley> How do I call avcodec's ff_add_pixels_clamped function pointer from assembly? I've declared it with "cextern add_pixels_clamped" but what kind of operand do I need to give to "call"? [23:13:06 CEST] <Gramner> the changes I did applies to parts of tm as well, but I'll leave that as an excercise to you [23:13:16 CEST] <BBB> oh [23:13:24 CEST] <BBB> I suppose you can punpcklwd the input [23:13:26 CEST] <BBB> and then pshufdx4 [23:13:36 CEST] <BBB> instead of pshuflw x4 + punpcklqdqx4 [23:13:37 CEST] <BBB> ? [23:13:38 CEST] <nevcairiel> J_Darnley: calling proper functions is hard work [23:13:44 CEST] <Gramner> punpckhwd, but yes. bingo [23:13:48 CEST] <nevcairiel> J_Darnley: better dont [23:14:15 CEST] <BBB> nice! [23:14:20 CEST] <J_Darnley> perhaps but then I need a wrapper around my DSP function (or I can duplicate the code). [23:14:32 CEST] <BBB> well thats not twice as fast, but ok, it saves 3/8th shuffles [23:14:39 CEST] <BBB> so you get a medal for that [23:15:09 CEST] <BBB> J_Darnley: just duplicate it [23:15:11 CEST] <Gramner> ~15 -> ~8 clocks [23:15:12 CEST] <BBB> add_pixels is trivial [23:15:24 CEST] <BBB> Gramner: ok cool, want me to incorporate it in my patch? [23:15:38 CEST] <Gramner> yes, that's fine. I'll post on the ML in a while [23:18:47 CEST] <BBB> ty, Ill wait [23:19:18 CEST] <Gramner> BBB: in general I think you're interleaving to much stuff which increases register pressure and also reduces the efficiency of the µop cache in some cases [23:19:45 CEST] <BBB> interleaving was a big thing back when I learned this [23:19:47 CEST] <Gramner> interleaving 1-cycle instructions 4 at a time is overkill, 2 is enough [23:19:49 CEST] <BBB> I guess it isnt anymore [23:20:00 CEST] <BBB> oh I see [23:21:02 CEST] <Gramner> if you can reuse the exact same instructions (including the same registers) multiple times the cpu wont have to decode it again. this sis beneficial sometimes [23:21:42 CEST] <Gramner> that's not part of asm 101 though! it's an extra course ;) [23:22:29 CEST] <rcombs> huh, interesting [23:23:04 CEST] <BBB> sounds complicated :-p [00:00:00 CEST] --- Sat Oct 3 2015

1 0

ffmpeg.log.20151002
by burek 03 Oct '15

03 Oct '15

[03:49:58 CEST] <t4nk879> hello [03:51:00 CEST] Last message repeated 1 time(s). [03:51:11 CEST] <t4nk879> I am building ffmpeg 2.8 with nothing disabled unless it's the default is that it's disabled [03:51:24 CEST] <t4nk879> but there are many missing header files for libavformat [03:51:29 CEST] <t4nk879> including network.h and rtsp.h [03:51:35 CEST] <t4nk879> when I do an install after [03:52:02 CEST] <t4nk879> it seems they are not copied over at all [03:52:15 CEST] <t4nk879> even though the option to disable them had not been set [03:59:38 CEST] <meh`> I'm having a hard time finding examples to generate and encode subtitles in a video using the library, could anyone point me to some? [04:09:50 CEST] <SpootDev> t4nk879: doing install as admin/root/sudo/etc? [04:29:51 CEST] <t4nk879> right now, root [04:30:09 CEST] <t4nk879> and I think I found the issue [04:30:42 CEST] <t4nk879> in libavformat/Makefile, it has this in it [04:30:45 CEST] <t4nk879> SKIPHEADERS-$(CONFIG_NETWORK) += network.h rtsp.h [04:31:13 CEST] <t4nk879> and CONFIG_NETWORK is set to yes in config.mak [04:32:25 CEST] <t4nk879> so even though I have network enabled, it is not copying the headers because the variable SKIPHEADERS-yes includes those files and I think is supposed to not copy those files for some reason [05:14:33 CEST] <t4nk879> ok so I found a way around it I think [05:15:24 CEST] <t4nk879> add this to libavformat/Makefile right after the SKIPHEADERS- lines [05:15:26 CEST] <t4nk879> HEADERS += $(SKIPHEADERS-yes) [05:17:21 CEST] <t4nk879> and the same would have to be done on the other Makefiles like in libavcodec [05:17:31 CEST] <t4nk879> are those files not meant to be used? [08:51:09 CEST] <sopparus> hello, can ffmpeg make use of VCE (amd) for encoding these days? [08:51:11 CEST] <sopparus> on linux [11:19:07 CEST] <Jee> Hi guys :) [11:20:14 CEST] <durandal_1707> Hi [11:21:08 CEST] <Jee> I think i can ask for help here about ffmpeg integration in my project ? I'm a the good place ? :D [11:21:26 CEST] <Jee> It's about G711 (PCM-ALAW) codec [11:22:21 CEST] <Jee> Someone already tried to encode with this codec ? [11:46:03 CEST] <durandal_1707> Jee: the encoding should be fine [11:59:00 CEST] <Jee> Hum, actually i just found out that G711 codec is CODEC_CAP_VARIABLE_FRAME_SIZE, so the frame_size that avcodec2() should fill was 0, that bother me and make fail my algorithm. Now if i have CODEC_CAP_VARIABLE_FRAME_SIZE capability, i set a arbitrary frame_size of 10000. Seems to make the deal. [15:40:57 CEST] <frenda> When I try 'ffmpeg -i input.ogg -strict -2 oupput.mp4' (oog-->mp4) [15:41:07 CEST] <frenda> it reduce the quality of video [15:41:10 CEST] <frenda> Oops [15:41:17 CEST] <frenda> mp4 --> ogg [15:41:45 CEST] <frenda> *'ffmpeg -i input.mp4 oupput.ogg' [15:42:14 CEST] <DHE> what codecs do you expect? copying encoded video isn't the default [15:42:51 CEST] <Mavrik> Yeah, that can't end well :) [15:44:22 CEST] <dv_> I have a question regarding ffmpeg 2.8. gst-libav uses ffmpeg 2.8 internally (ignore the name confusion for now). in openembedded, this patch is applied against gst-libav: http://git.openembedded.org/openembedded-core/tree/meta/recipes-multimedia/… [15:45:02 CEST] <dv_> as the commit message states, this was originally a fix in debian related to gcc 4.9.2's memcpy(). is this still relevant for ffmpeg 2.8? does anybody know more about this bugfix? [15:45:26 CEST] <frenda> DHE > what codecs do you expect? --> default [15:45:30 CEST] <frenda> -c copy? [15:45:46 CEST] <dv_> err, memset, not memcpy [15:45:52 CEST] <DHE> that will copy video as-is. very fast. not sure if .ogg will work but you can try it [15:48:29 CEST] <frenda> '-c copy' didn't work [15:48:34 CEST] <frenda> ERR: Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument [16:16:51 CEST] <alan01252222> hi all, hopefully a really simple question.. I'm getting this error from ffmpeg " Input format adts is not available" what flag do I need to enable in configure to get this to work? help greatly appreciated :) [16:24:19 CEST] <DHE> has anyone successfully built ffmpeg with --enable-lto? I get errors in cabac.h. Running gcc-5.2.0 (gentoo built) [17:02:04 CEST] <qpablito> hi I using FFmpeg version 0.6.5 and when i try to run "ffmpeg -i xxx.mp4 -vcodec copy -bsf:v h264_mp4toannexb teste.ts" had a error -> Unrecognized option 'bsf:v' [17:24:24 CEST] <DHE> that's a very old version of ffmpeg... [17:27:16 CEST] <iive> there is ffmpeg 2.8 at the topic :) [19:08:35 CEST] <alan01252222> Hi everyone, anyone around who knows why ffmpeg would be giving me this "Error: Input format adts is not available" I know adts can be used as an input format because the codes working o my dev box, not on my staging server it's throwing this! [19:09:17 CEST] <voice> same build? [19:11:38 CEST] <alan01252222> using 2.8 on staging, dev running 2.7.1 .. [19:12:13 CEST] <alan01252222> I'm trying to match all the configure flags now, not entirely sure which one is needed for that input format [19:14:48 CEST] <voice> do a ./ffmpeg -version on the box with 2.8 [19:14:57 CEST] <voice> it should tell you the ./configure flags used [19:15:47 CEST] <voice> sorry, misread, just do ./configure -version on the dev box :P [19:16:16 CEST] <alan01252222> this is dev configuration: --extra-libs=-ldl --prefix=/opt/ffmpeg --enable-avresample --disable-debug --enable-nonfree --enable-gpl --enable-version3 --enable-libopencore-amrnb --enable-libopencore-amrwb --disable-decoder=amrnb --disable-decoder=amrwb --enable-libpulse --enable-libdcadec --enable-libx264 --enable-libx265 --enable-libfdk-aac --enable-libvorbis --enable-libmp3lame --enable-libopus --enable-libvpx --enable-libspeex [19:16:27 CEST] <alan01252222> this is live [19:16:29 CEST] <alan01252222> configuration: --prefix=/home/deploy/ffmpeg_build --pkg-config-flags=--static --extra-cflags=-I/home/deploy/ffmpeg_build/include --extra-ldflags=-L/home/deploy/ffmpeg_build/lib --bindir=/home/deploy/bin --enable-nonfree --enable-gpl --enable-version3 --enable-libx264 --enable-libfdk-aac --enable-libvorbis --enable-libmp3lame --enable-libopus --enable-libass --enable-avisynth --enable-libvo-aacenc --enable-libdcadec libavutil [19:16:49 CEST] <alan01252222> just going through trying to make live match dev... but it's never just that easy ;) [19:17:26 CEST] <voice> let me ask you this, does it need to be a local build? :P [19:18:16 CEST] <alan01252222> hmmmmm I guess not... [19:18:56 CEST] <voice> I always had problems doing local builds which to me didn't make sense to do anyways unless you were trying to test out different builds/configurations [19:19:28 CEST] <alan01252222> *nod* I think you're right, and to be honest I've wasted a bit too much time trying to get this to build... [19:19:37 CEST] <alan01252222> thank you :) [19:19:39 CEST] <voice> I'm sure thats not the right mind set to have but thats just what I do personally [19:20:53 CEST] <martijnb> can't seem to get ffmpeg to take udp multicast as input [19:21:09 CEST] <martijnb> don't see any join attempts on a tcpdump [19:21:35 CEST] <martijnb> anyone spot anything wrong here; [19:21:54 CEST] <martijnb> ffmpeg -i udp://233.81.233.70:11000?multicast=1 -codec copy -map 0 -loglevel debug output.mp4 [19:22:04 CEST] <DHE> martijnb: udp://239.0.0.1:12345 works just fine for me... make sure your routing table is correct if you have multiple NICs [19:26:00 CEST] <martijnb> everything looks right, but maybe I've been staring at it for too long [19:28:48 CEST] <martijnb> this can wait until monday, thanks DHE [19:29:18 CEST] <martijnb> exit [19:29:24 CEST] <martijnb> er.. irc isn't a terminal [19:29:25 CEST] <martijnb> ;p [19:29:49 CEST] <DHE> you want /quit probably [19:30:21 CEST] <martijnb> yeah, I was shamelessly mashing exit closing terminals but irc snuck in [19:30:39 CEST] <martijnb> have a good weekend gents [21:57:06 CEST] <hwgasdfasdf> I'm trying to join a bunch of jpgs together into a video, and I'm using a command almost directly from the ffmpeg documentation, but it seems to only take the first frame like the glob isn't working [21:57:28 CEST] <hwgasdfasdf> the command I'm using is: ffmpeg -framerate 2 -i %*.jpg -vf "crop=1296:988:0:1" -c:v libx264 test.mp4 [21:57:42 CEST] <c_14> Where is that in the docs? [21:57:46 CEST] <c_14> That syntax is deprecated. [21:57:49 CEST] <hwgasdfasdf> I've also tried putting quotes around the *.jpg [21:57:52 CEST] <hwgasdfasdf> and omitting the % [21:57:54 CEST] <c_14> use -pattern_type glob -f image2 -i *.jpg [21:58:19 CEST] <durandal_1707> what are file names [21:59:26 CEST] <hwgasdfasdf> filenames are like 20150930_1300.jpg 20151001_1300.jpg [21:59:46 CEST] <hwgasdfasdf> c_14: I've tried that as well [21:59:55 CEST] <hwgasdfasdf> no matter what I do, I only get 33 frames of video [21:59:59 CEST] <hwgasdfasdf> and I don't see any errors [22:00:39 CEST] <c_14> How many images are there? [22:00:48 CEST] <hwgasdfasdf> roughly 160 [22:01:10 CEST] <hwgasdfasdf> and with an input framerate of 2, that should be a lot more frames of video [22:02:02 CEST] <c_14> It should still be 160 frames. at 80s [22:02:52 CEST] <hwgasdfasdf> is there a preferred pastebin to use here? I'll show the full output [22:03:23 CEST] <c_14> Doesn't matter solang as it doesn't need weird js/has popups/whatever [22:03:28 CEST] <hwgasdfasdf> shouldn't it be a lot more than 160 frames? 160 frames at 2 / sec * 25fps output (default framerate) is 80s * 25fps [22:03:42 CEST] <c_14> The default framerate is the input framerate [22:04:39 CEST] <c_14> Which in your case is 2 [22:06:43 CEST] <hwgasdfasdf> gah, stupid me... let's see what it does now... [22:12:08 CEST] <hwgasdfasdf> also my fault, I think the first few frames were at half the resolution as the rest - that's why it was only encoding the first few before [22:25:11 CEST] <hwgasdfasdf> ok, almost working [22:25:25 CEST] <hwgasdfasdf> if I want to scale then crop, is that two separate -vf arguments? [22:25:43 CEST] <c_14> -vf scale,crop [22:26:07 CEST] <hwgasdfasdf> and how do I specify the arguments? [22:26:15 CEST] <c_14> Same way you have before [22:26:24 CEST] <hwgasdfasdf> doing it as two separate obviously didn't work - it only took the last one [22:26:49 CEST] <c_14> -vf scale=x:y,crop=x:y etc [22:27:09 CEST] <hwgasdfasdf> ok [00:00:00 CEST] --- Sat Oct 3 2015

1 0

ffmpeg-devel.log.20151001
by burek 02 Oct '15

02 Oct '15

[00:04:14 CEST] <BBB> durandal_1707: probably [00:04:24 CEST] <BBB> durandal_1707: theres various ways to write it, this one is probably fairly easy to follow [00:04:35 CEST] <BBB> durandal_1707: I can teach you other methods as we go and you can choose which one you like most :) [00:06:38 CEST] <durandal_1707> lets continue tomorrow, its late [00:07:59 CEST] <BBB> ok, g'nite [00:41:58 CEST] <rcombs> looks like some fate tests are borked [00:42:19 CEST] <rcombs> filter-separatefields, filter-select-alternate, filter-tblend, others [00:53:53 CEST] Action: rcombs spins wheel [00:53:55 CEST] <rcombs> I blame wm4 [00:58:28 CEST] <wm4> I accept the blame [00:58:43 CEST] <wm4> I have a solution: remving 200kloc of code [00:58:49 CEST] <wm4> removing even [00:59:47 CEST] <rcombs> actually it might just be me forgetting to `make install` because dylibs are silly [00:59:54 CEST] <rcombs> so& never mind, then [01:00:09 CEST] <wm4> I noticed the same problem on linux [01:00:46 CEST] <wm4> due to rpath ffmpeg is picking up the installed libs, not the locally compiled ones [01:00:59 CEST] <rcombs> yeah [01:01:07 CEST] <rcombs> doesn't happen if you only build static libs, but& [01:12:27 CEST] <cone-724> ffmpeg 03Michael Niedermayer 07master:dabea74d0e82: avcodec/vp8: Do not use num_coeff_partitions in thread/buffer setup [01:21:34 CEST] <cone-724> ffmpeg 03Michael Niedermayer 07master:9e9d731b5106: avcodec/pngdec: mark previous_picture as done on end of decode_frame_common() [01:25:12 CEST] <rcombs> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179207.html <-- nobody seems to object to this, so should I just push? [01:38:24 CEST] <wm4> rcombs: should be ok IMO [01:40:59 CEST] <wm4> you could ping it if you're unsure [01:51:33 CEST] <jamrial> BBB: you're not really using pw_4095 on vp9lpf_16bpp, yet you moved it to constants.c to include it there. [02:10:06 CEST] <rcombs> hmm, I can't connect via ssh for git [02:10:17 CEST] <BBB> jamrial: I am, I think? [02:10:23 CEST] <BBB> jamrial: I must be using it for clipping pixels [02:10:55 CEST] <BBB> jamrial: https://github.com/rbultje/ffmpeg/commit/32a0178737312ed551a66ad11ac769c34f… [02:11:07 CEST] <BBB> and then look for pw_ %+ %%maxusgn [02:11:49 CEST] <jamrial> oh, i see, i looked for pw_4095 and only found the cextern line [02:11:51 CEST] <jamrial> nevermind then [02:12:46 CEST] <BBB> jamrial: sorry, its a little bit convoluted maybe [02:14:33 CEST] <BBB> Gramner: your patch is totally obscure [02:16:04 CEST] <BBB> so you get one flag field after the &, then you ^ it with the flag itself, so its flag if not set, or 0 if set, then you -1, so its -1 if set, or something relatively small if set, then you >>31 to get -1 if set or 0 if not set, and then you &1 to get 1, right? [07:52:44 CEST] <Gramner> BBB: cpuflags_xxx is not a single flag bit, it's multiple, so & gives a bunch of bits. that's why the ^ is neccessary. otherwise correct [07:53:14 CEST] <Gramner> since x ^ y == 0 iff x == y [11:41:05 CEST] <ubitux> wm4: c368538667121fb20c5414dfaf0fb273035a0854 [11:41:16 CEST] <ubitux> wasn't buf[1] supposed to be buf[0]? [11:43:54 CEST] <ubitux> somehow unrelated but it appears that sometimes there are other stuff after the event number [11:43:57 CEST] <ubitux> that's so insane& [11:44:05 CEST] <ubitux> https://trac.ffmpeg.org/attachment/ticket/4898/events_export.srt [11:44:31 CEST] <ubitux> anyway, the probing need to be more lenient& [11:45:45 CEST] <wm4> ubitux: you might be right... [11:45:56 CEST] <ubitux> ok [11:45:59 CEST] <ubitux> i'll fix in a moment [11:50:30 CEST] <cone-572> ffmpeg 03Clément BSsch 07master:d161a2a72b08: avformat/srtdec: fix number check for the first character [11:50:30 CEST] <cone-572> ffmpeg 03Clément BSsch 07master:7218352e0228: avformat/srtdec: more lenient first line probing [11:51:27 CEST] <Daemon404> ubitux's favourite passtime: SRT [11:51:43 CEST] <wm4> srt seems to make a lot of work [11:51:55 CEST] <Daemon404> because it's a bad format that was just kinda madeup [11:51:59 CEST] <Daemon404> but teh subrip guy [11:52:09 CEST] <Daemon404> was never intended to distro, i think? [11:52:12 CEST] <ubitux> it's actually pretty fine [11:52:12 CEST] <Daemon404> (i could be wrong) [11:52:22 CEST] <wm4> seems like a very bad format to me [11:52:27 CEST] <ubitux> i mean, fixing them is not that much work [11:52:38 CEST] <Daemon404> ubitux, dealing with users' srt files make me hate it, i guess [11:52:39 CEST] <ubitux> i think the format is fine, except maybe the numbering of events [11:52:45 CEST] <Daemon404> 90 million workarounds for bad srt files [11:52:52 CEST] <ubitux> :) [12:21:57 CEST] <nevcairiel> srt is pretty simple, the only annoying part is the subset of html tags people like to throw in it [12:22:12 CEST] <nevcairiel> but even simple string parsing and C don't like each other very much [12:49:25 CEST] <durandal_170> BBB: hi, I wrote asm that memset buffer to zero [12:52:01 CEST] <BBB> durandal_170: \o/ [12:52:05 CEST] <BBB> very good [12:52:49 CEST] <JEEB> I should hone my asm skills some day, I haven't written a line of asm since '12 [12:52:53 CEST] <BBB> try to write a multiply [12:53:01 CEST] <BBB> JEEB: didnt we practice asm a few years ago? [12:53:05 CEST] <JEEB> yeah [12:53:06 CEST] <BBB> I thought we did [12:53:08 CEST] <BBB> ah, ok [12:53:13 CEST] <BBB> I thought I was getting forgetful [12:53:25 CEST] <BBB> durandal_170: or, actually, start with a copy [12:53:28 CEST] <JEEB> I did manage to do some left-prediction [12:53:30 CEST] <BBB> durandal_170: and then try to write a multiply of some sort [12:53:37 CEST] <BBB> durandal_170: youll get the hang of it pretty quickly [13:00:44 CEST] <wm4> holy shit, libavdevice/decklink_common.cpp is ifdefferied to work on both win32 and OSX (using some native APIs on both) [13:02:02 CEST] <durandal_170> BBB: what should I use to subtract what I get from punpcklbw? [13:06:33 CEST] <BBB> psubw [13:06:39 CEST] <BBB> theres also paddw [13:06:45 CEST] <BBB> (add word) [13:06:51 CEST] <BBB> and theres paddb, paddd, etc. [13:07:00 CEST] <BBB> and sub counterparts [13:07:20 CEST] <BBB> theres also a variety of multiply or multiply-and-add variants [13:23:53 CEST] <durandal_170> BBB: what to use for multiply and add? [13:28:44 CEST] <BBB> durandal_170: try pmaddwd [13:28:51 CEST] <BBB> durandal_170: theres also pmaddubsw, which is ssse3 [13:29:10 CEST] <BBB> durandal_170: pmaddwd takes words as input and outputs the sum of two adjacent word-multiplies in a single dword [13:29:48 CEST] <BBB> durandal_170: so for input a1,a2,a3,a4,a5,a6,a7,a8 and b1-8, it returns dwords: a1*b1+a2*b2, a3*b3+a4*b4, a5*b5+a6*b6, a7*b7+a8*b8 [13:30:05 CEST] <BBB> durandal_170: pmaddubsw is the same ish for byte to word [13:30:36 CEST] <BBB> durandal_170: but for pmaddubsw you typically care about signedness, so dst/src1 should be unsigned and src2 should be signed [13:30:43 CEST] <BBB> durandal_170: whereas for pmaddwd I believe theyre both signed [13:33:54 CEST] <durandal_170> BBB: but I need to add 128, how can this be done? [13:35:29 CEST] <BBB> two ways [13:35:36 CEST] <BBB> you typically want to add a constant [13:35:40 CEST] <BBB> for that, we have rodata [13:35:50 CEST] <BBB> so you can have a RO_DATA segment with pw_128: times 8 dw 128 [13:35:58 CEST] <BBB> and thats exactly that [13:36:11 CEST] <BBB> we probably already have that in another file so then you can share it with the other file by using cextern pw_128 [13:36:17 CEST] <BBB> but in avfilter maybe not [13:36:29 CEST] <BBB> then, you typically shift, right? like psraw m0, 8 [13:36:37 CEST] <BBB> psraw=signed shift, psrlw=unsigned shift [13:36:41 CEST] <BBB> psllw=left-shift [13:36:58 CEST] <BBB> but you can also merge the add a shift together, by using pmulhrsw [13:37:25 CEST] <BBB> look up what that instruction does and how vp9/vp8 ssse3 code uses it and youll get quickly enough how that allows merging an add+shift into a single instruction [13:55:15 CEST] <Gramner> BBB: cpuflags_* is not a single flag bit, it's multiple, so & results in several bits. that's why the ^ is neccessary (since x ^ y == 0 iff x == y). otherwise correct [13:59:31 CEST] <BBB> ohright [13:59:32 CEST] <BBB> ok [14:35:46 CEST] <durandal_170> BBB: I did it but thing can overflow 16 bit when adding 128 [14:35:56 CEST] <BBB> nah [14:36:07 CEST] <BBB> having a pixel of 8 bit max value=0xff [14:36:15 CEST] <BBB> multiply by 256 gives 0xff00 [14:36:19 CEST] <BBB> adding 0x80 gives 0xff80 [14:36:22 CEST] <BBB> easily fits 16bit [14:37:46 CEST] <durandal_170> yes but last addition is also xff [14:41:21 CEST] <BBB> you could try a saturated add [14:41:35 CEST] <BBB> http://x86.renejeschke.de/html/file_module_x86_id_229.html [14:41:39 CEST] <BBB> paddusw [14:44:05 CEST] <durandal_170> I pushed wip to github [14:48:12 CEST] <durandal_170> well I don't think overflow do happen [14:52:52 CEST] <durandal_170> BBB: can you spot obvious bug? [14:53:14 CEST] <BBB> link to actual patch? [14:57:47 CEST] <durandal_1707> BBB: https://github.com/FFmpeg/FFmpeg/compare/master...richardpl:mm [15:40:33 CEST] <ubitux> ./configure --help|grep enable-hwaccel [15:40:41 CEST] <ubitux> ./configure --enable-hwaccel=vdpau --fatal-warnings [15:40:43 CEST] Action: ubitux sadness [15:41:59 CEST] <wm4> ? [15:42:42 CEST] <ubitux> the option --enable-hwaccel is not recognized [15:43:32 CEST] <durandal_170> this broke? [15:44:06 CEST] <ubitux> maybe, still trying to figure out what's going on [15:44:49 CEST] <ubitux> enable d3d11va dxva2 vaapi vda vdpau videotoolbox xvmc i wonder why these global vars are not prefixed by hwaccel_* [15:45:30 CEST] <ubitux> or maybe suffixed, i don't remember the convention [15:46:17 CEST] <BBB> durandal_1707: looks ok to me [15:46:31 CEST] <BtbN> It's codec_api_hwaccel [15:46:38 CEST] <BtbN> so for example hevc_vaapi_hwaccel [15:47:08 CEST] <nevcairiel> ubitux: those are not the hwaccels themself, but the depedency "libraries" [15:47:13 CEST] <nevcairiel> dependency* [15:47:24 CEST] <durandal_170> BBB: using unsigned shift I get better results [15:47:40 CEST] <ubitux> nevcairiel: ah yeah i remember now... [15:47:54 CEST] <BBB> durandal_170: unsigned shift (psrlw) should be right, yes [15:47:56 CEST] <ubitux> i need --enable-<hwaccel> [15:48:10 CEST] <durandal_170> But some super white become black [15:48:22 CEST] <BBB> hm& let me see [15:48:58 CEST] <BBB> so you have pixels, right? [15:49:01 CEST] <BBB> you subtract [15:49:10 CEST] <BBB> so you get a word range of -0xff,0xff [15:49:12 CEST] <durandal_170> Yes [15:49:18 CEST] <BBB> then you multiply with 0-0xff [15:49:32 CEST] <BBB> so you get something along the range of -0xff00,0xff00 [15:49:37 CEST] <BBB> ? [15:49:54 CEST] <BBB> so that doesnt fit in anything [15:49:58 CEST] <BBB> you may want to do two pmullws then [15:50:35 CEST] <BBB> so ignore the bilinear trick that I mentioned earlier (a*b+(256-a)*c+128>>8 = c+(a*(b-c)+128>>8) [15:50:40 CEST] <BBB> since that only works if you have a bit left [15:50:45 CEST] <BBB> so just do two pmullws [15:51:03 CEST] <BBB> and then the range of the output result should be 0-0xff00 again [15:52:40 CEST] <BBB> you should be able to use this trick for 10-14bpp [15:52:52 CEST] <BBB> just not for 8bpp [16:16:15 CEST] <durandal_170> BBB: what instruction do uint8 clipping? [16:16:25 CEST] <BBB> packuswb clips signed word to unsigned byte [16:16:40 CEST] <BBB> and at the same time moves them from word to byte packing [16:17:54 CEST] <durandal_170> now I can write simd for few blend modes [16:53:28 CEST] <BBB> durandal_170: ah so its working? cool [16:54:15 CEST] <durandal_170> I'm out of machine [16:54:56 CEST] <wm4> ubitux: should srt be able to handle entities? like ">" [16:55:24 CEST] <ubitux> are you crafting a file to tease me? [16:55:42 CEST] <RiCON> http://j.fsbn.eu/The.Daily.Show.2015.09.30.Chris.Christie.720p.CC.WEBRip.AA… [16:55:57 CEST] <RiCON> subs with these seem to only come from comedy central [16:56:03 CEST] <ubitux> wm4: if you have a file like this, i suppose it has to [16:56:12 CEST] <ubitux> omg [16:56:14 CEST] <ubitux> :(( [16:56:51 CEST] <BBB> hehe :) [16:57:26 CEST] <nevcairiel> ubitux: i can make you any crazy-ass thing you want, if you're looking for busy-work [16:57:38 CEST] <ubitux> i'm really not :( [16:58:59 CEST] <nevcairiel> any semi-spec you find only mentions b/i/u/font tags, no mention of html entities [16:59:06 CEST] <nevcairiel> what even renders those [16:59:59 CEST] <RiCON> well, vsfilter doesn't [17:00:29 CEST] <RiCON> nor mpc-hc's internal renderer [17:00:53 CEST] <wm4> RiCON> subs with these seem to only come from comedy central <- so over youtube-dl? then it might be youtube-dl's fault [17:01:44 CEST] <nevcairiel> some players had problems with <> in the text in the past. someone might have thought its a smart idea to escape them [17:01:46 CEST] <RiCON> dunno if the group uses ytdl to rip it, nor can i test since CC videos aren't acessible here [17:02:44 CEST] <ubitux> rcombs had some escaping code no? [17:02:57 CEST] <ubitux> if it gets upstream maybe we could use it for srt [17:03:03 CEST] <ubitux> probably harmless [17:03:59 CEST] <wm4> RiCON: there must be at least one player which handles it [17:07:41 CEST] <RiCON> http://sprunge.us/XYHS?json [17:07:54 CEST] <RiCON> comedy central's flash player, I guess [17:09:04 CEST] <RiCON> so it is probably ytdl's issue [17:09:25 CEST] <RiCON> since they should convert the entities when converting from vtt to srt(?) [17:09:55 CEST] <wm4> I'd say so (and here I bet ffmpeg's vtt code doesn't handle this either?) [17:10:21 CEST] <kierank> lol webvtt [17:10:35 CEST] <kierank> I'd have loved wm4 and j-b in the same room as the webvtt people 3 years ago [17:10:40 CEST] <nevcairiel> fucking webvtt [17:10:53 CEST] <nevcairiel> because everything is a web browser these days [17:11:25 CEST] <ubitux> we could easily escape all the < &gtl &quot etc [17:11:44 CEST] <ubitux> but well, what about é etc [17:12:08 CEST] <ubitux> http://webdesign.about.com/od/localization/l/blhtmlcodes-fr.htm random fun [17:17:11 CEST] <cone-099> ffmpeg 03Sven Dueking 07master:5d4a3563f23d: qsvenc.c: use query to catch all kind of setting issues [17:22:08 CEST] <RiCON> ytdl uses ffmpeg to convert the subs, so I guess ffmpeg vtt code is supposed to deal with it [17:24:41 CEST] <RiCON> ubitux: you probably only need these escapes: http://dev.w3.org/html5/webvtt/#dfn-webvtt-escape-state [17:28:18 CEST] <ubitux> RiCON: ok [17:28:20 CEST] <ubitux> error: 'UTGetOSTypeFromString' is unavailable: not available on iOS [17:28:22 CEST] <ubitux> FU [17:28:24 CEST] <ubitux> FUUUU :( [17:28:31 CEST] <ubitux> vtb doesn't work anymore on ios [17:29:13 CEST] <nevcairiel> thats only part of ffmpeg_videotoolbox.c, not the actual hwaccel [17:29:17 CEST] <nevcairiel> so if you dont need that.. [17:29:23 CEST] <ubitux> except the dep is actually hard [17:29:50 CEST] <nevcairiel> fixing the dep should be easy [17:30:43 CEST] <ubitux> there is no dependency granularity between videotoolbox and ffmpeg_videotoolbox [17:30:51 CEST] <nevcairiel> yes, add one [17:30:52 CEST] <nevcairiel> :D [17:32:24 CEST] <nevcairiel> or even better, make the code to select a pixfmt dependent on that only [17:33:04 CEST] <ubitux> yeah, it's simpler [17:33:26 CEST] <ubitux> or maybe i'll add a ff_fuapple_UTGetOSTypeFromString [17:42:58 CEST] <ubitux> it's curious how the link on CoreServices doesn't complain though [17:55:35 CEST] <Gramner> BBB: i was thinking about adding a comment above the cpuflag() code in x86inc. how does "; Returns a boolean value expressing whether or not the specified cpuflag is enabled." sound? [17:56:22 CEST] <BBB> it sounds like adding a comment // a counter that iterates from 0 to num above a line int i; [17:56:43 CEST] <BBB> I dont think its necessary, its pretty obvious what it does [17:56:52 CEST] <BBB> how it does it, is a little bit convoluted [17:58:23 CEST] <Gramner> the macros in x86inc are basically an API though [17:59:53 CEST] <BBB> true [18:00:26 CEST] <BBB> ok, I guess the comment is fine [18:00:31 CEST] <BBB> for api doc purposes [18:00:45 CEST] <BBB> it still doesnt explain the elaborate set of operands that implements the api ;) [18:00:46 CEST] <Gramner> I thunk it makes sense to be more verbose there than in a random piece of code [18:02:03 CEST] <Gramner> x86inc is in general poorly documented but that's fairly standard when it comes to open source stuff [18:03:22 CEST] <Gramner> the go-to answer is basically "look at and/or copy some existing code and work from there" [18:03:37 CEST] <ubitux> we need a warning or something when a explicitely requested element is not actually enabled in the configure [18:04:13 CEST] <ubitux> --fatal-warnings mitigates some of it (if we typo), but not if a requested element is not enabled because of a missing dep [18:04:33 CEST] <ubitux> like, --enable-ffplay but missing sdl or sth like that [18:07:24 CEST] <BBB> Gramner: thats certainyl how I started [18:07:35 CEST] <BBB> Gramner: ask durandal_1707, he just started writing assembly today [18:13:00 CEST] <BBB> Gramner: and patch remains ok of course (I dont feel like responding on ML :-p) [18:13:31 CEST] <Gramner> ok, I'll just push it I guess, thanks [18:14:16 CEST] <BBB> ty! [18:14:22 CEST] <BBB> (it allows me to push one of my patches) [18:14:39 CEST] <BBB> or, well, at least makes it work [18:14:47 CEST] <BBB> the dir intra pred simd one [18:21:48 CEST] <cone-099> ffmpeg 03Henrik Gramner 07master:17710550c483: x86inc: Make cpuflag() and notcpuflag() return 0 or 1 [18:22:54 CEST] <BBB> Gramner: do you know if theres anything alongside pmaddqd? [18:23:01 CEST] <BBB> Gramner: if you see what I mean [18:23:31 CEST] <Gramner> 128-bit add? [18:23:37 CEST] <BBB> pmaddwd [18:23:45 CEST] <BBB> but dq instead of wd [18:23:59 CEST] <BBB> does that exist? can I emulate it somehow? [18:25:04 CEST] <Gramner> probably need to do separate multiplies and adds [18:29:57 CEST] <Gramner> pmuldq, psrlq, pmuldq, paddq or something [18:31:28 CEST] <durandal_170> cpuflags are global? [18:31:33 CEST] <Gramner> there's really not much consistency in the x86 instruction sets. some instructions are really good but nobody bothered porting them to other data types [18:34:57 CEST] <kierank> http://demuxed.com/live.html [18:34:59 CEST] <Gramner> durandal_170: the cpuflags variable is set by INIT_MMX/INIT_XMM/INIT_YMM and remains until the next invocation of INIT_* [19:28:15 CEST] Action: DHE is bisecting a regression/bug in libavformat/hlsenc.c [19:47:45 CEST] <J_Darnley> durandal_1707: You define the linesize arguments as integer so on x86_64 you need to sign-extend (movsx or the macro movsxifnidn) the registers before using the quadword versions. [19:56:13 CEST] <jamrial> no, he should use ptrdiff_t [19:57:03 CEST] <J_Darnley> Or that. I just sent an email with that comment and another [19:58:51 CEST] <cone-099> ffmpeg 03Carl Eugen Hoyos 07master:aea5db97f794: lavf/rawdec: Autodetect raw mlp streams. [20:00:47 CEST] <durandal_1707> I just fixed it [20:20:53 CEST] <durandal_1707> jamrial: what to use to copy one m to another? [20:21:04 CEST] <jamrial> mova [20:22:06 CEST] <durandal_1707> I do and it crashes [20:22:55 CEST] <jamrial> weird, can i see the code? pastebin or github [20:30:12 CEST] <durandal_1707> I changed order, perhaps thats problem? [20:30:26 CEST] <durandal_1707> function args* [20:31:53 CEST] <jamrial> ah, could be. if you change the prototype you'll have to change the cglobal line accordingly [20:40:48 CEST] <durandal_1707> jamrial: putting back lea fixes it [20:43:43 CEST] <jamrial> that's odd [20:43:59 CEST] <jamrial> are you replacing "lea reg, [reg + linesize]" with "add reg, linesize"? [20:45:35 CEST] <durandal_1707> oops, no [20:47:37 CEST] <DHE> I'll see if I can make a fix for #4900 [20:53:24 CEST] <durandal_1707> jamrial: can this function make use of newer instructions? [20:55:18 CEST] <jamrial> if you need them sure, but you'll have to duplicate the function to make sure the correct version runs on supported targets [20:55:54 CEST] <jamrial> the sse2 version of the function must not use newer instructions [21:00:28 CEST] <wm4> michaelni: apparently cbbd906be6150be38dfc14b6bc67dcac8da8aea4 break rtmpe [21:00:48 CEST] <wm4> and of course the commit doesn't indicate what the heck it's needed for [21:00:53 CEST] <wm4> (classic) [21:01:47 CEST] <wm4> especially fun because the flv data is muxed by lavf itself in this case [21:04:19 CEST] <superware> is cehoyos here? [21:04:47 CEST] <BtbN> Just look at the userlist? [21:06:59 CEST] <superware> maybe a different name here... this is his "tracker" name [21:07:50 CEST] <durandal_1707> he is not on irc [21:08:36 CEST] <durandal_1707> jamrial: what instructions? [21:09:42 CEST] <jamrial> anything newer than sse2. you asked if you could use newer instructions, so i assumed you had some in mind that could be used for this function [21:10:57 CEST] <Gramner> ssse3 and sse4 could possibly be useful [21:16:10 CEST] <durandal_1707> well I need exact instruction [21:16:19 CEST] <Gramner> see ML [21:19:47 CEST] <jamrial> Gramner: pmovzx is useful mainly when you can't afford having a register containing all zeroes (or with avx2 when you need to zero extend across lanes). It's not faster than punpck, so not really worth adding an sse4 version of the function just for that [21:21:36 CEST] <Gramner> that might be true I guess, I haven't used any of the sign/zero extension instructions from SSE4 in ages [21:26:25 CEST] <BBB> you x264 kids get to play all day with haswells and skylakes [21:26:52 CEST] <BBB> you dont understand us responsible adults who have to dig in the dungeons of realworld cpus [tm] [21:27:10 CEST] <BBB> *grumble* [21:27:13 CEST] <nevcairiel> i live in the real world and i have 2 haswells in my house :( [21:27:16 CEST] <Gramner> I don't have an skylake xeon with AVX-512... yet ;) [21:27:31 CEST] <nevcairiel> (and another in a remote server) [21:27:52 CEST] <BBB> yo intel wheres my skylake? [21:27:57 CEST] Action: BBB shouts in the void [21:28:55 CEST] <nevcairiel> i didnt buy skylake because the specs seemed rather underwhelming [21:29:05 CEST] <Gramner> normal skylakes aren't that interesting for writing asm though [21:29:20 CEST] <nevcairiel> simd wise it got nothing over a haswell anyway [21:29:24 CEST] <nevcairiel> and even performance wise it doesnt [21:29:26 CEST] <nevcairiel> so there is that [21:29:27 CEST] <nevcairiel> :D [21:29:30 CEST] <BBB> its interesting if the last thing you had was a core2 [21:29:38 CEST] <nevcairiel> buy a broadwell [21:29:47 CEST] <BBB> yo intel wheres my broadwell [21:29:55 CEST] <Gramner> it has more execution engines for some SIMD stuff, but doesn't really affect how you write code [21:29:59 CEST] <BBB> silence, still [21:30:14 CEST] <Gramner> it also has LESS execution engins for some MMX SIMD which is interesting [21:30:20 CEST] <nevcairiel> i was offered some intel hardware once, but silly me was honest and admitted in already having everything thats needed [21:30:24 CEST] <Gramner> i believe they're starting to deprecate mmx [21:30:54 CEST] <nevcairiel> they should just like emulate mmx in sse execution units [21:31:02 CEST] <Gramner> so porting some mmx to sse2 might be useul on skylake even if you only use half of the xmm registers [21:31:20 CEST] <nevcairiel> i wonder if we still have a b unch of code thats mmx-only [21:31:29 CEST] <nevcairiel> porting mmx to sse/sse2 isnt that big of a deal [21:31:33 CEST] <BBB> nevcairiel: ... [21:31:42 CEST] <BBB> nevcairiel: can you forward these emails to me? :-p [21:31:49 CEST] <nevcairiel> it was years ago [21:31:52 CEST] <BBB> the correct response is not I alreeady have it [21:32:02 CEST] <nevcairiel> and about gpu decoding support, not simd [21:32:04 CEST] <BBB> the correct response is I dont need it, but BBB here[CCed] does" [21:32:28 CEST] <BBB> he wants a new macbook pro, his old one is crapping out [21:32:33 CEST] <BBB> (or so) [21:32:48 CEST] <Gramner> you can get their compiler for free if you do non-profit open source things. isn't that enough?! [21:33:04 CEST] <nevcairiel> i just bought a macbook last year as a tax writeoff :( [21:33:05 CEST] <BBB> no [21:33:21 CEST] <BBB> oooooh thats right I can subtract macs from taxes [21:33:31 CEST] <BBB> can I subtract both a mbp as well as a mac pro? [21:33:33 CEST] <BBB> or is it either or? [21:33:40 CEST] <nevcairiel> what do i know [21:33:45 CEST] <nevcairiel> i dont think they would care here [21:33:51 CEST] <BBB> here=? [21:33:55 CEST] <nevcairiel> not US [21:33:55 CEST] <nevcairiel> :D [21:33:58 CEST] <BBB> crap [21:34:29 CEST] <nevcairiel> writing off individual hardware upgrades is always a bit harder, so a complete thing like a macbook was easier [21:34:36 CEST] <nevcairiel> and i needed something for some mac testing anyway [21:34:42 CEST] <nevcairiel> better than my old hackintosh, i guess [21:38:00 CEST] <BtbN> philipl, that 940M doesn't seem to support nvenc at all. At least OpenEncodeSessionEx fails with ERR_UNSUPPORTED_DEVICE [21:38:31 CEST] <nevcairiel> speaking about nvenc, i setup OBS the other night, and the nvenc encoder produces nothing but odd looking garbage :( [21:38:49 CEST] <BtbN> It worked for me when i wrote it. [21:39:00 CEST] <BtbN> No idea what they did to it though after i left. [21:39:14 CEST] <nevcairiel> x264 still worked, so i just used that for the time being [21:39:29 CEST] <BtbN> Did you set it to some strange lossless mode? [21:39:30 CEST] <nevcairiel> it just blocked me for like an hour when i was debugging the other end of my streaming chain =p [21:39:32 CEST] <Daemon404> BtbN, they follow MS naming...? [21:39:36 CEST] <nevcairiel> BtbN: nah just defaults [21:39:39 CEST] <Daemon404> (FunctionEx) [21:39:47 CEST] <nevcairiel> i should test ffmpeg and see if that works [21:39:51 CEST] <nevcairiel> or my driver maybe being screwed [21:39:56 CEST] <BtbN> Daemon404, yeah, seems like it [21:40:29 CEST] <Daemon404> when do we get OpenEncodeSessionW [21:40:31 CEST] <Daemon404> and A [21:40:54 CEST] <BtbN> As all functions are dynamicaly loaded, they can be named whatever you like anyway. [21:41:36 CEST] <Daemon404> 9 [21:41:37 CEST] <Daemon404> o [21:42:09 CEST] <BtbN> I wonder if it's just some unsupported parameter, some weirdness with this optimus laptop, or if there actualy is no nvenc unit in this GPU [21:45:06 CEST] <BtbN> yep, it actualy has no video engine. The hell [21:45:10 CEST] <nevcairiel> hm which header do i have to collect again for nvenc [21:45:13 CEST] Action: nevcairiel looks [21:45:17 CEST] <BtbN> nvEncodeApi.h [21:45:40 CEST] <BtbN> somewhere inside that 300MB zip archive [21:46:05 CEST] <nevcairiel> wasnt that the thing which actually hides somewhere in the samples folder [21:46:08 CEST] <BtbN> yes [21:46:09 CEST] <nevcairiel> not in a prominent "includes" folder [21:47:02 CEST] <nevcairiel> hey its only 92mb [21:47:21 CEST] <BtbN> oh, they removed the tons of sample yuv videos? [21:47:27 CEST] <nevcairiel> dunno [21:47:36 CEST] <nevcairiel> nvenc_5.0.1_sdk.zip .. 92.1mb [21:53:35 CEST] <Gramner> durandal_1707: oh another minor thing, it's customary to vertically align asm so that the first comma in each row is at the same column (exceptions for long lines are fine, stores are usually the main culprit) [21:56:44 CEST] <BBB> if anyone ever thought libvpx encoding was slow with vp9 [21:56:54 CEST] <BBB> try a vp10 encode compiled at -O0 running under valgrind [21:56:56 CEST] <cone-099> ffmpeg 03Paul B Mahol 07master:0701ff2c321e: avfilter/x86/vf_psnr.asm: fix typo [21:57:09 CEST] <DHE> what's your SPF rate? [21:57:32 CEST] <gnafu> Enough to prevent sunburn, that's for sure! [21:57:45 CEST] <Gramner> do you need 64-bit integers to measure SPF? [21:57:51 CEST] <Gramner> ;) [21:57:59 CEST] <nevcairiel> vp9 at least seems to have gotten a bit faster since I tested it a couple years ago [21:58:12 CEST] <DHE> Seconds Per Frame (1/fps) [21:59:03 CEST] <BBB> I think Im at multiple minutes per frame [21:59:06 CEST] <BBB> I might be approaching HPF [21:59:15 CEST] <BBB> its pretty painful [21:59:24 CEST] <nevcairiel> well no opts and valgrind [21:59:29 CEST] <nevcairiel> :D [22:00:04 CEST] <Gramner> is it possible to run valgrind valgrind <something>? [22:00:36 CEST] <BBB> Id like intel to reinstate moores law [22:00:41 CEST] <BBB> this isnt going anywhere [22:00:44 CEST] <BBB> its all intels fault [22:01:01 CEST] <ubitux> valgrind: You cannot run 'valgrind' directly. [22:01:13 CEST] <Gramner> that's lame [22:01:35 CEST] <BBB> if something takes 10 years to finish (1YPF), then according to moores law, it makes more sense to wait 2 years to run it, since then it finishes in 2.5 years [22:02:00 CEST] <BBB> take that, xkcd compiling! [22:02:57 CEST] <Gramner> doesn't moore's law only cover transistor density though? while that correlates somewhat with performance it's not linear [22:05:25 CEST] <kurosu_> iirc, most of the remaining mmx code is related to mpeg2 (grep -l '%%m' ../libavcodec/x86/*.c) [22:05:57 CEST] <JEEB> the libmpeg2 legacy? [22:06:06 CEST] <JEEB> aka the mpeg-2 GPL code :D [22:06:31 CEST] <BBB> no, native mpegvideo code also [22:06:35 CEST] <kurosu_> I don't know, might be code written during michael's first years on ffmpeg [22:07:45 CEST] <kurosu_> I have equivalent crime with vc1, but seeing how it is broken anyway and the existence of h/w acceleration for it... [22:08:19 CEST] <nevcairiel> wtf is wrong with my ffmpeg [22:08:59 CEST] <nevcairiel> http://pastebin.com/7zvnkDhN .. am i too dumb to use it today, or did something magical break somewhere [22:09:40 CEST] <wm4> ffmpeg maps to ffprobe? [22:09:40 CEST] <JEEB> o__O [22:09:47 CEST] <wm4> look at the version header [22:09:48 CEST] <JEEB> oh [22:09:49 CEST] <JEEB> yeah [22:09:51 CEST] <nevcairiel> wtf [22:09:51 CEST] <JEEB> lol [22:09:53 CEST] <nevcairiel> how did that happen [22:09:56 CEST] <nevcairiel> fucking make [22:10:06 CEST] Action: nevcairiel cleans [22:10:33 CEST] <nevcairiel> make still randomly barfs up on windows when using high concurrency (-j12 or such) [22:12:56 CEST] <jamrial> on windows, make might fail running strip on any of the binaries if i also have the build folder open in windows explorer, with an error about lacking permision to rename files or some such [22:13:18 CEST] <nevcairiel> ...and then replace ffmpeg.exe by ffprobe? [22:13:30 CEST] <jamrial> no, that never happened to me :p [22:14:14 CEST] <nevcairiel> anyway encoding with ffmpeg nvenc works [22:14:18 CEST] <nevcairiel> must just be obs being fucked [22:16:27 CEST] <BBB> kurosu_: you can try android cross-compiler [22:16:35 CEST] <BBB> kurosu_: (for arm/neon compiles) [22:33:32 CEST] <cone-099> ffmpeg 03Paul B Mahol 07master:f5afd1c738d4: configure: check rubberband version, allow only latest one [00:00:00 CEST] --- Fri Oct 2 2015

1 0

ffmpeg.log.20151001
by burek 02 Oct '15

02 Oct '15

[01:59:34 CEST] <HoloPed> hey all. How do I extract the last frame of a video using ffmpeg? Considering that I don't know the total number of frames. [03:36:27 CEST] <klaxa> HoloPed: you could use the reverse filter and do -vframes 1 [03:36:45 CEST] <klaxa> like: ffmpeg -i input.mp4 -vf revrse -vframes 1 out.png [03:37:33 CEST] <HoloPed> oh snap [03:37:36 CEST] <HoloPed> nice klaxa [03:37:39 CEST] <HoloPed> thanks [03:39:13 CEST] <klaxa> remember that this may take quite long depending on the track [03:39:22 CEST] <klaxa> and it's also somewhat wasteful [03:39:46 CEST] <klaxa> reading the file twice (once for finding out the duration and once for extracting the frame) would be a lot faster [03:40:45 CEST] <klaxa> err... s/track/input/ [03:40:51 CEST] <klaxa> HoloPed: ^ [04:56:26 CEST] <dabbler> I'm using ffmpeg to simply change container formats ("ffmpeg -i foo.flv -c copy foo.mp4"), but it's not preserving the encoding timestamp of the streams. Shouldn't it? [05:08:40 CEST] <dabbler> All the "encoded" and "tagged" timestamps, container-level and stream-level, are being replaced with 1904-01-01 00:00:00. [05:10:06 CEST] <dabbler> I could understand the logic of *updating* the container-level timestamps, since the container is being recreated, but not the stream-level timestamps. [05:18:48 CEST] <epitron> dabbler: whenever i run into a problem like that, i usually write a duct-tape script that copies over the metadata after the processing is finished :) [05:35:17 CEST] <dabbler> epitron: yeah, it'd be nice to not have to do that. also, the ffmpeg options are so overwhelming it'd probably take an hour to figure out what command would copy such timestamps over. :) [05:37:30 CEST] <epitron> dabbler: oh, i just meant like, grepping the output and extracting the metadata to strings, then writing it into the new file :) [05:37:44 CEST] <epitron> serious duct tape [05:38:03 CEST] <epitron> you're right though -- figuring out how to write that info could be a huge pain [05:39:00 CEST] <epitron> probably easier to patch the code [05:42:54 CEST] <klaxa> epitron: i'm not sure myself how it works, but maybe this manpage section helps: https://ffmpeg.org/ffmpeg.html#Advanced-options see: -map_metadata [05:43:26 CEST] <klaxa> also not sure if that'll work with what's not working for you right now [05:43:45 CEST] <epitron> klaxa: thanks! (this was dabbler's issue) [05:43:56 CEST] <klaxa> ah, oops [05:45:19 CEST] <epitron> my problem is getting QP working with nvenc [05:46:03 CEST] <dabbler> klaxa: yeah, i saw that. thing is, if I understand it correctly, if i used that switch, i'd have to list out every mapping to make, not just the ones it was failing to make by default [05:47:02 CEST] <klaxa> >Optional metadata_spec_in/out parameters specify, which metadata to copy. [05:47:09 CEST] <klaxa> so i guess by default it copies everything? [05:48:21 CEST] <dabbler> it doesn't clearly state it, but i assume it means it copies everything that it would make sense to preserve [05:49:04 CEST] <klaxa> have you tried running it? [05:50:09 CEST] <dabbler> running&? i've tried "ffmpeg -i foo.flv -c copy foo.mp4", and it obliterates all the timestamps [05:52:35 CEST] <dabbler> also seems relevant to deciphering default behavior: > These default mappings are disabled by creating [05:52:36 CEST] <dabbler> any mapping of the relevant type. A negative file index can be used to create a dummy mapping [05:52:36 CEST] <dabbler> that just disables automatic copying. [05:52:56 CEST] <dabbler> so there is automatic copying [05:53:02 CEST] <pinPoint> sine`: ok, thanks [05:55:09 CEST] <klaxa> i meant to just run the code like in the examples? i.e.: ffmpeg -i in.mkv -map_metadata 0 -c copy out.mkv [05:55:45 CEST] <klaxa> and see if that does what you want [06:28:08 CEST] <dabbler> hm. that appears to make it set every timestamp to a particular value, including ones that were 1970-01-01 in the input [06:28:44 CEST] <dabbler> i think it's copying the container timestamps to all the streams [09:37:37 CEST] <epitron> hmm.. still having trouble controlling the bitrate with nvenc_h264 [09:37:39 CEST] <epitron> https://www.ffmpeg.org/doxygen/2.7/nvenc_8c_source.html#l00772 [09:38:06 CEST] <epitron> it looks like there's a constqp setting, but -qp isn't wired up to the codec [09:38:26 CEST] <epitron> -qmin and -qmax kinda work... [09:40:49 CEST] <epitron> if i set them to the same value, and make that value really high, the file is a bit smaller :) [09:41:02 CEST] <epitron> using h264 by itself results in the smallest file though [09:41:07 CEST] <epitron> (with no settings) [10:40:55 CEST] <Eli12> Hello! I am having troubles with streaming and was wandering is someone could take a look at the command I'm using to direct me to my mistake.. [10:43:11 CEST] <Eli12> the command I've used is: ffmpeg.exe -y -f gdigrab -framerate 2 -i title="YouTube - Google Chrome" -an -f mpegts udp://127.0.0.1:12345 [10:43:42 CEST] <Eli12> when I'm opening VLC to to read the stream, I get a blank black screen [11:45:33 CEST] <CounterPillow> Is it possible for the "ass" video filter to load fonts from the mkv file attachments? [11:57:41 CEST] <relaxed> CounterPillow: it should do that by default with the subtitle filter [11:58:09 CEST] <CounterPillow> I don't remember it doing that but I think I used the "ass" filter; I'll try again [11:59:15 CEST] <relaxed> you want to copy them to the output or hardsub with the font? [11:59:21 CEST] <CounterPillow> hardsub [12:00:26 CEST] <relaxed> use the subtitle filter [12:01:38 CEST] <CounterPillow> thanks [12:02:06 CEST] <CounterPillow> aww, too bad fast seeking still breaks the timing [12:20:15 CEST] <CounterPillow> ah, solved it with -copyts and setpts [13:08:25 CEST] <feliwir> ffmpeg doesn't build with msvc 2015? [14:43:32 CEST] <Anoia> hi all [14:44:28 CEST] <Anoia> I'm doing some work that extracts decoded H.264 data (YUV420) into a Direct3D compatable buffer. Can anyone confirm the data layout in data[0,1,2]? [14:44:46 CEST] <Anoia> and the stride in any pointer/alignment requirements? [14:47:31 CEST] <Anoia> ahha, just found "For video the linesizes should be multiples of the CPUs alignment preference, this is 16 or 32 for modern desktop CPUs." [14:50:09 CEST] <deroad> Hi, i'm writing an app to record an rtmp stream, but i do not understand what i should do to save the stream in the same format i get fromthe network. i do not want to use a decoder, but i want to write directly the packet to a file. can someone enlighten me? [14:52:13 CEST] <deroad> do i need to alloc another AVFormatContext struct just to save the stream? [14:54:47 CEST] <svvitch> someone had memory leak with command like this http://pastebin.com/23yXT7Nv ? , how to avoid it [14:55:42 CEST] <svvitch> in a day it can use approxim 9GB of RAM [15:33:37 CEST] <Mavrik> deroad, you'll need to remux it so yeah [15:36:07 CEST] <durandal_170> svvitch: report it on tracker [15:37:45 CEST] <deroad> ok, thanks Mavrik [15:44:43 CEST] <svvitch> durandal_170: is seriously a bug? or maybe some hack with options [15:45:03 CEST] <durandal_170> bug [18:20:32 CEST] <sopparus> hello [18:20:56 CEST] <sopparus> is it possible to utilize amd VCE or OpenMax for encoding with ffmpeg under linux? [21:16:24 CEST] <pinPoint> c_14: looks like final cut pro loves .mp4-> prores 422 proxy. [21:16:27 CEST] <pinPoint> http://i.imgur.com/0pq0Ykh.jpg [21:16:43 CEST] <pinPoint> no complaints importing the file into timeline [23:20:20 CEST] <YaMoonSun> How do I turn a jpeg into a x264 video stream, and then import an audio stream to make an .mp4? [23:20:24 CEST] <YaMoonSun> 1fps [23:21:02 CEST] <YaMoonSun> Or frame per hour if that's even possible. [23:33:19 CEST] <c_14> ffmpeg -i jpg [23:33:21 CEST] <c_14> eh [23:33:47 CEST] <c_14> ffmpeg -framerate 1/3600 -i jpg -i audio -c:v libx264 -c:a copy out.mkv [23:36:01 CEST] <YaMoonSun> You can do multiple inputs? Here my dumb self was trying to use the -map feature on a directory.. smh [23:38:07 CEST] <DHE> -map 0:0 would be the jpg, -map 1:0 would be the audio. but the default is import everything [23:38:31 CEST] <c_14> s/everything/one video, one audio and one subtitle stream/ [23:38:50 CEST] <YaMoonSun> The mapping feature only works on media containers, not directories, am I right? [23:39:08 CEST] <c_14> ffmpeg doesn't work with directories [23:39:12 CEST] <YaMoonSun> The video seems to have worked, but won't play because I didn't specifiy a frame rate I don't think. [23:39:19 CEST] <DHE> unless someone wants to write such a feature. :) [23:39:28 CEST] <YaMoonSun> Cheers, thanks for your help so far man. [23:39:35 CEST] <DHE> closest is to make a movie out of a collection of files, but that's more a filename wildcard system [23:39:37 CEST] <YaMoonSun> .iso support would be nice as well =p [23:39:50 CEST] <c_14> Most players probably don't like the framerate being that low. Might want to duplicate frames with the output. or -loop 1 -t something [23:40:47 CEST] <c_14> DHE: there actually is preliminary fs-navigation support, but nobody really likes the feature so it's avpriv [00:00:00 CEST] --- Fri Oct 2 2015

1 0