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

[burek]

[00:29:56 CEST] <cone-590> ffmpeg 03Vittorio Giovara 07master:960b4d47612e: decode: Initialize ret before using it
[00:39:16 CEST] <cone-590> ffmpeg 03Philip Langdale 07master:181aa1be4934: avcodec/crystalhd: Explicitly set frame pts at all times
[00:39:17 CEST] <cone-590> ffmpeg 03Philip Langdale 07master:dd49eff93095: avcodec/crystalhd: Another attempt at using mpeg4_unpack_bframes bsf
[01:39:20 CEST] <BtbN> durandal_1707, sure, go ahead.
[01:39:35 CEST] <BtbN> durandal_1707, I also thougt about unifiying all the *key filters, they share a lot of logic
[01:39:53 CEST] <BtbN> And the whole thing is also missing a spill removal, but I have no clue of a proper algorithm for that
[12:50:14 CEST] <durandal_1707> BtbN: i found high quality chroma key algorithm
[12:50:33 CEST] <BtbN> yes, for chroma keying there are a lot of them
[12:50:39 CEST] <BtbN> but not for the spill reduction after the fact
[12:50:44 CEST] <BtbN> And the one I found is for RGB
[14:53:19 CEST] <durandal_1707> BtbN: and quality is better and its faster than chromakey in ffmpeg
[14:53:46 CEST] <BtbN> sounds nice. Does it support despill natively?
[14:56:07 CEST] <durandal_1707> nope, but it spills much less
[14:56:49 CEST] <BtbN> Feel free to replace/improve the existing algorithm. It's basically the plain stupid approach to chromakeying
[14:58:41 CEST] <wm4> so merging "decode: restructure the core decoding code" did indeed cause this threading fate regression
[15:01:30 CEST] <wm4> every 4 threads it drops 1 frame
[15:01:49 CEST] <wm4> so with THREADS=N you get N/4 dropped frames
[16:12:43 CEST] <wm4> jamrial: the thing you asked for is caused by "decode: restructure the core decoding code", it drops a N/4 frames for N threads
[16:12:57 CEST] <jamrial> yes
[16:13:13 CEST] <wm4> I haven't found out why yet, I suspect it's something about not reporting decoding errors for exactly the packet which causes it
[16:14:03 CEST] <jamrial> the only fate test that reflects this is one with a huge amount of decoding errors, to the point it needs to increase the threshold of erros before ffmpeg bails out, so yeah
[17:23:31 CEST] <durandal_1707> BtbN: problem is that filter have different options: angle, noise
[17:50:43 CEST] <FishB8> Haivision sent out a press release today that they have open-sourced their Secure Reliable Transport protocol. Already submitted an enhancement request to integrate support for it.
[17:52:05 CEST] <FishB8> I've used it before in their appliances and really like it. Thought people here with interest in streaming transports might find it interesting.
[18:34:40 CEST] <thebombzen> on nutenc.c, lines 716-720, is this a bug?
[18:35:08 CEST] <thebombzen> http://sprunge.us/ejej
[18:36:23 CEST] <thebombzen> nvm, I see
[18:39:58 CEST] <kylophone> Anyone know what would cause a segfault in av_assert0_fpu()
[18:40:12 CEST] <kylophone> gdb is not being helpful
[19:46:58 CEST] <wm4> what's error code -1094995529
[19:47:06 CEST] <wm4> (typical problem when dealing with ffmpeg error codes)
[19:47:34 CEST] <wm4> ah invalid data
[19:48:02 CEST] <wm4> jamrial: so it happens that after starting the flush, the old decode API returns an error code _and_ a frame
[19:48:07 CEST] <wm4> I thought we fixed that...
[19:48:18 CEST] <wm4> but maybe that's a similar but different case
[19:59:45 CEST] <wm4> jamrial: extremely shitty hack (which surely isn't meant to be applied, probably): http://sprunge.us/RIDc
[20:00:03 CEST] <wm4> but it's probably a pthread_frame.c issue
[20:00:14 CEST] <wm4> I'm not even sure what it should do with errors on draining
[20:02:27 CEST] <jamrial> wm4: is it too hacky that it can't even be added as a temporary workaround, assuming it doesn't break anything else?
[20:02:49 CEST] <wm4> jamrial: sure, it'll work as temporary work around, but strictly speaking it's all kind of awful and wrong
[20:03:51 CEST] <jamrial> eh, that's not very encouraging :p
[20:04:07 CEST] <wm4> can we know in pthread_frame.c when we're draining?
[20:04:35 CEST] <wm4> err
[20:04:38 CEST] <wm4> of course we can
[20:04:45 CEST] <jamrial> we pass avctx to ff_thread_decode_frame, so i guess yes
[20:04:55 CEST] <wm4> let me guess whether a more direct hack passes fate
[20:05:01 CEST] <wm4> s/guess/check
[20:06:42 CEST] <jamrial> with avconv, the file from fate-h264-attachment-631 can barely decode one frame if using one thread, and absolutely nothing if using two or more threads, so i guess they are also affected by this
[20:07:42 CEST] <wm4> in this case it's just about handling errors during draining
[20:16:34 CEST] <wm4> jamrial: http://sprunge.us/MQEj
[20:16:36 CEST] <wm4> this passed
[20:16:43 CEST] <wm4> with THREADS=16
[20:16:53 CEST] <wm4> (ignore the commented chunk)
[20:17:18 CEST] <wm4> basically if(have_frame)ignore_error();
[20:22:13 CEST] <jamrial> wm4: can you send that to the ml? also, the comment right above this line wouldn't be correct anymore after this, so it needs updating
[20:25:37 CEST] <jamrial> seems to work with 4 and 8 threads as well, and it now plays right using ffplay
[20:25:59 CEST] <wm4> I can do that tomorrow maybe, though I'm not comfortable with the patch
[20:27:30 CEST] <jamrial> if anything it will get more eyes to look at it if you can't find another solution
[20:27:35 CEST] <jamrial> thanks a lot for that matter
[20:31:46 CEST] <BBB> guys, re: merging, I personally think its totally fine to just say no to the requests on the ML
[20:33:08 CEST] <wm4> jamrial: if it's just for review I can send it in a moment
[20:41:38 CEST] <cone-684> ffmpeg 03Paul B Mahol 07master:dfc4ce5f5ddb: avfilter: add lumakey filter
[20:45:04 CEST] <ubitux> BBB: btw, do you think you can get the bsf thing this week or we should skip it to give you more time and go on with the merges?
[20:45:20 CEST] <BBB> Im not sure Ill finish it that soon
[20:45:26 CEST] <BBB> Id skip it and leave it for later
[20:45:35 CEST] <BBB> Ill do it, I promise, but I Cant guarantee itll be done by $date
[20:45:43 CEST] <ubitux> sure, no pb, ok
[20:59:24 CEST] <wm4> what bsf thing? vp9?
[21:00:00 CEST] <ubitux> yes
[21:02:03 CEST] <wm4> so how is it going to work? like in Libav?
[21:02:36 CEST] <wm4> (that is will the packet format change to messing the invivisble frame together with a visible one)
[21:03:25 CEST] <ubitux> the plan is to adapt and use the bsf instead of the parser yes afaict
[21:03:34 CEST] <ubitux> btw, make checkheaders is broken
[21:03:41 CEST] <ubitux> decode.h is missing a header or so
[21:04:30 CEST] <jamrial> ubitux: i'll take a look at that
[21:06:07 CEST] <jamrial> ubitux: heh, it was fixed in libav in 554e55bbf0, a bunch of commits away from the current merge point
[21:08:56 CEST] <wm4> oops
[21:11:44 CEST] <BBB> and I applaud wm4 for coming out for a project merge, thank you, thankk you, *bow*
[21:13:10 CEST] <wm4> uh what
[21:13:15 CEST] <wm4> didn't I argue this for years
[21:13:32 CEST] <BBB> no idea, I applaud it anyway
[21:13:46 CEST] <BBB> you dont need a seismic shift to receive applause, do you?
[21:14:01 CEST] <BBB> musicians perform the same show every day for years and still they get applauded
[21:14:07 CEST] <BBB> (every night!)
[21:14:36 CEST] <wm4> lol
[21:15:05 CEST] <wm4> anyway, j-b has been claiming that ffmpeg devs are less open to the idea of an merge than libav devs
[21:15:17 CEST] <BBB> j-b: LIES! FILTHY LIES! ;)
[21:15:19 CEST] <wm4> so maybe we should push this idea a bit more
[21:15:39 CEST] <durandal_1707> at least carl is against
[21:15:46 CEST] <wm4> but carl is carl
[21:16:12 CEST] <wm4> we shouldn't tolerate his behavior against Libav
[21:20:37 CEST] <jamrial> i've always been in favor. doubt anyone here except carl and maybe nicolas are against it
[21:22:25 CEST] <gnafu> Hehe, that's the way to do it.  "I hear you guys are more against it than they are."  "Oh, yeah?!  We'll show you!  We're going to be more in favor than they are."
[21:23:19 CEST] <gnafu> While I have never contributed more than typo fixes to the old website and random musings on IRC, I'm personally 100% in favor of seeing a merger between ffmpeg and libav.
[21:25:22 CEST] <wm4> gnafu: that's how it should be - the devil is in the detail, so it's a big problem if we don't even agree in a broad way
[21:25:50 CEST] <wm4> (the details would consist of what repo to use as a base and which development rules etc., hard to solve)
[21:26:04 CEST] <gnafu> I've been lurking on here since before the split, and it's always been sad to me that it had to be that way.  I agree it will be tricky to make it work.
[21:28:04 CEST] <jamrial> wm4: definitely ffmpeg's tree. it's the only one with all the commits from both projects for proper authorship/blame reference
[21:28:33 CEST] <wm4> seems like Libav really doesn't like this idea (and I can understand that)
[21:28:50 CEST] <wm4> but, old discussion
[21:28:57 CEST] <jamrial> the history is dirty, yes
[21:29:05 CEST] <jamrial> the tree, i mean
[21:33:54 CEST] Action: gnafu wonders if things have diverged too much, or whether both could remain as a useful stable/testing distinction.
[21:34:08 CEST] <gnafu> Or something like that.
[21:35:13 CEST] <wm4> ffmpeg is still basically a superset with Libav - there are way more changes that were merged than changes that were skipped or undone
[21:35:20 CEST] <wm4> to my knowledge
[21:36:11 CEST] <wm4> s/with/of/
[21:36:16 CEST] <gnafu> That's been my impression.  ffmpeg has more in it than libav, because almost everything goes libav-->ffmpeg but very little goes ffmpeg-->libav.
[21:37:28 CEST] <gnafu> But it's a good thing I'm not leading any discussions, because I definitely don't know what amount of work is required or what's at stake ;-D.
[21:37:52 CEST] <gnafu> I would just love to see everyone working together on a common codebase that continues to benefit countless people around the world.
[21:38:33 CEST] <gnafu> Like how there is still one primary Linux kernel, but maybe some smaller groups carry out-of-tree patches for particular usage types.
[21:38:53 CEST] <gnafu> Imagine a world where there were two Linux kernel forks fighting for primacy.
[21:38:57 CEST] <BBB> I still think were wasting our time with this discussion
[21:39:05 CEST] <BBB> the fork is there, it wont go away by itself anytime soon
[21:39:25 CEST] <gnafu> Yeah, I'm just musing and speculating :-).
[21:39:42 CEST] <BBB> (with the fork, I dont mean libav devs are evil, I just mean there is a reality in which theres two more-or-less identical source code trees being pushed in distinct projects, aka a project forked in two)
[21:39:49 CEST] <gnafu> I saw it mentioned, and I figured I'd jump in and share my end-user perspective.  A guy can dream :-D.
[21:55:22 CEST] <gnafu> At the end of the day, it's more important to me that all y'all brilliant developers feel empowered to keep making awesome stuff.  If a fork is needed for some people to feel like they can still contribute, to me that's better than shutting them out.
[21:55:34 CEST] <gnafu> The license allows for sharing of code by those who want to do that work.
[21:55:41 CEST] <wbs> jamrial: just for the record, if it matters in the argumentation: the reason I sent the VP9 patches to ffmpeg is because that was sponsored work, unrelated to the merging pace
[21:55:51 CEST] <gnafu> I'm grateful for everyone's work throughout the years.
[21:55:58 CEST] <jamrial> wbs: ah, i see
[21:56:14 CEST] <wbs> (had the merges been up to date I would of course have been able to skip sending the patches here as well, except for the cases where there were nontrivial differences)
[22:05:01 CEST] <philipl> BtbN: Are you looking at the latest nvenc thing from Ben Chang?
[22:06:10 CEST] <BtbN> I took a quick look at it, but no full review, and I didn't understand some things of it on the first look
[22:06:27 CEST] <BBB> wbs: FWIW, we merged the vp9 decoder split from libav (thanks to some work from ubitux), so at least that code is truly in sync now
[22:06:50 CEST] <ubitux> BBB: we will probably need a pass of cosmetics on the c code of the dsp
[22:06:54 CEST] <ubitux> after they merge it
[22:06:58 CEST] <BtbN> it kind of seems to counteract the buffer or some surfaces which are needed to make the encoder go fast
[22:07:01 CEST] <ubitux> like, spaces before \ and that kind of stuff
[22:07:18 CEST] <ubitux> current state is too different to work on reducing the diff though
[22:07:51 CEST] <BBB> all remaining diff is cosmetic though, right?
[22:08:19 CEST] <ubitux> probably
[22:09:48 CEST] <BtbN> philipl, like, there are 32 surfaces by default because nvenc gets horribly slow if you force it to return the frame immediately, which this does when no buffer is needed
[22:11:11 CEST] <wbs> BBB: yep, I saw that
[22:12:02 CEST] <jamrial> BBB: and 10/12 bits i think. that's not in libav
[22:12:14 CEST] <philipl> BtbN: Reply and ask him about that?
[22:12:38 CEST] <wbs> BBB: no, there's one subtle difference that matters for the asm; libav has got int8_t ff_vp9_subpel_filters[3][15][8], while ffmpeg has got int16_t ff_vp9_subpel_filters[3][16][8]
[22:12:45 CEST] <BtbN> it actually seems to reduce it to 4
[22:12:57 CEST] <BtbN> so I'd need to benchmark how much slower that gets
[22:13:10 CEST] <wbs> BBB: libav has skipped the first line (mx/my=0 filter) of the second dimension of the array
[22:13:40 CEST] <wbs> BBB: and it's int16_t vs int8_t; so the code for calculating the offset into this is very subtly different, and in libav I need to do int8_t -> int16_t after loading
[22:14:17 CEST] <uau> wm4: isn't that errors-on-draining stuff exactly what we talked about here a while ago?
[22:15:29 CEST] <uau> and about which nothing was done at the time IIRC (contrary to what you say above)
[22:16:08 CEST] <BBB> wbs: thats probably why I made it int16_t ;)
[22:16:27 CEST] <BBB> (not sure though)
[22:16:40 CEST] <BBB> may also be that the first entry was 128 which doesnt fit in int8_t
[22:16:50 CEST] <BBB> the x86 simd has copies of these tables
[22:16:52 CEST] <BBB> anyway
[22:17:11 CEST] <BBB> we can copy these kind of changes, I honestly dont really care since its unlikely to affect performance
[22:17:24 CEST] <wbs> I also had copies initially, but janne requested to share it with the main decoder instead
[22:17:28 CEST] <BBB> but I still feel this is going the wrong way. the decoder was written by me and ubitux, we should be involved in review of such changes
[22:17:53 CEST] <wbs> I don't really care either way, I'm just pointing out the difference I noticed
[22:19:04 CEST] <BBB> ty :)
[22:21:16 CEST] <wbs> for the record, I sent one other unrelated patch last year as well, an openh264 decoder wrapper. that was also because it was sponsored
[22:28:34 CEST] <wm4> uau: probably...
[22:39:43 CEST] <uau> wm4: IIRC the discussion contained at least 1) i pointed out that your commit had changed semantics so that now it could return a frame AND error, 2) there was some discussion about what exactly the semantics SHOULD be (as in return errors and frames in "correct" order or errors after valid frames only), you preferred "correct" order IIRC 3) i noted that you'd need to change the calling code in other files as it'd stop calling for 
[22:39:43 CEST] <uau> more frames if error was returned before frame on draining
[22:40:03 CEST] <uau> and there the discussion stopped i think
[22:46:38 CEST] <wm4> yeah, it's unclear how it should behave
[22:46:55 CEST] <wm4> also, other decoders also have issues with errors during draining (like getting stuck)
[00:00:00 CEST] --- Tue Apr 25 2017