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

[burek]

[00:11:31 CEST] <durandal_1707> ubitux: have you posted link here about audio spatialization long ago?
[01:11:40 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:c5d2fa2fdff0: avcodec/takdec: Fix multiple  runtime error: left shift of negative value -1
[01:11:41 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:ddb2dd7edbcc: avcodec/lagarith: Fix runtime error: left shift of negative value -1
[01:11:42 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:ed3c9b5b0dd5: avcodec/lagarith: Check scale_factor
[02:38:38 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:2bd8eb05d21b: avcodec/texturedsp: Fix runtime error: left shift of 218 by 24 places cannot be represented in type 'int'
[02:38:39 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:ae6fd1790f48: avcodec/svq3: Fix multiple runtime error: signed integer overflow: -237341 * 24552 cannot be represented in type 'int'
[03:50:08 CEST] <KGB> [13FFV1] 15dericed opened pull request #60: update to version 02 (06master...06version-02) 02https://git.io/v9PH0
[04:08:25 CEST] <cone-714> ffmpeg 03James Almer 07master:984e2218f2a0: avfilter/af_afir: remove extra space in the header inclusion guards
[04:23:02 CEST] <KGB> [13FFV1] 15michaelni closed pull request #60: update to version 02 (06master...06version-02) 02https://git.io/v9PH0
[06:09:08 CEST] <rcombs> >Application provided invalid, non monotonically increasing dts to muxer in stream
[06:09:33 CEST] <rcombs> getting this when trying to remux MPEGTS->MPEGTS(segment)
[06:09:42 CEST] <rcombs> wondering what the best solution is
[06:11:01 CEST] <rcombs> it's accurate; the source packets do go backwards in time
[06:11:22 CEST] <rcombs> and sometimes just don't advance
[06:12:38 CEST] <rcombs> wondering if I should add a flag to just log and go on instead of failing (I could've sworn that used to happen, at least in some cases), or maybe to rewrite bad timestamps to never decrease
[06:14:05 CEST] <wm4> why do the timestamps go backwards?
[06:14:23 CEST] <rcombs> ~broadcast~
[06:14:29 CEST] <wm4> or are these normal timestamp wraparounds
[06:17:17 CEST] <rcombs> it's interesting; only the second timestamp goes backwards wrt the first one
[06:17:32 CEST] <rcombs> so maybe it's a quirk of the tuner
[06:17:44 CEST] <rcombs> (or, maybe they go backwards again later; I'm not sure)
[06:18:42 CEST] <rcombs> yeah, just the first one
[06:19:20 CEST] <wm4> could be libavformat/utils.c corrupting the timestamps
[06:21:56 CEST] <rcombs> they show up backwards in time in ffprobe, so if it's a bug it's a demux-side one
[06:22:40 CEST] <wm4> that's what I mean
[06:22:56 CEST] <wm4> it wouldn't be the first case... utils.c used to corrupt h264 timestamps in ts too
[06:25:29 CEST] <rcombs> what other tools are useful to compare output with
[06:26:10 CEST] <wm4> good question
[06:26:49 CEST] <wm4> personally I'd probably first check whether mpegts itself returns monotonic timestamps or not
[06:27:08 CEST] <rcombs> https://puu.sh/vLhXB/acf855cc4c.ts here's the file
[06:27:23 CEST] <rcombs> hmm, easy enough to check
[06:30:51 CEST] <rcombs> yeah, they go backwards in mpegts.c
[06:32:02 CEST] <wm4> evil
[06:34:50 CEST] <jamrial> kierank: i sent a patch long ago that converted fdct from inline asm to y/nasm, but it wasn't committed as it depended on some other code that was still inline
[06:35:10 CEST] <kierank> jamrial: ok, we are doing idct
[06:35:54 CEST] <jamrial> so if J_Darnley was going to deal with that, tell him to pick it up so he doesn't rewrite it
[06:52:33 CEST] <kierank> ok
[09:17:23 CEST] <ubitux> durandal_1707: mmh that's possible but i don't remember; ebu r128 is a modelization of this, so i may have shared some papers but i honestly don't remember
[10:30:58 CEST] <cone-366> ffmpeg 03Ben Chang 07master:18a659d1b653: avcodec/nvenc: add fractional CQ support
[10:30:59 CEST] <cone-366> ffmpeg 03Sumit Agarwal 07master:01775730fd1e: avcodec/nvenc: add weighted prediction support
[14:02:04 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07master:ec1f869f0f5b: doc/codecs: Add missing documentation for apply_cropping
[14:02:05 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07master:014d47ed74c4: doc/codecs: Change common boolean parameters listed to "bool"
[14:02:06 CEST] <cone-366> ffmpeg 03Simon Thelen 07master:54b6bef6e13a: libavformat/tcp: fix return code for tcp_accept
[14:02:07 CEST] <cone-366> ffmpeg 03Martin Vignali 07master:6ce57fb3c2ef: fate/exr : add test for Y, b44A negative half, and datawindow != displaywindow
[14:02:08 CEST] <cone-366> ffmpeg 03erankor 07master:2b06f2d2e24c: ffmpeg: add enc_time_base option
[14:29:09 CEST] <BBB> nevcairiel: is http://stackoverflow.com/questions/43542888/ffmpeg-msvc-compilation-stuck/43882289#43882289 true? (i.e. does ffmpeg fail to compile currently with msvs 2010?)
[14:29:20 CEST] <BBB> nevcairiel: is that something you might be able to test?
[14:29:33 CEST] <nevcairiel> i stopped caring about 2010 years ago
[14:29:41 CEST] <nevcairiel> tell them hat 2015 and 2017 are free =p
[14:30:04 CEST] <iive> they are?
[14:30:26 CEST] <iive> great, now I just need a windows :D
[14:30:42 CEST] <nevcairiel> with conditions (ie. for single developers or teams of up to 5 people iirc, companies still need to buy), but yes
[14:30:44 CEST] <iive> j/k
[14:31:37 CEST] <iive> these are pritty reasonable conditions
[14:32:06 CEST] <wbs> and only as long as your turnover is less than a couple hundred thousand $ or so
[14:32:18 CEST] <nevcairiel> (at which point you can afford it)
[14:33:06 CEST] <BBB> nevcairiel: do you think its worth testing?
[14:33:06 CEST] <nevcairiel> BBB: anyhow I don't even have 2010 or 2012 installed anymore anywhere, the compiler "getting stuck" seems  rather odd though, if it would just error or something we could fix it
[14:33:11 CEST] <nevcairiel> personally? no
[14:33:14 CEST] <BBB> ok
[14:33:23 CEST] <nevcairiel> wbs still has 2010 test boxes for libav, though
[14:33:51 CEST] <wbs> the issue sounds to me like c99conv messes up with the source in ffv1enc.c
[14:34:06 CEST] <BtbN> BBB, the exact same thing is occasionally happening with MSVC2017 to me as well.
[14:34:11 CEST] <BtbN> cl.exe gets stuck and eats all my 32GB of RAM
[14:34:22 CEST] <nevcairiel> i have never had that
[14:34:36 CEST] <wbs> on the same file, or something different? if that guy gets it reliably on that file, it might be a different issue
[14:34:43 CEST] <BtbN> just canceling and continuing makes everything work usually
[14:35:22 CEST] <BBB> wbs: right that was my first idea also
[14:35:33 CEST] <BBB> wbs: but then the fix that he put there seems & incredibly strange
[14:35:41 CEST] <wbs> BBB: indeed
[14:35:43 CEST] <BBB> i.e. something c99conv should support
[14:35:52 CEST] <BBB> since its just random preproc garbage
[14:36:29 CEST] <wbs> in any case, c99conv has long outlived its intended usage IMO - if there still are issues and they easily can be fixed (like nevcairiel said, I'm still running fate instances with it for libav), fine, but otherwise I wouldn't spend much extra effort on it these days
[14:36:43 CEST] <wbs> it has worked surprisingly well with surprisingly little extra maintainance though I have to say
[14:36:58 CEST] <BBB> indeed
[14:37:18 CEST] <BBB> I agree c99conv isnt worth maintaining much longer, the goal was to get msvs to support c99 and they do
[14:37:30 CEST] <BBB> Ive always been worried that c99conv bugs can cause valid source code to introduce buggy behaviour
[14:38:00 CEST] <BBB> which could then be abused to get tricky code into a linuxy project and get them to accidnetally ship broken windows code that could be used to take over a system or so
[14:38:04 CEST] <BBB> not sure how realistic that is
[14:38:11 CEST] <BBB> but Id rather not be responsible for that ;)
[14:39:50 CEST] <BtbN> BBB, i didn't pay attention to where it happens, and it's also hard to tell, as I usually run with -j16
[14:40:02 CEST] <BtbN> so by the time I notice that one cl.exe is stuck, the build is way way ahead
[14:40:16 CEST] <BBB> is there something like ps aux so you can see the full commandline invocation of the cl that is stuck?
[14:40:25 CEST] <BBB> <- windows n00b
[14:40:26 CEST] <BtbN> None that I'm aware of, taskmanager only shows cl.exe
[14:40:57 CEST] <BtbN> it also only happens very infrequently
[14:41:01 CEST] <BtbN> most builds finish just fine
[14:41:32 CEST] <BtbN> Idea for a cuvid based video processing filter?
[14:41:41 CEST] <BtbN> cuvpp? cuvid_vpp? nvvpp?
[14:41:56 CEST] <nevcairiel> cuvid is no longer used as a name
[14:41:56 CEST] <nevcairiel> :D
[14:42:08 CEST] <BBB> is it possible that you let the build finish and then re-run (after all other files have completed) so you can see which file didnt finish int he first make invocation?
[14:42:16 CEST] <BBB> then at least you could see which file it was
[14:44:52 CEST] <Compn> arent there other projects using c99conv ?
[14:45:08 CEST] <Compn> i'm not saying we should support it for them, but if we are to abandon it, we can give some notice
[14:45:43 CEST] <iive> what is c99conv a program that turns c99 source into something that msvc can compile?
[14:45:50 CEST] <BtbN> yes
[14:45:54 CEST] <BtbN> old MSVC
[14:45:56 CEST] <iive> is c99conv opensource? or microsoft ?
[14:46:02 CEST] <BtbN> modern msvc has no issues with c99
[14:46:31 CEST] <BBB> Compn: I think some other people have occasionally used it, but were not taking away binaries nor are we actively deleting the code
[14:46:58 CEST] <Compn> no problem, i am just saying a news post wouldnt hurt 
[14:47:50 CEST] <BBB> dont forget c99conv isnt a ffmpeg project, its a separate thing
[14:48:19 CEST] <atomnuker> abandon it?
[14:48:21 CEST] <BBB> (so the news posting wouldnt appear on ffmpeg.org)
[14:48:47 CEST] <atomnuker> how are we going to abandon it? we still have to support msvc older than 2012, right?
[14:48:47 CEST] <Compn> it could appear on ffmpeg.org though. nothing stopping that from happening
[14:49:03 CEST] <atomnuker> (I'm all for dropping it if I can start using for (int i loops)
[14:49:49 CEST] <iive> ok, so the problem is that c99conv is broken and there is nobody to fix it?
[14:50:48 CEST] <BBB> I dont think anyone is advocating dropping or abandoning anything
[14:57:13 CEST] <BBB> what do people think of these type punnings that fix ubsan warnings?
[14:57:34 CEST] <BBB> (change/cast random variables to unsigned/signed to make behaviour defined)
[14:58:01 CEST] <iive> i think some C behaviour should have been defined decades ago
[14:58:13 CEST] <iive> who wants to make a petition?
[15:05:51 CEST] <DHE> is there interest in frame-based threading for filters? the low hanging fruit (that catches my attention) is the {a,}split filter which is just asking for threads to handle the outputs.
[15:09:12 CEST] <BBB> DHE: I would be interested in that, sure
[15:22:01 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07master:3d8d3729475c: avcodec/y41pdec: Fix width in input buffer size check
[15:22:02 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07master:5871adc90f8c: avcodec/cavs: Check updated MV
[15:22:03 CEST] <cone-366> ffmpeg 03N^ 07master:3d232196372f: avformat/wavdec: Check chunk_size
[15:30:54 CEST] <BtbN> philipl, re cuvidInit: That's the function in their samples which dynloads all the external symbols.
[16:01:50 CEST] <philipl> BtbN: ah.
[16:03:13 CEST] <philipl> BtbN: They seem determined not to respond to the broken b-frames issue
[16:03:24 CEST] <BtbN> yep
[16:10:08 CEST] <philipl> one more try
[16:24:58 CEST] <BtbN> philipl, plain settings -refs 2 does not magically fix it, so lets see which references he means
[17:54:49 CEST] <BtbN> philipl, I don't think he meant more than 1 bframe
[17:54:53 CEST] <BtbN> but more than one reference frame per bframe
[18:43:52 CEST] <BtbN> [ GPU #0 - < GeForce GTX 1050 > has Compute SM 6.1 ]
[18:45:24 CEST] <BtbN> also, https://bpaste.net/show/a1ad5011250a
[18:45:57 CEST] <BtbN> for hevc_cuvid it looks the same
[18:50:43 CEST] <jamrial_> 8k vp9 decoding?
[18:52:12 CEST] <jamrial_> talk about pointless, with av1 around the corner
[18:54:55 CEST] <atomnuker> it will take a lot of sweat and swearing to get a fast enough decoder to do that
[18:55:26 CEST] <atomnuker> (at least the git repo's there so you'll know who to send angry emails when you're pissed)
[18:56:35 CEST] <nevcairiel> jamrial_: also up to 12-bit :D
[18:56:45 CEST] <nevcairiel> it probably didnt cost them much to just extend all decoders to that resolution
[18:56:49 CEST] <jamrial_> now *that* is pointless :p
[18:57:49 CEST] <jamrial_> but yeah, 8k is def not going to be a thing for a while, and av1 will have hardware decoders in most gpu solutions by then
[19:14:12 CEST] <alevinsn> 4k isn't really going to be a thing for a while
[19:14:16 CEST] <alevinsn> even if it is available now
[19:14:35 CEST] <atomnuker> its a thing already
[19:14:39 CEST] <alevinsn> in a sense
[19:14:43 CEST] <alevinsn> but there is almost no content
[19:14:50 CEST] <alevinsn> none of the broadcasters (in the US) are moving to it
[19:14:59 CEST] <alevinsn> very few people seem to care about it
[19:15:13 CEST] <alevinsn> to get the advantages of it, you need a really large television
[19:15:33 CEST] <alevinsn> so, its a thing, but there is pretty much no need for it
[19:15:52 CEST] <atomnuker> who cares about broadcasters, the internet's where its all at
[19:16:14 CEST] <atomnuker> seriously, would you follow a bunch of people who sit around making excuses to keep interlacing in this century?
[19:16:15 CEST] <alevinsn> Netflix has a little 4K content, but not much
[19:16:36 CEST] <alevinsn> I freely admit that I hate interlacingg
[19:16:38 CEST] <alevinsn> interlacing
[19:16:57 CEST] <alevinsn> but, 720p or 1080p is likely sufficient for most people
[19:17:11 CEST] <atomnuker> what, interlaced 1080p?
[19:17:23 CEST] <alevinsn> um, 1080p is progressive
[19:17:25 CEST] <atomnuker> "boss, we're getting complaints about our picture looking like shit!"
[19:17:31 CEST] <atomnuker> "boost the bitrate then."
[19:17:39 CEST] <alevinsn> use a better encoder
[19:17:41 CEST] <atomnuker> "its already 80Mbps"
[19:18:01 CEST] <atomnuker> "what's more can we do then?"
[19:18:12 CEST] <atomnuker> "...don't stream 1080i?"
[19:18:32 CEST] <alevinsn> Almost no one is streaming interlaced video
[19:18:45 CEST] <alevinsn> the reason it still exists is for broadcast television mostly
[19:18:48 CEST] <atomnuker> everyone in broadcast
[19:18:52 CEST] <alevinsn> no
[19:18:54 CEST] <alevinsn> some are 720p
[19:18:56 CEST] <alevinsn> some are 1080i
[19:19:17 CEST] <atomnuker> haven't seen 720p and I know those that do use it aren't taken seriously
[19:20:17 CEST] <Threads> its all that mbaff crap lately
[19:20:31 CEST] <alevinsn> ABC and Fox use 720p
[19:20:37 CEST] <alevinsn> NBC and CBS use 1080i
[19:20:53 CEST] <Threads> all 4 use mpeg2 right ?
[19:21:03 CEST] <alevinsn> for Over the Air, yes
[19:21:08 CEST] <alevinsn> but, a lot of it depends on the encoder
[19:21:09 CEST] <atomnuker> it might be popular in the us but haven't seen it this side of the pond
[19:21:11 CEST] <Threads> living in the past i guess
[19:21:18 CEST] <wm4> for broadcast I have yet to get anything larger than SD...
[19:21:32 CEST] <wm4> not sure if they're even broadcasting anything better
[19:21:42 CEST] <wm4> maybe terrestrial is just shit
[19:21:45 CEST] <alevinsn> At least in the US, it depends on which digital subchannel is being used
[19:21:50 CEST] <Threads> mpeg2 over here is only used for SD content for broadcasting
[19:21:54 CEST] <alevinsn> there is the .1, .2, .3, etc
[19:22:02 CEST] <Threads> h264 is for HD
[19:22:02 CEST] <alevinsn> MPEG2 is used for all over the air content
[19:22:14 CEST] <alevinsn> even HD, I believe
[19:22:16 CEST] <atomnuker> in the us you have haich-dee radio so who knows what else is in that bag of worms
[19:22:54 CEST] <alevinsn> in the us, everything is sent using a mpeg2 transport stream
[19:22:56 CEST] <alevinsn> that's true
[19:23:03 CEST] <Threads> i might have something like 2 or 3 channels which are SD which use h264 but thats about it
[19:23:21 CEST] <alevinsn> and the mpeg2ts usually has multiple programs
[19:23:38 CEST] <alevinsn> possibly 2 HD and 1 to 2 SD
[19:24:06 CEST] <alevinsn> but, as far as I know, they are all encoded using MPEG2
[19:24:14 CEST] <alevinsn> it is possible to use H.264 or even HEVC
[19:24:30 CEST] <alevinsn> but, a lot of equipment doesn't support that yet I think
[19:24:45 CEST] <alevinsn> Also, may not be supported by ATSC 1.0
[19:25:21 CEST] <alevinsn> The quality that is squeezed into those streams has a lot to do with the encoder that is used
[19:25:38 CEST] <atomnuker> nah, mpeg2, its all up to the bitrate used mate
[19:25:58 CEST] <alevinsn> I was at a presentation at NAB that demonstrated how one can get 2 high quality HD programs and 1-2 pretty high quality SD streams in like half the available bandwidth
[19:26:25 CEST] <alevinsn> since stations have lost spectrum due to the channel auction
[19:26:47 CEST] <alevinsn> atomnuker:  I assure you the encoder plays a role
[19:26:59 CEST] <atomnuker> sure, but not as much as in h264
[19:27:01 CEST] <alevinsn> The presentation showed that Thomson, with one of their encoders
[19:27:24 CEST] <alevinsn> was getting high quality SD at .9 Mbps that other manufacturers need 2 Mbps to do
[19:27:28 CEST] <alevinsn> or something like that
[19:27:38 CEST] <atomnuker> why would you look at anything like that? did they have fancy pee-ess-en-arr graphs in linear domain?
[19:28:01 CEST] <alevinsn> are you asking why I would pay attention to such a presentation?
[19:28:10 CEST] <atomnuker> yep
[19:28:44 CEST] <kierank> the thomson encoder isn't bad but it's not magic
[19:28:45 CEST] <alevinsn> I'm self-employed, but I do work for a broadcast television company
[19:29:04 CEST] <alevinsn> and, I happened to sit in on one of the presentations that my colleague gave
[19:29:09 CEST] <alevinsn> he's not selling Thomson
[19:29:15 CEST] <alevinsn> but, because of the reduction in spectrum
[19:29:24 CEST] <atomnuker> kierank: seriously? aren't they hardware based?
[19:29:26 CEST] <alevinsn> and they have some of their own networks
[19:29:43 CEST] <alevinsn> they want various stations to continue to carry these networks
[19:29:43 CEST] <kierank> atomnuker: sure but one of the semi-decent ones
[19:29:46 CEST] <kierank> not as good as ateme
[19:30:11 CEST] <alevinsn> they did a test with Thomson, Harmonics, and I think one other
[19:30:21 CEST] <alevinsn> to see what was possible in 10 Mbps (or maybe it was 9 Mbps, something like that)
[19:30:33 CEST] <alevinsn> or maybe it was 19.3 Mbps, I forget
[19:30:46 CEST] <BtbN> philipl, nevcairiel: https://github.com/BtbN/FFmpeg/commit/be745a75c6c91671b5d7908e8bcd1f36c4de40da if any of you have an idea how that raw yuv processing of cuvid works... I think I have most of the boilerplate done, but it outputs garbage.
[19:30:49 CEST] <alevinsn> and they found that Thomson came out ahead, particularly for SD
[19:31:08 CEST] <alevinsn> and they don't have any Thomson gear other than some stuff for captions I think
[20:00:45 CEST] <cone-366> ffmpeg 03James Almer 07master:f738140807f5: avcodec/hevc_sei: fix amount of bits skipped when reading picture timing SEI message
[20:00:46 CEST] <cone-366> ffmpeg 03James Almer 07master:6655939f03ea: avcodec/hevc_sei: remove bugus debug message
[20:10:32 CEST] <cone-366> ffmpeg 03Paul B Mahol 07master:bd404e3949b0: avfilter/af_afir: workaround nonsense limitation in vector_fmul_scalar()
[20:14:36 CEST] <J_Darnley> How much memory is used for LOCAL_ALIGNED_8(int64_t, temp, [16])?  It is 16 int64_t, right?  So 128 bytes, right?
[20:25:41 CEST] <nevcairiel> plus any overhead from aligned, presumably
[20:25:57 CEST] <nevcairiel> but i would say so, yes
[20:30:28 CEST] <iive> J_Darnley: is this part of a structure?
[20:30:48 CEST] <J_Darnley> no just on the stack
[21:34:27 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07master:6ea428789371: avcodec/dss_sp: Fix runtime error: signed integer overflow: 2147481189 + 4096 cannot be represented in type 'int'
[21:34:28 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07master:a8de60ba2740: avcodec/eatqi: Fix runtime error: signed integer overflow: 4466147 * 1075 cannot be represented in type 'int'
[21:34:29 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07master:db5fae322947: avcodec/truemotion1: Fix multiple runtime error: left shift of negative value -1
[22:16:07 CEST] <cone-366> ffmpeg 03Michael Niedermayer 07master:942036e97c8b: avfilter/vf_uspp: Fix currently unused input frame dimensions
[00:00:00 CEST] --- Thu May 11 2017