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

Tue Nov 28 03:05:03 EET 2017

[00:00:15 CET] <philipl> jkqxz: I had gimp save me a jpg and it blew up when I tried to decode it
[00:00:26 CET] <philipl> not in nvdec code, mind you...
[00:03:59 CET] <philipl> Seems to dislike progressive dct
[00:09:29 CET] <philipl> Alright. So I generated single images with gimp across the matrix of (progressive, 420/422/444, integer/float/fast-integer)
[00:09:59 CET] <philipl> All the 420 progressive and 444 progressive ones blow up. The rest work, including 422 progressive.
[00:10:09 CET] <philipl> It's dying in an avx transform, which I guess doesn't apply to 422
[00:10:27 CET] <philipl> ff_simple_idct8_put_avx
[00:10:46 CET] <philipl> corrupted stack trace
[00:10:46 CET] <philipl> sad
[00:21:40 CET] <philipl> jkqxz: I want to say that the there's a dependency on some step in the decode taking place before the idct works. One of the parameters passed to the idct is 0 with hwaccel and non-zero otherwise.
[00:22:21 CET] <atomnuker> why does the idct even run when doing a hardware decode?
[00:22:29 CET] <jcdutton> Isn't there a fast transform between mjpeg and H.264 ? Like a half decode then re-encode?
[00:22:49 CET] <philipl> atomnuker: I could not say. Perhaps that is the problem.
[00:23:19 CET] <philipl> It's happening as part of parsing EOI
[00:23:23 CET] <atomnuker> jcdutton: no, both use different dcts
[00:23:24 CET] <philipl> but I don't know my jpeg structures.
[00:25:25 CET] <jkqxz> Oh, I missed some processing in the progressive case.
[00:25:32 CET] <jkqxz> Yeah, it will do something nasty there.
[00:26:07 CET] <jkqxz> Will fix.
[00:26:16 CET] <philipl> Cheers.
[00:27:30 CET] <jkqxz> So nvdec actually supports all of those?
[00:29:16 CET] <philipl> everything else worked.
[00:29:27 CET] <philipl> I have not tried any kind of lossless as yet
[00:35:29 CET] <jcdutton> atomnuker, but I heard there was some short cut in the conversion. 
[00:41:26 CET] <atomnuker> I guess if you hack the coefficients enough you could get something which resembles the input for h264 baseline (which has 8x8 transforms, high has 4x4)
[00:41:48 CET] <jkqxz> Other way around.
[00:42:11 CET] <jkqxz> 8x8 transforms are optional in the higher profiles.
[00:43:31 CET] <atomnuker> yep
[00:43:37 CET] <atomnuker> (but mandatory in lower profiles)
[00:44:44 CET] <kierank> other way round
[00:44:52 CET] <kierank> baseline and main don't have 8x8
[00:46:08 CET] <jcdutton> I wonder why web cams use mjpeg. I would guess that H.264 with only I-Frames would at least be easier to compress later.
[00:47:11 CET] <kierank> you can get to high bitrates with mjpeg
[00:47:22 CET] <kierank> whereas with h264 it would be O(cabac)
[00:47:31 CET] <jcdutton> I guess mjpeg is just the cheapest to encode.
[01:07:23 CET] <c3r1c3-Win> Also keep in  mind the patents for h264 on hardware... as far as I know there are none for MJPEG.
[01:10:29 CET] <jkqxz> Standardised by ITU in 1992 - should have expired by now if there were.
[01:29:50 CET] <atomnuker> jamrial: "It's avx2 and using ymm regs, not avx" <- but its under an if cpuflag(avx)
[01:30:41 CET] <jamrial> and as i said in my previous email, that's wrong ang should be avx2
[01:32:28 CET] <jamrial> there are no avx functions, and he's adding an avx2 one
[01:32:32 CET] <jamrial> the check works as intended, but as demostrated by your confusion, it should ideally be more specific :p
[01:33:35 CET] <atomnuker> ah, I see, yeah that confused me
[01:46:20 CET] <jamrial> something broke msvc
[01:51:45 CET] <atomnuker> to be fair msvc is already broken :)
[01:56:07 CET] <jamrial> that's far from fair :p
[01:56:12 CET] <jamrial> http://git.videolan.org/?p=ffmpeg.git;a=shortlog;h=89248-g3701d499f8;hp=89243-g8794e0c037 one of these broke it
[01:57:27 CET] <jamrial> none really look related, though
[02:06:03 CET] <jamrial> jkqxz: varied undefined references to ff_*_nvdec_hwaccel on --enable-random builds when linking lavc
[02:26:11 CET] <cone-822> ffmpeg 03James Almer 07master:921d7af6e9e6: avcodec/mpeg4videodec: fix preprocessor check for the nvdec hwaccel
[02:26:12 CET] <cone-822> ffmpeg 03James Almer 07master:1eee394c7c84: avcodec/vc1dec: fix preprocessor checks and hw_configs lists for the hwaccels
[02:26:14 CET] <jamrial> jkqxz: ^
[02:33:04 CET] <atomnuker> what the hell is libavcodec/parser.c doing?
[02:33:17 CET] <atomnuker> av_first_parser is always NULL
[02:33:42 CET] <atomnuker> oh, wait, nvm
[02:35:05 CET] <jamrial> atomnuker: are you sure reverting those two commits will not help? it simplifies the functions considerably, removing the last_whatever pointer
[02:37:26 CET] <atomnuker> they didn't remove it iirc
[02:38:57 CET] <philipl> jamrial: thanks
[02:39:03 CET] <jamrial> atomnuker: they added it. i mean that reverting them will remove it
[02:39:50 CET] <atomnuker> I'll look at them again
[02:41:52 CET] <atomnuker> yeah, 133fbfc7811 isn't going to make things any harder or easier, it maps to just some atomic loads or stores
[02:45:22 CET] <jamrial> and reverting ec464c96831, effectively getting rid of the last_avcodec pointer?
[02:47:56 CET] <atomnuker> yeah, both aren't too bad but I'll deal with them once I've dealt with parser.c
[02:48:09 CET] <atomnuker> any ideas why "static _Atomic AVCodecParser *av_first_parser = NULL;" isn't accepted as input to atomic_load()?
[02:48:22 CET] <atomnuker> "error: address argument to atomic operation must be a pointer to _Atomic type ('_Atomic(AVCodecParser) ***' invalid)"
[02:49:26 CET] <SortaCore> no brackets and where the * is
[02:51:59 CET] <atomnuker> that worked, tnx
[02:52:15 CET] <SortaCore> *completely guessed it*
[03:28:53 CET] <jamrial> can we please get the amd headers + encoder committed in some form? with or without a concrete policy about external headers, we can decide that latter
[03:29:13 CET] <jamrial> but right now we're being kinda unfriendly with a contributor
[03:30:07 CET] <atomnuker> I'd rather have a separate repo for these headers if possible
[03:32:55 CET] <cone-822> ffmpeg 03Michael Niedermayer 07master:38f966b2222d: tests/checkasm/float_dsp: Increase allowed difference for float_dsp.vector_dmul
[03:32:56 CET] <cone-822> ffmpeg 03Michael Niedermayer 07master:3aad94bf2b14: avcodec/kgv1dec: Check that there is enough input for maximum RLE compression
[03:32:57 CET] <cone-822> ffmpeg 03Michael Niedermayer 07master:9cc926da7d99: avcodec/h264idct_template: Fix integer overflow in ff_h264_idct8_add
[03:32:58 CET] <cone-822> ffmpeg 03Michael Niedermayer 07master:883de7e8b4fe: libavformat/mov: Replace duplicate stream_nb check by assert
[03:32:59 CET] <cone-822> ffmpeg 03Michael Niedermayer 07master:97c00edaa043: avcodec/mlpdsp: Fix signed integer overflow, 2nd try
[03:33:00 CET] <cone-822> ffmpeg 03Michael Niedermayer 07master:8e7ac4f04903: tests/fate-run: Use -bitexact
[03:33:24 CET] <philipl> I'm fine with shipping the header.
[03:33:41 CET] <jamrial> again, we can decide that later, as it requires moving the nvenc and avisynth headers to external repos as well
[03:35:32 CET] <atomnuker> ok, I'm fine with that
[03:36:25 CET] <jamrial> philipl: then please say so in any of the relevant threads. preferably the latest, otherwise carl will eventually drive him mad or angry
[03:39:23 CET] <philipl> I said so in one of the threads, as did Btbn, but I'm happy to repeat myself.
[03:48:32 CET] <philipl> sent
[03:50:04 CET] <jamrial> thanks
[04:12:31 CET] <whysohard> Hi guys. For years I couldn't understand. Ffmpeg is very powerful. But it cannot handle with a very simple trim case: Trim end of file.. There are several commands -ss -sseof -t... But it's not sufficient.... There is a question about that: https://stackoverflow.com/questions/31862634/i-need-to-cut-mp4-videos-a-part-at-the-beginning-and-a-part-at-the-end-in-a-bat The solution is sooo complex. Why dont we have an easy single co
[04:15:46 CET] <whysohard> I've thousands of video. All of them are different length. I want only remove last 5 seconds! I could easily if I want to remove FIRST 5 seconds.... The problem is LAST! But the solution is very complex. 
[04:25:05 CET] <stevenliu> src/libavcodec/nvdec_vp8.c: In function nvdec_vp8_start_frame:
[04:25:05 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:68: error: unknown field frame_type specified in initializer
[04:25:05 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:68: warning: missing braces around initializer
[04:25:07 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:68: warning: (near initialization for (anonymous).CodecSpecific.vp8.Reserved1)
[04:25:09 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:69: error: unknown field version specified in initializer
[04:25:11 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:70: error: unknown field show_frame specified in initializer
[04:25:13 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:70: warning: excess elements in struct initializer
[04:25:15 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:70: warning: (near initialization for (anonymous).CodecSpecific.vp8)
[04:25:17 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:71: error: unknown field update_mb_segmentation_data specified in initializer
[04:25:19 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:71: warning: excess elements in struct initializer
[04:25:21 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:71: warning: (near initialization for (anonymous).CodecSpecific.vp8)
[04:25:38 CET] <stevenliu> dose this been fixed? or need do something?
[04:26:27 CET] <stevenliu> git pull;rm -rf *;../configure  --toolchain=valgrind-memcheck --enable-fontconfig --enable-gpl --enable-libx264 --enable-version3 --cc='ccache gcc' --enable-nonfree;make -j16
[04:29:09 CET] <jamrial> what compiler? gcc 7.2.0 doesn't complain
[04:29:25 CET] <stevenliu> gcc version 4.4.7 20120313 (Red Hat 4.4.7-18) (GCC)
[04:29:54 CET] <stevenliu> CentOS release 6.9 (Final)
[04:31:15 CET] <atomnuker> jamrial: ...there isn't even a need for atomics at all in avfilter_register
[04:31:19 CET] <atomnuker> fuck
[04:31:29 CET] <atomnuker> it doesn't modify any external state
[04:31:46 CET] <atomnuker> avpriv_atomic_ptr_cas was just used out of convenience
[04:32:06 CET] <atomnuker> because ternary operators are hard
[04:34:08 CET] <atomnuker> I'm willing to bet at least one of the other 4 places that function is used is the same
[04:43:05 CET] <jamrial> stevenliu: does https://pastebin.com/raw/EBckJSFT fix compilation for you?
[04:46:04 CET] <stevenliu> I have disabled_nvdec module , Let me try this patch again :D
[04:47:20 CET] <philipl> What misfortune leads you to using such an old compiler?
[04:48:06 CET] <jamrial> his OS probably :p
[04:48:39 CET] <stevenliu> yes, Centos 6.9, just this reason :D
[04:48:55 CET] <stevenliu> ffmpeg won't support on CentOS6.9?
[04:49:29 CET] <philipl> What misfortune leads you to using such an old distro? :-)
[04:50:15 CET] <stevenliu> ffmpeg won't support on CentOS6.9?
[04:50:36 CET] <stevenliu> jamrial: src/libavcodec/nvdec_vp8.c:68: error: unknown field wFrameTagFlags specified in initializer
[04:50:55 CET] <jamrial> :/
[04:51:03 CET] <stevenliu> have problem always :D, maybe this should disabled default?
[04:51:39 CET] <jamrial> obviously not
[04:51:50 CET] <jamrial> philipl: why is CUVIDVP8PICPARAMS so different than the rest, for that matter?
[04:52:11 CET] <philipl> it has a bit field in an anoymous union.
[04:52:17 CET] <philipl> only one that has it,
[04:52:26 CET] <jamrial> i know, i'm asking why :p
[04:52:37 CET] <philipl> onky nvidia can answer that
[04:52:42 CET] <jamrial> it's like they went all "we must make this struct small. 8 bits for four fields!"
[04:52:48 CET] <jamrial> then they did the hevc one
[04:52:51 CET] <jamrial> with huge arrays
[04:53:10 CET] <philipl> Yeah. clearly implementation details leaking through
[04:53:35 CET] <philipl> vp8 isn't important enough to get more than one byte.
[04:54:44 CET] <philipl> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676
[04:55:08 CET] <philipl> It was fixed a long time ago, but centos 6 is even older.
[04:55:19 CET] <philipl> Will need to switch to dynamic initialisation.
[04:55:55 CET] <philipl> I still think it's nuts to be using centos 6 in this day and age, of course.
[04:56:21 CET] <stevenliu> I complie ffmpeg have no problem before, on centos 6
[04:56:35 CET] <jamrial> we have a lot of < 4.6 fate clients, though
[04:58:03 CET] <philipl> stevenliu: humour me: why do use centos 6?
[04:58:34 CET] <stevenliu> always using it online, no why
[04:59:01 CET] <philipl> This gcc feature was added 7 years ago.
[04:59:11 CET] <philipl> It's crazy.
[04:59:18 CET] <stevenliu> we don't want to change to newest version, there have unstable factor.
[05:00:42 CET] <philipl> I'll start by saying I'll fix this, but it'll cost you a rant about ancient distros and compilers.
[05:00:44 CET] <stevenliu> If use only at local, i can use newest version, but that is online system, support more and more user, we need more and more time to try the stable.
[05:01:19 CET] <philipl> gcc 4.4.3 is what? 10 years old; it's obviously a facetious argument to suggest it's the last stable gcc.
[05:01:52 CET] <stevenliu> no matter, i don't care that, i know use disable-nvdec, i just want say ,there have lots of centos 6 user, i don't know if they know use --disable-nvdec
[05:02:14 CET] <philipl> I know. It's not your fault. It's redhat's fault.
[05:02:29 CET] <philipl> They start with old components, then make a release that's supported for 10 years from them.
[05:02:34 CET] <stevenliu> fix it please :D
[05:03:40 CET] <philipl> jamrial: actually, why doesn't this initialization blow up on windows? Or fate hasn't fired yet?
[05:03:59 CET] <jamrial> it works fine here with mingw-w64
[05:04:07 CET] <jamrial> and msvc is currently broken for unrelated reasons
[05:09:19 CET] <philipl> jamrial: http://paste.ubuntu.com/26055929/
[05:09:29 CET] <philipl> bah. Ignore. has extra crap
[05:09:54 CET] <philipl> http://paste.ubuntu.com/26055932/
[05:09:55 CET] <philipl> that's better
[05:11:28 CET] <jamrial> still compiles fine with mingw-w64
[05:11:51 CET] <jamrial> also, it's decrepit, not decrepid :p
[05:12:15 CET] <philipl> foiled.
[05:12:16 CET] <philipl> Will fix
[05:13:37 CET] <jamrial> stevenliu, StevenLi_: can you try http://paste.ubuntu.com/26055932/ ?
[05:13:43 CET] <stevenliu> src/libavcodec/nvdec_vp8.c: In function nvdec_vp8_start_frame:
[05:13:43 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:76: error: CUVIDVP8PICPARAMS has no member named frame_type
[05:13:43 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:77: error: CUVIDVP8PICPARAMS has no member named version
[05:13:45 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:78: error: CUVIDVP8PICPARAMS has no member named show_frame
[05:13:47 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:79: error: CUVIDVP8PICPARAMS has no member named update_mb_segmentation_data
[05:13:49 CET] <stevenliu> src/libavcodec/qtrleenc.c: In function qtrle_encode_frame:
[05:14:54 CET] <philipl> I'm tempted to add a gcc check and say you don't get vp8 if your gcc is old and busted
[05:14:59 CET] <philipl> This is ridiculous
[05:15:06 CET] <jamrial> do that
[05:15:16 CET] <stevenliu> That is better way :)
[05:15:30 CET] <stevenliu> check if the gcc is ok :D
[05:15:39 CET] <philipl> We could also patch in names for the anonymous inners...
[05:16:07 CET] <philipl> but we have nice gcc check macros so I'll do that.
[05:20:01 CET] <philipl> jamrial: if I wanted to do this properly, I'd add a configure dependency
[05:20:27 CET] <philipl> It doesn't look like we have the right kind of test ready to do
[05:25:43 CET] <philipl> Oh man.
[05:25:48 CET] <philipl> This is ridiculous.
[05:30:41 CET] <atomnuker> jamrial: sent patches which remove all but the last usage of that function
[05:30:53 CET] <atomnuker> as it turned out NONE of the cases did require atomics
[05:31:05 CET] <atomnuker> so that function did nothing but slow down registration
[05:31:27 CET] <atomnuker> the last case doesn't look like it needs the function as well
[05:33:14 CET] <jamrial> so only the lock manager stuff remains after this?
[05:35:03 CET] <atomnuker> yeah
[05:36:44 CET] <atomnuker> avpriv_atomic_ptr_cas(mutex, *mutex, NULL);
[05:36:47 CET] <atomnuker> omfg
[05:37:17 CET] <atomnuker> this is essentially *mutext = *mutex == *mutet ? NULL : *mutex;
[05:37:53 CET] <atomnuker> and before that there's a av_free(*mutex);
[05:38:13 CET] <atomnuker> so just changing it to freep and removing the cas crap is enough for one of the two uses
[05:43:03 CET] <philipl> jamrial: http://paste.ubuntu.com/26056061/
[05:43:16 CET] <philipl> That's an attempt at using explicit braces, which is supposedly a workaround.
[05:43:34 CET] <philipl> Can you at least test it on what you have
[05:44:40 CET] <jamrial> seems to work on mingw-w64
[05:44:53 CET] <atomnuker> jamrial: okay, sent over the last patch, now there's absolutely no usage of any avpriv_atomic stuff
[05:45:01 CET] <atomnuker> I'll leave you with the honor of removing them
[05:45:08 CET] <atomnuker> because I'm going to bed
[05:45:38 CET] <philipl> jamrial: I'm going to push it then. fate is unfortunately hosed so I don't think we'll get a reading there for a while.
[05:45:48 CET] <philipl> stevenliu: can you try that patch?
[05:45:53 CET] <philipl> http://paste.ubuntu.com/26056061/
[05:49:19 CET] <tyng> durandal_1707 when i use the ffmpeg dnxhd muxer at 24fps it then interpret the file as 25fps
[05:51:45 CET] <tyng> get https://comfy.moe/mzsucy.mkv and try -c:v copy -f data at 24fps then ffprobe it back as 25fps
[05:53:00 CET] <cone-822> ffmpeg 03Philip Langdale 07master:b93d96a07be4: avcodec/nvdec: Make vp8 initialisation more 'compatible'
[05:53:23 CET] <philipl> stevenliu: I've pushed it, and hopefully it works. I'd really appreciate it if you could try it out.
[05:53:45 CET] <philipl> There are a couple of other possible ways to work around it but this is the least disruptive one if it works
[06:12:40 CET] <stevenliu> src/libavcodec/nvdec_vp8.c: In function nvdec_vp8_start_frame:
[06:12:40 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:72: warning: braces around scalar initializer
[06:12:41 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:72: warning: (near initialization for (anonymous).CodecSpecific.vp8.Reserved1[0])
[06:12:42 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:73: error: field name not in record or union initializer
[06:12:44 CET] <stevenliu> src/libavcodec/nvdec_vp8.c:73: error: (near initialization for (anonymous).CodecSpecific.vp8.Reserved1[0])
[06:13:16 CET] <stevenliu> have a lunnch, come back now.
[06:24:35 CET] <philipl> stevenliu: well, that's progress, I think. I'll send you another patch
[06:26:41 CET] <philipl> stevenliu: http://paste.ubuntu.com/26056297/
[06:47:58 CET] <stevenliu> compling
[06:48:43 CET] <stevenliu> this patch is ok mpw
[06:48:50 CET] <stevenliu> this patch is ok now
[06:49:50 CET] <philipl> *phew*
[06:49:53 CET] <philipl> Thanks for testing.
[06:49:55 CET] <philipl> I will push
[07:00:59 CET] <philipl> stevenliu: If you would be so kind, could I ask you to retry without the last patch (ie: try with current master)
[07:01:10 CET] <philipl> I booted a centos6 VM and I can't see why the previous logic wouldn't work
[07:21:34 CET] <cone-822> ffmpeg 03Philip Langdale 07master:0e93694e64cd: avcodec/nvdec: More effort to make vp8 compile with gcc < 4.6
[07:22:19 CET] <philipl> Well, I've pushed the second fix. Perhaps some day I'll be in a position to test a full compile and see if I can refine it, but at least it compiles now
[09:14:17 CET] <cone-822> ffmpeg 03Tobias Rapp 07master:26c0c84784f1: avformat/avienc: fix fields-per-frame value for interlaced video streams
[09:37:57 CET] <stevenliu> Ah, come back from hospital :D
[09:38:15 CET] <stevenliu> of course, philipl
[09:51:42 CET] <nevcairiel> philipl: thats why i really dont like this struct init syntax all the nvdec stuff uses =p
[09:53:10 CET] <nevcairiel> without the explicit names like in the last change, it even becomes quite unreadable
[09:58:23 CET] <nevcairiel> hm one of those atomic commits broke msvc compiling
[10:08:01 CET] <nevcairiel> oh its because windows.h has #define near
[10:16:02 CET] <rcombs> forgot to WIN32_LEAN_AND_MEAN?
[10:18:22 CET] <nevcairiel> nah thats unrelated to that
[10:19:18 CET] <nevcairiel> far and near are decades old keywords from 16-bit days and memory segmenting, so instead of having people remove them, they just defined them to empty <.<
[11:08:36 CET] <BtbN> Does only the VP8 hwaccel fail with old gcc? None of the others?
[11:09:28 CET] <nevcairiel> apparently they forgot to name some of the inner structs
[11:26:10 CET] <gmoryes> Hello, if I want to know the version of libavcodec, I should look to output of command "ffmpeg", and "libavcodec     56. 60.100 / 56. 60.100" the first number "56." - version? Am I right?
[11:26:41 CET] <BtbN> 56.60.100 is the version
[11:27:42 CET] <gmoryes> thanks!
[12:52:16 CET] <jkqxz> AMF encoder using proper headers: <http://sprunge.us/aPiQ>.
[12:52:32 CET] <jkqxz> I haven't tested it on Windows yet, I'll do that later and send it to the ML.
[12:52:36 CET] <jkqxz> But it works fine on Linux.
[12:53:11 CET] <jkqxz> (Where "works" means "builds but fails immediately at runtime because there is no library".)
[12:57:50 CET] <nevcairiel> should AV_PIX_FMT_D3D11 in ff_amf_pix_fmts be conditional on d3d11 support being build? i  did it like that in nvenc, dont want to claim to support it if its not build in
[12:59:59 CET] <jkqxz> Not sure it matters much?
[13:00:06 CET] <jkqxz> Probably more consistent, though.  I'll change it.
[13:56:13 CET] <cone-097> ffmpeg 03Paul B Mahol 07master:9152bda839c5: avfilter/af_silenceremove: fix logic error in EOF case
[14:09:38 CET] <cone-097> ffmpeg 03Carl Eugen Hoyos 07master:b7324950c0fc: lavd/alsa: Double maximum alsa buffer size.
[16:03:29 CET] <philipl> BtbN: it's just vp8. The rest are sane.
[16:11:07 CET] <jamrial> nevcairiel: do you know what could have broken msvc?
[16:11:47 CET] <jamrial> apparently it was one of these http://git.videolan.org/?p=ffmpeg.git;a=shortlog;h=89248-g3701d499f8;hp=89243-g8794e0c037 but none touch jpegls
[16:12:08 CET] <nevcairiel> [10:08:00] <nevcairiel> oh its because windows.h has #define near
[16:12:26 CET] <nevcairiel> .. and the atomic changes pull in windows.h in more files
[16:12:45 CET] <SortaCore> near is from 16-bit days isn't it?
[16:12:58 CET] <nevcairiel> [10:19:18] <nevcairiel> far and near are decades old keywords from 16-bit days and memory segmenting, so instead of having people remove them, they just defined them to empty <.<
[16:13:28 CET] <SortaCore> yay
[16:13:44 CET] <SortaCore> slap an #undef band-aid on it
[16:19:05 CET] <iive> far pointers should still exists in 32 and 64 bit x86. they are a couple of segment register and (32/64) offset.
[16:19:51 CET] <SortaCore> if it's defined to blank then it has no effect though?
[16:21:13 CET] <nevcairiel> with virtual memory stuff, you dont have to deal with that anymore, someone else does it for you, and 64-bit has enough pointer space to address quite a lot of memory directly either way
[16:25:43 CET] <iive> in 32 bit the offset is relative to the segment start address
[16:26:06 CET] <iive> in 64 bit the offset is relative to the effective address space (aka memory after paging)
[16:27:13 CET] <iive> still segments exists and could/are used for different things. e.g. PIC used a special segment to hold some tables
[16:28:30 CET] <iive> or making the stack segment non-executable.
[16:30:04 CET] <iive> it was possible to have segment+offset pointer is modern C, but I don't remember details about it.
[16:31:18 CET] <nevcairiel> possible perhaps, but the point is, you just dont
[16:31:25 CET] <nevcairiel> its all done under the hood
[16:34:19 CET] <cone-097> ffmpeg 03Paul B Mahol 07master:2d1594a8d6a7: avfilter/af_silenceremove: fix possible crash if supplied duration is negative
[16:55:06 CET] <BtbN> isn't there some LEAN_AND_MEAN define, to get rid of some of the cruft?
[16:55:32 CET] <philipl> I remember that from the mid 90s...
[16:58:07 CET] <philipl> nevcairiel: Regarding the messy static initialisation - I tried doing regular field assignment through a pointer but it apparently generated errors too - I'm not aware of what syntax you use if the names are not automatically resolved through the anonymous inners.
[17:23:31 CET] <atomnuker> jamrial / michaelni: can you review the atomics patches?
[17:40:48 CET] <cone-097> ffmpeg 03James Almer 07master:9d464dc3fccb: avformat/matroskaenc: actually enforce the stream limit
[17:49:29 CET] <atomnuker> "I would prefer if the bundled external headers were installed together with ffmpeg public headers"
[17:49:33 CET] <atomnuker> what is that guy on?
[17:50:29 CET] <kierank> that's really annoying
[17:50:41 CET] <kierank> it means you get these silly nvidia devices on by default
[17:50:51 CET] <jkqxz> Sounds like someone who actually wants the external repo with the cleaned headers.
[17:50:58 CET] <jkqxz> Rather than them being in ffmpeg at all.
[17:51:31 CET] <jkqxz> (Being able to use them in other projects was one of the arguments for that.)
[17:51:47 CET] <durandal_1707> help me find out ideas for new filters!
[17:51:58 CET] <kierank> durandal_1707: add new cineform features
[17:53:34 CET] <durandal_1707> cineform? only if i get paid
[17:55:02 CET] <kierank> get that guy to pay you
[17:55:45 CET] <kierank> though actually the files that use the temporal transform are historical files, probably no commercial value
[18:00:46 CET] <iive> durandal_1707: do we have a filter that syncs two video streams visually? e.g. if we have 2 inputs that are off by a few frames, make so similar/identical frames have same timestamps.
[18:02:28 CET] <jamrial> durandal_1707: like i said the other day, tilt shift?
[18:05:56 CET] <cone-097> ffmpeg 03Paul B Mahol 07master:eb86f72fcaf3: avfilter/vf_threshold: use correct linesize
[18:07:43 CET] <durandal_1707> jamrial: what?
[18:07:56 CET] <jamrial> suggestion for a filter
[18:19:00 CET] <BtbN> jkqxz, no, he actually wants to make them public headers.
[18:19:05 CET] <BtbN> Which is silly and not going to happen.
[18:19:25 CET] <BtbN> I won't watch over API/ABI compatiblity for nvidias headers.
[19:01:48 CET] <durandal_1707> jamrial: imagemagick have it, its basically mix of blured and normal with saturation and contrast boosted
[20:49:32 CET] <jdarnley> Can I do this operation with palignr? https://pastebin.com/zxc0gDup
[20:50:41 CET] <jdarnley> Gramner, jamrial, atomnuker, durandal_1707 ^
[20:54:15 CET] <iive> jdarnley: looks like something exactly for palign
[20:54:34 CET] <iive> assuming +16 is +mmsize
[20:55:14 CET] <iive> or maybe use xm0 
[20:56:02 CET] <jamrial> jdarnley: i think yes, palignr m1, m0, m2, 4 or so
[21:00:01 CET] <iive> the shift is in bytes, so 12 it is.
[21:31:19 CET] <atomnuker> jdarnley: >using crap outdated notation for registers
[21:32:47 CET] <atomnuker> use r0-r7, only old people who haven't seen the light of x86inc.asm use those names
[21:37:41 CET] <rcombs> use r0-r15 nobody cares about 32-bit x86
[21:40:00 CET] <omerjerk> Is there something I can work on? Kind of done with my ALS codec related work.
[21:40:14 CET] <atomnuker> learn assembly
[21:40:19 CET] <durandal_1707> omerjerk: encoder?
[21:40:52 CET] <Compn> durandal_1707 : how goes bayer rgb support ? :)
[21:40:56 CET] <Compn> r3dcode...
[21:41:03 CET] <omerjerk> durandal_1707: It's done from my side. Waiting for Thilo to review the patch.
[21:41:23 CET] <durandal_1707> Compn: bayer is on hiatus
[21:42:04 CET] <omerjerk> atomnuker: I know basic stuff. Do you have something in mind for me?
[21:42:24 CET] <durandal_1707> fun project: add gui for filtering 
[21:43:04 CET] <omerjerk> okay....
[21:43:28 CET] <atomnuker> omerjerk: how about some debugging?
[21:43:33 CET] <atomnuker> the mlp decoder has issues
[21:43:42 CET] <atomnuker> it has some sort of an overflow happening
[21:43:57 CET] <atomnuker> and that causes a pop to appear once every few seconds
[21:44:01 CET] <jamrial> and the mlp encoder is broken. too many scenarios where it's not bitexact
[21:44:21 CET] <atomnuker> erm yeah, I meant encoder, not decoder
[21:45:11 CET] <atomnuker> I haven't been able to figure out where the issue is
[21:45:48 CET] <omerjerk> okay. 
[21:46:00 CET] <omerjerk> is there a bug on the trac which I can pick up?
[21:46:05 CET] <durandal_1707> you use address sanitizer to check fo overflows at runtime
[21:46:27 CET] <omerjerk> I mean bug for exactly this issue?
[21:48:03 CET] <omerjerk> Is there a ticket for this issue on trac.ffmpeg?
[21:48:36 CET] <durandal_1707> nope
[21:48:48 CET] <omerjerk> okay. 
[21:48:59 CET] <durandal_1707> you just try encoding file
[21:49:13 CET] <omerjerk> okay.
[21:49:50 CET] <durandal_1707> no need to type okay each time:its little creppy
[21:50:25 CET] <omerjerk> ._.
[21:50:36 CET] <durandal_1707> :)
[21:51:42 CET] <jamrial> i opened a ticket about it some time ago
[21:52:39 CET] <jamrial> there, ticket 6216
[22:04:14 CET] <durandal_1707> atomnuker: why it eats last packet without producing output?
[22:04:32 CET] <atomnuker> it does?
[22:06:06 CET] <durandal_1707> compare framemd5 asetnsamples=1024 output of any stereo file encoded by that codec
[22:06:34 CET] <durandal_1707> i see in code it simply returns 1
[22:09:16 CET] <atomnuker> yeah, that's a problem
[22:09:50 CET] <atomnuker> right, erm, finders keepers so since you found it its up to you to fix it :)
[00:00:00 CET] --- Tue Nov 28 2017