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

[burek]

[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