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

burek burek021 at gmail.com
Fri Oct 16 02:05:03 CEST 2015


[00:00:07 CEST] <durandal_1707> and extension xma
[00:00:27 CEST] <J_Darnley> Patch welcome!
[00:00:57 CEST] <durandal_1707> installing wine on ubuntu sucks
[00:02:05 CEST] <durandal_1707> do you know what effort is to re something nontrivial?
[00:02:13 CEST] <iive> is something known about the codec?
[00:02:28 CEST] <J_Darnley> Not personally but I know it is hard.
[00:02:49 CEST] <iive> durandal_1707: it is quite an effort. and you must find the smallest codec that works
[00:03:42 CEST] <iive> i've heard that ida pro have extension decompiler that is quite good. But I haven't seen it myself.
[00:04:53 CEST] <durandal_1707> there is binary decoder which decompiles into delphi
[00:08:45 CEST] <iive> if only where was somebody who knew pascal...
[00:12:25 CEST] <iive> there....
[00:12:58 CEST] <durandal_1707> It's not problem
[00:18:51 CEST] <iive> </just kidding>
[00:26:01 CEST] <cone-538> ffmpeg 03Michael Niedermayer 07master:83fc0b9d48d1: doc/examples/muxing: Fix mixed declaration and code
[00:53:01 CEST] <nevcairiel> ubitux: this one doesnt seem to like your videotoolbox change http://fate.ffmpeg.org/report.cgi?time=20151014211751&slot=arm64-osx10.9-apple-clang
[01:04:15 CEST] <pross> durandal_1707: i care, but have no spare time
[01:05:56 CEST] <durandal_170> nice, maybe I will start it
[01:09:21 CEST] <kierank> Is this function SIMDable?
[01:09:21 CEST] <kierank> https://github.com/FFmpeg/FFmpeg/blob/87ff61b9abde99d8cdc2a4332b41f69a80eb3d56/libavfilter/drawutils.c#L410
[01:10:48 CEST] <J_Darnley> probaably
[01:11:15 CEST] <J_Darnley> no branches and basic arithmetic in the loop
[01:11:53 CEST] <kierank> might try it during the weekend]
[01:12:18 CEST] <cone-538> ffmpeg 03Carl Eugen Hoyos 07master:2c2d1624a2e7: lavf: Remove duplicated latm demuxer.
[01:15:08 CEST] <J_Darnley> why is src a value and not a pointer
[01:16:22 CEST] <kierank> dunno
[01:16:31 CEST] <kierank> quite a costly function
[01:18:53 CEST] <J_Darnley> I might take that back.
[01:19:13 CEST] <J_Darnley> it doesn't look like you load from mask in a continuous manner.
[01:20:56 CEST] <durandal_170> where is this used?
[01:21:02 CEST] <J_Darnley> Perhaps if you go one function "higher" and try SIMD where its called from.
[01:23:36 CEST] <rcombs> ooh
[01:23:39 CEST] <rcombs> is it the one I think it is
[01:23:42 CEST] Action: rcombs pulls up thing
[01:23:54 CEST] <rcombs> yup it is
[01:24:21 CEST] <Compn> didnt already have a loop option? 
[01:24:31 CEST] Action: Compn reads ml
[01:24:56 CEST] <J_Darnley> something about two different options being "loop"?
[01:25:48 CEST] <rcombs> J_Darnley: that blends an alpha-only bitmap with `src` being the color to blend
[01:26:01 CEST] <rcombs> and yes it's almost certainly quite SIMDable
[01:26:27 CEST] <J_Darnley> Then yes it is
[01:26:38 CEST] <J_Darnley> And I am surprised that the C is written like this.
[01:27:23 CEST] Action: J_Darnley runs off to his Unique Tone component
[01:28:34 CEST] <wm4> IMO libass should export such a function
[01:29:28 CEST] <durandal_170> libass have simd?
[01:29:36 CEST] <wm4> although this is probably used by other lavfi filters too
[01:29:41 CEST] <wm4> durandal_170: yes
[01:39:24 CEST] <J_Darnley> Oh I see why it mask isn't continuous
[01:39:45 CEST] <J_Darnley> the whole mask doesn't have to be the same size as the frame
[01:42:02 CEST] <J_Darnley> which does make sense for chroma submapling
[01:48:50 CEST] <J_Darnley> kierank: my suggestion would be to SIMD the loop on lines 447-452
[02:48:49 CEST] <cone-538> ffmpeg 03Christophe Gisquet 07master:96b165fae24b: dnxhd: interleave AC levels and flags
[03:25:25 CEST] <cone-538> ffmpeg 03Kyle Swanson 07master:0131636f22b4: avfilter/af_tremolo: clean up extra newlines
[05:04:18 CEST] <cone-538> ffmpeg 03Ganesh Ajjanagadde 07master:76cd82d9257b: doc/ffmpeg: use stream_loop instead of loop
[05:22:11 CEST] <rcombs> nevcairiel: are you planning to send that schannel patch?
[08:03:17 CEST] <cbsrobot> would be nice if blend_pixel supported >8bit formats
[10:03:15 CEST] <ubitux> nevcairiel: ugh. how did it work out for me
[10:03:34 CEST] <nevcairiel> seems like a weird issue, why would it not have the define at all
[10:03:37 CEST] <ubitux> i think i know what to change (move config.h above definition), but need to do some tests
[10:03:56 CEST] <ubitux> give me a moment, will fix asap
[10:03:57 CEST] <nevcairiel> ah right
[10:03:59 CEST] <nevcairiel> that would be it
[10:04:16 CEST] <ubitux> i can quick commit this but this is surprising
[10:04:54 CEST] <ubitux> oh i know why i didn't have the issue, i disabled ffmpeg for xcompile ... derp
[10:06:47 CEST] <ubitux> but that box wasn't failing build previously?
[10:06:51 CEST] <ubitux> that's surprising
[10:09:47 CEST] <nevcairiel> it last build 7 days ago
[10:10:07 CEST] <nevcairiel> maybe it actually has that function
[10:12:40 CEST] <ubitux> yeah it's weird, it's not supposed to be available
[10:12:54 CEST] <ubitux> anyway, commiting a fix, will see
[10:14:34 CEST] <cone-946> ffmpeg 03Clément BSsch 07master:9898ef8139ff: ffmpeg/videotoolbox: try to fix compilation when cross compiling ffmpeg with VT for iOS under certain configuration
[10:17:26 CEST] <__gb__> rcombs, I definitely won't go the libyami route, if you want my own opinion
[10:17:59 CEST] <rcombs> __gb__: so you'd move that functionality into lavc/lavfi?
[10:18:40 CEST] <rcombs> (or, you'd suggest doing that?)
[10:20:40 CEST] <__gb__> native support within lavc & lavfi is desired, yes
[10:20:49 CEST] <__gb__> or through a more appropriate C implementation
[10:21:03 CEST] <__gb__> clean & maintainable
[10:22:10 CEST] <rcombs> so seems everyone agrees libyami's a mess
[10:22:34 CEST] <rcombs> (I've only glanced at it briefly and& first thing I noticed was use of the Factory pattern)
[10:23:38 CEST] <__gb__> I didn't write that, and I reserve my own opinion, of course :)
[10:23:47 CEST] <rcombs> heheheheh
[10:23:49 CEST] <__gb__> again, native lavc & lavfi implementation is always preferred
[10:24:10 CEST] <__gb__> anyway, at the expense probably to add a few more vaapi helpers in there
[10:24:16 CEST] <rcombs> alright, guess I have my work cut out for me
[10:27:24 CEST] <cone-946> ffmpeg 03Clément BSsch 07master:304161851693: ffmpeg/videotoolbox: protect UTGetOSTypeFromString on both VDA and VT
[10:27:43 CEST] <ubitux> sorry for the noise, and it seems i still have to fix a few things
[10:31:02 CEST] <__gb__> BtbN, for ffmpeg/vaapi test, you can try ffvademo until ffplay & ffmpeg get updated :)
[10:32:53 CEST] <__gb__> not an advanced player, but enough for testing visually
[10:33:09 CEST] <__gb__> for testing conformance, you have FATE, or MVT
[10:34:17 CEST] <__gb__> wm4, btw, I have updated sample code in there for EGL interop if you don't want to read through xbmc
[10:34:28 CEST] <__gb__> this requires Mesa >= 11.0
[10:45:17 CEST] <cone-946> ffmpeg 03Clément BSsch 07master:f2f55bd9ca45: build/videotoolbox: add missing CoreVideo framework
[11:13:36 CEST] <durandal_1707> what's this wrapped_avframe encoder thing?
[11:35:53 CEST] <durandal_1707> are you against rawaudio demuxer?
[11:36:07 CEST] <nevcairiel> dont we already have that
[11:36:43 CEST] <nevcairiel> pcmdec is essentially raw audio
[11:37:45 CEST] <rcombs> what nevcairiel said
[11:52:12 CEST] <durandal_1707> the one that would allow to set offset and packet size
[11:54:15 CEST] <ubitux> > Maximum Response Limit: You have reached your limit of 100 survey responses. To see all 101 responses, upgrade to any pro plan. 
[11:54:17 CEST] <ubitux> oh bitch plz
[11:54:31 CEST] <ubitux> i was wondering when surveymonkey would do its asshole move
[11:55:07 CEST] <__gb__> google forms were free :)
[11:56:12 CEST] <wm4> __gb__: yeah, I've already implemented the EGL interop myself
[11:56:15 CEST] <rcombs> durandal_1707: seems like it'd be easy enough to add that to pcmdec
[11:56:50 CEST] <wm4> __gb__: your example has many code paths, but wss otherwise readable and helpful
[11:57:09 CEST] <wm4> __gb__: the only problem was that EGL_IMAGE_INTERNAL_FORMAT_EXT didn't work
[11:57:26 CEST] <__gb__> it's now gone since mesa 11 has the required functionality :)
[11:57:27 CEST] <wm4> only EGL_LINUX_DRM_FOURCC_EXT did
[11:58:09 CEST] <fritsch> __gb__: nice to see you back ... no reply from "OTC Media architect, that is responsible for driver development and features for VAAPI at Intel" concerning our simple hevc 10 bit question yet
[11:59:03 CEST] <__gb__> really? got an answer that "I am in contact with XX and following up with him directly"
[11:59:12 CEST] <__gb__> oh well
[11:59:30 CEST] <__gb__> sparsely, need to run this afternoon
[12:00:23 CEST] <durandal_1707> rcombs: its mostly for headerless adpcm
[12:02:31 CEST] <fritsch> __gb__: he never replied :-(
[12:03:16 CEST] <fritsch> but I did now
[12:03:21 CEST] <fritsch> you are on bcc as last time
[12:03:53 CEST] <nevcairiel> poor linux users
[12:04:06 CEST] <nevcairiel> dont even have the underlying architecture for shit yet
[12:04:37 CEST] <fritsch> hehe
[12:04:54 CEST] <fritsch> everybody knows besides the "OTC ... whatever" guy
[12:05:18 CEST] <fritsch> what is OTC btw.?
[12:05:32 CEST] <nevcairiel> that reminds me what I wanted to poke my haswell box and see if it exposes dxva2 vp8 or vp9
[12:05:36 CEST] <fritsch> One time coder?
[12:05:38 CEST] <nevcairiel> s/what/that/
[12:06:09 CEST] <nevcairiel> Open-Source Technology Center?
[12:06:14 CEST] <fritsch> :p
[12:06:17 CEST] <fritsch> i made a joke ...
[12:06:27 CEST] <fritsch> but you know, germans and jokes won't work out
[12:06:40 CEST] <__gb__> nevcairiel, afaik, no vp8 nor vp9 for haswell, sorry
[12:06:56 CEST] <nevcairiel> __gb__: it does it with the mediasdk though <.<
[12:07:06 CEST] <fritsch> same for linux, the vp9 driver was disabled later on for hsw after release - the hybrid driver
[12:07:22 CEST] <__gb__> vp9 hybrid is for broadwell and newer
[12:07:28 CEST] <fritsch> nevcairiel: media-sdk ... that's for those that pay money
[12:07:29 CEST] <__gb__> vp8 hybrid, I am not sure it went out :)
[12:07:36 CEST] <nevcairiel> fritsch: not on windows
[12:08:01 CEST] <wm4> always so lovely if a broken sample was generated by lavf
[12:09:46 CEST] <__gb__> technically, vp9 hybrid is doable on haswell, but I don't remember the actual requirements
[12:09:54 CEST] <__gb__> probably requires a GT3{,e}
[12:10:26 CEST] <fritsch> __gb__: so the media-sdk uses some optimized "CPU algorithms"?
[12:11:35 CEST] <fritsch> https://github.com/01org/intel-hybrid-driver/commit/d611fc867855ae8cbbdb7dc11e37c37133fe4eda <- here it was added
[12:11:40 CEST] <fritsch> but most likely removed later
[12:12:07 CEST] <nevcairiel> guess no system to test my dxva2 vp9 on then
[12:12:17 CEST] <nevcairiel> nvidia exposes it on their gtx960 but its still broken
[12:12:23 CEST] <nevcairiel> need moar drivers
[12:12:47 CEST] <fritsch> i currently run a broadwell laptop here (for work)
[12:12:53 CEST] <fritsch> so - if I should "run something"
[12:12:58 CEST] <fritsch> just tell me
[12:13:03 CEST] <__gb__> fritsch, I tried to dig a little into that, the number of EUs / threads looked insufficient, or the states were wrongly filled
[12:13:12 CEST] <__gb__> at least, on my NuC, so likely a GT2
[12:13:38 CEST] <fritsch> __gb__: btw. whom to ask now at intel if someone really has a technical question concerning vaapi?
[12:14:09 CEST] <fritsch> __gb__: is Sean V Kelley the "first level" support and should be contacted?
[12:15:01 CEST] <nevcairiel> do they have skylake NUCs yet or something like that
[12:15:06 CEST] <fritsch> nope
[12:15:11 CEST] <fritsch> braswell
[12:15:21 CEST] <fritsch> are there 3700 and 3050
[12:15:33 CEST] <nevcairiel> those are atom cores
[12:15:38 CEST] <fritsch> jep
[12:15:44 CEST] <fritsch> but should have vp9
[12:15:52 CEST] <nevcairiel> they usually also have a low-end desktop cpu NUC
[12:15:57 CEST] <nevcairiel> but maybe not skylake yet
[12:16:11 CEST] <fritsch> i did not see one of those
[12:16:16 CEST] <fritsch> there is the pentium 3700
[12:16:20 CEST] <fritsch> but that's also braswell
[12:16:35 CEST] <nevcairiel> rumors are there is one coming with  Core i5-6200U
[12:16:38 CEST] <fritsch> http://www.heise.de/preisvergleich/intel-nuc-kit-nuc5ppyh-boxnuc5ppyh-a1273287.html
[12:16:49 CEST] <nevcairiel> NUC6i5SYK/H
[12:16:51 CEST] <nevcairiel> but not yet
[12:16:52 CEST] <fritsch> yeah - i don't care basically
[12:17:01 CEST] <fritsch> as there is no 10 bit hevc support on linux
[12:17:06 CEST] <fritsch> the rest we already do
[12:17:22 CEST] <fritsch> without that 10 bit support it does not matter if you throw your media on a braswell
[12:17:38 CEST] <fritsch> as both won't be good enough for uhd live tv of the future
[12:18:03 CEST] <nevcairiel> maybe i should just replace my htpc with a skylake system
[12:18:13 CEST] <fritsch> you run windows, right?
[12:18:20 CEST] <nevcairiel> of course
[12:18:23 CEST] <fritsch> did you do some hevc 10 bit benchmarks?
[12:18:25 CEST] <nevcairiel> i wouldnt touch video on linux :p
[12:18:32 CEST] <fritsch> with skl?
[12:18:38 CEST] <nevcairiel> no, dont have any skl
[12:18:40 CEST] <fritsch> and the hybrid decoder?
[12:18:42 CEST] <fritsch> okay
[12:18:44 CEST] <nevcairiel> i can give you gtx960 benchmarks though!
[12:18:49 CEST] <fritsch> hehehe
[12:18:59 CEST] <fritsch> not sure if broadwell also does 10 bit
[12:19:03 CEST] <fritsch> with the hybrid driver
[12:19:06 CEST] <fritsch> on win
[12:19:20 CEST] <fritsch> though, perhaps one could check 8 bit performance
[12:19:30 CEST] <fritsch> to see how fast the wrapper driver does this
[12:20:31 CEST] <fritsch> dxva checker on my notebook tells: HEVC_VLD_Main10
[12:20:41 CEST] <nevcairiel> guess it does then
[12:20:58 CEST] <nevcairiel> does it list the vp9 thing by any chance as well?
[12:21:24 CEST] <fritsch> WMV9_IDCT I see here
[12:22:13 CEST] <nevcairiel> if your dxva checker is slightly old it may not show the name of the device .. the GUID starts with 463707f8
[12:22:24 CEST] <fritsch> i have:
[12:22:30 CEST] <fritsch> 442B942A
[12:22:39 CEST] <fritsch> and 8C56E
[12:22:43 CEST] <fritsch> 7688A
[12:22:48 CEST] <fritsch> A74CCA
[12:22:54 CEST] <fritsch> that it does not identify
[12:23:01 CEST] <fritsch> and 4976
[12:23:03 CEST] <fritsch> let me update
[12:23:52 CEST] <nevcairiel> {90B899EA-3A62-4705-88B3-8DF04B2744E7} is VP8 and {463707F8-A1D0-4585-876D-83AA6D60B89E} is VP9 .. but Microsoft released the spec for those just last week, so even if it would support those, it might need rather new drivers
[12:25:29 CEST] <nevcairiel> nvidia exposes the VP9 GUID on the 960, but its not working yet
[12:26:43 CEST] <fritsch> https://dl.dropboxusercontent.com/u/55728161/dxvachecker2.PNG
[12:26:47 CEST] <fritsch> nevcairiel: ^^ a screenshot
[12:27:18 CEST] <fritsch> i don't have hevc 10 bit content to test here, though - this benchmark utility is a bit "not that self explaining"
[12:28:38 CEST] <nevcairiel> yeah no vp9 in there yet, but maybe new drivers will add it
[12:29:33 CEST] <fritsch> it's a thinkpad
[12:29:41 CEST] <fritsch> no new driver available
[12:29:59 CEST] <fritsch> got to go
[12:30:05 CEST] <fritsch> exhibition continues :-)
[12:30:06 CEST] <nevcairiel> guess its one of those cases where mobile gets screwed because official intel drivers dont install?
[13:07:44 CEST] <cone-946> ffmpeg 03Ronald S. Bultje 07master:b95f241b6e63: vp9: split header into separate struct and expose in vp9.h
[13:07:45 CEST] <cone-946> ffmpeg 03Hendrik Leppkes 07master:6e719dc6bb64: vp9: expose reference frames in VP9SharedContext
[13:16:25 CEST] <__gb__> fritsch, whom? well, you already have the right contact name -- he is the technical man :)
[13:33:02 CEST] <__gb__> nevcairiel, your "some decoders" comment concerns mainly h264 which is the most used one indeed :)
[13:33:21 CEST] <nevcairiel> i actually found this with vp9
[13:33:50 CEST] <nevcairiel> my own code has set [0] for years, no idea why i didnt put that into ffmpeg_dxva2 when i wrote it
[13:34:38 CEST] <__gb__> anyway, your patch is obvious to be committed
[13:35:29 CEST] <__gb__> for h264, this generally can be fatal with b-frames, and some rare case when you need to swap ref lists
[13:36:11 CEST] <__gb__> probably something we should document maybe for hwaccel users
[14:08:23 CEST] <nevcairiel> apparently all theses cases have been fixed in those encoders that use hwaccel
[14:08:31 CEST] <nevcairiel> just vp9 did it because it didnt hwaccel before
[14:10:16 CEST] <cone-946> ffmpeg 03Anssi Hannula 07master:fd74d45d5158: avformat/hls: fix segment selection regression on track changes of live streams
[14:10:17 CEST] <cone-946> ffmpeg 03Anssi Hannula 07master:909907948846: avformat/hls: add support for EXT-X-MAP
[14:12:36 CEST] <nevcairiel> s/encoders/decoders/
[14:27:58 CEST] <cone-946> ffmpeg 03Anssi Hannula 07release/2.8:d51ddd45b211: avformat/hls: fix segment selection regression on track changes of live streams
[14:27:59 CEST] <cone-946> ffmpeg 03Anssi Hannula 07release/2.8:68a6178ef05a: avformat/hls: add support for EXT-X-MAP
[14:53:11 CEST] <BBB> nevcairiel: does that mean you got hardware working?
[14:53:24 CEST] <nevcairiel> no
[14:55:05 CEST] <nevcairiel> but i fixed more problems!
[14:57:50 CEST] <nevcairiel> now it actually tries to decode all them frames
[14:57:52 CEST] <nevcairiel> even if it fails
[15:00:04 CEST] <BBB> I guess this is what working in the dark feels like
[15:00:07 CEST] <BBB> nothing works
[15:00:11 CEST] <BBB> let me fix something random"
[15:00:15 CEST] <BBB> nothing still works!"
[15:01:00 CEST] <cone-946> ffmpeg 03Anssi Hannula 07release/2.7:e69d8fc619d2: avformat/hls: fix segment selection regression on track changes of live streams
[15:01:02 CEST] <cone-946> ffmpeg 03Anssi Hannula 07release/2.7:1f25a3ddb83d: avformat/hls: add support for EXT-X-MAP
[15:15:26 CEST] <TyrfingMjolnir> Anyone working on atmos?
[15:16:48 CEST] <BBB> whats atmos?
[15:18:29 CEST] <TyrfingMjolnir> 64 channel sound
[15:18:32 CEST] <TyrfingMjolnir> Dolby atmos
[15:20:39 CEST] <TyrfingMjolnir> 9.2
[15:21:11 CEST] <JEEB> Yet Another Dolby DTS Extension?
[15:21:23 CEST] <JEEB> noticed it on a blu-ray disc's packaging a couple of days ago
[15:21:32 CEST] <J_Darnley> 64?
[15:21:44 CEST] <J_Darnley> What does anyone need with 64 channels?
[15:22:18 CEST] <J_Darnley> I'm not picturing people sitting inside a bucky ball of speakers
[15:22:24 CEST] <J_Darnley> s/not/now
[15:22:34 CEST] <phh> it's meant to compute more realistic sounds with any speakers configuration
[15:24:19 CEST] <TyrfingMjolnir> It's 9.2 but 64 objects
[15:24:56 CEST] <TyrfingMjolnir> Whatever that means
[15:25:02 CEST] <TyrfingMjolnir> Where is the surround code in ffmpeg?
[15:25:25 CEST] <TyrfingMjolnir> http://www.dolby.com/us/en/professional/cinema/products/dolby-atmos-next-generation-audio-for-cinema-white-paper.pdf
[15:25:48 CEST] <TyrfingMjolnir> The first-generation Dolby Atmos Cinema Processor CP850 can support up to 64 outputs. Although 61.3 channels may seem excessive when compared with typical existing configurations, currently available multichannel amplifiers can individually amplify a large number of speakers (for example, 11 surrounds on each side wall in a large theatre, each amplified on its own channel).
[15:28:42 CEST] <kierank> TyrfingMjolnir: how are you going to get the spec for atmos?
[15:28:53 CEST] <kierank> the samples are already out
[15:29:04 CEST] <kierank> but you need a hardware receiver to decode them
[15:29:18 CEST] <TyrfingMjolnir> It's a chip
[15:29:22 CEST] <TyrfingMjolnir> I can buy it, no?
[15:29:38 CEST] <TyrfingMjolnir> And put it in a JTAG or micro scope and see what is there.
[15:31:33 CEST] <TyrfingMjolnir> Or maybe this one is simpler to reverse? http://www.barco.com/en/Auro11-1
[15:31:35 CEST] <kierank> easier to reverse engineer the firmware
[15:31:36 CEST] <kierank> yes
[15:31:50 CEST] <kierank> many of them have atmos ifrmware updates
[15:32:00 CEST] <TyrfingMjolnir> Interesting
[15:32:09 CEST] <TyrfingMjolnir> Where are these firmware updates?
[15:48:23 CEST] <nevcairiel> TyrfingMjolnir: dont mix up Dolby Atmos Cinema with the Atmos used for consumer streams on Blu-rays
[15:48:31 CEST] <nevcairiel> Blu-rays only provide 7.1.4, not 64 channels
[15:48:43 CEST] <TyrfingMjolnir> It's a light version
[15:50:24 CEST] <TyrfingMjolnir> CP-750 is still a bit expensive: http://www.ebay.com/sch/i.html?_odkw=Dolby+Atmos+Cinema+Processor+CP850&_osacat=0&_from=R40&_trksid=p2045573.m570.l1313.TR0.TRC0.H0.XDolby+Atmos+Cinema+Processor+CP-850.TRS0&_nkw=Dolby+Atmos+Cinema+Processor+CP-850&_sacat=0
[16:01:29 CEST] <cone-946> ffmpeg 03wang-bin 07master:0861862b897a: winrt: multithreading support
[16:15:06 CEST] <j-b> How hard is it to have proper author name?
[16:16:20 CEST] <wm4> hard
[16:17:04 CEST] <RiCON> he does seem to use a proper name in other projects, so it's not like you, wm4 
[16:18:44 CEST] <BBB> wm4: whats your objection to using a realname?
[16:18:49 CEST] <BBB> it is kind of weird
[16:38:12 CEST] <JEEB> TyrfingMjolnir: JEEB: https://mrcn.st/t/of5.DA83XLA_010203040506.03111 that's the DSP firmware blob, no strings. tell him to have fun :D
[16:38:30 CEST] <JEEB> (that's for one of the onkyo things)
[16:43:13 CEST] <TyrfingMjolnir> author name?
[16:43:23 CEST] <TyrfingMjolnir> Like J R R Tolkien?
[16:47:16 CEST] <TyrfingMjolnir> JEEB: 59372215 seems populer
[16:47:19 CEST] <TyrfingMjolnir> *popular
[18:29:49 CEST] <durandal_1707> kierank: how long you fuzzed ffv1?
[18:29:53 CEST] <kierank> 30 seconds
[18:30:02 CEST] <kierank> lots of crashes
[18:30:03 CEST] <durandal_1707> lol
[18:30:18 CEST] <durandal_1707> what sample?
[18:30:49 CEST] <kierank> https://trac.videolan.org/vlc/ticket/9490
[18:30:54 CEST] <kierank> first one I found googling "ffv1 sample"
[18:33:09 CEST] <durandal_1707> ahh, I tested single thread version 3 and small sample
[19:59:37 CEST] <cone-946> ffmpeg 03Derek Buitenhuis 07master:1a29804558c1: aac: Make codec init run under ff_thread_once
[20:16:35 CEST] <cone-946> ffmpeg 03wm4 07master:be583c6fd3a6: avcodec/h264: remove redundant and bogus get_format call
[20:16:36 CEST] <cone-946> ffmpeg 03wm4 07master:cdf4a13f8615: swresample: slightly nicer debug output for auto matrix
[20:16:47 CEST] <wm4> oh shit
[20:17:01 CEST] <wm4> michaelni_: I accidentally pushed that other patch
[20:17:10 CEST] <wm4> please someone force push it away
[20:18:11 CEST] <wm4> (or revert it, whatever is more appropriate)
[20:19:09 CEST] <BtbN> Can't you push a revert yourself?
[20:19:17 CEST] <wm4> sure
[20:19:39 CEST] <wm4> I guess if someone can force push it away, it could remove such a revert too
[20:20:05 CEST] <BtbN> I don't think force pushing to master is appropriate
[20:20:16 CEST] <cone-946> ffmpeg 03wm4 07master:17fe18d21ad9: Revert "avcodec/h264: remove redundant and bogus get_format call"
[20:20:39 CEST] <wm4> for a short time after it was pushed, it should be ok
[20:21:09 CEST] <kierank> so what other decoders should I fuzz
[20:23:16 CEST] <ubitux> kierank: subtitles
[20:24:30 CEST] <ubitux> like, playing with the ones in fate-samples/sub
[20:25:09 CEST] <ubitux> (make sure you specify the input charset for some of them or it won't be processed)
[20:25:42 CEST] <kierank> how do I output the subtitles somewhere
[20:25:45 CEST] <kierank> ./ffmpeg_g -i example.srt -f null - doesn't work
[20:25:54 CEST] <kierank> "Output file #0 does not contain any stream"
[20:25:55 CEST] <ubitux> try -f ass -
[20:26:26 CEST] <ubitux> make fate-subtitles V=1 for inspiration
[20:26:28 CEST] <jamrial> kierank: maybe the texture ones merged from libav
[20:32:52 CEST] <cone-946> ffmpeg 03Vicente Olivert Riera 07master:50366b429508: mips: disable all features in configure if no cpu is matched
[20:45:24 CEST] <Daemon404> wow.
[21:03:50 CEST] <wm4> 512x33056
[21:03:51 CEST] <wm4> nice
[21:04:26 CEST] <kierank> I uploaded it to youtube as well to troll thierry of course
[21:04:42 CEST] <nevcairiel> lol
[21:05:06 CEST] <wm4> can't confirm a memory leak here
[21:05:13 CEST] <JEEB> lol
[21:05:44 CEST] <kierank> ./ffmpeg_g -i out9.webm -f null -
[21:06:23 CEST] <kierank> my server locks up for a bit
[21:06:55 CEST] <Daemon404> are you sure its not just a large alloc
[21:07:04 CEST] <wm4> hm, with ffmpeg it gets killed
[21:07:07 CEST] <wm4> doesn't happen with mpv
[21:07:16 CEST] <kierank> Daemon404: 10GB of memory here
[21:07:18 CEST] <Daemon404> inb4 filter buffering
[21:07:22 CEST] <Daemon404> due to timestamps
[21:07:23 CEST] <wm4> maybe it's the encoder or so... or filters
[21:12:40 CEST] <BBB> is that a valid file?
[21:12:45 CEST] <kierank> no, fuzzed
[21:12:47 CEST] <BBB> 33056& is a little much
[21:12:49 CEST] <BBB> ok
[21:12:53 CEST] <BBB> what do you want me to do?
[21:13:19 CEST] <BBB> does it not return an error or so? so theres unchecked malocs in there?
[21:13:21 CEST] <kierank> I need to find a way of running ffmpeg and seeing what allocates the memory (infinitely?)
[21:13:32 CEST] <ubitux> try massif
[21:13:51 CEST] <kierank> I ran valgrind and it was using 10GB of RAM
[21:14:34 CEST] <kierank> trying massif
[21:14:44 CEST] <BBB> kierank: does it also lock up with -threads 1?
[21:14:48 CEST] <BBB> or only with multiple threads?
[21:14:59 CEST] <kierank> dunno, currently locked up avdev :)
[21:15:08 CEST] <Daemon404> you should really disable swa
[21:15:09 CEST] <Daemon404> p
[21:15:36 CEST] <kierank> let's see if youtube processed it
[21:15:54 CEST] <wm4> or just restrict max. memory alloc
[21:15:55 CEST] <Daemon404> youtube likely doesnt use ffvp9
[21:16:02 CEST] <Daemon404> their ffmpeg is a weird old fork
[21:16:05 CEST] <BBB> well find out soon enough
[21:16:05 CEST] <Daemon404> isnt it?
[21:16:08 CEST] <nevcairiel> mm braswell with recent drivers seems to export vp9 dxva2 support as well
[21:16:12 CEST] <nevcairiel> time to buy one
[21:16:24 CEST] <Daemon404> s/buy/expense/?
[21:16:39 CEST] <nevcairiel> well yeah i'll just charge it to work
[21:16:44 CEST] <kierank> paste.ubuntu.com/12793052
[21:16:45 CEST] <nevcairiel> its only like 180¬
[21:16:46 CEST] <BBB> where do you work
[21:16:53 CEST] <fritsch> nevcairiel: get the 3700
[21:16:57 CEST] <nevcairiel> i did
[21:17:10 CEST] <nevcairiel> NUC5PPYK or what its called
[21:17:12 CEST] <kierank> BBB: ok with threads 1
[21:17:16 CEST] <fritsch> yeah BtbN has the same
[21:17:47 CEST] <fritsch> curious on your results with the hevc-10 bit gpu assisted decoding
[21:17:59 CEST] <nevcairiel> it doesnt seem to offer it
[21:18:05 CEST] <nevcairiel> probably GPU too weak
[21:18:30 CEST] <nevcairiel> but i'll see when i get it
[21:18:52 CEST] <BBB> kierank: hm so it never releases buffers?
[21:18:55 CEST] <BBB> thats so weird
[21:19:00 CEST] <BtbN> you need the hybrid thing for vp9 on bras
[21:19:13 CEST] <nevcairiel> its windows, it either comes with everything or nothing =p
[21:19:28 CEST] <BBB> kierank: Ill have a look
[22:02:38 CEST] <kurosu> does youtube support vp9 *input* ? :D
[22:02:53 CEST] <cone-946> ffmpeg 03Michael Niedermayer 07master:c980c5e54dfe: avcodec/jpeg2000dec: Clear properties in jpeg2000_dec_cleanup() too
[22:03:20 CEST] <kurosu> (I suppose it doesn't, even with a very long pole, support hevc)
[22:03:47 CEST] <kierank> you are right
[22:05:19 CEST] <kurosu> in other news, another notable company joined hevc advance - it doesn't look like it will end well
[22:08:47 CEST] <TD-Linux> yeah I've uploaded vp9 to youtube, it works
[22:09:10 CEST] <TD-Linux> kurosu, it's marginally better than the company being in no pool.
[23:51:35 CEST] <Justin`> Any patch for CVE-2015-6761 yet on 2.8.1?
[23:57:49 CEST] <nevcairiel> you act as if we're supposed to know what that is
[23:58:03 CEST] <nevcairiel> i dont see it mentioned in any report on trac
[23:58:45 CEST] <Justin`> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-6761 nevcairiel 
[00:00:00 CEST] --- Fri Oct 16 2015


More information about the Ffmpeg-devel-irc mailing list