[00:02:23 CEST] <cone-764> ffmpeg 03Burt P 07master:d574e22659bd: af_hdcd: Process stereo channels together, fix #5727 [00:02:24 CEST] <cone-764> ffmpeg 03Burt P 07master:bea17a3d5705: af_hdcd: Warn if there is any resampling or format conversion in the link chain [00:13:54 CEST] <cone-764> ffmpeg 03Anton Khirnov 07master:996f13413b04: h264: fix warnings in fill_filter_caches_inter() [00:13:55 CEST] <cone-764> ffmpeg 03James Almer 07master:01f0598b18e9: Merge commit '996f13413b0415097e2a184d161462ffb3ceb647' [00:15:31 CEST] <jamrial> ubitux: there, reduced the h264 queue a bit :p [02:09:18 CEST] <sanmarcos> anybody have experiecne with Openh264 here? [02:35:57 CEST] <Compn> there is a patch to include an openh264 lib in ffmpeg on the ml [02:36:13 CEST] <Compn> sanmarcos : is that what you are asking about ? [02:55:42 CEST] <RiCON> openh264 can be included in ffmpeg already [02:55:50 CEST] <RiCON> the problem was including the git version [03:03:18 CEST] <rcombs> atomnuker: how's AAC perf work going? [10:15:36 CEST] <atomnuker> rcombs: 90% done for the past 3 months :( [10:15:50 CEST] <rcombs> what's holding back that last 10%? [12:03:59 CEST] <Bitterblue> Does the timestamp of a blank subtitle (num_rects=0) in a PGS stream signify the last point where the previous (valid) subtitle should be displayed, or the first point where it shouldn't be? [12:18:01 CEST] <michaelni> Bitterblue, this is a good question, iam not sure this was considered before but to me the first point of non display seems more logic to me [12:20:01 CEST] <Bitterblue> Indeed. [12:20:39 CEST] <Bitterblue> On the other hand, Suprip thinks it's the former. [12:26:58 CEST] <Bitterblue> There is no public specification, is there? [12:32:12 CEST] <robUx4> nevcairiel: you might want to check this https://mailman.videolan.org/pipermail/vlc-commits/2016-August/036684.html [12:32:41 CEST] <robUx4> it's code borrowed for ffmpeg_dxva2 [12:33:16 CEST] <robUx4> I have a HEVC 4K file that would trigger a crash without this [12:33:39 CEST] <robUx4> and it crashed at the first BeginFrame() call [12:35:35 CEST] <robUx4> I noticed it by increasing the number of threads used (I know, it's bad) which in turn increases the number of buffers allocated [12:36:17 CEST] <robUx4> there was a limit where the CreateSurface would fail with OutfMemory [12:36:44 CEST] <robUx4> but with -1 that amount the CreateSurface works but BeginFrame crashes [12:37:18 CEST] <robUx4> so I assume it's the internal +1 of CreateSurface that is actually meant to be internal [12:39:55 CEST] <robUx4> if you want the file https://drive.google.com/file/d/0B-WXvZryGokkX3hVaDdMMlhHcFE/view?usp=sharin... [12:40:11 CEST] <robUx4> (I had to remux the .ts to .mkv so it actually works in VLC) [12:40:37 CEST] <nevcairiel> the method is clearly documented as creating one front buffer and N backbuffers, i can only assume they do something else quirky [12:40:56 CEST] <nevcairiel> their code is entirely unrelated to ffmpeg_dxva2.c [12:41:42 CEST] <nevcairiel> also the rar is password protected [12:43:42 CEST] <robUx4> "hevc10b" [12:46:42 CEST] <nevcairiel> not sure where the notion comes from that its an "internal thing", the msdn docs are quite clear on how the function works [12:46:45 CEST] <robUx4> it might try to allocate an extra buffer internally, but there's no memory available [12:47:09 CEST] <robUx4> (there's plenty but it may be a per process/decoder limit) [12:47:57 CEST] <robUx4> at least that's the way I managed to get rid of the crash [12:48:20 CEST] <robUx4> by not using the decoder if the allocation would fail with the +1 [12:49:15 CEST] <robUx4> https://msdn.microsoft.com/en-us/library/windows/desktop/ms696227(v=vs.85).a... [12:49:39 CEST] <robUx4> I'm not sure I understand the caller is supposed to provide N rather than N - 1 [12:50:18 CEST] <nevcairiel> all the docs say is that it creates "BackBuffers + 1" surfaces, so you can translate that in code anyway you like [12:50:47 CEST] <robUx4> it's ambiguous [12:51:20 CEST] <robUx4> so I prefer the call that doesn't crash in tricky conditions [12:51:25 CEST] <nevcairiel> maybe due to an error condition you accidentally called it with sys->surface_count = 0, which resulted in passing -1 to the function? [12:51:47 CEST] <robUx4> no it's 24 that fails [12:52:13 CEST] <robUx4> we were passing 23 and it would crash on BeginFrame() [12:52:16 CEST] <nevcairiel> anyway i've never had any issue reports of such crashes [12:52:39 CEST] <robUx4> how many people use HEVC 4K with dvxa2 ? [12:53:06 CEST] <robUx4> also, they might use it the way you say it should: no threading [12:53:20 CEST] <robUx4> so they'd never reach 24 [12:53:30 CEST] <robUx4> with single thread it would be 20 [12:53:43 CEST] <cone-228> ffmpeg 03Petru Rares Sincraian 07master:7be021d9495b: fate: add test for tremolo filter [12:53:44 CEST] <cone-228> ffmpeg 03Lucas Cooper 07master:3d7ea1d39e09: doc/filters: Add stats_version documentation to PSNR filter [12:54:10 CEST] <robUx4> only with my local VLC build where I force multithread (to test issues) has the issue [12:54:58 CEST] <nevcairiel> i actually use 24 in my own software for performance improvements, never had issues [12:55:14 CEST] <robUx4> you pass 24 or 23 ? [12:55:20 CEST] <nevcairiel> 23 of course [12:55:22 CEST] <nevcairiel> 24 surfaces [12:55:38 CEST] <robUx4> maybe it depends on the hardware/driver [12:56:13 CEST] <robUx4> I don't know why it says OutOfMemory with 24, the 950 GTX card has 2 GB of RAM [12:56:34 CEST] <nevcairiel> this has been tested on a 2gb 960 at least and not crashed there [12:56:42 CEST] <robUx4> note: I allocate P010 surfaces, not NV12 [12:58:26 CEST] <robUx4> also do you mark the front buffer somewhere or tell DXVA2 which buffer is the front ? [12:58:41 CEST] <nevcairiel> its really all the same buffer type [12:58:47 CEST] <robUx4> or keep one buffer from the array for the libavcodec code ? [12:58:50 CEST] <nevcairiel> the allocation function just splits that somehow [12:59:23 CEST] <robUx4> otherwise if you pass N-1 there's a buffer that's allocated but noone knows about it [12:59:33 CEST] <nevcairiel> it gets passed into the output surface array [12:59:53 CEST] <nevcairiel> thats why the docs say it needs to be N+1 in size [13:02:18 CEST] <robUx4> the "output surface array" is in the DXVA API ? [13:02:27 CEST] <nevcairiel> from CreateSurface [13:02:46 CEST] <nevcairiel> you pass it an array it writes the surfaces into, it writes N+1 surfaces into this array [13:03:02 CEST] <nevcairiel> The address of an array of IDirect3DSurface9 pointers allocated by the caller. The size of the array must be 1 + BackBuffers (enough for the back buffers plus one front buffer). [13:10:20 CEST] <robUx4> indeed if I call CreateSurface() with 1, it fills 2 surfaces in the array [13:13:09 CEST] <nevcairiel> hence where the -1 came from [13:13:32 CEST] <nevcairiel> if yo uwant 2 surfaces, pass it a 1 [13:14:24 CEST] <nevcairiel> why it crashes for you i cannot answer, maybe its related to the multithreading on other levels and not just the surface count [13:17:04 CEST] <robUx4> no, I verified with and without mulithreading it's the same thread that does the BeginFrame call, nothing else is called before [13:17:36 CEST] <robUx4> that's why I found it odd that it would know how many threads are used when in fact only 1 is used [13:31:55 CEST] <robUx4> nevcairiel: different workaround https://patches.videolan.org/patch/14186/ [13:32:55 CEST] <nevcairiel> if anything that sounds like an issue in the driver not handling an oom condition properly somewhere [13:33:04 CEST] <nevcairiel> so you just test for some extra free memory [13:34:03 CEST] <robUx4> yes, it's a "workaround" as I know it's likely to crash later [13:34:59 CEST] <robUx4> a crash on BeginFrame() sounds like a bug in the driver anyway [13:39:39 CEST] <robUx4> that's NVIDIA and on Intel I get a crash on another API call... [16:22:57 CEST] <cone-228> ffmpeg 03Carl Eugen Hoyos 07master:8ee113afa138: lavf/rmdec: Do not return EIO on EOF. [16:45:23 CEST] <cone-228> ffmpeg 03Timothy Gu 07master:fbe22355b7d4: build: Make API documentation depend on config.mak [16:51:04 CEST] <cone-228> ffmpeg 03Timothy Gu 07master:19d7098c9e7b: avutil: Group hash functions separately in Doxygen [16:51:05 CEST] <cone-228> ffmpeg 03Timothy Gu 07master:0a7a4e33f303: avutil: Add detailed Doxygen description to a few hashes [16:51:06 CEST] <cone-228> ffmpeg 03Timothy Gu 07master:39211cb9aab3: murmur3: Add Doxygen documentation [17:08:48 CEST] <cone-228> ffmpeg 03Carl Eugen Hoyos 07master:5aede0512021: lavu/hwcontext_vaapi: Fix compilation if VA_FOURCC_ABGR is not defined. [18:01:25 CEST] <cone-228> ffmpeg 03Timothy Gu 07master:1fcf24321625: mathematics: Make function prototypes identical to definitions [18:41:23 CEST] <cone-228> ffmpeg 03Paul B Mahol 07master:82b84c71b009: avcodec/alacenc: allocate bigger packets [19:41:22 CEST] <BtbN> Best feature of patchwork: Being able to download a patch. Getting a patch out of my mails was so annoying. [19:44:08 CEST] <bp0> indeed [19:44:16 CEST] <JEEB> aye [19:44:38 CEST] <JEEB> are they curl'able btw? I hadn't tried that out yet [19:44:43 CEST] <bp0> yes [19:45:08 CEST] <bp0> both mbox and raw [19:45:15 CEST] <JEEB> najs [19:46:58 CEST] <bp0> 2nd best feature (imo) is the message id is right there at the top for git send-email --in-reply-to [19:47:20 CEST] <JEEB> I think the mail archives also had that? [19:47:49 CEST] <BtbN> Is there a problem with super long passwords with patchwork? [19:48:04 CEST] <BtbN> registered with a 32 character one, and can't login with it now. [19:49:04 CEST] <bp0> I used a very long one, without problem [19:50:22 CEST] <bp0> JEEB, if it did, I never knew it [19:51:20 CEST] <BtbN> guess something went wrong with my Password Manager then. Resetting it to the same exact password worked fine. [20:18:58 CEST] <durandal_170> j-b: you give money for doing new decoders in lavc? [20:22:04 CEST] <cone-228> ffmpeg 03LoRd_MuldeR 07master:8ab200fb8ade: avfilter/af_dynaudnorm: improve pre-filling code [20:26:13 CEST] <cone-228> ffmpeg 03Michael Niedermayer 07master:35e7fc60301e: avformat/tee: Factor parse_slave_options() out [21:16:32 CEST] <cone-228> ffmpeg 03James Almer 07master:7a9a8afc8253: avcodec/ttaenc: split off hybrid filter processing as ttaencdsp [21:16:33 CEST] <cone-228> ffmpeg 03James Almer 07master:efc9d5c4bc40: x86/ttaenc: add ff_ttaenc_filter_process_{ssse3,sse4} [22:01:59 CEST] <cone-228> ffmpeg 03Patrick Felt 07master:5469293758c9: cosmetics: Correct comments in decklink_dec [22:22:50 CEST] <BtbN> Anyone happens to have an idea about what youtube is doing with its video processing? I uploaded a bunch of videos recently, all from the exact same source, just cut. Some of them are 1080p60 now, others 1080p50. The source was at a consistent 60 fps. [22:37:19 CEST] <Compn> BtbN : what codec ? [22:37:34 CEST] <Compn> what tool did you use to cut them? [22:37:39 CEST] <Compn> let me guess... prores and fcp ? [22:40:33 CEST] <Timothy_Gu> 13:37 < Compn> BtbN : what codec ? [22:40:34 CEST] <Timothy_Gu> 13:37 < Compn> what tool did you use to cut them? [22:40:34 CEST] <Timothy_Gu> 13:37 < Compn> let me guess... prores and fcp ? [22:41:30 CEST] <Compn> thanks Timothy_Gu, you are good people. [22:45:06 CEST] <Timothy_Gu> welcome [23:25:57 CEST] <cone-228> ffmpeg 03Carl Eugen Hoyos 07release/3.1:9a345b235fbd: lavu/hwcontext_vaapi: Fix compilation if VA_FOURCC_ABGR is not defined. [00:00:00 CEST] --- Wed Aug 3 2016