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

[burek]

[01:32:25 CEST] <BtbN> hm, my ffmpeg-devel folder has 15k mails
[01:32:35 CEST] <BtbN> that _might_ explain why Thuderbird is so horribly laggy
[01:33:23 CEST] <philipl> claws-mail, 59k. No problems.
[01:33:41 CEST] <BtbN> It's deleting 14k of them
[01:33:57 CEST] <BtbN> and windows wants to kill it, because it's unresponsive for a good couple minutes now
[01:58:58 CEST] <cone-196> ffmpeg 03Paul B Mahol 07master:c62cb9bf5a50: avcodec/utvideodec: add support for ULY4 and ULH4
[02:20:32 CEST] <jamrial> BtbN: i have like 40k and no issues
[02:22:34 CEST] <jamrial> BtbN: maybe it's running some unnecessary addons or plugins. i for example disabled the calendar stuff
[02:22:49 CEST] <DHE> message body indexing?
[09:12:27 CEST] <cone-932> ffmpeg 03Matt Oliver 07master:8b4e4bc620c2: configure: Remove fifo muxers dependency on pthreads.
[11:17:27 CEST] <durandal_1707> ubitux: going to comment palette filters patch?
[11:22:46 CEST] <JEEB> hmm, mateo`_ - did you check that ff_AMediaCodecProfile_getProfileFromAVCodecContext actually has a profile in there? I will try to test it as I get home. because I'm just not sure if the profile field is available in there.
[11:56:34 CEST] <mateo`_> JEEB: yes the profile is set (I rely on avformat_find_stream_info to set this field)
[12:22:53 CEST] <cone-932> ffmpeg 03Christophe Gisquet 07master:b6e8efb082c2: fate: add 12bpp sample
[13:00:03 CEST] <durandal_1707> michaelni: whant to comment gblur filter?
[13:01:06 CEST] <BtbN> I don't understand why carl wants to get rid of the & 0xFFC0 so badly. It's imo the correct way to do it.
[13:13:06 CEST] <JEEB> mateo`_: ok - I will add some logging and test after I get home then
[13:57:27 CEST] <wm4> did vdd produce any results extremely embarrassing to the ffmpeg and libav projects yet?
[13:57:34 CEST] <wm4> +results
[13:59:10 CEST] <JEEB> not sure
[13:59:46 CEST] <JEEB> there was one misplaced comment during the avcodec discussion time, otherwise it's been quite civil
[14:19:26 CEST] <mateo`_> JEEB: will there be a report of the discussions ?
[14:46:02 CEST] <durandal_1707> michaelni: I added slice threading to gblur, it's pretty fast, gonna commit this
[14:47:03 CEST] <durandal_1707> JEEB: what was it about?
[14:52:56 CEST] <cone-932> ffmpeg 03Vittorio Giovara 07master:5df993f3b129: vf_colorspace: Allow overriding input color properties
[14:52:57 CEST] <cone-932> ffmpeg 03Paul B Mahol 07master:817846d0c3c6: doc/filters: improve weave example
[15:00:36 CEST] Action: JEEB updates some of his patches to codecpar
[15:13:08 CEST] <durandal_1707> JEEB: what patches?
[15:22:22 CEST] <JEEB> the stuff I posted in March
[15:22:31 CEST] <JEEB> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/191735.html
[15:25:34 CEST] <JEEB> so was max rate somewhere in codecpar?
[15:25:41 CEST] <JEEB> what happened to it in dashenc
[15:26:23 CEST] <JEEB> oh, was that part removed from dashenc? :<
[15:27:16 CEST] <JEEB> since I remember seeing manifest_bit_rate = stream->bit_rate ? stream->bit_rate : stream->rc_max_rate; or so
[15:34:05 CEST] <JEEB> yeah, seems like that existed
[15:34:48 CEST] <cone-932> ffmpeg 03Paul B Mahol 07master:ee605aa730dd: avfilter: add gblur filter
[15:34:49 CEST] <cone-932> ffmpeg 03Paul B Mahol 07master:9833cf2ae1e8: avfilter/vf_bitplanenoise: silence clang warning, do not truncate value
[15:34:50 CEST] <cone-932> ffmpeg 03Paul B Mahol 07master:28b920c09b6b: avfilter/Makefile: move anullsrc and nullsink to correct place
[15:54:09 CEST] <JEEB> so how retarded do you think adding rc_max_rate to codecpar is?
[15:55:19 CEST] <cone-932> ffmpeg 03Paul B Mahol 07master:3c55baf08f7e: avccodec/utvideoenc: support encoding ULY4 and ULH4
[16:04:02 CEST] <nevcairiel> JEEB: we have side data for the rc settings I think
[16:04:42 CEST] <JEEB> oh
[16:06:38 CEST] <JEEB> AVCPBProperties, I see
[16:17:55 CEST] <JEEB> lessee if this compiles, switched to the side data
[16:22:55 CEST] <JEEB> builds and seems to work. yayifications
[16:31:30 CEST] <RiCON> utvideoenc is almost up to par with vanilla utvideo, cool
[16:31:59 CEST] <RiCON> just missing 10-bit formats?
[16:33:57 CEST] <durandal_1707> yes
[16:48:41 CEST] <philipl> BtbN: So, I'm guessing the seek problem with cuvid is because it doesn't implement flush?
[16:48:53 CEST] <BtbN> There is a seek issue?
[16:49:00 CEST] <philipl> Yeah. Testing in mpv
[16:49:28 CEST] <philipl> You'd need to flush the queue right?
[16:49:47 CEST] <philipl> doesn't come up in a transcode scenario
[16:51:15 CEST] <durandal_1707> JEEB: mpv supports lavfi filters, and you can use vstack :)
[16:52:00 CEST] <BtbN> philipl, I'm not sure if cuvid even supports that.
[16:52:10 CEST] <BtbN> Might need a full re-initialization.
[17:02:44 CEST] <BtbN> I can finally do hevc/10bit tests on nvenc...
[17:05:21 CEST] <philipl> It seems to work
[17:06:31 CEST] <philipl> BtbN: Well, I'll see if I can implement some kind of flush.
[17:06:55 CEST] <philipl> BTW: Did you see my comment about 10bit decode yesterday? It works for hevc but is undocumented.
[17:07:12 CEST] <BtbN> But it seems kind of pointless if it still outputs NV12
[17:07:34 CEST] <philipl> It's better than nothing.
[17:07:47 CEST] <philipl> if you worry about CPU load
[17:08:07 CEST] <BtbN> does it need any changes to the code, or does it just work?
[17:08:31 CEST] <philipl> There's a new field in CUVIDDECODECREATEINFO
[17:08:36 CEST] <philipl> bitDepthMinus8
[17:08:46 CEST] <philipl> The header in the 7.0 SDK is updated
[17:08:48 CEST] <BtbN> that should be filled by the NAL parsers, should it?
[17:09:12 CEST] <philipl> Not in this case. You need to copy the value over from the CUVIDEOFORMAT
[17:12:48 CEST] <durandal_1707> ubitux: ping
[17:13:51 CEST] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/ff339fab3a21e1fe7686e19a54f7d74a81684fac
[17:40:21 CEST] <philipl> woo. got seeking working
[17:41:54 CEST] <philipl> nope. didn't work.
[17:41:55 CEST] <philipl> bah.
[17:42:22 CEST] <nevcairiel> i'm categorically against decoding 10-bit to 8-bit, fwiw
[17:44:21 CEST] <philipl> nevcairiel: Well, it's a moot issue for now - I had to hack up my header by hand. Presumably the cuda 8 sdk has the updated header but we can't require it.
[17:44:41 CEST] <nevcairiel> you could add a configure check and enable it when available
[17:44:52 CEST] <BtbN> Or just put a version check around that line.
[17:46:14 CEST] <philipl> Ok. So mpv is seeking correctly on chapter changes and gets into a mess on arbitrary seeks. I'm guessing this is because the decoder gets very unhappy if advanced to some frame with missing references.
[17:47:02 CEST] <BtbN> just skip over any non-iframes until one comes by?
[17:47:21 CEST] <philipl> I can try.
[17:47:28 CEST] <BtbN> The information on that should be somewhere in the structs the cuvid parser returns
[17:47:34 CEST] <philipl> yeah.
[17:55:01 CEST] <philipl> Ok, this is weird. That made no difference.
[17:55:26 CEST] <philipl> I thought it might be due to the frame queue - after the seek, you'd be de-queuing old frames, but that would affect the chapter seek too.
[17:55:44 CEST] <philipl> and I tried flushing and recreating the queue with no visible effect.
[17:56:13 CEST] <BtbN> How are you flushing it?
[17:56:17 CEST] <philipl> wm4: Does mpv do anything meaningfully different between a chapter seek and an arbitrary seek?
[17:56:35 CEST] <BtbN> I highly suspect you won't manage to add flushing without doing a full re-init in the flush
[17:56:57 CEST] <wm4> philipl: chapter seeks are hr-seeks by default, so they might skip frames before displaying them
[17:57:16 CEST] <philipl> BtbN: I agree, with respect to the decoder. But given the behaviour I'm seeing, I'm not convinced the decoder is actually unhappy.
[17:57:35 CEST] <philipl> wm4: thanks.
[17:57:37 CEST] <BtbN> just seek with pure ffmpeg and see what happens?
[17:57:56 CEST] <philipl> BtbN: ffplay?
[17:58:33 CEST] <wm4> normal seeks in mpv show the very first frame it gets from the decoder... ffplay should behave the same, I think
[17:59:15 CEST] <philipl> Yeah, I'd expect that.
[17:59:32 CEST] <philipl> So my guess remains the decode queue.
[17:59:40 CEST] <philipl> After the seek, the decoder is still draining the queue right now.
[17:59:59 CEST] <philipl> but that ought to mess up after a chapter seek as well - the stale frames are still there.
[18:03:18 CEST] <wm4> depends on the timestamps
[18:05:17 CEST] <philipl> It silently discards if they're obviously wrong?
[18:08:57 CEST] <wm4> precise seeking works by skipping all frames that have a timestamp lower than the seek target
[18:11:09 CEST] <philipl> Hrm. So, sometimes I see it recover after a couple of small seeks.
[18:13:27 CEST] <philipl> Yeah, so the A-V desync status field shows 60s desynced after I do a 60s seek. No surprises.
[18:13:47 CEST] <philipl> Then if I seek again, it's some smaller value that the player will catch up.
[18:14:06 CEST] <philipl> So, I think that makes it clear that the decoder is still pushing out the old frames.
[18:14:35 CEST] <philipl> And I guess flushing our queue isn't enough because the cuda decoder can still be pushing out old frames even after that point.
[18:15:17 CEST] <philipl> Still, all that doesn't explain why chapter seeks are reliable.
[18:16:18 CEST] <BtbN> because they are exact and discard all frames with a lower timestamp?
[18:17:08 CEST] <philipl> correct. I reconfigured mpv to do exact seeks for the 60s thing and it 'solves' the problem.
[18:17:29 CEST] <BtbN> so, you have to drain the output queue and cuvid on flush
[18:18:10 CEST] <philipl> Draining our queue is easy - throw it away. cuvid is decoding in the background. How would I know it was drained?
[18:18:28 CEST] <BtbN> give it EOF frames until no new frames come out
[18:18:40 CEST] <philipl> cute.
[18:18:42 CEST] <BtbN> And hope it will still accept new frames after that
[18:18:47 CEST] <philipl> Heh.
[18:20:28 CEST] <philipl> I tried tearing down the decoder and the parser on flush but I got the "AVHWFramesContext is already initialized" error when initializing the new decoder.
[18:20:38 CEST] <philipl> I don't really get that.
[18:22:19 CEST] <BtbN> it's kind of a hack
[18:22:52 CEST] <BtbN> The cuvid-decoder late-initializes the HWFramesContext, because before that the needed information to do that are missing. so ffmpeg_cuda.c can't do it.
[18:23:25 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/cuvid.c#L167 <- this part
[18:23:58 CEST] <philipl> Yeah. But can I 'un-init' it? I can't free it completely because it might not be owned by the decoder right? (ffmpeg_cuda.c etc)
[18:24:25 CEST] <BtbN> uninitializing might mess with everything after cuvid using frames from it, yes.
[18:25:18 CEST] <philipl> So can I make decode_sequence just be ok with an initialized one? On the assumption that it was set up correctly before the flush?
[18:25:34 CEST] <philipl> sorry, handle_video_sequence
[18:25:51 CEST] <BtbN> Probably. It will just explor miserably if it isn't.
[18:25:54 CEST] <BtbN> *explode
[18:26:28 CEST] <ubitux> durandal_1707: i will
[18:27:03 CEST] <ubitux> jamrial: thx!
[18:27:48 CEST] <philipl> VICTORY
[18:29:40 CEST] <philipl> BtbN: So, right now I'm just skipping HWFramesContext init if it's already initialised. Should I do something like fail if flush has never been called but keep going if it has.
[18:29:54 CEST] <philipl> I think that retains the sanity check aspect.
[18:30:35 CEST] <BtbN> hm
[18:30:47 CEST] <BtbN> If it's not too much of a mess, yes
[18:33:18 CEST] <philipl> It's not. Got it.
[18:47:43 CEST] <philipl> BtbN: reviews sent
[19:32:09 CEST] <durandal_1707> I wrote 3d rotating cube video source, anybody interested?
[19:34:43 CEST] <durandal_1707> should we ditch xavs support?
[20:14:04 CEST] <DSM_> durandal_1707: yeah, how did you write a video?
[20:15:21 CEST] <durandal_1707> DSM_: of rotating cube?
[20:15:28 CEST] <DSM_> yes
[20:15:52 CEST] <durandal_1707> Its pure c, no opengl
[20:16:20 CEST] <DSM_> oh!
[20:16:30 CEST] <DSM_> i really wanna see it
[20:18:45 CEST] <durandal_1707> I stole buggy code from Rosetta and fixed it
[20:19:06 CEST] <durandal_1707> its in cube branch
[20:20:18 CEST] <thardin> make a plasma too
[20:20:58 CEST] <durandal_1707> what's plasma? Kind of noise?
[20:22:41 CEST] <thardin> sin(x+t)*sin(y+t)  type of thing
[20:23:21 CEST] <DSM_> durandal_1707: awesome 
[20:29:10 CEST] <cone-514> ffmpeg 03Carl Eugen Hoyos 07master:445522c01b75: fate: Add test for ticket #5805.
[20:51:38 CEST] <Chloe> durandal_1707: is the builtin avs codec better?
[20:59:40 CEST] <durandal_1707> Chloe: xavs looks to be abandoned
[21:02:56 CEST] <Chloe> durandal_1707: I think that even if it's abandoned, until the ffmpeg avs codec is as good (or better), or xavs stops working (which would make the ffmpeg codec better by default), it should probably stay in. If the ffmpeg avs codec is just as good, then I dont see a reason why xavs should stay.
[21:20:35 CEST] <DSM_> durandal_1707: i seem to find a bug
[21:20:44 CEST] <DSM_> *found
[21:21:27 CEST] <DSM_> if i try to interpolate raw video which is 4:2:2, there's lot of green frames
[21:21:57 CEST] <DSM_> the non-interpolated frames are 90% green
[21:24:28 CEST] <DSM_> i had been using a script which convert video to raw -> interpolate -> check psnr -> compare last best -> if (true) -> replace psnr
[21:24:45 CEST] <DSM_> all videos i've been using were 4:2:0
[21:24:55 CEST] <DSM_> this one, which doesn't work is 4:2:2
[21:25:20 CEST] <DSM_> durandal_1707: does it need special handling?
[21:26:08 CEST] <durandal_1707> 422 works fine here
[21:26:34 CEST] <durandal_1707> show script
[21:28:22 CEST] <DSM_> durandal_1707: okay, problem comes when converting it to YUV
[21:28:40 CEST] <DSM_> i used ffplay to play orig.yuv
[21:30:11 CEST] <durandal_1707> use nut format and mpv as player
[21:30:35 CEST] <DSM_> nut format?
[21:30:47 CEST] <DSM_> durandal_1707: btw, i use ../FFmpeg/ffmpeg -i $INPUT.mp4 $ORIG.yuv -y 
[21:31:18 CEST] <DSM_> and when i play it half-screen green frames
[21:32:58 CEST] <DSM_> works fine with 4:2:0
[21:33:11 CEST] <DSM_> but not 4:2:2
[21:33:38 CEST] <durandal_1707> because you need to fix your script
[21:33:45 CEST] <DSM_> to verify, how can i convert a 4:2:2 -> 4:2:0?
[21:33:54 CEST] <DSM_> durandal_1707: how?
[21:34:17 CEST] <durandal_1707> don't use yuv format, use nut or y4m
[21:34:47 CEST] <DSM_> okay
[21:35:15 CEST] <durandal_1707> DSM_: that is very basic question, see format filter docs
[21:35:40 CEST] <DSM_> durandal_1707: yuv doesn't work with 4:2:2?
[21:36:32 CEST] <durandal_1707> it works, but you need to manually tell whole history
[21:36:56 CEST] <durandal_1707> Yuv is pita
[21:38:01 CEST] <durandal_1707> *format you use, not colorspace
[21:38:29 CEST] <durandal_1707> its not format at all, btw
[21:39:28 CEST] <DSM_> y4m works fine
[21:41:36 CEST] <DSM_> i've always been using yuv, question is why it worked with 420 not 422?
[21:48:03 CEST] <AnonBaiter> https://www.sendspace.com/filegroup/zKTy7nGQXwdYxVCHvP6Fnw
[21:48:07 CEST] <AnonBaiter> these files don't work with even the latest build
[21:48:45 CEST] <AnonBaiter> the at3 6-channel variant has never been seen before
[21:52:55 CEST] <durandal_1707> DSM_: because you need to specify pix fmt as input option
[21:56:22 CEST] <DSM_> durandal_1707: okay got it
[22:09:17 CEST] <durandal_1707> AnonBaiter: what plays them?
[22:14:28 CEST] <AnonBaiter> nothing I know of
[22:15:24 CEST] <AnonBaiter> it doesn't even work with MPC-HC
[22:36:12 CEST] <AnonBaiter> btw i gotta go
[00:00:00 CEST] --- Mon Sep  5 2016