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

[burek]

[00:13:51 CEST] <thardin> I'd say this project isn't small potatoes in the video world, so taking a harder stance/leading the way should work
[00:24:03 CEST] <kierank> thardin: it's not a big potato either tbh
[00:24:16 CEST] <thardin> mm
[00:44:55 CEST] <cone-488> ffmpeg 03Michael Niedermayer 07release/3.2:abdbbe895838: avcodec/htmlsubtitles: Be a bit more picky on syntax
[00:44:55 CEST] <cone-488> ffmpeg 03Kevin Backhouse via RT 07release/3.2:23ccf3cabb4b: avcodec/htmlsubtitles: Fixes denial of service due to use of sscanf in inner loop for tag scaning
[00:44:55 CEST] <cone-488> ffmpeg 03Kevin Backhouse via RT 07release/3.2:273f2755ce86: avcodec/htmlsubtitles: Fixes denial of service due to use of sscanf in inner loop for handling braces
[00:44:55 CEST] <cone-488> ffmpeg 03Michael Niedermayer 07release/3.2:ba11e4028cfc: Changelog: Update
[01:49:33 CEST] <cone-488> ffmpeg 03Gyan Doshi 07n3.2.14:HEAD: doc/filters: add scale2ref example for proportional scaling
[11:36:41 CEST] <cone-586> ffmpeg 03Jun Zhao 07master:c663046b4105: lavf/dashdec: fix the coding logic after open_input fail
[11:36:41 CEST] <cone-586> ffmpeg 03Jun Zhao 07master:bf6e0f709be2: lavf/dashdec: refactoring error handle logic for open_input
[12:09:15 CEST] <cone-586> ffmpeg 03Andreas Rheinhardt 07master:8b2140de6314: avutil: Add missing reference files for pixdesc fate test
[12:09:16 CEST] <cone-586> ffmpeg 03Michael Niedermayer 07master:87a54e150e9c: avcodec/cinepak: Check available input against encoded buffer size
[14:03:42 CEST] <somedave> hello.  I'm looking for a bit of guidance on reporting a bug.  The problem is that it's not always reproducible so doesn't quite fit into the bug reporting guidelines
[14:03:57 CEST] <somedave> the headline for my problem would be that using ffprobe to find the duration of a file sometimes returns blank output
[14:05:49 CEST] <somedave> I have all the output from
[14:05:50 CEST] <somedave> ffprobe -i myfile.mp4 -show_entries format=duration -v trace -of csv=p=0
[14:06:02 CEST] <somedave> (the trace output, I mean)
[14:32:44 CEST] <somedave> it still happens with
[14:32:46 CEST] <somedave> https://johnvansickle.com/ffmpeg/builds/ffmpeg-git-i686-static.tar.xz
[14:32:53 CEST] <somedave> (git: g06ba4783a0 built on 20190507)
[14:43:44 CEST] <somedave> I tried ffmpeg-devel but having looked at the irc logs on the web it may work well here.
[14:43:51 CEST] <somedave> I'm looking for a bit of guidance on reporting a bug.  The problem is that it's not always reproducible so doesn't quite fit into the bug reporting guidelines
[14:44:02 CEST] <somedave> the headline for my problem would be that using ffprobe to find the duration of a file sometimes returns blank output
[14:44:09 CEST] <somedave> I have all the trace output from
[14:44:10 CEST] <somedave> ffprobe -i myfile.mp4 -show_entries format=duration -v trace -of csv=p=0
[14:44:18 CEST] <somedave> it still happens with
[14:44:18 CEST] <somedave> https://johnvansickle.com/ffmpeg/builds/ffmpeg-git-i686-static.tar.xz
[14:44:19 CEST] <somedave> (git: g06ba4783a0 built on 20190507)
[14:44:31 CEST] <somedave> (sigh, sorry)
[14:45:04 CEST] <cone-586> ffmpeg 03Paul B Mahol 07master:8ef163ba9e3d: avfilter: add xmedian filter
[14:52:56 CEST] <cone-586> ffmpeg 03Andreas Rheinhardt 07master:670251de56cd: avfilter/vf_stack: Don't modify const strings
[15:25:31 CEST] <cone-586> ffmpeg 03Paul B Mahol 07master:f49cec2ba883: avfilter: add asr filter
[16:19:07 CEST] <kurosu> pross: getting consistent 0.5% speedup for using a better bitstream reader for the vp4 decoder would indicate a lot of time is spent there
[16:20:01 CEST] <kurosu> which makes me think I haven't seen benchmarks for the cached reader elsewhere than lossless video (where it makes the most sense)
[16:21:09 CEST] <kurosu> Could be interesting, but who cares about a 1% speedup on a "millennial" codec, I guess
[16:21:54 CEST] <kurosu> Ah, I hadn't got to James' mail :D
[18:05:45 CEST] <Lynne> great, the mdct thread has been completely derailed by carl
[19:23:06 CEST] <BtbN> philipl, https://www.nvidia.com/Download/driverResults.aspx/147582/en-us
[19:35:22 CEST] <kurosu> Lynne: whenever 2 out of 3-4 people start discussing, it seems to turn sour - haven't checked, not sure it is the case here
[19:38:34 CEST] <kurosu> re the original issue, I would also prefer to still copy the copyright even if incomplete because:
[19:39:12 CEST] <kurosu> 1) that someone did something wrong should not encourage to do the same thing
[19:39:18 CEST] <kurosu> 2) it's just the nice thing to do
[19:39:57 CEST] <kurosu> 3) some of the issue can be traced to git not copying over history (it's either in one file or in another when you split)
[19:41:36 CEST] <kurosu>  I'd think Carl and myself wouldn't be alone to have an opinion on the side of copying the copyright
[19:46:04 CEST] <Lynne> so do we add everyone who ever contributed to headers or do we carry around decade old headers which can't be removed
[19:47:23 CEST] <kurosu> it's true that eg for relicensing you'd still have to search for history
[19:47:39 CEST] <kurosu> but when in doubt, I just prefer leaving the copyright out of respect
[19:47:56 CEST] <kurosu> the discussion, now that I've read it, is more undecided, I admit
[19:48:30 CEST] <Lynne> what if there's an author who doesn't own copyright and a copyright owner who didn't write the code listed?
[19:50:19 CEST] <kurosu> that is not the point I'm making
[19:50:28 CEST] <kurosu> if you can prove it's wrong then so be it
[19:50:42 CEST] <kurosu> you may have a point in that case
[19:51:04 CEST] <kurosu> I'm not going to say no to the commit or anything
[19:51:30 CEST] <kurosu> I'm just stating that I don't like that particular point, but that's not something I want to fight or argue about
[19:51:42 CEST] <Lynne> well my point is that it isn't so black and white and for any serious copyright/authorship digging you'll need to trace the git history
[19:52:24 CEST] <kurosu> yeah, that happened, and is needed, when relicensing occured
[19:52:41 CEST] <Lynne> so having decade old headers isn't helping anyone, especially those who commited but didn't add their name to the header
[19:54:10 CEST] <kurosu> that happened to me more than once - added code to a file, didn't add myself as author
[19:54:57 CEST] <kurosu> yet, I consider the potential bad of removing an author as more important than the potential good (or null consequence) of removing him
[19:58:28 CEST] <kurosu> Lynne: I see the topic is getting heated, sorry for pouring more gasoline - it's not worth causing more bad feelings, so I'll just shutup
[20:02:49 CEST] <jamrial> Lynne: just add Loren Merritt and the libdjbfft lines plus a line with your name and the year 2019 to tx.c, and lets get it over with
[20:04:46 CEST] <kurosu> on the technical side, Rotislav would have had comments I guess
[20:41:17 CEST] <Lynne> jamrial: done
[21:43:53 CEST] <kurosu> Lynne: what's the object size of tx.o ? Not that it matters (it needs what it needs), just out of curiosity
[21:44:30 CEST] <kurosu> also, how was this benchmarked? (I don't remember if there's a specific benchmark tool)
[21:45:06 CEST] <kurosu> ie how big the data was? (eg was it fitting in L1 or L2 cache)
[21:50:02 CEST] <cone-742> ffmpeg 03James Almer 07master:58d167bcd517: avcodec/Makefile: add missing pngdsp dependency to the lscr decoder
[22:00:37 CEST] <Lynne> kurosu: 700k with debug data, 60k stripped
[22:02:15 CEST] <Lynne> tested this with a hacky program which linked to the object file and ran it on a random N length array, measured time with a ripped off standalone libavutil/timer.h
[22:03:14 CEST] <kurosu> ok about benchmarking, sounds like what I thought more probable
[22:03:37 CEST] <kurosu> how much are the tables out of that object size? are they duplicate of other ones elsewhere ?
[22:03:55 CEST] <kurosu> (may not be shareable)
[22:04:15 CEST] <kurosu> not a big deal, as the end goal is I guess to remove any duplocation
[22:04:19 CEST] <kurosu> *duplication
[22:04:52 CEST] <Lynne> they're duplicated in lavc, but lavu can't depend on lavc
[22:06:21 CEST] <Lynne> like the commit message says I'm not sure when lavc's fft can be removed, though we should deprecate av_fft once there's at least x86 SIMD
[22:14:28 CEST] <Lynne> actually maybe not, if there's x86, neon and aarch64 simd maybe some certain person who doesn't even use 3dnow and mmx won't realize there's no 3dnow or mmx SIMD
[22:15:29 CEST] <kurosu> yay smaller libs! but sorry, this channel is publicly logged :D
[22:19:58 CEST] <BBB> mmx simd?
[22:20:02 CEST] <BBB> o_O
[22:20:10 CEST] <BBB> don't forget pentium pro simd :-p
[22:21:47 CEST] <kepstin> hmm, does this mean that ffmpeg is getting slower on my K6-III+ box? :)
[22:22:30 CEST] <kepstin> (that's mostly a joke, it can't usefully do anything with modern media anyways)
[22:31:25 CEST] <BBB> and lynne is right, that thread went insane
[22:51:54 CEST] <philipl> BtbN: which part? the vdpau stuff was in 430.09 too. That's what provoked the work I did last week.
[22:52:24 CEST] <BtbN> Huh, their changelogs are weird then.
[22:52:31 CEST] <BtbN> Thought that wasn't released in a driver yet
[22:52:40 CEST] <philipl> It's because 430.09 was a beta driver and 430.14 is a 'release' driver.
[22:52:43 CEST] <philipl> they repeat the changelog
[22:53:14 CEST] <philipl> BtbN: please look at the scale_cuda changes when you can.
[22:53:29 CEST] <BtbN> ah, will do
[00:00:00 CEST] --- Wed May 15 2019