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

[burek]

[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=sharing
[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).aspx
[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