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

[burek]

[02:16:47 CEST] <thebombzen> it looks like they're linking in Libav, not ffmpeg
[02:17:16 CEST] <thebombzen> given the whole --enable-avserver --enable-avplay
[02:17:39 CEST] <thebombzen> kierank: this doesn't look like an issue with FFmpeg
[02:17:58 CEST] <thebombzen> so yea it's an GPL violation but shouldn't this by taken up with Libav?
[02:18:00 CEST] <kierank> hmm probably yes
[02:18:13 CEST] <kierank> but there's definitely ffmpeg code in there so whatever
[02:22:33 CEST] <thebombzen> IANAL /shrug
[03:07:01 CEST] <rcombs> any GPL violation is generally going to be violating the copyright of both projects
[03:07:12 CEST] <rcombs> since they share most of their code
[05:34:57 CEST] <ZeroWalker> is there a way to tell ffmpeg that the video frame is upside down?
[06:35:30 CEST] <cone-468> ffmpeg 03James Almer 07master:45759540a559: fate: update ref files for gray pixel formats changes
[09:37:32 CEST] <nevcairiel> how do dropbox mails like that even get to the ML, clearly dropbox isnt subscribed, shouldnt that then be in ML moderation? did someone approve that? :p
[10:02:08 CEST] <durandal_1707> Compn approved it
[11:41:35 CEST] <Compn> [04:02] <durandal_1707> Compn approved it
[11:41:36 CEST] <Compn> lies
[11:52:36 CEST] <Compn> the last time we investigated a similar email, it turned out that the automated mailer (i think it was linkedin....) had spoofed its mail headers
[11:55:56 CEST] <Compn> so shyamaldass001 at gmail is a subscriber to the list, and dropbox used that email as its FROM: , while using an reply-to email no-reply at dropboxmail.com
[11:56:02 CEST] <Compn> at least thats my guess
[11:56:06 CEST] <Compn> i didnt verify with the logs
[14:18:28 CEST] <kurosu> nasm dependency generation seems broken here (MSYS2/2.13.01)
[14:18:36 CEST] <kurosu> example: libavcodec/x86/simple_idct10.o: <PATH>/libavcodec/x86/simple_idct10.asm
[14:19:14 CEST] <kurosu> correct: libavcodec/x86/simple_idct10.o: <PATH>/libavcodec/x86/simple_idct10.asm config.asm <PATH>/libavutil/x86/x86util.asm <PATH>/libavutil/x86/x86inc.asm <PATH>/libavcodec/x86/simple_idct10_template.asm
[14:19:58 CEST] <kurosu> seems to work correctly if "-MD <FILE>.d -M" is used instead of plain "-MD <FILE>.d"
[14:20:08 CEST] <kurosu> moving the '-M' in front doesn't work
[14:21:25 CEST] <kurosu> (above is content of libavcodec/x86/simple_idct10.d)
[14:23:32 CEST] <kurosu> test: change date of libavcodec/x86/simple_idct10_template.asm and see not being libavcodec/x86/simple_idct10.o recompiled
[14:24:54 CEST] <kurosu> nevermind the solution, doesn't work, but the problem still there
[14:25:08 CEST] <J_Darnley> atomnuker, kierank: do you have any suggestions for removing/working around the buffer allocation for bitstream writing in vc2enc?
[14:26:41 CEST] <atomnuker> J_Darnley: you need a buffer to write to
[14:26:52 CEST] <atomnuker> and its already written to directly, there's nothing to remove
[14:27:18 CEST] <atomnuker> you need to know how many bits it'll take to encode something to you know how much to alloc
[14:27:49 CEST] <nevcairiel> buffer allocation in encoders is an annoying problem
[14:27:54 CEST] <atomnuker> you could always allocate the max possible
[14:28:01 CEST] <atomnuker> then encode to it without knowing the size
[14:28:05 CEST] <J_Darnley> But I can't allocate it without knowing the size needed.  I can't know that without doing the transform.  I can't do the transform without the whole picture.
[14:28:38 CEST] <atomnuker> then you have a buffer where you write to which is always big enough to store uncompressed coeffs + a bit more
[14:28:41 CEST] <nevcairiel> ffv1enc uses the max size, but the max size is basically uncompressed size, which poses its own sort of problems with high resolution content
[14:28:43 CEST] <atomnuker> you encode to it
[14:28:52 CEST] <J_Darnley> But it seems to allocate 1 buffer for every slice?
[14:28:55 CEST] <atomnuker> and then you copy the amount you wrote to the main one
[14:29:35 CEST] <atomnuker> you could get away without copying but then you'll need to do things serially
[14:30:02 CEST] <atomnuker> so you won't be able to slice thread if you don't memcpy
[14:30:09 CEST] <J_Darnley> I miss the days when I was writing directly to network card buffer.
[14:34:22 CEST] <atomnuker> the only exciting thing about network cards is ipv6
[14:35:02 CEST] <atomnuker> I had to connect to an rpi I flashed, I didn't have a router, I didn't have a dhcp server, I had a cable and 2 ethernet ports
[14:35:26 CEST] <atomnuker> thanks to stateless ipv6 I was able to just hook them up and use the rpi's hostname to ssh
[14:40:55 CEST] <kierank> J_Darnley: if you constrain the encoder to take a slice at a time you can do what you want
[14:41:04 CEST] <kierank> Just allocate and overshoot
[14:41:11 CEST] <kierank> And then write direct to that buffer
[14:56:29 CEST] <kurosu> nevcairiel / jamrial (when and if he shows up): https://bugzilla.nasm.us/show_bug.cgi?id=3392420 for the above issue
[14:59:07 CEST] <iive> can we assume that the encoded picture would always be smaller than the raw input fame size?
[14:59:14 CEST] <iive> frame
[14:59:25 CEST] <atomnuker> iive: nope
[15:00:08 CEST] <iive> ok, but if it gets bigger... maybe we should just dump the raw frame ;)
[15:01:52 CEST] <cone-446> ffmpeg 03wm4 07master:caa12027baf1: lavc, lavu: move frame cropping to a convenience function
[15:01:53 CEST] <cone-446> ffmpeg 03wm4 07master:463b81de2b25: imgutils: add function to clear an image to black
[15:25:58 CEST] <atomnuker> J_Darnley: no one has started working on such a thing on the encoding side, only on the decoding side using draw_horiz_band
[17:15:05 CEST] <durandal_1707> how good is speex aec?
[17:16:35 CEST] <wm4> have merges completely died?
[17:17:35 CEST] <wm4> last one was 3 months ago
[17:18:03 CEST] <atomnuker> durandal_1707: should be pretty good, though ask jmspeex in #opus if he has come up with something better
[17:18:45 CEST] <wm4> philipl: tried to look at libav's cuda hwaccel?
[18:01:15 CEST] <durandal_1707> ubitux is on vacation
[18:55:19 CEST] <cone-446> ffmpeg 03Paul B Mahol 07master:41096904d036: avfilter/vf_separatefields: stop leaking last frame
[18:57:33 CEST] <Compn> wm4 : no one wants merge job
[18:57:49 CEST] <Compn> wm4 : feel free to cherry pick ?
[18:58:11 CEST] <durandal_1707> Compn: are you coming to VDD?
[18:59:06 CEST] <Compn> durandal_1707 : no, dont think so
[18:59:18 CEST] <Compn> durandal_1707 : are you going ?
[18:59:32 CEST] <durandal_1707> no :(
[18:59:35 CEST] <Compn> why not ?
[18:59:41 CEST] <Compn> paris is nice 
[18:59:50 CEST] <durandal_1707> im busy and afraid
[19:00:17 CEST] <atomnuker> Compn: okay, you're not there, is you beard going to attend though?
[19:00:40 CEST] <Compn> only if it was in the south france part
[19:00:47 CEST] <Compn> i'd go if it were held in nice :)
[19:01:08 CEST] <Compn> check out monaco again
[19:01:59 CEST] <Compn> atomnuker : buy a beard and wear it around vdd to keep the beard levels up
[19:25:41 CEST] <cone-446> ffmpeg 03Michael Niedermayer 07master:a5380f9c1c46: avcodec/dirac_dwt: Fixes integer overflows in COMPOSE_DAUB97*
[19:32:45 CEST] <kierank> durandal_1707: afraid of whom?
[19:32:59 CEST] <kierank> I know kung fu I can protect you
[19:33:14 CEST] <durandal_1707> kierank: im afraid of paris
[19:33:41 CEST] <kierank> who isn't
[19:34:03 CEST] <atomnuker> I know, right, the metro system can leave you trapped in the tunnels
[19:34:20 CEST] <kierank> i'm afraid of the smell tbh
[19:34:29 CEST] <kierank> everywhere smells of piss
[20:02:12 CEST] <philipl> wm4: No. They added a full one?
[20:02:23 CEST] <wm4> yes
[20:02:36 CEST] <wm4> haven't had the chance to test because I'd need the cuda sdk installed
[20:02:39 CEST] <philipl> Someone loves suffering. nvidia don't document how to use it without their parser
[20:02:53 CEST] <wm4> seems like elenril figured it out
[20:05:11 CEST] <philipl> But still too stubborn to borrow any code from ffmpeg so he didn't use the dynamic loader for cuda
[20:06:52 CEST] <philipl> I think, conceptually, it's better to have a real hwaccel as the nvidia parser is not perfect. It's probably the cause for the glitches that hanna observed.
[20:07:05 CEST] <wm4> I had this discussion with him
[20:07:09 CEST] <philipl> BtbN: You look at this?
[20:07:10 CEST] <wm4> he was all like "just install the sdk"
[20:07:24 CEST] <BtbN> hm?
[20:07:31 CEST] <philipl> real cuvid hwaccel
[20:07:50 CEST] <BtbN> Did they actually merge it in libav?
[20:07:53 CEST] <philipl> Yep
[20:07:58 CEST] <philipl> https://github.com/libav/libav/blob/master/libavcodec/cuvid_hevc.c etc
[20:08:07 CEST] <BtbN> How did they solve the issue of it being horribly slow, because no buffering?
[20:08:21 CEST] <philipl> Of course, only two codecs right now.
[20:08:33 CEST] <philipl> Dunno. I guess it's fast enough for playback even if you do nothing
[20:08:42 CEST] <philipl> Transcode might be garbage, but we'd have to test
[20:09:50 CEST] <philipl> If there are no functional regressions (and performance is the big one I guess), I'd be in favour of adopting it. Of course, we'd need to keep the current one around to cover the other codecs until someone writes the individual hwaccels
[20:10:32 CEST] <philipl> I don't think there's any claim that the nvidia parser is better in any circumstance.
[20:10:55 CEST] <BtbN> It's nice to have it around though
[20:12:13 CEST] <BtbN> https://github.com/libav/libav/blob/master/libavcodec/decode.h#L39
[20:12:33 CEST] <philipl> Assuming we had all the hwaccels and no functional regressions, would you actually want it around?
[20:12:38 CEST] <philipl> That's his solution to buffering?
[20:12:46 CEST] <BtbN> https://github.com/libav/libav/commit/704311b2946d74a80f65906961cd9baaa18683a3
[20:12:49 CEST] <BtbN> yes, looks like it
[20:13:10 CEST] <BtbN> https://github.com/libav/libav/commit/badf0951f54c1332e77455dc40398f3512540c1b
[20:13:28 CEST] <philipl> Yay I guess.
[20:13:43 CEST] <BtbN> Yeah, if it works at the same performance, I'd prefer it
[20:13:53 CEST] <BtbN> Allows for some more obscure stuff to be possible
[20:13:56 CEST] <philipl> In practical terms, I know the nvidia parser prevents us supporting wmv9 and webp.
[20:14:11 CEST] <BtbN> like those weird in-video subtitles
[20:14:51 CEST] <philipl> Aren't those fun...
[20:15:06 CEST] <BtbN> I wonder though, the delay that adds does not seem overly crazy
[20:15:10 CEST] <philipl> Switching would also let me drop the whole fake hwaccel comamnd line thing that we never resolved.
[20:15:35 CEST] <BtbN> I don't think switching is possible without breaking api
[20:17:03 CEST] <philipl> Well, we can keep the current decoder around - the namespace is separate
[20:17:17 CEST] <philipl> So this would be additional until the next break opportunity
[20:17:53 CEST] <BtbN> It does not look like their cuvid stuff is able to output CUDA frames though?
[20:17:59 CEST] <wm4> both cuvid decoder and hwaccel will call get_format
[20:18:03 CEST] <wm4> you're in for some mess
[20:18:12 CEST] <philipl> eh...
[20:18:17 CEST] <BtbN> hm?
[20:18:29 CEST] <BtbN> The new cuvid decoder is a normal hwaccel
[20:18:34 CEST] <BtbN> It will behave like any other one
[20:18:41 CEST] <philipl> wm4: I mean, we'd have give the two hwaccels different names.
[20:19:02 CEST] <wm4> get_format uses _only_ the pixfmt to identify or select the hwaccel
[20:19:22 CEST] <BtbN> Just going to get rid of the dummy hwaccel then
[20:19:25 CEST] <wm4> so a caller using the cuda hwaccel would have to distinguish them in another way
[20:19:26 CEST] <BtbN> it's not needed anymore then anyway
[20:19:36 CEST] <philipl> Well, then we now have an opportunity to change the format to use cuda arrays :-)
[20:19:38 CEST] <wm4> that could work, or would at least reduce the mess
[20:20:17 CEST] <wm4> btw. I wonder if there is cuda/vulkan interop
[20:21:07 CEST] <BtbN> There is a generic extension for VK to use "external memory"
[20:24:13 CEST] <philipl> I keep looking.
[20:24:20 CEST] <philipl> There needs to be a cuda side to the VK extension
[20:24:26 CEST] <philipl> That doesn't exist yet - maybe it's in cuda 9
[20:24:38 CEST] <wm4> it could be that the vulkan side just imports generic memory
[20:24:59 CEST] <wm4> and you use that as an image
[20:25:08 CEST] <wm4> (vulkan is low level enough that this is possible)
[20:25:39 CEST] <wm4> via VK_KHX_external_memory / VK_KHX_external_memory_fd
[20:25:52 CEST] <kurosu> what's the content of libavcodec/x86/simple_idct10.d (build system dependency file included by makefile) for people targeting x86 here?
[20:26:26 CEST] <kurosu> can anyone confirm it has a single dependency <PATH>/libavcodec/x86/simple_idct10.asm
[20:27:34 CEST] <philipl> wm4: it is possible, but it does at least need to be documented as to whether you just pass a cuda pointer, etc.
[20:27:40 CEST] <wm4> yeah
[20:38:29 CEST] <kierank> kurosu: J_Darnley: ping
[20:38:43 CEST] <kierank> maybe you know the answer J_Darnley 
[20:38:50 CEST] <J_Darnley> Maybe
[20:41:15 CEST] <cone-446> ffmpeg 03Michael Niedermayer 07master:fea7bc9e7b9a: avcodec/dvenc: Support adjusting the quantizer deadzone
[20:41:16 CEST] <cone-446> ffmpeg 03Michael Niedermayer 07master:abaeeb3ce08d: avcodec/dvenc: Change quantizer dead zone default to 7
[20:41:19 CEST] <J_Darnley> I would expect the deps for an assembly object to be the .asm file, x86inc.asm, x86util.asm
[20:41:37 CEST] <J_Darnley> Oh, and config.asm I guess
[20:42:03 CEST] <kurosu> and also simple_idct10_template.asm in that case
[20:42:17 CEST] <kurosu> that's the output of -M, while -MF is borked
[20:42:56 CEST] <kurosu> for a particular case, until verified on other platforms
[20:43:38 CEST] <J_Darnley> Didn't someone file a bug on nasm's tracker about it?
[20:43:53 CEST] <kurosu> <- you're probably thinking of this guy
[20:44:01 CEST] <J_Darnley> :) maybe I am
[20:46:54 CEST] <ubitux> hello
[20:47:24 CEST] <ubitux> holidays are boring, i'm better at home derping with other nerds
[20:47:50 CEST] <ubitux> hey wm4, not sure if you saw it, i fixed your subrip nesting issue a few days ago
[20:47:56 CEST] <ubitux> you may want to give it a try
[20:48:08 CEST] <ubitux> (i took the opportunity to improve the br handling too)
[20:48:11 CEST] <J_Darnley> kurosu: yes, with nasm 2.13 I have only the asm file as a dependency
[20:48:40 CEST] <ubitux> J_Darnley: nasm deps are broken, i opened a ticket a while ago, but i should probably open it at nasm bug tracker
[20:48:48 CEST] <kurosu> oh
[20:48:49 CEST] <ubitux> i wasn't sure if we messed up options ourselves
[20:48:51 CEST] <kurosu> I just did
[20:49:08 CEST] <wm4> ubitux: saw it, it's nice
[20:49:12 CEST] <kurosu> no, bug confirmed by martsin storsjo & a nasm developper
[20:49:22 CEST] <kurosu> https://bugzilla.nasm.us/show_bug.cgi?id=3392420
[20:49:33 CEST] <ubitux> oh that's great
[20:49:36 CEST] <kurosu> and it now appears to be for several platforms (I suspect all)
[20:49:53 CEST] <kurosu> weird that nobody was bitten by this bug
[20:50:46 CEST] <kurosu> using -M (which doesn't generate the object file) generates the proper output
[20:51:03 CEST] <ubitux> mmh i can't find the ticket again
[20:51:19 CEST] <ubitux> only https://trac.ffmpeg.org/ticket/6516 which is unrelated (but also a nasm bug)
[20:51:27 CEST] <ubitux> maybe i only poke on the ml
[20:52:22 CEST] <J_Darnley> Well, I would only be bitten by it if I were working on the headers.
[20:53:03 CEST] <thebombzen> Who administers the website HTML stuff? There's a deadlink: http://0x0.st/d2f.png
[20:53:07 CEST] <J_Darnley> I might have noticed when working on the idct template but I was usually dealing with both files for that.
[20:53:16 CEST] <thebombzen> This button "Read on Gmane" is a big fat 404
[20:53:45 CEST] <thebombzen> or do I submit a trac bug for website UI issues as well
[20:53:58 CEST] <J_Darnley> kierank: was the nasm thing why you pinged me?
[20:54:53 CEST] <kierank> Yes
[20:54:59 CEST] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/212899.html
[20:55:00 CEST] <J_Darnley> thebombzen: if nobody replies then you may submit a ticket
[20:55:05 CEST] <ubitux> kurosu: seems i only reported it here ^
[20:55:14 CEST] <thebombzen> alright
[20:55:21 CEST] <ubitux> (and we had a discussion on irc)
[20:56:12 CEST] <kurosu> "touch libavcodec/x86/simple_idct10_template.asm" doesn't trigger a recompilation of the object file, as expected with the incomplete dependency file
[20:57:04 CEST] <ubitux> yep
[20:57:06 CEST] <kurosu> well, I was likely to have missed all these discussions, but the bug is filed and acknowledged by the nasm authors
[20:57:15 CEST] <ubitux> it took me a while to realize the problem when i was doing regression testing
[21:01:23 CEST] <jamrial> does that affect every nasm version until now, or just the most recent ones?
[21:02:16 CEST] <jamrial> depending on that, we should add a configure check to use the yasm style preprocess-then-assemble in two separate calls based on reported nasm version
[21:06:35 CEST] <durandal_1707> have new chl api been merged into libav?
[21:14:01 CEST] <kurosu> jamrial, no idea, I think I saw a bug report around 2014 because -MF (or -MD) didn't exist 
[23:34:58 CEST] <BtbN> 0.6.3?!
[23:35:07 CEST] <nevcairiel> its a very old ticket
[00:00:00 CEST] --- Wed Aug  9 2017