[00:13:54 CET] <cone-066> ffmpeg 03Paul B Mahol 07master:681f83361026: avfilter/vf_waveform add support for other scalers for graticule [00:16:41 CET] <cone-066> ffmpeg 03Paul B Mahol 07master:1a5895757db8: avfilter/vf_waveform: fix indentation [00:46:09 CET] <cone-066> ffmpeg 03Michael Niedermayer 07master:b2ab3398f59e: avformat/hlsenc: Fix passing options, regression since bc9a5965c815cf7fd998d8ce14a18b8e861dd9ce [03:23:28 CET] <michel71> Hello all. I have been referred to this IRC to inquire as to how I could contribute to the FFMpeg project. [03:24:25 CET] <michel71> I am currently a graduate student in EE, and my research topic is related to signal processing. Any idea where I could start? [03:33:38 CET] <Shiz> in light of a specific program or in general? [03:34:29 CET] <Compn> michel71 : any experience in C or asm ? [03:36:57 CET] <michel71> In general, especially to those topics that are mathematical in nature. I have experience in C, but almost none in assembly. [03:38:44 CET] <J_Darnley> If you didn't realise, Shiz was asking whether you are looking to apply to GSOC or Outreachy. [03:39:03 CET] <Shiz> yes, that [03:39:09 CET] <Shiz> i worded it rather poorly [03:39:55 CET] <Shiz> gsoc prep is in full force right now, so there's quite a few people whoo come in and ask about in light of it [03:40:25 CET] <rcombs> lovely ticket there [03:40:35 CET] <rcombs> "please use Core Image for& something or other" [03:40:37 CET] <J_Darnley> Yes, I've seen them pop up everywhere [03:41:00 CET] <michel71> Oh, sorry. Nothing related to GSOC or Outreachy. [03:41:17 CET] <J_Darnley> That's fine. I just thought everyone should be clear. [03:41:45 CET] <jamrial> michel71: get familiar with the code. look at existing decoders and encoders, see if you can improve them in some way [03:42:01 CET] <J_Darnley> Start by making sure you can compile it. [03:42:02 CET] <jamrial> maybe look at trac and see if you can find a bug ticket you can fix [03:42:17 CET] <Shiz> yeah the best source for things to work on is probably the trac [03:42:30 CET] <cone-066> ffmpeg 03Ganesh Ajjanagadde 07master:66edd8656b85: lavc/lpc: exploit even symmetry of window function [03:44:14 CET] <michel71> Thanks, I will definately check out the Trac Issue Mailing list. [03:44:32 CET] <Shiz> for new things, the 'enhancement' and 'task' types are probably what you want to filter for, but there's also plenty of bugs out there [03:44:51 CET] <Shiz> http://ffmpeg.org/developer.html this is also generally useful [03:47:42 CET] <michel71> Thanks for the reference, I'll check them out. [03:48:41 CET] <michel71> Any idea on the required mathematical prereqs? Linear Algebra, Numerical Analysis, etc? [03:49:04 CET] <J_Darnley> high school algebra [03:49:19 CET] <J_Darnley> so that you understand variables and math with no numbers [03:49:44 CET] <Shiz> also depends in what area you want to contribute, probably [03:50:20 CET] <Shiz> improving an upscaler has different needs than adding support for a streaming protocol [03:51:29 CET] <michel71> Ah okay, right, sounds good. Thanks for all the info, much appreciated, I'll get to reading. [03:52:12 CET] <Shiz> don't be afraid to ask (not too vague) questions [03:52:24 CET] <Shiz> just be aware of a possible response delay [09:09:44 CET] <ismail> durandal_1707: noone paid but please consider donating me 100k ¬ [09:52:35 CET] <cone-137> ffmpeg 03Paul B Mahol 07master:119c108b31c0: avfilter/vf_waveform: fix ire8 for 25% [10:00:41 CET] <durandal_1707> ismail: 100k, yes Sir [10:02:39 CET] <wm4> ismail: done, subtracted 50k taxes, and 50k no-fun fee [10:03:22 CET] <ismail> wm4: mpv tax? Worth it :P [10:05:27 CET] <wm4> no-fun tax actually [10:06:39 CET] <ismail> you can't tax & fee for the same thing [10:06:50 CET] <wm4> oh yes we can! [10:07:19 CET] <wm4> wow there's a ticket for using coreaudio for decoding [10:10:50 CET] <ubitux> i'm trying to play with .altmacro (gas) to do something like v%(1+1).8H [10:11:17 CET] <ubitux> (to point on a specific simd reg) [10:11:25 CET] <ubitux> but can't make it work [10:11:28 CET] <ubitux> any suggestion? [10:26:14 CET] <cone-137> ffmpeg 03Paul B Mahol 07master:867637caeab5: avfilter/vf_waveform: fix and extend millivolts grat lines [10:26:23 CET] <wbs> ubitux: you may need to wrap it in a separate macro, so that the 1+1 thingie is a macro parameter and gets evaluated there [10:26:45 CET] <ubitux> mmh ok, let's try [10:26:47 CET] <wbs> ubitux: in general, altmacro is problematic, it's one of the few gas features that clang hasn't implemented yet afaik [10:27:10 CET] <wbs> (so when I end up with something where I would like to do arithmetic like that, I go for a more verbose solution than rely on altmacro) [10:27:45 CET] <ubitux> yes, we can't build for android with the clang in the ndk [10:27:58 CET] <ubitux> are we supposed to use gas pp here as well? [10:28:13 CET] <ubitux> anyway, i just discovered noaltmacro because of this, so now i want to use it :$ [10:28:45 CET] <wbs> noaltmacro? [10:29:00 CET] <ubitux> sorry, altmacro [10:29:09 CET] <wbs> ah, k [10:29:16 CET] <wbs> yes, clang builds for 32 bit arm need gas-pp due to this [10:29:37 CET] <ismail> https://llvm.org/bugs/show_bug.cgi?id=18918 looks like stalled. [10:29:40 CET] <wbs> I guess clang says "patch welcome" if you nag them about it; it's a feature that e.g. the linux kernel doesn't use (afaik) so those who improved the gas compat in clang haven't bothered [10:29:53 CET] <wbs> janne filled in a lot of the other details, but this one is still not done [10:30:37 CET] <ubitux> alright, so enabling gaspp is not specific to darwin [10:30:48 CET] <ubitux> but just clang gas [10:31:17 CET] <wbs> no, not specific to clang gas either [10:31:37 CET] <nevcairiel> to any "non-gnu gnu assembler" =p [10:31:37 CET] <wbs> it's for anything that doesn't fulfill everything that our gas asm (either arm or ppc) requires [10:31:54 CET] <wbs> before clang, apple still used binutils gas [10:32:00 CET] <wbs> ... forked from upstream binutils around 1991 [10:32:06 CET] <nevcairiel> haha [10:32:12 CET] <wbs> so it lacked most of the actual gas features [10:32:18 CET] <wbs> this is what gas-pp was written to support initially [10:32:26 CET] <wbs> later clang came along, and didn't support much more gas stuff either [10:32:35 CET] <wbs> then clang was fixed to be able to build the linux kernel, and stuff improved [10:32:52 CET] <wbs> and janne fixed some more stuff, so for aarch64, you don't need gas-pp, but for arm you still need for altmacro [10:32:59 CET] <wbs> and then I fixed stuff for microsoft compilers [10:33:15 CET] <wbs> since they have a completely different syntax, but gas-pp can output that as well [10:33:39 CET] <wbs> so instead of just expanding the macros, it rewrites all the directives (most of the asm itself passes through pretty much unchanged) [10:33:57 CET] <wbs> so today you need it for apple-gas, clang-anything, and ms armasm [10:36:54 CET] <ubitux> http://sprunge.us/hCdW :( [10:37:06 CET] <ubitux> well, whatever :) [10:40:06 CET] <ubitux> anyway, ok for gaspp, thanks [10:40:08 CET] <wbs> move the altmacro/noaltmacro to around the foo %() call [10:40:25 CET] <ubitux> ooh [10:40:30 CET] <ubitux> thanks! [10:40:38 CET] <ubitux> nice :) [10:44:46 CET] <mateo`_> wbs: thanks for the info, i'll give another try at building ffmpeg with clang3.8+gas-pp for arm [10:45:29 CET] <ismail> you can also use -no-integrated-as [10:45:33 CET] <ismail> for clang [10:45:41 CET] <wbs> ah, yes [10:47:06 CET] <mateo`_> ismail: what does -no-integrated-as do ? [10:47:37 CET] <ismail> mateo`_: it disables clang's internal assembler and uses gas [10:47:43 CET] <ismail> which will fix assembler errors [10:55:28 CET] <ubitux> http://sprunge.us/HjER thanks wbs :D [11:05:24 CET] <mateo`_> ismail: thanks a lot, the build succeeded [11:08:59 CET] <ismail> mateo`_: you are welcome. [11:28:24 CET] <nevcairiel> changed all my windows fate boxes to use dash instead of bash, lets see if something breaks next run! [11:29:08 CET] <fritsch> any reason to do so? working towards "sh compatibility"? [11:29:32 CET] <nevcairiel> dash is just much faster on windows for some reason [11:29:56 CET] <ubitux> i'm running my configure with dash locally all the time [11:30:23 CET] <nevcairiel> presumably using busybox would be much faster still [11:30:31 CET] <nevcairiel> but no clue how much that would break [11:31:45 CET] <ubitux> /bin/bash ./configure > /dev/null 11.77s user 0.71s system 78% cpu 15.910 total [11:31:47 CET] <ubitux> /bin/dash ./configure > /dev/null 3.31s user 0.44s system 55% cpu 6.794 total [11:31:55 CET] <cba321> i am also trying to check this channel to comply with a message in the code to "please do not contact google" [11:32:28 CET] <nevcairiel> ubitux: here its something like 150s vs 100s =p [11:32:53 CET] <cba321> is this the right channel to speak to ffmpeg.org [11:34:30 CET] <cba321> why put a message in the code to not let google know anything...if no one from ffmpeg is around [11:35:44 CET] <wm4> cba321: where? [11:36:32 CET] <cba321> wm4...ok i will be happy to report the issue to the right person who put the message in the code...so that google can't find out anything. [11:36:49 CET] <cba321> wm4...are you a ffmpeg developer [11:38:14 CET] <fritsch> cba321: that does not matter - post a link to the file in question ... [11:38:43 CET] <cba321> fritsch...hell yes it does matter....i respect coders wishes...maybe you don't respect anything you damn motherfucker [11:39:03 CET] <BtbN> is this some next level trolling? [11:39:16 CET] <wm4> apparently so [11:39:19 CET] <fritsch> i think it is [11:48:47 CET] <mateo`_> cba321: where is this message located ? [11:49:13 CET] <cba321> mateo...who are you..are you a ffmpeg developer...i am trying to comply with the message. [11:49:30 CET] <ubitux> lol [11:49:37 CET] <ubitux> who knows [11:49:40 CET] <ubitux> better not trust him [11:50:25 CET] <cba321> i don't give a shit who or what you trust....i am trying to comply with a message by a small developer that doesn't want to be runover by big sharks. [11:50:56 CET] <BtbN> Well, the ffmpeg codebase is entirely open, so google already indexed that holy file anyway. [11:50:58 CET] <ubitux> there are a few google spies here [11:51:23 CET] <BtbN> I also highly doubt ffmpeg contains any message like that. [11:51:48 CET] <cba321> BtbN...obviously you don't spend time with the code to try to make anything work [11:52:36 CET] <cba321> BtbN if you don't even know what messages are contained in various projects [11:55:10 CET] <nevcairiel> if you think anyone is going to talk to you after you already insulted the first person, you are surely misguided [11:55:25 CET] <ubitux> nevcairiel: well, you still talk with mats :° [11:55:41 CET] <cba321> nevcairiel...ask me if i give a shit...if the shoe fits...wear it you god damn bastards. [11:56:19 CET] <cba321> nevairel..i respect the lowly..not the giant monsters [11:58:55 CET] <cba321> what made Tifa famous is that she was merely a lowly bartender....who was able to rise to conquer the world as well as some crackpot who thought he was God. [11:59:54 CET] <ritsuka> you know, this channel is called ffmpeg-devel, is not like the people here are totally unrelated with ffmpeg, you can just post your error and be done [12:00:31 CET] <cba321> ritsuka...go to hell...i am trying to make sure information does not fall into the wrong hands...this is at the request of a lowly programmer. [12:00:53 CET] <fritsch> i could not parse your request, sorry ... [12:01:09 CET] <ubitux> cba321: so what are you going to do? [12:01:17 CET] <cba321> fritsch...well maybe you don't know how to configure the right parser for the right formats [12:02:00 CET] <wm4> "checking value of MSG_OOB... 1" dear god why would you do this, glib [12:02:22 CET] <nevcairiel> wm4: configure scripts are full of such crazy things [12:02:45 CET] <wm4> sometimes they seem to be a little bit too crazy [12:03:09 CET] <cba321> nevcairiel...why don't you try to learn grep , egrep, fgrep and so on to save some time looking for things [12:04:18 CET] <fritsch> why don't you learn to use tab completion to save time and write other's names correctly? [12:06:05 CET] <cba321> well if nevcairiel is not the right word...that is too bad...because that is what i see here. [12:14:48 CET] <ubitux> i miss the guy already [12:15:10 CET] <mateo`_> well that was entertaining [12:15:56 CET] <nevcairiel> someone invent the remote punching machine for me [12:18:00 CET] <nevcairiel> the message he saw probably came from libvpx itself or something, which makes it even funnier [12:20:32 CET] <mateo`_> look at #ffmpeg :D [12:21:45 CET] <ubitux> http://sprunge.us/acOK for those not on #ffmpeg [12:21:55 CET] <nevcairiel> should get him K-lined just out of spite =p [12:29:35 CET] <rcombs> oh no, google's going to get our precious& sample files? [13:08:23 CET] <rcombs> "+1 for this enhancement" [13:08:27 CET] <rcombs> how extremely useful [13:09:07 CET] <rcombs> any reason not to just merge the lavc audiotoolbox stuff [13:09:39 CET] <rcombs> might have some issue around end behavior in HE-AAC, but there's no such thing as a regression in a new encoder [13:19:34 CET] <wm4> rcombs: I'm noticing you never seem to set any codeccontext parameters (except sample_fmt) [13:20:01 CET] <wm4> and channels, maybe [13:20:11 CET] <wm4> what about sample rate and channel layout? [13:21:05 CET] <rcombs> audiotoolbox's assumptions around that are kinda weird [13:21:13 CET] <rcombs> seems to expect you to set them early on [13:21:46 CET] <nevcairiel> it expects you to know them before calling the decoder? [13:21:48 CET] <rcombs> but I could probably try reading the values back after sending extradata and each frame [13:21:50 CET] <nevcairiel> that will end up breaking =p [13:21:53 CET] <wm4> even for formats which fully have them in the headers? [13:22:03 CET] <rcombs> nevcairiel: it expects to get _something_, at least [13:22:03 CET] <wm4> like mp3 or ac3 should have [13:24:29 CET] <rcombs> fortunately the bitmap format for channel layouts is the same in lav* as in audiotoolbox [13:25:06 CET] <nevcairiel> its just the wav way! [13:25:06 CET] <rcombs> (iirc the ordering comes from mpeg or the like, so makes sense) [13:25:37 CET] <wm4> well that means nothing, 3 channels still could be either 2.1 or 3.0 etc. [13:25:46 CET] <rcombs> yeah [13:26:18 CET] <rcombs> just means that when moving channel layout bitmaps between lavc and at, I don't have to remap anything [13:26:38 CET] <rcombs> nor when actually moving around audio data [13:30:07 CET] <nevcairiel> using the wave/riff layout is so common that even apple couldnt pretend to invent a new one, i suppose [13:30:33 CET] <andrey_utkin> I am sorry, is Claudio Freire here? I want to ask regarding "AAC encoder 3x performance drop in 3.0 since Oct 2014" topic [13:32:07 CET] <rcombs> andrey_utkin: tl;dr the AAC encoder had some major improvements made focused on output quality/efficiency, and there hasn't been much time spent optimizing that new code for speed yet [13:32:30 CET] <kierank> send patches [13:32:31 CET] <rcombs> or, well, not enough time to get it back near where it used to be on speed [13:32:45 CET] <andrey_utkin> I just want to ask if I can currently speed things up by, like, turning off twopass [13:32:52 CET] <andrey_utkin> because bitrate is not a concern [13:32:59 CET] <rcombs> twopass in AAC? [13:33:13 CET] <nevcairiel> he means twoloop, and no, all the alterntives are crap [13:33:35 CET] <rcombs> you could try `-aac_coder fast`, but you'll pay in quality [13:33:37 CET] <nevcairiel> you could try the fast coder, but i believe its extremely bad [13:33:57 CET] <andrey_utkin> err twoloop [13:34:19 CET] <andrey_utkin> i tried fast coder, no significant change [13:35:03 CET] <andrey_utkin> i am not proficient enough to patch encoder, I can probably fund the development somewhat [13:35:22 CET] <kierank> make some perf reports perhaps [13:37:13 CET] <nevcairiel> you could try vbr, from what I understand a major speed problem is that the psy produces rather bad guesses, making the encoder work hard to reach the target bitrate .. maybe that wouldnt have such a big impact in vbr [13:38:58 CET] <nevcairiel> recent changes to aacenc should have already made it 20-30% faster [13:41:25 CET] <kierank> ak____: hello [14:02:28 CET] <nevcairiel> so i broke my fate boxes earlier today, and for some reason t he fate website has already swallowed their entries [14:02:30 CET] <nevcairiel> how odd [14:02:39 CET] <nevcairiel> usually they take month to disappear if inactive [14:03:57 CET] <ubitux> i haven't updated my --disable-everything fate instance since 11 days and it's still there [14:04:12 CET] <nevcairiel> no clue why those vanished so quickly [14:04:19 CET] <ubitux> did they broke by uploading empty reports or sth? [14:04:21 CET] <nevcairiel> hope they come back when a fixed run goes through now =p [14:04:34 CET] <nevcairiel> dont think the rpeort was empty, just very short [14:04:48 CET] <ubitux> empty or simply broken in a way fate doesn't like them [14:05:04 CET] <ubitux> anyway, better ask Timothy_Gu [14:06:35 CET] <nevcairiel> it failed configure and the report reflected as much [14:06:36 CET] <nevcairiel> oh well [14:07:05 CET] <nevcairiel> i made a copy of the report if Timothy_Gu is interested later [14:30:51 CET] <toot> hi, can someone help me, and say how to add/register a new demuxer? i've searched documentation, but found almost nothing [14:32:08 CET] <Compn> you can check git log for when another demuxer was added [14:32:12 CET] <Compn> and then just copy what was done [14:33:12 CET] <toot> surely, thanks [14:45:32 CET] <wm4> toot: libavformat/allformats.c [14:45:53 CET] <wm4> the configure script parses this (which causes most of the confusion) [14:46:59 CET] <rcombs> yeah, add to allformats.c and libavformat/Makefile [14:50:29 CET] <wm4> rcombs: btw. what's the state of your ordered chapters patch, and does it have edition support? [14:51:06 CET] <rcombs> sitting around largely functional but in need of better error detection and handling (and probably better perf), and yes [14:51:24 CET] <wm4> performance? [14:51:46 CET] <rcombs> opening files to check if their UUIDs are what we're looking for [14:51:51 CET] <wm4> right [14:51:52 CET] <rcombs> it's currently slower than it could be [14:51:58 CET] <rcombs> does more seeks than necessary [14:52:12 CET] <wm4> it should probably just open a raw stream and do some manual ebml parsing [14:52:15 CET] <wm4> does it have edition support? [14:52:41 CET] <rcombs> yes [14:53:24 CET] <wm4> how? [14:53:45 CET] <rcombs> iirc just an AVOption for which edition to use [14:54:17 CET] <wm4> I see [14:54:25 CET] <rcombs> the 3 big things I wanted to add were support for changing extradata (by sending packet side data indicating the change), for providing a list of files to check on the CLI (as opposed to scanning the dir [which would still be the default]), and for exposing the editions through some API [14:55:40 CET] <rcombs> wm4: oh, wait, I just hardcoded it to use the first edition right now [14:55:50 CET] <rcombs> but doing the AVOption thing would be trivial [14:56:06 CET] <rcombs> it's got full support for it and just always picks the first one [14:56:48 CET] <wm4> what I'd like to have is if the demuxer could export the full ordered chapter info, so that API user (mpv) can do it on its own [14:57:22 CET] <rcombs> yeah [14:57:59 CET] <rcombs> I mean, I could stick it in an AV_OPT_TYPE_BIN with some defined struct format if I wanted [14:58:12 CET] <rcombs> and say you're not allowed to modify it [14:58:19 CET] <wm4> maybe glorious side data [14:58:31 CET] <rcombs> is there demuxer-level side data? [14:58:32 CET] <wm4> I also need to add some other features, like subtitle preroll [14:58:35 CET] <rcombs> or metadata I guess [14:58:36 CET] <wm4> I think so [14:58:49 CET] <rcombs> but it seems like we might want a proper API for this sort of thing [14:59:09 CET] <rcombs> remind me how "programs" work right now? [14:59:17 CET] <rcombs> (that's an mpegts thing, right?) [14:59:29 CET] <wm4> ah I was wrong, no demuxer side data yet [14:59:33 CET] <wm4> just AVStream [14:59:39 CET] <wm4> yes [14:59:39 CET] <rcombs> yeah [15:03:20 CET] <nevcairiel> bl [15:03:22 CET] <nevcairiel> woops [15:03:40 CET] <rcombs> nevcairiel's into BL? [15:04:07 CET] <Daemon404> or worse [15:04:08 CET] <Daemon404> arm assembly [15:04:09 CET] <rcombs> or is this ARM or PPC ASM (I forget which uses that syntax for "branch if lower") [15:04:25 CET] <rcombs> Daemon404: hah [15:04:53 CET] <Daemon404> :D [15:05:12 CET] <nevcairiel> just not info shifting focus while typing [15:05:25 CET] <rcombs> ENOTTY [15:15:38 CET] <Daemon404> does mats not understand the concept of a bug tracker [15:31:53 CET] <kierank> J_Darnley: any luck with haar? [15:46:36 CET] <J_Darnley> I haven't been working on it [15:47:29 CET] <J_Darnley> I've been too busy wasting time on the internet trolling and shitposting [15:47:56 CET] <Daemon404> hopefully those shitposts are dank memes [15:49:18 CET] <J_Darnley> No. I am too poor in dank memes [16:04:59 CET] <durandal_170> he got free job at #ffmpeg [16:05:37 CET] <Daemon404> act [16:05:42 CET] <Daemon404> woops [16:05:52 CET] <thardin> did someone say memes? [16:06:11 CET] <Daemon404> not memese [16:06:12 CET] <Daemon404> dank memes [16:06:42 CET] <thardin> ofc. no one wants stank memes [16:10:08 CET] <Daemon404> https://github.com/blog/2119-pull-request-and-issue-reactions [16:10:13 CET] <Daemon404> but we still cant disable PRs [16:11:08 CET] <wm4> imagine a code base where disabling this can't be a simple flag, while for issues it can [16:13:33 CET] <Daemon404> wm4, yes [16:20:59 CET] <J_Darnley> if you disable pull requests people might discover that there are other ways to contribute that don't even have to involve github [16:21:49 CET] <Daemon404> :D [16:57:18 CET] <Gramner> obviously they want you to use their service instead of going somewhere else [17:03:59 CET] <BBB> should by bsf change bump micro or minor? [17:04:16 CET] <durandal_170> mayor [17:04:28 CET] <BBB> that seems mildly aggressive [17:06:39 CET] <BBB> Ill bump micro then? [17:08:29 CET] <BBB> new bsf, maybe & minor? [17:08:30 CET] <Shiz> should cause a library rename [17:08:31 CET] <BBB> I dont know [17:10:42 CET] <iive> it breaks abi and api, of course it should be the mayor [17:11:09 CET] <iive> ;) [17:15:21 CET] <BBB> it only breaks some eggs [17:19:39 CET] <cone-338> ffmpeg 03Ronald S. Bultje 07master:6d8ab358a3c2: lavf: allow BSFs to drop packets. [17:19:40 CET] <cone-338> ffmpeg 03Ronald S. Bultje 07master:2e6636aa8730: vp9: add superframe merging bitstream filter. [17:48:10 CET] <jamrial> BBB: can the new bsf be invoked by the user, for example with the cli, or is it autoinjected only? [17:48:20 CET] <BBB> both [17:48:38 CET] <BBB> it automatically adds itself when muxing vp9 into ivf or mkv [17:48:38 CET] <jamrial> then you should have bumped minor, since it's a new component :p [17:48:44 CET] <jamrial> at least that's how it always goes [17:48:50 CET] <BBB> -ETOOLATE [17:49:03 CET] <nevcairiel> that is rather arbitrary anyway [17:49:08 CET] <nevcairiel> cli users dont care about the versions [17:49:10 CET] <BBB> feel free to change minor, I dont mind [17:50:12 CET] <kierank> where's a good place to upload large files [17:50:42 CET] <wm4> does anyone care about the versions? [17:50:50 CET] <jamrial> mega? [17:53:50 CET] <kierank> upload speed very very slow [17:54:28 CET] <wm4> what's the file size? [17:57:13 CET] <kierank> A bunch of files totalling 20GB or so [17:57:33 CET] <wm4> ok that's huge [17:57:44 CET] <kierank> I guess I have a box.net account [17:57:54 CET] <kierank> I wonder if it'll let me upload directly [17:58:52 CET] <kierank> nope files too big [20:07:19 CET] <jamrial> BBB: i'm getting a lot of "[NULL @ 000001980e815040] Invalid superframe packet size: 15108867 frame size: 249065" error messages decoding a webm file i created using codec copy from another webm as source [20:07:23 CET] <jamrial> decoding doesn't fail, but the md5 output is different than before [20:07:53 CET] <BBB> after my patch just now? [20:07:56 CET] <jamrial> yeah [20:07:59 CET] <BBB> huh... [20:08:05 CET] <BBB> how do I reproduce? [20:08:35 CET] <jamrial> i used the tears of steel vp9 video ubitux or nevcairiel made back when you first benched the decoder [20:08:39 CET] <jamrial> tos3k-vp9-b10000.webm [20:09:20 CET] <jamrial> i did a simple "./ffmpeg -i tos3k-vp9-b10000.webm -c:v copy -t 10 tos.webm" then "./ffmpeg -i tos.webm -f md5 -" [20:09:27 CET] <BBB> let me try... [20:10:00 CET] <jamrial> muxing is also considerably slower now, but i guess it's to be expected since it's running the bsf code [20:12:46 CET] <BBB> it shouldnt be slower [20:12:56 CET] <BBB> I mean its not that much overhead [20:14:32 CET] <BBB> oh well [20:14:38 CET] <BBB> not sure what happened here [20:14:46 CET] <BBB> but it seems like were writing the index in BE but reading it in LE [20:14:50 CET] <BBB> that would be & troubling [20:14:55 CET] <BBB> how did this work originally? [20:19:00 CET] <BBB> (writing a fix) [20:22:54 CET] <BBB> jamrial: fix on ML [20:23:01 CET] <BBB> jamrial: with that, the two MD5s are identical for me [20:24:24 CET] <jamrial> actually, nevermind about the muxing speed thing. the file wasn't cached on memory the first time i ran it so it seemed slower [20:24:34 CET] <BBB> makes sense then [20:24:38 CET] <BBB> ty for testing [20:27:00 CET] <jamrial> i see nothing on the ml [20:27:07 CET] <jamrial> and no prob [20:30:37 CET] <jamrial> ah, there it is [20:33:04 CET] <nevcairiel> how did that ever work =p [20:33:29 CET] <jamrial> BBB: works great now, thanks [20:40:37 CET] <BBB> like my kid sometimes says [20:40:44 CET] <BBB> dont ask me questions like that I dont like it!" [20:42:53 CET] <cone-259> ffmpeg 03Ronald S. Bultje 07master:abedde65d1ce: vp9_superframe: fix endianness of size markers. [20:43:27 CET] <BBB> so I think trac is lacking any further vp9 tickets except some trivial signed integer leftshifts which are silly but Ill fix them anyway [20:47:10 CET] <jamrial> BBB: did you check that argon streams thing someone mentioned the other day? [20:47:26 CET] <BBB> google did [20:47:33 CET] <BBB> I dont have the streams [20:48:07 CET] <jamrial> can't you get your hands on them? would be nice to check your decoder with it [20:48:32 CET] <BBB> I dont think they were run under all combinations of ubsan, asan, helgrind, tsan etc, but just a plain md5 check matches between ffvp9/libvpx for all streams [20:48:35 CET] <jamrial> then again, ffvp9 coverage seems to be above 90% [20:48:42 CET] <BBB> I could probably buy them, but what do I care [21:53:22 CET] <BBB> jamrial: wanna review the other vp9 patch? [22:06:38 CET] <BBB> ty [22:07:41 CET] <cone-259> ffmpeg 03Ronald S. Bultje 07master:b86339a9f8d7: vp9: fix a few signed integer left-shifts. [22:54:36 CET] <llogan> "lavf/riffenc: Improve spec compliance" 28 of 33 messages are one guy talking to himself. [22:55:13 CET] <jamrial> Mats? [22:55:27 CET] <llogan> RE: RE: RE: RE: yes. [22:56:19 CET] <llogan> i guess some of those are replies to real replies, but i still don't get his methodology [22:58:31 CET] <BBB> mats is crazy yes [23:01:52 CET] <BBB> weve told him several times to not do that [23:01:55 CET] <BBB> he just doesnt listen [23:06:03 CET] <llogan> also, why the interest in riff? [23:10:30 CET] <cone-259> ffmpeg 03Paul B Mahol 07master:817d0c6da26b: avfilter/vf_waveform: add parade display mode [23:57:49 CET] <cone-259> ffmpeg 03Shivraj Patil 07master:15ef98afd10b: configure: build fix for P5600 along option --disable-msa [00:00:00 CET] --- Sat Mar 12 2016