Ffmpeg-devel-irc
Threads by month
- ----- 2026 -----
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
May 2017
- 1 participants
- 62 discussions
[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/4… 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/be745a75c6c91671b5d7908e8bcd1f36c4de4… 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
1
0
[03:38:25 CEST] <Rekka> Hi! Is there a way to fix the "chunk too big" error? Here is my ffmpeg command - https://pastebin.com/vUtfaQGL ; I've already read this page - https://superuser.com/questions/1025635/ffmpeg-chunk-too-big - and tried to adjust the png file in GIMP but it still getting the same "chunk too big" error and the time it occurs keeps changing too, hence, the png file also keeps changing.
[03:52:41 CEST] <DHE> Rekka: also include the output
[03:53:09 CEST] <DHE> if it's the same as your superuser.com command, that's an error on the input. ffmpeg doesn't like a PNG part way through the sequence
[03:55:02 CEST] <Rekka> Thank you for the response @DHE. Here's the output - https://pastebin.com/bM4TQpps
[03:55:50 CEST] <Rekka> How should I fix that "ffmpeg doesn't like PNG part way through the sequence"?
[03:57:06 CEST] <cali_> Hi there.
[03:58:55 CEST] <DHE> Rekka: no idea honestly...
[04:06:31 CEST] <c3r1c3-Win> Rekka: Try sorting the directory by size and look at the smallest PNGs for a corrupt one.
[04:31:31 CEST] <tezogmix> How would the string to add look if I want to convert a 4k video file to 1080 while maintaining the aspect ratio? (3840x2160 to 1920x1080) ? The source is 16:9 at 59.940 frame rate.
[04:31:49 CEST] <tezogmix> ffmpeg -r 60000/1001 -i input.mp4 -preset veryfast -crf 20 -r 60000/1001 -c:a copy output.mp4
[04:32:07 CEST] <furq> you don't need to specify the framerate
[04:32:17 CEST] <furq> and add -vf scale=-2:1080
[04:32:18 CEST] <tezogmix> ^ I have this much. I saw in the documentation : "-vf scale=" but not sure if I would make it: "-vf scale=1920:1080" ?
[04:32:53 CEST] <tezogmix> I also saw one part mentioning "force_original_aspect_ratio" - the device limit is 1080. Oh thanks furq for replying....
[04:35:51 CEST] <tezogmix> furq, I read this post on stackexchane: https://video.stackexchange.com/questions/14907/how-to-downsample-4k-to-108… > the user commented "with the entire image being composed of square "tiles" as if I was magnifying 4:1."
[04:36:06 CEST] <tezogmix> In short, they entered: "ffmpeg -i orig.mp4 -vf scale=1920:1080 smaller.mp4"
[04:36:51 CEST] <tezogmix> Another responded that they had missed maybe "-crf XX -preset XXXX"
[04:37:05 CEST] <furq> lol
[04:37:29 CEST] <furq> the second to last comment on the page is the only one who noticed
[04:38:34 CEST] <furq> the guy who posted the question has a build with no libx264, so he encoded 1080p with 1-pass 200kbps mpeg4
[04:38:39 CEST] <furq> so i'm not surprised it looked like garbage
[04:38:54 CEST] <tezogmix> Oh I see. It was a dated article.
[04:39:01 CEST] <tezogmix> and older build...
[04:39:06 CEST] <furq> it's not dated, the guy just had a useless build
[04:39:17 CEST] <furq> some distro builds are like that
[04:39:27 CEST] <furq> if you have libx264 then the defaults will be more or less fine
[04:39:44 CEST] <tezogmix> My last ffmpeg update was from a few days ago.
[04:39:46 CEST] <furq> no harm in using -crf 20 though
[04:39:51 CEST] <tezogmix> for win64
[04:40:02 CEST] <furq> the zeranoe builds have everything you'd want
[04:40:48 CEST] <furq> you might want to use -vf zscale=-2:1080:f=lanczos
[04:40:48 CEST] <tezogmix> I've been playing a little with -18 and -20 for some devices and trying to see how much of a tradeoff there is between fast and veryfat presets, still a bit tough other than the obvious time difference.
[04:41:00 CEST] <furq> that'll be a bit slower but much sharper
[04:41:23 CEST] <furq> the default scale algorithm is bilinear, which is pretty soft
[04:42:26 CEST] <furq> the presets only really matter if you care about filesize
[04:42:40 CEST] <furq> -preset veryfast with a low crf will look as good as -preset veryslow with a higher crf
[04:42:48 CEST] <furq> although the exact values you'd need come down to trial and error
[04:43:39 CEST] <tezogmix> I see and good to know, these [scaling] are definitely new strings for me that you're mentioning. Are those in the official wiki docs?
[04:43:45 CEST] <furq> !filter zscale
[04:43:45 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#zscale
[04:44:01 CEST] <tezogmix> Same with attempting a downscaling of 4k to 1080.
[04:44:04 CEST] <furq> zscale is from an external lib, but the zeranoe builds include it
[04:44:12 CEST] <furq> it's generally recommended over swscale
[04:44:15 CEST] <furq> which is the builtin scaler
[04:44:17 CEST] <tezogmix> hmmm... cool.
[04:49:43 CEST] <tezogmix> I'm generally downloading the non-nightly static 64-bit windows build zip as is from : https://ffmpeg.zeranoe.com/builds/ (just realizing this might be the build you're referring to furq)
[04:50:01 CEST] <kepstin> not that there's anything really wrong with the scale filter for most use. With a 4k1080p downscale, i'd consider using -vf scale=sws_flags=area
[04:50:59 CEST] <tezogmix> so now we have 2 suggestions :)
[04:51:27 CEST] <kepstin> well, scaling algorithms are one of those "to personal taste" kind of things
[04:54:40 CEST] <tezogmix> I can fully respect the subjectivity. My interest I suppose is what kind of output either of those strings would show. The 4k file I have is quite large and I'll try to cut a small 1-2 minute segment "ffmpeg -i input.mp4 -c copy -ss xx:xx:xx -to xx:xx:xx output.mp4" Curious what I should be looking for.
[04:57:15 CEST] <tezogmix> kepstin, does your example string "-vf scale=sws_flags=area" take longer/shorter compared to furq's "-vf zscale=-2:1080:f=lanczos" and with your string, does that portion already assume ffmpeg will convert it to 1920x1080?
[04:58:27 CEST] <kepstin> tezogmix: you still need the other options with the scale filter, so "-vf scale=w=-2:h=1080:sws_flags=area" all together
[04:59:06 CEST] <kepstin> i'd expect area to be rather faster, it's a simple average of pixel values, rather than the more complex lanczos kernel
[04:59:07 CEST] <dystopia_> what does the =area do?
[05:00:11 CEST] <tezogmix> So kepstin, something like this then? "ffmpeg -i input.mp4 -preset veryfast -crf 20 -c:a copy -vf scale=w=-2:h=1080:sws_flags=area output.mp4" Source is 3840x2160, ~8gb
[05:00:32 CEST] <kepstin> tezogmix: sure
[05:01:18 CEST] <tezogmix> I may drop the crf to 18 though like furq was mentioning rather than switching to both a fast/lower crf
[05:01:25 CEST] <dystopia_> -sws_flags spline -s 1920x1080
[05:01:30 CEST] Action: dystopia_ resizes like this
[05:05:28 CEST] <tezogmix> These are all unchartered waters for me :) My main concerns was if the output would be warped to what the source looks like. How does your resize method differ to the other suggestions from both kepstin & furq shared dystopia?
[05:05:48 CEST] <furq> it doesn't
[05:05:59 CEST] <furq> that's the same as -vf scale=1920:1080:sws_flags=spline
[05:06:23 CEST] <kepstin> tezogmix: the ffmpeg scale filters always preserve aspect ratio unless you work hard to convince them to do otherwise, so no squishing
[05:06:32 CEST] <furq> whether spline, lanczos or area is better comes down to preference
[05:06:44 CEST] <furq> and also probably the source
[05:07:07 CEST] <furq> i'd expect area to do well on an exact 2:1 downscale
[05:07:40 CEST] <furq> really the important thing is that you're not using bilinear
[05:07:42 CEST] <kepstin> tezogmix: downscaling frok 4k (3840x2160) to 1080p (1920x1080) is really simple, because it's exactly œ the width and œ the height. Hard to get wrong...
[05:07:50 CEST] <furq> which is the default with swscale
[05:08:00 CEST] <kepstin> furq: the default with swscale is bicubic, not bilinear?
[05:08:03 CEST] <tezogmix> Interesting comments from you all... I'm not sure what I would be visually looking for when it comes down those comparing your preferences....
[05:08:03 CEST] <furq> is it
[05:08:11 CEST] <furq> oh
[05:08:15 CEST] <furq> bilinear is the default with zscale
[05:08:17 CEST] <furq> that's stupid
[05:08:34 CEST] <furq> tezogmix: how sharp the image is
[05:08:54 CEST] <furq> bilinear will give noticeably blurry results compared to lanczos
[05:09:13 CEST] <furq> but you'd need a good eye to notice the difference between spline and lanczos
[05:09:20 CEST] <kepstin> tezogmix: just encode a section of the video (use -ss to pick a good spot, and -t to do like 10s or something), and just check the different options to see what you like
[05:09:24 CEST] <furq> yeah
[05:10:40 CEST] <furq> http://matplotlib.org/mpl_examples/images_contours_and_fields/interpolation…
[05:10:44 CEST] <furq> that's upscaling but you get the idea
[05:12:08 CEST] <tezogmix> Ah I see, well that helps a lot in clarifying to use a visual sharpness as a factor to compare these 3...
[05:12:33 CEST] <tezogmix> at least for one example factor I suppose but this helps!
[05:12:39 CEST] <furq> spline, sinc and lanczos are all very similar
[05:12:54 CEST] <furq> i think swscale's spline is a bit faster
[05:13:14 CEST] <furq> it's not worth worrying too much about this really
[05:13:33 CEST] <furq> unless you pick something really bad then it's the kind of thing you'll only notice if you're looking for it
[05:13:59 CEST] <furq> obviously that doesn't stop people from spending hours writing detailed guides about picking the best scaler for mpv
[05:14:04 CEST] <furq> but those people are already dead
[05:14:07 CEST] <tezogmix> :)
[05:15:59 CEST] <tezogmix> I appreciate the huge tips and links furq, kepstin and dystopia_ - saving these for future reference!
[05:20:00 CEST] Action: james999 sniffs around for some useful links
[05:21:01 CEST] <james999> lol in that matplotlib picture the first two pictures are both labeled None
[05:21:49 CEST] <tezogmix> I can see the lanczos sharpness furq (in comparison to spline) sinc looks interesting
[05:22:49 CEST] <furq> lanczos is a variant of sinc
[05:22:59 CEST] <furq> so those will generally be almost identical
[05:23:11 CEST] <james999> they all 3 look identical to me
[05:23:26 CEST] <furq> spline is slightly more blurry in that image
[05:24:06 CEST] <tezogmix> yes spline36 is from what I'm seeing. sinc I'm doing a few double takes.
[05:24:23 CEST] <tezogmix> but seems just a tad sharper than lanczos
[05:24:31 CEST] <furq> also it's worth pointing out that you might want to use something softer if your source isn't clean
[05:24:49 CEST] <tezogmix> hmmm...
[05:24:49 CEST] <furq> really sharp resamplers will amplify any artifacts in the source
[05:25:03 CEST] <furq> if you have a nice 4k source then it's probably fine
[05:26:53 CEST] <tezogmix> Some nice features I'll need to test out with -ss + -t
[05:53:10 CEST] <Rekka> DHE: I think I solved it by removing -framerate 24 and only keeping -r 24
[06:00:04 CEST] <Rekka> DHE: Or not
[06:00:12 CEST] <Rekka> Now it's out of sync. Damn.
[06:01:50 CEST] <kepstin> Rekka: yes, using the '-r' input option will almost always cause a desync, because it completely ignores video timestamps and makes up new ones
[06:02:18 CEST] <kepstin> er, i just scrolled up to re-read your stuff
[06:02:31 CEST] <kepstin> that's not what happened at all, you're using the -r output option :)
[06:04:19 CEST] <kepstin> Rekka: yeah, you need to keep the -framerate input option (if you don't specify, the default is iirc 25, which likely isn't right).
[06:06:33 CEST] <kepstin> i have no idea how you'd do it, but you need to find which png filein your directory is corrupt and remove/replace it :/
[06:06:50 CEST] <kepstin> it should be fairly close to the frame 61563 where the encoding stopped, tho...
[06:12:56 CEST] <tezogmix> thanks again kepstin, furq & dystopia_ - leaving channel for now, have a good week!
[06:24:37 CEST] <Rekka> kepstin: Thanks for the response. But when I checked the sequence of pictures, they're not corrupt at all which is odd.
[06:25:13 CEST] <Rekka> I'm using waifu2x for it you see. But yeah, might as well re-waifu2x them again
[06:32:18 CEST] <kepstin> hmm. input frames are all the same size, right? how big are the images you're using as ffmpeg input?
[06:32:59 CEST] <kepstin> (and I dunno how well waifu2x would work on video, iirc it doesn't make any attempt to be temporally consistent, so you could get jittery edges and whatnot)
[06:53:13 CEST] <james999> is waifu2x a new kind of algorithm like sinc or lanczos?
[07:04:10 CEST] <thebombzen> james999: waifu2x is a program specifically designed to denoise and scale anime-style lineart
[07:04:34 CEST] <thebombzen> and by "denoise" I mean like removing DCT crud
[07:05:09 CEST] <thebombzen> it's not like lanczos because it's not general purpose. it's actually a machine-learning algorithm with a neural network that was trained on a bunch of data
[07:05:30 CEST] <dystopia_> you mean it watches a lot of anime :O
[07:06:12 CEST] <thebombzen> no, I mean the developers fed lots of image pairs of the form "this is the original, this is the original but with DCT crud"
[07:06:27 CEST] <dystopia_> cool
[07:06:45 CEST] <thebombzen> and via machine learning and training data it's supposed to be able to do the inverse problem of reconstructing the original image from the image with DCT cruid
[07:06:51 CEST] <thebombzen> it's the same thing with scaling
[07:07:06 CEST] <thebombzen> it's supposed to be able to reconstruct the upscaled version
[07:07:42 CEST] <thebombzen> it's better because it can assume that the original image was some sort of anime art and thus, for example, it can assume that the original image can be approximated extremely well by some form of vector graphics
[07:08:21 CEST] <thebombzen> if you try to use it on a photograph it won't work very well
[07:09:12 CEST] <thebombzen> although I have used it to take shitty-facebook-jpeg-photograph-with-black-on-white-fuzzy-text-above and remove the jpeg crud from the caption atop
[08:00:10 CEST] <Pandela> Does anyone know what "xyz12le" stands for?
[08:00:31 CEST] <thebombzen> 12le is probably 12bit little endian
[08:00:40 CEST] <thebombzen> xyz is probably the xyz colorspace, which is probably CIE 1931
[08:01:50 CEST] <Pandela> thebombzen: Oh okay, I would have never figured out the CIE 1931 part. Thanks fam
[08:02:11 CEST] <thebombzen> well CIE 1931 is usually xyY or something
[08:02:19 CEST] <thebombzen> so you should doublecheck rather than take that at face value
[08:04:13 CEST] <james999> oh yeah thanks for that link to the wikipedia on CIE 1931
[08:04:16 CEST] <james999> thebombzen
[08:04:42 CEST] <Pandela> thebombzen: I think you're right either way though haha
[08:05:49 CEST] <Pandela> xyz12le is my favorite by far when it comes to sonification and raw data. i.e pumping rawvideo with an xyz12le colorspace; through audio filters and back into ffmpeg
[08:07:43 CEST] <Pandela> Terrible quality, but heres a sample
[08:07:44 CEST] <Pandela> https://u.nya.is/gaknsm.gif
[08:09:31 CEST] <thebombzen> that doesn't sound like something I would want to use
[08:10:51 CEST] <thebombzen> and james999 I didn't link to wikipedia
[08:12:05 CEST] <james999> well perhaps not, but I did check it out anyway
[08:13:04 CEST] <james999> not a lot of books on codecs though. i did find one on SO recommended but it was a hundred bucks (!)
[08:14:17 CEST] <thebombzen> why would you want a book on codecs
[08:14:28 CEST] <thebombzen> it seems easier to just learn info on codecs in realtime
[08:14:40 CEST] <thebombzen> as in "this is the problem I want to solve, ask in #ffmpeg which codec"
[08:14:47 CEST] <thebombzen> eventually you'll learn the stuff you need
[08:14:55 CEST] <james999> sure, just thought i'd google first
[08:15:40 CEST] <james999> i'm kind of in an awkward position of getting ready to reformat my machine
[08:15:49 CEST] <james999> so i don't want to dl anymore code atm
[08:16:35 CEST] <thebombzen> "I don't want to download anymore code" seems to contradict "I'm about to wipe everything"
[08:16:44 CEST] <thebombzen> you shouldn't care about DLing more code if it's just going to disappear lol
[08:16:58 CEST] <furq> i would care about things that were going to disappear
[08:17:28 CEST] <james999> lol well i need more space and some of my stuff is corrupted i think from swapping video cards or something
[08:17:59 CEST] <james999> also i forgot password to my linux partition. T_T
[08:18:21 CEST] <Pandela> rip
[08:18:57 CEST] <Pandela> Soundsl like me, only I corrupt my shit on purpose lol
[08:19:58 CEST] <james999> Pandela: like installing from non-official repos on debian or ubuntu? i've done that
[08:20:20 CEST] <james999> The response of people in #debian was that it produces "frankendebian" - no support given!
[08:20:53 CEST] <james999> or rather, i think i was mixing packages from jesse and wheezy which is even worse
[08:21:09 CEST] <Pandela> james999: Ye, that and just running my files through a hex editor or decoding video files with incorrect codecs
[08:21:19 CEST] <thebombzen> you should just use arch
[08:21:27 CEST] <thebombzen> then you won't be surprised when shit gets corrupted
[08:21:55 CEST] <james999> hah. arch sounds scary. their wiki is so clearly and lucidly written step by step, i imagine the ways you can foobar your system must be uncountable
[08:24:12 CEST] <james999> at least my frankendebian was predictably screwed up
[08:24:41 CEST] <james999> i couldn't update packages because version mismatches everywhere after installing packages from the next version
[08:30:28 CEST] <furq> yeah don't do that
[08:30:54 CEST] <furq> just run the right version of debian to begin with
[08:31:44 CEST] <james999> well sometimes you don't know what you're doing
[08:31:59 CEST] <james999> and nobody's around. and you have some forum or website with a quick solution
[08:32:12 CEST] <james999> and then you foobar your system. %_%
[08:32:21 CEST] <furq> i hope you've learned your lesson
[08:32:23 CEST] <furq> never read forums
[08:32:54 CEST] <james999> out of date ones at least for sure
[08:33:34 CEST] <james999> and blindly copy and pasting code in general.
[10:07:34 CEST] <SouLShocK> What's considered the best all round algorithm for downscaling 1080p to 720p? Is there even one considered best all round?
[10:07:42 CEST] <furq> no
[10:08:27 CEST] <furq> it depends on the source, how you want the output to look, how long you're happy for it to take, etc
[10:09:04 CEST] <furq> if you've got a good source, want it to look sharp and not take too long (which is pretty ordinary) then lanczos is very popular
[10:13:38 CEST] <SouLShocK> Those criteria fit my use case pretty well. Thanks
[10:25:25 CEST] <k_sze[work]> Does anybody know if it's possible to compile ffmpeg with OpenMAX IL support on Jetson TK1?
[11:08:04 CEST] <JC_Yang> how to properly cleanup stuff when using custom aviocontext? huge amount of leaks here.
[12:28:42 CEST] <Pandela> Incorrectly decode my raw video data, S-senpai~
[12:40:41 CEST] <thebombzen> is there a way to get -vf unsharp or -vf smartblur to not change the gamma of the image?
[12:41:08 CEST] <thebombzen> I have an image which is basically blurred-black-text-on-a-white-background, and using either sharpening filter turns the background to gray
[12:43:48 CEST] <thebombzen> hm, it appears to be a bug where it doesn't intepret partial range YUV correctly
[12:44:11 CEST] <thebombzen> it works fine if you use -vf format=yuvj444p,unsharp
[12:46:00 CEST] <thebombzen> but smarblur doesn't accept yuvj444p and it'll autoinsert a format=yuv444p if you try
[13:19:41 CEST] <Mandevil> How can I tell from ffprobe output whether a clip is interlaced?
[13:19:50 CEST] <Mandevil> It doesn't seem to say.
[13:23:19 CEST] <thebombzen> things can be interlaced on a frame-by-frame basis
[13:25:11 CEST] <thebombzen> Mandevil: you can check out -vf idet
[13:25:55 CEST] <Mandevil> Let me see.
[13:27:36 CEST] <thebombzen> in particular you might care about analyze_interlaced_flag
[13:27:54 CEST] <Mandevil> I have no idea how ffprobe works to be honest.
[13:28:22 CEST] <Mandevil> I just have 1300+ clips and I need to sort progressive/interlaced apart.
[13:36:42 CEST] <Mandevil> How do I use -vf idet with ffprobe? "-vf idet" is not accepted.
[13:40:35 CEST] <furq> you don't
[13:40:37 CEST] <furq> you use it with ffmpeg
[13:44:21 CEST] <furq> http://vpaste.net/9zESv
[13:48:41 CEST] <Mandevil> furq: Hm, I was expecting some nice output like ffprobe does.
[13:50:20 CEST] <furq> ffprobe and mediainfo will only tell you if it's flagged as interlaced
[13:50:23 CEST] <furq> which is often inaccurate
[13:50:26 CEST] <Mandevil> I see.
[13:50:43 CEST] <furq> idet actually analyses the video, which is why it takes ages
[13:50:43 CEST] <Mandevil> Any idea how quickly automate the above task?
[13:50:56 CEST] <Mandevil> Short of writing actual script that will parse the output etc.?
[13:51:21 CEST] <furq> not without writing a script
[13:51:42 CEST] <Mandevil> Well, let's go write it.
[13:53:43 CEST] <Mandevil> Single frame detection: TFF: 6 BFF: 5 Progressive: 360
[13:53:45 CEST] <Mandevil> Wut?
[13:53:54 CEST] <Mandevil> There are tff/bff frames in progressive video?
[14:01:41 CEST] <furq> false positive
[14:08:12 CEST] <Mandevil> Problem is that this is extremely slow.
[14:08:19 CEST] <Mandevil> 1300 files will take a day.
[14:08:32 CEST] <furq> you can add -t 60 to only analyse the first minute
[14:08:44 CEST] <Mandevil> It's slow even on quite short files.
[14:08:52 CEST] <Mandevil> Most of the clips are sub-1 minute anyway.
[14:08:58 CEST] <furq> i'm not aware of anything more accurate really
[14:09:02 CEST] <Mandevil> Hm.
[14:09:10 CEST] <furq> or faster, rather
[14:09:38 CEST] <Mandevil> How does a player immediately know how to handle the video?
[14:09:45 CEST] <Mandevil> Or it doesn't?
[14:09:48 CEST] <furq> most players don't
[14:09:52 CEST] <Mandevil> True.
[14:09:55 CEST] <furq> players which autodetect are doing something like idet
[14:10:11 CEST] <furq> or just relying on flags
[14:10:16 CEST] <Mandevil> God damn. To hell with interlaced media.
[14:49:18 CEST] <termos> is there a best practice way to handle AVPacket's moving though a series of AVThreadMessageQueue's? not sure when I should do av_packet_unref or if av_write_frame_interleaved does this for me? it seems to, but I'm having some memory leaks
[15:00:12 CEST] <DHE> termos: av_interleaved_write_frame says "Libavformat will always take care of freeing the packet, even if this function fails."
[15:00:29 CEST] <DHE> you might need to run under valgrind or something more invasive if you're not able to track it down
[15:00:39 CEST] <termos> interesting thanks
[15:01:15 CEST] <termos> yes looking into using valgrind, but it seems to have issues with macOS 10.12 ugh :)
[15:24:36 CEST] <Pandela> Interperet my raw audio as raw video data O-Oneesan~
[15:25:56 CEST] <Pandela> https://my.mixtape.moe/xfnokr.mp3
[15:28:37 CEST] <zerodefect> Quite new to using the ffmpeg api/sdk. Having issues with understanding how to select pixel formats during media decode from file. The media I have is DV video.
[15:29:56 CEST] <zerodefect> When I call 'avcodec_find_decoder', all is well. Except the pix_fmt pointer within the structure is NULL
[15:30:34 CEST] <zerodefect> ...as it says in the documentation. I'm sort of struggling where I set the pix fmt and how I determine if the format is supported?
[15:31:07 CEST] <zerodefect> Currently, I'm receiving AV_PIX_FMT_YUV422P, but I would prefer AV_PIX_FMT_YUYV422 (packed)
[15:31:45 CEST] <zerodefect> When I'm receiving, I should elaborate and indicate that I'm able to decode :)
[15:32:24 CEST] <pump> ihave a problem adding an external libx265 library because i have changed it. and now it has opencv as dependency. i have solved the dependency problem by changing x265 source cmakelists.txt. it run perfect but when i add it ffmpeg gives the same linking error. can i change configure file in ffmpeg to add dependency library on it?
[15:53:45 CEST] <zerodefect> Actually, it has me thinking. Do I need to perform a format conversion?
[16:27:29 CEST] <phishy> Curious, is there a preferred distro for fastest performance?
[16:38:59 CEST] <furq> not really
[16:39:12 CEST] <furq> certainly not for ffmpeg
[16:40:02 CEST] <kepstin> phishy: most of the performance sensitive stuff in ffmpeg and codecs is assembly code selected based on cpu support, so as long as the distro didn't break it by e.g. disabling assembly, it should be more or less the same.
[16:40:10 CEST] <phishy> I've also noticed that doing encodes on DigitalOcean SSD with a bunch of cores versus a high-powered Mac, the Mac wins out.
[16:41:59 CEST] <BtbN> Why would SSDs matter?
[16:42:02 CEST] <BtbN> encoding is CPU bound
[16:42:48 CEST] <phishy> I figured faster disks meant faster input? But yeah, overall is seems like bare-metal is faster than cloud-compute in general.
[16:42:55 CEST] <furq> i'm not surprised that an actual cpu is better than a virtual cpu
[16:43:41 CEST] <phishy> Yeah, makes sense
[16:43:58 CEST] <furq> but yeah ffmpeg does runtime cpu feature detection
[16:44:05 CEST] <furq> as does x264 and probably a bunch of other codecs
[16:44:14 CEST] <furq> so as long as you don't disable asm then it doesn't matter how you compile it
[16:44:32 CEST] <phishy> I did notice that it tried to use the 8 cores, even though top never really showed anything above 320%
[16:44:37 CEST] <furq> it also generally matters less if you're on amd64 since that guarantees at least sse2
[16:45:09 CEST] <furq> distros which still compile for i386 will have a lot of stuff which is noticeably slower than manually compiled stuff
[16:45:28 CEST] <furq> but that's not really the case with amd64 unless it's one of the rare things which benefits a lot from sse4/avx/whatever
[16:46:26 CEST] <furq> i'm sure a gentoo user will be along shortly to tell me all about their USE flags
[16:47:41 CEST] <kepstin> phishy: for DO in particular, I think you're not guaranteed full use of the cpu cores, see if your top program shows 'steal time', which is how most of the cpu you're not being allowed to use.
[16:48:01 CEST] <kepstin> (that's true of many virtual environments)
[16:48:51 CEST] <furq> digitalocean is all kvm so it should be less susceptible to oversubscription than other virtual servers
[16:49:00 CEST] <phishy> Yeah I had read some posts about arch and gentoo and people getting all excited about that. I'm also using a static build, and I was trying to run some tests to see of compiled vs static showed any noticeable difference.
[16:49:03 CEST] <furq> i still wouldn't expect to get the full performance advertised in /proc/cpuinfo though
[16:49:40 CEST] <furq> but yeah if you want 100% ricer speed then you need to use gentoo with everything compiled and optimised especially for your cpu
[16:50:07 CEST] <furq> but that rarely makes a noticeable difference, and it's a huge inconvenience compared to using binary packages
[16:50:41 CEST] <furq> it was more important back when distros were building binary packages for 386, but it's not worth it at all any more
[16:50:58 CEST] <furq> plus most "i386" distros aren't any more
[16:51:09 CEST] <furq> most of them are i686 now
[17:03:33 CEST] <kepstin> which really makes it tricky to run modern linux on my old K6 box, but that's another issue ;)
[17:05:07 CEST] <furq> iirc debian still runs on 486
[17:06:09 CEST] <furq> at least until stretch is released
[17:06:20 CEST] <furq> the K6 is still supported by jessie
[17:40:13 CEST] <celyr> furq, are you sure ? I've red that 3. kernels dropped the support to 486 or something ? Not really sure tho
[17:48:35 CEST] <priyo> hi
[17:49:46 CEST] <furq> celyr: the k6 is 586
[17:49:58 CEST] <furq> https://lists.debian.org/debian-devel-announce/2016/05/msg00001.html
[17:52:33 CEST] <priyo> I am trying to build ffmpeg 3.3 for ndk r14b but getting the following error https://pastebin.com/WVQ3yV7f
[20:18:50 CEST] <thebombzen> Pandela: you'd have the best lucky using grayscale probably
[20:19:05 CEST] <thebombzen> try intepreting pcm_s16le as gray16le
[20:19:44 CEST] <thebombzen> or even better pcm_u16le as gray16le
[20:19:48 CEST] <thebombzen> that might actually make sense
[20:32:05 CEST] <thebombzen> Pandela: this one is actually really interesting (careful, turn volume down, it maxes and clips)
[20:32:15 CEST] <thebombzen> ffmpeg -f lavfi -i testsrc,format=gbrp16le -f rawvideo - | ffplay -f u16le -ar 48000 -ac 1 -i -
[20:36:17 CEST] <Pandela> thebombzen: Ayy thats pretty rad mate. My ffmpeg doesnt let me use gbrp16le as an output pixel format though, so In used gbrp14le
[20:36:25 CEST] <Pandela> *I used
[20:36:34 CEST] <thebombzen> sounds like you should update your ffmpeg
[20:37:55 CEST] <Pandela> Apperantly :0 should probably compile from sauce instead of an apt install
[20:40:07 CEST] <thebombzen> apt? what are you on?
[20:40:49 CEST] <Pandela> Ubuntu currently
[20:41:10 CEST] <thebombzen> I figured that part out
[20:41:26 CEST] <thebombzen> I meant which version
[20:42:40 CEST] <Pandela> oh lol
[20:42:41 CEST] <Pandela> Ubuntu 16.04 LTS
[20:49:09 CEST] <Pandela> thebombzen: ffmpeg -f lavfi -i testsrc,format=pal8 -s 1280x725 -f rawvideo - | ffplay -f u8 -ar 48000 -ac 1 -i -
[20:49:28 CEST] <thebombzen> how are you generating pal8 without palettegen or paletteuse
[20:51:02 CEST] <Pandela> *shrugs* Im just using a pixel format filter. Is that normal behavior for ffmpeg?
[20:51:19 CEST] <thebombzen> I was under the impression that you couldn't without palettegen/paletteuse
[20:52:27 CEST] <Pandela> Ah okay, idunno lol. But You can use it with -pix_fmt too
[20:54:14 CEST] <Pandela> Or you could use multiple formats
[20:54:17 CEST] <Pandela> ffmpeg -f lavfi -i testsrc,format=monow -s 1280x725 -f rawvideo -pix_fmt pal8 - | ffplay -f u8 -ar 48000 -ac 1 -i -
[21:00:57 CEST] <Pandela> Welp, off to work. Squadilah!!
[21:03:46 CEST] <tmatth> this may be a tall order, but I'm having to add an anullsrc and colorsrc to my filter_complex to be able to overlay 2 videos where the 1st is shorter, otherwise both freeze when the shorter clip ends
[21:04:02 CEST] <tmatth> for reference: http://people.videolan.org/~tmatth/nonfreezing-mux/mux.sh
[21:04:18 CEST] <tmatth> and http://people.videolan.org/~tmatth/nonfreezing-mux/mux_test.txt
[21:05:01 CEST] <tmatth> normally I'd use hstack but I need to support arbitrary dimensions (e.g., Picture-in-Picture)
[22:21:07 CEST] <durandal_1707> set repeatlast to 0
[22:24:04 CEST] <Tatsh> encoding a DVD with nnedi, wondering if it's a waste
[22:24:11 CEST] <Tatsh> DVD to h264
[22:24:20 CEST] <Tatsh> waste, compared to yadif
[22:26:50 CEST] <TheWild> hello
[22:27:13 CEST] <TheWild> ffmpeg -i filename.ext -vn -acodec copy filename.???
[22:27:37 CEST] <TheWild> yeah, right. I don't know the output extension. How I can list all the formats I can convert input file to?
[22:27:42 CEST] <Tatsh> we don't know what the original file has
[22:27:48 CEST] <Tatsh> ffmpeg -i filename.ext and get the audio codec
[22:29:01 CEST] <TheWild> ah, right! It's there: Stream #0:0(eng): Audio: opus, 48000 Hz, stereo, fltp (default)
[22:29:07 CEST] <TheWild> thanks for help.
[22:29:30 CEST] <Tatsh> if it's that then you want the matroska container right?
[22:29:45 CEST] <kepstin> tmatth: I've actually just hit a hanging bug with complex filters and overlays - what ffmpeg version are you using? can you try 3.2.x and see if it works there?
[22:30:01 CEST] <kepstin> tmatth: might be unrelated tho :)
[22:30:01 CEST] <TheWild> this time is easy, just output is filename.opus, but what if it is something I don't know extension for?
[22:30:27 CEST] <tmatth> durandal_1707: eof_pass already sets repeatlast to 0 (in vf_overlay.c)
[22:30:31 CEST] <Tatsh> there's no such thing as the exact extension for any particular codec; sometimes people use .mpeg instead of .mpg
[22:30:33 CEST] <Tatsh> and etc
[22:30:41 CEST] <Tatsh> the main thing is getting the container (if required) correct
[22:30:50 CEST] <Tatsh> the extension you set can control for that
[22:30:58 CEST] <tmatth> kepstin: i'll try with latest git, i've mostly tested 3.1.1
[22:31:05 CEST] <kepstin> TheWild: well, most codecs can be put into multiple different formats, e.g. there's no problem making a matroska (mkv) file containing opus audio only
[22:31:18 CEST] <kepstin> tmatth: ah, yeah, unrelated to my issue then :/
[22:32:05 CEST] <Tatsh> TheWild, i suggest looking on wikipedia for 'common extensions'
[22:32:14 CEST] <Tatsh> ffmpeg will more than likely support at least one of them correctly
[22:33:05 CEST] <Tatsh> also
[22:33:09 CEST] <Tatsh> ffmpeg -h muxer=<name of muxer>
[22:33:14 CEST] <Tatsh> you can use ffmpeg -muxers to get the list
[22:33:42 CEST] <Tatsh> once you do, ffmpeg -h muxer=matroska for exampl,e you get the 'Common extensions:' line
[22:34:06 CEST] <Tatsh> ffmpeg -h muxer=matroska 2>&1 | fgrep 'Common extensions'
[22:34:20 CEST] <TheWild> ffmpeg -muxers - Unrecognized option 'muxers'
[22:34:26 CEST] <TheWild> well, I might have old version.
[22:34:29 CEST] <Tatsh> you need a newer ffmpeg then
[22:34:46 CEST] <TheWild> time to update
[22:36:10 CEST] <TheWild> awesome thing
[22:36:21 CEST] <TheWild> Thank you very much Tatsh and kepstin
[22:38:56 CEST] <raboof> hi! I'm using ffmpeg on Debian and I'd like to cut a selection of a vp9 webm video
[22:39:26 CEST] <raboof> the command I'm using is 'ffmpeg -noaccurate_seek -ss 00:11:34 -t 00:19:22 -i 14_59_26.ts.webm -vcodec copy -acodec copy command_line_tools_python_mixed.mp4' and the output http://paste.debian.net/931884/ - notably 'Could not find tag for codec vp9 in stream #0, codec not currently supported in container'
[22:40:07 CEST] <raboof> the output does suggest ffmpeg was built with --enable-libvpx - what could be wrong?
[22:40:30 CEST] <kepstin> raboof: change the output filename to end in .webm instead of .mp4
[22:41:09 CEST] <raboof> lol thanks.. that was it!
[22:45:38 CEST] <TheWild> ffmpeg -i input.webm -vn -acodec output1.ogg & ffmpeg -i input.webm -vn -acodec output2.ogg
[22:45:52 CEST] <james999> fucking hell, so you can type bold and italics on irc?
[22:46:01 CEST] <james999> *what* the heck lol how do you do that
[22:46:31 CEST] <TheWild> between output1.ogg and output2.ogg there are countless differences. Why is that?
[22:46:44 CEST] <TheWild> timestamps?
[22:47:17 CEST] <raboof> james999: terminal escape sequences I presume?
[22:48:14 CEST] <TheWild> james999: https://github.com/myano/jenni/wiki/IRC-String-Formatting
[22:49:03 CEST] <raboof> oh neat
[22:50:25 CEST] <james999> I'm on mirc on windows atm though, so i don't see how to enter \x02 or whatnot
[22:50:44 CEST] <james999> maybe in a script or something. some guy just typed a single word in italics though in a sentence
[22:51:29 CEST] <james999> ^C0,3 is also looks like bash code
[22:52:49 CEST] <drv> fortune favors the bold
[22:54:13 CEST] <james999> wierd, when i hold ctrl-k a little menu pops up
[22:54:42 CEST] <james999> but it doesn't work
[22:55:22 CEST] <james999> wtf is wrong with my client!!
[22:56:07 CEST] <james999> oh i get it now
[22:56:24 CEST] <james999> but still no italics
[22:56:35 CEST] <james999> still no italics and stuff
[22:56:53 CEST] <james999> now I have italics and stuff.
[22:57:03 CEST] <james999> looks like you were right drv!
[22:58:04 CEST] <TheWild> test
[22:59:02 CEST] <TheWild> back to my question, why my files differ?
[23:14:20 CEST] <kepstin> TheWild: when writing ogg files, the muxer choses random stream ids which are different each time it runs
[23:14:33 CEST] <kepstin> this is as recommended by the ogg specs, and helps with stuff like file concatenation
[23:16:17 CEST] <kepstin> if for some reason you need files to be the same every time, you can use "-fflags +bitexact" - but don't do that for regular encodes, the defaults are better.
[23:18:21 CEST] <excalith> hello, i have been looking for a solution about boosting quality while using ffmpeg with vidstab. i used to use profile:v high but cant make it work with vidstab. any ideas?
[23:21:33 CEST] <DHE> You can also try using -preset:v slow (or slower maybe?) for libx264 with the obvious downsides
[23:22:36 CEST] <excalith> will try now thanks, but to be sure why would profile:v wont work anymore with vidstab?
[23:24:02 CEST] <excalith> it still looks like 480p
[23:24:09 CEST] <excalith> on 4k monitor lol
[23:24:23 CEST] <DHE> with 4k source footage?
[23:25:09 CEST] <excalith> nah, just to explain how it looks actually it is a web export
[23:29:31 CEST] <TheWild> got it. Thanks kepstin.
[23:31:27 CEST] <Tatsh> is npp a hardware specific thing or is my gentoo built copy of ffmpeg not building it in?
[23:31:32 CEST] <Tatsh> is it something in ./configure?
[23:39:54 CEST] <excalith> guys anybody managed to work ffmpeg with vidstab? we can't manage to do it. we have learned that older ffmpeg versions were buggy with vidstab, which version is stable? cant find anything on web related to his
[23:47:19 CEST] <Tatsh> doing ivtc with crop,fieldmatch,nnedi,decimate,fps=24000/1001 and only getting 28.2% speed
[23:47:24 CEST] <Tatsh> on a 480p input :/
[23:47:31 CEST] <Tatsh> 480 mixed i should say
[23:52:52 CEST] <cryptodechange> How do I do cropdetect without any rounding? (again)
[00:00:00 CEST] --- Thu May 11 2017
1
0
[00:03:13 CEST] <cone-846> ffmpeg 03Aaron Levinson 07master:7f7ee86d5a49: avdevice/decklink: fix MSVC build issues
[00:52:17 CEST] <jkqxz> alevinsn: Yes.
[00:53:35 CEST] <jkqxz> Do you prefer them in merge form or not? I wasn't clear about the answer to that. (And I don't mind at all.)
[00:54:25 CEST] <jkqxz> Or should I just apply tghem directly because we've wasted enough time back and forth on this...
[00:56:25 CEST] <jkqxz> Also, github links are kindof weird in commit messages. There is an ffmpeg git server, and all decent client things (including gitweb) will expand hashes to links anyway.
[01:20:58 CEST] <jkqxz> Also your emails have the header twice, which does the wrong thing when applied by git (puts some of the header inside the commit messages). If you send patches inline, don't include the header again. (Or use git send-email, which does the Right Thing.)
[01:29:47 CEST] <cone-846> ffmpeg 03Michael Niedermayer 07master:d3088e0fd874: avcodec/g723_1dec: Fix several integer related cases of undefined behaviour
[01:29:48 CEST] <cone-846> ffmpeg 03Michael Niedermayer 07master:548459080b1b: avcodec/fic: Check coefficients
[01:29:49 CEST] <cone-846> ffmpeg 03Michael Niedermayer 07master:159fb8ff7e40: avcodec/indeo2: Check for invalid VLCs
[01:29:50 CEST] <cone-846> ffmpeg 03Michael Niedermayer 07master:28230a690e73: avcodec/clearvideo: Fix runtime error: signed integer overflow: 181 * 18050756 cannot be represented in type 'int'
[01:32:56 CEST] <nevcairiel> why are hevc profiles so annoying in the bitstream
[01:33:31 CEST] <nevcairiel> couldnt they just have added a proper profile enum somewhere like h264 had .. no, everything beyond the basics is grouped into "rext" and you can manually figure out wtf is in the stream
[01:34:37 CEST] <nevcairiel> so if I want to know if a file is Main12 conformant, i get to read all sorts of shit
[01:38:26 CEST] <nevcairiel> (for extra fun, the values you are looking for are at the very end of the SPS)
[01:38:51 CEST] <jkqxz> It's not too bad. You just need the lookup table for the 8 flags -> actual profile. (Table A-2.)
[01:39:22 CEST] <nevcairiel> the really annoying part is that its hidden literally at the end of the sps
[01:39:25 CEST] <nevcairiel> its like, the last element
[01:39:34 CEST] <nevcairiel> so much crappy parsing code
[01:39:39 CEST] <nevcairiel> just to skip to there
[01:40:56 CEST] <jkqxz> Er, no? Those are in PTL. The flags at the end are other crazy stuff for the actual coding layer.
[01:42:00 CEST] <jkqxz> (And they are deliberately fixed-offset so you don't have to parse them properly...)
[01:43:02 CEST] <nevcairiel> the spec isnt exactly straight forward, but it does list table A.1 first with those crazy flags and their restrictions in w hat profiles
[01:43:59 CEST] <jkqxz> Those are additional restrictions rather than defining the profile, though.
[01:47:07 CEST] <jkqxz> If you aren't actually decoding, all reading them will do is allow you to do is possibly conclude that the stream is technically invalid. How useful.
[01:48:32 CEST] <nevcairiel> i wonder if such a profile translation might be nice to have in the lavc decoder, instead of calling everything rext
[01:49:52 CEST] <jkqxz> Like how the constraint flags are applied on top of profile_idc for H.264 in lavc? Yeah, that could be neat.
[01:55:40 CEST] <jamrial> isn't "rext" the name for a group of like 20+ profiles?
[01:55:57 CEST] <jamrial> libavcodec should probably report things like Main 12 instead of just "rext"
[01:56:13 CEST] <nevcairiel> yeah but figuring out the actual profile is a bit of work
[01:56:19 CEST] <nevcairiel> its not just a number in the bitstream
[02:00:02 CEST] <jkqxz> "general_profile_idc = get_bits(5); skip_bits(36); actual_profile = get_bits(8) << 5 | general_profile_idc;" Done :P
[02:00:19 CEST] <nevcairiel> well thats some random number i guess =p
[02:00:31 CEST] <jkqxz> Just like H.264!
[02:00:40 CEST] <nevcairiel> although one of those numbers is variable
[02:00:45 CEST] <nevcairiel> should probably exclude it
[02:01:02 CEST] <nevcairiel> lower_bit_rate_constraint can be 0/1 for many profiles
[02:01:12 CEST] <jkqxz> Hence reading 8 bits, not 9.
[02:01:17 CEST] <nevcairiel> ah right
[02:02:29 CEST] <jamrial> trying any of the rext samples in hevc-conformance is an av_log fest of "unimplemented" and "not tested" warnings
[02:02:36 CEST] <nevcairiel> hehe
[02:02:50 CEST] <nevcairiel> well a simple main12 file should work fine
[02:03:20 CEST] <jamrial> it's curious how little development hevc has gotten since the last big openhevc contribution
[02:07:58 CEST] <nevcairiel> the openhevc thing mostly died as well, they had some hacky random branches with stupid features but nothing really happened
[02:10:41 CEST] <jamrial> yeah, kinda sucks :/
[02:12:03 CEST] <jamrial> although the general opinion i've seen a lot online is "lol software hevc"
[02:12:36 CEST] <nevcairiel> its kinda true
[02:12:50 CEST] <jamrial> with that argument nobody would have bothered with h264 back when even a 720p anime rip would bring any cpu to its knees
[02:12:54 CEST] <nevcairiel> real-time decoding of a 4k main10 stream requires a r ather high-end system
[02:13:16 CEST] <nevcairiel> and at this point, the majority of the speed is stuck in cabac
[02:25:31 CEST] <kierank> hopefully more people use high 422 hevc to troll hardware decoders
[03:43:48 CEST] <cone-846> ffmpeg 03Aaron Levinson 07master:dd8319767e16: qsvenc: Use MFXVideoENCODE_Query() to update the parameters
[03:43:49 CEST] <cone-846> ffmpeg 03Aaron Levinson 07master:ae5b67ee64be: qsvenc: Make sure the interlaced encoding works
[03:43:50 CEST] <cone-846> ffmpeg 03Aaron Levinson 07master:164e27732614: configure: Added require alternative for libmfx to support alternate installation options
[04:47:34 CEST] <philipl> BtbN: Do you understand what cuvidInit is for?
[04:48:39 CEST] <philipl> BtbN: changes look fine and work fine (and no 10bit vp9 for me). The capability check is undermined by the fact that we don't actually know the bit-depth at the time we run the check. It's only known reliably after the parser has done its work.
[06:25:46 CEST] <alevinsn> jkqxz: sorry, I've been away
[06:26:06 CEST] <alevinsn> jkqxz: and just got back--I'd say apply directly, since it isn't really being done as a merge
[06:26:25 CEST] <alevinsn> jkqxz: thanks for letting me know about hashes and also the header business--I didn't know that
[06:27:12 CEST] <alevinsn> oops, looks like michaelni already applied those patches :-)
[08:31:18 CEST] <wm4> WTF
[08:31:44 CEST] <wm4> do I see an nvidia employee posting a patch adding new decls to our "free'd" compat nvenc header?
[08:32:03 CEST] <wm4> actually scratch that
[08:32:13 CEST] <wm4> the header was by nvidia and free-enough in the first place
[08:32:36 CEST] <wm4> probably confused it with the cuda/cuvid stuff
[09:41:00 CEST] <jkqxz> alevinsn: Er, right. Not sure why he would do that, but whatever, doesn't really matter.
[10:18:59 CEST] Action: ubitux confused at the io layers in ffmpeg
[10:46:10 CEST] <BtbN> philipl, that's why I probe and store all 3 of them.
[11:45:51 CEST] <michaelni> jkqxz, dont you think patches which were posted to the ML repeatly and said that they where reveiwed already, should be applied?
[11:47:57 CEST] <jkqxz> Not when they are still being discussed.
[11:48:51 CEST] <jkqxz> Though it was only quibbling over the commit message content. The code is right so it doesn't really matter.
[11:48:53 CEST] <michaelni> i dont remember seeing a discussion
[11:49:30 CEST] <michaelni> greping for qsv i see nothing exept the patches since 3 weeks or so
[11:49:33 CEST] <jkqxz> See above.
[11:49:43 CEST] <michaelni> ahh ok
[11:50:11 CEST] <michaelni> sorry, i did not realize that the commit message was not as intended
[12:00:20 CEST] <BtbN> hm, how do I deprecated a parameter if its value is unchanged, only a new name for it?
[12:19:05 CEST] <nevcairiel> just support both forever
[12:19:05 CEST] <nevcairiel> :D
[12:19:30 CEST] <BtbN> that wouldn't be too terribly hard, as they just renamed them in the API as well
[12:19:35 CEST] <nevcairiel> or move the deprecated ones to a new value, warn on use, and then map to the old value
[12:19:51 CEST] <BtbN> The parameter is straight up using the values from nvEncodeApi.h
[12:19:53 CEST] <nevcairiel> if you really want to get rid of them
[12:19:57 CEST] <BtbN> and they just added defines for the old names
[12:20:01 CEST] <BtbN> so they have the exact same value
[12:20:32 CEST] <BtbN> One of the rc modes was deprecated without a replacement though
[12:20:36 CEST] <BtbN> no idea what to do with that
[12:20:40 CEST] <nevcairiel> that doesnt prevent you from inventing some fake value
[12:21:20 CEST] <BtbN> could just invent some IS_DEPRECATED flag and | them
[12:21:34 CEST] <nevcairiel> something like that, and strip that on use
[12:21:54 CEST] <nevcairiel> was the min-qp mode any useful? sounds like something low quality
[12:22:07 CEST] <BtbN> no idea, I never used it
[12:22:15 CEST] <BtbN> I'll just keep it around as long as the header offers it
[12:35:16 CEST] <durandal_1707> anybody please comment SIMD for afir filter
[12:46:43 CEST] <BtbN> Does anyone have a 12 bit sample of hevc or something cuvid supports?
[13:15:49 CEST] <nevcairiel> BtbN: https://www.dropbox.com/sh/wtmcgd5xzhwbp9r/AABALMuNausQng7T6LSqHhGHa?dl=0 the 420 12-bit works with cuvid
[14:13:37 CEST] <BtbN> philipl, I think I'm done with the SDK Update now.
[14:45:37 CEST] <j-b> so pushing again things to support without pkg-config?
[14:46:17 CEST] <j-b> even on Windows, pkg-config exists...
[14:48:30 CEST] <cone-714> ffmpeg 03Mark Thompson 07release/3.2:016064625fd5: hwcontext_vdpau: Fix missing subscripts
[14:48:52 CEST] <j-b> BtbN: did you retest the git speed?
[14:49:13 CEST] <BtbN> didn't have anything to push yet, will have soon though
[14:50:37 CEST] <j-b> BtbN: we have had a few 600Mbps requests on another server this morning
[14:51:01 CEST] <BtbN> weird... if that's some attempt to DDoS, it's quite a small one.
[14:51:12 CEST] <BtbN> Feels more like someone with a heavily misconfigured script
[15:33:22 CEST] <durandal_1707> jamrial: hi, please review simd in afir filter
[15:35:23 CEST] <jamrial> durandal_1707: nice, sse3 float instrunctions
[15:36:06 CEST] <durandal_1707> it colu
[15:36:17 CEST] <durandal_1707> it could use fma3?
[15:37:40 CEST] <jamrial> i think so, the mulps + addsubps can probably be replaced with a single vfmaddsub
[16:19:20 CEST] <cone-714> ffmpeg 03Paul B Mahol 07master:66be24262689: avfilter/vf_histogram: actually add parade display mode
[16:22:36 CEST] <philipl> BtbN: sure - but you don't actually used the saved caps results yet :-)
[16:29:56 CEST] <philipl> BtbN: Changes look good. ship it.
[17:07:44 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:3f5a68533dec: avcodec/flacdec: Return error code instead of 0 for failures
[17:07:45 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:ea627dc0949c: avcodec/snowdec: Remove unneeded {}
[17:07:46 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:78aa93807b3e: avcodec/snowdec: Check width
[18:13:47 CEST] <jamrial> durandal_1707: do you have a working example command line for the afir filter? using a fate sample or a source filter preferably
[18:15:32 CEST] <durandal_1707> jamrial: any audio as input for second input google for impulse response files or generate/record your own
[18:17:23 CEST] <jamrial> alright, but what comman line do i use to get it working? it keeps complaining about needing exactly one input and one output
[18:17:40 CEST] <durandal_1707> eg: using aevalsrc=between(n,0,0),atrim=end_sample=1024 as IR should give same audio
[18:18:35 CEST] <durandal_1707> ffmpeg -i input -i ir.wav -lavfi afir out.wav
[18:43:15 CEST] <BtbN> philipl, i do?
[18:43:27 CEST] <BtbN> in the sequence callback, to error out if the bit variant isn't supported
[18:47:10 CEST] <philipl> BtbN: I see it. When I tried it last night (as opposed to this morning), I got the failure to create decoder error. I guess you added it afterwards
[18:47:14 CEST] <philipl> Anyway. It's good to go
[19:00:56 CEST] <cone-714> ffmpeg 03Timo Rothenpieler 07master:78518b72cf03: compat/nvenc: bump nvEncodeAPI.h to Video Codec SDK 8.0.14
[19:00:57 CEST] <cone-714> ffmpeg 03Timo Rothenpieler 07master:23538ad2eb76: avcodec/nvenc: remove usage of deprecated fields
[19:00:58 CEST] <cone-714> ffmpeg 03Timo Rothenpieler 07master:17f63d98e679: compat/cuda: update cuvid/nvdec headers to Video Codec SDK 8.0.14
[19:00:59 CEST] <cone-714> ffmpeg 03Timo Rothenpieler 07master:f15129a44bcd: compat/cuda: fix cast warnings on windows
[19:01:00 CEST] <cone-714> ffmpeg 03Timo Rothenpieler 07master:fea471347218: avcodec/cuvid: use capability check instead of dummy decoder
[19:01:01 CEST] <cone-714> ffmpeg 03Timo Rothenpieler 07master:ef390e348eba: Changelog: document updated Video Codec SDK
[19:01:02 CEST] <cone-714> ffmpeg 03Timo Rothenpieler 07master:cfbebe9dda7d: avcodec/nvenc: deprecated old rc modes, add new ones
[19:07:22 CEST] <BtbN> philipl, I really wonder if cuvid can be used as a video filter now
[19:07:34 CEST] <BtbN> Can't find any proper documentation on that.
[19:07:37 CEST] <BtbN> Tempted to just try
[19:11:11 CEST] <BtbN> j-b, it was still taking a bit of time after "Update is fast-forward", but not several minutes.
[19:12:43 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:2f2bc2e24632: avcodec/webp: Check for VP8X after other VP8 chunks
[19:12:44 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:c4f63b78b71e: avcodec/webp: Factor update_canvas_size() out
[19:12:45 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:72810d20b74f: avcodec/webp: Update canvas size in vp8_lossy_decode_frame() as in vp8_lossless_decode_frame()
[19:51:24 CEST] <durandal_1707> jamrial: so, what you tried?
[19:51:53 CEST] <alevinsn> j-b: the libmfx patch that adds a require alternative doesn't have to do with the existence of pkg-config on Windows
[19:52:08 CEST] <alevinsn> j-b: this was discussed on the ML
[19:52:11 CEST] <philipl> BtbN: yeah, that's definitely interesting.
[19:52:14 CEST] <alevinsn> j-b: it is a special case
[19:52:34 CEST] <alevinsn> michaelni: are you the maintainer of the ffmpeg tool?
[19:53:07 CEST] <alevinsn> assuming you are around
[19:54:31 CEST] <jamrial> durandal_1707: was trying to get fma3 asm working, but for an addsub as accumulator in fma3 there's no single instruction solution, so not sure if there will be any gain in performance
[19:56:17 CEST] <michaelni> alevinsn, i guess i am but there are several other people who probably understand some parts here or there better i havnt worked much on ffmpeg.c recently
[19:57:32 CEST] <alevinsn> michaelni: oh--well, I had submitted a patch to fix an interlaced video bug with ffmpeg and decoding some time ago, and I recently submitted a new version that allows it to pass fate on both Windows and Linux
[19:57:55 CEST] <alevinsn> is that code that you are familiar with, or would someone else be a better fit?
[20:01:35 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:62c5949beca2: avcodec/cllc: Check prefix
[20:01:36 CEST] <cone-714> ffmpeg 03Michael Niedermayer 07master:f1a4dd5e4809: avcodec/scpr: Fix multiple runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
[20:04:31 CEST] <michaelni> alevinsn, where can i find the patch ? do you know some subject or so of the mail?
[20:14:48 CEST] <alevinsn> if you search for interlaced you can find it easily on the ML
[20:14:53 CEST] <alevinsn> I can get you the direct link to it though
[20:15:22 CEST] <alevinsn> Re: [FFmpeg-devel] [PATCH] Fixed bug encountered when decoding interlaced video
[20:15:51 CEST] <alevinsn> I posted a better version last Friday
[20:16:05 CEST] <wm4> when will we have standards for commit messages
[20:16:42 CEST] <alevinsn> michaelni: Also at https://patchwork.ffmpeg.org/patch/3574/
[20:16:50 CEST] <alevinsn> wm4: with regard to what?
[20:20:54 CEST] <Compn> wm4 : or an easy way to fix commit messages... talk to git ?
[20:21:49 CEST] <durandal_1707> MNmpeg when??
[20:22:09 CEST] <durandal_1707> we are now CEmpeg afaik
[20:29:05 CEST] <nevcairiel> alevinsn: any commit message that says "fix bug" in any variant is usually not very good =p
[20:29:59 CEST] <alevinsn> nevcairiel: you would prefer a trac record to correspond to it?
[20:30:05 CEST] <alevinsn> I never submitted one
[20:30:13 CEST] <nevcairiel> no, i would want a proper message :)
[20:30:21 CEST] <alevinsn> this one is complicated
[20:30:36 CEST] <alevinsn> to describe in sufficient detail in a short one-line
[20:30:50 CEST] <nevcairiel> one line doesnt have to describe it, just summarize it
[20:30:57 CEST] <nevcairiel> there is plenty space to describe it below that
[20:31:07 CEST] <alevinsn> here's the latest version of the one line btw
[20:31:25 CEST] <alevinsn> ffmpeg: Fixed bug with decoding interlaced video
[20:31:30 CEST] <alevinsn> but I take it that isn't any better :-)
[20:31:52 CEST] <alevinsn> "ffmpeg: Fixed issue with decoding interlaced video" -- is that better? :-P
[20:32:56 CEST] <alevinsn> I mean, in the latest version of the patch I submitted, the subject is; "ffmpeg: Fixed bug with decoding interlaced video"
[20:33:18 CEST] <alevinsn> I think that's a pretty good summary--it explains everything in more detail in the commit message
[20:35:14 CEST] <alevinsn> nevcairiel: I'm not deliberately being obtuse, I just can't think of any way to describe it in one-line better than that
[20:55:31 CEST] <cone-714> ffmpeg 03Paul B Mahol 07master:49bbfb9d1393: avfilter: add arbitrary audio FIR filter
[20:56:45 CEST] <michaelni> alevinsn, review posted to ML
[20:59:47 CEST] <alevinsn> michaelni: thanks
[20:59:57 CEST] <alevinsn> what do you mean by: "It should be cleaner to not call check_init_output_file() from
[20:59:57 CEST] <alevinsn> init_output_stream() which avoids the new argument."
[21:02:25 CEST] <michaelni> i mean the function call could be done by the caller after the function where needed instead of passing an argument into the function to skip it
[21:03:59 CEST] <nevcairiel> alevinsn: as a general rule the top line should describe what the patch does, not what it fixes
[21:04:55 CEST] <alevinsn> nevcairiel: I'll have to think about how to summarize that in one line. Its not so easy in this case
[21:05:51 CEST] <alevinsn> michaelni: true, but then I would have to modify the two other places that call init_output_stream()
[21:06:42 CEST] <alevinsn> which I already did anyway, but would have to modify even further--is that your preference?
[21:07:23 CEST] <michaelni> the seperation of that call can be done in a "cosmetic" patch prior to the rest, i think the patches would be clearer that way
[21:08:11 CEST] <alevinsn> michaelni: that makes sense. So a cosmetic patch that has nothing to do with the bug fix, and then the bug fix patch to follow
[21:08:28 CEST] <michaelni> yes
[21:10:10 CEST] <alevinsn> ok, will do, thanks for reviewing the patch
[21:10:38 CEST] <michaelni> np
[21:10:39 CEST] <alevinsn> michaelni: do you think it would be useful to have a FATE test for this? I think so
[21:10:47 CEST] <michaelni> i think so too
[21:11:16 CEST] <alevinsn> I may need some help on IRC for uploading to the rsync repository, but I'll tackle that afterwards
[22:07:57 CEST] <wbs> alevinsn: have you actually encountered real HLS streams with tags continued on the next line with backslashes?
[22:08:14 CEST] <alevinsn> no--I'm just referring to the specification
[22:08:20 CEST] <wbs> alevinsn: you're reading it wrong then
[22:08:29 CEST] <wbs> alevinsn: nothing in the spec actually describes how this works
[22:08:33 CEST] <wbs> alevinsn: it's only in one example
[22:08:51 CEST] <wbs> alevinsn: and there it is only because you're not allowed to have too long lines in an RFC
[22:08:51 CEST] <alevinsn> " A '\' is used to indicate that the tag continues on the following
[22:08:51 CEST] <alevinsn> line with whitespace removed:
[22:08:51 CEST] <alevinsn> "
[22:08:54 CEST] <wbs> yes
[22:09:11 CEST] <wbs> the literal string written in the .m3u8 does not have the backslash, it's only for readability in the RFC
[22:09:40 CEST] <wbs> if you actually try to make such a .m3u8 and play it with apple tools, which would be the official reference implementation, you'll see that it doesn't actually work
[22:10:01 CEST] <alevinsn> I see
[22:10:27 CEST] <alevinsn> and, I guess it can be interpreted as such at https://developer.apple.com/library/content/technotes/tn2288/_index.html as well
[22:10:44 CEST] <alevinsn> well, why don't you chime in then :-)
[22:11:07 CEST] <wbs> no, I've done enough here already
[22:11:17 CEST] <wbs> if you want to add code for something that doesn't actually exist, I won't stop you
[22:11:32 CEST] <alevinsn> I wasn't doing this
[22:11:40 CEST] <alevinsn> I suggested it in a review to Steven Liu
[22:11:53 CEST] <alevinsn> and he interpreted it the same way (although, English isn't his first language)
[22:11:58 CEST] <alevinsn> and he wrote the patch
[22:12:11 CEST] <wbs> and neither of you chose to actually test if any official hls player supports it?
[22:12:31 CEST] <alevinsn> I merely provided a review--he was the one working on this
[22:13:03 CEST] <alevinsn> and that was only one small aspect to my initial review
[22:13:14 CEST] <alevinsn> the funny thing is
[22:13:25 CEST] <alevinsn> why would Apple put the '\'
[22:13:30 CEST] <alevinsn> in a non-RFC Web page
[22:13:33 CEST] <alevinsn> at https://developer.apple.com/library/content/technotes/tn2288/_index.html
[22:13:46 CEST] <alevinsn> that doesn't make sense, if the only purpose was to do that for RFC purposes
[22:14:58 CEST] <alevinsn> there is plenty of room to put the entire tag specification on one line
[22:15:06 CEST] <nevcairiel> the comment there does seem like its only a note for the example, and not something thats supposed to be a standard
[22:15:14 CEST] <nevcairiel> and who knows what kind of display sizes they design it for
[22:15:58 CEST] <wbs> yes, and like, when you read the literal spec with grammars and whatnot, there's no reference to it anywhere, except for in that example
[22:16:19 CEST] <alevinsn> it is a bit ambiguous, but if it doesn't work with the official player, then there is no point to having it in ffmpeg
[22:20:19 CEST] <alevinsn> ok, I'll respond to me review
[22:35:43 CEST] <alevinsn> wbs: thanks for the correction
[23:30:53 CEST] <cone-714> ffmpeg 03Paul B Mahol 07master:65b710910534: Changelog: mention afir addition
[00:00:00 CEST] --- Wed May 10 2017
1
0
[01:00:21 CEST] <kinkinkijkin> is there a cpu-based encoder of h265?
[01:00:31 CEST] <furq> x265
[01:00:34 CEST] <kinkinkijkin> thanks
[01:00:43 CEST] <furq> and libkvazaar but nobody uses that
[01:01:01 CEST] <kinkinkijkin> and h265 will crunch files a lot smaller, right?
[01:01:04 CEST] <mixfix41> hi i cut a clip of mine https://superuser.com/questions/138331/using-ffmpeg-to-cut-up-video but after cutting twice to have 3 clips total the 2nd clip is missing the moov atom : moov atom not found, is there a way to cut the clip and keep the moov file present in the consequetive outputs
[01:02:48 CEST] <furq> mixfix41: that should work, although you can do it all in one command using the segment muxer
[01:03:11 CEST] <furq> kinkinkijkin: in theory, sure
[01:03:20 CEST] <furq> not so much in practice
[01:04:52 CEST] <kinkinkijkin> if I have two encodes with a target bitrate of 700kbps, one h264 and one h265, which is likely to look better given settings maximized for quality with no importance on encode time?
[01:05:51 CEST] <furq> x265
[01:06:08 CEST] <kinkinkijkin> okay, thank you
[01:06:19 CEST] <furq> it'll take ~10x longer than x264 veryslow
[01:06:21 CEST] <furq> maybe even more
[01:06:48 CEST] <furq> a lot of people think it's a magic bullet and they can use x265 with default settings and it'll be 50% smaller than x264
[01:07:05 CEST] <furq> you only really see gains when you use excruciatingly slow x265 settings
[01:07:15 CEST] <furq> you can get pretty good gains though
[01:07:52 CEST] <kinkinkijkin> darn, if only I had access to hardware h265 on this setup
[01:09:48 CEST] <furq> hardware h265 is generally worse than x264
[01:10:03 CEST] <kinkinkijkin> ah...
[01:10:17 CEST] <furq> nvenc hevc is scarcely better than hvenc h264
[01:10:35 CEST] <furq> it's just an hevc bitstream because then they can write "HEVC" on their gpu box
[01:11:31 CEST] <kinkinkijkin> is there a bundled setting with x265 to get these excruciating encode times? like -preset veryslow or something like that
[01:11:35 CEST] <furq> presumably next to the picture of a 3d wizard riding a motorcycle and doing an endo on a giant vram chip
[01:11:54 CEST] <furq> and yeah x265's interface is modelled on x264's
[01:12:02 CEST] <furq> so you can just use -preset veryslow and -crf
[01:12:14 CEST] <furq> the crf values aren't the same as x264, but it's the same idea
[01:12:44 CEST] <furq> it's worth pointing out that in spite of the name and interface, they're completely different developers
[01:13:04 CEST] <furq> i think the community has a rather higher opinion of x264's developers
[01:26:57 CEST] <mixfix41> yeah it looks i can clip those output files from seg muxer thanks furq
[02:21:35 CEST] <kinkinkijkin> ah, I love it when my reencode is going at 0.12x speed
[02:21:44 CEST] <kinkinkijkin> and has been for the past 45 minutes
[02:21:51 CEST] <furq> welcome to x265
[02:22:26 CEST] <kinkinkijkin> I decided to test-reencode an episode of an anime (which was already encoded extremely well)
[02:22:34 CEST] <kinkinkijkin> instead of one of my 3-minute rally stage videos
[02:23:16 CEST] <furq> https://www.youtube.com/watch?v=3Kt7sq7F3C8
[02:23:19 CEST] <furq> is this your channel
[02:23:51 CEST] <kinkinkijkin> lol I wish
[02:24:01 CEST] <kinkinkijkin> I like how it starts out with tarmac rally
[02:24:09 CEST] <kinkinkijkin> tarmac doesn't get enough love from rally spectators
[02:25:30 CEST] <kinkinkijkin> oh my
[02:25:33 CEST] <kinkinkijkin> is this all tarmac
[02:26:58 CEST] <kinkinkijkin> oh some light gravel
[02:27:23 CEST] <geri> hi i try to concatinate some mp4 files but run into the following issue: http://ideone.com/O0JEga
[02:27:25 CEST] <geri> any idea?
[02:29:28 CEST] <kinkinkijkin> heh furq, that video even has harri rovanpera
[02:29:46 CEST] <furq> geri: the concat file should look like "file 'soccer1.mp4'" etc
[02:29:55 CEST] <geri> they are from iphone 6 and original in mov format
[02:29:55 CEST] <kinkinkijkin> the son of which is currently the WRC-2 favourite, at only 16
[02:30:16 CEST] <furq> i noticed carlos sainz in there, who also has a famous son
[02:31:02 CEST] <kinkinkijkin> and richard burns, the rally game of whom is still the current rally league standard
[02:31:20 CEST] <kinkinkijkin> even though it's 15 years old
[02:32:03 CEST] <furq> i've only really played the mcrae ones
[02:32:14 CEST] <furq> and the ones in that series after they stopped using his name
[02:32:24 CEST] <furq> i still need to check out dirt rally actually
[02:32:28 CEST] <kinkinkijkin> they only stopped using his name because he died
[02:32:37 CEST] <furq> they used his name in one after he died iirc
[02:32:38 CEST] <kinkinkijkin> dirt rally is hard, as is richard burns rally
[02:32:44 CEST] <kinkinkijkin> and sebastien loeb rally, too
[02:32:54 CEST] <furq> yeah i was a big fan of dirt 3 but i was under no illusions about how realistic it was
[02:33:08 CEST] <furq> dirt 1 was pretty good as well
[02:33:21 CEST] <furq> before they pumped it full of ken block
[02:33:45 CEST] <kinkinkijkin> ken block and gymkhana were the worst things about dirt 3
[02:33:51 CEST] <furq> NICE DRIFT BRAH. CLICK THE YOUTUBE BUTTON TO UPLOAD IT TO YOUR FANS
[02:33:55 CEST] <furq> no thanks ken
[02:34:03 CEST] <furq> 2 was much worse for that stuff
[02:34:12 CEST] <kinkinkijkin> that wasn't ken block lol, that's another guy
[02:34:17 CEST] <furq> pastrana?
[02:34:28 CEST] <kinkinkijkin> I meant that line
[02:34:33 CEST] <furq> oh right yeah
[02:34:47 CEST] <kinkinkijkin> that line is your "team engineer", the name of whom is only in the game credits
[02:35:06 CEST] <furq> the important thing is that you could still have a scottish co-driver in 3
[02:35:18 CEST] <furq> that's the most critical aspect of any rally game
[02:35:26 CEST] <drv> dirt rally is good stuff, especially in VR
[02:35:38 CEST] <furq> yeah i've been meaning to check it out
[02:35:40 CEST] <furq> along with grid autosport
[02:35:50 CEST] <kinkinkijkin> dirt rally has some unrealisms in its physics though, like the gravity is set wrong and there is no aero simulation
[02:36:04 CEST] <kinkinkijkin> it's all suspension, tires, ground, and gravity
[02:36:06 CEST] <furq> i'm not a hardcore enough sim racer to really care
[02:36:09 CEST] <furq> i don't have a wheel or anything
[02:36:17 CEST] <kinkinkijkin> the gravity is an annoying thing
[02:36:21 CEST] <kinkinkijkin> because it's way too weak
[02:36:26 CEST] <kinkinkijkin> even for fun purposes
[02:36:33 CEST] <furq> i did like how often they mentioned pike's peak in dirt 3
[02:36:41 CEST] <furq> they gave you all the pike's peak special edition cars
[02:36:45 CEST] <furq> but then they didn't let you race on pike's peak
[02:36:54 CEST] <kinkinkijkin> dirt rally has pikes peak
[02:37:03 CEST] <kinkinkijkin> in fact, pikes peak is the only hillclimb in dirt rally
[02:37:05 CEST] <kinkinkijkin> somewhat annoyingly
[02:37:07 CEST] <furq> i assume because you'd have probably found it suspicious that you'd have been able to break the record by two and a half minutes
[02:37:34 CEST] <kinkinkijkin> heh
[02:37:59 CEST] <furq> in the original grid i could do 2:30 laps around le mans, which is about 50 seconds faster than the actual car you were meant to be driving
[02:38:06 CEST] <furq> and i wasn't particularly good
[02:38:26 CEST] <geri> furq: works now, but the video is rotate by 90 degrees, any idea?
[02:38:32 CEST] <geri> i mean the final one
[02:38:41 CEST] <kinkinkijkin> add rotation metadata
[02:38:49 CEST] <kinkinkijkin> it probably had that before and it ended up being stripped
[02:39:03 CEST] <furq> if only one of them is rotated then you're probably going to have to reencode it
[02:39:07 CEST] <geri> oh
[02:39:22 CEST] <geri> ad the end of video 1 the phone is flipped
[02:39:39 CEST] <furq> yeah you'll need to reencode one of the videos
[02:39:48 CEST] <furq> the rotation metadata can't change mid-stream
[02:40:25 CEST] <furq> !filter transpose
[02:40:25 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#transpose
[02:40:35 CEST] <furq> reencode it with that and then concat it to the ones that are the right way up
[02:40:51 CEST] <furq> you'll need to make sure you use the same settings though
[02:41:04 CEST] <furq> it might be less hassle to just reencode the whole thing
[02:42:29 CEST] <furq> actually nvm you can't do a 180 flip with transpose
[02:42:32 CEST] <furq> !filter vflip
[02:42:32 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#vflip
[02:42:52 CEST] <furq> !filter rotate
[02:42:52 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#rotate
[02:42:54 CEST] <furq> one of those two will do it
[02:43:04 CEST] <furq> or hflip and then vflip
[02:44:08 CEST] <kinkinkijkin> hour and 5 minutes, reflow and reencode is half done
[02:47:53 CEST] <geri> For values between 4-7, the transposition is only done if the input video geometry is portrait and not landscape. These values are deprecated, the passthrough option should be used instead.
[02:47:54 CEST] <geri> hu?
[02:52:56 CEST] <kinkinkijkin> oh wait a second, I thought the video I'm reencoding was a really big h264, turns out it's rawvideo
[02:53:02 CEST] <kinkinkijkin> lol no wonder it's so hugeà
[02:58:37 CEST] <geri> what video format is good for a phone?
[02:59:09 CEST] <DHE> typically mp4 with H264 Main profile video
[03:01:53 CEST] <geri> how to check the codec i currently use?
[03:01:58 CEST] <geri> i have a mp4 video
[03:02:43 CEST] <DHE> ffprobe can tell you, but the profile I'm not sure about
[03:03:54 CEST] <geri> http://ideone.com/o8ujBh
[03:04:32 CEST] <geri> can i concatinate those 2 videos: intro.mp4 and final.mp4 ?
[05:02:47 CEST] <kinkinkijkin> https://www.youtube.com/watch?v=PVeIBtUwpJI 30-minute reencode from mpeg2
[05:09:40 CEST] <furq> does youtube accept hevc now
[05:10:33 CEST] <kinkinkijkin> yep
[05:10:44 CEST] <kinkinkijkin> probably still reencodes it, like it does with everything
[05:10:56 CEST] <kinkinkijkin> but it didn't lose a noticeable amount of quality
[05:11:24 CEST] <furq> well yeah it reencodes everything
[05:11:26 CEST] <kinkinkijkin> the source was already blurry, because the game being recorded is slightly blurry in my current setup
[05:11:29 CEST] <furq> but until recently you couldn't upload hevc
[05:11:34 CEST] <kinkinkijkin> so nothing is easy to notice
[05:20:23 CEST] <kinkinkijkin> furq to be honest I'm really impressed with the quality of mvtools when applied to something other than anime
[05:20:42 CEST] <kinkinkijkin> no noticeable artifacts, except some missed motion
[05:28:07 CEST] <james999> what are the problems with anime again? bad interlacing?
[05:28:52 CEST] <furq> it's bad
[05:30:11 CEST] <kinkinkijkin> when interpolating framerates, any source with lots of flat colours and large amounts of motion will have tons of artifacts
[05:30:35 CEST] <kinkinkijkin> the higher the contrast, the more visible they will be
[05:33:24 CEST] <james999> interpolating framerates? like 3:2 or converting NTSC to PAL?
[05:33:44 CEST] <kinkinkijkin> like adding new frames from motion data
[05:33:56 CEST] <kinkinkijkin> specifically from motion data is there an issue
[05:34:02 CEST] <kinkinkijkin> with artifacts, anyways
[05:34:47 CEST] <kinkinkijkin> I'm trying to work on a way of either removing the artifacts or making them far less likely of happening
[05:35:39 CEST] <kinkinkijkin> the former would require knowing how to compare frames, which I don't
[05:57:47 CEST] <thebombzen> oh man YouTube can do HEVC now?
[05:57:49 CEST] <thebombzen> about time
[06:02:52 CEST] <james999> there's probably a subtle reason why you refer to it as hevc instead of h265
[06:03:31 CEST] <james999> well that was an awkward say of asking that lol
[06:04:05 CEST] <kinkinkijkin> hevc is easier and quicker to type
[06:04:17 CEST] <kinkinkijkin> also h265 is really similar to h264
[06:04:26 CEST] <james999> yes that's what I thought of immediately after I typed it
[06:04:28 CEST] <TD-Linux> this windows CVE
[06:04:29 CEST] <TD-Linux> I'm dead
[06:04:36 CEST] <TD-Linux> also wrong channel
[06:55:09 CEST] <thebombzen> james999: because its' more common to call it HEVC than H.265
[06:55:25 CEST] <thebombzen> in the same way that H.264 can also be called AVC but nobody does, it's more common to use H.264
[09:22:47 CEST] <james999> ah ok
[10:32:04 CEST] <gr8> I have a bunch of 1080p movies that I want to convert to a lower resolution because my old computer is not able to play it. The thing is, it is converting videos very slowly obviously, so I am looking for the most efficient method to resize the video to either 720p or 540p!? Usually I am just using -c:a copy -vf scale=960:-1, but is there a better way?
[10:34:52 CEST] <furq> if you're using x264 then you probably want to use -preset superfast or something
[10:39:33 CEST] <gr8> furq: well actually I would prefer if it wouldn't do any resampling, but mechanically divide the resolution by 2, e.g. merge each 4 pixels into one...
[10:39:48 CEST] <gr8> don't know if that behavior can be enforced?
[10:40:38 CEST] <gr8> the codec is h264
[12:17:55 CEST] <crst> Hi, why do I get: Unable to find a suitable output format for 'libopus' for: find . -name "*.mp3" -print0 | xargs -0 -P8 -n1 -I {} ffmpeg -i {} -acodec libopus {}.opus
[12:22:20 CEST] <furq> crst: -i "{}"
[12:22:26 CEST] <furq> and quote the output filename as well
[12:24:28 CEST] <crst> furq: mhmm, I tried different combos of quoting but I still get the same error
[12:28:32 CEST] <crst> I asked at #bash before I came here, and they told me it's not a bash question
[12:42:21 CEST] <termos> my ffmpeg created flv stream plays well in ffplay but not in any of the flv flash players that I've tried. Could it be some metadata missing?
[12:42:52 CEST] <termos> the flash players are playing other rtmp flv streams well, but not the one I'm generating
[12:43:58 CEST] <furq> what codecs
[12:44:37 CEST] <termos> h264 and aac, libx264 and fdk_aac specifically
[12:44:57 CEST] <furq> weird
[12:45:30 CEST] <furq> i've not used ffmpeg's rtmp as anything other than ingest for nginx-rtmp for ages, but that works fine
[12:45:37 CEST] <furq> and i don't remember having issues back when flash was still a thing
[12:45:50 CEST] <furq> or needing to do anything out of the ordinary
[12:48:42 CEST] <termos> indeed weird, i have another encoder based on libffmpeg that's working fine so i'm sure i have missed something
[16:29:02 CEST] <termos> hm, while printing out my AVCodecContext->time_base while decoding (no errors) it just says 0/2. What is the actual time_base used here? For audio it's 1/44100 which looks correct since it's 1/sample_rate
[16:29:37 CEST] <termos> expecting the decoder to set it to something like 1/(framerate*n)
[16:38:30 CEST] <Mavrik> Check your AVStream timebase
[16:38:37 CEST] <Mavrik> That might be more accurate depending on format
[16:45:57 CEST] <termos> that one seems to be correct, well it's 1/1000 at least
[16:46:39 CEST] <termos> so i'm doing av_packet_rescale_ts from AVStream.time_base into codec time_base, so scaling 1/1000 -> 1/44100 for audio but 1/1000 -> 0/2 for video
[16:46:56 CEST] <termos> is it wrong to want to rescale here?
[16:49:20 CEST] <kepstin> why do you want to rescale there? The important thing is to have the frame pts match the timebase you're using, and that should be happening by default if you just use the stream timebase, I think?
[16:53:55 CEST] <termos> it doesn't play without rescaling, i'm following the example here: https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/transcoding.c#L54…
[16:54:31 CEST] <termos> i'm not using avcodec_decode_video2 but rather the newer avcodec_send_packet
[17:12:15 CEST] <draean> I'm using ffmpeg to transcode files to h264. I've noticed that an older version (x264 core 120 r2151 a3f4407) seems to transcode the same file about 6x faster than a newer version (x264 core 148 r3 4fc4a2b). If I look at the encoding settings, they appear identical with the exception that the newer ffmpeg includes 'lookahead_threads=1' I'm wondering why this drastic speed reduction in the later version?
[17:16:14 CEST] <DHE> holy crap that's old. build 120 is probably around 2011, maybe early 2012
[17:17:41 CEST] <draean> yeah, that sounds about right >_< stuff was working! so I didn't change anything, then I wanted new goodies in the later version, so i upgraded, but now my transcodes have become so much slower, it's bummin' me out =p
[17:18:06 CEST] <kepstin> draean: If you want to reduce the quality of the new version so that it's as fast as the older one, just use a slower preset? :)
[17:18:09 CEST] <DHE> you can speed it up by adding -preset fast (or faster, or veryfast, or superfast) at the cost of image quality or file size epdending on your settings
[17:18:13 CEST] <kepstin> er, faster preset*
[17:18:40 CEST] <DHE> but over ~5 years no idea what's changed specifically. unless you feel like bisecting...
[17:18:51 CEST] <furq> 6x sounds suspect
[17:18:52 CEST] <draean> ahha. so I tried adding -preset veryfast to both the new and the old. it seemed to increase the speed of either by a similar factor
[17:19:01 CEST] <furq> does your new build have some optimisations disabled or something
[17:19:19 CEST] <DHE> that would explain a lot. perhaps missing nasm or something?
[17:19:46 CEST] <draean> oh, you ask good questions. lemme see
[17:19:48 CEST] <kepstin> huh, I thought current x264 required yasm, didn't work with nasm?
[17:19:55 CEST] <DHE> yeah my mistake
[17:20:02 CEST] <kepstin> either way, the configure output should tell you if it can't build the assembly code
[17:20:03 CEST] <DHE> you'd know if you didn't because you'd have to compile with --disable-asm
[17:20:16 CEST] <furq> x264 --version should show the config options
[17:20:49 CEST] <furq> assuming it's the same build you linked ffmpeg with
[17:21:40 CEST] <draean> root@b100-hypercaster:/media/psg/vol1/preload# x264 --version
[17:21:40 CEST] <draean> x264 0.148.3 4fc4a2b
[17:21:41 CEST] <draean> built on Oct 26 2015, gcc: 4.6.3
[17:21:42 CEST] <draean> x264 configuration: --bit-depth=8 --chroma-format=all
[17:21:44 CEST] <draean> libx264 configuration: --bit-depth=8 --chroma-format=all
[17:21:46 CEST] <draean> x264 license: GPL version 2 or later
[17:22:24 CEST] <furq> [libx264 @ 000000000060f500] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
[17:22:30 CEST] <furq> you should get a message like that from ffmpeg
[17:22:41 CEST] <furq> make sure that looks correct, that it's actually using 100% cpu etc
[17:24:46 CEST] <draean> [libx264 @ 0x374bf00] using SAR=1/1
[17:24:46 CEST] <draean> [libx264 @ 0x374bf00] using cpu capabilities: none!
[17:24:46 CEST] <draean> [libx264 @ 0x374bf00] profile High, level 3.1
[17:24:51 CEST] <draean> D:
[17:24:58 CEST] <furq> that's probably not goodf
[17:25:46 CEST] <draean> [libx264 @ 0x1152340] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2 AVX
[17:25:50 CEST] <draean> that's from the older version
[17:26:11 CEST] <furq> did you build the new version yourself
[17:26:22 CEST] <furq> i'm not sure whether it'll automatically build without asm if you don't have yasm installed
[17:26:30 CEST] <furq> if it does then that's probably to blame
[17:27:19 CEST] <draean> I did build it myself. so you're saying I probably don't have asm built into it, and I need it
[17:27:23 CEST] <furq> yeah
[17:27:42 CEST] <furq> install yasm and rebuild
[17:27:54 CEST] <furq> or just grab a static build of ffmpeg
[17:28:08 CEST] <furq> https://www.johnvansickle.com/ffmpeg/
[17:28:42 CEST] <draean> excellent. thanks a lot. I think I'm stuck with building it myself, we have some weirdo patch in some place I'm not that familiar with to try and more closely approximate CBR
[17:29:53 CEST] <furq> that might not be needed any more
[17:30:29 CEST] <furq> you can use -x264-params nal-hrd=cbr
[17:30:35 CEST] <furq> that's cbr enough for bluray compatibility
[19:23:08 CEST] <holst1> I'm looking at the man page http://www.linuxhowtos.org/manpages/1/ffmpeg-devices.htm and I cannot understand how I can pass the "window_id" flag to `-f xv`?
[19:27:12 CEST] <c_14> the official manpages are here https://ffmpeg.org/ffmpeg-devices.html, and just put -window_id <foo> before -f xv
[19:27:22 CEST] <kepstin> holst1: those flags just turn into command line options when used with the ffmpeg cli, so you have "-window_id 1234 -f xv"
[19:29:36 CEST] <holst1> ah thanks!
[19:39:03 CEST] <kbarry> I'm wanting to know if a file is VBR or CBR. Google is failing me in searching for how I might do this with ffprobe.
[19:39:34 CEST] <kbarry> Also, i'm only working with Audio (mp3) files.
[19:39:56 CEST] <furq> use mediainfo
[19:42:19 CEST] <kbarry> Thanks,
[19:42:35 CEST] <kbarry> Is it safe to assume there is no strait-forward method for this in ffprobe?
[19:45:42 CEST] <furq> not that i know of
[19:46:17 CEST] <furq> the most obvious way would be bit_rate != max_bit_rate
[19:46:26 CEST] <furq> but that doesn't work for the first vbr mp3 i tried it with
[19:48:46 CEST] <DHE> ffprobe doesn't scan the whole file and is usually happy once it's convinced it has all the codec parameters. unless you use options to force the issue like -show_frames
[19:49:29 CEST] <furq> i just get max_bit_rate=N/A
[19:49:37 CEST] <furq> even with -analyzeduration 100M -count_frames
[19:51:55 CEST] <furq> mediainfo generally seems more robust even if the interface is somehow even more arcane than ffprobe's
[19:59:46 CEST] <furq> http://vpaste.net/ExMGg
[19:59:48 CEST] <furq> this also works
[20:04:44 CEST] <pgorley> hi, is there an example on how to implement the mediacodec hwaccel somewhere? or is it along the same lines as vaapi and vdpau?
[20:19:44 CEST] <draean> Alright, Im still having trouble getting cpudetect to work. I have yasm installed:
[20:19:44 CEST] <draean> root@aio-b2000-12:~/ffmpeg-3.2.4# apt-cache policy yasm
[20:19:44 CEST] <draean> yasm:
[20:19:46 CEST] <draean> Installed: 1.1.0-1
[20:19:48 CEST] <draean> Candidate: 1.1.0-1
[20:19:50 CEST] <draean> Version table:
[20:19:52 CEST] <draean> *** 1.1.0-1 0
[20:19:54 CEST] <draean> 500 file:/var/www/apt_repo/master/ Packages
[20:19:56 CEST] <draean> 100 /var/lib/dpkg/status
[20:19:58 CEST] <draean> and Im installing with
[20:20:00 CEST] <draean> ./configure --arch=amd64 --extra-libs=-ldl --enable-gpl --enable-libx264 --enable-libmp3lame --enable-postproc --enable-libvorbis --enable-libtheora --enable-libvpx
[20:20:02 CEST] <draean> is this a path issue or something? I feel it must be some nub thing Im doing :/
[20:49:24 CEST] <kepstin> draean: you need to rebuild x264, not ffmpeg
[20:50:11 CEST] <kepstin> (well, if you're using static libs, you need to do both, but x264 first, for sure!)
[20:51:50 CEST] <draean> ahha, thanks
[21:24:16 CEST] <metaphysician> How do I use Quick Sync Video encoding on Ubuntu?
[21:25:59 CEST] <metaphysician> Do I only need libmfx or the entire Intel Media SDK?
[21:29:16 CEST] <BtbN> Just use libva instead
[21:31:13 CEST] <metaphysician> BtbN: For h264 encoding that would be h264_vaapi?
[21:35:19 CEST] <BtbN> metaphysician, yes, doesn't need any insane patches applied to the system
[21:48:20 CEST] <metaphysician> OK, it seems to be working with -vaapi_device /dev/dri/renderD128 -vf 'format=nv12,hwupload' -c:v h264_vaapi , but I cannot use the scale filter with this for resizing.
[21:49:14 CEST] <BtbN> just use it before uploading
[21:49:41 CEST] <BtbN> or use scale_vaapi to also hw accelerate the scaling
[22:09:07 CEST] <metaphysician> Cool, but how do you control the quality/bitrate? -crf option doesn't work.
[22:11:32 CEST] <metaphysician> Looking at vaapi_encode_h264.c, it seems to have a quality 0-8 option.
[22:12:57 CEST] <BtbN> that's pretty much it I think, no idea, don't have a machine that supports it
[22:13:09 CEST] <kepstin> metaphysician: i think it only supports single-pass vbr, so set a bitrate.
[22:13:36 CEST] <kepstin> metaphysician: if you want high quality, you should be using x264 rather than a hardware encoder, of course.
[22:23:51 CEST] <vidj> i got a question regarding obs&ffmpeg. basically i'm using ffmpeg to record and i'm wondering if nvenc_hevc (libx265) uses gpu or cpu to encode?
[22:24:07 CEST] <vidj> and if it's even possible for x265 to use gpu encoding
[22:33:43 CEST] <vidj> what encoder would i use for hardware encoding with hevc?
[22:37:52 CEST] <ChocolateArmpits> vidj, try hevc_qsv seems the only one atm
[22:38:36 CEST] <ChocolateArmpits> Of course you have to have a supported cpu and the ffmpeg must be compiled for quick sync support
[22:40:10 CEST] <metaphysician> Thanks BtbN, kepstin.
[22:41:04 CEST] <BtbN> vidj, uhm, "nvenc_hevc (libx265)". What?
[22:41:26 CEST] <kepstin> vidj: nvenc_hevc and libx265 are two separate encoders, the first uses gpu, the second uses cpu.
[22:42:23 CEST] <kepstin> (well, nvenc_hevc uses a hardware encoder block on the gpu die, not the main "gpu" processor itself, but that's being pedantic)
[22:47:55 CEST] <thebombzen> BtbN: wouldn't you want to put the scale filter before format, not before hwupload?
[22:48:12 CEST] <BtbN> doesn't really matter
[22:48:45 CEST] <thebombzen> afaik the way libavfilter works is -vf format simply requests a format from the previous filter
[22:49:25 CEST] <thebombzen> so scale,format will cause scale to do the colorspace conversion and the size conversion in one go
[22:50:09 CEST] <thebombzen> whereas format,scale will autoinsert a scale filter in front with a colorspace conversation, and then the scale you explicitly used will be after that
[22:50:49 CEST] <thebombzen> because if the previous filter (such as vf_buffer) can't provide the requested format it'll insert a scale filter
[22:51:03 CEST] <vidj> BtbN, kepstin i guess it's just poor naming in obs
[22:51:11 CEST] <vidj> ChocolateArmpits: ye will try hevc_qsv now
[22:51:22 CEST] <BtbN> libx265 is a software encoder.
[22:51:40 CEST] <vidj> ye but nvenc_hevc should be hardware
[22:51:53 CEST] <vidj> i've no idea why there's (libx265) appended to it
[22:52:06 CEST] <vidj> same goes for hevc_qsv, (libx265) also appended
[22:52:08 CEST] <vidj> makes no sense for me
[22:52:21 CEST] <BtbN> I guess someone tought libx265 is the codec name?
[22:52:26 CEST] <BtbN> But since when does obs even support hevc?
[22:53:52 CEST] <kepstin> well, we see people confused with x264/h264 all the time here. but *lib*x265? :/
[22:55:17 CEST] <vidj> BtbN: well i've grabbed latest ffmpeg libs and put it in obs bin/
[22:55:21 CEST] <vidj> so it supports it now :D
[22:55:25 CEST] <vidj> but just for recording
[22:56:05 CEST] <vidj> i mean, im using it just for recording, it's pointless to stream with 265 when twitch and all the other services i know don't support the codec
[22:56:37 CEST] <vidj> and obs errors out on hevc_qsv :|
[22:57:56 CEST] <vidj> 22:56:14.771: ffmpeg_data_init failed
[22:59:01 CEST] <vidj> BtbN: https://www.plusforward.net/post/25305/obs%2Bx265/ you can see here my recordings with h265
[00:00:00 CEST] --- Wed May 10 2017
1
0
[00:02:05 CEST] <durandal_1707> convolve_add ?
[00:02:51 CEST] <durandal_1707> if its used by single filter i can not move it to lavu?
[00:05:07 CEST] <kierank> durandal_1707: what does it do exactly the function?
[00:06:18 CEST] <durandal_1707> it multiplies two complex numbers and sum it to accumulator
[00:06:52 CEST] <durandal_1707> accumulator is also complex number
[00:08:34 CEST] <kierank> scalarproduct_complex
[00:08:48 CEST] <kierank> or just scalarproduct if you want
[00:09:13 CEST] <jamrial> the former
[00:10:10 CEST] <nevcairiel> if it does the same as scalarproduct_float just on complex numbers, then scalarproduct_complex is what it should be called
[03:29:53 CEST] <cone-979> ffmpeg 03Michael Niedermayer 07master:80a3227be624: ffprobe: make function replacement macros behave correctly
[03:29:53 CEST] <cone-979> ffmpeg 03Michael Niedermayer 07master:3c3d4ce4fda1: doc: fix bistream typo
[03:29:53 CEST] <cone-979> ffmpeg 03Michael Niedermayer 07master:8b1f66cf5c2e: avcodec/wmv2dsp: Fix runtime error: signed integer overflow: 181 * -12156865 cannot be represented in type 'int'
[03:29:53 CEST] <cone-979> ffmpeg 03Michael Niedermayer 07master:3a4d387195a5: avcodec/ffv1dec: Fix copying planes of paletted formats
[03:29:53 CEST] <cone-979> ffmpeg 03Michael Niedermayer 07master:5f928c5201c0: avcodec/rangecoder: Test for invalid corner case
[05:52:28 CEST] <atomnuker> rcombs: ping
[05:52:32 CEST] <rcombs> hi
[05:52:53 CEST] <atomnuker> solved flac problems?
[05:53:05 CEST] <rcombs> oh yeah, would probably help if I rebased and resent, wouldn't it
[05:53:40 CEST] <atomnuker> yep, very much so
[06:39:55 CEST] <rcombs> atomnuker: there you go
[06:47:19 CEST] <atomnuker> cool
[06:47:26 CEST] <atomnuker> I've send my librsvg patches too
[06:54:54 CEST] <jamrial> rcombs: ideally, you'd make flac_write_picture() shared in its own file (or in flac_picture.c)
[06:55:11 CEST] <jamrial> so it can be used by the ogg muxer
[06:55:12 CEST] <rcombs> oh, is that something other code would want to do?
[06:55:14 CEST] <rcombs> ahh
[06:55:47 CEST] <rcombs> flac_picture.c sounds good
[06:57:10 CEST] <jamrial> that file has the decode picture function, so i'm not sure if the encode one should go there
[06:57:17 CEST] <jamrial> maybe flacenc_picture.c instead
[06:57:22 CEST] <cone-370> ffmpeg 03Daniil Cherednik 07master:b8c2b9c39279: avcodec/dcaenc: Initial implementation of ADPCM encoding for DCA encoder
[06:59:01 CEST] <rcombs> maybe flac_picture_enc.c?
[06:59:17 CEST] <rcombs> (does it really matter?)
[07:01:59 CEST] <jamrial> I prefer flacenc_picture.c
[07:03:31 CEST] <atomnuker> yeah, would be nice to be able to embed pictures inside ogg files too
[07:17:54 CEST] <atomnuker> rcombs: what does the segment muxer do?
[07:18:12 CEST] <rcombs> like, in general?
[07:18:25 CEST] <atomnuker> yeah
[07:19:22 CEST] <rcombs> writes output to multiple segment files, using some underlying muxer
[07:19:55 CEST] <atomnuker> is it used by the flac muxer?
[07:20:26 CEST] <atomnuker> wait, multiple segment files?
[07:20:29 CEST] <rcombs> you can use whatever underlying muxer you like
[07:20:34 CEST] <atomnuker> it writes to multiple files?
[07:20:38 CEST] <rcombs> yes
[07:21:17 CEST] <rcombs> it can either reopen the underlying muxer for each file, or keep the muxer open and reopen the AVIOContext
[07:21:47 CEST] <rcombs> in this case, I'm using it to split cue/flac pairs
[07:22:22 CEST] <rcombs> the cue demuxer outputs the cue sheet's contents as chapters, and the flac file's contents as streams and packets
[07:22:37 CEST] <atomnuker> damn, I didn't know this was possible
[07:22:39 CEST] <rcombs> I configure the segment muxer to split each chapter into a separate .flac file
[07:22:59 CEST] <rcombs> with the filenames based on the chapter metadata
[07:23:14 CEST] <rcombs> the primary disadvantage is that it only gives packet-level granularity, rather than sample-level
[07:26:09 CEST] <wm4> such a hack
[07:26:51 CEST] <rcombs> you're not wrong
[07:27:48 CEST] <rcombs> atomnuker: if you come up with something better for this use-case (small C wrapper around lavf+lavc, I'd imagine?), I'd be happy to use that instead
[07:29:30 CEST] <atomnuker> rcombs: no, to split cue to stuff I have a lua script which decodes to a wav and lets shnsplit do
[07:29:44 CEST] <atomnuker> *do the splitting and encoding
[07:30:10 CEST] <rcombs> I'm not sure if that's better or not
[07:30:17 CEST] <atomnuker> shnsplit doesn't support tta
[07:31:13 CEST] <atomnuker> its alright, cue files don't offer sample precise offsets
[07:31:44 CEST] <atomnuker> so however you split them they'll be imprecise
[07:32:05 CEST] <rcombs> frame-precise, though (588 samples)
[07:32:17 CEST] <rcombs> and it's as precise as the CD itself gets, right?
[07:32:53 CEST] <atomnuker> well CD tracks are segmented into frames of 2100ish bytes
[07:33:23 CEST] <rcombs> 75 frames per second
[07:33:23 CEST] <atomnuker> I guess that's actually more precise than CD frames themselves
[07:33:35 CEST] <atomnuker> or less, no idea
[08:11:26 CEST] <atomnuker> rcombs: got any idea how to test your patches?
[08:12:57 CEST] <atomnuker> I'm writing an image packet with a separate stream index with the lavf API but nothing seems to happen
[08:14:43 CEST] <rcombs> specifically trying to test the FLAC attachment support, then?
[08:15:00 CEST] <atomnuker> https://github.com/atomnuker/cyanrip/blob/master/src/cyanrip_encode.c#L226
[08:15:14 CEST] <atomnuker> yep
[08:16:05 CEST] <rcombs> pkt->stream_index = 0; <-- don't you want 1?
[08:16:47 CEST] <rcombs> also, fmt->video_codec is meant to be immutable
[08:16:49 CEST] <atomnuker> (btw the cue demuxer seems to work fine)
[08:17:07 CEST] <rcombs> you should configure st_img->codecpar instead
[08:17:26 CEST] <atomnuker> but that would mean configuring an encoder as well, no?
[08:17:33 CEST] <atomnuker> (I don't want to encode, just mux)
[08:17:49 CEST] <rcombs> no
[08:18:03 CEST] <rcombs> codecpar is independent from actual encoders
[08:18:30 CEST] <rcombs> and I _think_ what you want to do here is set st_img->attached_pic before calling write_header
[08:18:57 CEST] <rcombs> rather than calling av_interleaved_write_frame for the attachment yourself
[08:19:02 CEST] <rcombs> lavf will do it for you
[08:19:10 CEST] <rcombs> make sure to set the stream disposition as well
[08:19:33 CEST] <rcombs> welp
[08:20:09 CEST] <rcombs> atomnuker: what was the last line you caught of that
[08:20:25 CEST] <atomnuker> "rcombs | codecpar is independent from actual encoders"
[08:20:35 CEST] <rcombs> <rcombs> and I _think_ what you want to do here is set st_img->attached_pic before calling write_header
[08:20:35 CEST] <rcombs> <rcombs> rather than calling av_interleaved_write_frame for the attachment yourself
[08:20:35 CEST] <rcombs> <rcombs> lavf will do it for you
[08:20:35 CEST] <rcombs> <rcombs> make sure to set the stream disposition as well
[08:21:52 CEST] <atomnuker> but for encoding attached_pic in AVStream is listed as unused
[08:22:08 CEST] <atomnuker> I also checked and its not used anywhere thoughout the muxers
[08:22:20 CEST] <atomnuker> (or does your patch change that?)
[08:22:26 CEST] <rcombs> oh derp, you're right
[08:22:36 CEST] <rcombs> yeah, I was looking at the wrong code
[08:22:56 CEST] <atomnuker> how do I initialize codecpar?
[08:23:15 CEST] <rcombs> st_img->codecpar->codec_id = <&>
[08:23:19 CEST] <rcombs> that might be all you need
[08:23:43 CEST] <rcombs> then set the disposition and make sure you get the stream index right
[08:26:26 CEST] <atomnuker> nope, not getting a thing
[08:27:01 CEST] <atomnuker> I don't think st_img is registered properly if there's such a thing
[08:28:04 CEST] <rcombs> nothing in the log?
[08:28:39 CEST] <rcombs> also, you don't need to set nb_streams; avformat_new_stream does that
[08:28:44 CEST] <atomnuker> av_dump_format doesn't print anything to suggest there's another stream
[08:29:44 CEST] <rcombs> oh, and you should set codecpar->codec_type = AVMEDIA_TYPE_VIDEO
[08:31:33 CEST] <rcombs> you can do ffmpeg -i input.flac -c copy output.flac and see it works
[08:31:42 CEST] <rcombs> (for an input file with an attached picture)
[08:32:13 CEST] <atomnuker> that's odd, dumping stream index 1 prints the same as stream index 0 (audio, flac, etc.)
[08:33:02 CEST] <atomnuker> yep, that works
[08:33:16 CEST] <rcombs> hmm? dumping a particular stream?
[08:33:30 CEST] <rcombs> afaik there's no public function for that
[08:33:32 CEST] <atomnuker> av_dump_format(avf, 1, filename, 1); instead of av_dump_format(avf, 0, filename, 1);
[08:33:56 CEST] <rcombs> the second arg is a file index, not a stream index
[08:34:01 CEST] <rcombs> it's just used in the string output
[08:34:17 CEST] <rcombs> for things like "#<file index>:<stream index>"
[08:37:28 CEST] <atomnuker> updated the file
[08:40:50 CEST] <atomnuker> when using ffmpeg.c and copying stream index 0 on the input is audio but on the output stream index 0 is video
[08:43:53 CEST] <atomnuker> swapping the stream indices here though causes "Invalid packet stream index: 1" to be printed
[08:55:41 CEST] <atomnuker> rcombs: what's also odd is writing to st->metadata doesn't write anything at all on the output
[09:36:13 CEST] <trapp> Hi! Just wantes to push a patch but SSH reports a changed RSA host key for source.ffmpeg.org . Can someone confirm that this is to be expected?
[09:36:13 CEST] <trapp> The fingerprint for the new RSA key is SHA256:KVBtJbvfrNcF+McexrkKdLtPNr+37PXjOUnRuGcqwJo.
[09:40:22 CEST] <wm4> I know it changed a few days or weeks before and it was expected
[09:48:00 CEST] <JEEB> weeks, but yea. if you want to double-check with someone I think thresh from #videolan is the one maintaining those boxes
[10:05:24 CEST] <trapp> Yes, it's been some weeks since my last commit. Thanks.
[10:09:48 CEST] <cone-453> ffmpeg 03Tobias Rapp 07master:78f51ecb7411: tests/fate/fifo-muxer: update fifo-muxer dependencies
[10:54:56 CEST] <ubitux> http://boxbase.org/entries/2017/may/8/optimizing_lever_png/
[10:59:15 CEST] <wm4> ubitux: "the fuck"
[10:59:34 CEST] <kierank> wm4: +1
[11:00:03 CEST] <wm4> also it's missing a conclusion
[11:00:08 CEST] <wm4> how fast did he get it?
[11:00:19 CEST] <thardin> nice glitch
[11:04:31 CEST] <thardin> vectorizing png decoding sounds a bit tricky
[11:08:44 CEST] <ubitux> i learned one thing: "layout asm" in gdb
[11:08:59 CEST] <ubitux> i'll be sure to use it next time
[12:35:37 CEST] <cone-453> ffmpeg 03Michael Niedermayer 07master:1e42736b9506: avcodec/cdxl: Check format for BGR24
[12:35:38 CEST] <cone-453> ffmpeg 03Michael Niedermayer 07master:279420b5a63b: avcodec/cavsdec: Check sym_factor
[12:35:39 CEST] <cone-453> ffmpeg 03Michael Niedermayer 07master:5d5118f81bd5: avcodec/hqxdsp: Fix multiple runtime error: signed integer overflow: 248220 * 21407 cannot be represented in type 'int' in idct_col()
[12:35:40 CEST] <cone-453> ffmpeg 03Michael Niedermayer 07master:8824b7370a9f: avcodec/vp8dsp: Fixes: runtime error: signed integer overflow: 1330143360 - -1023040530 cannot be represented in type 'int'
[12:59:01 CEST] <kierank> BBB: J_Darnley is going to be working on mpeg-2 asm conversion over the next few weeks
[13:23:21 CEST] <wm4> inline asm -> yasm?
[13:23:24 CEST] <wm4> or nasm
[13:23:29 CEST] <wm4> since yasm is dead
[13:24:55 CEST] <JEEB> yea, nasm changed license and yasm-ng isn't gonna become reality
[13:25:09 CEST] <JEEB> so, uh, yasm effectively accomplished its mission
[13:25:16 CEST] <JEEB> by becoming unneeded
[13:25:40 CEST] <nevcairiel> its practically the same syntax anyway
[13:33:47 CEST] <iive> isn't yasm a fork of nasm?
[13:36:26 CEST] <nevcairiel> its a rewrite
[13:37:43 CEST] <BBB> kierank: thats amazing
[13:38:02 CEST] <kierank> wm4: yes
[13:38:07 CEST] <BBB> vp8dsp?
[13:38:11 CEST] <kierank> BBB: are you able to help J_Darnley from time to time
[13:38:14 CEST] <BBB> michaelni: is that patch on the ML?
[13:38:17 CEST] <BBB> kierank: of course
[13:38:46 CEST] <BBB> michaelni: please send patches to vp8 to the ML, I still maintain and review that
[13:42:26 CEST] <michaelni> BBB do you also want to review webp ? (as its using vp8)
[13:42:46 CEST] <BBB> I can look, but I dont necessarily care for it as much ;)
[13:50:30 CEST] <BBB> michaelni: the above patch looks OK, I think C is clunky there but what can you do
[14:22:10 CEST] <J_Darnley> I will start with the functions in simple_idct.c
[14:24:11 CEST] <kierank> ok
[14:27:42 CEST] <J_Darnley> I think I can get the syntax all turned around today and have a nasm mmx version working tomorrow
[14:28:05 CEST] <kierank> nice
[14:30:31 CEST] <wm4> so we will untangle mpegvideo?
[14:30:38 CEST] <wm4> or is it just asm
[14:30:55 CEST] <J_Darnley> Just asm, inline -> nasm right now
[14:32:08 CEST] <Compn> untangle mpegvideo? it will only become angry...
[14:32:09 CEST] <Compn> ehe
[14:32:12 CEST] <BBB> J_Darnley: Ive looked at some of that stuff
[14:32:30 CEST] <BBB> J_Darnley: I think if you simply convert without adding anything new (so ignore sse2 etc. for now), you should be OK
[14:32:42 CEST] <BBB> J_Darnley: if you want to make it pretty, you will cry
[14:32:47 CEST] <J_Darnley> :)
[14:32:51 CEST] <BBB> J_Darnley: but thanks so much for doing this
[14:33:11 CEST] <BBB> I think weve had multiple people work on aspects of inline->nasm conversion and its nice to see someone picking it up again
[14:33:20 CEST] <J_Darnley> Hey, I'd sell my organs for money
[14:33:24 CEST] <BBB> ...
[14:33:26 CEST] <BBB> dont do that
[14:33:35 CEST] <Compn> i'd buy your brain, $15
[14:34:04 CEST] <nevcairiel> what other major components are still inline asm?
[14:37:03 CEST] <J_Darnley> A quick glance at `git grep HAVE_INLINE_ASM -- libavcodec/x86` suggests: old video stuff (mpeg), obscure video stuff (lossless and now), h264 cabac, vc1, vp 5 6
[14:37:25 CEST] <J_Darnley> *lossless and _snow_
[14:37:52 CEST] <J_Darnley> There's more inline assembly on other platforms
[14:38:02 CEST] <nevcairiel> cabac is actual inline asm
[14:38:30 CEST] <nevcairiel> ie. its mixed with C code all over
[14:39:47 CEST] <J_Darnley> yeah, I don't think it is a candidate for being moved to nasm.
[14:39:54 CEST] <J_Darnley> ever
[14:41:16 CEST] <nevcairiel> someone should totally write much faster cabac code
[14:44:03 CEST] <BBB> I think mpegvideo and vc1/vp56 are the interesting ones
[14:44:13 CEST] <BBB> obscure video isnt very interesting
[14:44:17 CEST] <BBB> (IMO)
[14:46:15 CEST] <iive> nevcairiel: is it possible to be faster?
[14:46:26 CEST] <BBB> oh vp56 is also arithmetic coding
[14:46:29 CEST] <BBB> so ignore that one also
[14:46:39 CEST] <BBB> its just the vc1 subpel MC and old mpegvideo stuff
[14:46:48 CEST] <BBB> the vc1 isnt terribly interesting but would be nice to convert
[14:47:04 CEST] <BBB> the mpegvideo is the only remaining one, but I think most people stopped caring because mpegvideo is old
[14:47:22 CEST] <BBB> (it was interesting before the h264/mpeg split, but after that people lost interest, at least I did)
[14:52:16 CEST] <kierank> faster cabac would be interesting but hard i guess
[14:52:48 CEST] <nevcairiel> cabac isnt simd, so from an optimization stand-point it requires quite a different approach then what we usually do with asm
[15:02:01 CEST] <wm4> ubitux: what's the deprecated "srt" decoder for?=
[15:02:58 CEST] <ubitux> it's the format where you have timestamps in the packet payload
[15:03:16 CEST] <nevcairiel> speaking of entropy coding, did av1 officially adopt the ANS entropy coding in favor of vp9s entropy coder?
[15:04:22 CEST] <BBB> oh
[15:04:31 CEST] <BBB> J_Darnley: snowdsp also (it doesnt use INLINE_MMX/etc. macros)
[15:06:56 CEST] <BBB> (and fdct, cavs)
[15:08:40 CEST] <atomnuker> nevcairiel: nope, the daala one was accepted
[15:09:09 CEST] <nevcairiel> which one was that?
[15:09:39 CEST] <atomnuker> the opus one which forgoes integer division and uses shifts
[15:09:43 CEST] <wm4> ubitux: yeah, but the decoder is obviously not different
[15:10:22 CEST] <ubitux> wm4: the decoder only supports SUBRIP now
[15:10:32 CEST] <ubitux> it's just a legacy to have an alias srt/subrip
[15:10:50 CEST] <ubitux> but CODEC_ID_SRT is no longer supported yes
[15:11:13 CEST] <ubitux> srt could be dropped i suppose
[15:11:15 CEST] <J_Darnley> BBB: I might have missed others because I only searched for HAVE_INLINE_ASM
[15:15:38 CEST] <j-b> BtbN: everything is back to normal, accoridng to the graphs
[15:17:47 CEST] <j-b> BtbN: but we have a weird attack on another server
[15:18:12 CEST] <BtbN> weird, so is it actually trying to do a small scale DDoS or something?
[15:18:33 CEST] <j-b> BtbN: I cannot say yet.
[15:20:10 CEST] <j-b> BtbN: but I'm happy about our security and splitting each service in a lxc
[16:06:42 CEST] <J_Darnley> Memeory arguments in __asm__ blocks all have byte offsets, right?
[16:07:02 CEST] <cone-705> ffmpeg 03Michael Niedermayer 07master:0075d9eced22: avcodec/dvbsubdec: check region dimensions
[16:07:02 CEST] <cone-705> ffmpeg 03Michael Niedermayer 07master:ea59ef0c031b: avcodec/dss_sp: Fix multiple runtime error: signed integer overflow: -15699 * -164039 cannot be represented in type 'int'
[16:07:02 CEST] <cone-705> ffmpeg 03Michael Niedermayer 07master:29692023b2f1: avcodec/bmvvideo: Fix runtime error: left shift of 137 by 24 places cannot be represented in type 'int'
[16:17:49 CEST] <Tomaz^W> Quick question, is there an issue with the ffmpeg configure script and using openssl-1.1.0c?
[16:18:22 CEST] <J_Darnley> quick answer: no idea
[16:18:26 CEST] <Tomaz^W> Since there is no SSL_library_init anymore in 1.1.0_
[16:22:22 CEST] <nevcairiel> configure should support both 1.0 and 1.1, using 1.1 will likely make using pkg-config mandatory though
[16:22:23 CEST] <jamrial> it's first checking for OPENSSL_init_ssl
[16:22:45 CEST] <BtbN> openssl 1.1 compat was merged last year
[16:22:52 CEST] <BtbN> if you're using some old release, it's time to update.
[16:23:37 CEST] <BtbN> nevcairiel, to me configure looks like pkg-config alreads is mandatory for OpenSSL 1.1
[16:23:57 CEST] <Tomaz^W> Using 3.3
[16:23:57 CEST] <BtbN> all the non-pkg-config checks look for the old symbol
[16:25:08 CEST] <BtbN> 3.3 has that.
[16:25:18 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/n3.3/configure#L5918
[16:25:35 CEST] <Tomaz^W> Am using non-pkg-config tho
[16:25:44 CEST] <nevcairiel> time to use pkg-config
[16:25:47 CEST] <BtbN> pkg-config is mandatory for 1.1
[16:25:56 CEST] <cone-705> ffmpeg 03James Almer 07master:74fee9760f7a: configure: add missing lpc dependency to mlp and truehd encoders
[16:49:31 CEST] <cone-705> ffmpeg 03James Almer 07master:2cb656ad1197: avcodec/mjpegenc: move ff_mjpeg_encode_picture_frame to mjpegenc_common
[17:03:42 CEST] <cone-705> ffmpeg 03Michael Niedermayer 07master:aaeec1c654a2: avcodec/wavpack: Fix signed integer overflow: 1285114081 * 2 cannot be represented in type 'int'
[17:03:43 CEST] <cone-705> ffmpeg 03Michael Niedermayer 07master:f4ae3cce64bd: avcodec/htmlsubtitles: Check for string truncation and return error
[17:03:44 CEST] <cone-705> ffmpeg 03Michael Niedermayer 07master:983e3fbcc5c9: avcodec/samidec: Check ff_htmlmarkup_to_ass() return code
[17:03:45 CEST] <cone-705> ffmpeg 03Michael Niedermayer 07master:7b94df232a4b: avcodec/srtdec: Check ff_htmlmarkup_to_ass() return code
[17:03:46 CEST] <cone-705> ffmpeg 03Michael Niedermayer 07master:8ef2c791c99e: doc/build_system: Document how to build decoder fuzzer
[17:50:10 CEST] <jamrial> ubitux: https://github.com/jamrial/FFmpeg/commits/mergework
[17:50:28 CEST] <ubitux> ooh
[17:50:37 CEST] <jamrial> h264 didn't merge cleanly, as usual, but it passes fate
[17:50:49 CEST] <jamrial> i changed size_t to unsigned. not sure if wm4 will agree :p
[17:50:50 CEST] <ubitux> did you figure out a way of rebasing all the merges?
[17:51:20 CEST] <jamrial> no, i just reapply them when i need to rebase
[17:51:40 CEST] <ubitux> how do you deal with the conflicts?
[17:51:54 CEST] <nevcairiel> in many cases rerere can do magic
[17:53:19 CEST] <jamrial> ubitux: when i first merge something i solve the conflicts the usual way. then if i need to rebase, i remerge with -s ours then apply the already cleaned changes i stashed somewhere else
[17:53:27 CEST] <jamrial> kinda archaic, but works :p
[17:53:34 CEST] <jamrial> i thought you had a script to rebase merges
[17:54:14 CEST] <ubitux> it's a semi scripts, but it doesn't work well with delete/moves
[17:54:39 CEST] <ubitux> nevcairiel: i should probably learn how to use that
[17:54:46 CEST] <ubitux> anyway.
[17:55:07 CEST] <ubitux> jamrial: which commits/merge are the sensible ones?
[17:55:44 CEST] <jamrial> the h264 ones, since those didn't apply cleanly. then we need to decide if we keep the fields as size_t like libav, of make them unsigned like i did there
[17:59:18 CEST] <wm4> jamrial: the crop params? well as I wrote in those mailing list discussions, I think it'd be better not to have such differences to Libav
[18:00:02 CEST] <jamrial> wm4: size_t then? pity you couldn't convince them to switch to unsigned
[18:00:36 CEST] <jamrial> size_t is kinda silly when they make sure all the calculated values are < INT_MAX, but whatever
[18:00:49 CEST] <wm4> yeah, I agree
[18:01:36 CEST] <wm4> they probably plan on changing other size quantities to size_t or similar too, so we'll get years of inconsistencies
[18:02:45 CEST] <jamrial> i don't get the whole "they are sizes, so use size_t"
[18:02:56 CEST] <jamrial> they are video dimensions, and are not system dependant
[18:04:29 CEST] <wm4> indeed
[18:05:22 CEST] <j-b> size_t is for the stuff that can be returned by sizeof, not for every size that exists in real life...
[18:05:27 CEST] <wm4> even in theory int is pretty sufficient, because an image using INT_MAX dimensions would require a memory allocation near INT64_MAX size
[18:06:36 CEST] <wm4> what I'd rather see would be removing the image size restriction of ~16000x16000 (or whatever it was)
[18:06:47 CEST] <wm4> which actually triggers in real life
[18:07:05 CEST] <wm4> but for crop dimensions, especially if width/height are still int, it seems ridiculous to me
[18:11:26 CEST] <ubitux> if you want a portable code between the two projects you can still always cast to int
[18:12:34 CEST] <ubitux> size_t for this doesn't make much sense
[18:15:12 CEST] <BBB> wm4: wasnt that limit introduced so michaelnis fuzzing experiments go faster?
[18:15:53 CEST] <wm4> BBB: AFAIK not? the image size limit is merely supposed to avoid int overflows when addressing pixels
[18:16:04 CEST] <BBB> hm...
[18:16:18 CEST] <BBB> but 1<<31 is much bigger than 16kx16k?
[18:16:46 CEST] <wm4> I'm referring to av_image_check_size
[18:19:09 CEST] <wm4> so when you do e.g. AVFrame.data[0] + AVFrame.linesize[0] * (int)x you could get an overflow if x and linesize are large
[18:19:19 CEST] <wm4> err that would be y, but whatever
[18:21:15 CEST] <nevcairiel> it like accounts for the worst possible cases
[18:21:24 CEST] <nevcairiel> like, 8 byte per pixel and whatnot
[18:21:29 CEST] <nevcairiel> or even more these days
[18:21:48 CEST] <ubitux> jamrial: you kept offsets[] in size_t?
[18:21:55 CEST] <BtbN> so nvenc on Linux gained OpenGL texture input support
[18:23:50 CEST] <wm4> BtbN: seems odd
[18:24:13 CEST] <wm4> given that opengl is pretty useless for image processing and icky as an API
[18:24:27 CEST] <BtbN> Probably aimed at live-encoding games and stuff
[18:24:41 CEST] <wm4> that on the other hand makes sense
[18:24:41 CEST] <nevcairiel> likely
[18:24:55 CEST] <wm4> but wouldn't they normally use cuda/opencl interop instead?
[18:25:10 CEST] <BtbN> Well, they don't need to anymore now
[18:25:25 CEST] <BtbN> Maybe they'll actually add OpenGL texture output support to nvdec, then it'd suddenly be a vdpau replacement candidate.
[18:25:47 CEST] <wm4> nvdec=cuvid?
[18:25:51 CEST] <BtbN> yes
[18:25:55 CEST] <nevcairiel> yeah they renamed it
[18:26:03 CEST] <wm4> doesn't that work already (just a bit awkward)
[18:26:16 CEST] <BtbN> By using tons of non-free cuda functions, yes
[18:26:29 CEST] <nevcairiel> 5) Decode capability API
[18:26:30 CEST] <nevcairiel> 6) Decode latency reduction
[18:26:34 CEST] <nevcairiel> i wonder what that means
[18:26:42 CEST] <nevcairiel> i should diff the headers later
[18:26:45 CEST] <BtbN> similar capability API like nvenc has
[18:27:11 CEST] <wm4> I wonder of Libav's attempt of using cuvid as hwaccel will result in anything
[18:29:33 CEST] <jamrial> ubitux: ah yeah, missed that
[18:30:22 CEST] <jamrial> in any case, i'll change the fields back to size_t, so that should be ok
[18:30:52 CEST] <jamrial> want me to force push that change to my repo?
[18:31:39 CEST] <ubitux> i was just curious
[18:35:45 CEST] <ubitux> i hope the cropping checks are sane
[18:36:11 CEST] <ubitux> especially given the unsigned property of the cropping values often mismatching with the signdness of width/height
[18:36:45 CEST] <ubitux> i suppose you checked that we didn't have more advanced checks on these
[18:37:13 CEST] <jamrial> we did in h264's case i think
[18:38:43 CEST] <jamrial> no, it was hevc. a cast to int64_t which i replaced with the new code in the merge
[18:49:15 CEST] <ubitux> i don't see anything special to comment on
[18:50:32 CEST] <BtbN> nevcairiel, pushed the updated headers to my github clone.
[18:51:01 CEST] <nevcairiel> BtbN: i'm signed up for designworks or whatever one needed anyway
[18:51:18 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/3d273dded7789318bbbe08462694322f4ddd5… this looks interesting. I have no clue what a CUstream is, but a raw_output_dptr looks primising. Might save the extra memcpy?
[18:52:27 CEST] <nevcairiel> they always had some incomplete API for processing raw YUV images through the nvdec processing pipeline, but it was never really functional
[18:52:30 CEST] <nevcairiel> maybe they fixed it
[18:52:45 CEST] <BtbN> it's at least no longer documented as "do not use"
[18:53:08 CEST] <BtbN> but I have a hard time finding documentation for that API
[18:53:30 CEST] <BtbN> Decoding capability API, "NVDECODE API to query hardware capabilities"
[18:53:37 CEST] <BtbN> Nowhere to be found in the updated headers though?
[18:53:51 CEST] <nevcairiel> tcuvidGetDecoderCaps ?
[18:53:54 CEST] <nevcairiel> seems to be there
[18:54:07 CEST] <BtbN> oh, indeed. blind
[18:54:33 CEST] <BtbN> that should be able to resolve that horrible "try to create a dummy decoder to see if it works" hack
[18:54:57 CEST] <wm4> how do you get a diff from the github patch view
[18:55:16 CEST] <wm4> because it only shows a dumb loading animation instead of all the changes
[18:55:18 CEST] <jamrial> wm4: append .patch to the url of the commit you're viewing
[18:55:24 CEST] <wm4> jamrial: does nothing
[18:55:41 CEST] <nevcairiel> https://github.com/BtbN/FFmpeg/commit/3d273dded7789318bbbe08462694322f4ddd5… ? works for me
[18:55:44 CEST] <jamrial> it does for me, gives me a raw text patch
[18:55:57 CEST] <nevcairiel> have to strip out the anchor link
[18:56:04 CEST] <wm4> opening this link worked
[18:56:14 CEST] <wm4> appending it to the address in firefox didn't
[18:56:16 CEST] <wm4> wtf
[18:56:34 CEST] <BtbN> .patch or .diff
[18:56:35 CEST] <wm4> I should leave tech and start gardening or so
[18:56:39 CEST] <BtbN> .diff is more human readable iirc
[18:56:58 CEST] <wm4> nevcairiel: ah, maybe it was the anchor
[18:57:11 CEST] <jamrial> mmh, weird, for merge commits it gives me the libav commit instead of the merge commit
[18:57:19 CEST] <jamrial> see for example https://github.com/jamrial/FFmpeg/commit/1d530860afa1c4e2ff59e7081ab418c68e…
[18:57:23 CEST] <BtbN> github is kinda broken with merges
[18:57:30 CEST] <nevcairiel> for merges its kinda useless
[18:57:44 CEST] <jamrial> yeah
[18:57:48 CEST] <nevcairiel> lets see if the new headers work out of the box in my code
[18:57:57 CEST] <nevcairiel> been a while since i touched cuvid code
[18:58:17 CEST] <BtbN> The ffmpeg header copies are slightly modified
[18:58:22 CEST] <BtbN> I think I got the update right though
[18:59:18 CEST] <nevcairiel> only had to remove some include line that doesnt exist for the d3d9 interop
[18:59:36 CEST] <BtbN> huh? That was never there in the first place for me
[18:59:41 CEST] <nevcairiel> d3dx is deprecated, someone tell nvidia =p
[18:59:42 CEST] <BtbN> which header?
[18:59:47 CEST] <nevcairiel> dynlink_cuda_d3d.h
[18:59:59 CEST] <BtbN> ah, yeah, not using those
[19:00:09 CEST] <jamrial> think you can fix the LOAD_SYMBOL warning spam from compat/cuda/dynlink_loader.h while at it?
[19:00:19 CEST] <BtbN> jamrial, I tried, it's MSVC being dumb
[19:00:28 CEST] <BtbN> gcc is perfectly happy with that.
[19:00:32 CEST] <jamrial> i'm getting it with mingw-w64
[19:00:37 CEST] <BtbN> really?
[19:00:43 CEST] <BtbN> I'll look at it again
[19:00:51 CEST] <jamrial> yeah
[19:01:09 CEST] <jamrial> i define _WIN32_WINNT=0x0602 when compiling, though
[19:01:19 CEST] <jamrial> maybe that's related
[19:04:37 CEST] <BtbN> I'll try a normal x86_64-w64-mingw32-gcc build
[19:05:34 CEST] <jamrial> i'm using the one provided by msys2 package manager. didn't try one of nevcairiel's builds or one of my own
[19:06:20 CEST] <BtbN> I'm using the one cygwin installed for me
[19:06:22 CEST] <BtbN> gcc 5.4
[19:06:40 CEST] <jamrial> http://fate.ffmpeg.org/log.cgi?time=20170508104153&log=compile&slot=x86_64-… nevcairiel's also show this
[19:08:10 CEST] <BtbN> I like how configure takes longer than actually building
[19:08:36 CEST] <jamrial> http://fate.ffmpeg.org/log.cgi?time=20170506184511&log=compile&slot=x86_64-… this old version as well, but is much less spammy about it
[19:09:36 CEST] <BtbN> Can I just cast the destination and source pointer to void*, and be done?
[19:10:32 CEST] <BtbN> This would be easy in C++, but no clue how to solve this in C
[19:26:08 CEST] <BtbN> gnu c has typeof()
[19:26:10 CEST] <BtbN> but MSVC doesn'T
[19:26:16 CEST] <BtbN> so manually enumerating all types it is...
[19:26:37 CEST] <jamrial> try __typeof__
[19:26:48 CEST] <jamrial> no wait, nevermind
[19:27:13 CEST] <BtbN> It should work on all compilers
[19:30:16 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/a455fa1f2345118e4c91b289137b0912333cd… that should silence them
[19:30:30 CEST] <BtbN> not pretty, but I can't think of any other solution
[19:36:25 CEST] <jamrial> ubitux: pushed a version using size_t to my repo
[19:39:01 CEST] <jamrial> michaelni: want to look at https://github.com/jamrial/FFmpeg/commits/mergework ? h264/hevc/theora custom cropping code replaced by generic code in decode.c using new avframe fields
[19:40:59 CEST] <uau> jamrial: why does gcc warn about assignment from void *?
[19:41:17 CEST] <jamrial> if you mean cuda, i don't know
[19:42:49 CEST] <durandal_1707> what is instruction to load every 2nd float in m0?
[19:43:05 CEST] <uau> does it warn about mixing void * and function types on windows? or is that not void * on windows?
[19:43:17 CEST] <durandal_1707> im writting simd for afir complex multiplication and add
[19:43:49 CEST] <BtbN> uau, FARPROC is not a void*, and can't be assigned to a function pointer without cast
[19:43:55 CEST] <BtbN> at least not without a warning
[19:45:09 CEST] <uau> is that what dlsym returns on windows?
[19:45:40 CEST] <BtbN> It's what GetProcAddress returns
[19:45:52 CEST] <BtbN> dlsym is just a convenience rename
[19:46:27 CEST] <jamrial> durandal_1707: what do you mean load every 2nd float? and from memory to m0, or from m0 to something else?
[19:47:14 CEST] <durandal_1707> from memory and do the reverse
[19:47:53 CEST] <durandal_1707> real component is every 2nd element in an array
[19:48:34 CEST] <durandal_1707> imaginary is 2 *n +1
[19:49:14 CEST] <jamrial> mmh, with avx2/avx512 you have gather/scatter, but with older sets you'll have to load everything and do shuffles i think
[19:51:49 CEST] <BtbN> philipl, https://github.com/BtbN/FFmpeg can you give this a test? Works on both my nvidia boxes.
[19:57:50 CEST] <philipl> I'll test tonight.
[20:02:25 CEST] <philipl> BtbN: GetDecoderCaps. How nice
[20:02:53 CEST] <BtbN> Haven't adapted to the new API yet, only removed some deprecated fields from nvenc
[20:02:59 CEST] <BtbN> They also deprecated all the old preset names
[20:03:06 CEST] <BtbN> they are not calling it twopass anymore
[20:03:16 CEST] <BtbN> *rc mode names
[20:09:37 CEST] <BtbN> haha, the nvidia ffmpeg usage guide already has an entry for ffmpeg 3.4 using Video Codec SDK 8.0
[20:10:07 CEST] <BBB> michaelni: https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.ht… you should apply for one of these prizes
[20:21:04 CEST] <michaelni> BBB, IIUC we already received the initial price on ffmpeg-spi. Do we qualify already for more ?
[20:21:35 CEST] <BBB> michaelni: no idea, Im not keeping track, just saying you did a lot of work on that and it looks like some of these conditions were met, but not sure
[20:21:39 CEST] <nevcairiel> i wonder if i should use getdecodercaps, i basically just create a decoder anyway and keep using that decoder instance as appropriate, not sure it would make my live that much better
[20:23:29 CEST] <michaelni> jamrial, can you post this to the ML so everyone can comment ?
[20:25:57 CEST] <jamrial> michaelni: alright
[20:37:44 CEST] <durandal_1707> jamrial: what to use fo shuffle then?
[20:38:58 CEST] <atomnuker> some unpacking/packing instruction (pshufb is slower compared to them)
[20:39:48 CEST] <jamrial> shufps, unpck[lh]ps, and/or vpermps with avx2
[20:40:57 CEST] <BtbN> nevcairiel, it doesn't seem overly useful for ffmpeg as well, as we basically don't know things like the bit depth until it's way too late anyway
[20:44:17 CEST] <philipl> BtbN: So they remain completely vague on which GPUs can decode vp9 10/12bit, but I assume it'll turn out to be GP107 (1050) only.
[20:44:20 CEST] <philipl> Sad.
[20:44:27 CEST] <philipl> And apparently they threw out vp8 after GP104
[20:44:57 CEST] <durandal_1707> jamrial: what to use for last arg?
[20:45:14 CEST] <BtbN> I just ordered a 1050
[20:45:17 CEST] <BtbN> so I'll see
[20:45:26 CEST] <BtbN> Also curious what the 1030 will be able to do
[20:45:29 CEST] <philipl> If it turns out to be 1050 only I'll probably get one too - they're cheap enough
[20:45:32 CEST] <philipl> Is 1030 announced?
[20:45:35 CEST] <BtbN> yes
[20:45:57 CEST] <philipl> Then I'll get one of those. Only want it for vp9 testing
[20:46:17 CEST] <BtbN> The difference in price is like 30¬, so I didn't bother waiting for it
[20:47:12 CEST] <cone-705> ffmpeg 03Anton Khirnov 07master:52627248e49e: frame: add a cropping rectangle to AVFrame
[20:47:13 CEST] <cone-705> ffmpeg 03Anton Khirnov 07master:019ab88a95cb: lavc: add an option for exporting cropping information to the caller
[20:47:14 CEST] <cone-705> ffmpeg 03James Almer 07master:a47bd5d77e3f: Merge commit '52627248e49e58eb4b78e4fcda90a64f4c476ea3'
[20:47:15 CEST] <cone-705> ffmpeg 03James Almer 07master:f089e02fa2b7: Merge commit '019ab88a95cb31b698506d90e8ce56695a7f1cc5'
[20:47:26 CEST] <philipl> Fair. Well, first I need to check with the latest drivers and sdk and see what GetDecoderCaps says for my 1080
[20:47:41 CEST] <philipl> but I fully expect disappointment.
[20:51:16 CEST] <BtbN> philipl, the new caps thing seems completely useless. You have to specify the bit depth as input parameter
[20:51:20 CEST] <nevcairiel> vp9 10bit no worky on my 1080 or 1060, too bad, nvidia rep once said that a 1060 might be able to
[20:51:24 CEST] <BtbN> so you basically have to call it 3 times to query all of them
[20:51:43 CEST] <philipl> fun
[20:53:19 CEST] <BtbN> Or do the container parsers give you information about that?
[20:53:51 CEST] <nevcairiel> they can, but there is no guarantee
[20:58:48 CEST] <michaelni> jamrial, i meant the API changes shoud be posted to the ML, i doubt theres much interrest in the implementation changes
[20:59:13 CEST] <jamrial> michaelni: i posted the patches that could introduce regressions in h264/hevc
[20:59:54 CEST] <jamrial> that's what i said i would in the ml thread a week or so ago
[21:08:13 CEST] <philipl> BtbN: ffmpeg -y -vsync 0 -hwaccel cuvid -c:v h264_cuvid -i input.mp4 -c:a
[21:08:13 CEST] <philipl> copy -c:v h264_nvenc -preset slow -profile high -b:v 5M -bufsize 5M -
[21:08:13 CEST] <philipl> maxrate 10M -qmin 0 -g 250 -bf 2 -temporal-aq 1 -rc-lookahead 20 -
[21:08:13 CEST] <philipl> i_qfactor 0.75 -b_qfactor 1.1 output.mp4
[21:08:23 CEST] <philipl> Maybe they fixed the b-frames bug in the driver
[21:08:31 CEST] <BtbN> nope
[21:08:32 CEST] <philipl> That's their example usage
[21:08:37 CEST] <BtbN> Doesn't work for me
[21:08:40 CEST] <philipl> hah.
[21:09:05 CEST] <BtbN> they don't specify -bf, so it's not using bframes to begin with
[21:11:21 CEST] <philipl> It's on that command line
[21:54:16 CEST] <BtbN> dafuq, after updating the cuvid headers, msvc just hogs all available RAM(So, 32GB), and never finishes building cuvid.c
[21:54:29 CEST] <BtbN> cl.exe to be precise
[23:01:07 CEST] <philipl> BtbN: shit's special.
[23:02:12 CEST] <BtbN> Only happened once, builts fine now
[23:50:49 CEST] <alevinsn> jkqxz: are you planning to apply the two qsv patches I submitted? I took the patches you had on your Web site
[23:51:07 CEST] <alevinsn> applied them, and then I generated new patches with altered text--code wasn't changed at all
[00:00:00 CEST] --- Tue May 9 2017
1
0
[00:00:33 CEST] <faLUCE> just checked that avformat_open_input returns OK even if I don't give enough bytes to it
[00:04:21 CEST] <faLUCE> this is really bad. The API doesn't provide a normal/simple way to feed the muxer with arrays without blocking
[05:58:27 CEST] <kinkinkijkin> is there a vapoursynth plugin to facilitate detecting artifacts generated by functions in the current filter, and trying to correct them?
[06:02:10 CEST] <kinkinkijkin> maybe I should ask this again during active hours lol
[07:14:38 CEST] <james999> well furq is in the UK
[07:14:50 CEST] <james999> so in a few hours maybe they will be active over there.
[07:15:26 CEST] <james999> I hear Jeremy Corbyn is gonna try and be next prime minister
[07:15:59 CEST] <james999> he's like if you took bernie sanders and simply swapped one affected accent for another. :D
[07:16:53 CEST] <furq> except people actually like bernie sanders
[07:20:04 CEST] <dystopia_> labour is kinda dead atm :(
[07:20:28 CEST] <dystopia_> there is no party of opposition
[07:21:39 CEST] <furq> strong and stable
[07:24:22 CEST] <kinkinkijkin> I figured out how to remove the artifacts
[07:24:27 CEST] <kinkinkijkin> reduce blocksize
[07:24:57 CEST] <kinkinkijkin> aka "might as well just do a static reencode" levels of CPU usage and desync
[07:26:56 CEST] <james999> furq: yeah sanders has a certain new england charm in his speeches
[07:27:20 CEST] <james999> i think there's a lawsuit now atm about how the dems rigged the proc against him
[07:27:37 CEST] <james999> from the sounds of it labour needs to rig the process against corbyn or something
[07:27:50 CEST] <james999> his poll numbers are in the trash
[07:30:13 CEST] <furq> what they need is a time machine
[07:31:10 CEST] <james999> how so?
[07:31:50 CEST] <furq> they've managed to not bother taking a stance on the biggest issue people care about right now
[07:32:13 CEST] <furq> since before the referendum
[07:32:34 CEST] <james999> oh yeah. didn't some lady persuade corbyn to back down from saying anything good about brexit?
[07:32:40 CEST] <furq> shrug
[07:32:44 CEST] <furq> he's always been broadly anti-EU
[07:32:53 CEST] <furq> just for less racist reasons than everyone else
[07:32:56 CEST] <james999> i recall something like that. he was going to give a speech in favor of it
[07:33:24 CEST] <james999> speaking of racism. is it true the papers refer to pakistanis as "asians"?
[07:33:31 CEST] <furq> i mean i'd rather have him than any of the tory-lite guys he was up against in the leadership contests
[07:33:34 CEST] <james999> i heard that from a brit podcast i listen to but couldn't believe it
[07:33:47 CEST] <furq> and some of the PLP shit to try and oust him was disgraceful and has helped us into this fucking mess
[07:33:51 CEST] <furq> but he still wouldn't have won
[07:33:55 CEST] <furq> and yeah
[07:33:59 CEST] <furq> that really annoys me as well
[07:34:35 CEST] <furq> at least say "south asians" if you're not sure whether they're pakistani, bangladeshi or indian
[07:34:42 CEST] <furq> because obviously getting that wrong could cause a diplomatic incident
[07:34:59 CEST] <furq> that's worse than calling a scotsman english
[07:35:01 CEST] <james999> well it's not like britain is sillicon valley and there's a bunch of chinese living there
[07:35:10 CEST] <james999> that's what the term 'asian' means mostly in US
[07:35:15 CEST] <furq> we have quite a lot of chinese
[07:35:18 CEST] <furq> we just call them chinese though
[07:35:31 CEST] <furq> there's pretty much no koreans or japanese so it works out ok
[07:35:51 CEST] <furq> and people from vietnam or whatever have got better shit to worry about
[07:36:02 CEST] <james999> there's actually koreans living in the US so it can be ambiguous i'll grant
[07:36:22 CEST] <james999> but nobody would generally say 'asian' when refering to someone from india or pakistan. they'd say indian or pakistani
[07:36:40 CEST] <furq> i mean the reverse is true here
[07:36:43 CEST] <furq> they're both equally stupid
[07:38:01 CEST] <james999> the number of black people is pretty low in britain right?
[07:38:21 CEST] <james999> like that movie with the diamond ... uh Snatch I think
[07:38:22 CEST] <furq> about 2%
[07:38:47 CEST] <james999> like half the cast was black.there was a russian too. Boris the Blade
[07:39:12 CEST] <furq> oh nvm that's the wrong column
[07:39:13 CEST] <furq> 3%
[07:39:29 CEST] <james999> yeah, it's like 13% in the US. still lots of division as well.
[07:39:43 CEST] <james999> some school district seceded from the surrounded school districts in the south
[07:40:05 CEST] <james999> and the judge presiding over it was like "well this is racist but since 20% of the city is black I guess it's ok. but you have to have a black person on the city council"
[07:41:04 CEST] <furq> also 7% south asian
[07:41:10 CEST] <furq> which seems like more than enough to implement sharia law
[07:41:22 CEST] <furq> thanks for the warning tommy robinson
[07:41:33 CEST] <james999> lol. have you seen thos youtube videos of bearded guys hustling passing strangers
[07:41:38 CEST] <furq> yes
[07:41:41 CEST] <james999> telling them "you can't drink, this is SHARIA zone"
[07:41:58 CEST] <furq> i have seen them when americans linked them to me as evidence that britain is operating under sharia law
[07:42:00 CEST] <james999> i always thought it seemed like an uncommon thing
[07:42:09 CEST] <james999> yeah
[07:42:13 CEST] <furq> bookended by PRISON PLANET video
[07:42:14 CEST] <furq> s
[07:42:24 CEST] <james999> or like, you can't kiss or hold hands here, london has fallen to the moor at last
[07:42:31 CEST] <james999> lol yeah
[07:42:34 CEST] <furq> you'd think it would be impossible for an alex jones affiliate to be even sadder than alex jones
[07:42:49 CEST] <james999> pjw is one of the brits i listen to once in awhile
[07:42:53 CEST] <furq> on which note, did you hear alex jones lost custody of his kids
[07:43:01 CEST] <furq> "i wonder why"
[07:43:03 CEST] <james999> yeah i just read the headline
[07:43:06 CEST] <james999> lol
[07:43:16 CEST] <furq> he was probably slipping colloidal silver into their food
[07:43:21 CEST] <james999> in the court filing his attorney said his show is all an act and he's not really like that irl
[07:43:31 CEST] <furq> yeah he said it was "performance art"
[07:43:52 CEST] <james999> when I think "performance art" i think of that swiss woman with the paint eggs
[07:44:05 CEST] <furq> which he then undermined by acting exactly the same throughout the trial as he does on tv
[07:44:08 CEST] <james999> probably about the same level tbh
[07:44:48 CEST] <james999> mostly the stat I hear from pjw a lot is london is over 50% islam or something like that
[07:44:59 CEST] <james999> with the implication that the rest of the country will follow
[07:45:01 CEST] <furq> he probably found that out by leaving the house and walking around
[07:45:05 CEST] <furq> oh wait, he can't do that
[07:46:18 CEST] <james999> weird why is a jury involved with alex jones
[07:46:37 CEST] <james999> normally custody is a single judge
[07:47:04 CEST] <furq> it's probably a conspiracy
[07:47:25 CEST] <furq> it turns out the illuminati have got a great sense of humour
[07:47:27 CEST] <james999> idk if you have juries over there in britain
[07:47:39 CEST] <furq> i've never lost custody of my kids so i wouldn't know
[07:47:41 CEST] <james999> imagine trying to convince 12 strangers off the street you should have primary custody of your kids
[07:47:54 CEST] <furq> a goal i have achieved by simply not having any
[07:47:56 CEST] <furq> top tips
[07:48:54 CEST] <james999> so what's up with sadiq khan anyway
[07:49:08 CEST] <furq> he's a mayor
[07:49:09 CEST] <james999> he's always the boogie man that's dragged out to prove that london is islamified
[07:49:19 CEST] <furq> that's literally all i know about h im
[07:49:25 CEST] <furq> he's a mayor, and he's not boris johnson, so that's good
[07:49:43 CEST] <james999> boris johnson. sounds like a russian agent was he ahacker?
[07:50:01 CEST] <furq> https://upload.wikimedia.org/wikipedia/commons/thumb/3/39/Boris_Johnson_-op…
[07:50:02 CEST] <james999> more to the point, did he sell illegal firearms from his house to gangsters?
[07:50:13 CEST] <furq> this is a real person and not an anthropomorphic claymation dog
[07:50:22 CEST] <furq> he's also the foreign secretary because of course he is
[07:50:54 CEST] <james999> http://static.srcdn.com/wp-content/uploads/rade-sherbedgia-taken-2.jpg
[07:51:04 CEST] <furq> i'm pretty sure i found the least embarrassing picture of him on google images
[07:51:17 CEST] <james999> ^that's what I picture someone named Boris looking like
[07:51:23 CEST] <furq> i wish
[07:55:16 CEST] <kinkinkijkin> how do I use vapoursynth with ffmpeg?
[07:55:38 CEST] <furq> vspipe -y foo.py - | ffmpeg -i - ...
[07:55:53 CEST] <kinkinkijkin> ah thanks
[07:56:14 CEST] <furq> you can ignore the thread_queue_size warnings
[07:56:41 CEST] <kinkinkijkin> anything special I have to put in the ffmpeg options or the vs script?
[07:56:57 CEST] <furq> nothing that comes to mind
[07:57:00 CEST] <kinkinkijkin> thanks
[07:57:07 CEST] <furq> vspipe is video only so obviously you'll need a separate audio input
[07:58:03 CEST] <kinkinkijkin> is there a way to specify the video input from one file and the audio input from the same file in this chain of commands?
[07:58:18 CEST] <furq> -i - -i bar.ts
[07:58:51 CEST] <furq> you might need -map but probably not
[07:59:23 CEST] <kinkinkijkin> so my source file has a video, and audio, and a subtitle
[07:59:31 CEST] <kinkinkijkin> could you put that in an example command?
[07:59:37 CEST] Action: james999 notes the subtle shift from - meaning stdout to stdin
[07:59:40 CEST] <furq> that should just work
[07:59:54 CEST] <kinkinkijkin> oki
[07:59:55 CEST] <furq> ffmpeg will pick the first video, audio and subtitle track it finds
[08:00:07 CEST] <furq> if it doesn't then -map 0:v -map 1:a -map 1:s
[08:00:19 CEST] <furq> if you have dual audio or something then you'll need that
[08:01:41 CEST] <kinkinkijkin> wait so where do I specify my video file initially?
[08:02:22 CEST] <furq> in the vapoursynth script
[08:03:17 CEST] <kinkinkijkin> I don't know python, do I have to send a "load file" thing?
[08:03:34 CEST] <kinkinkijkin> my schooling went straight from turing to java
[08:04:38 CEST] <james999> rather like discussing architecture by going from da vinci to soviet designs
[08:04:38 CEST] <furq> http://vpaste.net/QrrKR
[08:04:40 CEST] <furq> something like that
[08:04:59 CEST] <kinkinkijkin> thanks
[08:06:04 CEST] <james999> gotta get russian hacking out of my brain. :(
[08:09:15 CEST] <kinkinkijkin> hmm, what is a way to read the input file's framerate with vapoursynth while vapoursynth is not running slave to a player?
[08:09:49 CEST] <kinkinkijkin> er
[08:09:56 CEST] <kinkinkijkin> nvm
[08:10:36 CEST] <kinkinkijkin> actually yeah
[08:15:24 CEST] <kinkinkijkin> furq do you know how to check a file's source fps?
[08:38:33 CEST] <teratorn> kinkinkijkin: ffprobe can sometimes show you a correct fps, or a tool like mediainfo
[10:56:36 CEST] <Guest15272> Hello guys! I have question about resize / deinterlace filter for Intel quicksync decoding / encoding , is this place right place to ask?
[11:08:54 CEST] <slug> hey, I have videos of unknown duration and want to generate a 2x3 thumbnail. I want to get the full duration and divide that 6 so I get 1 thumbnail with 6 scenes from the whole movie. I am currently manually specifing like this, does anyone know a better way? "select=not(mod(n\,185)),scale=800:600,tile=2x3
[11:09:42 CEST] <furq> that's the shortest command but it'll take a long time
[11:10:51 CEST] <furq> you probably want something with ffprobe -skip_frame nokey -count_frames
[11:13:35 CEST] <slug> the way I do it I sometimes end up with black boxes where I have over run the file
[11:13:58 CEST] <slug> was wondering if I coudl auto detect the frames I need to devide by
[11:14:15 CEST] <furq> that's what ffprobe -count_frames does
[11:15:28 CEST] <furq> ffprobe -skip_frame nokey -v error -select_streams v:0 -count_frames -show_entries stream=nb_read_frames -of default=nokey=1:noprint_wrappers=1 "$file"
[11:15:33 CEST] <furq> specifically that
[11:17:52 CEST] <slug> ok if I run that I get 4
[11:23:34 CEST] <slug> cheers furq I'll play around with that
[11:56:30 CEST] <MR-2> Hello!
[11:57:21 CEST] <MR-2> I'm trying to download a HLS-vtt subtitle but ffmpeg only fetches the first segment, what am i doing wrong?
[12:56:29 CEST] <termos> when reading and rescaling my first AVPacket after I open the input, the time_base in my AVCodecContext is 0/2, but it's the correct value for the succeeding packages. Is there some period after init where my AVCodecContext is not fully initialized?
[13:01:11 CEST] <nyuszika7h> I didn't do the encode, but what would cause x264 to use Baseline(a)L1.3 profile?
[13:01:25 CEST] <nyuszika7h> it's 720x576 at 2500 kbps
[13:04:29 CEST] <JEEB> nyuszika7h: not using CABAC or b-frames
[13:04:40 CEST] <JEEB> that ends up with baseline
[13:04:48 CEST] <nyuszika7h> but L1.3?
[13:05:12 CEST] <JEEB> not sure if that resolution/rate actually fits into that level but -level 1.3 should give you that
[13:05:28 CEST] <JEEB> libx264 would scream at you if the limits aren't handle'able
[13:05:36 CEST] <nyuszika7h> opencl=1 / cabac=0 / ref=2 / deblock=1:0:0 / analyse=0x1:0x111 / me=umh / subme=6 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=250 /
[13:05:37 CEST] <nyuszika7h> keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=abr / mbtree=1 / bitrate=2500 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
[13:05:38 CEST] <JEEB> (but I think it would still encode with that levle, I think?
[13:05:54 CEST] <nyuszika7h> it plays fine and doesn't seem much worse than the others at a higher profile
[13:05:59 CEST] <JEEB> well, d'uh
[13:06:00 CEST] <nyuszika7h> though the Intel QSV decoder choked on it lol
[13:06:05 CEST] <JEEB> if you use enough rate
[13:06:10 CEST] <JEEB> anything will look good enough
[13:06:18 CEST] <JEEB> (and what is "enough" depends on the content and your eyes)
[13:06:46 CEST] <furq> yeah that just looks like a misflagged level
[13:07:08 CEST] <furq> 576p25 needs at least 3.0
[13:07:30 CEST] <nyuszika7h> yep it's 25 fps
[13:07:35 CEST] <furq> but libx264 won't stop you passing a too-low level
[13:07:54 CEST] <furq> i'm not surprised some decoders choke on it
[13:09:21 CEST] <furq> but then those are clearly custom settings and yet he's using 1-pass abr
[13:09:25 CEST] <furq> so whoever encoded this obviously sucks
[13:20:09 CEST] <denisenkoaj> Hello guys! What's principle difference between RTMP and RTSP ? I need to stream video to application on iOS and Android from mediaserver.
[13:20:09 CEST] <denisenkoaj> I already utilize stream from NGINX to iOS with RTMP and HLS, and don't know should i test RTSP or not
[13:35:36 CEST] <thebombzen> it seems weird to turn all those options off and then use me=umh
[15:06:58 CEST] <dystopia_> can i dump audio cd tracks to .wav with ffmpeg?
[15:12:37 CEST] <relaxed> dystopia_: yes if you compiled it with --enable-libcdio
[15:12:44 CEST] <furq> https://github.com/JoeLametta/whipper/
[15:12:54 CEST] <furq> that's the right thing to use on *nix atm
[15:13:18 CEST] <dystopia_> thanks guys
[15:13:26 CEST] <furq> assuming you don't want to use eac in wine
[15:16:22 CEST] <saste> dystopia: there is also a libcdio module in libavdevice
[15:17:24 CEST] <saste> dystopia: https://ffmpeg.org/ffmpeg-devices.html#libcdio
[15:19:05 CEST] <thebombzen> furq: how is there no FOSS equiavlent of EAC
[15:19:10 CEST] <thebombzen> why has nobody written this
[15:24:59 CEST] <furq> because cdparanoia hasn't been updated since 2008
[15:28:30 CEST] <furq> there have been loads of attempts to do it, but they're all based on cdparanoia, which has a known bug which results in different crcs from eac on at least one cd
[15:28:52 CEST] <furq> and evidently nobody wants to fix that bug, and nobody wants to rewrite cdparanoia
[15:53:39 CEST] <thebombzen> but if you want the CDs to bit bitexact
[15:53:45 CEST] <thebombzen> why can't you just create an ISO and use Wodim
[15:55:31 CEST] <LunaLovegood> What command arguments do I need to use to encode to 480i MPEG-2 from a 59.94 fps progressive source? (I want smooth motion at 59.94 interlaced fields per second)
[15:57:16 CEST] <BtbN> I think tinerlace does that.
[15:57:17 CEST] <BtbN> But why?
[15:57:55 CEST] <LunaLovegood> to make DVDs
[15:58:18 CEST] <LunaLovegood> from 1080p60 sources
[16:02:44 CEST] <BtbN> Does it have to be that horrible format?
[16:02:56 CEST] <BtbN> Most players play better stuff
[16:04:37 CEST] <LunaLovegood> How else do you get 60fps on a 20$ dvd player from 10 years ago then?
[16:05:47 CEST] <LunaLovegood> sorry, more like 15 years
[16:11:17 CEST] <BtbN> I don't think you can get real 60 fps at all
[16:11:50 CEST] <BtbN> you can get 60 fiels per second, so a full frame every two fields
[16:12:15 CEST] <LunaLovegood> Interlaced video does 59.94 fields per seconds. It looks real smooth on a TV with good deinterlacing, or on a CRT.
[16:12:35 CEST] <BtbN> it looks smoth because it tricks the eye
[16:13:47 CEST] <LunaLovegood> Yeah sure, but my camera records at 59.94, and it looks like crap when panning if I try to record at 29.97 instead.
[16:13:58 CEST] <BtbN> https://ffmpeg.org/ffmpeg-filters.html#tinterlace
[16:16:41 CEST] <LunaLovegood> oh yeah, ok thanks
[16:17:01 CEST] <BtbN> for 1080p60 to 1080i60 you'd probably want merge
[16:17:26 CEST] <BtbN> well, would be more like 1080p60 to 2160i60
[16:17:36 CEST] <BtbN> which you can then scale to your desired resolution
[16:17:42 CEST] <LunaLovegood> my problem with 29.97fps is probably cause there's no way to choose a longer exposure time on my video camera. It probably would look good with a 1/30 exposure time.
[16:19:09 CEST] <LunaLovegood> The scaling doesn't mess the interlace fields? I was thinking of scaling to 720x480, then tinterlace=5
[16:33:50 CEST] <Maverick|MSG> in case anyone uses handbrake: https://objective-see.com/blog/blog_0x1D.html (Mac Handbrake got hacked)
[16:35:25 CEST] <Maverick|MSG> (or rather: the handbrake mirror server was compromised)
[16:36:31 CEST] <kerio> thebombzen: it's 2017
[16:36:39 CEST] <kerio> stop buying circles made of plastic
[16:41:52 CEST] <dystopia_> i just started buying them again
[16:42:07 CEST] <dystopia_> it's nice to collect somthing physical
[16:42:17 CEST] <kerio> D;
[17:51:59 CEST] <thebombzen> kerio: I use them when I want to make a bootable install medium
[17:52:02 CEST] <thebombzen> but otherwise I don't
[17:52:18 CEST] <thebombzen> what I don't understand though is why Exact Audio Copy is necessary
[18:30:39 CEST] <cableguy> team
[18:31:00 CEST] <cableguy> how do i cap audio from this
[18:31:02 CEST] <cableguy> https://pastebin.com/yA7sZ1W2
[18:31:36 CEST] <cableguy> as you can see, you get unique token, etc
[18:31:42 CEST] <cableguy> the stream works, tested on vlc
[18:32:10 CEST] <cableguy> but ffmpeg returns multiple errors
[19:11:03 CEST] <relaxed> cableguy: ffmpeg -i input
[19:11:21 CEST] <relaxed> and quote the url
[19:18:22 CEST] <cableguy> relaxed, At least one output file must be specified
[19:18:36 CEST] <cableguy> it shows video h264 and audio aac
[19:18:41 CEST] <cableguy> but i dont need video
[19:18:43 CEST] <cableguy> i need only audio
[19:18:58 CEST] <cableguy> and untouched audio as possible, like raw audio or something
[19:20:02 CEST] <Threads> ffmpeg -i input -vn -acodec copy -y audio.mka
[19:20:55 CEST] <cableguy> uh isnt it m4a for aac
[19:21:28 CEST] <Threads> up to you what you want
[19:21:51 CEST] <cableguy> so whats the difference
[19:22:04 CEST] <Threads> container thats it
[19:22:10 CEST] <relaxed> one is matroska, the other is mp4
[19:22:29 CEST] <cableguy> container is aac for m4a like mkv for h264 no?
[19:22:40 CEST] <relaxed> just use m4a
[19:23:19 CEST] <cableguy> so this will copy the audio to m4a the same bitrate as it is on the stream url?
[19:24:00 CEST] <relaxed> it will copy the audio stream
[19:25:18 CEST] <cableguy> and how do u stop the copy
[19:26:51 CEST] <relaxed> q
[19:28:25 CEST] <cableguy> ur right, it says it right there
[19:30:13 CEST] <cableguy> what happens if i output it to .wav instead is that ok
[19:30:31 CEST] <cableguy> then i wont need to rencode it to wav from m5a
[19:30:33 CEST] <cableguy> m4a*
[19:31:26 CEST] <cableguy> hmm the .wav wont open in sound forge
[19:48:21 CEST] <cableguy> anyway
[19:48:24 CEST] <cableguy> everyone thanks for help
[19:48:26 CEST] <cableguy> cheers
[20:14:23 CEST] <faLUCE> relaxed: give your feedback too for my API usage example :-) :-)
[20:14:39 CEST] <faLUCE> like iive did
[21:55:02 CEST] <user___> anyone know if it's possible to use ffmpeg to capture webcam data, but just view it directly(locally) with mpv or vlc, etc
[21:55:40 CEST] <user___> more of a live stream, no output file, or do i need output file, then just view the ouptut.. possible or not
[22:00:29 CEST] <vlt> user___: It's possible. There's also ffplay. Maybe it's involved.
[22:05:28 CEST] <DHE> user___: yes, ffplay is provided as a simple video player. also note the mpv and VLC are actually using ffmpeg internally for their heavy lifting so most ffmpeg supported containers/codecs/protocols do work
[22:30:00 CEST] <user___> DHE: thanks
[22:42:51 CEST] <kerio> what
[22:43:06 CEST] <kerio> are you sure that VLC uses ffmpeg?
[22:46:35 CEST] <JEEB> kerio: it can use other libraries as well for a limited set of things
[22:46:45 CEST] <JEEB> but most video and audio decoding things except for HW dec/enc are from lavc
[22:46:54 CEST] <JEEB> and demuxing can also be done through lavf
[23:09:04 CEST] <baumy> i'm trying to cut the first 1 second or so off of a video but ffmpeg -i input.mkv -ss 00:00:01 cuts the first 10 seconds, guessing this has something to do with keyframes
[23:09:07 CEST] <baumy> what is the best way around this?
[23:09:59 CEST] <user___> DHE: ffplay works great, but what about multiple inputs(usb webcams)? giving me a resource busy
[23:18:17 CEST] <kepstin> baumy: in order to cut video at arbitrary points, you have to re-encode the video (i.e. set -c:v to something other than 'copy')
[00:00:00 CEST] --- Tue May 9 2017
1
0
[01:04:08 CEST] <cone-671> ffmpeg 03Takayuki 'January June' Suwa 07master:ea93b74074c5: avdevice/alsa: wait until playback buffers are drained before closing
[01:04:09 CEST] <cone-671> ffmpeg 03Ricardo Constantino 07master:c0b3781bf2fe: rtmpproto: send swfverify value as swfurl if latter is unused
[03:59:29 CEST] <cone-671> ffmpeg 03James Almer 07master:fb0f29f9aaaf: avcodec/hevc_sei: actually propagate error codes
[04:14:07 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:1121d9270783: avcodec/msmpeg4dec: Correct table depth
[04:14:08 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:669419939c1d: avcodec/svq3: Fix multiple runtime error: signed integer overflow: 44161 * 61694 cannot be represented in type 'int'
[04:14:09 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:9e88cc94e58e: avcodec/ivi_dsp: Fix multiple left shift of negative value -2
[04:14:10 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:e92fb2bea180: avcodec/texturedsp: Fix multiple runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
[04:14:11 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:3e56db892600: avcodec/targa_y216dec: Fix width type
[04:54:12 CEST] <cone-671> ffmpeg 03James Almer 07master:4a51aa7ddaeb: configure: add missing avcodec dependencies to filters
[05:31:08 CEST] <cone-671> ffmpeg 03Steven Liu 07master:cc25a887c546: avformat/matroskadec: fix resource leak
[05:33:18 CEST] <atomnuker> bofh_: ping
[07:44:07 CEST] <atomnuker> does our flac muxer support writing attached pics (coverart)?
[07:45:01 CEST] <atomnuker> apparently not
[08:00:02 CEST] <rcombs> atomnuker: I have a patch for that
[08:00:34 CEST] <rcombs> https://gist.github.com/64a70e9aacd8c1f361098c59bafcb3a7
[08:00:52 CEST] <rcombs> I think it was sent back because of some GIF-related problem that I haven't gotten around to fixing
[08:01:28 CEST] <atomnuker> remove gif support then, its useless
[08:02:27 CEST] <rcombs> yeah that's the easy solution, I just haven't bothered
[08:02:36 CEST] <rcombs> lemme go see what all is blocking that patchset atm
[08:03:26 CEST] <rcombs> oh, just that
[08:03:41 CEST] <wm4> gif nicely breaks libavformat's awful abstraction for attached images
[08:04:00 CEST] <atomnuker> lgtm, +2, remof gaf support, skip the ml, commit, we'll fax issuas laterz
[08:04:20 CEST] <wm4> becaused attached images are "streams", except they're not, so gifs with multiple frames just don't git in
[08:05:18 CEST] <wm4> (probably better solution: just make them blobs, require user to open them as memory streams with another lavf context)
[08:09:16 CEST] <atomnuker> rcombs: when you submit the patch to the ML could you bump lavf micro as well? I need it for my cd ripper
[08:09:32 CEST] <rcombs> atomnuker: hah, that is what this is for :P
[08:09:50 CEST] <rcombs> (also includes segment.c breaking on chapters and a cue sheet demuxer)
[10:03:04 CEST] <rcombs> so, lavc's FLAC encoder's end behavior appears to be invalid
[10:04:12 CEST] <rcombs> it changes the block size for the last frame, which is fine, except that it encodes the timestamp as a frame number instead of a sample number, and my understanding is that you can only do that if every preceding frame has the same block size as the current one
[10:05:14 CEST] <wm4> doesn't the timestamp refer to the first sample in a frame
[10:05:22 CEST] <wm4> so how does the length of the last frame matter for timestamps
[10:06:49 CEST] <rcombs> wm4: the timestamp can be either in units of samples or of frames
[10:07:03 CEST] <rcombs> if it's in frames, then you convert to samples by multiplying by the block size
[10:07:14 CEST] <rcombs> this doesn't work if the block size has changed
[10:07:38 CEST] <rcombs> oh wait, there's a thing about this
[10:07:39 CEST] <rcombs> >(In the case of a fixed-blocksize stream, only the last block may be shorter than the stream blocksize; its starting sample number will be calculated as the frame number times the previous frame's blocksize, or zero if it is the first frame)
[10:08:26 CEST] <rcombs> so, what, you need to know a priori that it's the last block?
[10:08:35 CEST] <rcombs> who the fuck came up with that?
[10:08:58 CEST] <rcombs> also: "hey, let's put timestamps in the frame headers", :|
[10:09:00 CEST] <wm4> hm not sure if I get it
[10:28:34 CEST] <nevcairiel> rcombs: cant you just always calc from the previous clocks size
[10:28:44 CEST] <nevcairiel> blocks*
[10:31:40 CEST] <alevinsn> wm4: I started doing the videotoolbox review tonight (before you sent the ping to the ML)--if you are willing to wait for my review
[10:31:44 CEST] <alevinsn> I'll get it done
[10:32:03 CEST] <wm4> ok
[10:32:29 CEST] <alevinsn> there is quite a bit of code, so its slow going
[10:32:55 CEST] <alevinsn> " // Somewhat tricky because the API user can call av_videotoolbox_default_free()
[10:32:55 CEST] <alevinsn> // at any time.
[10:32:55 CEST] <alevinsn> "
[10:33:01 CEST] <alevinsn> I didn't understand this comment
[10:33:15 CEST] <alevinsn> av_videotoolbox_default_free() doesn't do anything with hwaccel_priv_data
[10:33:23 CEST] <alevinsn> it only frees hwaccel_context
[10:35:38 CEST] <wm4> because videotoolbox_default_free calls that function
[10:37:36 CEST] <alevinsn> I don't understand why that matters--if it returns null, videotoolbox_default_free() just returns
[10:41:22 CEST] <rcombs> nevcairiel: yeah, that's what I'm doing in flacenc now
[10:41:59 CEST] <wm4> alevinsn: because there is an unusual situation with avctx->internal not being set because the codec context can be closed
[10:42:22 CEST] <rcombs> nevcairiel: but that doesn't work for e.g. flac_read_timestamp
[10:44:42 CEST] <alevinsn> wm4: okay, but what does that have to do with av_videotoolbox_default_free()? plus, if that's the case, why is it okay to use hwaccel_priv_data directly in the next function, videotoolbox_buffer_create()?
[10:47:51 CEST] <alevinsn> and then further, if we go to the places that call videotoolbox_get_context(), such as videotoolbox_session_decode_frame()
[10:48:15 CEST] <alevinsn> if it is possible for internal to be null, then what this function is doing looks wrong
[10:50:45 CEST] <wm4> av_videotoolbox_default_free() calls an internal function that's shared
[10:50:56 CEST] <wm4> it's not
[10:50:58 CEST] <wm4> ...
[10:56:20 CEST] <alevinsn> you mean how videotoolbox_default_free() is also called by videotoolbox_uninit()?
[10:58:55 CEST] <wm4> just read the code
[11:01:00 CEST] <alevinsn> I have--but, I still don't understand why the comment is relevant, and if it is relevant, why there aren't issues in the other places
[11:01:40 CEST] <alevinsn> maybe if you could describe the sequence that prompted that check, it would be helpful (for me)
[11:02:18 CEST] <wm4> when videotoolbox_default_free() is called if the codec is closed
[11:10:07 CEST] <alevinsn> so, are you saying there is the possibility that, because av_videotoolbox_default_free() is exposed to the user
[11:10:17 CEST] <alevinsn> if it is called after the codec has been closed
[11:10:25 CEST] <alevinsn> you have that check there to make sure it doesn't crash?
[11:10:33 CEST] <wm4> yes
[11:12:15 CEST] <alevinsn> OK, I got it, next thing, I know it was doing this in the existing code, but why isn't there a cast to (VTContext *) for hwaccel_priv_data? hwaccel_priv_data is of type void *
[11:12:20 CEST] <alevinsn> I would think that this would at least produce a warning
[11:12:27 CEST] <alevinsn> a compiler warning
[11:13:08 CEST] <wm4> this is not C++
[11:13:31 CEST] <nevcairiel> yeah C does not need casting for that
[11:13:47 CEST] <alevinsn> but, it is needed for: CVPixelBufferRef pixbuf = (CVPixelBufferRef)vtctx->frame;
[11:14:09 CEST] <nevcairiel> you dont need casts from void* to other pointers
[11:14:23 CEST] <nevcairiel> but you do need it for other complex type conversions
[11:14:50 CEST] <alevinsn> oh--that just looks wrong to me, but I can get used to it
[11:16:13 CEST] <alevinsn> ok, before I head to bed, I had a thought that you might find amusing that I thought I would share
[11:16:51 CEST] <alevinsn> since wm4 is effectively anonymous, wm4 could in theory be anyone... so, if we take that to its logical conclusion....
[11:17:05 CEST] <alevinsn> wm4 is cehoyos masquerading as wm4 :-)
[11:17:54 CEST] <alevinsn> ok, maybe not as amusing as I thought it was
[11:18:42 CEST] <nevcairiel> using a fixed name still identifies you, even if its not your real name
[11:19:29 CEST] <alevinsn> I meant
[11:20:08 CEST] <alevinsn> with the nature of the Internet, it is certainly possible to have multiple aliases
[11:21:19 CEST] <nevcairiel> that could be claimed about anyone
[11:21:34 CEST] <nevcairiel> how do we know you are who you are claiming to be? :d
[11:22:04 CEST] <alevinsn> yes, yes, a "real name" doesn't mean anything as well
[11:23:24 CEST] <alevinsn> but, at least with wm4, and the e-mail address associated with wm4 on the ML, I don't think there is anything to easily tie wm4 to the identity of a specific individual
[11:24:22 CEST] <alevinsn> so, I was suggesting that these arguments between wm4 and cehoyos may be a joke perpetrated by cehoyos entirely... its ridiculous, which is why I thought it was amusing
[11:31:55 CEST] <iive> alevinsn: you mean, this might be a joke by wm4 entirely :P
[11:47:36 CEST] <wm4> does anyone know what the allowed timestamp range is?
[11:47:43 CEST] <wm4> in libavformat
[11:51:12 CEST] <BtbN> Whatever fits into int64 I'd assume?
[11:52:14 CEST] <wm4> then stuff like RELATIVE_TS_BASE could probably not work
[11:52:17 CEST] <nevcairiel> 48 bit i think, because of this relative ts hack
[11:52:21 CEST] <wm4> lol
[11:52:38 CEST] <nevcairiel> (not like 48 bit isnt a lot of timestamps)
[11:53:52 CEST] <JEEB> relative TS base?
[11:53:58 CEST] <JEEB> it feels like I don't want to know about this...
[11:54:32 CEST] <wm4> indeed you don't
[11:54:58 CEST] <nevcairiel> i forget wtf this was even for
[11:58:09 CEST] <wm4> full 64 bit is a bit crazy, because it'd overflow most calculations that do something with timestamps
[11:58:27 CEST] <rcombs> OK now I've gotta know
[11:58:32 CEST] <rcombs> what is this
[11:58:39 CEST] <rcombs> (RELATIVE_TS_BASE)
[12:01:07 CEST] <wm4> see libavformat/utils.c
[12:01:09 CEST] <wm4> try not to cry
[12:02:13 CEST] <rcombs> &wat
[12:16:25 CEST] <BtbN> hm, adding support for the hw_device_ctx to nvenc.c is harder than expected
[12:16:42 CEST] <BtbN> as it relies on the data_pix_fmt from the context
[12:18:39 CEST] <wm4> what does it do with it? initialization?
[12:19:08 CEST] <BtbN> I'm trying to find out if it really needs it before getting the first frame
[12:19:53 CEST] <wm4> it it really does, using hw_frames_ctx might be reasonable, but only jkqxz knows whether this would be ok API use
[12:21:36 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L408 here it just gets the cuda context, using hw_device_ctx instead is trivial there.
[12:22:24 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L1406 and here it gets the width/height and sw_format, which I'm pretty sure can all be gotten from the frame instead.
[12:22:43 CEST] <wm4> certainly
[12:23:00 CEST] <wm4> so it looks like hw_device_ctx support is possible/easy
[12:23:13 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L1305 but this is the place that's the problem
[12:23:42 CEST] <wm4> ah
[12:23:58 CEST] <BtbN> That data_pix_fmt is used in the capabilities checks, to see if the device supports 10bit/yuv444 and so on
[12:24:26 CEST] <wm4> you could init the encoder on the first frame
[12:24:37 CEST] <wm4> though that seems annoying
[12:24:38 CEST] <BtbN> That would be a huge re-structure
[12:25:04 CEST] <BtbN> It's also used when configuring the encoder, like vui->videoFullRangeFlag = (avctx->color_range == AVCOL_RANGE_JPEG || ctx->data_pix_fmt == AV_PIX_FMT_YUVJ420P || ctx->data_pix_fmt == AV_PIX_FMT_YUVJ422P || ctx->data_pix_fmt == AV_PIX_FMT_YUVJ444P);
[12:25:54 CEST] <wm4> J formats, seriously
[12:26:13 CEST] <wm4> they're deprecated and hw_device_ctx doesn't have colorspace info AFAIK
[12:26:16 CEST] <BtbN> A lot of decoders still output those
[12:26:25 CEST] <wm4> sorry, hw_frames_ctx
[12:26:55 CEST] <wm4> you can check avctx->color_range though, which I suppose is set on init
[12:27:00 CEST] <wm4> (why not the pixfmt??)
[12:27:07 CEST] <wm4> maybe this is a non-issue
[12:27:25 CEST] <BtbN> hm, I'd assume I can just do ctx->data_pix_fmt = avctx->sw_pix_fmt;
[12:27:39 CEST] <wm4> yeah
[12:27:54 CEST] <wm4> just update the docs
[12:28:04 CEST] <BtbN> There are docs about that?
[12:28:19 CEST] <wm4> the current docs say about that field: * - encoding: unused.
[12:28:29 CEST] <wm4> (well, doxygen, not docs)
[12:28:34 CEST] <BtbN> ah, those docs
[12:30:32 CEST] <BtbN> Do I just put "set by user" there?
[12:30:50 CEST] <BtbN> Or should I describe it a bit more in detail?
[12:31:43 CEST] <wm4> maybe mention that it's only interpreted if pix_fmt is a hwaccel format
[12:32:43 CEST] <BtbN> "encoding: May be used by some hw encoders to find the underlying sw pixel format when pix_fmt is a hwaccel format."
[12:33:39 CEST] <wm4> sounds good
[12:33:41 CEST] <BtbN> I wonder if ffmpeg.c already sets it correctly when encoding
[12:33:46 CEST] <BtbN> It should?
[12:34:01 CEST] <wm4> searching for it shows nothing lol
[12:34:13 CEST] <wm4> but nothing should stop it from being able to
[12:34:30 CEST] <BtbN> cuvid.c makes use of it, so ffmpeg.c has to touch it somewhere
[12:37:58 CEST] <jkqxz> It's set in the get_format code in lavc.
[12:38:54 CEST] <jkqxz> I'm not sure exactly what you are trying to do here, but hw_device_ctx for encoders is only useful if you are using software frames as input.
[12:39:14 CEST] <BtbN> So far it was used by nvenc.c to get the cuda context
[12:39:26 CEST] <BtbN> And as such was also inter-mangled into some other things
[12:39:51 CEST] <BtbN> primarily only to get the sw pixel format. And I'm not trying to add avctx->hw_device_ctx support to nvenc.c
[12:39:58 CEST] <BtbN> to eventually migrate ffmpeg_cuvid.c
[12:40:03 CEST] <wm4> jkqxz: so he should access hw_frames_ctx?
[12:40:33 CEST] <wm4> the doxygen doesn't really say whether it's set on init
[12:40:45 CEST] <jkqxz> If you have hardware frames as input, then you use hw_frames_ctx (including the device inside it).
[12:41:06 CEST] <jkqxz> If you have software frames as input, use hw_device_ctx to get the device you are meant to use, or if not set you can make one up yourself by whatever means.
[12:41:25 CEST] <jkqxz> Yes, hw_frames_ctx must be set on init.
[12:42:05 CEST] <jkqxz> ("This field should be set before avcodec_open2() is called.")
[12:42:23 CEST] <wm4> oh damn
[12:42:26 CEST] <wm4> blindness
[12:42:38 CEST] <BtbN> But that makes the entire effort pointless
[12:42:47 CEST] <jkqxz> AVCodecContext.sw_pix_fmt shouldn't be relevant, because either it's the sw_pix_fmt of the hw_frames_ctx, or it's the pix_fmt itself because you are using software frames.
[12:43:09 CEST] <wm4> BtbN: well for sw mode, you still want to read hw_device_ctx to set the device to be used
[12:43:25 CEST] <wm4> makes for a better user API than messing with private options etc.
[12:43:39 CEST] <BtbN> in sw mode nvenc.c just creates its own cuda context
[12:44:37 CEST] <BtbN> But the whole idea was to get rid of the half-initialized hw_frames_ctx ffmpeg_cuvid.c does, and instead get rid of it entirely, as it's essentialy not needed at all
[12:44:56 CEST] <BtbN> And I'm pretty sure that can be done without any crazy hackery
[12:45:28 CEST] <jkqxz> The context created by nvenc will be on some device it picks (possibly with a private option), rather than on the one defined by the user with this common mechanism. That's all you gain by using this.
[12:45:47 CEST] <jkqxz> (Same change for libmfx: <https://git.libav.org/?p=libav.git;a=commit;h=3d197514e613ccd9eab43180c0a7c…>.)
[12:46:16 CEST] <jkqxz> (Except it's worse there, because of things opening for exclusive access by default and breaking multiple instances.)
[12:48:14 CEST] <wm4> BtbN: well the user can still init the hw_frames_ctx for decoding, it just isn't particularly useless
[12:48:24 CEST] <wm4> for videotoolbox the situation is similarly awkward
[12:48:41 CEST] <wm4> (maybe worse because neither hw_frames_ctx nor hw_device_ctx really make sense for it)
[12:48:45 CEST] <wm4> at least for decoding
[13:00:19 CEST] <BtbN> wm4, https://github.com/FFmpeg/FFmpeg/compare/master...BtbN:master this looks pretty clean to me.
[13:08:37 CEST] <wm4> BtbN: not sure
[13:09:11 CEST] <wm4> I think hw_device_ctx should be used in sw format mode only?
[13:09:45 CEST] <BtbN> But what was the whole point of the entire effort then? I thought it was to get rid of the ugglynes ffmpeg_cuvid.c does
[13:09:58 CEST] <BtbN> It didn't help with that at all
[13:13:59 CEST] <wm4> but what does this have to do with ffmpeg_cuvid.c?
[13:14:20 CEST] <BtbN> It currently half-initializes a hw_frames_ctx, which then gets fully initialized by cuvid.c
[13:14:31 CEST] <BtbN> That's ugly, and it really only needs to create a CUDA context
[13:15:29 CEST] <wm4> you can drop that
[13:15:48 CEST] <BtbN> No I can't, nvenc.c needs the hw_frames_ctx
[13:15:52 CEST] <wm4> output avframes will have a privately created heframesctx
[13:16:04 CEST] <BtbN> but nvenc needs it on the avctx
[13:16:09 CEST] <BtbN> at init-time
[13:16:12 CEST] <BtbN> to get the cuda context
[13:18:27 CEST] <wm4> encoders are initialized once the first frame was filtered/decoded, right?
[13:18:59 CEST] <BtbN> in ffmpeg.c, yes. But nvenc needs the hw_frames_ctx to be set on init, it being on the frames isn't enough.
[13:19:20 CEST] <atomnuker> they ought to be given container framesize != first image's framesize
[13:21:50 CEST] <jkqxz> hw_frames_ctx on the AVCodecContext is set from the first frame when the encoder is opened.
[13:22:59 CEST] <wm4> BtbN: so it looks like you're already done
[13:23:16 CEST] <wm4> although being able to set the device in sw mode would be good too
[13:23:54 CEST] <BtbN> jkqxz, where is that done?
[13:24:05 CEST] <jkqxz> I don't understand what sw_pix_fmt is even meaning there. You already have the hw_frames_ctx in that case, so you already know the sw_pix_fmt.
[13:24:31 CEST] <BtbN> for cases where you don't have a hw_frames_ctx, but only a hw_device_ctx
[13:24:38 CEST] <BtbN> As for CUDA, there is no inherent need for one
[13:24:53 CEST] <jkqxz> <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg.c;h=e798d922779f6fbcf…>
[13:25:13 CEST] <jkqxz> But the only such cases are software case where the pix_fmt is pix_fmt.
[13:25:29 CEST] <jkqxz> (Immediately before avcodec_open2()...)
[13:25:47 CEST] <BtbN> right now they are, but due to the new field being available, the whole cuvid/nvenc hwaccel could be migrated to not use an external hw_frames_ctx
[13:27:29 CEST] <wm4> hw_frames_ctx is also needed for filtering
[13:27:38 CEST] <wm4> mpv uses it to get the sw_format (and also screenshots)
[13:27:38 CEST] <jkqxz> There is no "external" hw_frames_ctx, but there is still the one carried in the frames (which is required, because you need the hardware metadata on them).
[13:27:56 CEST] <jkqxz> And you need to pass that one to the encoder.
[13:27:57 CEST] <wm4> oh with external you mean the one in ffmpeg_cuvid.c?
[13:28:03 CEST] <BtbN> yes
[13:28:10 CEST] <wm4> just create the hw_frames_ctx in the decoder
[13:28:12 CEST] <BtbN> cuvid.c conveniently creates one internally, so the frames coming out of it have one
[13:28:14 CEST] <wm4> like it's done now
[13:28:17 CEST] <wm4> (after my patch)
[13:28:48 CEST] <BtbN> hm, this basically means that ffmpeg_cuvid.c can be almost entirely removed now
[13:28:56 CEST] <wm4> if cuvid.c doesn't support custom frame allocation, and if changing the sw_format to something else doesn't make sense, the "external" hw_frames_ctx should be deprecated
[13:29:16 CEST] <wm4> (changing sw_format might make sense if the hw decoder supports multiple formats for the same video)
[13:29:28 CEST] <wm4> (like videotoolbox does, urgh)
[13:29:36 CEST] <BtbN> it does
[13:29:51 CEST] <BtbN> you can for example request an 8bit format for 10bit video, and it will do as you told it
[13:30:09 CEST] <wm4> in that case, only the half-initialized part needs to be deprecated
[13:30:24 CEST] <BtbN> cuvid.c already uses sw_pix_format for that
[13:30:26 CEST] <wm4> (so a user would either have to set a fully initialized one, or none)
[13:30:42 CEST] <wm4> well I don't think the user is supposed to set sw_pix_format
[13:31:00 CEST] <BtbN> But it looks like ffmpeg.c would have to learn about hw_device_ctx first. The InputStream only has a hw_frames_ctx
[13:31:12 CEST] <wm4> and for videotoolbox I made it so that it can select the sw_format with a hw_frames_ctx
[13:31:32 CEST] <wm4> advanced device selection is in Libav
[13:31:41 CEST] <BtbN> cuvid.c insist that thw hw_frames_ctx swformat is identical to the one in sw_pix_fmt
[13:31:47 CEST] <wm4> I think it's 50 commits or so away from the currently merged one
[13:32:05 CEST] <wm4> why does it do that?
[13:32:32 CEST] <BtbN> Because anything else doesn't make sense?
[13:33:17 CEST] <wm4> well what sw_pix_fmt is is not too well defined anyway
[13:33:30 CEST] <wm4> for example with real hwaccels, the hw_frames_ctx sw_format can be different
[13:33:35 CEST] <BtbN> What is it supposed to do if the sw_pix_fmt is NV12, but the externally supplied context is yuv420p?
[13:33:48 CEST] <wm4> e.g. if sw_pix_fmt is yuv420p, the hw_frames_ctx one is usually nv12
[13:33:49 CEST] <BtbN> So it just throws an error
[13:34:12 CEST] <wm4> does cuvid (the nvidia API) support yuv420p decoding?
[13:34:17 CEST] <BtbN> no
[13:34:21 CEST] <wm4> then throw an error
[13:34:31 CEST] <BtbN> It will throw an error whenever they mismatch
[13:34:34 CEST] <BtbN> no matter in what way
[13:35:36 CEST] <wm4> didn't you say it supports decoding 10 bit video to 8 bit surfaces?
[13:36:43 CEST] <BtbN> it does
[13:36:59 CEST] <BtbN> but that works by having 10bit hevc, and setting an 8 bit sw format
[13:37:00 CEST] <wm4> so in that case, if the user sets a hw_frames_ctx, it could set the sw_format to 8 bit
[13:37:08 CEST] <wm4> even though avctx->sw_pix_fmt is 10 bit
[13:37:36 CEST] <BtbN> It will want that to be 8 bit as well
[13:37:58 CEST] <wm4> then set it?
[13:37:58 CEST] <BtbN> which makes sense to me, as it represents the output pixel format. coded input doesn't have a pixel format
[13:38:08 CEST] <wm4> sw_pix_fmt has no meaning
[13:38:20 CEST] <wm4> it only has some meaning within hwaccels and get_format
[13:38:30 CEST] <wm4> but it's not interpreted or used otherwise by anything
[13:38:39 CEST] <wm4> so do whatever is convenient?
[13:41:47 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/compare/master...BtbN:master this should be enough for support in sw mode
[13:44:13 CEST] <wm4> yeah looks good to me
[13:44:22 CEST] <wm4> maybe the factoring could be improved
[13:44:39 CEST] <wm4> like moving device creation into a function (or just using the hwcontext's device creation)
[13:45:46 CEST] <BtbN> that's a bit complicated as it's interleaved with the capabilities check
[13:46:03 CEST] <BtbN> it will by default use the first device that supports the needed features for the current encode, unless user-specified
[13:46:56 CEST] <wm4> are there really multiple devices usually?
[13:47:19 CEST] <BtbN> I have come across multiple people who have more than one GPU
[13:47:29 CEST] <wm4> yeah, I'd expect one device per GPU
[13:47:30 CEST] <BtbN> Also some with very different GPUs
[13:47:56 CEST] <BtbN> Like, an old Quadro K600 as output-GPU, and a bunch of GPGPU-Cards on top
[13:47:57 CEST] <wm4> in theory you can pass an AVDictionary to device creation, but yeah maybe not worth the effort
[13:48:19 CEST] <BtbN> I'd still need to enumerate all devices
[13:48:25 CEST] <BtbN> And check each one for its nvenc capabilities
[13:48:34 CEST] <wm4> I mean you could do the enumeration in the hwcontext code
[13:48:46 CEST] <BtbN> And pass in a callback to check if it's ok? oO
[13:49:06 CEST] <wm4> no, just come up with a way to signal requirements via the AVDictionary
[13:49:18 CEST] <wm4> but that's probably way more complex than the current code
[13:49:38 CEST] <BtbN> That'd make the hwcontext code need to know about nvenc
[13:49:50 CEST] <BtbN> As qurying the device capabilities is nvenc api, not generic CUDA
[13:49:57 CEST] <jkqxz> Yeah, requirements would be nasty.
[13:50:50 CEST] <wm4> still a bit annoying that this nvenc can't be used when doing full-hw transcoding
[13:50:52 CEST] <jkqxz> I assume the default mode is also so that you automagically choose the next card when you run into the two-instances-per-consumer-GPU limit?
[13:51:12 CEST] <wm4> (is it still 2 per GPU?)
[13:51:22 CEST] <BtbN> 2 per nvenc chip on consumer cards
[13:51:25 CEST] <BtbN> which happen to have only one
[13:52:14 CEST] <BtbN> jkqxz, yes, it would indeed do that.
[13:52:20 CEST] <BtbN> Never tought about that, but yes, that would happen
[13:52:54 CEST] <jkqxz> Because that would be useful to some set of people, and isn't really achievable without weird configuration by any other route.
[13:53:49 CEST] <BtbN> nvEncOpenEncodeSessionEx is what fails in that case, which makes nvenc_open_session fail, which makes nvenc_check_device fail, which causes nvenc_setup_device to iterate to the next device
[13:56:15 CEST] <wm4> pretty nasty if you'd like that with full-hw transcoding
[13:56:24 CEST] <wm4> since the encoder is actually opened last
[13:58:45 CEST] <BtbN> With full-hw transcoding it gets a cuda context as input
[13:58:49 CEST] <BtbN> and that logic never runs
[13:59:01 CEST] <BtbN> it just runs a capability check on the passed context, and throws an error if it doesn't work
[14:03:54 CEST] <wm4> yeah
[14:04:04 CEST] <wm4> which is a problem if someone wants that fallback logic
[14:06:42 CEST] <BtbN> it's not possible in a sensible way to do that on full hw transcoding
[14:14:50 CEST] <cone-349> ffmpeg 03Timo Rothenpieler 07master:dad6f44bbd57: avcodec/nvenc: support external context in sw mode
[14:14:50 CEST] <cone-349> ffmpeg 03Timo Rothenpieler 07master:f89a89c5500c: avcodec/nvenc: use frames hwctx when registering a frame
[14:15:17 CEST] <BtbN> Is the git server busy/about to die? It just was sitting there at "remote: -Info- Update is fast-forward" for almost two minutes
[14:15:48 CEST] <atomnuker> hm, I think I noticed a slowdown too
[14:16:19 CEST] <BtbN> j-b, ^
[15:32:57 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07master:464c4b86ee43: avcodec/mss34dsp: Fix multiple signed integer overflow
[15:32:58 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07master:78bf446852a7: avcodec/ra144: Fix runtime error: left shift of negative value -798
[15:32:59 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07master:2162b862eba5: avcodec/magicyuv: Check len to be supported
[15:52:31 CEST] <Compn> BtbN : dont we run our own git ?
[15:53:20 CEST] <Compn> yeah git.ffmpeg.org goes to our bg host
[15:53:25 CEST] <michaelni> Compn, our git is not slow
[15:53:53 CEST] <Compn> BtbN and atomnuker were the reporters, not me :)
[15:54:08 CEST] <michaelni> deveopers use git@source.ffmpeg.org:ffmpeg
[15:54:31 CEST] <michaelni> source.ffmpeg.org. 600 IN CNAME git.videolan.org.
[15:54:34 CEST] <Compn> ah
[15:54:42 CEST] <jamrial> is this about fetch/pull or push? because while the former is fast as usual, the latter started being slow for me ever since the videolan server move
[15:54:43 CEST] <Compn> yeah sorry i was thinking something else :D
[15:55:22 CEST] <Compn> tracert is timing out to source.ffmpeg.org, somewhere in london
[15:55:38 CEST] <Compn> at least for me
[15:55:54 CEST] <Compn> not that that has anything to do with git slowdonw
[15:55:56 CEST] Action: Compn runs
[16:10:43 CEST] <philipl> BtbN: so what was the conclusion on whethere the hw_frame_ctx initialisation can be removed from ffmpeg_cuvid.c?
[16:11:55 CEST] <wm4> it can
[16:12:11 CEST] <BtbN> well, not without some merge from libav it seems
[16:15:32 CEST] <wm4> Libav brings the generic hwaccel
[16:15:42 CEST] <wm4> it will work with the current cuvid
[16:15:52 CEST] <wm4> (because it uses hw_device_ctx)
[16:16:09 CEST] <wm4> so ffmpeg_cuvid.c can be deleted, and the hwaccel entry in ffmpeg_opt.c slightly updated
[16:16:23 CEST] <philipl> And we think nvenc will work correctly after the last changes?
[16:16:50 CEST] <wm4> yes
[16:21:55 CEST] <philipl> great.
[17:18:02 CEST] <Compn> whos the nvenc maintainer ?
[17:18:03 CEST] Action: Compn runs
[17:42:32 CEST] <philipl> BtbN: So you guys were discussing using avctx->sw_pix_fmt in ff_nvenc_encode_init instead of hw_frames_ctx. Any reason not to do that now? I tried and it works with ffmpeg.c
[17:42:55 CEST] <BtbN> Because it's documented as unused
[17:43:15 CEST] <BtbN> And of course it works, data_pix_fmt being wrong wouldn't cause obvious failures
[17:43:43 CEST] <BtbN> Could only cause wrong colors, and wrong settings when doing yuv444 or 10bit encodes
[17:44:21 CEST] <BtbN> hw_frames_ctx is set anyway, so no need to jump through hoops here
[17:44:38 CEST] <philipl> fair enough
[17:45:24 CEST] <j-b> BtbN: yes, see https://munin.videolan.org/VideoLAN/goldeneye.videolan.org/vmstat.html
[17:45:56 CEST] <j-b> BtbN: or https://munin.videolan.org/VideoLAN/goldeneye.videolan.org/index.html in general
[17:46:41 CEST] <BtbN> yeah, looks very busy the last day or so
[17:47:06 CEST] <j-b> the load is very very high
[17:47:44 CEST] <j-b> and requests quite high too
[17:47:48 CEST] <BtbN> are there some people constantly cloning stuff with no end?
[17:47:54 CEST] <BtbN> that's how it looks to me
[17:48:15 CEST] <j-b> yes
[17:48:17 CEST] <j-b> very often
[17:48:31 CEST] <j-b> usually people start doing that in loop
[18:03:38 CEST] <j-b> BtbN: I did some magic. I hope it will help. Answer in 10 min.
[18:12:00 CEST] <j-b> BtbN: seems way better.
[18:12:12 CEST] <BtbN> banned some spamming IP(s)?
[18:16:47 CEST] <j-b> BtbN: + cleaning + restarting some services, yes.
[18:25:20 CEST] <atomnuker> BBB: what fails currently that we need to align stuff?
[18:25:29 CEST] <atomnuker> why didn't it happen before?
[18:30:19 CEST] <j-b> BtbN: everything is in place, yes. But it's weird to see that many git requests, aka 3x more than last week.
[18:33:02 CEST] <BtbN> probably a single user with a massive misconfiguration hammering the server
[18:35:13 CEST] <j-b> BtbN: does not seem so.
[18:52:42 CEST] <philipl> Shouldn't we add these new *.version files to .gitignore?
[19:12:25 CEST] <jamrial> they aren't?
[19:14:46 CEST] <BBB> atomnuker: see earlier emails about specifics, but the current patch series is trying to address the more general issue of how to make requirements for alignment specific and explicit
[19:14:56 CEST] <BBB> (right now its implied but undocumented and easy to get wrong)
[19:15:22 CEST] <jamrial> philipl: ah yeah, an upcoming merge adds them
[19:15:43 CEST] <jamrial> philipl: i'll cherry pick it since it's a bit far away from out current point
[19:19:23 CEST] <cone-834> ffmpeg 03Diego Biurrun 07master:fbc304239fe6: build: Ignore generated .version files
[19:33:47 CEST] <cone-834> ffmpeg 03Michael Niedermayer 07master:c04aa148824f: avcodec/g726: Fix runtime error: left shift of negative value -2
[19:33:48 CEST] <cone-834> ffmpeg 03Michael Niedermayer 07master:0ac1c87194a6: avcodec/eamad: Fix runtime error: signed integer overflow: 49674 * 49858 cannot be represented in type 'int'
[19:33:49 CEST] <cone-834> ffmpeg 03Michael Niedermayer 07master:a38e9797cb41: avcodec/s302m: Fix left shift of 8 by 28 places cannot be represented in type 'int'
[19:33:50 CEST] <cone-834> ffmpeg 03Michael Niedermayer 07master:a5e0dbf530d4: avcodec/aacdec_template: Do not decode 2nd PCE if it will lead to failure
[19:33:51 CEST] <cone-834> ffmpeg 03Michael Niedermayer 07master:441026fcb13a: avcodec/xwddec: Check bpp more completely
[19:48:31 CEST] <cone-834> ffmpeg 03Marton Balint 07master:c0443c1af1a7: lavfi/avfiltergraph: only return EOF in avfilter_graph_request_oldest if all sinks EOFed
[20:00:48 CEST] <cone-834> ffmpeg 03wm4 07release/3.3:059db2204046: ffmpeg: check for unconnected outputs
[20:00:49 CEST] <cone-834> ffmpeg 03Marton Balint 07release/3.3:508e410d348e: lavfi/avfiltergraph: only return EOF in avfilter_graph_request_oldest if all sinks EOFed
[21:01:43 CEST] <alevinsn> wm4: just finished videotoolbox review
[21:22:33 CEST] <durandal_1707> would someone write cmadd SIMD for me?
[21:43:16 CEST] <kierank> durandal_1707: no
[21:44:57 CEST] <durandal_1707> kierank: why?
[21:45:03 CEST] <kierank> i dunno what cmadd is
[21:45:28 CEST] <durandal_1707> complex multiple and add
[23:58:29 CEST] <durandal_1707> jamrial: how should i name function that does complex multiplication and adds result to accumulator?
[23:59:16 CEST] <jamrial> scalarproduct_something?
[00:00:00 CEST] --- Mon May 8 2017
1
0
[00:00:15 CEST] <grublet> the hood on my oven didnt vent properly
[00:00:20 CEST] <furq> i had a job interview on one of those days as well
[00:00:28 CEST] <grublet> so anytime i cooked the house would fill with smoke or steam
[00:00:31 CEST] <furq> i had to shower by filling a bunch of 2-litre coke bottles with water from the kettle
[00:00:36 CEST] <furq> that was fun
[00:00:44 CEST] <grublet> ive taken plenty of sink showers
[00:00:55 CEST] <grublet> when i left my place i slept in my car and showered at the gym
[00:01:15 CEST] <furq> well this was in london, so we were paying £900 pcm for the privilege of getting fucked around like this
[00:01:35 CEST] <grublet> my rent at that shitty complex was $170 a month
[00:01:47 CEST] <furq> yeah i pay less than a third of that for my current place
[00:01:50 CEST] <grublet> now i pay $450 but that includes everyting
[00:02:11 CEST] <grublet> and i live in the gay part of the city, so that's pretty good deal
[00:02:36 CEST] <furq> also at that place in london, the guy downstairs complained that there was a leak coming through from our flat into his bathroom
[00:02:47 CEST] <grublet> i know one gay homeless dude who squats in a place in old louisville with like 4 other gay dudes or w/e
[00:02:55 CEST] <furq> so the landlord came round, determined that it was nothing to do with him, but actually that we were taking such vigorous baths that the water was spilling over the edge of the bath
[00:03:03 CEST] <grublet> furq: my shower would link on the old lady beneath me
[00:03:06 CEST] <furq> even though both of us only ever used the shower
[00:03:15 CEST] <kinkinkijkin> we pay $200 a month plus utilities to live in a crappy-but-maintained old single-floor house in a nice neighbourhood in the middle of all of the bad neighbourhoods
[00:03:16 CEST] <grublet> leak*
[00:03:41 CEST] <furq> so instead of resealing the bath, he went outside, literally looked around in the alley round the back of our house, found a discarded upvc window frame, cut one edge off it, and screwed it to the side of the bath
[00:03:57 CEST] <furq> he actually thought this would work
[00:04:16 CEST] <furq> obviously he was back round a week later to reseal the fucking bath
[00:04:21 CEST] <furq> but he left the windowframe there
[00:04:29 CEST] <grublet> landlords; fuck em
[00:04:29 CEST] <furq> it's probably still there now, baffling the new occupant
[00:04:43 CEST] <furq> that was one of the most mental things i've ever seen anyone do
[00:04:52 CEST] <kinkinkijkin> I know a landlord on espernet who is actually a pretty good landlord
[00:04:54 CEST] <grublet> you havent seen much then
[00:05:06 CEST] <kinkinkijkin> gives his occupants free gigabit via ethernet lol
[00:05:16 CEST] <grublet> kinkinkijkin: furq are you from the uk?
[00:05:27 CEST] <furq> he'd travelled halfway across london to come to the flat, brought his mate with him, and then went to that much effort to avoid paying for a tube of caulk
[00:05:28 CEST] <kinkinkijkin> I'm in canada
[00:05:34 CEST] <grublet> same thing
[00:05:34 CEST] <kinkinkijkin> but this landlord I know is from the US
[00:05:36 CEST] <grublet> just colder
[00:05:40 CEST] <furq> well, "effort"
[00:05:52 CEST] <furq> and yeah i am
[00:05:52 CEST] <kinkinkijkin> lolno, canada is like the US if it were good
[00:06:02 CEST] <kinkinkijkin> the UK is the US of europe
[00:06:16 CEST] <grublet> canada is like the us if we were a territory
[00:07:15 CEST] <kinkinkijkin> oh yeah by the way, I don't recommend using VAAPI encoding on AMD GPUs right now unless you're testing; outputs garbage
[00:07:32 CEST] <kinkinkijkin> and runs at .1x speed for me
[00:07:39 CEST] <grublet> Canada is only good for 2 things. One is Trailer Park Boys, and the other is the Montreal death metal scene
[00:07:51 CEST] <furq> fuck off lahey
[00:08:09 CEST] <kinkinkijkin> let's not get to insulting each others' countries even though I did it first
[00:08:15 CEST] <grublet> Yeah a canadian friend turned me onto that show
[00:08:19 CEST] <kinkinkijkin> ignore my hypocrisy
[00:08:55 CEST] <furq> put a fuckin shirt on randy
[00:09:25 CEST] <grublet> If i were a character from that show, it would probably be randy, just because im fat and gay
[00:10:12 CEST] <furq> you seem more like a cory to me
[00:10:17 CEST] <kinkinkijkin> I am not a character from that show, and I will not pretend to share similarities with any character of that show
[00:10:25 CEST] <furq> i'm obviously cyrus
[00:10:34 CEST] <grublet> i look like julian
[00:10:58 CEST] <grublet> my canadian friend is basically an irl ricky
[00:15:15 CEST] <grublet> furq: https://s-media-cache-ak0.pinimg.com/736x/af/a6/53/afa653f749cb888f9cad2a34…
[00:17:58 CEST] <grublet> i like trailer park boys because it characters and situations could actually exist in real life
[00:28:32 CEST] <kinkinkijkin> heh, x264 is 5x faster at minimum
[00:34:19 CEST] <grublet> kinkinkijkin: 5x faster than what?
[00:34:34 CEST] <kinkinkijkin> h264_vaapi on a 7850
[00:34:41 CEST] <kinkinkijkin> running radeon/mesa
[00:39:47 CEST] <grublet> my gpu is pretty old now
[00:39:53 CEST] <grublet> gtx 670
[01:06:47 CEST] <pomegranate> Hi, I am a newbie and need some guidance. I am trying to write a code that receives a live input stream (rtmp or hls for example), decode a frame every x seconds, and pass the image as an array to another program. Where do you recommend to start?
[01:07:27 CEST] <JEEB> '34
[02:07:21 CEST] <DHE> pomegranate: there's API examples in doc/examples for you to start with. do note that if you only pick a single frame to send then you must either single out keyframes or decode all frames in memory for selection
[03:04:43 CEST] <kinkinkijkin> I have a dilemma: radeon+mesa affords me higher framerates in games and more gpu transcode options
[03:05:14 CEST] <kinkinkijkin> but amdgpu+mesa lets me use svp and has better gpu transcode performace and allows me to use vulkan
[03:07:37 CEST] <c3r1c3-Win> Sounds like a dilemma for AMD to solve. ;-)
[03:12:21 CEST] <kinkinkijkin> oh and then amdgpu pro gives better vulkan and OCL performance but limits my system in ways I'm reluctant to allow
[04:43:07 CEST] <atomnuker> supposing I have an AVPacket of a single jpeg image and I wanted to mux that as a cover image to a flac stream
[04:44:34 CEST] <atomnuker> how would I do that using the lavf API? I'm already writing the flac stream, but can't find any info on just single images
[05:04:37 CEST] <james999> well now i'm gonna listen to a video about #Brexit
[05:04:41 CEST] <james999> this should be interesting
[10:01:11 CEST] <crow> i need to do bisect for an bug which i opened, working release is 3.2.4 and 3.3 is not, but how to find these commit in master? I was checking https://git.ffmpeg.org/gitweb/ffmpeg.git/shortlog and https://git.ffmpeg.org/gitweb/ffmpeg.git/tags but for example i dont get it what is commit from 3.2.4 which is good
[10:13:15 CEST] <furq> crow: https://github.com/FFmpeg/FFmpeg/tags
[10:14:12 CEST] <furq> you can just use the tag name with git bisect though
[10:19:41 CEST] <crow> furq thank you for both, well first time doing bisect so thank you for the tipp
[12:52:52 CEST] <faLUCE> iive: see? nobody cared about the usage example :-)
[13:55:20 CEST] <hiihiii> hello
[13:55:50 CEST] <hiihiii> scale up then double frame rate? or do reverse
[13:56:06 CEST] <hiihiii> double frame rate then scale up?
[13:56:48 CEST] <hiihiii> "scale=480:-1,setsar=1:1,fps=60" vs "fps=30,scale=480:-1,setsar=1:1"
[13:57:03 CEST] <hiihiii> sorry "scale=480:-1,setsar=1:1,fps=60" vs "fps=60,scale=480:-1,setsar=1:1"
[13:59:43 CEST] <hiihiii> I think 1st way is more efficient if ffmpeg scales the frame then outputs it two times in a row
[14:00:02 CEST] <hiihiii> as opposed to double the frame then do scaling for both of them
[14:03:27 CEST] <furq> yeah, scale first
[14:04:20 CEST] <hiihiii> okay
[14:07:47 CEST] <hiihiii> can you explain the tblend filter in terms of what it does to frames
[14:08:34 CEST] <hiihiii> a 60fps : A B C D E F G H
[14:09:00 CEST] <furq> it'll output A+B C+D E+F G+H at 30fps
[14:10:02 CEST] <hiihiii> huh? I run "tblend=all_mode=average" on it and it became 60fps : A+B B+C C+D D+E E+F G+H
[14:10:27 CEST] <hiihiii> well not sure
[14:10:31 CEST] <furq> oh
[14:10:35 CEST] <furq> i'm probably wrong
[14:10:36 CEST] <hiihiii> all I know is that it stayed 60fps
[14:11:58 CEST] <hiihiii> so it must have blended the frames to A+B B+C C+D D+E E+F G+H. I can't think of any other way
[14:12:20 CEST] <hiihiii> I had to put "tblend=all_mode=average,fps=30" to get a 30fps
[14:12:31 CEST] <hiihiii> A+B C+D E+F G+H
[15:40:44 CEST] <TheWild> hello
[15:42:08 CEST] <TheWild> can ffmpeg be used to cut MP3 files (and possibly other types) at frame boundaries?
[15:42:46 CEST] <c_14> if you use -c copy it'll cut at frame boundaries by default
[15:49:47 CEST] <TheWild> This worked like a charm! Thank you very much.
[15:50:44 CEST] <TheWild> I regret I didn't know about this software few years ago.
[16:03:39 CEST] <faLUCE> hey, do you know how I can feed av_read_frame with: char* muxed_packet?
[16:04:36 CEST] <faLUCE> (so I can demux muxed_packet)
[16:07:03 CEST] <mosb3rg> hey guys, does anyone have any reading material or reference material on a way to implement the hls cookie system used in ffmpeg to simply load the feed directly into a browser connecting directly, i have been digging around everywhere i just cannot find any documentation on how its done.
[16:58:57 CEST] <main> Hey. Can someone tell me how to compile the ffplay. I have tdm-gcc and VS 2013. I tried to do everything according to the instructions. But I get a lot of mistakes.
[17:00:10 CEST] <JEEB> ffplay needs SDL2 IIRC
[17:01:25 CEST] <tdr> yes it does
[17:02:13 CEST] <main> i have sdl2, msys, yasm. do as told here https://trac.ffmpeg.org/wiki/CompilationGuide/MSVC
[17:02:39 CEST] <JEEB> then time to check config.log
[17:03:28 CEST] <JEEB> also I hope you're on the latest update of vs2013
[17:18:47 CEST] <crow> i am trying to compile an commit but i needed to remove few stuff from configure and now it wont finish compiling https://defuse.ca/b/FbCRnoT5 <- i am doing bisect and i am almost there : "Bisecting: 1 revision left to test after this (roughly 1 step)" .. if i skip it or mark bad as i cant compile would it change a lot on in final result?
[17:24:34 CEST] <nyuszika7h> okay I can't seem to reproduce the issue of getting 4000 kbps for 720x400 with CRF 18 so far, maybe that was in an earlier encode where I wasn't doing deinterlacing/scaling, I'll wait and see with the rest of the episodes
[17:38:19 CEST] <nyuszika7h> heh, exactly 1x encoding speed
[18:10:09 CEST] <faLUCE> Any idea of how I can demux a char* array? do I have to link a custom I/O (avio_ctx) to an AVFormatContext and then call avio_write(avio_ctx, array, size) ?
[18:40:54 CEST] <JEEB> faLUCE: yes if it's not a way that lavf generally reads things then you will have to implement the callbacks for read read (and possibly others)
[18:44:12 CEST] <main> VS2013. Horror, like a pervert, to compile files.
[18:44:13 CEST] <main> It was necessary to replace in all files the expression "static inline" to "statics __inline"
[18:44:15 CEST] <main> Had to comment a few lines. Example cmdutils.c "PRINT_LIB_INFO(avresample, AVRESAMPLE, flags, level);" avresample not found.
[18:44:16 CEST] <main> It was surprisingly assembled. But it works badly. Sound does not play for network stream
[18:44:41 CEST] <JEEB> uhh
[18:44:49 CEST] <JEEB> I'm pretty sure a new enough FFmpeg has that inline stuff
[18:45:01 CEST] <JEEB> since MSVC2013/2015/2017 work out of the box
[18:45:26 CEST] <JEEB> ctrl+F microsoft on http://fate.ffmpeg.org/
[18:45:33 CEST] <JEEB> those are the automated tests run on master
[18:49:24 CEST] <main> thank You. I did not know about this page
[18:49:51 CEST] <main> failed test for VC2013
[18:53:04 CEST] <JEEB> yea, but as far as I know no need for your change as it should be done by the configure script
[18:53:16 CEST] <JEEB> or I think it might even be just under an ifdef
[18:53:46 CEST] <JEEB> what I'm aiming at is that the change that you were doing is there, otherwise I would've not been able to build FFmpeg with MSVC either :P
[18:53:56 CEST] <JEEB> (I have built it with 2013,2015 and 2017)
[18:55:52 CEST] <main> I will be very grateful if you will help me . Send me please a project file "*.sln" or "*.vcxproj", so that it works out of the box. My task is only ffplay.
[18:58:16 CEST] <main> i used the source code "ffmpeg-20170503-a75ef15-win32-dev"
[19:02:28 CEST] <JEEB> no, you use the build system to get the compiles
[19:02:37 CEST] <JEEB> heck, I even linked you the FATE configurations
[19:03:42 CEST] <main> In an ideal I want to change a little ffplay to build as "dll" and to make some interface outside, but it is impossible to build really even "exe" ))
[19:04:04 CEST] <JEEB> no, ffplay is a proof of concept thing
[19:04:11 CEST] <JEEB> if you want a player use libvlc or libmpv as a base
[19:09:33 CEST] <main> I need the ffmpeg, i could write my own player, but it's easier to take a ready-made implementation. Ffplay for this fits.
[19:10:08 CEST] <JEEB> I'm pretty much sure it doesn't
[19:10:34 CEST] <JEEB> libvlc is LGPL and most likely a better fit if you actually need a player
[19:10:49 CEST] <JEEB> it also uses FFmpeg in the background
[19:10:55 CEST] <JEEB> and is more tested than ffplay
[19:11:03 CEST] <JEEB> (and is less of a PoC than ffplay)
[19:24:23 CEST] <crow> can someone these compiling these two skiped commits in this bug report https://trac.ffmpeg.org/ticket/6364#comment:3 because of that a first bad commit is not found. and I am not sure why it does not get compiled
[19:26:35 CEST] <BtbN> just disable-doc?
[19:51:09 CEST] <crow> ok let me check
[20:16:01 CEST] <faLUCE> [18:40] <JEEB> faLUCE: yes if it's not a way that lavf generally reads things then you will have to implement the callbacks for read read (and possibly others) <--- sorry for my late answer, so, I do I have to call avio_write(), then av_read_frame() with a custom read callback (avio_alloc_context(avio_ctx_buffer, avio_ctx_buffer_size, 0, &bd, &read_packet, NULL, NULL) ) ?
[20:23:49 CEST] <kinkinkijkin> anybody know an alternative to SVP for frame interpolation? I'm okay with reencoding beforehand
[20:25:31 CEST] <durandal_1707> kinkinkijkin: vapoursynth and mvtools
[20:27:50 CEST] <kinkinkijkin> do I have to write anything myself to use this?
[20:27:55 CEST] <kinkinkijkin> it looks like I do
[20:30:16 CEST] <faLUCE> I'm seeing that avio_reading uses av_file_map() in order to provide to the aviocontext the muxed data: https://ffmpeg.org/doxygen/3.2/avio_reading_8c-example.html#a14 ... What should I use if I don't have a file but char* arrays?
[20:31:23 CEST] <JEEB> faLUCE: this is old code but this is all I did with IStreams :P https://github.com/jeeb/matroska_thumbnails/blob/master/src/matroska_thumbn…
[20:31:42 CEST] <JEEB> and I didn't have to call anything extra as the callbacks got used
[20:32:00 CEST] <JEEB> https://github.com/jeeb/matroska_thumbnails/blob/master/src/istream_wrapper…
[20:32:07 CEST] <JEEB> this is the functions themselves :P
[20:32:24 CEST] <JEEB> I mean, it's not harder than that
[20:34:55 CEST] <faLUCE> thanks JEEB, this was what I did, more or less. But I don't see avio_write() ... how do you provide arrays to the muxer?
[20:35:05 CEST] <JEEB> I didn't do any muxing
[20:35:12 CEST] <faLUCE> demuxer
[20:35:14 CEST] <JEEB> so if you are doing muxing you provide the writer callback
[20:35:21 CEST] <faLUCE> I'm doing demuxing
[20:35:32 CEST] <JEEB> then just reading stuff is all you need, and if you can seeking :P
[20:35:42 CEST] <JEEB> I don't see where the writing comes to play
[20:36:49 CEST] <faLUCE> but the read callback is called after av_read_frame() .... I need to know how to feed the demuxer with the char* arrays of muxed data
[20:37:04 CEST] <faLUCE> I tried avio_write() but I don't know if it is the right method
[20:37:07 CEST] <JEEB> what
[20:37:18 CEST] <JEEB> the callback will get called when the thing wants data from you
[20:37:23 CEST] <JEEB> I don't get what's the problem there
[20:38:11 CEST] <faLUCE> JEEB: now I see. I thought that the read callback was called after av_read_frame
[20:38:32 CEST] <faLUCE> ok, thanks, let's try
[20:41:49 CEST] <faLUCE> more precisely: it's called after av_read_frame(), and inside it I have to fill the buffer with custom data
[20:41:51 CEST] <faLUCE> right?
[20:41:58 CEST] <kinkinkijkin> durandal_1707, do I have to write anything myself for using mvtools? if so, how much writing will I have to do?
[20:43:11 CEST] <durandal_1707> kinkinkijkin: download vapoursynth and mvtools and write script
[20:43:30 CEST] <furq> https://kaangenc.me/mpv/
[20:43:34 CEST] <furq> kinkinkijkin: there's a sample script there
[20:44:23 CEST] <JEEB> faLUCE: if av_read_frame was the demuxing function then yes, within it if it will require more data it will ask you for it through that callback
[20:45:36 CEST] <kinkinkijkin> thanks furq
[20:52:52 CEST] <crow> BtbN seems it does not work, as if i disable that link ffmpeg will not be made in packages
[20:53:06 CEST] <crow> BtbN make: *** No rule to make target 'ffmpeg.1'. Stop.
[20:53:30 CEST] <BtbN> probably in the middle of some broken merge then, an can be safely ignored
[20:53:41 CEST] <kinkinkijkin> furq this implies you can't use vapoursynth with hwdec, is this so?
[20:55:04 CEST] <crow> BtbN this is PKGBUILD (archlinux build file) https://defuse.ca/b/IQOtEhbq
[20:56:03 CEST] <BtbN> so?
[20:58:59 CEST] <crow> do you see anything suspect not to build ffmpeg binary file?
[20:59:32 CEST] <crow> as with line 32 commented out it builds but no /usr/bin/ffmpeg
[21:00:32 CEST] <BtbN> when building those specific commits?
[21:00:39 CEST] <crow> exactly
[21:00:53 CEST] <BtbN> they are probably libav merges, and thus it'll build avconv instead.
[21:03:37 CEST] <kinkinkijkin> furq, contrary to the implications of this post, this does in fact work with hwdec
[21:16:52 CEST] <kinkinkijkin> hmmm, mvtools' framerate upscaling is less consistent than SVP but also has far less artifacts
[21:17:53 CEST] <crow> BtbN that was it, it build avconv . now my bisecting was done, and this seems as bad commit http://git.ffmpeg.org/gitweb/ffmpeg.git/commit/744801989099df26e90b00062c64… for https://trac.ffmpeg.org/ticket/6364
[23:17:32 CEST] <faLUCE> JEEB: I'm seeing that avformat_open_input() calls the read callback and wants a number of muxed bytes to buffer. Is there a way to know this number before calling avformat_open_input() ?
[23:18:10 CEST] <faLUCE> (In this way I can buffer enough bytes before calling it)
[23:18:21 CEST] <JEEB> not really
[23:19:28 CEST] <faLUCE> damn...
[23:21:09 CEST] <JEEB> generally if you really run out of bytes you can't do much more than block (or try to tell you don't have the bytes yet by returning less)
[23:22:59 CEST] <faLUCE> JEEB: if I return less than bufsize, then do I have to call avformaT_open_input() again?
[23:23:18 CEST] <faLUCE> (when I have enough bytes)
[23:24:00 CEST] <JEEB> depends. it might just be going to retry the reading by itself.
[23:24:18 CEST] <JEEB> or it just will try to guess your input format without actually reading any bytes
[23:24:35 CEST] <JEEB> if you know your demuxer before hand it'd probably a be a good idea to define that :P
[23:24:59 CEST] <JEEB> and then after it picks the demuxer you probably can start just reading data and it will ask you for more buffer each time :P
[23:26:14 CEST] <faLUCE> [23:24] <JEEB> or it just will try to guess your input format without actually reading any bytes <--- I can do that, but do I have to call avformat_open_input() in this case too?
[23:27:07 CEST] <faLUCE> sorry, wrong question
[23:30:07 CEST] <faLUCE> the correct question is: I call avformaT_open_input(), and I see, inside the read callback, that it needs more bytes than what I actually have. How can I retry that, without blocking??
[23:30:28 CEST] <JEEB> IO tends to be blocking
[23:31:08 CEST] <faLUCE> I know, but I'm trying to avoid blocking
[23:31:49 CEST] <JEEB> you can only do that to a limit without threads for the IO and trying to pre-empt
[23:31:57 CEST] <JEEB> like, you get a successful return from the open
[23:32:05 CEST] <JEEB> (by not returning any data)
[23:32:16 CEST] <JEEB> (or by having X amount of bytes returned)
[23:32:37 CEST] <JEEB> and then of course the next stuff would be to call the read() function which can need X or Y amount of bytes
[23:32:45 CEST] <JEEB> depending on the format and the size of coded samples etc
[23:33:12 CEST] <faLUCE> JEEB: yes, I suspected that. So, do I have to return less bytes from the callback, so that avformaT_open_input() returns unsucessful, and then I know that I have to call it again?
[23:33:48 CEST] <JEEB> only if it doesn't succeed, I mean most likely it will pick some demuxer (although you can define the correct demuxer in various ways)
[23:34:01 CEST] <JEEB> after which it's just reading that you need to do
[23:34:56 CEST] <faLUCE> what I wonder is: if I return less bytes from the callback, does avformaT_open_input() returns unsucessful, so I can re-call it?
[23:35:55 CEST] <JEEB> I don't know, because you might want to open a demuxer without feeding any data to it yet :P
[23:36:16 CEST] <JEEB> so in theory as long as the opening of the demuxer succeeds you should be able to move to the reading phase instead
[23:36:21 CEST] <JEEB> but what do I know :P
[23:37:01 CEST] <faLUCE> do you mean that another solution would be opening a demuxer with correct infos, so it doesn't need to buffer while avformat_open_input() ?
[23:37:29 CEST] <JEEB> if you know your input format for the demuxer before hand that would make sense yes
[23:37:38 CEST] <JEEB> that you tell that it will be MPEG-TS, for example :P
[23:37:57 CEST] <faLUCE> I don't think so... I suspect this is true for av_find_stream_info()
[23:38:06 CEST] <faLUCE> but not for avformat_open_input()
[23:39:37 CEST] <faLUCE> I think that avformat_open_input() is only some buffering stuff, but not probing stuff
[23:39:45 CEST] <faLUCE> but I can be wrong
[23:43:55 CEST] <JEEB> https://ffmpeg.org/doxygen/trunk/structAVFormatContext.html#a78efc5a53c21c8…
[23:44:10 CEST] <JEEB> the input format gets set by avformat_open_input
[23:49:35 CEST] <faLUCE> right. I could try to open the demuxer by manually filling iformat = MPEGTS, but I suspect that it wants other fields to be set... (streams with codecs)
[23:49:47 CEST] <faLUCE> JEEB
[23:50:36 CEST] <JEEB> well mpeg-ts brings you streams on runtime
[23:50:44 CEST] <JEEB> as you keep reading packets
[00:00:00 CEST] --- Mon May 8 2017
1
0
[00:00:23 CEST] <draean> more specifically, say it's there for a few minutes, then drops out, but I want to continue encoding video, just with blank audio, until it comes back in, then start mixing them again.
[00:04:05 CEST] <faLUCE> arog: private msg, I'm going to help you
[00:25:05 CEST] <hiihiii> hello
[00:26:17 CEST] <hiihiii> I was reading a bit about tinterlace filter
[00:26:42 CEST] <hiihiii> and I don't think I understand the modes correctly
[00:27:31 CEST] <hiihiii> I'm looking to make a 60i from a 30p video
[00:27:51 CEST] <hiihiii> so if I have
[00:28:33 CEST] <hiihiii> frmaes of 30p : [A] [B] [C] [D]
[00:29:53 CEST] <hiihiii> frames of 60i : [A0] [A1] [B0] [B1] [C0] [C1] [D0] [D1] with 1 & 0 denoting even & odd fields respectively
[00:30:57 CEST] <hiihiii> interlacex2 mode seems to be the answer but not sure
[00:33:22 CEST] <hiihiii> then there are these flags -flags +ilme+ildct -alternate_scan 1 -top 0, that I don't know if I can set in conjunction with tinterlace filter
[00:39:34 CEST] <zerodefect> hiihiii: Can you not use the 'separatefields' filter?
[00:42:56 CEST] <hiihiii> zerodefect: okay give me a sec. I'll read that
[00:44:18 CEST] <zerodefect> Admittedly, I don't quite understand how it determines the field dominance with that filter though
[00:49:27 CEST] <james999> hmm are there NLEs for linux that use ffmpeg libraries?
[00:50:24 CEST] <hiihiii> zerodefect: but it says half height
[00:51:12 CEST] <hiihiii> field dominance is not an issue though
[00:52:12 CEST] <zerodefect> Yes...i think it's say that each field will be half the height of your progressive scan
[00:52:49 CEST] <zerodefect> *saying
[00:53:38 CEST] <hiihiii> and... if I deinterlace that I would get original height back?
[00:54:23 CEST] <hiihiii> or if I would play it in a media player I'd get full height?
[00:54:43 CEST] <zerodefect> Yes to both of those
[00:54:51 CEST] <zerodefect> ...that is my interpretation of the docs :)
[00:54:52 CEST] <hiihiii> oh ok
[00:55:03 CEST] <zerodefect> Not tried both those filters
[00:55:46 CEST] <hiihiii> I wish they had filters and options grouped together
[00:56:17 CEST] <hiihiii> like having a section of al filters dealing with interlaced footage
[00:56:49 CEST] <hiihiii> they have stuff all over the place, weave interlace tinterlace doubleweave select
[00:57:12 CEST] <zerodefect> It's not helped by the fact that there are so many video filters :)
[00:58:57 CEST] <hiihiii> here's what I'm really trying to achieve. I'd like to go from a 60p to 120i to 60p again then to 30p
[01:00:12 CEST] <zerodefect> Can I ask why?
[01:00:44 CEST] <hiihiii> because then I'd end up with a video whose frames look like this [A0+B1] [C0+D1] [E0+F1] [G0+H1]...
[01:01:50 CEST] <hiihiii> useful for a specific game
[01:02:17 CEST] <zerodefect> https://ffmpeg.org/ffmpeg-filters.html#interlace
[01:02:27 CEST] <zerodefect> There is an interlace filter....that is actually the one you want
[01:02:47 CEST] <hiihiii> I know I've listed it up
[01:04:46 CEST] <hiihiii> I got confused when I knew about the other filters and flags
[01:05:58 CEST] <hiihiii> on one forum, someonesaid that +ildct reduces DCT ringing artifacts https://forum.videohelp.com/attachment.php?attachmentid=18161&d=1370191855
[01:06:48 CEST] <hiihiii> was wondering if I could use that with the other flags
[01:08:08 CEST] <zerodefect> Yeah, I'm not sure.
[01:08:15 CEST] <zerodefect> I need to run though.
[01:11:55 CEST] <hiihiii> it always ends with you having to do your own tests
[01:22:27 CEST] <hiihiii> huh? I run -vf "interlace" -crf 0 output.mp4 and it gave me progressive scan
[01:24:39 CEST] <furq> hiihiii: -flags +ilme+ildct
[01:30:29 CEST] <hiihiii> ok thx
[02:24:47 CEST] <hiihiii> wait... if I couldn't get MBAFF scan type with -vf interlace, only when I added -flags +ilme+ildct, then shouldn't the flags be enough
[02:25:02 CEST] <hiihiii> i'll run a test
[02:30:18 CEST] <hiihiii> looks the same as "fps=60,interlace"
[02:30:59 CEST] <hiihiii> without me having to double the framerate
[02:46:44 CEST] <Guest23360> who can recompile ffmpeg for me
[03:44:20 CEST] <kinkinkijkin> https://pastebin.com/kDDD8vSx hello, I'm running into the error "undefined constant or missing '(' in 'baseline'" while trying to transcode video using ffmpeg
[03:45:51 CEST] <kinkinkijkin> the currently-used encoder is h264_vaapi but the issue persists with other encoders
[03:46:25 CEST] <hiihiii> maybe you should specify -level
[03:46:45 CEST] <kinkinkijkin> changes nothing
[03:47:11 CEST] <hiihiii> -level has arguments
[03:47:21 CEST] <kinkinkijkin> I know
[03:47:26 CEST] <kinkinkijkin> I specified 3.0
[03:47:56 CEST] <hiihiii> ok
[03:48:26 CEST] <hiihiii> how about 3.1
[03:48:38 CEST] <furq> that won't make any difference
[03:48:51 CEST] <cryptodechange> Going through some DVDs I passed through MakeMKV
[03:49:03 CEST] <furq> kinkinkijkin: do you get the same issue with libx264
[03:49:08 CEST] <furq> because that looks like something's just broken
[03:49:10 CEST] <cryptodechange> One source, don't notice any lines, but there is blending between frames
[03:49:40 CEST] <furq> cryptodechange: welcome to the world of badly deinterlaced dvds
[03:50:14 CEST] <kinkinkijkin> no, libx264 with most of my options stripped succeeds
[03:51:14 CEST] <furq> does -profile:v 66 work
[03:51:47 CEST] <furq> with h264_vaapi
[03:52:24 CEST] <kinkinkijkin> almost
[03:52:53 CEST] <kinkinkijkin> new output https://pastebin.com/9yfwwXUV
[03:55:17 CEST] <cryptodechange> furq
[03:55:17 CEST] <cryptodechange> https://imgur.com/a/QmDqm
[03:55:24 CEST] <cryptodechange> What do you suggest in this situation? Leave as is?
[03:55:30 CEST] <cryptodechange> Encode as is*
[03:55:58 CEST] <furq> that's just a shitty transfer
[03:57:08 CEST] <cryptodechange> from VHS?
[03:58:19 CEST] <furq> no it's just a badly done telecine
[03:58:26 CEST] <furq> if it's ntsc then you might be able to ivtc it
[03:59:17 CEST] <cryptodechange> 25 fps PAL
[03:59:24 CEST] <furq> rip
[03:59:42 CEST] <furq> field blended pal is pretty much a nightmare
[04:02:19 CEST] <kinkinkijkin> wait, if I switch from distro-provided ffmpeg to manually-compiled ffmpeg, do I also have to manually-compile libav?
[04:02:31 CEST] <furq> you already did
[04:02:51 CEST] <kinkinkijkin> ah
[04:03:17 CEST] <kinkinkijkin> so I'm running dry for ideas on what could be causing this
[04:03:42 CEST] <kinkinkijkin> it's just saying encoding profile not found but it also dumps a warning about the current encoding profile
[04:03:48 CEST] <furq> if it wsa a library mismatch then ffmpeg would yell at you abou tit
[04:03:59 CEST] <furq> i've never used vaapi so i have no idea what's going on there
[04:04:20 CEST] <furq> i assume that message means the device doesn't support that profile
[04:04:20 CEST] <cryptodechange> What's the solution? figure out the normal to blended frame ratio and knock down the FPS?
[04:04:49 CEST] <furq> i've not really worked enough with animation to know
[04:05:03 CEST] <furq> there are doubtless some avisynth scripts that deal with this sort of thing
[04:07:22 CEST] <draean> I need to take in an audio stream source that may come and go, but if it's gone, I want to continue streaming, just play silence. is there a way to do that with ffmpeg? or is there another program I could use to stream black audio merged with the stream source to ffmpeg?
[04:08:14 CEST] <james999> <furq> cryptodechange: welcome to the world of badly deinterlaced dvds
[04:08:17 CEST] <james999> ^ this
[04:08:56 CEST] <furq> yeah that's particularly bad
[04:09:28 CEST] <kinkinkijkin> what are the names of the hevc profiles?
[04:12:37 CEST] <furq> https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Profiles
[04:12:42 CEST] <furq> ffmpeg doesn't have aliases for them yet iirc
[04:12:47 CEST] <furq> you have to set the options manually for x265
[04:16:51 CEST] <kinkinkijkin> furq do you know which I should input, though?
[04:17:02 CEST] <kinkinkijkin> main doesn't work
[04:27:17 CEST] <cryptodechange> <furq> there are doubtless some avisynth scripts that deal with this sort of thing
[04:27:22 CEST] <cryptodechange> any examples i can look for?
[04:27:31 CEST] <cryptodechange> I have some content with some clear telecine
[04:28:18 CEST] <kinkinkijkin> found the issue, mesa vaapi driver doesn't support my gpu while using amdgpu instead of radeon
[04:28:24 CEST] <kinkinkijkin> should've checked that first
[04:28:33 CEST] <kinkinkijkin> going to go back to radeon and verify this is really it
[04:32:27 CEST] <cryptodechange> https://imgur.com/a/SOOVw
[04:32:40 CEST] <cryptodechange> This source looks like every 1st, 2nd, 3rd frame is ok, 4th 5th is not
[04:36:08 CEST] <kinkinkijkin> okay, I now have access to vaapi fully
[04:36:13 CEST] <kinkinkijkin> ... and the issue persists
[04:55:58 CEST] <kinkinkijkin> what is the number I should put for the profile if I want to use main, instead of baseline, for x264
[04:56:18 CEST] <kinkinkijkin> my driver doesn't actually able to encode to baseline
[04:56:26 CEST] <kinkinkijkin> only main, high, and constrainedbaseline
[04:57:03 CEST] <furq> 77
[04:57:07 CEST] <kinkinkijkin> thanks
[04:58:29 CEST] <kinkinkijkin> now I'm getting just "b frames are now supported"
[05:02:26 CEST] <kinkinkijkin> it's working with -bf 0
[05:17:02 CEST] <cryptodechange> So I have a NTSC source, 29.97 FPS and interlaced
[05:18:00 CEST] <cryptodechange> -vf fieldmatch,decimate ?
[05:18:42 CEST] <furq> do you mean interlaced or telecined
[05:19:09 CEST] <cryptodechange> https://imgur.com/a/SOOVw
[05:19:41 CEST] <cryptodechange> 3 progessive, 2 split, so telecine?
[05:19:41 CEST] <dystopia_> thats not interlaced
[05:19:44 CEST] <thebombzen> looks telecined
[05:19:52 CEST] <thebombzen> have you tried -vf fieldmatch,decimate
[05:19:54 CEST] <cryptodechange> Google told me
[05:20:18 CEST] <cryptodechange> Interlace is 100% split, I guess? Telecine is mix of progressive and split
[05:20:53 CEST] <furq> -vf fieldmatch,bwdif=deint=interlaced,decimate
[05:20:58 CEST] <furq> is apparently a good way to go
[05:21:41 CEST] <thebombzen> I'm not sure how it compares to -vf pullup
[05:21:43 CEST] <cryptodechange> i'll do -preset fast -tune animation to try some out
[05:22:00 CEST] <cryptodechange> I found this
[05:22:02 CEST] <cryptodechange> https://forum.doom9.org/showthread.php?t=172289
[05:22:09 CEST] <furq> yeah try -vf pullup as well
[05:22:12 CEST] <cryptodechange> -vf fieldmatch,yadif=deint=interlaced
[05:22:18 CEST] <thebombzen> btw, what movie is that from
[05:22:22 CEST] <furq> bwdif is better than yadif
[05:22:25 CEST] <furq> and you need decimate afterwards
[05:22:27 CEST] <cryptodechange> Dragonball GT DVD set
[05:22:35 CEST] Action: cryptodechange ducks
[05:22:43 CEST] <thebombzen> I mean it looks like old anime
[05:22:46 CEST] <furq> also wrt that x-men or whatever it was dvd, you probably just want to find an ntsc source
[05:23:00 CEST] <thebombzen> sad that the put the telecined version on the dv
[05:23:03 CEST] <furq> you're never going to get a clean rip from field blended garbage
[05:23:04 CEST] <thebombzen> on the dvd and not the source
[05:23:30 CEST] <cryptodechange> I kind of regret getting the entire set from Amazon now
[05:23:35 CEST] <cryptodechange> Should've bought from .com and .co.uk
[05:23:41 CEST] <cryptodechange> not .co.uk*
[05:23:59 CEST] <furq> yeah it's annoying
[05:24:07 CEST] <furq> proper film to pal is ideal if the only source is dvd
[05:24:13 CEST] <cryptodechange> https://imgur.com/a/QmDqm
[05:24:19 CEST] <cryptodechange> for thebombzen
[05:24:30 CEST] <furq> but the flip side is that you sometimes get film to ntsc to pal, which is fucking disgusting
[05:24:56 CEST] <dystopia_> ghosting and needs a big crop :(
[05:25:05 CEST] <thebombzen> cryptodechange: that doesn't look like dragonball gt
[05:25:06 CEST] <furq> you really need to use your player's screenshot function
[05:25:08 CEST] <thebombzen> that looks like xmen
[05:25:22 CEST] <cryptodechange> It is :D
[05:25:25 CEST] <thebombzen> and I think VLC can just screenshot the video
[05:25:30 CEST] <thebombzen> I know mpv can
[05:25:31 CEST] <furq> notice how i said "your player" to avoid even coming close to endorsing the use of vlc for anything ever
[05:25:43 CEST] <thebombzen> well to be fair
[05:26:04 CEST] <thebombzen> calling VLC terrible is unfair because we use Linux and we're used to CLI players
[05:26:13 CEST] <furq> maybe you do
[05:26:33 CEST] <thebombzen> for people on windows who only ever use GUIs, VLC isn't so bad, especially since most of them are used to WMP
[05:26:40 CEST] <furq> sure
[05:26:44 CEST] <furq> some things do smell worse than shit
[05:26:48 CEST] <dystopia_> i prefer mpc in windows
[05:26:52 CEST] <dystopia_> vlc seems bloated
[05:27:00 CEST] <cryptodechange> So uh
[05:27:03 CEST] <thebombzen> vlc isn't great mind you but it's not godawful
[05:27:04 CEST] <cryptodechange> Should I trash the x-men?
[05:27:11 CEST] <furq> if you can find an ntsc source then yeah
[05:27:20 CEST] <thebombzen> cryptodechange: you should X it
[05:27:22 CEST] <furq> that's a bad pal transfer from ntsc
[05:27:28 CEST] <furq> rather than from the master
[05:27:34 CEST] <cryptodechange> X?
[05:27:36 CEST] <furq> so it's of absolutely no value
[05:27:38 CEST] <thebombzen> pun
[05:27:44 CEST] <thebombzen> "axe it" is a slang term for cut it
[05:27:48 CEST] <thebombzen> but it's X men
[05:27:49 CEST] <thebombzen> so X it
[05:27:51 CEST] <thebombzen> nvm
[05:27:54 CEST] <cryptodechange> oh
[05:27:56 CEST] <cryptodechange> lel
[05:28:23 CEST] <thebombzen> yea you should trash it if you can find anything better. the source you have isn't really worth keeping unless its' the only thing
[05:28:35 CEST] <kinkinkijkin> anybody here use obs? I need help translating an ffmpeg command to their ffmpeg command auto-generating interface
[05:28:43 CEST] <furq> it's comic book shit so i'm sure it'll be easy to find
[05:28:45 CEST] <kinkinkijkin> since they removed custom commands
[05:28:52 CEST] <thebombzen> kinkinkijkin: they did not remove custom commands
[05:29:00 CEST] <thebombzen> you have to go to advanced output and select FFmpeg output to file
[05:29:09 CEST] <cryptodechange> note to self, avoid old animated stuff on DVD
[05:29:13 CEST] <furq> i would not feel bad about pirating it after spending money on such a piece of shit dvd
[05:29:13 CEST] <cryptodechange> from UK*
[05:29:21 CEST] <kinkinkijkin> I did, I still get an autogenerator
[05:29:23 CEST] <cryptodechange> ikr
[05:29:28 CEST] <thebombzen> oh you mean that thing
[05:29:32 CEST] <thebombzen> yea
[05:29:37 CEST] <thebombzen> what command did you have
[05:29:43 CEST] <furq> also to reiterate again, a lot of pal dvds are better than ntsc
[05:29:58 CEST] <furq> so i guess try and check if it sucks
[05:30:01 CEST] <furq> before buying
[05:30:08 CEST] <kinkinkijkin> ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -vf format='nv12|vaapi,hwupload' -threads 1 -f matroska -b:v 1M -minrate 1M -maxrate 1M -vcodec h264_vaapi -bf 0 -profile:v 77
[05:30:28 CEST] <furq> does obs use vaapi for vce
[05:30:33 CEST] <furq> i thought it had some bindings which actually work properly
[05:30:34 CEST] <kinkinkijkin> the -hwaccel and -vaapi_device passes are extremely important as they're the only things that make vaapi work
[05:30:41 CEST] <kinkinkijkin> VCE isn't implemented linux-side
[05:30:42 CEST] <furq> that might just be on windows though
[05:30:50 CEST] <furq> fair enough
[05:30:58 CEST] <thebombzen> kinkinkijkin: there's "custom muxer commands"
[05:31:00 CEST] <furq> i didn't think vce worked properly with vaapi yet
[05:31:00 CEST] <thebombzen> try putting it there
[05:31:07 CEST] <thebombzen> I think those are passed verbatim to ffmpeg
[05:31:07 CEST] <furq> it didn't last time someone knowledgeable mentioned it in here
[05:31:59 CEST] <cryptodechange> is there a difference between yadif=deint=interlaced and bwdif=deint=interlaced?
[05:32:16 CEST] <thebombzen> different deinterlacing algorithms
[05:32:19 CEST] <thebombzen> bwdif's is better though
[05:32:36 CEST] <dystopia_> is yadif=deint=interlaced just the same as yadif=0:0
[05:32:49 CEST] <furq> 0:0:1
[05:32:51 CEST] <kinkinkijkin> crap, I can't figure this out
[05:33:02 CEST] <thebombzen> kinkinkijkin: did you try what I suggested
[05:33:07 CEST] <kinkinkijkin> yep
[05:33:13 CEST] <thebombzen> and what happened?
[05:33:20 CEST] <thebombzen> like did you check the OBS logfile
[05:33:22 CEST] <kinkinkijkin> same nondescript error as ever
[05:34:40 CEST] <thebombzen> which is?
[05:34:46 CEST] <thebombzen> also try asking in #obsproject
[05:34:49 CEST] <thebombzen> someone there might know
[05:35:39 CEST] <kinkinkijkin> okay actually, muxer settings does pass them verbatim
[05:36:11 CEST] <cryptodechange> Ok wth
[05:36:15 CEST] <cryptodechange> Some episodes are interlaced
[05:36:22 CEST] <cryptodechange> and not frame blended
[05:37:06 CEST] <cryptodechange> aha
[05:37:11 CEST] <cryptodechange> its the first disc only
[05:37:19 CEST] <cryptodechange> whoever did the first disc screwed up
[05:38:11 CEST] <dystopia_> i used srestore with avisynth to repair some blended ntsc to pal anime conversions but the result was still pretty crappy
[05:40:16 CEST] <cryptodechange> Better than what it was though?
[05:40:22 CEST] <cryptodechange> It's only like, 7 20 minute episodes
[05:42:30 CEST] <furq> yeah i've used srestore to fix some field blended shit
[05:42:47 CEST] <furq> it does a pretty amazing job considering how bad the source was, but it's still not great
[05:43:18 CEST] <cryptodechange> Any guides or whatnot around?
[05:43:19 CEST] <furq> also it looks like what you have is field blended and then run through a shit deinterlacer
[05:43:25 CEST] <furq> i'm not sure if it'll work at all with that
[05:44:27 CEST] <furq> http://avisynth.nl/index.php/Srestore
[05:44:36 CEST] <furq> idk if there's a vapoursynth equivalent
[05:44:44 CEST] <furq> and you're on your own when it comes to getting all the shit you need installed
[05:45:41 CEST] <furq> at least for my source i still had visible blending on scene transitions and stuff
[05:45:48 CEST] <furq> but it was a big improvement
[05:46:03 CEST] <furq> that source was exceptionally bad though
[05:46:15 CEST] <furq> billy blanks deserves better tbh
[05:46:52 CEST] <james999> what is the equivalent of avisynth for linux?
[05:46:57 CEST] <furq> vapoursynth
[05:47:11 CEST] <furq> it's better on windows as well
[05:47:19 CEST] <james999> oh. thought you were talking in slang
[05:47:30 CEST] <furq> it's slightly slower and there aren't as many scripts
[05:47:39 CEST] <furq> but you get multithreading that doesn't randomly crash
[05:47:47 CEST] <james999> i just realized that's maybe a bad question to ask
[05:48:09 CEST] <james999> because it doesn't distinguish between "exact duplicate of the tool from another platform" and "the ordinary tool people on linux would tend to use for this problem"
[05:48:25 CEST] <furq> it's more or less a clone
[05:48:33 CEST] <furq> except it uses python instead of some custom scripting language
[05:48:43 CEST] <james999> yeah. i guess that's not what i intended but it's what i asked lol
[05:48:53 CEST] <furq> that is also the tool you would normally use on linux
[05:49:56 CEST] <james999> i know jack all about video editing on linux though.
[05:50:07 CEST] <james999> seems like gnome and kde were always having some half assed thing for that
[05:50:19 CEST] <furq> if you want an actual NLE then shotcut seems passable
[05:52:18 CEST] <james999> hah i wasn't even wrong. when i google for linux editors first one that comes up is Kdenlive from kde
[05:52:52 CEST] <furq> gnome has pitivi as well
[05:53:03 CEST] <james999> right that's what i thought
[05:53:06 CEST] <furq> which is written in pythona dn uses gstreamer
[05:53:16 CEST] <furq> imagine that!
[05:53:35 CEST] <james999> it's kind of confusing b/c gnome and kde would always compete by both providing a buggy, half-assed application to do something like this lol
[05:53:42 CEST] <furq> yeah
[05:53:54 CEST] <furq> i mean kate vs gedit is fair enough. that's relatively simple
[05:54:00 CEST] <furq> but don't fucking make two competing NLEs
[05:54:02 CEST] <james999> yeah
[05:54:13 CEST] <james999> when you get to that level it's taking it too far imo
[05:54:19 CEST] <james999> i can't even remember the names of everything either
[05:54:20 CEST] <furq> same with shit like gimp vs krita
[05:54:31 CEST] <james999> like it was gwenview for image viewing in kde for awhile. not sure what the gnome one was
[05:54:54 CEST] <furq> "oh it uses the wrong library for drawing widgets, so we rewrote the entire thing and made it suck even more"
[05:55:01 CEST] <furq> thanks linux that's a really helpful attitude
[05:55:44 CEST] <furq> the other nice thing about shotcut is that it's the only linux nle that doesn't have a fucking terrible name
[05:55:53 CEST] <james999> reminds me of that article complaining about freebsd autoconf tools checking for 26 non existent fortran compilers just to compilefirefox
[05:55:54 CEST] <furq> and also it actually works on windows
[05:56:16 CEST] <james999> is it related to openshot? this article says it's also cross platform
[05:56:36 CEST] <furq> they're competitors i think
[05:56:49 CEST] <furq> i've not used either but based on conversations in here, shotcut is better
[05:56:58 CEST] <james999> but regardless it seems like in linux the philosophy is, don't delete code ever and let's both write our own crappy version of photoshop or something
[05:57:56 CEST] <furq> it's pretty much "we're going to fork/develop our own version of this incredibly complex thing because of some fucking insane technicality"
[05:58:50 CEST] <furq> openoffice, ignore this
[05:58:54 CEST] <furq> libreoffice....hello
[05:58:59 CEST] <james999> haha. or because of a trivial argument that can't be resolved, so something gets forked
[05:59:12 CEST] <james999> oooh wasn't that staroffice back in the day?
[05:59:14 CEST] <james999> iirc
[05:59:19 CEST] <furq> i actually forgot about the whole ffmpeg/libav thing while i was typing that
[05:59:33 CEST] <furq> but yeah that's some typical open source bullshit
[05:59:41 CEST] <james999> yeh i read about that yesterday. that was more "let's fork this because fu i'm crazy"
[06:00:18 CEST] <furq> michael niedermayer is a mean bully, so we're going to fucking cause mayhem for years until it all goes to shit
[06:00:38 CEST] <furq> that one actually turned out ok though because of ffmpeg's policy of just merging all their changes
[06:00:58 CEST] <furq> while they pissed away grant money on reinventing libswresample for no reason
[06:02:07 CEST] <james999> i'm not any kind of guru. but i imagine they might have been able to survive if they found a niche
[06:02:21 CEST] <furq> i don't even know what michaelni actually did to earn their ire
[06:02:24 CEST] <james999> like that gimp vs krita thing. it's stupid but at least there are a base of users for each one
[06:02:29 CEST] <furq> i've seen much worse project maintainers
[06:02:43 CEST] <furq> based on everything i've seen of him he just seems permanently exhausted
[06:03:01 CEST] <james999> idk the article i read was saying "anti social nerd gets his project forked" so maybe he was like sheldon on big bang theory and the crybabies couldnt' handle it
[06:03:14 CEST] <furq> i wouldn't want to use anything that was anything like the big bang theory either
[06:03:40 CEST] <james999> although idk how much truth there is to it. i've had to work remotely with a touchy boss before and it can be tiring.
[06:03:41 CEST] <furq> also the gimp vs krita thing is pretty much down to whether you're using gnome or kde
[06:04:04 CEST] <james999> e.g. one time I asked him if this line of javascript was ok because it did xyz and he was like, DO NOT QUESTION MY JAVASCRIPT
[06:04:12 CEST] <furq> it's literally just because kde distros would find it embarrassing to ship with gtk installed
[06:04:16 CEST] <furq> and vice versa
[06:04:45 CEST] <furq> which is a tremendously shit reason to split the userbase and developers between two projects that are nowhere near as good as photoshop
[06:04:50 CEST] <james999> right. but my point is, at least those are users who will use krita say. even if it doesn't matter
[06:05:09 CEST] <furq> well libav had the same thing for a while because it finagled its way into debian
[06:05:10 CEST] <james999> if the libav ppl weren't idiots from the sound of it they might have succeeded in staying separate. just have to find a niche
[06:05:19 CEST] <furq> and a few other major distros
[06:05:31 CEST] <james999> right but taht was basically because they knew someone in debian. not a good long term prospect
[06:06:17 CEST] <furq> that's pretty much how you carve out a niche on linux though
[06:06:24 CEST] <furq> you make it a massive pain in the arse to install the alternative
[06:06:51 CEST] <james999> haha
[06:07:03 CEST] <furq> same with the 700 different file managers that every DE has
[06:07:33 CEST] <james999> idk i was thinking they could optimize something differently than ffmpeg. like go for speed where you go for size. or go for stability where you go for bleeding edge updates. something like that
[06:07:37 CEST] <furq> because every DE has to have their own config manager, and only the apps for that DE will pay attention to its settings
[06:08:04 CEST] <furq> so you install nautilus on xfce and it looks fucked for no reason that an ordinary person would give a shit about
[06:09:24 CEST] <james999> yeah i've heard linuxes accused of being elitist in that way before. and not just by non-techies either
[06:09:55 CEST] <james999> like, i like the command line, i use it a lot. but when you have to use it to do basic tasks like changing a background or something then it's just shit
[06:10:01 CEST] <thebombzen> furq: gimp vs krita isn't the same sort of thing
[06:10:17 CEST] <thebombzen> krita is a digital art drawing program and gimp is a general-purpose image editing program
[06:10:32 CEST] <james999> i think i had to basically do command line fu on debian wheezy just to add a desktop shortcut. literally something that takes a few mouse clicks in windows
[06:10:33 CEST] <thebombzen> gimp is designed to be "a free photoshop" or something similar. krita is not intended to replace photoshop
[06:10:57 CEST] <thebombzen> james999: symblolic links work in most graphical DEs
[06:11:11 CEST] <thebombzen> ln -s /usr/bin/firefox ~/Desktop/ should work
[06:11:35 CEST] <james999> i dont' recall the details, all I recall is I had to use the command line in gnome on wheezy when the comparable operation in windows would be easier.
[06:11:51 CEST] <furq> i mean i normally use linux on servers so i'm perfectly happy using a shell
[06:12:20 CEST] <furq> but even that doesn't work consistently
[06:12:25 CEST] <james999> me too. but the ordinary user doesn't give a crap. if it's an easy thing they're used to doing on windows, and linux makes you open a command line and enter even just 1 arcane command... well then
[06:12:47 CEST] <furq> the answer to "how do i do x" is often one of 19 different things depending on what distro you're on, what DE you're using, what version of the previous two you're using, etc etc etc
[06:13:19 CEST] <thebombzen> well yes Linux is by design defragmented
[06:13:21 CEST] <james999> yeah. at least if they tried to copy windows explorer for common tasks they'd have a unified way. it wouldn't be perfect, but at least it wouldn't be that
[06:13:28 CEST] <thebombzen> it depends on which system you have installed
[06:13:31 CEST] <furq> you mean fragmented
[06:13:33 CEST] <thebombzen> yes I do
[06:13:48 CEST] <thebombzen> although I look at it differently
[06:14:04 CEST] <thebombzen> I see it as "on Linux the CLI is very easy to use" whereas on windows the cli is... not
[06:14:16 CEST] <thebombzen> there's no builtin windows CLI http client for example like cURL or wget
[06:14:21 CEST] <furq> i just said i don't care about having to use the cli
[06:14:27 CEST] <furq> that's a different issue from the fragmentation
[06:14:35 CEST] <thebombzen> correct
[06:14:37 CEST] <james999> the thing is people use macintosh a lot too, it has a command line, but nobody ever complains about usability on there like they would for linux
[06:14:39 CEST] <thebombzen> I'm commenting on the other thing
[06:14:44 CEST] <furq> the normal apologist answer i see is "oh...it's about choice"
[06:14:49 CEST] <furq> but it's not. it's the opposite
[06:14:58 CEST] <furq> if i want to install some alternative thing in windows it'll work
[06:15:13 CEST] <furq> on linux it won't because i'm using the wrong DE or some bullshit i don't care about
[06:15:23 CEST] <thebombzen> furq: this is not really true anymore
[06:15:36 CEST] <thebombzen> I install KDE applications on my MATE desktop all the time
[06:15:49 CEST] <thebombzen> like KVIrc, k3b, krita, or kdenlive
[06:15:51 CEST] <furq> do they look correct without any configuration
[06:16:11 CEST] <thebombzen> they look correct with the same amount of configuration as my mate DE has
[06:16:12 CEST] <james999> ah i used k3b all the time on my laptop. *nostalgia*
[06:16:13 CEST] <furq> last time i installed a kde app in a gtk de it looked fucked
[06:16:22 CEST] <thebombzen> I just need to install oxygen-icons and everything is fine
[06:16:24 CEST] <furq> it didn't even use the same fonts
[06:16:33 CEST] <thebombzen> that's an old problem
[06:16:36 CEST] <furq> different theme, different fonts, different font rendering somehow
[06:16:45 CEST] <thebombzen> nowadays, kde aps look fine on gtk desktops
[06:16:57 CEST] <thebombzen> they look like all your other qt apps
[06:17:05 CEST] <thebombzen> which look fine
[06:17:06 CEST] <furq> but i want them to look like all my gtk apps
[06:17:16 CEST] <furq> or at least similar enough
[06:17:22 CEST] <thebombzen> they look close enough that I don't care
[06:17:57 CEST] <thebombzen> that's also like the same problem on windows. projects using different abstraction toolkits won't look the same as projects using the native windows api
[06:18:07 CEST] <furq> that's only really true for gtk
[06:18:15 CEST] <furq> most stuff looks more or less native
[06:18:26 CEST] <james999> java interfaces did used to look pretty shit on windows
[06:18:32 CEST] <thebombzen> they look pretty shit always
[06:18:33 CEST] <furq> yeah but java is always shit everywhere
[06:18:50 CEST] <james999> haha i haven't used one in awhile, or if i did I didn't notice
[06:19:07 CEST] <thebombzen> keep in mind that you're insisting that all your applications look the same which is only possible with forced decustomizability
[06:19:26 CEST] <thebombzen> with macOS, all your applications look the same. the downside is they all look like whatever Steve Jobs says is the best
[06:19:50 CEST] <thebombzen> there's always going to be a tradeoff between having everythign look the same and having everything look exactly how you want it to
[06:20:01 CEST] <furq> there's a middle ground that isn't impossible to achieve though
[06:20:11 CEST] <thebombzen> GTK/QT has that
[06:20:24 CEST] <furq> also it's not just about looks, it's about pointless duplication of effort
[06:20:24 CEST] <james999> is part of the reason ubuntu did so well though that it emulated some of those mac os features?
[06:20:36 CEST] <thebombzen> ubuntu didn't do so well
[06:20:38 CEST] <furq> i don't mind if there are several file managers or text editors or whatever
[06:20:42 CEST] <furq> those are fairly trivial
[06:20:50 CEST] <james999> it's one of the top linux desktops now is it not?
[06:21:00 CEST] <thebombzen> james999: only among people who dont' know any better
[06:21:15 CEST] <furq> but why you would have so many different competing office suites, or NLEs, or graphic editors, when you're already playing catchup to such a huge extent
[06:21:22 CEST] <thebombzen> you don't have so many office suits
[06:21:31 CEST] <furq> and for such spurious reasons as "we didn't like the license" or "it uses the wrong widget toolkit"
[06:21:57 CEST] <thebombzen> as for office suites, the schism was caused by oracle forcing direction of the project that the developers didn't agree with
[06:22:21 CEST] <furq> they donated it to the ASF six years ago
[06:22:29 CEST] <furq> they've had six years to just fucking merge
[06:22:31 CEST] <furq> but they won't
[06:22:40 CEST] <thebombzen> but nobody uses openoffice
[06:22:46 CEST] <furq> of course they do
[06:22:53 CEST] <furq> loads of people don't know that libreoffice exists
[06:23:49 CEST] <thebombzen> as for image editors, there isn't a huge schism. Gimp and Krita aren't replacements for each other and do different things.
[06:24:05 CEST] <thebombzen> as for NLEs, well, yea. They shouldn't do that with NLEs. they all kind of suck.
[06:24:17 CEST] <thebombzen> given that they're all based on opencv and ffmpeg anyway
[06:24:24 CEST] <furq> pitivi isn't
[06:24:27 CEST] <furq> and i don't think kdenlive is
[06:24:36 CEST] <furq> pitivi is gnome so naturally that has to use gstreamer
[06:24:43 CEST] <furq> because the correct thing to do with good money is throw it after bad money
[06:25:45 CEST] <james999> idk i think maybe pride is part of it. like in my example with a shortcut, if they made it work similar to windows or mac that would be admitting the other system was "better" or something
[06:25:59 CEST] <furq> there are plenty of DEs where that is as simple as you'd hope
[06:26:07 CEST] <furq> but the way to do it on all of them is probably different
[06:26:13 CEST] <james999> yeah i was on debian, so i 'm sure you're correct
[06:26:18 CEST] <james999> also correct
[06:26:21 CEST] <thebombzen> kdenlive is based on melt
[06:26:28 CEST] <thebombzen> but it uses ffmpeg for various things
[06:26:42 CEST] <james999> it's common sense to me you'd want to make something simple like that similar to windows
[06:26:46 CEST] <thebombzen> I don't know why but every time something uses gstreamer I just feel bad
[06:26:53 CEST] <furq> i think you do know why
[06:26:54 CEST] <thebombzen> like gstreamer just never works the way I wan tit to
[06:27:05 CEST] <thebombzen> there's nothing obvious I can point out about it
[06:27:16 CEST] <thebombzen> it's more just that it's always ready to break randomly
[06:27:26 CEST] <thebombzen> especially since it just sits atop avcodec I always just want to use avcodec directly
[06:27:56 CEST] <thebombzen> as for the NLE things, yea. NLEs on Linux just suck
[06:28:12 CEST] <thebombzen> I tend to use ffmpeg.c to do most of that stuff
[06:28:55 CEST] <james999> well working together on one big NLE is hard i suppose
[06:29:02 CEST] <james999> you'd have to give up the one you work on now. :)
[06:29:20 CEST] <thebombzen> honestly the whole tookkit thing could be fixed by writing libNLE.so and just linking to it
[06:29:31 CEST] <furq> in other news, my ear is bleeding
[06:29:33 CEST] <furq> pretty cool huh
[06:30:07 CEST] <james999> furq: I found out picking at a scab on my chest caused my chest to bleed. kinda cool as well
[06:31:51 CEST] <furq> yeah that'll happen
[06:45:16 CEST] <james999> weird news story about some tech in america faking lab results to get convictions. now 23,000 prisoners are gonna be released cause of it
[06:45:55 CEST] <james999> what shocked me almost as much was the part where it said the Supreme Court ruled defendants can challenge lab chemists on the witness stand.
[07:38:01 CEST] <c3r1c3-Win> Every Testimony presented in the court of law has the right to be cross-examined.
[07:38:24 CEST] <c3r1c3-Win> If it can not be cross-examined, it can not be presented.
[07:54:27 CEST] <james999> well that's what they ruled
[07:54:38 CEST] <james999> what bugs me about that is that for a case to get to the Supreme Court takes a lot of steps
[07:54:56 CEST] <james999> often with judges disagreeing about it
[07:55:40 CEST] <james999> so there must have been some support for not allowing the lab techs to be called
[08:09:31 CEST] <c3r1c3-Win> Every single judge along the way could have ruled the same way... that said I have no idea what judges ruled which ways.
[08:12:23 CEST] <james999> you're saying the S.C. sometimes hears cases... and just agrees with every lower court?
[08:12:34 CEST] <james999> i mean they could just not hear it for the same effect right?
[08:27:22 CEST] <c3r1c3-Win> Depends.
[08:28:11 CEST] <c3r1c3-Win> Lets' say the 9thcircuit and 8th circuit have both ruled in agreement... then one side appeals. The SC can look at the case nad say "This is important enough that we need to make a ruling on it" and then hear the case and make a decision.
[08:28:55 CEST] <c3r1c3-Win> Hell, the SC can pick any federal case in any docket and decide to hear and rule on it.
[09:06:37 CEST] <thebombzen> james999: the supreme court hears 100 cases a year
[09:06:41 CEST] <thebombzen> which is like 1 every 3 days
[09:06:47 CEST] <thebombzen> 3 to 4
[09:07:07 CEST] <thebombzen> so keep in mind that it's intentionally difficult to get to the highest court, because they don't have the time to deal with it all
[09:08:08 CEST] <thebombzen> c3r1c3-Win: this is not quite accurate.... it has to be appealed to the SC
[09:08:32 CEST] <thebombzen> the supreme court doesn't decide to rule on cases not appealed to them unless they have original jurisdiction
[09:08:41 CEST] <thebombzen> which they do for a shortlist of things
[09:09:24 CEST] <thebombzen> james999: in order for the surpeme court to hear a case, they need a writ of certiorari which is a statement by 4 of the 9 judges agreeing to hear the case. given that there's lots of cases, there has to be some sort of triaging going on
[09:10:17 CEST] <thebombzen> james999: the argument for not allowing the lab techs to be called for cross-examination is that judges and lawyers and juries don't really have the scientific expertise to question the laboratory process
[09:11:04 CEST] <thebombzen> I happen to disagree with that. I think being able to cross-examine is still relevant and lawyers just shouln't ask technical questions that require too much background knowledge. in this case "faking data" is an easy concept to udnerstand even ifyou're not a lab technician
[09:11:16 CEST] <thebombzen> but that was the argument that the other side presented
[09:12:35 CEST] <thebombzen> also
[09:14:16 CEST] <thebombzen> c3r1c3-Win: you mentioned in February that there was no ETA on the replay buffer in "advanced mode" for OBS. Has this changed in the last three months or is there still no update on the progress
[09:14:33 CEST] <furq> is this the annie dookhan case or is this something new
[09:15:23 CEST] <c3r1c3-Win> No progress that I know of, thebombzen. That said, I know that Jim wants to release 19.0 in about 2 weeks, so you might be able to ask him about trying to get it on for 19.0
[09:15:53 CEST] <thebombzen> furq: http://www.nbcnews.com/news/us-news/stunning-drug-lab-scandal-could-upend-2…
[09:16:10 CEST] <thebombzen> c3r1c3-Win: is there a changelog? is there a way for me to betatest?
[09:16:10 CEST] <furq> yes, then
[09:16:33 CEST] <furq> this has been going on for years
[09:16:51 CEST] <thebombzen> yea
[09:16:57 CEST] <furq> bloody trinidadians
[09:17:01 CEST] <thebombzen> hm?
[09:17:19 CEST] <furq> she's from trinidad
[09:17:25 CEST] <c3r1c3-Win> theYou would have to ask Jim to add it, and if agrees, he would push the code for testing to a repo branch. Since he has not mentioned it (nor has anyone else in dev-land) I can only assume that it won't be in for 19.0 unless someone asks him and he agrees.
[09:17:39 CEST] <thebombzen> furq: she's a US citizen
[09:17:42 CEST] <c3r1c3-Win> thebombzen: ^
[09:17:47 CEST] <furq> she's still from trinidad
[09:17:53 CEST] <thebombzen> but she's American
[09:18:01 CEST] <furq> Annie Dookhan was born Annie Sadiyya Khan in San Fernando, Trinidad and Tobago in 1977.[3] She moved to the United States when she was a child and eventually became a citizen.
[09:18:05 CEST] <thebombzen> yes
[09:18:15 CEST] <furq> then what are you even saying
[09:18:20 CEST] <thebombzen> I think you realize this, but that last sentence means she's American
[09:18:28 CEST] <furq> why are you telling me this
[09:18:35 CEST] <thebombzen> [03:16:57] <furq> bloody trinidadians
[09:18:35 CEST] <james999> yes it is Annie Dookhan. I'm surprised you mentioned her by name.
[09:18:38 CEST] <furq> yes
[09:18:41 CEST] <furq> she is from trinidad
[09:18:53 CEST] <james999> releasing 23,000 prisoners at once is insane. but i guess they're doing it
[09:18:58 CEST] <thebombzen> well yes but in the US we call people who moved her permanently "Americans."
[09:19:04 CEST] <thebombzen> here*
[09:19:19 CEST] <furq> well then stop it
[09:19:56 CEST] <furq> anyway it's good that they're actually doing something about this
[09:19:58 CEST] <thebombzen> c3r1c3-Win: this implies someone has written the code and it's still in testing right
[09:20:11 CEST] <furq> even if it's taken two years since they found out she was full of shitr
[09:20:58 CEST] <thebombzen> otherwise, is there a 19.0 changelog I can look at?
[09:21:10 CEST] <thebombzen> or a release candidate I can test?
[09:21:10 CEST] <james999> the really crazy part is she's already out of jail
[09:21:14 CEST] <c3r1c3-Win> thebombzen: There is no advanced mode code for replay that I know of. You'll have to ask Jim where he is on it and what his timeline is.
[09:21:19 CEST] <furq> lol
[09:21:29 CEST] <furq> of course she would get out before the people she had falsely imprisoned
[09:21:35 CEST] <james999> right i was about to say that lol
[09:21:52 CEST] <james999> it took them less time to let her go than to let the others go
[09:22:23 CEST] <james999> plus you kinda have to wonder about the people running those labs.
[09:22:29 CEST] <thebombzen> c3r1c3-Win: hm, okay. are there nightly builds by the way?
[09:22:29 CEST] <furq> i want to know how there are still 21,000 people in jail for low-level drug charges based on evidence from before 2013
[09:22:45 CEST] <james999> if somebody is working 4x as good as everybody else... that's usually an indicator of fraud of some sort
[09:22:46 CEST] <thebombzen> furq: because US drug policy sucks ass
[09:22:51 CEST] <furq> in massachusetts
[09:23:02 CEST] <furq> i mean if it was alabama or one of those hellholes then i could understand
[09:23:27 CEST] <c3r1c3-Win> thebombzen: There are not. Not surprising given that there are no daily merges and all work is done in branches, tested and completed before being merged into main.
[09:23:28 CEST] <james999> furq: you have an interesting notion of what constitutes a hellhole!
[09:23:43 CEST] <thebombzen> ah okay, I'll have to wait two weeks for new features then
[09:23:50 CEST] <furq> missouri then
[09:24:01 CEST] <furq> whichever is the worst deep south state
[09:24:06 CEST] <thebombzen> missouri is not a deep south state
[09:24:10 CEST] <thebombzen> you're thinking of mississippi
[09:24:16 CEST] <thebombzen> and it's that
[09:24:39 CEST] <james999> i mean i have friends that commute to Massachusetts for work and traffic is a nightmare
[09:24:48 CEST] <thebombzen> where do you they live
[09:24:50 CEST] <furq> is traffic related to drug policy
[09:24:53 CEST] <james999> not even joking, if you signal for a turn then people will cut you off
[09:25:01 CEST] <thebombzen> drug trafficking
[09:25:02 CEST] <thebombzen> get it
[09:25:03 CEST] <thebombzen> pun
[09:25:10 CEST] <james999> it's crazy. traffic = hellhole in boston
[09:25:18 CEST] <james999> XD
[09:25:19 CEST] <thebombzen> you think boston traffic is bad lol
[09:25:22 CEST] <thebombzen> you should see LA
[09:25:30 CEST] <thebombzen> james999: what city are you in
[09:25:45 CEST] <furq> thebombzen: i don't get it
[09:25:47 CEST] <furq> could you explain it
[09:25:51 CEST] <thebombzen> No
[09:25:59 CEST] <james999> the_bombzen: one of the "hellholes" that furq mentioned rofl
[09:26:04 CEST] <james999> not alabama though
[09:26:11 CEST] <thebombzen> are you in St. Louis?
[09:26:17 CEST] <furq> i'll be deep in the cold, cold ground before i recognise missouri
[09:26:27 CEST] <furq> that's literally everything i know about missouri
[09:26:31 CEST] <james999> haha no. but compared to boston traffic accidents are way lower where i live
[09:26:35 CEST] <thebombzen> well yes
[09:26:50 CEST] <thebombzen> boston is a more dense city than every city in Missouri, including St. Louis
[09:26:51 CEST] <james999> o
[09:27:02 CEST] <thebombzen> Boston is huge af
[09:27:07 CEST] <thebombzen> that doesn't surprise me at all
[09:27:11 CEST] <james999> i'm trying to say that there's lots of factors to determining how crappy a place to live is
[09:27:26 CEST] <thebombzen> well traffic makes boston bad unless you don't use a car
[09:27:30 CEST] <thebombzen> boston actually has public transit
[09:27:45 CEST] <thebombzen> I'm from Cleveland which has fake ass public transit. it's not practical to live in cleveland without a car
[09:28:05 CEST] <thebombzen> or rather it's possible but a pain in the ass
[09:28:30 CEST] <furq> if boston is anything like boston then i agree that it fucking sucks
[09:28:48 CEST] <thebombzen> people who say boston fucking sucks have not been to Dallas
[09:28:51 CEST] <thebombzen> truly bad city
[09:29:00 CEST] <furq> i don't know if boston fucking sucks
[09:29:02 CEST] <furq> but boston fucking sucks
[09:29:11 CEST] <atomnuker> people who say a certain state sucks haven't been to many states
[09:29:16 CEST] <atomnuker> they all suck
[09:29:26 CEST] <thebombzen> some suck a lot more than others
[09:29:33 CEST] <thebombzen> kansas is pretty fucking awful
[09:30:00 CEST] <thebombzen> of all the states I have been two, kansas is my least favorite
[09:30:02 CEST] <thebombzen> by far
[09:30:13 CEST] <atomnuker> I can't really blame anyone who hasn't been to many states though
[09:30:19 CEST] <furq> Boston residents voted strongly (76% with 77% participation) in favour of leaving the European Union on 23 June 2016, this was the strongest such vote in the country.
[09:30:23 CEST] <atomnuker> you know, lack of public transport, they probably walk
[09:30:25 CEST] <furq> see
[09:30:27 CEST] <furq> what a shithole
[09:30:35 CEST] <james999> by the way, fun fact about the supreme court. apparently they were 1 vote in a 5-4 ruling to overturn Roe v Wade. But Kennedy flipped at the last minute. This is how the courts work. -_-
[09:30:49 CEST] <thebombzen> "kennedy flipped at the last minute" LOLOLOL
[09:30:52 CEST] <thebombzen> where have I heard that before
[09:31:07 CEST] <thebombzen> I should look that up
[09:31:31 CEST] <james999> it's insane that law affecting millions of people can depend on one guy changing his mind at the last minute on something but there ya go.
[09:31:49 CEST] <thebombzen> okay so I just looked it up
[09:31:52 CEST] <thebombzen> Roe v Wade was 7-2
[09:32:07 CEST] <thebombzen> Rhenquist and White dissented
[09:32:20 CEST] <furq> https://www.youtube.com/watch?v=RzybAS7zltE&t=4
[09:32:22 CEST] <james999> i'm talking PP v Casey which could have overturned it but didn't.
[09:32:43 CEST] <thebombzen> oh overturning roe v wade
[09:32:49 CEST] <thebombzen> thebombzen: learn to read
[09:32:50 CEST] <furq> roe v wade is the good bill which is good, right
[09:32:57 CEST] <thebombzen> not a bill
[09:33:01 CEST] <furq> case, then
[09:33:38 CEST] <thebombzen> it's the ruling that extended the 4th amendment constitutional right to privacy to a woman's right to choose
[09:34:16 CEST] <thebombzen> specifically, it extended the constitutional right to privacy in that the government cannot ban abortions (of nonviable fetuses)
[09:34:30 CEST] <james999> according to wikipedia it was surprisingly nuanced. defining different rights depending on early, middle, or late-stage pregnancy when state interest became more compelling to restrict it.
[09:34:41 CEST] <furq> warren burger
[09:34:43 CEST] <furq> mmm...burger
[09:35:07 CEST] <james999> was he same that covered up JFK? name sounds familiar
[09:35:25 CEST] <furq> idk i only know his name because homer simpson said it and then i typed the thing he said just now
[09:35:32 CEST] <thebombzen> ted kennedy is part of the kennedy family yea
[09:35:37 CEST] <thebombzen> same family that JFK was part of
[09:35:44 CEST] <furq> the kennedy family
[09:35:59 CEST] <thebombzen> yea there's a lot of people related to JFK who are all in political positions
[09:36:11 CEST] <thebombzen> RFK his brother, ran for president against Johnson (and was assassinated)
[09:36:16 CEST] <thebombzen> nvm against Nixon
[09:36:24 CEST] <thebombzen> you know what I don't remember
[09:36:38 CEST] <james999> by some crazy palestinian in a restaurant kitchen if memory serves
[09:36:45 CEST] <james999> i'm not sure why i remember some facts and not others...
[09:36:54 CEST] <furq> because you've forgotten the others
[09:37:31 CEST] <thebombzen> nvm I'm thinking of Anthony Kennedy
[09:37:33 CEST] <thebombzen> who is the justice
[09:37:40 CEST] <thebombzen> Ted Kennedy is the former massachussets senator
[09:38:08 CEST] <james999> furq: was that brexit vote in boston a joke? 77% voting to leave the EU... lol
[09:38:28 CEST] <furq> no
[09:38:32 CEST] <furq> that's about right
[09:38:48 CEST] <furq> boston is a proper shithole
[09:38:52 CEST] <furq> that whole county needs to fuck off
[09:39:09 CEST] <james999> they should do a poll for the french election next. curious to see how many mass people can name the candidates
[09:39:22 CEST] <furq> macron and le pen
[09:39:34 CEST] <furq> and some people who weren't racist enough to make it to the second round
[09:40:11 CEST] <furq> i enjoy how brazen the russian hackers are now
[09:40:39 CEST] <james999> i just want to see how many polled actually know anything about them.
[09:40:47 CEST] <james999> if 77% of them want to leave the EU... <snicker>
[09:41:06 CEST] <thebombzen> well it's not realistic to pull Boston people about a decision about britain leaving the EU
[09:41:19 CEST] <furq> i'm enjoying this misunderstanding but it's time to stop it
[09:41:22 CEST] <furq> there is more than one boston
[09:41:44 CEST] <thebombzen> I assume you're not talking about Boston, OH
[09:41:48 CEST] <thebombzen> is there a boston in England or something?
[09:41:48 CEST] <furq> you might not know this, but a lot of places in america are named after places in england
[09:41:53 CEST] <james999> oh damn. i was hoping bostonians would be stupid enough to vote to leave a union they aren't part of. ^_^
[09:42:05 CEST] <furq> for example, "new england"
[09:42:16 CEST] <thebombzen> Boston Township Ohio is not named after Boston, England
[09:42:17 CEST] <furq> which is actually named after england
[09:42:33 CEST] <thebombzen> I think the English's favorite pastime is accusing Americans of being dumb
[09:42:40 CEST] <thebombzen> and then they voted to leave the EU
[09:42:41 CEST] <furq> that's not true
[09:42:44 CEST] <furq> it's knowing that they are
[09:43:09 CEST] <furq> also i have never said anything about the english not being a bunch of twats
[09:43:24 CEST] <furq> i'm embarrassed to be one
[09:43:27 CEST] <thebombzen> you haven't said anything at all about the English
[09:43:37 CEST] <thebombzen> you spend all of your time complaining about Americans
[09:43:46 CEST] <james999> last news story i read about england that wasn't brexit related was the highest condom purchasing city in england. durham... or dunland? something like that
[09:43:47 CEST] <furq> well let's be honest, it's mostly your fault
[09:44:05 CEST] <thebombzen> it's not my fault you are complaining about me
[09:44:08 CEST] <furq> also it's probably durham on account of the other place doesn't exist
[09:44:33 CEST] <thebombzen> in fact you don't have to be up at 8:45 a.m. complaining about Americans on freenode
[09:45:12 CEST] <furq> or do i
[09:45:31 CEST] <james999> it was a fluff piece about condoms or how it was one city in england where ppl had the most sex iirc.
[09:45:54 CEST] <james999> i'm guessing it wasn't scotland at least so it had to be in the south
[09:45:58 CEST] <furq> also boston township, OH is named after boston, MA
[09:46:04 CEST] <furq> so it is named after boston, lincolnshire
[09:46:17 CEST] <furq> the worst of all bostons
[09:46:57 CEST] <furq> also why would you guess it wasn't scotland
[09:47:02 CEST] <james999> furq: so england has cities named York, Jersey, Haven, and Foundland?
[09:47:21 CEST] <furq> jersey isn't a city, it's an island
[09:47:24 CEST] <james999> just wildly speculating. lol
[09:47:25 CEST] <furq> and it's not technically part of england
[09:47:38 CEST] <furq> it's a crown dependency or one of those bullshit things
[09:48:11 CEST] <james999> speaking of the crown. my boston friend told me the other day the english crown is descended from transylvanian nobility
[09:48:15 CEST] <furq> and yes there are several places called haven
[09:48:19 CEST] <james999> something about gotha-saxeburg
[09:48:29 CEST] <furq> that's probably right
[09:48:33 CEST] <james999> i believe dracula's name came up as well
[09:48:47 CEST] <furq> the windsors are all germans, and prince philip is greek
[09:48:57 CEST] <furq> so there's probably some vampire blood in there somewhere
[09:48:59 CEST] <thebombzen> all the european royalty are all related
[09:49:03 CEST] <furq> more or less
[09:49:16 CEST] <furq> A member of the House of Schleswig-Holstein-Sonderburg-Glücksburg, Philip was born into the Greek and Danish royal families.
[09:49:28 CEST] <furq> look at that good old british name
[09:49:37 CEST] <james999> if you want a tv show about nobility try "The Tudors". it was popular for awhile here in the US.
[09:50:05 CEST] <james999> king henry was potrayed as a greek god like physique, and not his actual fat sickly pnysique.
[09:50:07 CEST] <furq> i'm just impressed you don't think that was a documentary filmed this year
[09:51:08 CEST] <james999> lol about what, the House of Tudor and how the current Tudor queen is ruling? actually scratch that, you could probably poll ppl in boston and get them to agree to that. :D
[09:51:22 CEST] <furq> https://en.wikipedia.org/wiki/Locations_in_the_United_States_with_an_Englis…
[09:51:25 CEST] <furq> looking good thebombzen
[09:51:41 CEST] <furq> although we had the good sense to get rid of cleveland
[09:51:58 CEST] <thebombzen> cleveland was not named after Cleveland, England
[09:52:44 CEST] <thebombzen> it was named after Moses Cleveland, a dude from connecticut who founded the city
[09:52:50 CEST] <furq> cleaveland
[09:52:52 CEST] <james999> "Bridgewater, Bristol, Canterbury, Chatham, Chesham, Chester, Chichester". yikes
[09:52:54 CEST] <thebombzen> Cleveland
[09:52:59 CEST] <thebombzen> the city is spelled Cleveland
[09:53:00 CEST] <furq> https://en.wikipedia.org/wiki/Moses_Cleaveland
[09:53:11 CEST] <furq> also i assume it was a george washington thing
[09:53:26 CEST] <furq> wikipedia doesn't say though
[09:53:32 CEST] <thebombzen> A "George Washington" thing
[09:53:42 CEST] <furq> yes
[09:53:53 CEST] <james999> kind of funny NH has a plaistow in it. I was just reading a story the other day about that
[09:53:55 CEST] <furq> washington is named after george washington who was named after washington, tyne and wear
[09:54:22 CEST] <furq> https://upload.wikimedia.org/wikipedia/commons/thumb/f/f1/John_Washington_p…
[09:54:46 CEST] <furq> another shithole, it's important to mention
[09:55:34 CEST] <thebombzen> he was actually named after a person
[09:55:38 CEST] <thebombzen> not after Washington Tyne and Wear
[09:56:35 CEST] <james999> furq: have you encountered a person whose only knowledge of the UK comes from harry potter?
[09:56:52 CEST] <furq> i've tried my best not to
[09:58:04 CEST] <thebombzen> especially if they read the Americanized version of the books
[09:58:12 CEST] <thebombzen> where they translate british slang into american slang so we can understand it
[09:58:22 CEST] <james999> they must exist just on pure numbers. that shit sold like crazy both sides of the sea
[09:58:28 CEST] <furq> i didn't think it was possible to make those books any worse
[09:58:36 CEST] <furq> i should never underestimate america
[09:58:37 CEST] <thebombzen> the harry potter books were great
[09:58:53 CEST] <james999> thebombzen: they changed slang?
[09:58:59 CEST] <furq> they're great if you're cold and in the wilderness and you need to make a fire
[09:59:18 CEST] <thebombzen> james999: yea. the scholastic version of the books changed british terms like "jumper" to American "sweater"
[09:59:22 CEST] <thebombzen> "bogey" to "booger"
[09:59:24 CEST] <thebombzen> that sort of thing
[09:59:40 CEST] <thebombzen> the only one they didn't was mum -> mom, because rowling insisted on keeping that one
[10:00:02 CEST] <james999> hmm. did they change "snogging" to "smooching"/"kissing"?
[10:00:09 CEST] <furq> i'm really upset that i know this now
[10:00:40 CEST] <furq> maybe it's time to take up heroin
[10:00:46 CEST] <furq> i've heard good things
[10:01:01 CEST] <james999> i actually never read the books, listened on audiobook. and i remember hearing some uk slang.
[10:01:33 CEST] <furq> "ow, ron, i'd fuckin smash her back doors in like," exclaimed harry
[10:01:36 CEST] <james999> furq: it's an epidemic in new england. people found dead in mcdonald's bathrooms etc
[10:02:01 CEST] <thebombzen> james999: here's a quick example
[10:02:02 CEST] <thebombzen> https://www.hp-lexicon.org/2001/08/25/differences-between-british-and-us-ve…
[10:02:31 CEST] <furq> i didn't know mcdonalds served heroin
[10:03:24 CEST] <furq> american slang is all fucked anyway
[10:03:28 CEST] <furq> like you call it "micky Ds"
[10:03:32 CEST] <furq> how am i supposed to understand that
[10:03:36 CEST] <furq> everyone knows it's "macky Ds"
[10:04:37 CEST] <thebombzen> I don't call it that
[10:04:47 CEST] <james999> apparently there are US and UK audio editions of the books.. o_0
[10:05:00 CEST] <thebombzen> yea. probably reading the british and us versions
[10:05:01 CEST] <james999> i'm mildly annoying i can't recall which one I listened to
[10:05:06 CEST] <furq> does stephen fry read the american one in an american accent
[10:05:13 CEST] <thebombzen> Philosopher's Stone or Sorcerer's Stone is the usual catch
[10:05:27 CEST] <furq> or is it the american equivalent of stephen fry
[10:05:28 CEST] <james999> no it's some guy named Jim Dale
[10:05:28 CEST] <thebombzen> furq: there's no such thing as an "American Accent"
[10:05:30 CEST] <furq> guy fieri
[10:05:40 CEST] <furq> yes there is
[10:05:42 CEST] <thebombzen> in the same way that there's no such thing as a "British Accent"
[10:05:52 CEST] <thebombzen> there's like several british accents and there's several American accents
[10:05:53 CEST] <furq> it's like this: yee-haw pardner whazzaaaaaap
[10:05:59 CEST] <thebombzen> that's a Texas accent
[10:06:00 CEST] <james999> thebombzen: yeah i'm paranoid now, was it philosopher stone or sorcerer stone lol
[10:06:18 CEST] <furq> i'm gon' get me some grits boy howdy
[10:06:27 CEST] <thebombzen> I don't even know what grits is
[10:06:38 CEST] <thebombzen> it's like some southern gross mush isn't it
[10:06:47 CEST] <furq> it's what you put on icy roads
[10:06:49 CEST] <james999> i have some in my pantry. they're like a wheat mush
[10:06:56 CEST] <thebombzen> we put Salt on icy roads
[10:07:01 CEST] <thebombzen> not oatmeall
[10:07:12 CEST] <thebombzen> or rather not wheatmeal
[10:07:33 CEST] <thebombzen> although it depends on where you are
[10:07:45 CEST] <thebombzen> if you live in the northern midwest, you put lots of rock salt on your roads
[10:08:03 CEST] <james999> what even is the american equivalent of stephen fry. all i know is his wiki bio says he's a gaytheist from britain
[10:08:07 CEST] <thebombzen> if you live in north carolina you flip the fuck out and panic and close everything and hide in your hideyhole if you get snow
[10:08:14 CEST] <thebombzen> who is Stephen Fry
[10:08:30 CEST] <furq> he's the english guy fieri
[10:08:41 CEST] <james999> https://en.wikipedia.org/wiki/Stephen_fry
[10:09:18 CEST] <thebombzen> I mean I can look him up on wikipedia too
[10:09:34 CEST] <thebombzen> also the description on wikipedia is nothing like guy fieri
[10:26:03 CEST] <james999> well after listening to samples of both fry and dale on youtube... i still don't know
[10:26:30 CEST] <james999> but my guess is i heard fry because the clip of the american reader had some silly music intro
[10:27:05 CEST] <thebombzen> furq btw you asked before about having all your applications look the same
[10:27:08 CEST] <thebombzen> see this https://0x0.st/Yuu.png
[10:27:18 CEST] <thebombzen> qt allows you to set GTK style
[10:27:52 CEST] <james999> i guess i just glossed over all the britisy slang? like jacket potato, car park and "sellotape"
[10:30:51 CEST] <james999> only way to find out for sure woudld be to listen to all of harry potter over again and see if the word "snog" gets replaced or not.
[10:30:58 CEST] <james999> and i'm not doing that. lol.
[10:31:41 CEST] <thebombzen> snogging is used in the American version though
[10:31:49 CEST] <thebombzen> so that test won't work
[10:31:50 CEST] <james999> well shit
[13:32:50 CEST] <kerio> weird, comconsole_pcidev stopped working
[15:02:05 CEST] <mattwj2002> hi guys
[15:02:12 CEST] <mattwj2002> I could use some kind assistance
[15:02:36 CEST] <mattwj2002> what would be the command syntax for trying out hardware acceleration using an NVIDIA graphics card
[15:02:37 CEST] <mattwj2002> :)
[15:02:54 CEST] <mattwj2002> h265 please
[15:04:53 CEST] <mattwj2002> hevc_nvenc ?
[15:06:47 CEST] <c_14> en or decoding?\
[15:07:10 CEST] <mattwj2002> encoding
[15:07:16 CEST] <c_14> yeah, that
[15:07:21 CEST] <c_14> -c:v hevc_nvenc
[15:08:54 CEST] <mattwj2002> c_14: h265 format?
[15:09:02 CEST] <mattwj2002> how would I specify that
[15:10:08 CEST] <mattwj2002> I am sure these sound like noob questions
[15:10:10 CEST] <mattwj2002> :-s
[15:10:58 CEST] <kerio> yes they do
[15:11:11 CEST] <kerio> anyway, that's hevc_nvenc
[15:11:16 CEST] <kerio> i assume there's a h264_nvenc for h.264
[15:13:45 CEST] <c_14> kerio: I think it's just called nvenc for h264
[15:13:55 CEST] <c_14> mattwj2002: just use a format like mp4 or mkv?
[15:13:58 CEST] <c_14> Or do you want raw h265?
[15:15:04 CEST] <mattwj2002> c_14: yes
[15:15:12 CEST] <mattwj2002> mp4 please
[15:15:14 CEST] <mattwj2002> :)
[15:15:35 CEST] <c_14> ffmpeg -i video -c:v hevc_nvenc out.mp4
[15:17:34 CEST] <mattwj2002> Cannot init CUDA
[15:17:34 CEST] <mattwj2002> Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
[15:17:41 CEST] <mattwj2002> I think I need to install cuda
[15:17:58 CEST] <mattwj2002> does anyone know the location of the nvida and cuda ppa in ubuntu?
[15:19:50 CEST] <BtbN> you need to install the nvidia driver, nothing else.
[15:20:05 CEST] <BtbN> increase the log level, and it will likely tell you what went wrong
[15:22:05 CEST] <mattwj2002> working on that now
[15:22:06 CEST] <mattwj2002> :)
[15:22:22 CEST] <mattwj2002> thanks for being nice to a noob like myself :D
[15:22:58 CEST] <mattwj2002> I can't talk real long
[15:23:03 CEST] <mattwj2002> I have a party to go to
[16:07:07 CEST] <faLUCE> iive: thanks for your feedback to the mailing list. This is for other people too: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-May/210971.html if you find this example useful, please send a msg to the mailing list in order to re-consider itù
[16:07:17 CEST] <faLUCE> s/itù/it
[16:29:02 CEST] <mattwj2002> hi guys
[16:29:30 CEST] <mattwj2002> does a Quadro 600 support hevc_nvenc?
[16:36:40 CEST] <c_14> https://developer.nvidia.com/video-encode-decode-gpu-support-matrix
[16:37:19 CEST] <kerio> unlimited number of streams? :o
[16:37:28 CEST] <kerio> infinite teraflops confirmed
[16:38:37 CEST] <ChocolateArmpits> I think that means how many encodings are allowed per gpu
[16:40:48 CEST] <kerio> INFINITE TERAFLOPS
[16:41:19 CEST] <kerio> INFINIFLOPS
[17:18:38 CEST] <DHE> oh that's a useful page...
[17:19:15 CEST] <DHE> and I guess the rule is "quadros whose numbers are <2000 (not <=) only run 2 streams, otherwise it's unlimited"
[17:20:18 CEST] <DHE> kerio: it also recycles the generated heat for its own power source resulting in free electricity
[17:23:42 CEST] <BtbN> the cuda cores are not involved with nvenc at all
[17:24:44 CEST] <BtbN> kerio, of course the total number of fps is not infiite. They will evenly be distributed accross all streams.
[17:24:51 CEST] <BtbN> Consumer cards are artificially limited to two streams
[17:30:50 CEST] <DHE> nvidia claims the distribution of multiple streams is done well enough that the chip's total FPS throughput should be pretty constant summed across all encoding jobs. still, for realtime jobs you probably don't want more than 10 per chip
[17:31:17 CEST] <DHE> also note that there is a distinct column for number of nvenc chips
[18:30:09 CEST] <faLUCE> JEEB: I finally understood WHY ffplay uses separate threads for audio and video: because it doesn't have an event driven demuxer.
[19:33:23 CEST] <james999> faLUCE: you're the one with that tutorial05.c site right?
[19:34:34 CEST] <mrkillius24> I want to make a batch script for ffmpeg? Should I go to ##windows or can I ask here?
[19:35:08 CEST] <thebombzen> if you ask here you'll be able to get help on calling ffmpeg
[19:35:26 CEST] <thebombzen> someone might know batch but I don't
[19:35:42 CEST] <thebombzen> but you'll be able to get help on actually calling ffmpeg
[19:35:42 CEST] <mrkillius24> I've never used batch properly before, only bash.
[19:35:50 CEST] <thebombzen> lol on Windows I still use bash
[19:35:51 CEST] <thebombzen> comes with git
[19:36:02 CEST] <mrkillius24> It wouldn't help because I want to call on native files
[19:36:08 CEST] <dystopia_> mrkillius24 you should go to ##dos heh
[19:36:08 CEST] <mrkillius24> which bash on windows can't do
[19:36:14 CEST] <dystopia_> best batch help on freenode
[19:36:15 CEST] <thebombzen> call on native files?
[19:36:16 CEST] <thebombzen> huh?
[19:36:19 CEST] <thebombzen> what do you mean
[19:36:32 CEST] <mrkillius24> I want to change the container on a whole folder of files
[19:36:40 CEST] <mrkillius24> like their video container
[19:36:46 CEST] <dystopia_> you can do that with a for loop
[19:36:55 CEST] <thebombzen> well to actually call ffmpeg you can do "ffmpeg -i input.mp4 -c copy output.mkv"
[19:36:58 CEST] <thebombzen> or something similar
[19:37:09 CEST] <thebombzen> if you're doing mp4 to mkv that is
[19:37:13 CEST] <james999> i don't think dos has been on windows since vista
[19:37:16 CEST] <mrkillius24> I'm doing mkv to mp4
[19:37:39 CEST] <thebombzen> well for a single input.mkv file, you can do "ffmpeg -i input.mkv -c copy output.mp4"
[19:37:40 CEST] <mrkillius24> But I have multi tracked audio does the container change work flawlessly or do I need to specify the number of tracks?
[19:37:49 CEST] <thebombzen> if you have multiple audio tracks you'll have to do this:
[19:37:58 CEST] <thebombzen> ffmpeg -i input.mkv -map 0 -c copy output.mp4
[19:38:09 CEST] <mrkillius24> I see I see
[19:38:10 CEST] <thebombzen> -map 0 says "map all streams from the 0th input" (which is input.mkv)
[19:38:15 CEST] <thebombzen> -c copy says "codec-copy"
[19:38:51 CEST] <dystopia_> for %%f in (*.mp4) do "ffmpeg -i %%~nf.mp4 -c copy %%~nf.mkv"
[19:39:07 CEST] <dystopia_> would process everything in a dir
[19:39:12 CEST] <thebombzen> in bash you would do it like this:
[19:40:03 CEST] <thebombzen> for file in *.mkv; do ffmpeg -i "$file" -map 0 -c copy "${file%.mkv}.mp4"; done
[19:40:10 CEST] <thebombzen> if you want ot use bash on windows
[19:40:11 CEST] <james999> what does the ~n do?
[19:40:28 CEST] <thebombzen> I think that truncates the extension
[19:41:12 CEST] <dystopia_> ~n is the file name
[19:41:58 CEST] <james999> isn't %%f the filename? i've written loops on windows b4 and don't recall that
[20:07:01 CEST] <ChocolateArmpits> % gets expanded when run from bat files
[20:07:27 CEST] <ChocolateArmpits> It is escaped by using %%
[20:07:47 CEST] <ChocolateArmpits> If you're running from the command line use a single %, inside of a bat file use double %%
[20:12:20 CEST] <mrkillius24> this is a lot more complicated that I thought it would be. I might have to end up learning powershell, is it truly that hard to get a script to read a folder take the files in them and then run ffmpeg on them to my output
[20:12:53 CEST] <james999> ChocolateArmpits: correct
[20:13:33 CEST] <james999> seems like you could just write %%f instead of $$~nf.mp4 to get the same result
[20:14:07 CEST] <james999> oh nvm lol
[20:14:18 CEST] <ChocolateArmpits> mrkillius24, what format are the files
[20:14:23 CEST] <ChocolateArmpits> that you want to convert
[20:14:31 CEST] <james999> now that i see the bash it makes more sense. weird syntax though
[20:14:45 CEST] <mrkillius24> mkv . I want to spit out mp4 with multi track audio, and split them after 15 minutes
[20:15:11 CEST] <hiihiii> hello
[20:15:14 CEST] <mrkillius24> hi
[20:15:20 CEST] <ChocolateArmpits> what do you mean by split, split every 15 minutes, or have two parts, one 15 minutes and other whatever length there is after ?
[20:15:40 CEST] <mrkillius24> The file itself after it's changed to mp4, I would like it to be split every 15 minutes
[20:15:46 CEST] <mrkillius24> that are inside the file
[20:15:57 CEST] <mrkillius24> so the duration of one file is only 15 minutes
[20:16:01 CEST] <hiihiii> how do you skip/remove the first N frames from the beginning using a filter?
[20:16:21 CEST] <hiihiii> I'v found on forums that
[20:16:40 CEST] <hiihiii> -vf 'select=gte(n\,100)' will remove first 100 frames but there might be other implications
[20:20:56 CEST] <mrkillius24> ffmpeg -i input.mkv -map 0 -c copy -f segment -segment_time 900 -reset_timestamps 1 output.mp4, something like that except that it goes through the folder where the mkvs are on, and the output is my other folder
[20:21:36 CEST] <mrkillius24> I might have to use something like python for this
[20:23:48 CEST] <hiihiii> Python overkill
[20:23:51 CEST] <hiihiii> excel
[20:23:52 CEST] <mrkillius24> is it?
[20:24:23 CEST] <hiihiii> -ss hh:mm:ss -t 00:15:00
[20:24:54 CEST] <hiihiii> you'd change -ss every cell
[20:25:23 CEST] <hiihiii> if you don't know how then any other language is okay
[20:25:52 CEST] <hiihiii> I haven't bothered to use bash in a while so
[20:27:02 CEST] <hiihiii> not sure if there's an option/filter in ffmpeg specific for this
[20:35:39 CEST] <ChocolateArmpits> mrkillius24, here https://pastebin.com/1FFzv186
[20:35:43 CEST] <ChocolateArmpits> tried and tested
[20:36:00 CEST] <mrkillius24> that's in bash right?
[20:36:03 CEST] <ChocolateArmpits> powershell
[20:36:24 CEST] <ChocolateArmpits> two parameters, one for the folder the files are in, the other for your ffmpeg binary
[20:36:41 CEST] <mrkillius24> awesome
[20:37:33 CEST] <ChocolateArmpits> paste in the powershell window and click enter so the function gets registered
[20:37:43 CEST] <ChocolateArmpits> you can then use it like a normal cmdlet for the time of the session
[20:37:57 CEST] <mrkillius24> ahh
[20:40:13 CEST] <draean> If you're combining a video and audio live stream with ffmpeg, is there a way to make it seamlessly continue the video with silence if the audio drops out?
[20:40:30 CEST] <ChocolateArmpits> draean, try -longest
[20:40:31 CEST] <hiihiii> can I drop first frame only using fps???
[20:40:55 CEST] <ChocolateArmpits> oh wait that's not a command
[20:43:36 CEST] <hiihiii> fps=start_time=-1 maybe?
[20:44:14 CEST] <ChocolateArmpits> hiihiii, just use the select command
[20:45:20 CEST] <ChocolateArmpits> Also start_time operates on time values rather than frame values, so it won't always give exact trim of 1 frame
[20:45:34 CEST] <hiihiii> ChocolateArmpits: -vf 'select=gte(n\,1)'
[20:45:43 CEST] <ChocolateArmpits> hiihiii, yeah try that
[20:45:50 CEST] <hiihiii> what exactly gte stand for
[20:45:57 CEST] <ChocolateArmpits> greater than or equal to
[20:46:19 CEST] <hiihiii> ohh well that sounds like it will do
[20:46:22 CEST] <ChocolateArmpits> it's part of the expression evaluation to craft more fine controls https://ffmpeg.org/ffmpeg-utils.html#Expression-Evaluation
[20:46:34 CEST] <hiihiii> thx
[20:46:52 CEST] <ChocolateArmpits> I however don't know if ffmpeg treats first frame as frame 0 logically
[20:47:01 CEST] <ChocolateArmpits> so you may have to try inputting 2 too
[20:47:34 CEST] <hiihiii> I think I'll have to start with 0
[20:47:48 CEST] <ChocolateArmpits> WEll 0 will output everything that's for sure
[20:51:23 CEST] <mrkillius24> choco I pasted it in and powershell and nothing happens
[20:51:43 CEST] <ChocolateArmpits> do you know how to use functions or cmdlets ?
[20:52:00 CEST] <mrkillius24> I don't know how you enter arguments is it like (arg,arg2) like other things?
[20:52:06 CEST] <mrkillius24> I tried that
[20:52:35 CEST] <ChocolateArmpits> Convert-Files -Path C:\pathtomyfolder -Ffmpeg C:\PathtoFfmpeg
[20:53:04 CEST] <ChocolateArmpits> You can use tab completion
[20:53:06 CEST] <mrkillius24> doesn't ffmpeg create a custom variable to it's location?
[20:53:13 CEST] <ChocolateArmpits> what variable ?
[20:53:18 CEST] <mrkillius24> like $ffmpeg$ or something
[20:53:24 CEST] <mrkillius24> like a global windows variable
[20:53:32 CEST] <ChocolateArmpits> absolutely not
[20:54:09 CEST] <ChocolateArmpits> IF you register the folder ffmpeg is in with the global PATH scope then yes you'll have it available
[20:54:26 CEST] <faLUCE> james999: sorry for the late answer: [19:33] <james999> faLUCE: you're the one with that tutorial05.c site right? <--- yes
[20:54:38 CEST] <ChocolateArmpits> any other case, no
[20:56:52 CEST] <james999> faLUCE: i thought so. thanks for the reply!
[20:57:52 CEST] <faLUCE> james999: do you have news for that? :-)
[20:58:02 CEST] <faLUCE> I'm coding my own threadless player
[20:58:13 CEST] <james999> why does it matter if it uses threads
[20:58:34 CEST] <faLUCE> because it's nonsense to use threads (but lot of people will oppose to this idea)
[20:58:46 CEST] <faLUCE> threads, in ffplay, are used as a workaround
[20:59:11 CEST] <faLUCE> anyway, that tutorial example doesn't work anymore
[21:18:03 CEST] <kinkinkijkin> faluce what do you propose as an alternative to threads in order to spread a spreadable workload across and entire device?
[21:18:23 CEST] <kinkinkijkin> I mean, I realize threads introduce overhead
[21:18:35 CEST] <kinkinkijkin> and are useless when you don't fill up a single processing unit
[21:18:36 CEST] <kinkinkijkin> but still
[21:19:25 CEST] <faLUCE> kinkinkijkin: the alternative is simple: libevent.
[21:19:51 CEST] <faLUCE> I'm coding a http-mpegts player with libplayer
[21:20:15 CEST] <faLUCE> I already used it in the library I published
[21:20:16 CEST] <kinkinkijkin> I'm not clear on what libevent provides
[21:20:32 CEST] <kinkinkijkin> event-response rendering or something like that?
[21:20:34 CEST] <faLUCE> kinkinkijkin: look at that: https://github.com/paolo-pr/laav
[21:21:33 CEST] <faLUCE> kinkinkijkin: about the audio, there's a non-blocking event-driven play() functiion in alsa
[21:22:51 CEST] <kinkinkijkin> I'm not entirely clear how event-driven-ness spreads the workload... I should note I had to leave programming due to disability before leaving game-loops
[21:23:43 CEST] <faLUCE> kinkinkijkin: there'ìs not a workload
[21:24:01 CEST] <faLUCE> I'll do the same thing I did for encoding/muxing/streaming
[21:24:30 CEST] <kinkinkijkin> uh, I think we have different understandings of the word workload
[21:24:38 CEST] <faLUCE> what do you mean?
[21:24:38 CEST] <kinkinkijkin> please explain your understanding to me
[21:24:59 CEST] <faLUCE> I mean the computational load
[21:25:32 CEST] <cryptodechange> holy cow, so one source at crf=16 I get 12mbit, another I get 22mbit
[21:25:39 CEST] <kinkinkijkin> how would even-driven rendering remove computational load entirely? the rendering still needs to happen, which introduces a workload
[21:26:36 CEST] <faLUCE> kinkinkijkin: I'm working at that. Does sdl provide an event driven rendering?
[21:26:54 CEST] <kinkinkijkin> dunno, I never used SDL
[21:27:10 CEST] <faLUCE> I'm asking that in the SDL channel
[21:27:30 CEST] <faLUCE> if so, I don't have problems
[21:27:42 CEST] <faLUCE> otherwise, I have to use another render lib
[21:27:46 CEST] <faLUCE> otherwise, I have to use another rendering lib
[21:28:14 CEST] <furq> is it really that important
[21:28:20 CEST] <faLUCE> but it could be that rendering is so fast, with sdl, that it can work without events too
[21:28:28 CEST] <furq> you're probably going to be spinning up multiple threads for decoding etc anyway
[21:28:55 CEST] <faLUCE> furq: given that I did not need them for encoding, I suppose they are not necessary for deconding too
[21:30:37 CEST] <furq> by "you" i mean the process
[21:30:52 CEST] <faLUCE> furq: same answer
[21:31:16 CEST] <furq> i don't see you preventing x264 from using multiple threads in that lib
[21:31:48 CEST] <faLUCE> x264 threads are used internally. This is not my matter
[21:32:09 CEST] <faLUCE> It's logical that x264 uses threads internally
[21:32:26 CEST] <faLUCE> what is bad is when players and demuxers use threads for decoupling tasks
[21:41:26 CEST] <faLUCE> kinkinkijkin: what do you use for rendering?
[21:41:54 CEST] <kinkinkijkin> I use whatever the player I'm using uses
[21:42:09 CEST] <kinkinkijkin> I haven't written any meaningful code since 2013
[21:42:44 CEST] <faLUCE> kinkinkijkin: ok
[21:43:06 CEST] <kinkinkijkin> usually I set the renderer to OGL
[21:43:37 CEST] <faLUCE> I'm asking in the OGL channel too
[21:44:07 CEST] <faLUCE> there must be libraries with event-driven rendering
[21:44:23 CEST] <BtbN> Well, there is OpenGL and Vulkan
[21:44:29 CEST] <BtbN> neither are event driven
[21:44:40 CEST] <BtbN> Doesn't really make sense for rendering anyway
[21:44:56 CEST] <kinkinkijkin> ogl can handle event-driven renderers though, but I mainly set to ogl because I use gpu decoding
[21:45:22 CEST] <kinkinkijkin> and the player I currently use (mpv) requires ogl be used for gpu decoding iirc
[21:45:32 CEST] <faLUCE> [21:44] <BtbN> Doesn't really make sense for rendering anyway <-- why?
[21:45:34 CEST] <BtbN> OpenGL doesn't care about events, as long as it get a sequential stream of commands it's happy
[21:45:42 CEST] <BtbN> Because you just draw on a screen
[21:45:45 CEST] <BtbN> no events happen there
[21:45:59 CEST] <faLUCE> BtbN: but is the rendering fast enough?
[21:46:07 CEST] <BtbN> Fast enough for what?
[21:46:25 CEST] <faLUCE> in order to avoid blocking the main process, when doing other stuff
[21:46:28 CEST] <BtbN> Rendering a single rect with a video texture on it? You'd need a pre-historic GPU to run into performance issues there
[21:46:32 CEST] <faLUCE> I have to process audio as well
[21:47:31 CEST] <BtbN> You usually put everything that's not directly related to rendering on a different thread, so it doesn't slow down rendering
[21:47:47 CEST] <faLUCE> BtbN: as said before, I don't want to use threads
[21:48:01 CEST] <faLUCE> then I wonder if is there an event driven rendering, in some lib
[21:48:06 CEST] <BtbN> well, that's completely your problem still.
[21:48:28 CEST] <BtbN> OpenGL has some blocking commands, it does not play well with an event loop
[21:48:54 CEST] <BtbN> And Vulkan was aggressively designed to be used from multiple threads
[21:49:18 CEST] <BtbN> like, you can prepare command queues on seperate threads, upload them, and then just execute them from the main thread
[21:50:14 CEST] <BtbN> I don't think you can easily integrate video rendering with Vulkan though, there is no interop available
[21:51:33 CEST] <mattwj2002> hi guys
[21:51:38 CEST] <mattwj2002> I could use some assistance
[21:53:18 CEST] <mattwj2002> ffmpeg -i input.mkv -c:v hevc_vaapi -f Matroska -c:a copy output.mkv
[21:53:35 CEST] <mattwj2002> MKp97KiW
[21:53:37 CEST] <mattwj2002> oops
[21:53:48 CEST] <mattwj2002> I get this https://pastebin.com/MKp97KiW
[21:54:27 CEST] <faLUCE> BtbN: in the sdl channel they told me the correct answer: [21:50] <slime> faLUCE: none of the rendering functions except for ReadPixels are truly blocking
[21:54:44 CEST] <faLUCE> [21:51] <slime> the rendering functions are just commands that tell the GPU what to do, this applies to any API that uses the GPU
[21:54:46 CEST] <faLUCE> [21:52] <slime> the GPU and graphics driver operates asynchronously to execute the work in a pipelined fashion
[21:54:54 CEST] <BtbN> all the texture upload commands are blocking
[21:54:54 CEST] <faLUCE> .... then, problem solved.
[21:55:09 CEST] <BtbN> And you are going to upload a lot of textures with video rendering
[21:55:16 CEST] <faLUCE> BtbN: [21:53] <MrFlibble> slime: glDrawArrays blocks
[21:55:28 CEST] <faLUCE> [21:53] <slime> MrFlibble: no it doesn't
[21:55:39 CEST] <BtbN> And I'm pretty sure there are quite a few special cases in OpenGL that block as well
[21:55:41 CEST] <faLUCE> [21:54] <slime> (the new graphics APIs like Vulkan expose the concept of this queue directly in the API, rather than having it be implicit)
[21:55:48 CEST] <BtbN> like, switching the buffers blocks, because vsync
[21:55:59 CEST] <kinkinkijkin> mattwj2002, I was getting that too, I forget how I solved it
[21:56:08 CEST] <mattwj2002> kinkinkijkin: hmmm
[21:56:13 CEST] <mattwj2002> any thoughts?
[21:56:47 CEST] <kinkinkijkin> are you using ffmpeg on a unixlike or windows?
[21:57:36 CEST] <mattwj2002> ubuntu linux
[21:58:49 CEST] <kinkinkijkin> what is your gpu?
[21:59:14 CEST] <mattwj2002> Quadro 600 nvidia
[21:59:35 CEST] <kinkinkijkin> nvidia gpu does not have vaapi support iirc
[21:59:46 CEST] <mattwj2002> kinkinkijkin: what does it support any thoughts?
[22:00:11 CEST] <kinkinkijkin> nvenc
[22:00:31 CEST] <kinkinkijkin> set up nvenc and try to encode with hevc_nvenc
[22:01:02 CEST] <mattwj2002> [hevc_nvenc @ 0x39a15c0] No NVENC capable devices found
[22:01:21 CEST] <kinkinkijkin> which driver are you using?
[22:01:28 CEST] <kinkinkijkin> I don't use an nvidia gpu so I'm shooting in the dark here
[22:01:54 CEST] <mattwj2002> NVIDIA-Linux-x86_64-375.66.run
[22:02:09 CEST] <mattwj2002> cuda_8.0.61_375.26_linux.run
[22:02:14 CEST] <mattwj2002> I think
[22:02:15 CEST] <mattwj2002> hmmm
[22:02:22 CEST] <mattwj2002> maybe it is only cuda
[22:02:31 CEST] <kinkinkijkin> see if there's an nvenc driver you can download
[22:02:32 CEST] <mattwj2002> this is my first attempt at gpu encoding :)
[22:02:36 CEST] <mattwj2002> okay
[22:04:22 CEST] <mattwj2002> kinkinkijkin: maybe I should switch to windows?
[22:04:41 CEST] <draean> Heeeey, someone familiar with streaming ak to talk this problem out with me? I'm trying to be able to take in a stream, but tolerate it dropping out, and continue playing the other inputs.
[22:04:55 CEST] <mattwj2002> also would handbrake be easier for this application
[22:05:16 CEST] <kinkinkijkin> I know nvenc works on linux
[22:05:48 CEST] <mattwj2002> okay
[22:06:10 CEST] <mattwj2002> got any idea
[22:07:36 CEST] <mattwj2002> what does the --enable-nonfree switch do?
[22:08:17 CEST] <kinkinkijkin> lets you do stuff with non-foss libraries
[22:08:25 CEST] <kinkinkijkin> https://www.maketecheasier.com/nvidias-gpu-assisted-video-encoding-nvenc-wo… seems to be what works
[22:08:27 CEST] <mattwj2002> oh okay
[22:10:20 CEST] <BtbN> mattwj2002, don't run the .run installers. That's a good way to break your system
[22:10:28 CEST] <BtbN> Use your distributions package manager
[22:10:28 CEST] <mattwj2002> kinkinkijkin: if this works I'll buy you a beer
[22:10:34 CEST] <mattwj2002> thanks btbN
[22:10:40 CEST] <mattwj2002> I appreciate the heads up
[22:10:55 CEST] <BtbN> Ubuntu has the nvidia drivers packaged, there is no need to run those
[22:11:14 CEST] <BtbN> That guide is ancient, it's for ffmpeg 2.8
[22:11:18 CEST] <mattwj2002> okay BtbN
[22:11:42 CEST] <BtbN> nvenc changed a lot from then on. You don't need anything special anymore. Any normal ffmpeg build that doesn't explicitly disable nvenc will have it
[22:12:07 CEST] <BtbN> you also do not need the cuda SDK
[22:12:07 CEST] <mattwj2002> got ya
[22:13:27 CEST] <mattwj2002> this isn't for work anything
[22:13:31 CEST] <mattwj2002> this is just for fun :)
[22:13:59 CEST] <mattwj2002> I want to see if I can get it to go
[22:14:14 CEST] <mattwj2002> the graphics card was a freebie
[22:15:07 CEST] <mattwj2002> BtbN: so you agree nvenc is what I need for my graphics card?
[22:15:35 CEST] <BtbN> I have no clue what graphics card you even got, but as the name might suggest, nvenc is from and for nvidia only.
[22:15:45 CEST] <mattwj2002> quadro 600
[22:15:54 CEST] <mattwj2002> it isn't super new
[22:15:56 CEST] <BtbN> No idea what generation that is
[22:16:00 CEST] <BtbN> nvenc works since Kepler
[22:16:04 CEST] <mattwj2002> ok
[22:16:28 CEST] <mattwj2002> I believe mine is third generation
[22:17:07 CEST] <BtbN> hevc encoding is a thing since 2nd Gen Maxwell.
[22:17:15 CEST] <BtbN> "third generation"?
[22:17:34 CEST] <furq> the quadro 600 is fermi isn't it
[22:17:52 CEST] <BtbN> 600 or K600?
[22:17:55 CEST] <furq> assuming it's not a k600 which is different
[22:17:58 CEST] <furq> because naming things is easy
[22:18:09 CEST] <mattwj2002> 600 not 600k
[22:18:13 CEST] <mattwj2002> oops k600
[22:18:29 CEST] <BtbN> That's first gen Kepler, it has basic h264 support, nothing more
[22:19:12 CEST] <furq> the 600 is fermi, the k600 is kepler
[22:19:13 CEST] <mattwj2002> bummer
[22:19:19 CEST] <furq> so if it's the 600 then you're out of luck
[22:19:24 CEST] <mattwj2002> bummer
[22:19:58 CEST] Action: mattwj2002 is out of luck :(
[22:20:34 CEST] <kinkinkijkin> try h264_vaapi still
[22:20:47 CEST] <BtbN> there is no vaapi support from the official nvidia driver.
[22:20:54 CEST] <BtbN> h264_nvenc will work, for yuv420
[22:20:54 CEST] <kinkinkijkin> oh yeah
[22:21:13 CEST] <BtbN> hevc won't, yuv444 won't, lossless won't
[22:25:52 CEST] <bgv> Hi. I have a color split display issue with videos made with Ffmpeg for Instagram. Here is the result https://www.instagram.com/p/BTw3dGnBwe4/ and there is log and media https://we.tl/jZDVx95V0Z Thank you
[22:31:34 CEST] <mattwj2002> BtbN: would a quadro 960 do a better job?
[22:32:28 CEST] <BtbN> No clue, look at nvidias support matrix
[22:33:06 CEST] <mattwj2002> okay will do
[22:33:40 CEST] <mattwj2002> last question and I'll just hang out.....how is ATI for video encoding? can any ATI do hardware video encoding
[22:34:05 CEST] <kinkinkijkin> yes
[22:34:07 CEST] <BtbN> They can, but the situation on linux is weird, and their Windows API is not implemented in ffmpeg.
[22:34:32 CEST] <kinkinkijkin> in linux you need to use the free driver, and not every codec actually supported by your card will be supported
[22:34:56 CEST] <BtbN> vaapi encoding on anything but Intel is not exactly well tested
[22:35:05 CEST] <BtbN> And the driver side implementation is also lacking
[22:35:40 CEST] <mattwj2002> okay thanks guys
[22:35:44 CEST] <mattwj2002> time to hang out :D
[22:37:11 CEST] <kinkinkijkin> on my gpu, b frames are not supported in h264
[22:37:28 CEST] <kinkinkijkin> in the driver
[22:37:35 CEST] <kinkinkijkin> but they are supported in the windows driver
[22:38:28 CEST] <kinkinkijkin> also, speaking of vaapi, what do I pass to h264_vaapi to make it act in CBR?
[22:39:01 CEST] <kinkinkijkin> everything I've tried either is invalid or I still get bloat from keyframes
[22:39:32 CEST] <BtbN> no video encoder supports true CBR
[22:39:35 CEST] <BtbN> not even x264
[22:39:42 CEST] <kinkinkijkin> well duh
[22:39:56 CEST] <kinkinkijkin> but how can I get it to pretend better?
[22:40:26 CEST] <BtbN> look at the code to check what parameters it supports, and see if there is one that looks like cbr/maxrate qp
[22:40:34 CEST] <mattwj2002> you guys have any ffmpeg recommended books?
[22:40:47 CEST] <kinkinkijkin> I can't read code anymore unfortunately
[22:41:25 CEST] <mattwj2002> ffmpeg o'reil maybe?
[22:43:29 CEST] <BtbN> Any book you might find will most likely be horribly outdated
[22:44:36 CEST] <BtbN> kinkinkijkin, http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vaapi_encode_h264…
[22:44:36 CEST] <mattwj2002> okay
[22:45:18 CEST] <kinkinkijkin> I dunno how to set this though
[22:45:23 CEST] <BtbN> so basically, set -b and -maxrate to the same value, and it will enter cbr mode
[22:45:38 CEST] <kinkinkijkin> huh, I tried that before
[22:46:00 CEST] <BtbN> well, as I said, "cbr mode" is still most likely only a very rough cbr
[22:46:11 CEST] <BtbN> that's constant over longer periods of times at best
[22:51:07 CEST] <mattwj2002> I am off guys
[22:51:17 CEST] <mattwj2002> thanks for the kind assistanace
[22:51:18 CEST] <mattwj2002> :)
[22:51:23 CEST] <mattwj2002> byeeeeeeeeeeeeeeeeeeeeeee
[22:51:24 CEST] <mattwj2002> :D
[22:52:35 CEST] <kinkinkijkin> how do I specify the keyframe interval?
[22:53:03 CEST] <BtbN> -g
[22:53:06 CEST] <kinkinkijkin> thanks
[22:53:34 CEST] <BtbN> it's in number of frames, not seconds or something
[22:55:35 CEST] <kinkinkijkin> I got that
[22:57:10 CEST] <kinkinkijkin> hmm, it seems to dump a keyframe every 5 seconds regardless of the settings
[22:57:43 CEST] <BtbN> vaapi h264?
[22:57:49 CEST] <kinkinkijkin> yep
[22:58:10 CEST] <BtbN> yeah, the vaapi_encode_h264.c file does not touch the variable it sets at all
[22:58:19 CEST] <BtbN> so I'd guess you can't influence the gop length
[22:58:46 CEST] <kinkinkijkin> darn
[22:59:04 CEST] <cryptodechange> Which would yield a higher bitrate on a grainy source? -tune film or grain?
[22:59:53 CEST] <BtbN> why do you want a higher bitrate?
[23:00:00 CEST] <cryptodechange> I don't
[23:00:15 CEST] <cryptodechange> Which would yield a lower bitrate from a grainy source*
[23:00:56 CEST] <BtbN> The only real answer there is try it and see
[23:01:21 CEST] <cryptodechange> I'm caught off guard here, two sources from 2016 released blurays
[23:01:34 CEST] <cryptodechange> crf=16, avg bitrate on one is 13mbps
[23:01:36 CEST] <cryptodechange> the other is 20mbps
[23:09:18 CEST] <furq> cryptodechange: what did you expect crf to do
[23:09:36 CEST] <furq> also grain will give a higher bitrate
[23:09:44 CEST] <furq> at least with everything i've ever tested
[23:13:32 CEST] <faLUCE> furq: are you from germany?
[23:13:41 CEST] <furq> i am not
[23:14:19 CEST] <faLUCE> furq: I thought that you were a german person who doesn't like Germany :-)
[23:18:34 CEST] <nyuszika7h> x264 CRF 18 gives me 1500 kbps average bitrate for a 720x576 DVD encoded 720x304 and 4000 kbps for a 720x576 TV broadcast encoded at 720x400 (both sources raw MPEG-2)... 4000 kbps is definitely way too high for SD
[23:20:09 CEST] <nyuszika7h> sure, I just bumped up the CRF to 21, but I don't quite get the point of CRF if it gives results out of sane bitrate bounds sometimes - it definitely isn't complex enough to bump up the bitrate that much beyond normally reasonable bounds
[23:20:42 CEST] <nyuszika7h> (I haven't really used anything else, my first encounter with encoding is H.264 CRF)
[23:21:34 CEST] <furq> the point is that it should give roughly the same quality across multiple sources
[23:21:41 CEST] <furq> rather than having to figure out what a good bitrate is every time
[23:21:52 CEST] <furq> if you get some unacceptably high bitrate then you probably want to denoise the source or something
[23:23:33 CEST] <nyuszika7h> I can't really see much noise but idk
[23:23:35 CEST] <grublet> CRF will definitely throw some crazy high bitrates out there if you have a source with a lot of complexity
[23:23:42 CEST] <grublet> happens with videogame captures too
[23:23:54 CEST] <grublet> nyuszika7h: do you have a sample or screenshot of the source?
[23:23:59 CEST] <nyuszika7h> yes one sec
[23:25:07 CEST] <nyuszika7h> I mean the only complexity I can think of is motion because it's a show about skating, but I don't know why it would cause THAT high bitrate
[23:25:23 CEST] <furq> denoising will also get rid of compression artifacts
[23:25:41 CEST] <furq> if it's a pdtv rip of a sports broadcast then i can imagine there's quite a lot of that
[23:26:03 CEST] <nyuszika7h> it's a scripted TV show, but it features skating
[23:26:20 CEST] <nyuszika7h> and yes it's a raw MPEG-2 rip from an SD channel
[23:26:32 CEST] <grublet> for what its worth, those bitrates you listed sound appropriate for those CRF settings, just from my own person experience messing with DVD sources
[23:26:47 CEST] <furq> yeah dvds usually use higher bitrates than pdtv
[23:26:51 CEST] <furq> at least halfdecent ones do
[23:27:34 CEST] <grublet> also if the framerate is higher on the broadcast, then the bitrate will definitely be higher
[23:27:46 CEST] <nyuszika7h> both are 25 fps PAL
[23:28:01 CEST] <grublet> okay then the only thing i could imagine is the visual complexity
[23:28:04 CEST] <furq> even if it was 50i and you were converting to 50p, it shouldn't cause that much of a spike
[23:28:18 CEST] <nyuszika7h> the DVD I tried with earlier was progressive according to MediaInfo for some reason, and I didn't see any interlacing artifacts either
[23:28:28 CEST] <nyuszika7h> and this is interlaced, I'm using yadif
[23:28:34 CEST] <furq> i usually deinterlace to 50p and it's like 10-20% bigger than 25p if you use good settings
[23:28:41 CEST] <grublet> if the video is really shaky, that can cause the btirate to go up because there's not as much temporal information to exploit
[23:28:48 CEST] <grublet> temporal similarity, i mean
[23:28:58 CEST] <furq> you might want to try a different deinterlacer
[23:29:26 CEST] <furq> bwdif is supposed to be better without being horrendously slow
[23:29:38 CEST] <grublet> furq: yeah goiod point
[23:29:52 CEST] <furq> i normally use qtgmc for sd mpeg2, but that's a lot of work to go through
[23:30:13 CEST] <grublet> nowadays i just say screw it and us Bob() in avisynth
[23:30:22 CEST] <furq> qtgmc is fantastic for sd mpeg2
[23:30:33 CEST] <furq> if you're dealing with high-bitrate 1080i sources then it doesn't really matter what you use
[23:31:36 CEST] <grublet> furq: why doesn't it matter?
[23:32:59 CEST] <furq> yadif gives perfectly adequate results for clean hd sources
[23:33:07 CEST] <furq> and yadif is pretty basic
[23:34:06 CEST] <grublet> a dumb bob is even basic-er
[23:34:13 CEST] <furq> sure
[23:34:23 CEST] <grublet> i usually dont notice the difference unless im looking at still frames
[23:34:41 CEST] <grublet> and doing fancy deint on 1080i is just like, nah forget that lol
[23:34:46 CEST] <furq> yeah
[23:34:56 CEST] <furq> qtgmc is already agonisingly slow on 576p
[23:34:59 CEST] <grublet> stuff like qtgmc is pretty fun to mess with
[23:35:06 CEST] <furq> or 576i rather
[23:35:47 CEST] <furq> the best thing about qtgmc is the mode that repairs badly deinterlaced stuff
[23:35:56 CEST] <furq> i've had properly amazing results with that
[23:36:46 CEST] <grublet> I liked using stuff like tempgaussmc/qtgmnc for deinterlacing stand up comedy dvds
[23:36:50 CEST] <ChocolateArmpits> The higher the resolution the less artifacts a deinterlacer has to account for
[23:37:05 CEST] <furq> right
[23:37:37 CEST] <furq> the really good deinterlacers excel with messy sources
[23:37:44 CEST] <furq> there's not much to get wrong with a clean source
[23:38:07 CEST] <ChocolateArmpits> I sometimes think because of this removing interlacing from 4K was quite stupid
[23:38:25 CEST] <grublet> Interlacing is something I've wanted to be gone since Blu-ray was new
[23:38:34 CEST] <furq> yeah i'm glad it's finally dying
[23:39:02 CEST] <BtbN> I don't get how it managed to survived for anything but the old SD formats
[23:39:14 CEST] <grublet> and I still think new formats should be using 4:4:4 instead of 4:2:0 for chroma
[23:39:19 CEST] <furq> i mean 1080i50 is nice for sport, and i'd take that over them dropping the bitrate
[23:39:22 CEST] <furq> but i'd take 720p50 over either
[23:39:56 CEST] <ChocolateArmpits> BtbN, HD was standartized back when digital TV wasn't even out in the public
[23:40:05 CEST] <grublet> BtbN: probably because most of the masters for sd and early HD stuff was stored as PsF on old tape storage formats
[23:40:09 CEST] <furq> and i still see some wonky artifacts on some devices with 1080i50 streams
[23:40:54 CEST] <furq> mostly shit like on-screen graphics that can't decide what line they're on
[23:41:13 CEST] <grublet> that's another thing i dont miss
[23:41:18 CEST] <grublet> mixed content
[23:41:28 CEST] <ChocolateArmpits> furq, that's because of deinterlacer
[23:41:31 CEST] <grublet> like 24p hard telecined with 60i stuff added to it
[23:41:37 CEST] <furq> yeah i know
[23:42:01 CEST] <furq> my point is that even good deinterlacers with 1080i50 sources still cause issues
[23:42:04 CEST] <grublet> doom9 is probably way less active now since blu-rays dont have that problem much now
[23:42:13 CEST] <furq> lol
[23:42:29 CEST] <furq> yeah mixed content is the bane of my fucking existence
[23:42:40 CEST] <furq> and i don't even have to deal with ntsc bullshit like mixed telecine and interlaced
[23:42:46 CEST] <grublet> makes me thankful i was never that into anime
[23:42:55 CEST] <grublet> oh yeah, im from the us
[23:43:15 CEST] <furq> it's bad enough with mixed progressive and interlaced on pal dvds
[23:43:28 CEST] <furq> but at least that all ends up the same framerate
[23:43:38 CEST] <grublet> at least with PAL film->tv is usually done with a speedup
[23:43:42 CEST] <furq> yeah
[23:43:54 CEST] <furq> except when it's done by scanning an ntsc rip
[23:43:59 CEST] <furq> in which case that dvd is going in the bin
[23:44:19 CEST] <kinkinkijkin> ah, h264_vaapi makes garbage on my gpu and driver right now
[23:44:20 CEST] <grublet> s/bin/garbage disposal
[23:44:21 CEST] <kinkinkijkin> wonderful
[23:44:28 CEST] <furq> we don't have garbage disposals in europe
[23:44:41 CEST] <furq> and i don't have a microwave
[23:44:41 CEST] <grublet> well you should for dvds like that lol
[23:44:43 CEST] <kinkinkijkin> we don't have them in canada either
[23:44:46 CEST] <kinkinkijkin> except for rich people
[23:44:49 CEST] <kinkinkijkin> really rich people
[23:44:50 CEST] <grublet> microwave is something i can live without
[23:44:55 CEST] <furq> same
[23:45:05 CEST] <furq> but it is nice to put infuriating discs in there
[23:45:08 CEST] <kinkinkijkin> microwave is something I need
[23:45:24 CEST] <grublet> i dont need it, but it sure makes eating much more likely to happen lol
[23:45:44 CEST] <grublet> its either that or pilfer whatever my roommates made
[23:45:46 CEST] <furq> don't you people heat up water in the microwave
[23:45:49 CEST] <furq> you savages
[23:46:01 CEST] <kinkinkijkin> I heat up water in the kettle
[23:46:04 CEST] <kinkinkijkin> or in a pot
[23:46:06 CEST] <grublet> thats what a kettle is for innit
[23:46:06 CEST] <furq> ok good
[23:46:09 CEST] <grublet> yeah what he said
[23:46:25 CEST] <kinkinkijkin> am grill, boil pots of water on my head
[23:46:35 CEST] <grublet> i have never seen a kettle in real life, i mean if you're boiling water here its probably on the stove
[23:46:40 CEST] <kinkinkijkin> please don't actually put a pot on a grill
[23:46:50 CEST] <furq> kettles aren't very popular in the us because of your dumb mains voltage
[23:47:13 CEST] <grublet> well, the US does a lot of dumb stuff, so im used to it
[23:47:46 CEST] <kinkinkijkin> higher AC rates increases heat generation too, you know
[23:47:49 CEST] <kinkinkijkin> iirc
[23:48:17 CEST] <furq> us power outlets can only put out 1800W
[23:48:22 CEST] <furq> which is not enough for a decent kettle
[23:48:38 CEST] <kinkinkijkin> wat, that's like
[23:48:41 CEST] <kinkinkijkin> a new house minimum
[23:48:49 CEST] <grublet> i was not aware of that 1800w limit, probably because ive never tried to use a kettle
[23:48:50 CEST] <furq> that's 120V at 15A
[23:49:08 CEST] <grublet> furq: pretty sure most of our breakers are around 15a
[23:49:21 CEST] <furq> apparently 15A is the legal limit
[23:49:32 CEST] <grublet> i think thats the limit for a single room
[23:49:33 CEST] <furq> but i'm reading this off a blog so it might be bullshit
[23:49:53 CEST] <grublet> well, most stuff on a breaker box here is 15a from what ive seen
[23:49:55 CEST] <BtbN> 230V@16A is already quite limited
[23:49:57 CEST] <kinkinkijkin> I dunno what the limit is here in canada but I'm running way more than 1800w at times in my room, which has a single breaker
[23:50:04 CEST] <furq> 16?
[23:50:07 CEST] <furq> the limit is 13 here
[23:50:15 CEST] <BtbN> All our fuses are 16A
[23:50:16 CEST] <furq> that gives you about 3000W though, which is plenty for boiling water
[23:50:17 CEST] <grublet> here we use 220a for washer/dryer or other things like that
[23:50:17 CEST] <BtbN> 3600W
[23:50:27 CEST] <grublet> which idk
[23:50:32 CEST] <grublet> because our mcirowave is 1800w
[23:50:34 CEST] <furq> yeah that's on a separate circuit
[23:50:40 CEST] <grublet> and i know i run it at the same time as the mcirowave plenty of times
[23:50:47 CEST] <furq> wait what
[23:50:49 CEST] <furq> 1800w microwave?
[23:50:52 CEST] <furq> are you sure about that
[23:50:54 CEST] <grublet> thats what it says
[23:50:57 CEST] <grublet> 1.8kW
[23:51:01 CEST] <furq> that seems a bit insane
[23:51:08 CEST] <grublet> my grandparents had one that was 1250w
[23:51:10 CEST] <kinkinkijkin> never seen a microwave above 1.2kw
[23:51:15 CEST] <furq> i've never seen one higher than 1kW
[23:51:16 CEST] <grublet> well, i have lol
[23:51:22 CEST] <grublet> my old microwave was only 800w
[23:51:29 CEST] <BtbN> Well, the oven and stuff have their own 3-fuse-setup. 3 fuses, 360V, 16A. So those can use LOTS of power
[23:51:36 CEST] <grublet> BtbN: yeah i derped there
[23:51:45 CEST] <grublet> oven would be on 220v here
[23:51:49 CEST] <grublet> 240*
[23:51:51 CEST] <grublet> not 120
[23:52:17 CEST] <grublet> we dont use actual fuses here
[23:52:32 CEST] <kinkinkijkin> we use a mix of fuses and a breaker
[23:52:48 CEST] <BtbN> Well, they are all switch-based, only old installations still have melting fuses
[23:52:58 CEST] <grublet> some of the outlets here are fused, usually stuff like the bathroom outlet because of things like haidriers
[23:53:04 CEST] <kinkinkijkin> the breaker has a fuse on it that goes in case of when the breaker is being held on
[23:53:05 CEST] <grublet> thats what i meant
[23:53:08 CEST] <grublet> old style fuses
[23:53:40 CEST] <kinkinkijkin> outlets in the kitchen and bathroom have a second breaker on them
[23:53:44 CEST] <kinkinkijkin> but this one is not fused
[23:53:52 CEST] <grublet> yeah i was mistaken
[23:53:56 CEST] <grublet> ours have a second breaker, not fuse
[23:54:05 CEST] <BtbN> Our flat is ancient
[23:54:08 CEST] <kinkinkijkin> I'm in canada, wouldn't be surprised if it was different
[23:54:10 CEST] <BtbN> we have one outlet in every room
[23:54:15 CEST] <BtbN> and _all_ of them are on the same fuse
[23:54:19 CEST] <grublet> fuck that
[23:54:21 CEST] <BtbN> so we can only use 3600W, in the entire flat
[23:54:27 CEST] <furq> nice
[23:54:32 CEST] <BtbN> Two PCs, the fridge, TV, ...
[23:54:34 CEST] <BtbN> everything
[23:54:34 CEST] <grublet> that's something ive never had to do, worry about how many watts im using
[23:54:51 CEST] <kinkinkijkin> I live in government-owned housing so electrics are updated to be "good" every time a tenant leaves
[23:54:52 CEST] <grublet> i have a gaming pc with 2 monitors, guitar amnp, electric heater running at the same time
[23:54:54 CEST] <BtbN> The super stupid thing is, in the breaker box, we have one for every room
[23:54:56 CEST] <grublet> i would set your house on fire
[23:55:04 CEST] <BtbN> but the actual wiring doesn't allow that, so all but one of them are unused
[23:55:13 CEST] <BtbN> you would just blow the fuse
[23:55:20 CEST] <BtbN> that's the whole point of it
[23:55:33 CEST] <grublet> kinkinkijkin: government owned anything is generally a bad idea
[23:55:41 CEST] <grublet> BtbN: it was a joke
[23:55:47 CEST] <kinkinkijkin> local government provided housing for poor people
[23:55:58 CEST] <kinkinkijkin> specifically so that poor people can live in safe neighbourhoods
[23:56:01 CEST] <grublet> kinkinkijkin: my last place was subsidized, yeah
[23:56:03 CEST] <grublet> fuck that
[23:56:11 CEST] <grublet> had mold, shower didnt work for 6 months, etc
[23:56:22 CEST] <furq> lol
[23:56:30 CEST] <furq> i lived in my mate's council house for a few months years ago
[23:56:32 CEST] <kinkinkijkin> we're not talking about the same country tho
[23:56:34 CEST] <grublet> they had the nerve to evict me when i refused to pay rent
[23:56:36 CEST] <furq> the ceiling in the front room caved in
[23:56:41 CEST] <furq> it took them like three months to fix it
[23:56:49 CEST] <BtbN> From my experience, living in a house that's owned by some semi-public organization is way better, as they actually care about your well being, and not only about their profit
[23:56:51 CEST] <grublet> kinkinkijkin: so is government owned shit better over there
[23:56:56 CEST] <kinkinkijkin> all our stuff works, the only issues with this house were uninspectable at the last inspection or caused by us
[23:57:00 CEST] <BtbN> When I lived with a private landlord, he only fixed things when he absolutely had to
[23:57:00 CEST] <kinkinkijkin> yes grublet
[23:57:02 CEST] <kinkinkijkin> by a lot
[23:57:09 CEST] <grublet> 'well jokes on you this is america, the government doesnt care
[23:57:20 CEST] <BtbN> Here I call because of a slightly dripping water outlet, and the next day someone comes and fixes it
[23:57:24 CEST] <furq> i've had awful private landlords as well tbh
[23:57:36 CEST] <kinkinkijkin> by comparison, last privately-owned renting we did was in a slum, and the landlord didn't fix stuff
[23:57:39 CEST] <kinkinkijkin> even when he had to
[23:57:45 CEST] <grublet> mine was income based but also accepted section 8 i believe
[23:57:55 CEST] <kinkinkijkin> we got a roach and squirrel infestation, exposed wires
[23:57:58 CEST] <grublet> i wasnt even in a bad part of town
[23:58:07 CEST] <kinkinkijkin> a window broke at one point
[23:58:20 CEST] <kinkinkijkin> whole place smelled of cigarettes
[23:58:23 CEST] <furq> one time they were installing new gas pipes, so we were supposed to have no gas for like 8 hours while they did the work
[23:58:30 CEST] <grublet> right before i got evicted my complex started getting overrun by heroin addicts and drunk vagrants
[23:58:46 CEST] <grublet> so whatever, nothing i couldnt live without
[23:59:00 CEST] <furq> then the landlord just appeared in the house after they'd been in the house for hours, and started kicking up a fuss about how they were going to put a gas meter in a cupboard which meant he'd have to pay someone certified if he wanted to change the cupboard
[23:59:01 CEST] <grublet> lived in my car for a few weeks til i found this place, roomates i pay a monthly lease
[23:59:06 CEST] <furq> and insisted that they put the meter outside
[23:59:11 CEST] <furq> so we had no gas for three or four days
[23:59:20 CEST] <furq> and also they'd already drilled the hole in the wall to run the pipe through
[23:59:30 CEST] <grublet> furq: having gas is very rare here in the us
[23:59:33 CEST] <grublet> most shit is electric
[23:59:35 CEST] <furq> so in that cupboard, there was a pipe coming in through the outer wall, then it went immediately back outside again
[23:59:42 CEST] <grublet> lol
[23:59:50 CEST] <grublet> smart ass
[00:00:00 CEST] --- Sun May 7 2017
1
0
[00:10:03 CEST] <kierank> there are options not available on the cli
[00:19:46 CEST] <kierank> BBB: http://www.streamingmediaglobal.com/Articles/ReadArticle.aspx?ArticleID=118…
[00:19:47 CEST] <kierank> congrats
[00:22:11 CEST] <jamrial> whoa, neat
[00:27:09 CEST] <BBB> sweet
[00:27:19 CEST] <BBB> why is everyone still doing hevc?
[00:27:39 CEST] <BBB> I guess 10bit support in hevc is better developed than it is for vp9, particularly in terms of client support
[00:27:42 CEST] <BBB> (tvs etc.)
[00:28:20 CEST] <nevcairiel> vp9 also lacks any kind of in-band metadata like SEI for HDR or whatnot, using the container is a bit awkward, wonder if they have that for av1
[00:28:45 CEST] <BBB> I think the reason is that for internet streaming this stuff is unlikely to change within a stream
[00:28:56 CEST] <BBB> and for stream switching you can use container-level stuff like HLS or whatever
[00:29:17 CEST] <BBB> I dont think av1 is doing this stuff differently ATM
[00:29:25 CEST] <BBB> (but I dont know all av1 details)
[00:29:32 CEST] <nevcairiel> i would still prefer all video relevant things to come from the bitstream
[00:29:44 CEST] <nevcairiel> piecing it together from different sources is always awkward
[00:30:01 CEST] <BBB> thats true
[00:30:22 CEST] <BBB> brb, dinner
[00:30:25 CEST] <nevcairiel> there is also problems with "who is right" which noone ever specifies
[00:30:42 CEST] <nevcairiel> like vp9 has some color matrix flags, but the container has more
[00:30:48 CEST] <nevcairiel> what if they disagree
[00:30:51 CEST] <BBB> I certainly agree vui-style signaling in vp9 could be improved
[00:31:05 CEST] <BBB> I think the container level takes priority becuse it was added since the codec level stuff was incomplete/suboptimal
[00:31:13 CEST] <BBB> but youre right, who knows, right? :)
[00:31:15 CEST] <BBB> brb
[00:33:37 CEST] <Compn> 8%!!!!!!!
[00:34:46 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:a234b5ade3ca: avcodec/mdec: Fix signed integer overflow: 28835400 * 83 cannot be represented in type 'int'
[00:34:47 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:a8ad83b793e8: avcodec/aacsbr_template: Do not leave bs_num_env invalid
[00:34:48 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:12dea8a5a153: avcodec/ivi: Free custom blk_vlc
[00:34:49 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:35f3df0d76e2: avutil/softfloat: Fix multiple runtime error: left shift of negative value -8
[00:36:33 CEST] <TD-Linux> nevcairiel, https://aomedia-review.googlesource.com/#/c/8738/
[00:37:30 CEST] <nevcairiel> man gerrits ui is so terrible
[00:37:45 CEST] <TD-Linux> ?polygerrit=0 makes it tolerable
[00:37:58 CEST] <nevcairiel> thats better
[00:39:16 CEST] <nevcairiel> those fields added there are the very least tehy should have, still no arbitrary metadata for eg. HDR
[00:39:49 CEST] <TD-Linux> yes, the HDR level information isn't there yet
[00:40:31 CEST] <nevcairiel> one problem with HDR is that the tech is still evolving, so without some extensible syntax elements like SEI it will be very limited very fast
[00:40:51 CEST] <nevcairiel> HEVC is adding a bunch new HDR signaling SEIs in the next spec update
[00:41:23 CEST] <TD-Linux> yes, extension points for metadata are quite desired so I expect them to get in at some point
[00:42:10 CEST] <nevcairiel> wasnt the bitstream supposed to freeze soon
[00:43:59 CEST] <TD-Linux> BBB, also nice
[00:44:49 CEST] <nevcairiel> everyone said vpxenc rate-control was garbage, but they never fixed it, so good for BBB :)
[00:45:02 CEST] <TD-Linux> atomnuker is fixing it t oo
[00:59:50 CEST] <jamrial> nevcairiel: pushed until the end of this year it seems
[01:10:49 CEST] <cone-036> ffmpeg 03James Almer 07master:214f4133c4cb: avcodec/hevc_parser: move hevc_find_frame_end() down in the file
[01:10:50 CEST] <cone-036> ffmpeg 03James Almer 07master:859cc5c8e662: avcodec/hevc_parser: cosmetics
[02:12:38 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:523205ce1ed9: avcodec/snowdec: Check qbias
[02:56:58 CEST] <james999> endrift: it said you closed a thread about mGBA link from 2015 a bit back
[02:57:20 CEST] <james999> was wondering if that's because the issue was fixed or you decided to drop it
[04:27:26 CEST] <wm4> Subject: [libav-devel] [PATCH 0-9/200] Introduction to a new channel layout API
[04:27:29 CEST] <wm4> what a good start
[04:37:16 CEST] <kierank> wm4: not actually that many changes
[04:37:22 CEST] <kierank> but it's done as a 200 patchset
[04:38:05 CEST] <wm4> probably 1 per decoder/encoder/filter
[04:42:01 CEST] <jamrial> yeah, same as codecpar and such
[04:54:24 CEST] <philipl> It's a great way to catch up on being 1000 changes behind :-)
[04:57:34 CEST] <wm4> I expect most of those patches to be quite trivial (just converting between channel mask and the new struct)
[04:58:04 CEST] <jamrial> in some cases they squash it all into one as well
[04:58:06 CEST] <wm4> though the fact that ffmpeg for some reason kept a separate channel count complicates this
[04:58:10 CEST] <jamrial> codecpar was squashed, bitstream reader wasn't
[05:18:04 CEST] <cone-860> ffmpeg 03Michael Niedermayer 07master:e813df4fa345: avcodec: Avoid splitting side data repeatedly
[06:38:37 CEST] <alevinsn> jkqxz: you there>
[06:38:38 CEST] <alevinsn> ?
[06:39:14 CEST] <alevinsn> jkqxz: Before I submit the qsv patches to the ML, I wanted to confirm with you that the way I represented you and Luca are okay
[06:39:27 CEST] <alevinsn> in the patches on your Web site, you had signed-off-by for both you and Luca
[06:39:48 CEST] <alevinsn> I changed that to Reviewed-by, which I've seen James Almer do in his patches
[06:39:51 CEST] <alevinsn> is that okay?
[06:41:20 CEST] <atomnuker> (those things are mostly pointless and some people omit them, don't take them seriously)
[06:42:00 CEST] <atomnuker> signed-off means you "sign-off" to the policies of the project, whatever that means, but you already do by submitting so its pointless
[06:46:37 CEST] <Compn> doesnt hurt to ask
[06:59:36 CEST] <alevinsn> I think it is nice to give proper credit
[07:00:05 CEST] <alevinsn> but signed-off-by seems to be associated with the author of the patch
[07:07:14 CEST] <wm4> that's how I interpret it
[11:39:32 CEST] <jkqxz> alevinsn: To my mind, signed-off-by is the set of people who signed off on something for it to be committed. Therefore, I would add it to things which I commit as maintainer of the relevant thing.
[11:40:01 CEST] <jkqxz> If the author is committing it themselves to code they maintain, then maybe only they appear. (Or not at all, since that is implicit.)
[11:40:08 CEST] <jkqxz> People are pretty inconsistent about using it, though.
[11:40:11 CEST] <nevcairiel> the SOB header means all sorts of different things to different people, the original usage the linux kernel uses is usually only used there =p
[11:40:25 CEST] <jkqxz> True.
[12:41:52 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:c535436cbeea: avcodec/mlpdec: Fix runtime error: left shift of negative value -22
[12:41:52 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:b20c71409b24: avcodec/fic: Fix multiple left shift of negative value -15
[12:41:52 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:c0ffcb34c7e9: avcodec/clearvideo: Fix multiple runtime error: left shift of negative value -1024
[13:17:03 CEST] <ubitux> nevcairiel: how do you deal with align for cropping?
[13:17:22 CEST] <ubitux> realloc when left cropping?
[13:18:26 CEST] <ubitux> same question with sample skipping
[13:19:15 CEST] <nevcairiel> probably
[13:19:37 CEST] <BtbN> wm4, feel free to push that cuvid patch btw.
[13:20:06 CEST] <wm4> already did
[13:20:07 CEST] <ubitux> nevcairiel: it could be much faster if the dsp was handling the unaligned part with C
[13:20:13 CEST] <ubitux> or something along these lines
[13:20:26 CEST] <BtbN> ah, missed that.
[13:20:44 CEST] <nevcairiel> ubitux: in most cases you would have to handle the entire thing in C then, which I doubt is going to be any faster then
[13:20:58 CEST] <nevcairiel> and it seems like a questionable optimization with a lot of complexity
[13:22:08 CEST] <ubitux> malloc+memcpy isn't great either when all you want is trimming 3 pixels on the left
[13:22:38 CEST] <ubitux> but i don't know, it's hard to have a general rule for that
[13:24:05 CEST] <BtbN> Why not just add an offset to the beginning, and reduce the width?
[13:24:20 CEST] <BtbN> Because of alignment of the initial pointer?
[13:24:49 CEST] <ubitux> yes
[13:25:08 CEST] <nevcairiel> alignment is two fold, you need to first pixel to be aligned properly of course, and the stride needs to be aligned so that further lines are also aligned
[13:25:54 CEST] <BtbN> yeah, probably not possible without either a memcpy, or a cropping parameter at the frame
[13:26:02 CEST] <ubitux> which reminds me that i never got done with png dsp on aarch64 because of the alignment requierement
[13:26:11 CEST] <ubitux> afaik the x86 dsp is handling it manually
[13:26:19 CEST] <ubitux> to support DR or whatever it was
[13:26:40 CEST] <ubitux> (or was it pngdec?)
[13:30:10 CEST] <ubitux> ah it wasn't about alignment but about padding
[13:30:25 CEST] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-February/189617.html
[13:31:05 CEST] <wm4> libav adds a cropping rect to AVFrame, so in theory you can crop by pixel
[13:31:30 CEST] <BtbN> But doesn't that mean that every single encoder/filter/.. needs to be aware of it?
[13:31:31 CEST] <wm4> of course that might be unusable in general
[13:31:35 CEST] <wm4> that too
[13:31:52 CEST] <ubitux> "if a user app returns pointers to some memory for direct rendering from get_buffer then it might be all kinds of stuff"
[13:31:56 CEST] <BtbN> filters probably not as much, as long as they pass it through untouched
[13:32:03 CEST] <ubitux> "for example it might be aligned but there might be data to the right like window decorations/border"
[13:32:10 CEST] <nevcairiel> get_buffer specifically documents alignment requirements
[13:33:12 CEST] <ubitux> shouldn't we have an alignment requirement check in avcodec encode side doing a realloc if needed?
[13:33:29 CEST] <nevcairiel> perhaps
[13:33:37 CEST] <ubitux> or we want it at frame level such that even lavfi could always assume alignment between filters?
[13:33:53 CEST] <nevcairiel> I also said as much in my reply to nicolas, but I dont think per-codec alignment info is a practical thing
[14:44:14 CEST] <BBB> nevcairiel: I partially disagree with what you wrote
[14:44:23 CEST] <BBB> nevcairiel: I think a per-codec-*instance* is crazy
[14:44:28 CEST] <BBB> nevcairiel: but per-codec certainly makes sense
[14:44:37 CEST] <BBB> not all codecs have avx2
[14:44:48 CEST] <BBB> and updating that per-codec isnt so hard, you could even integrate that into the dsp_init functions
[14:45:27 CEST] <BBB> unsigned ff_h264dsp_init(H264DSPContext *ctx); <- return value is max_alignment
[14:45:33 CEST] <BBB> and then up that value for each arg dsp init
[14:45:39 CEST] <BBB> (or pointer; whatever)
[14:45:51 CEST] <BBB> however& I think it should be per-codec, not per-codec-instance
[14:46:02 CEST] <BBB> since its unlikely that one h264 needs 16 and another 32
[14:46:07 CEST] <BBB> they likely both need 32
[14:49:53 CEST] <nevcairiel> per codec makes determining that even harder though, since you cant call the dsp function to figure it out
[14:58:09 CEST] <BBB> maybe
[14:58:41 CEST] <BBB> or you declare it in the dsp header file, and then you can
[14:58:57 CEST] <BBB> we already have a substandard system (configure) to define which dec/* depends on which dsp
[14:59:09 CEST] <BBB> so why not use that and automatically generate alignment contraints from that?
[14:59:14 CEST] <BBB> this shouldnt be super-hard
[14:59:30 CEST] <BBB> per-codec enable/disable is also configure-generated
[15:24:59 CEST] <nevcairiel> I'm mostly worried about even more subtle bugs
[15:25:08 CEST] <nevcairiel> because our typical test cases of memory are always fully aligned
[15:25:15 CEST] <nevcairiel> so partial alignment will basically not be tested much
[15:33:25 CEST] <ubitux> pixelutils tests do test alignment :3
[15:35:17 CEST] <wm4> alignment of what?
[15:35:23 CEST] <ubitux> buffer
[15:35:28 CEST] <ubitux> :/
[15:35:40 CEST] <ubitux> the pointer passed to the dsp func
[15:35:54 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:4654baff125d: avcodec/opus_silk: Fix integer overflow and out of array read
[15:35:55 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:d58fe0177453: tools/target_dec_fuzzer: Do not use codec_id to look up decoder, but use selected decoder directly
[15:35:56 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:38e79d9d9c94: tools/target_dec_fuzzer: Do not attempt to fuzz VDPAU, its not supported
[15:35:57 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:fc2c420b8293: avcodec/mimic: Fix runtime error: left shift of negative value -1
[15:35:59 CEST] <ubitux> it misalign it before testing function that are supposed to support misaligned data
[16:10:13 CEST] <iive> nevcairiel: what is the issue here?
[16:10:28 CEST] <iive> also isn't avx a lot more relax about alignment?
[16:37:59 CEST] <BBB> nevcairiel: well
[16:38:06 CEST] <BBB> nevcairiel: I believe most affected code is simd, right?
[16:38:12 CEST] <BBB> nevcairiel: if we make it a goal to get 100% checkasm coverage
[16:38:19 CEST] <BBB> nevcairiel: we can test it effectively as part of checkasm
[16:38:22 CEST] <BBB> nevcairiel: which is part of fate
[16:38:27 CEST] <BBB> nevcairiel: wouldnt that be enough?
[16:57:32 CEST] <wm4> it's funny how I noticed problems with unaligned audio data and certain encoders years ago
[16:57:58 CEST] <wm4> I was all like "ok this is libavcodec bullshit" and simply changed my internal audio code to work like avframe
[16:59:45 CEST] <JEEB> sounds like a valid way of handling it
[17:12:32 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:4ace2d22192f: avcodec/g723_1: Fix multiple runtime error: left shift of negative value
[17:12:33 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:12936a4585bc: avcodec/dfa: Fix signed integer overflow: -2147483648 - 1 cannot be represented in type 'int'
[17:12:34 CEST] <cone-080> ffmpeg 03Michael Niedermayer 07master:9bf4523e4014: avcodec/webp: Fix null pointer dereference
[17:15:27 CEST] <durandal_1707> ubitux: how is fft handled with avfft in lavc?
[17:16:21 CEST] <durandal_1707> first element and last one is 0 for img part
[17:34:22 CEST] <BBB> durandal_1707: the first elements img is the last elements real
[17:34:51 CEST] <BBB> durandal_1707: so that it doesnt require (2^n)+1 elements where the first/last img are 0, but instead just 2^n elements, thus making memory management slightly easier
[17:34:53 CEST] <BBB> (all this IIRC)
[20:53:23 CEST] <jamrial> michaelni: when were you planning on tagging 3.3.1?
[20:53:49 CEST] <jamrial> even if only a few fixes are backported, at least one of them is a very important CLI one
[21:04:15 CEST] <michaelni> jamrial, i wanted to fix and backport a few more issues, ossfuzz found quite a few new issues in the last days
[21:04:31 CEST] <jamrial> michaelni: ah ok
[21:13:38 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:0884b1c5ffe0: avcodec/golomb: Assert that k is valid in get_ur_golomb_jpegls()
[21:13:38 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:7b6a51f59c46: avcodec/shorten: Check k in get_uint()
[21:13:38 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:2ef0f3927114: avcodec/mss3: Change types in rac_get_model_sym() to match the types they are initialized from
[21:13:38 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:1283c4244767: avcodec/hq_hqa: Fix runtime error: left shift of negative value -207
[21:13:38 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:df8575584dca: avcodec/shorten: Check residual size
[21:29:27 CEST] <ubitux> michaelni: "unsupportd" typo in df8575584dcacde187d92ee3142800373fd34882
[22:24:44 CEST] <cone-671> ffmpeg 03Aaron Levinson 07master:b9d2005ea5d6: avformat/utils: free AVStream.codec properly in free_stream()
[22:53:49 CEST] <cone-671> ffmpeg 03James Almer 07release/3.3:4f19268eee12: avcodec/options: factorize avcodec_copy_context() cleanup code
[22:53:50 CEST] <cone-671> ffmpeg 03James Almer 07release/3.3:8119efdbec1f: avcodec/options: do a more thorough clean up in avcodec_copy_context()
[22:53:51 CEST] <cone-671> ffmpeg 03Aaron Levinson 07release/3.3:329176adc52c: avformat/utils: free AVStream.codec properly in free_stream()
[23:25:19 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:277e397eb596: avutil/softfloat: Fix overflow in av_div_sf()
[23:25:20 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:e1b60aad77c2: avcodec/cdxl: Check format parameter
[23:25:21 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:8a8335de030a: avcodec/dds: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
[00:00:00 CEST] --- Sun May 7 2017
1
0