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

[burek]

[01:18:02 CEST] <cone-031> ffmpeg 03James Almer 07master:af2acbd23f85: avcodec/av1_metadata: add an option to insert and remove Temporal Delimiter OBUs
[01:49:31 CEST] <cone-031> ffmpeg 03James Almer 07master:ebc3d04b8df4: avcodec: add an AV1 parser
[03:42:50 CEST] <kierank> https://github.com/FFmpeg/FFmpeg
[03:42:53 CEST] <kierank> dates are screwed up, weird
[04:16:11 CEST] <BradleyS> kierank: i believe you may be referring to the authored dates, which may be different than committed dates
[04:17:03 CEST] <BradleyS> so if you author a commit and then amend it or rebase, the committed date will be different while the authored date stays the same
[04:17:16 CEST] <kierank> github seems to be mixing the dates then
[04:17:25 CEST] <kierank> "jamrial committed on 14 Jul"
[04:17:58 CEST] <BradleyS> i agree it's pretty silly, they should s/committed/authored/
[04:18:40 CEST] <jamrial> yeah, authored date is 14 july because i've been rebasing and changing the commit locally since then
[04:18:49 CEST] <jamrial> no idea why github shows it as commit date
[04:20:49 CEST] <BradleyS> git log --pretty=fuller
[04:21:12 CEST] <BradleyS> i'm pretty sure i reported this to github awhile back but *shrug*
[08:27:01 CEST] <sharax> hello
[08:27:13 CEST] <sharax> i want to install ffmpeg on centos 7 for php7 
[08:27:15 CEST] <sharax> can help me?
[12:07:32 CEST] <J_Darnley> Sure: ./configure && make
[12:07:56 CEST] <J_Darnley> Oh that was three and half hours ago
[12:17:22 CEST] <JEEB> I already told him to stop spamming on #ffmpeg and that php-ffmpeg has nothing to do with FFmpeg
[12:18:39 CEST] <durandal_1707> it is so quiet
[12:18:52 CEST] <JEEB> enjoy the calm before the storm?
[12:28:35 CEST] <cone-025> ffmpeg 03Paul B Mahol 07master:7d65fe87e9d3: avfilter: add ff_inlink_queued_samples()
[12:28:35 CEST] <cone-025> ffmpeg 03Paul B Mahol 07master:ef3babb2c70f: avfilter/af_asetnsamples: use lavfi internal queue
[12:28:36 CEST] <cone-025> ffmpeg 03Paul B Mahol 07master:6725fd8b0fb7: avfilter/af_headphone: use lavfi internal queue instead
[12:28:37 CEST] <cone-025> ffmpeg 03Paul B Mahol 07master:4901fa1fb8de: avfilter/af_afir: use internal lavfi queue
[12:35:16 CEST] <JEEB> fun sample
[12:36:32 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=fftools/ffmpeg.c;h=934dc71a74e41c5f969d91086c1cd87868898d0c;hb=HEAD#l4463
[12:36:59 CEST] <JEEB> ffmpeg.c hits this, then adjusts and then the logic starts adjusting timestamps on both video and audio at each read
[12:37:14 CEST] <JEEB> because first you get a funky amount of audio packets which crawl up
[12:37:23 CEST] <January> How can I make gmail manageable with the mailing list? In other email services I can setup ffmpeg emails to go to a folder, Ive done this on gmail but they still go to inbox as they use tags
[12:37:24 CEST] <JEEB> and don't cause a discontinuities
[12:37:43 CEST] <JEEB> January: I've been able to make a directory just fine?
[12:37:47 CEST] <JEEB> or whatever it's called
[12:37:51 CEST] <JEEB> in IMAP it ended up as a directory
[12:38:22 CEST] <January> Mmh. Mine ended up as a directory in their web client but nothing to reflect that in IMAP
[12:39:21 CEST] <JEEB> I did the setup 100% in the webui
[12:39:36 CEST] <JEEB> basically I added a rule for the mailing list
[12:39:52 CEST] <JEEB> "move to directory and 'archive (move from inbox)'"
[12:39:55 CEST] <JEEB> if I recall correctly
[12:40:11 CEST] <JEEB> latter makes sure it doesn't "stick" in your inbox IIRC
[12:40:49 CEST] <JEEB> they redid the gmail webui lately so I can't say exactly how I did it, but you should have an alternative to "filter messages from this list" if you open a ffmpeg-devel e-mail
[12:42:38 CEST] <JEEB> anyways, I wonder if it makes sense to check if we've already taken in a packet with a similar timestamp that doesn't go over our dts_delta_threshold
[12:42:45 CEST] <JEEB> for example if we have a video track, check the audio track
[12:42:50 CEST] <JEEB> *check all audio tracks
[12:42:53 CEST] <JEEB> or vice versa
[12:43:40 CEST] <JEEB> because if we've already taken in a packet with similar timestamp then adjusting the timestamp doesn't really make sense as it most likely will cause A/V desync in case the timestamps are correct and there just was a discontinuity
[12:44:11 CEST] <JEEB> I have a 60s sample if anyone wants to see ffmpeg.c freaking out
[12:44:29 CEST] <JEEB> but yea, I did add a check like that and it effectively stops the snowfall
[12:44:53 CEST] <JEEB> (vanilla keeps on adjusting timestamps for both audio and video, and the result is 100% out of sync for the amount of discontinuity)
[12:45:40 CEST] Action: JEEB is just wondering if as an idea that makes sense
[13:44:26 CEST] <JEEB> http://up-cat.net/p/dc4a0d2d
[13:45:16 CEST] <JEEB> so then with each read that discontinuity check gets hit and the timings are all over the place
[13:45:55 CEST] <JEEB> while if you just make it compare the received timestamp against the audio's next_dts then you figure out that you're close enough, and you block the "fixing"
[13:46:02 CEST] <JEEB> but I have no idea if that makes sense as a check :P
[13:47:01 CEST] <JEEB> basically as a "you've already let the other stream go far enough that they seem to be in synch, maybe let's not touch the timestamps any more?"
[13:49:39 CEST] <JEEB> with my PoC it just does http://up-cat.net/p/805aa51b
[13:49:48 CEST] <JEEB> and keeps on churning OK with no visible breakage in A/V synvh
[13:49:50 CEST] <JEEB> *synch
[14:40:41 CEST] <January> JEEB: ah. Needed the 'archive' flag, works now thanks
[14:52:35 CEST] <JEEB> cheers
[18:24:16 CEST] <lemourin> Hi, if I made MediaFoundation wrapper for FFmpeg, would you merge it? I saw this https://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209720.html and I would like to make it work with current master.
[18:24:56 CEST] <nevcairiel> thats questionable
[18:25:18 CEST] <nevcairiel> what exactly would it allow you to d o that we cant  do already? And why wouldnt one work to allow whatever thing without some huge other framework involved?
[18:25:50 CEST] <lemourin> The idea is that if you use MediaFoundation you don't have to pay MPEG LA royalties.
[18:26:37 CEST] <lemourin> Because Microsoft paid it already when it selled you Windows
[18:27:00 CEST] <lemourin> I have that confirmed with a lawyer.
[18:29:30 CEST] <nevcairiel> yeah thats not a reason thats going to convince anyone to add a huge chunk of code thats going to be hard to maintain
[18:29:44 CEST] <nevcairiel> instead of using avcodec you could just use  MF directly in your code
[18:29:54 CEST] <nevcairiel> its probably even easier then making a patch
[18:35:59 CEST] <lemourin> Yeah it would probably work. And it would be easier. I just thought that I could implement something which could be useful for someone in the future (besides me).
[18:39:00 CEST] <lemourin> Ah, and it gives you a non GPL h264/hevc encoder.
[18:39:16 CEST] <lemourin> Software encoder.
[18:39:46 CEST] <JEEB> openh264 exists for that
[18:39:51 CEST] <lemourin> openh264 is crap
[18:39:54 CEST] <JEEB> sure
[18:40:10 CEST] <lemourin> and has very weird license
[18:40:12 CEST] <JEEB> then you have that new project for HEVC from intel which I haven't been able to benchmark yet
[18:40:38 CEST] <JEEB> I thought the license was relatively standard? the only extra bit is that if you take the binaries from cisco you don't need to care about MPEG-LA
[18:40:45 CEST] <JEEB> since end user distro is being done by cisco
[18:41:06 CEST] <JEEB> (which is why mozilla downloads cisco binaries of openh264)
[18:41:15 CEST] <lemourin> yes, but you have to offer builds with and without this encoder and user has to be able to choose
[18:42:20 CEST] <lemourin> @JEEB do you mean this: https://github.com/ultravideo/kvazaar ?
[18:42:53 CEST] <JEEB> lemourin: no, although that's an older Tampere uni project
[18:42:59 CEST] <JEEB> https://github.com/intel/SVT-HEVC
[18:43:03 CEST] <JEEB> this is the recent intel thing
[18:44:58 CEST] <durandal_1707> hevc is out, AV1 is IN
[18:46:34 CEST] <JEEB> they said they'll be publishing an optimized AV1 encoder as well, but so far that mailing list only has a single test e-mail
[18:46:47 CEST] <lemourin> AV1 plz; it took me a week to encode 3 minutes 60fps fullhd video
[18:46:50 CEST] <lemourin> 12k frames
[18:46:51 CEST] <JEEB> https://lists.01.org/pipermail/svt-av1/2018-September/thread.html
[18:47:14 CEST] <lemourin> and it looks shit :(
[18:47:29 CEST] <durandal_1707> what?
[18:47:30 CEST] <JEEB> yea, not much psyopts
[18:49:15 CEST] <lemourin> so still no h264 non gpl software encoder
[18:49:30 CEST] <lemourin> so this would be a reason for MF wrapper
[18:49:56 CEST] <durandal_1707> write it for gstreamer
[18:51:10 CEST] <lemourin> why don't you want it in ffmpeg?
[18:52:09 CEST] <atomnuker> lemourin: hey, x264 can be lgpl if you paid money to license it
[18:52:40 CEST] <lemourin> @atomnuker: and royalties as well..
[18:52:57 CEST] <lemourin> so like 15mln usd / year
[18:53:29 CEST] <JEEB> we have encoders for mac frameworks and such :P
[18:53:36 CEST] <bencoh> JEEB: how does it compare to x265 (SVT-HEVC)?
[18:53:38 CEST] <JEEB> so for encoders MF /might/ be useful
[18:53:48 CEST] <JEEB> bencoh: as I said I have not had *any* time to check it out
[18:53:58 CEST] <bencoh> ah, mybad
[18:54:08 CEST] <JEEB> its primary thing seems to be being able to share some stuff between profiles
[18:54:11 CEST] <JEEB> in a multi-profile encode
[18:54:15 CEST] <lemourin> exactly, thats just weird that i do have encoders for mac and linux but not for windows
[18:54:41 CEST] <JEEB> lemourin: with MF by default people think of decoding :P
[18:54:48 CEST] <JEEB> which is available through dxva2 and d3d11va
[18:54:54 CEST] <lemourin> yea i know
[18:55:30 CEST] <lemourin> i wanted to start implementing it but i don't want to do it if there is no chance to merge it
[18:55:58 CEST] <bencoh> JEEB: that could be done with no specific encoder support for quite a lot of things, but, meh, why not :)
[18:56:10 CEST] <bencoh> (it does save computing time though)
[18:56:40 CEST] <bencoh> (I'd still rather see a good h265 encoder than a medium-grade multi-profile one)
[18:57:15 CEST] <durandal_1707> I do not like windows in general, and ms in particular, otherwise why not write other wrappers like dshow and vfw?
[18:57:16 CEST] <atomnuker> x265 is decent
[18:57:53 CEST] <lemourin> durandal_1707: do those have encoders?
[18:58:21 CEST] <bencoh> atomnuker: I haven't had a look at time for quite a while, to be honest
[18:58:24 CEST] <JEEB> bencoh: sure, for VOD I totally agree
[18:58:40 CEST] <JEEB> for live streams I feel like we could get quite a bit from both x264 or x265 if we'd share some metrics
[18:58:45 CEST] <JEEB> and/or decisions
[18:58:58 CEST] <JEEB> x265 already has an API for that but I'm not sure if it would fit into lavc at all :P
[19:00:22 CEST] <bencoh> an API for? uploading metrics?
[19:00:30 CEST] <JEEB> sharing state
[19:00:33 CEST] <bencoh> or live-sharing between encoders?
[19:08:23 CEST] <lemourin> So what's the conclusion; a definite no for MF encoders in FFmpeg?
[19:09:01 CEST] <January> lemourin: I wouldnt go to the effort to implement it in FFmpeg if I were you
[19:09:50 CEST] <JEEB> we have AMF and QSV and nvenc for windows I think, and the primary reason we have the QT API encoders on macOS is because that's the only API? but as such MF and QT would be similar for encoding
[19:09:54 CEST] <JEEB> so I dunno
[19:10:32 CEST] <lemourin> you have videotoolbox on mac
[19:10:43 CEST] <JEEB> that's what I more or less meant I guess :s
[19:10:48 CEST] <JEEB> I didn't remember the API name
[19:11:06 CEST] <lemourin> @January: don't worry about my effort; I dont do it for free luckily
[19:15:36 CEST] <January> lemourin: I mean, if you did it in a similar fashion to macOS  then I dont see why it wouldnt be accepted provided there werent any really big issues, I guess
[19:15:59 CEST] <January> Maybe implement a minimum patch and send to ML
[19:16:51 CEST] <JEEB> also one thing that should be kept in mind
[19:17:01 CEST] <JEEB> does lavc's abstractions and usage match with the MF model
[19:17:44 CEST] <lemourin> i wouldn't even start this discussion if i didn't see a patch that did the MF wrapper
[19:17:51 CEST] <lemourin> but was abandoned
[19:18:02 CEST] <lemourin> anyway thanks, now i have some incentive to do it
[19:19:17 CEST] <lemourin> @JEEB: "we have AMF and QSV and nvenc" those are all hardware encoders; what if someone has amd processor with no gpu :P
[19:19:31 CEST] <JEEB> yes, very true
[20:01:10 CEST] <durandal_1707> j-b: do you have any ETA?
[20:19:35 CEST] <gnafu> Has there been any more movement on implementing tiles support for libaom-av1?  I particularly liked the idea of having a '-tiles
[20:19:52 CEST] <gnafu> ' option instead of having to specify columns and rows, even though it breaks from libvpx-vp9 tradition.
[20:20:42 CEST] <gnafu> Just curious if that's being actively figured out, or if what's on the ML is the latest news.
[20:21:58 CEST] <gnafu> Oh, and I see I missed a newer mention on the ML, and it looks like the patest patch implements both.  Nice!
[20:22:08 CEST] <gnafu> s/patest/latest/
[20:45:02 CEST] <cone-371> ffmpeg 03James Almer 07master:e08a876e67a7: avcodec/libaomdec: remove bogus comment
[20:57:13 CEST] <gnafu> Is '-b:v 0' still required with libaom-av1 to do constant quality, or is it enough to specify -crf and no bitrate?
[20:57:34 CEST] <gnafu> I know libvpx-vp9 required '-b:v 0'.
[21:03:43 CEST] <jamrial> gnafu: for constant quality you still need to set bitrate to 0
[21:04:00 CEST] <jamrial> otherwise the default of 256 is used, which results in constrained quality
[21:06:43 CEST] <gnafu> jamrial: Thanks :-).  I wanted to make sure I wasn't just putting it out of habit if it wasn't actually needed.
[23:10:41 CEST] <lotharkript__> Hi all. Commit http://git.videolan.org/?p=ffmpeg.git;h=ddef3d902f0e4cbd6be6b3e5df7ec158ce51488b  enabled passing through of rotation side data from input to output. This is an issue when using HW filter to rotate, but have no way of clearing this side data after rotation. Is there a way to clear stream side data for output, from command line ?
[23:20:08 CEST] <tmm1> would it make sense to let the metadata bsfs passthrough packets they weren't able to parse?
[23:53:27 CEST] <cone-276> ffmpeg 03Paul B Mahol 07master:0baca077593d: avilter/af_afir: add irfmt option
[23:53:27 CEST] <cone-276> ffmpeg 03Paul B Mahol 07master:196dd13c76c2: avfilter/avf_showspectrum: implement zoom mode
[00:00:00 CEST] --- Fri Oct  5 2018