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

[burek]

[09:43:52 CEST] <j-b> 'morning
[09:55:08 CEST] <durandal_1707> 'morning
[17:06:22 CEST] <durandal_1707> j-b: so what have been used for audio filtering for VDD videos in the end?
[17:07:06 CEST] <j-b> no clue.
[17:07:15 CEST] <j-b> did not take care about it at all.
[17:07:27 CEST] <j-b> I'm still too busy from the aftermath of VDD.
[17:17:52 CEST] <Compn> i hope j-b gets some vacation :D
[17:19:39 CEST] <j-b> I wish too
[17:19:49 CEST] <j-b> Mostly people complain to me :)
[18:24:53 CEST] <kierank> durandal_1707: can you fix it
[18:24:56 CEST] <kierank> can't hear
[18:43:25 CEST] <durandal_1707> kierank: fix what?
[18:43:35 CEST] <kierank> background noise in vdd audio
[18:46:52 CEST] <durandal_1707> kierank: which video?
[19:11:28 CEST] <BtbN> philipl, does that new CUDA SDK enable Vulkan interop with those functions?
[19:12:16 CEST] <JEEB> IIRC he got as far as having to pull the image out and then transfer it to another vulkan surface for it to work or so?
[19:12:50 CEST] <BtbN> That'd be nice. Vulkan filters for CUDA frames.
[19:12:52 CEST] <JEEB> BtbN: probably relevant https://github.com/mpv-player/mpv/pull/6170
[19:13:41 CEST] <atomnuker> BtbN: it apparently requires a gpu memcpy
[19:14:04 CEST] <atomnuker> I was going to extend my lavu patches with it but gave up on hearing that
[19:14:45 CEST] <BtbN> It's a pretty new API, mapping might still be possible. But I don't have time to look into that until the weekend.
[19:22:42 CEST] <atomnuker> apparently philipl went through hell figuring out how the api worked as it wasn't documented or something
[19:24:00 CEST] <durandal_1707> kierank: i use mpv Video\ Dev\ Days\ 2018\ -\ HDR\ \&\ placebo-kQ8fxENEGtk.m4a -lavfi-complex "[aid1]afftdn=nr=97:nf=-20:nt=c:bn=24 20 19 19 19 17 13 5 -4 -15 -24 -24 -24 -17 10:om=o,asplit[ao],showspectrum=sc
[19:24:15 CEST] <durandal_1707> ale=log:color=magma[vo]"
[19:24:19 CEST] <kierank> meh mpv
[19:24:28 CEST] <kierank> too l1337 for me
[19:24:52 CEST] <durandal_1707> kierank: it is for real time playbakc
[19:26:42 CEST] <durandal_1707> best results would be if somone have not cut silence parts, and than i could run sampling noise algo to give me profile of noise
[19:27:44 CEST] <durandal_1707> kierank: mpv uses crap^Wlavfi filters
[19:53:34 CEST] <cone-655> ffmpeg 03Sigga Regina 07master:dcbd89e0008f: avformat/matroskaenc: reserve free space for metadata on request
[20:04:09 CEST] <JEEB> huh, intel just published two new encoders?
[20:04:21 CEST] <JEEB> SVT-HEVC and SVT-AV1
[20:04:25 CEST] <JEEB> https://itpeernetwork.intel.com/open-source-visual-cloud/
[20:05:12 CEST] <gnafu> Well, published one and announced the other.  I haven't seen code for SVT-AV1 yet.
[20:05:28 CEST] <JEEB> yea, I kind of meant "announced" as "published"
[20:05:33 CEST] <JEEB> as in, "published info on"
[20:05:39 CEST] <gnafu> But yeah, SVT-HEVC is out on GitHub and looks interesting
[20:05:40 CEST] <gnafu> .
[20:05:52 CEST] <gnafu> JEEB: That makes sense.
[20:09:52 CEST] <durandal_1707> is it new separate codec or new codec encoder?
[20:10:16 CEST] <JEEB> it's a new encoder
[20:10:18 CEST] <gnafu> It's a fast HEVC encoder.
[20:10:30 CEST] <gnafu> (And eventually a fast AV1 encoder, I guess.)
[20:17:23 CEST] <philipl> BtbN: Yes
[20:17:47 CEST] <philipl> https://github.com/mpv-player/mpv/pull/6170
[20:18:01 CEST] <philipl> That's me using it in mpv. But the same basic approach can work for the filters.
[20:18:49 CEST] <philipl> As atomnuker says, I currently need an intermediate buffer in Vulkan because I couldn't get copying directly to a VkImage to work (get visual mess that looks like incorrect stride + tiling)
[20:19:09 CEST] <philipl> The CUDA docs imply that the memory layout should be fully abstracted, but it's not acting like it and nvidia has no VkImage example.
[20:19:22 CEST] <philipl> But for filters it's unclear if you event want to use a VkImage vs a VkBuffer anyway.
[20:21:33 CEST] <atomnuker> well, buffers are always linear, so you don't really want to use them
[20:24:13 CEST] <philipl> yeah, but it's just the first hop, and your source was presumably linear to begin with anyway. The extra GPU copy is fast enough that it doesn't invalidate the advantages.
[20:24:30 CEST] <philipl> Obviously, I'd much rather get the VkImage mapping to work.
[20:26:20 CEST] <philipl> I'll keep experimenting with it but it's hard when they don't explain what the constraints are.
[20:27:04 CEST] <philipl> For example: Switching the tiling mode of the VkImage changes the visual mess I end up with, but the whole point of using an Array abstraction on the CUDA side is to decouple the memory layout, so it shouldn't make a difference.
[20:43:38 CEST] <Compn> ehe
[20:43:49 CEST] <Compn> someone emails me about rtmpdump,. there still porn out there to be ripped! 
[20:44:16 CEST] <durandal_1707> porn is illegal here, stop promoting it or be banned!
[20:44:24 CEST] <JEEB> Compn: there still is rtmp stuff
[20:44:26 CEST] <Compn> hyc , ksv and svnpenn kind of dissapeared 
[20:44:37 CEST] <Compn> streaming forum died too :\
[20:45:00 CEST] <Compn> JEEB : do you know of any active rtmpdump repos ?
[20:45:20 CEST] <JEEB> nope
[20:46:31 CEST] <Compn> its weird working on a project for so long and then it all stops when the technology + software changes :D
[20:56:33 CEST] <durandal_1707> j-b: i have samples for you
[21:29:05 CEST] <RiCON> Compn: openssl 1.x broke rtmpdump, btw
[21:29:34 CEST] <BtbN> 1.x?!
[21:29:37 CEST] <BtbN> Or you mean 1.1?
[21:29:45 CEST] <JEEB> yea, most likely
[21:31:44 CEST] <RiCON> yeah, msys finally upgraded their openssl to 1.1.1 and promptly broke a few packages
[21:32:26 CEST] <BtbN> well, rtmpdump / librtmp is pretty dead
[21:32:58 CEST] <RiCON> still works with libressl and gnutls, yeah
[21:55:08 CEST] <Compn> RiCON : i personally havent seen an rtmp stream in the wild in a long time. i am happy for this. :D
[21:55:14 CEST] <Compn> i should probably fix rtmpdump but 
[21:55:19 CEST] <Compn> theres so many other patches
[21:55:27 CEST] <Compn> i wish someone would step up to maintain it
[21:56:20 CEST] <Compn> but i'd rather see mplayer maintained than rtmpdump heh
[21:56:22 CEST] <BtbN> Well, everytime you watch Twitch, YouTube, FaceBook, ... live, that's rtmp.
[21:57:06 CEST] <Compn> ah then its possible i was using ffmpeg rtmp stuff to watch those
[21:57:15 CEST] <BtbN> not on the watching side
[21:57:17 CEST] <BtbN> but on the ingest side
[21:57:32 CEST] <BtbN> rtmp web players died with flash
[21:57:56 CEST] <Compn> oh i see
[21:58:04 CEST] <BtbN> And librtmp is the most commonly used "ingest client"
[21:58:17 CEST] <BtbN> Probably because obs uses it
[21:58:18 CEST] <Compn> success! 
[21:59:02 CEST] <Compn> would you say librtmp is used on the phone apps for livestreaming ?
[22:00:25 CEST] <BtbN> I have no clue what they use
[22:00:31 CEST] <JEEB> no. if they have RTMP support it's usually some android thing or so
[22:00:38 CEST] <JEEB> generally HLS/DASH is used
[22:00:47 CEST] <BtbN> Can't ingest with HLS/DASH
[22:00:52 CEST] <JEEB> of course not
[22:01:06 CEST] <BtbN> So the apps can't use that :D
[22:01:09 CEST] <JEEB> or well, actually you can but that's a different story
[22:01:28 CEST] <JEEB> but yes, most ingest is RTMP for a whole lot of stuff
[22:01:34 CEST] <JEEB> which is unfortunate
[22:01:43 CEST] <JEEB> because FLV is not going to get extended by Adobe any more
[22:01:48 CEST] <BtbN> Well, there is a distinct lack of alternatives
[22:01:51 CEST] <JEEB> yet people have their infrastructure
[22:02:12 CEST] <JEEB> BtbN: some things take in fragmented ISOBMFF or MPEG-TS
[22:02:32 CEST] <JEEB> and I think akamai got caught using the MPEG-TS one
[22:02:43 CEST] <JEEB> because their manifests contained a version number
[22:02:48 CEST] <JEEB> and identifier
[22:02:50 CEST] <BtbN> Problem with those usually is that they perform a lot worse when under package loss pressure
[22:03:07 CEST] <JEEB> why would it be any different from RTMP?
[22:03:09 CEST] <JEEB> since it's all TCP
[22:03:22 CEST] <BtbN> as horrible as rtmp is, it really does manage to adapt to low bandwidth
[22:03:46 CEST] <BtbN> by dropping the "least important" frames first
[22:03:55 CEST] <JEEB> isn't that an implementation detail?
[22:04:21 CEST] <JEEB> the sender drops non-I frames if there's bandwidth issues
[22:04:33 CEST] <BtbN> not really, B before P before I before audio dropping is part of the protocol
[22:04:55 CEST] <kierank> an intelligent sender can drop whatever in ts
[22:05:06 CEST] <BtbN> With pure mpeg-ts that's kinds hard to do, as the layer that's doing the network sending doesn't usually have that information
[22:06:46 CEST] <kierank> yes hence intelligent sender
[22:10:58 CEST] <durandal_1707> Compn: you are responsible for mplayer death
[22:26:33 CEST] <j-b> durandal_1707: Nice.
[22:30:23 CEST] <durandal_1707> can i upload to samples.ffmpeg.org or to videolan ftp server or some other one?
[22:33:03 CEST] <j-b> sure
[22:33:11 CEST] <j-b> put the mess you have wherever youcan
[22:49:07 CEST] <durandal_1707> j-b: AGM2 https://0x0.st/sY9F.agm
[22:51:07 CEST] <durandal_1707> j-b: RASC https://0x0.st/sYpi.avi --- ffmpeg already have decoder for it
[22:53:42 CEST] <durandal_1707> Compn ^ more samples
[00:00:00 CEST] --- Tue Oct  2 2018