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

[burek]

[00:08:13 CEST] <Guest78083> I see "Reading option '-newoption' ... matched as AVOption 'newoption' with argument 'new'." in the debug logging but the demuxer still doesn't get this "new" value. weird.
[00:26:07 CEST] <cone-725> ffmpeg 03Michael Niedermayer 07master:5620ed355716: avcodec/hevc: Remove skipped_bytes_nal, simplify code
[01:16:55 CEST] <cone-725> ffmpeg 03Michael Niedermayer 07master:bcc6c7bb65f3: avcodec/hevc: Move skipped_bytes_pos_size_nal into HAVCNAL
[01:16:56 CEST] <cone-725> ffmpeg 03Michael Niedermayer 07master:ad92410d900b: avcodec/hevc: Move skipped_bytes_pos_nal to HEVCNAL, simplify code
[01:16:57 CEST] <cone-725> ffmpeg 03Michael Niedermayer 07master:99558270ed1e: avcodec/hevc: Simplify skipped_bytes_pos code further
[01:24:10 CEST] <jamrial> philipl: the recent hevc stuff merged from libav broke vdpau_hevc
[01:28:16 CEST] <nevcairiel> i wonder if dxva broke as well then
[01:37:44 CEST] <jamrial> nevcairiel: yeah, it did
[01:39:29 CEST] <jamrial> your mingw clients are fine since they use mingw-w64 v4, so no hevc dxva2. the msvc clients and any toolchain using mingw-w64 trunk did however break
[01:49:32 CEST] <nevcairiel> Where did sps move to anyway
[01:49:53 CEST] <jamrial> HEVCParamSets
[01:51:37 CEST] <jamrial> so instead of being (HEVCContext*)ctx->sps it's now  (HEVCContext*)ctx->ps.sps
[01:52:17 CEST] <jamrial> making that change seems to fix dxva2 hevc, but i can't test it beyond seeing it compile, so ymmv
[02:15:51 CEST] <cone-725> ffmpeg 03Anton Khirnov 07master:650060dfb665: hevc_parser: parse and export some stream parameters
[02:15:52 CEST] <cone-725> ffmpeg 03Michael Niedermayer 07master:9e810a98a263: Merge commit '650060dfb665552442ec11b456660e3e9a9d9016'
[02:15:53 CEST] <cone-725> ffmpeg 03Michael Niedermayer 07master:4496ccc72468: avcodec/hevc_parser: Reenable the old parser under ADVANCED_PARSER define
[02:39:11 CEST] <cone-725> ffmpeg 03Ronald S. Bultje 07master:a1f48480497b: ssim: refactor a weird double loop.
[02:51:51 CEST] <cone-725> ffmpeg 03Ronald S. Bultje 07master:03931ecf7171: vf_ssim: remove another obscure double loop.
[02:51:52 CEST] <cone-725> ffmpeg 03Michael Niedermayer 07master:d6ff68ad853c: Factor duplicated ff_fast_malloc() out into mem_internal.h
[03:36:00 CEST] <cone-725> ffmpeg 03Michael Niedermayer 07master:7c944b0a3670: tests/checkasm/x86/Makefile: Use ASMSTRIPFLAGS for asm
[03:52:01 CEST] <cone-725> ffmpeg 03Michael Niedermayer 07master:10d7d0880cd8: avcodec/utils: Check that the sample rate is not negative when opening an encoder
[04:42:27 CEST] <philipl> jamrial: awesome.
[04:42:58 CEST] <jamrial> check my dxva2 patch. should be easy to fix
[04:43:29 CEST] <philipl> Yeah, as long as it's just syntax and not semantics.
[04:56:44 CEST] <philipl> Seems fine after the fix. Thanks.
[04:57:08 CEST] <cone-725> ffmpeg 03Philip Langdale 07master:b11c3fce3890: avcodec/vdpau_hevc: unbreak compilation after sps/pps changes
[04:58:15 CEST] <philipl> After looking at dxva patch, that code should definitely assign the sps and pps to local variables up front. :-)
[04:58:39 CEST] <jamrial> probably
[04:58:48 CEST] <jamrial> will not make the patch any smaller, though :p
[04:59:00 CEST] <jamrial> just future ones in case something like this happens again
[05:02:14 CEST] <philipl> Yeah
[05:07:29 CEST] <cone-725> ffmpeg 03James Almer 07master:1aab5d8ab1e2: avcodec/dxva2_hevc: unbreak compilation after recent sps/pps changes
[10:48:26 CEST] <j-b> 'morning
[10:57:32 CEST] <Leo1> afternoon
[12:22:51 CEST] <AstralStorm> hello; is libstagefright supported in ffmpeg for mp3 and aac handling?
[12:23:05 CEST] <AstralStorm> I see it is for h264
[12:24:33 CEST] <J_Darnley> it does not appear to be according to ./configure --list-decoders | grep stage
[12:25:09 CEST] <AstralStorm> hmmh, so maybe I'll add that thing - it might work
[12:25:30 CEST] <Leo1>   /quit
[12:26:39 CEST] <J_Darnley> Wow, I am surprised that we have 6 "different" mp3 decoders already
[12:46:49 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:b183fb4767f2: avformat: Add ff_configure_buffers_for_index()
[12:46:49 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:488cc0519242: avformat/mov: Use ff_configure_buffers_for_index()
[13:27:34 CEST] <Compn> J_Darnley : nice to have int-only decoders for embedded devices :P
[13:47:03 CEST] <cone-613> ffmpeg 03Zhang Rui 07master:f5c281daa8ae: configure: clean whitespace with [:space:]
[14:20:53 CEST] <BtbN> What the hell is this mail on the ml oO
[14:21:03 CEST] <BtbN> vlc0.8.6i(stable version), ffmpeg0.4.8
[14:21:04 CEST] <BtbN> oO
[14:21:37 CEST] <nevcairiel> old software is old
[14:21:51 CEST] <nevcairiel> china is just a bit behind on the software front
[14:21:54 CEST] Action: nevcairiel ducks
[14:23:19 CEST] <JEEBsv> lol
[14:23:23 CEST] <JEEBsv> that *is* old
[14:23:45 CEST] <JEEBsv> I mean, I did use that VLC version until the official builds got fixed regarding x264 miscompilation in the 0.9.x times
[14:23:48 CEST] <JEEBsv> but that was years ago
[14:25:12 CEST] <BtbN> vlc is currently failing hard on rtmp
[14:25:18 CEST] <BtbN> even though it's using lavf
[14:25:21 CEST] <BtbN> and ffplay works fine
[14:25:27 CEST] <BtbN> no idea what is going on there
[14:25:38 CEST] <BtbN> it just buffers forever
[14:25:54 CEST] <nevcairiel> i added rtmp support using lavf some time ago to my software, but reproducing problems from users on streams not always available to me is just annoying
[14:26:13 CEST] <BtbN> The stream is a bit annoying, as the source has a 30 second keyframe interval
[14:26:20 CEST] <BtbN> So joining it might take a while
[14:26:39 CEST] <BtbN> But so far every player managed to play it, except for vlc
[14:26:41 CEST] <D404|Ghetto> that's quite a logn startup time
[14:26:50 CEST] <D404|Ghetto> unelss it has PRI
[14:26:51 CEST] <D404|Ghetto> PIR*
[14:26:55 CEST] <BtbN> Nope
[14:27:25 CEST] <BtbN> The source is an RPi with a USB Webcam. It has no resources to re-encode with a lower gopsize.
[14:27:33 CEST] <BtbN> So there isn't much i can do
[14:27:53 CEST] <D404|Ghetto> lol rpi
[14:27:55 CEST] <D404|Ghetto> fuck it
[14:28:10 CEST] <wm4> indeed
[14:28:59 CEST] <kierank> lool 30 seconds
[14:37:54 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:b51366125100: avformat/utils: Skip ff_configure_buffers_for_index() for local files
[15:01:39 CEST] <bove>  I'm trying to decode a raw format with a fixed header size (2048 bytes) for each frame. I'm already skipping the header using skip_initial_bytes, but I can't seem to skip the packet headers. Any tips on existing demuxer that either match this pattern or can be easily tweaked to do so?
[15:09:32 CEST] <J_Darnley> yuv4mpeg
[15:09:39 CEST] <J_Darnley> sounds similar
[15:13:17 CEST] <bove> J_Darnley: this is an uncompressed stream btw
[15:13:48 CEST] <J_Darnley> and y4m, despite the name, is uncompressed
[15:15:00 CEST] <J_Darnley> As I recall it has a global header which provides format information and a frame header too (for some reason)
[15:15:21 CEST] <nevcairiel> the frame header is for syncing
[15:15:39 CEST] <J_Darnley> You probably can't make it read your format without altering the source code but it is somewhere to start
[15:15:40 CEST] <nevcairiel> not necessarily required, but not like 6 bytes for an uncompressed frame make any difference
[15:15:57 CEST] <J_Darnley> Ah, well I guess that makes sense
[15:22:53 CEST] <bove> Trying -f yuv4mpegpipe now, but I get permission denied. Should I be able to run it on regular files?
[15:26:12 CEST] <D404|Ghetto> ubitux: ping
[15:26:18 CEST] <D404|Ghetto> or anyone who understands lavfi madness
[15:26:43 CEST] <ubitux> what can i do for you young fellow?
[15:27:22 CEST] <D404|Ghetto> im trying to figure out how to do something incredibly simple (which is one line in avs or vs, ~4-10 in C or c++)
[15:27:25 CEST] <D404|Ghetto> that is
[15:27:35 CEST] <D404|Ghetto> for an argument of N
[15:27:49 CEST] <D404|Ghetto> output clip.trim(0,N).reverse()+clip
[15:28:01 CEST] <D404|Ghetto> so N=5, outputs 5432112345<...>
[15:28:08 CEST] <D404|Ghetto> apparently this is nontrivial with lavfi.
[15:28:20 CEST] <ubitux> >reverse
[15:28:29 CEST] <J_Darnley> bove: yes
[15:28:29 CEST] <D404|Ghetto> yeah bruh
[15:28:31 CEST] <D404|Ghetto> stacks a queues
[15:28:33 CEST] <D404|Ghetto> hard shit.
[15:28:34 CEST] <D404|Ghetto> and*
[15:28:35 CEST] <ubitux> if it's reversing all the frames, you're going to have a bad time
[15:28:40 CEST] <D404|Ghetto> N will be low
[15:28:43 CEST] <D404|Ghetto> it needs a buffer of N frames
[15:28:45 CEST] <D404|Ghetto> the end
[15:28:55 CEST] <ubitux> you'll need to write a filter for that then
[15:29:02 CEST] <D404|Ghetto> lol what a shithole lavfi is
[15:29:11 CEST] <D404|Ghetto> cant even do the simplest thing...
[15:29:15 CEST] <ubitux> but people are going to abuse it and mem bomb their machines
[15:29:25 CEST] <D404|Ghetto> by setting N=10000000?
[15:29:35 CEST] <ubitux> by trying to reverse whole video streams
[15:29:44 CEST] <D404|Ghetto> heh
[15:29:55 CEST] <D404|Ghetto> it's probably less painful to write a 10 line C program to pipe...
[15:29:56 CEST] <D404|Ghetto> meh
[15:30:04 CEST] <D404|Ghetto> rather than 200-300 lines of lavfi boilerplate shit
[15:30:16 CEST] <ubitux> writing such filter is not much effort though
[15:30:26 CEST] <J_Darnley> I should submit my empty vf_example filer
[15:30:27 CEST] <D404|Ghetto> *if you know all the internals of lavf already*
[15:30:45 CEST] <ubitux> D404|Ghetto: writing a filter like this really is trivial you know
[15:30:55 CEST] <D404|Ghetto> i can only didagree
[15:31:01 CEST] <D404|Ghetto> trivial is a 10 line program to pipe it
[15:31:13 CEST] <D404|Ghetto> not dealing with the complexity that is lavfi
[15:31:18 CEST] <ubitux> the filter will be 100 lines max
[15:31:26 CEST] <ubitux> then you can use it in a simple graph
[15:31:28 CEST] <D404|Ghetto> >100 lines for a fuckign queue
[15:31:31 CEST] <D404|Ghetto> yes
[15:31:32 CEST] <D404|Ghetto> "trivial"
[15:31:36 CEST] <D404|Ghetto> maybe you ought to take a step back
[15:31:40 CEST] <ubitux> ... whatever
[15:32:00 CEST] <D404|Ghetto> if 100 liens is trivial
[15:32:03 CEST] <D404|Ghetto> no wonder lavfi is the way it is
[15:32:03 CEST] <D404|Ghetto> >.>
[15:32:06 CEST] <ubitux> you can probably make it under 50 lines if you remove the license
[15:32:34 CEST] <D404|Ghetto> is there an example file yet
[15:32:39 CEST] <D404|Ghetto> or up-to-date doc
[15:32:52 CEST] <D404|Ghetto> it would entail modifying the clip length.
[15:33:04 CEST] <J_Darnley> vf_example: http://codepad.org/OQjPwIcg
[15:33:31 CEST] <J_Darnley> (oh lord it did try to compile it)
[15:33:42 CEST] <D404|Ghetto> J_Darnley: great
[15:33:49 CEST] <D404|Ghetto> that's miles better than the stuff i saw before
[15:33:53 CEST] <D404|Ghetto> with little to no comments
[15:35:00 CEST] <ubitux> ...
[15:35:27 CEST] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=doc/writing_filters.txt;hb=HEAD
[15:36:10 CEST] <ubitux> i'd suggest to take basis on vf_thumbnail
[15:36:30 CEST] <ubitux> which is queuing N frames and outputing one at the end
[15:36:31 CEST] <D404|Ghetto> ubitux: vf_example.c gave me more info almost immediately than i felt i absorbed after reading that doc
[15:36:44 CEST] <D404|Ghetto> as in, it is concrete
[15:36:52 CEST] <D404|Ghetto> i'd +1 to adding it somewhere in the wiki
[15:36:53 CEST] <D404|Ghetto> or texi
[15:37:00 CEST] <ubitux> sed 's/edgedetect/foobar/g;s/EdgeDetect/Foobar/g' libavfilter/vf_edgedetect.c > libavfilter/vf_foobar.c
[15:37:06 CEST] <ubitux> here you have your vf_foobar.c
[15:37:29 CEST] <durandal_1707> why you need to reverse order of frames and how many of them you need?
[15:37:38 CEST] <D404|Ghetto> durandal_1707: it's a work around for me
[15:37:53 CEST] <D404|Ghetto> x264 + threads + vbv + crf doesnt work well on some clios
[15:37:58 CEST] <D404|Ghetto> vbv needs warming up
[15:38:11 CEST] <D404|Ghetto> a good way suggested to me was to use a palindrome at teh start
[15:38:15 CEST] <D404|Ghetto> and chop it off before muxing
[15:38:30 CEST] <D404|Ghetto> in lieu of fixing it in x264, since it's nontrivial to do so atm
[15:38:45 CEST] <D404|Ghetto> aside from a very large test for good starting oarams (empirical)
[15:38:50 CEST] <D404|Ghetto> mostly a stop-gap.
[15:39:32 CEST] <durandal_1707> there is libavfilter/bufferqueue.h
[15:40:21 CEST] <durandal_1707> btw nobody cares for dynaudnorm :(
[15:45:45 CEST] <durandal_1707> so how much of max frames you need to buffer?
[15:46:18 CEST] <D404|Ghetto> depends on the buffer in x264 and number of threads
[15:46:21 CEST] <D404|Ghetto> its a hack, like i said
[15:47:25 CEST] <durandal_1707> so 1773?
[15:47:43 CEST] <D404|Ghetto> e.g. 8 threads is ~15 frames
[15:48:18 CEST] <D404|Ghetto> it's something like thread_count+b_frame+delay
[16:09:09 CEST] <D404|Ghetto> might be working
[16:09:16 CEST] <JEEB> nice
[16:09:25 CEST] <D404|Ghetto> probably too edge-case-y to submit
[16:09:43 CEST] <D404|Ghetto> it's a shame there is no equivalent to trim easily
[16:11:10 CEST] <ubitux> ?
[16:11:52 CEST] <D404|Ghetto> it would make more sense to submit vf_reverse
[16:12:03 CEST] <D404|Ghetto> to be used something like -vf reverse=5 and output a clip of length 5
[16:12:07 CEST] <D404|Ghetto> or something
[16:12:15 CEST] <D404|Ghetto> and then concat the two clips separately
[16:12:23 CEST] <ubitux> just reverse the whole stream in vf_reverse
[16:12:33 CEST] <D404|Ghetto> wouldnt that be insanely slow
[16:12:41 CEST] <ubitux> and you just trim it
[16:12:43 CEST] <ubitux> ?
[16:12:57 CEST] <ubitux> -vf reverse,trim=end=5
[16:13:04 CEST] <D404|Ghetto> why did you suggest i write my own filter net
[16:13:07 CEST] <D404|Ghetto> then*
[16:13:13 CEST] <nevcairiel> how can a filter reverse a movie
[16:13:21 CEST] <ubitux> nevcairiel: by queuing everything
[16:13:44 CEST] <nevcairiel> that seems like something that wouldnt work very well
[16:13:46 CEST] <D404|Ghetto> ubitux: so in theory it *is* possible to do clip.revers().trim(0,N)+clip
[16:13:47 CEST] <ubitux> except reverse will get a EOF and will just push its queue in reverse 
[16:13:48 CEST] <D404|Ghetto> in lavfi?
[16:13:52 CEST] <D404|Ghetto> with a compelx filergarph?
[16:13:54 CEST] <nevcairiel> buffering an entire movie uncompressed in memory
[16:13:54 CEST] <ubitux> if you write a reverse filter
[16:13:55 CEST] <nevcairiel> oh boy
[16:13:59 CEST] <ubitux> which is a few lines of code
[16:14:02 CEST] <D404|Ghetto> ubitux: ok but thats simple
[16:14:15 CEST] <D404|Ghetto> thats why i said reverse=5
[16:14:18 CEST] <D404|Ghetto> to limit its length
[16:14:25 CEST] <D404|Ghetto> rather than default to some insane lenght
[16:14:27 CEST] <D404|Ghetto> like the whole movie
[16:14:28 CEST] <ubitux> the following trim filter does it for you
[16:14:38 CEST] <D404|Ghetto> 16:14 <@D404|Ghetto> rather than default to some insane lenght
[16:14:42 CEST] <ubitux> it won't
[16:14:43 CEST] <D404|Ghetto> -vf swap
[16:14:56 CEST] <D404|Ghetto> eh?
[16:15:03 CEST] <D404|Ghetto> reversing the whole clip is an insane default.
[16:15:09 CEST] <ubitux> it won't
[16:15:17 CEST] <D404|Ghetto> i.e. just a bare -vf reverse
[16:15:17 CEST] <ubitux> i mean, the trim will stop you
[16:15:22 CEST] <D404|Ghetto> NO TRIM
[16:15:25 CEST] <D404|Ghetto> see above
[16:15:28 CEST] <ubitux> well, there are filters to stop streams
[16:15:32 CEST] <D404|Ghetto> note how i said default
[16:15:36 CEST] <D404|Ghetto> with no otehr filters
[16:15:54 CEST] <ubitux> you could also use the timeline mecanism to flush your queue btw
[16:16:08 CEST] <D404|Ghetto> i dont know what that means
[16:16:13 CEST] <D404|Ghetto> but none of this soudns very user friendly
[16:16:33 CEST] <ubitux> "reverse=enable='lt(t,5)'"
[16:16:47 CEST] <ubitux> (so you could reverse chunks)
[16:16:51 CEST] <D404|Ghetto> 16:15 <@D404|Ghetto> i.e. just a bare -vf reverse
[16:16:55 CEST] <D404|Ghetto> what about this case
[16:16:58 CEST] <D404|Ghetto> which would surelt be common
[16:17:17 CEST] <ubitux> just don't duplicate a mecanic that already exists
[16:17:22 CEST] <ubitux> aka trim filters or timeline system
[16:17:34 CEST] <D404|Ghetto> that si not helpful
[16:17:44 CEST] <D404|Ghetto> so what SHOULD be the default of a bare call to reverse
[16:17:48 CEST] <D404|Ghetto> if not to limit its size
[16:17:57 CEST] <D404|Ghetto> instead of queuign a whole movie
[16:18:08 CEST] <ubitux> i see no other sane default
[16:18:14 CEST] <ubitux> you prefer hardcoding 5 seconds?
[16:18:19 CEST] <D404|Ghetto> something like that yes
[16:18:25 CEST] <D404|Ghetto> with a av_log or something
[16:18:40 CEST] <D404|Ghetto> i expect carl will love me
[16:18:45 CEST] <ubitux> so let's say you have a user that reverse very small gif of < 5 sec
[16:18:47 CEST] <D404|Ghetto> for hoards of users reversing entire movies
[16:18:51 CEST] <ubitux> and one days he allows 7 seconds
[16:18:58 CEST] <ubitux> only a part of it will be reversed?
[16:19:04 CEST] <D404|Ghetto> no
[16:19:14 CEST] <D404|Ghetto> i would NEVER write vf_reverse to reverse chunks only
[16:19:18 CEST] <D404|Ghetto> thats completely fuckign stupid and pointless
[16:19:36 CEST] <ubitux> so how it would behave for t>5?
[16:19:42 CEST] <D404|Ghetto> tirm it.
[16:19:44 CEST] <D404|Ghetto> trim*
[16:20:05 CEST] <ubitux> :/
[16:20:16 CEST] <D404|Ghetto> i argue that tirming makes more sense than reversing a chunk
[16:20:27 CEST] <D404|Ghetto> which is a stupid-as-hell idea
[16:20:48 CEST] <ubitux> which is why you should just reverse the whole stream given and let other filters do the trim
[16:20:55 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:f7068bf277a3: avcodec/alac: Clear pointers in allocate_buffers()
[16:20:56 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:39bbdebb1ed8: avcodec/sanm: Reset sizes in destroy_buffers()
[16:20:59 CEST] <D404|Ghetto> that is also terrible
[16:21:03 CEST] <ubitux> why?
[16:21:06 CEST] <D404|Ghetto> lets use ALL THE MEMORY 
[16:21:13 CEST] <D404|Ghetto> on a filter that people will definitely use
[16:21:16 CEST] <D404|Ghetto> (they use other tools atm)
[16:21:23 CEST] <D404|Ghetto> surely nothing bad will happen
[16:21:32 CEST] <ubitux> what happens in vs when you clip.reverse()?
[16:21:42 CEST] <D404|Ghetto> vs has random access.
[16:21:45 CEST] <D404|Ghetto> so does avs.
[16:21:55 CEST] <D404|Ghetto> it has seeking and cachign aroudn said seeks
[16:21:56 CEST] <nevcairiel> yeah theyll read chunk after chunk and reverse those
[16:21:57 CEST] <ubitux> so it reverses per chunk and does seeks?
[16:22:02 CEST] <ubitux> ok
[16:22:08 CEST] <nevcairiel> the only way to really do it
[16:22:14 CEST] <ubitux> what if it can't stream?
[16:22:16 CEST] <ubitux> heh
[16:22:19 CEST] <ubitux> can't seek*
[16:22:22 CEST] <D404|Ghetto> it always can.
[16:22:25 CEST] <D404|Ghetto> it is a requirement
[16:22:31 CEST] <D404|Ghetto> so is a known clip length
[16:22:34 CEST] <ubitux> so it supports almost nothing?
[16:22:39 CEST] <nevcairiel> it does expensive indexing if required
[16:22:40 CEST] <D404|Ghetto> almost everything you mean?
[16:22:50 CEST] <D404|Ghetto> nevcairiel: indexing 200 gb took me 20s
[16:22:53 CEST] <D404|Ghetto> "expensive"
[16:23:00 CEST] <D404|Ghetto> with ffms2
[16:23:14 CEST] <D404|Ghetto> it's almost as if,
[16:23:15 CEST] <D404|Ghetto> and keep with me here
[16:23:21 CEST] <D404|Ghetto> avs and vs were meant for NLE
[16:23:25 CEST] <D404|Ghetto> oh wait they were.
[16:23:26 CEST] <D404|Ghetto> SHOCKING
[16:23:30 CEST] <nevcairiel> i dunno, when i encode a movie with x264 and ffms input, indexing takes ages :(
[16:23:59 CEST] <nevcairiel> like 1gb in minutes, not seconds
[16:24:03 CEST] <D404|Ghetto> wut
[16:24:08 CEST] <D404|Ghetto> i cant say i have that experience
[16:24:14 CEST] <D404|Ghetto> but i also dont use x264
[16:24:16 CEST] <D404|Ghetto> i use ffmsindex.
[16:24:42 CEST] <nevcairiel> it seems to go faster if i pass --no-interlace to the command, as if it does extra processing then, but what do i know
[16:24:45 CEST] <nevcairiel> i only rarely encode
[16:24:48 CEST] <D404|Ghetto> wut
[16:24:58 CEST] <D404|Ghetto> ffms2 doesnt index differently 
[16:26:03 CEST] <nevcairiel> all i know is that indexing takes ages here
[16:26:14 CEST] <nevcairiel> 3.4gb dvd rip, about 1.2 hours in length
[16:26:16 CEST] <D404|Ghetto> lavfi is the opposite end
[16:26:24 CEST] <D404|Ghetto> we cant have ANY filters taht require a sane random access
[16:26:27 CEST] <D404|Ghetto> in any sane way
[16:26:28 CEST] <nevcairiel> indexing takes at least a minute
[16:27:00 CEST] <D404|Ghetto> i dont use ffms2 for dvds if i can
[16:27:05 CEST] <D404|Ghetto> lavf is pretty bad at mpeg-ps
[16:27:14 CEST] <nevcairiel> its a mkv
[16:27:20 CEST] <nevcairiel> was a dvd at one time
[16:27:22 CEST] <D404|Ghetto> oh, *rip*
[16:27:23 CEST] <D404|Ghetto> i misread
[16:27:33 CEST] <D404|Ghetto> nevcairiel: that may have been due to the haali demuxer
[16:27:37 CEST] <D404|Ghetto> which is now nuked.
[16:27:53 CEST] <nevcairiel> it was a x264 build from last week, but what do i know what versions were used
[16:28:00 CEST] <D404|Ghetto> :D
[16:28:14 CEST] <nevcairiel> (i actually did this on the weekend, archiving some content)
[16:30:16 CEST] <D404|Ghetto> i guess i will just submit vf_reverse.c
[16:30:22 CEST] <D404|Ghetto> amd have it queue the whole movie
[16:30:28 CEST] <D404|Ghetto> and carl can direct all complaints at ubitux 
[16:31:09 CEST] <ubitux> :)
[16:33:22 CEST] <ubitux> you forgot the step were you complain about lavfi because of request_frame()
[16:33:31 CEST] <ubitux> and then abandon the idea of writing the filter
[16:33:35 CEST] <ubitux> after complaining one more time
[16:33:42 CEST] <ubitux> and derping about how vs is so much better ;)
[16:34:09 CEST] <ubitux> (and then durandal_1707 will implement it just like with w3dif the next day)
[16:34:23 CEST] <D404|Ghetto> vs has a similar mechanism
[16:34:37 CEST] <D404|Ghetto> filters need to know how many frames they need
[16:35:41 CEST] <D404|Ghetto> mind you vs handles it a bit mroe for you
[16:35:44 CEST] <D404|Ghetto> (i.e. no need to loop_
[16:38:09 CEST] <wm4> D404|Ghetto is hacking libavfilter? has hell frozen over?
[16:38:12 CEST] <cone-613> ffmpeg 03Anton Khirnov 07master:18156b53f9b6: hevc: do not pass an entire HEVCContext into export_stream_params()
[16:38:13 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:d13fc982470f: Merge commit '18156b53f9b642b71c182c5c9818175a61572d2b'
[16:38:30 CEST] <D404|Ghetto> wm4: it's either that or i pipe like ffmpeg | my10lineCfile | ffmpeg
[16:45:18 CEST] <Plorkyeran> indexing large files with ffms2 is typically i/o bound if you're only indexing video
[16:45:38 CEST] <Plorkyeran> so indexing something already in the cache is super fast
[16:45:39 CEST] <D404|Ghetto> i always hard disable audio
[16:45:48 CEST] <D404|Ghetto> since i dont use ffms2 for audio
[16:46:15 CEST] <nevcairiel> isnt audio usually quite cheap, why would that slow things down much
[16:46:37 CEST] <Plorkyeran> it has to decode the audio
[16:46:50 CEST] <Plorkyeran> for sample-accurate seeking
[16:47:05 CEST] <nevcairiel> i wonder if x264 is smart enough to ignore the audio when it uses ffms
[16:47:41 CEST] <Plorkyeran> iirc ffms was initially added to x264 specifically for audio support, but since audio never actually landed...
[16:47:52 CEST] <cone-613> ffmpeg 03Anton Khirnov 07master:077b55943330: hevc: handle a NULL sps in set_sps() properly
[16:47:53 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:afa97144cff8: Merge commit '077b55943330150db0eafd36bbee614697cabd98'
[16:48:03 CEST] <Plorkyeran> you do have to actively ask for audio tracks to be indexed
[16:48:18 CEST] <D404|Ghetto> http://git.videolan.org/?p=x264.git;a=blob;f=input/ffms.c;h=6a3eb6c7663aba9a0d2901ce17e1a31d840de164;hb=HEAD#l115
[16:49:23 CEST] <Plorkyeran> yeah, doesn't index audio
[16:54:41 CEST] <durandal_1707> seeking with lavfi, what needs to be done?
[16:54:54 CEST] <nevcairiel> A total redesign
[16:55:48 CEST] <D404|Ghetto> lol yep
[16:58:48 CEST] <cone-613> ffmpeg 03Anton Khirnov 07master:b9f76d19d81f: hevc_ps: make sure failing to decode an SPS always returns an error
[16:58:49 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:1127b35ff100: Merge commit 'b9f76d19d81fbc7f088536f966c2d3dc23c34ddc'
[17:11:13 CEST] <cone-613> ffmpeg 03Anton Khirnov 07master:a062a55d3772: hevc_parser: fix standalone build with the hevc decoder disabled
[17:11:14 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:5be07d020691: Merge commit 'a062a55d37720abc8c704aa0e8682efd3cdc9c9b'
[17:17:30 CEST] <durandal_1707> do we have ffserver maintainer?
[17:19:46 CEST] <cone-613> ffmpeg 03James Almer 07master:1b9a8e5f1d00: dxva2_hevc: unbreak compilation after recent sps/pps changes
[17:19:47 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:da10aaf23844: Merge commit '1b9a8e5f1d007ea19f04032490d681becd0d4e6a'
[17:20:05 CEST] <ubitux> durandal_1707: reynaldo 
[17:20:25 CEST] <ubitux> about seeking i would guess you need to mark filters that support seeking
[17:20:40 CEST] <ubitux> most likely, it overlaps with all those with generic timeline filter
[17:20:42 CEST] <kierank> lglinskih: ping
[17:21:38 CEST] <ubitux> s/filter/support/
[17:22:38 CEST] <ubitux> (so about 50 filters where seekable requires 0 effort)
[17:23:50 CEST] <ubitux> "seeking" support can mean many thing actually
[17:25:02 CEST] <ubitux> i don't see how a filter can request a seek
[17:28:23 CEST] <lglinskih> kierank: hi! I'm preparing the first version of a patch -- I will send it to you in a few minutes
[17:28:28 CEST] <kierank> ok
[17:51:12 CEST] <durandal_1707> ubitux: have you tried dynaudnorm?
[17:51:42 CEST] <ubitux> nope
[17:51:53 CEST] <durandal_1707> D404|Ghetto: have you sent patch?
[17:52:01 CEST] <lglinskih> kierank: https://github.com/lglinskih/FFmpeg/commit/d507e334340371104a15591a4c05296b5bfcb41e
[17:52:48 CEST] <ubitux> durandal_1707: where is that?
[17:53:14 CEST] <lglinskih> kierank: it looks pretty simple, but it was hard)
[17:54:01 CEST] <kierank> lglinskih: cool
[17:54:08 CEST] <kierank> can you make it work with all the h264 samples?
[17:54:37 CEST] <durandal_1707> ubitux: dynamic audio normalizer
[17:55:00 CEST] <D404|Ghetto> durandal_1707: not yet
[17:55:11 CEST] <D404|Ghetto> i still have no inyernet at home aside from my.phone
[17:55:13 CEST] <durandal_1707> on ml
[17:55:15 CEST] <D404|Ghetto> soon
[18:00:02 CEST] <lglinskih> kierank: this line in h264.c capabilities = /*CODEC_CAP_DRAW_HORIZ_BAND |*/  confuses me
[18:00:18 CEST] <kierank> hmm someone disabled it
[18:00:27 CEST] <wm4> probably didn't work
[18:00:41 CEST] <wm4> mplayer gets crashes all the time because it tries to use this
[18:01:00 CEST] <wm4> that, and custom (broken?) get_buffer usage, or something
[18:01:45 CEST] <kierank> difficult to tell what commit changed it because of k&r
[18:02:27 CEST] <wm4> which file?
[18:02:45 CEST] <wm4> ah, h264.c
[18:03:14 CEST] <kierank> yeah it's just part of a huge diego k&r
[18:03:27 CEST] <wm4> hahaha
[18:03:35 CEST] <wm4> it was commented in the initial commit
[18:03:39 CEST] <wm4> 0da71265d84b587c7159cd82708ca60ad050dd4c
[18:03:43 CEST] <wm4> (also gitk is awesome)
[18:03:55 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:ba051661746f: configure: Fix build with --disable-decoders --enable-parser=hevc
[18:12:01 CEST] <nevcairiel> i'm still confuzzled about the actual use of that "feature"
[18:12:14 CEST] <nevcairiel> seems like something worth purging rather than testing
[18:12:36 CEST] <kierank> it lets you do processing on the decoded video before it's finished decoding
[18:12:47 CEST] <kierank> x264 has a similar feature in the coded domain
[18:12:52 CEST] <nevcairiel> how is that a good thing
[18:13:06 CEST] <kierank> data's in cache still
[18:13:16 CEST] <nevcairiel> doesnt that ruin reference frames for you
[18:13:50 CEST] <kierank> you don't change it in place
[18:14:06 CEST] <nevcairiel> seems like a very marginal usecase then
[18:17:00 CEST] <jamrial> lots of new memleaks in hevc after the recent merges
[18:21:49 CEST] <durandal_1707> stop merges
[18:59:47 CEST] <lglinskih> kierank: so should I add support of other codecs? 
[18:59:52 CEST] <kierank> yes
[19:13:54 CEST] <xLinuxBot> anyone tried hardware accelerated encoding with ffmpeg on ARM devices ?
[19:17:15 CEST] <Reelee> Can anyone look at  https://trac.ffmpeg.org/ticket/4200 an see if it's possible to be looked into?
[19:31:27 CEST] <Compn> xLinuxBot : i know its possible depending on your arm hardware :P
[19:31:35 CEST] <Compn> well decodin, not sure about encoding ...
[19:33:33 CEST] <Compn> Reelee : theres a couple bugs in that bug. one is that there are some subtitles that ffmpeg are not displaying. do the subs display for you in ffplay ?
[19:33:40 CEST] <Compn> or do you have a sample you can share with us ?
[19:33:40 CEST] <nevcairiel> why do we have two hevc parsers now, for once I wish we would just decide and drop one of them
[19:34:29 CEST] <Reelee> Compn: The sample is attached to the ticket. The subs don't show in FFplay (2.7.1) but they show fine on VLC 2.2.
[19:34:53 CEST] <Reelee> Compn: Sample can be found here https://trac.ffmpeg.org/attachment/ticket/4200/dvbsub-sample.ts
[19:35:06 CEST] <Compn> right
[19:35:22 CEST] <Compn> oh yeah , i was unable to download that sample
[19:35:30 CEST] <Compn> because my web browser and wget refuse it :D
[19:35:39 CEST] <Compn> let me try chrome
[19:36:00 CEST] <Compn> Reelee : do any of the tsprobe options help ffplay to display / detect the subs ?
[19:36:56 CEST] <Reelee> Checking now...
[19:37:02 CEST] <Compn> chrome wont even load that sample for me , https://trac.ffmpeg.org/attachment/ticket/4200/dvbsub-sample.ts
[19:37:32 CEST] <Reelee> Hm, any way you can download it locally and try like that? I think it might have to do with ffmpeg.org server
[19:37:40 CEST] <Compn> right , its a bug on our end
[19:38:46 CEST] <Compn> argh that url brings up trac displaying binary :\
[19:38:49 CEST] <Compn> why trac whyyyy
[19:38:57 CEST] <Reelee> Uploading to Dropbox to bypass :)
[19:38:57 CEST] <Compn> also why am i not trac admin
[19:39:31 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:697160366fd1: avcodec/vp3: check current_frame before accessing it
[19:39:32 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:cc0380222add: avcodec/mpegvideo: Check for NULL in ff_mpv_common_end()
[19:39:33 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:feb6a94f740b: avutil/frame: fix crash with av_frame_unref(NULL)
[19:39:51 CEST] <Reelee> Compn: Here's an alternative for the sample https://www.dropbox.com/s/pbl8z98jo70wp8b/dvbsub-sample.ts?dl=0
[19:40:24 CEST] <Compn> thx
[19:41:32 CEST] <Compn> [dvbsub @ 01387e80]Invalid DVB subtitles stream extradata!
[19:41:36 CEST] <Compn> lavc failed decoding subtitle
[19:42:25 CEST] <nevcairiel> thats only a warning, it could still work
[19:43:05 CEST] <nevcairiel> seems kinda odd anyway, from a TS file you wouldnt get any extradata anyway
[19:43:19 CEST] <Compn> (thats mplayer output)
[19:43:41 CEST] <durandal_1707> J_Darnley: what happened with lut patch testing?
[19:43:42 CEST] <Compn> obviously, the dvbsub line is from lavf though
[19:45:29 CEST] <J_Darnley> durandal_1707: did I not say?  I couldn't get any sensible results
[19:46:46 CEST] <durandal_1707> just with simple time?
[19:46:55 CEST] <J_Darnley> yeah, even that
[19:47:10 CEST] <J_Darnley> I could show that 2+ threads was quicker than 1
[19:47:34 CEST] <J_Darnley> but time didn't reliably decrease with 3 or 4 threads
[19:48:33 CEST] <xLinuxBot> Compn : yes. decoding working fine in many AMR devices. 
[19:48:35 CEST] <jamrial> nevcairiel: see my related patch. in a way it's not a bad idea having both since the new one is supposedly less complete
[19:48:48 CEST] <nevcairiel> then drop the new one
[19:48:49 CEST] <jamrial> and it's not like they are two separate components, like it happened with asf
[19:48:53 CEST] <nevcairiel> two is just silly
[19:49:17 CEST] <nevcairiel> parsers arent magic afterall
[19:50:27 CEST] <xLinuxBot> Compn : like to do HW encoding in Amlogic S805, it supports H264 1080p. 
[19:53:48 CEST] <Compn> Reelee :  i am unable to get the dvbsubs to decode or even rip in ffmpeg. i'll keep looking. it might also be possible to use vlc to transcode that file though if you wanted, not sure if vlc can do hls output though
[19:54:47 CEST] <jamrial> nevcairiel: old one requires hevc decoder. new one doesn't. and as i said it's one parser component. with my patch it will compile one or the other depending on hevc decoder availability
[19:55:09 CEST] <Reelee> Compn: I can try VLC to decode/encode but it complicates things by passing on FFmpeg settings, etc.
[19:55:09 CEST] <jamrial> now, assuming there's no point in having a parser without a decoder then yeah, i agree we could just drop the new one
[19:55:46 CEST] <Reelee> Compn: Thanks for looking into it, I appreciate it. And let me know if I can help in any way :)
[19:56:19 CEST] <Compn> oh i was able to rip it 
[19:56:33 CEST] <Compn> ffmpeg -i dvbsub-sample.ts -vn -an -scodec copy -f rawvideo out.dvbsubs
[19:56:40 CEST] <Compn> but i'm not sure what good that will do me
[19:58:45 CEST] <cone-613> ffmpeg 03James Almer 07master:84e847c7c80c: avcodec/hevc_parser: use the old parser only when hevc decoder is available
[20:07:25 CEST] <Reelee> Compn: Can you view the subtitles in the output using VLC?
[20:08:11 CEST] <Compn> yes
[20:08:22 CEST] <Compn> in the sample file
[20:08:23 CEST] <Compn> i mean
[20:11:22 CEST] <Compn> i dont think anything will be able to play ffmpeg's raw dvbsub output 
[20:11:30 CEST] <Compn> of course, thats probably not useful for anything.
[20:13:33 CEST] <Reelee> Any way these can be burned into output?
[20:16:55 CEST] <Compn> Reelee : with vlc yes
[20:17:21 CEST] <Compn> Reelee : i dont know how to fix it with ffmpeg, will have to ask someone else to look at it :)
[20:17:35 CEST] <Reelee> Thanks!
[20:17:59 CEST] <Reelee> Compn: So with VLC would that be VLC doing the decoding/encoding by itself or would FFmpeg pipe the output to VLC to then encode?
[20:20:21 CEST] <Compn> Reelee : i think vlc could do it all
[20:20:56 CEST] <Reelee> Cool! Thank you very much for your time and I hope someone gets a chance to sort the #4200 in FFmpeg.
[20:43:30 CEST] <Compn> xLinuxBot : sorry, gotta run. find out what api we need to add to use hw encoding on your android device. is it omx ?
[20:55:07 CEST] <xLinuxBot> Compn: np, are you saying about Android Media API ? 
[20:55:08 CEST] <philipl> I thought we already had omx and/or mediacodec
[20:59:05 CEST] <xLinuxBot> Compn: philipl:need to check MediaCodec and OMXCodec is working or not.
[21:00:43 CEST] <xLinuxBot> i would like to do encode live sream and push stream to remote server with ffmpeg, is it possible on those devices
[21:02:13 CEST] <xLinuxBot> Compn: some one did this on Allwinner A80 + ffmpeg for 4K video -> https://youtu.be/99kjbriibPY
[21:37:59 CEST] <durandal_1707> michaelni: if nobody reviews psnr and ssim asm patch feel free to apply them
[21:43:21 CEST] <jamrial> michaelni: 4496ccc7 started the hevc leaks
[21:44:05 CEST] <jamrial> looks like the old parser doesn't play nice with the rest of the changes to the parameterset stuff
[22:09:50 CEST] <philipl> xLinuxBot: My impression is Android codec support is constantly re-implemented by other entities (hardware companies, media player authors) who never send patches back.
[22:10:33 CEST] <philipl> If you're lucky, they publish their source somewhere and then forget about it. If you're not lucky, they just happily violate the licence.
[22:11:19 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:5d346feafa81: avcodec/pthread_frame: check avctx on deallocation
[22:11:20 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:32d023eb6d0a: avformat/oggdec: Check buf before copying data in to it
[22:13:15 CEST] <philipl> It appears that upstream we have support H.264 acceleration through libstagefright
[22:13:25 CEST] <philipl> We don't have any other form of OMX and no mediacodec at all.
[22:13:35 CEST] <philipl> kodi uses mediacodec directly without involving ffmpeg
[22:25:25 CEST] <durandal_1707> J_Darnley: are you going to update removegrain patch after almer comments?
[22:31:21 CEST] <J_Darnley> Yeah, probably
[22:32:50 CEST] <J_Darnley> I did apply them then started looking at other factorising and avx2
[22:37:40 CEST] <cone-613> ffmpeg 03Michael Niedermayer 07master:85b7456efe9c: avcodec/hevc_parser: Fix memleaks in parser mix
[22:41:56 CEST] <michaelni> jamrial, should be fixed
[22:44:05 CEST] <J_Darnley> To the other people writing assembly: do you use any tools to indent and align things for you?  Or do you do it manually?
[22:45:38 CEST] <jamrial> manually
[23:11:29 CEST] <xLinuxBot> philipl: they are not publishing source. kodi using mediacodec for decode videos. 
[23:13:41 CEST] <wm4> supporting OMX is probably pointless
[23:13:55 CEST] <wm4> supposedly android is moving away from it
[23:14:05 CEST] <wm4> and normal apps can't access it anyway
[23:14:13 CEST] <philipl> xLinuxBot: I know diceplayer published source, but it's also possible that they just had the basic h.264 stagefright as I don't think it supports hw decode for anything else.
[23:15:15 CEST] <nevcairiel> on Android you should just use MediaCodec, although I have no clue how to get access to that from C, i only know the Java way
[23:15:28 CEST] <philipl> wm4: So it's going to all MediaCodec or is stagefright still a supported C way
[23:15:38 CEST] <philipl> How does kodi use MediaCodec? reverse JNI??
[23:15:41 CEST] <wm4> *shrug*
[23:15:55 CEST] <wm4> and apparently newer android versions have a C or C++ API for mediacodec
[23:16:16 CEST] <philipl> http://stackoverflow.com/questions/22084784/does-android-ndk-support-native-methodomxal-of-video-encoding
[23:16:18 CEST] <nevcairiel> Yeah apparently newer NDKs have a lib to access MediaCodec
[23:16:19 CEST] <philipl> Ta da.
[23:16:36 CEST] <wm4> https://github.com/xbmc/xbmc/blob/master/xbmc/cores/dvdplayer/DVDCodecs/Video/DVDVideoCodecAndroidMediaCodec.cpp
[23:16:42 CEST] <wm4> hurray jni
[23:17:03 CEST] <philipl> Oh gosh.
[23:17:21 CEST] <wm4> only 1.2kloc
[23:17:50 CEST] <philipl> If I read this correctly, they are not using the official NDK method, but are using the JNI interfaces that the java calls down to.
[23:17:53 CEST] <philipl> eeek
[23:18:08 CEST] <wm4> well that's all you could do some time ago
[23:18:15 CEST] <wbs> this isn't anything less official than using the stuff from the NDK
[23:18:19 CEST] <philipl> For sure. but they haven't tried to change it.
[23:18:23 CEST] <philipl> I guess for backward compat?
[23:18:23 CEST] <wbs> the new "ndk" way to access mediacodec is available only on android >= 5.0
[23:19:04 CEST] <wbs> it's a completely new "platform api" just to avoid having to write jni code (which really isn't bad), so for most usecases it's really best just to go for jni unless you can afford to just support the latest versions
[23:19:28 CEST] <nevcairiel> well "only latest" is a relative term anyway
[23:19:30 CEST] <wbs> also, the "stagrfright" decoder doesn't use supported api, at all - it never really worked well anywhere and has been unmaintained for 4 years
[23:19:49 CEST] <wbs> nevcairiel: well true, but still
[23:20:05 CEST] <wbs> but it's worth pointing out that it's not about you as developer having a new enough ndk, but the user having a new enough platform
[23:20:14 CEST] <xLinuxBot> they are using JNI -> https://github.com/xbmc/xbmc/blob/master/xbmc/android/jni/MediaCodec.cpp
[23:20:17 CEST] <wbs> (since it's not a static lib you link in that handles it for it)
[23:20:38 CEST] <wm4> <wbs> also, the "stagrfright" decoder doesn't use supported api, at all - it never really worked well anywhere and has been unmaintained for 4 years <- haha
[23:20:41 CEST] <nevcairiel> a year or two ago, using MediaCodec exclusively would've been a big nono since its only 4.1 and up
[23:20:51 CEST] <nevcairiel> these days, requiring 4.1 or newer is fine =p
[23:21:05 CEST] <wbs> wm4: yes, and still people seem to behave as if it is a working, good solution
[23:21:15 CEST] <wm4> haha
[23:21:21 CEST] <xLinuxBot> HEVC not playing well in Kodi in my device. but inbuild video player play well
[23:21:48 CEST] <wm4> wbs: and ffmpeg will never ever remove it anyway
[23:21:53 CEST] <wbs> wm4: and pretend that it is a viable, supported thing. people really should have read the commit message of the PoC patch that was merged even though it wasn't something that should be anywhere near a official tree, at least not without immense amounts of warnings and disclaimers
[23:21:55 CEST] <wm4> because it could be useful to someone
[23:22:22 CEST] <wm4> <3 ffmpeg dev process
[23:22:45 CEST] <nevcairiel> there is a process now?
[23:23:46 CEST] <wm4> yes, there is: blindly merge all the patches
[23:23:58 CEST] <wm4> ok I'll go back to my troll cave now
[23:24:36 CEST] <nevcairiel> speaking of caves, i wonder in which the dcadec author went to hide
[23:48:00 CEST] <philipl> wm4: Send a patch to delete the libstagefright codec. I'll ACK it :-)
[23:52:45 CEST] <J_Darnley> Ah mobile devices...  You can't count on things remaining the same so nobody ever implements features properly.
[23:53:12 CEST] <wm4> I bet dxva works just fine on windows phone
[23:53:22 CEST] <nevcairiel> no clue
[23:53:22 CEST] <nevcairiel> :D
[23:54:22 CEST] <nevcairiel> But it might as well, having a OS-level API for this sure helped to drive adoption of one API
[23:54:45 CEST] <nevcairiel> Although I think you need to use the d3d11 variant on recent Windows Mobile thingys
[23:57:10 CEST] <wm4> nevcairiel: right, that's why vlc added d3d11 support to lavc
[23:57:45 CEST] <wm4> and on Linux these hw decoding APIs are still vendor specific
[23:58:03 CEST] <nevcairiel> get systemd to adopt vdpau
[23:58:04 CEST] <nevcairiel> :P
[23:58:17 CEST] <wm4> there's vdpau, xvba (hopefully dead), vaapi, omx, v4l (yes they have a decoding API too), mediacodec
[23:58:36 CEST] <wm4> and then some more on random shitty SoCs (like mmal on rpi)
[23:59:10 CEST] <wm4> and this is so because nobody cares about the platform, only about pitching their shitty hw
[23:59:13 CEST] <nevcairiel> no idea how well dxva really works on mobile devices, but on desktop its not like there is much exotic hardware to support
[23:59:25 CEST] <rcombs> and then the higher-level thing on top of vaapi?
[00:00:00 CEST] --- Tue Jul 14 2015