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

[burek]

[00:04:35 CEST] <pfelt> ubitux: just found where it processes teh commands libavfilter/avfiltergraph.c:avfilter_graph_send_command()  looks like it'll work to pass to all filters with the same name so i can use the instance parameter to set it
[00:04:54 CEST] <pfelt> only other question is.  is there a way to send commands from an external process?  i haven't found a way yet
[00:06:36 CEST] <durandal_1707> z filter something
[00:06:50 CEST] <durandal_1707> need another lib
[00:11:00 CEST] Action: pfelt 's google foo isn't strong today
[00:19:40 CEST] <pfelt> durandal_1707: zmq filter
[00:49:38 CEST] <pfelt> is there any rhyme to the name of a filter?  (f* vs vf* vs af* etc)
[01:25:01 CEST] <Compn> pfelt : Video Filter v Audio Filter
[01:25:06 CEST] <Compn> vf v af
[01:25:29 CEST] <Compn> if thats what you were asking :D
[08:02:07 CEST] <kurosu> the wma lossless samples are 81KB zipped. Should I upload them somewhere, or is sending them to the mailing list ok ? (I guess the zip would be stripped from the mail)
[08:23:53 CEST] <ubitux> h
[08:23:57 CEST] <ubitux> oups
[08:35:55 CEST] <rcombs> so apparently AVFoundation sometimes decides to give us a 24-bit signed integer low-aligned (in 32-bit) stream
[08:36:03 CEST] <rcombs> as opposed to the usual 32-bit float
[08:36:31 CEST] <rcombs> no idea why, and I've been poking at supporting it with no luck
[08:36:49 CEST] <rcombs> seems to be random
[08:37:06 CEST] <rcombs> same device switches between giving 24-bit aligned int and 32-bit float
[08:37:17 CEST] <rcombs> (not during a single session, of course)
[09:31:57 CEST] <nevcairiel> sounds like a reliale api
[10:47:57 CEST] <JEEB> heh, coded_width/height case :/
[10:52:19 CEST] <j-b> 'morning
[11:04:40 CEST] <rcombs> now I'm curious what it uses coded_width/height for
[11:09:31 CEST] <nevcairiel> nothing of consequence it appears
[11:11:41 CEST] <nevcairiel> it does however check if its not null for some reason
[11:11:56 CEST] <nevcairiel> anyway exporting it in the compat block does no harm
[11:15:44 CEST] <wm4> is it a good idea to parse h264 extradata (sps in particular) on init to check the stream's profile?
[11:16:26 CEST] <nevcairiel> i do that
[11:17:42 CEST] <wm4> the fact that libavformat attempts to extract extradata even from annex b streams makes this attractive
[11:22:24 CEST] <wm4> some decoders return EAGAIN
[11:22:34 CEST] <wm4> this conflicts with the new decode API
[11:22:39 CEST] <wm4> bleh
[11:44:15 CEST] <mateo`> i'm wondering ... is the old bsf api still available ? (i just saw the audiotoolbox related patch)
[11:46:12 CEST] <wm4> it's deprecated, which means it'll still work for a while
[11:46:48 CEST] <nevcairiel> but any internal usage in ffmpeg libraries or tools should be updated rather sooner than later
[11:47:11 CEST] Action: wm4 wonders if there's any API ffmpeg.c uses that is NOT deprecated
[11:48:49 CEST] <mateo`> wm4: ok, i'm asking because the mediacodec decoder uses it, and i don't want it to be broken.
[11:49:25 CEST] <wm4> you should update it
[11:49:38 CEST] <mateo`> I don't have time to do the porting right now, but it's planned for something within 2~3 weeks
[11:50:30 CEST] <wm4> that should be fine
[11:50:31 CEST] <mateo`> it's not too far away in time ?
[11:50:38 CEST] <mateo`> ok
[12:14:54 CEST] <rcombs> moving to the new API is pretty simple; I only had trouble because I had to screw around with extradata and because I uncovered a couple semi-related issues at the same time
[12:15:23 CEST] <rcombs> though it could be tricky if using a filter that isn't 1:1
[12:15:26 CEST] <nevcairiel> since it uses extradata it should make that easier than the old compat hacks with avctx
[12:15:46 CEST] <nevcairiel> since its native codecpar now
[12:16:19 CEST] <rcombs> I mean in audiotoolbox
[12:16:44 CEST] <nevcairiel> ah well
[12:20:28 CEST] <rcombs> for autobsf it'll be awkward around 1:N bsfs, if those end up existing
[12:20:41 CEST] <nevcairiel> we only have a N:1 bsf so far
[12:20:51 CEST] <nevcairiel> the old api didnt really allow for 1:N, so =p
[12:21:12 CEST] <rcombs> guess I'll assume they don't exist for now
[12:21:23 CEST] <rcombs> what's N:1?
[12:21:29 CEST] <nevcairiel> vp9 superframe
[12:21:31 CEST] <rcombs> the VP9 one?
[12:21:32 CEST] <rcombs> ah
[12:21:44 CEST] <nevcairiel> it sometimes eats multiple frames and then packs them into one
[12:21:55 CEST] <rcombs> we packed B-frames now?
[12:22:04 CEST] <nevcairiel> vp9 doesnt have b frames
[12:22:23 CEST] <rcombs> </bad_joke>
[12:22:41 CEST] <nevcairiel> speaking about b-frames, the mpeg4 bframe unpack bsf could in theory be implemented as 1:N
[12:22:48 CEST] <rcombs> also, wait, VP9 doesn't have B-frames?
[12:22:50 CEST] <nevcairiel> but because its old, it somehow does that with internal buffering
[12:23:18 CEST] <nevcairiel> rcombs: not in the classic (mpeg) definition of a B frame, no
[12:23:50 CEST] <rcombs> I assume it has frame reordering
[12:23:53 CEST] <nevcairiel> no
[12:23:58 CEST] <nevcairiel> thats the shit it wanted to avoid
[12:24:11 CEST] <rcombs> huh, what's it do to compensate
[12:24:13 CEST] <wm4> wait what, really
[12:24:30 CEST] <wm4> no timestamp reordering fun and such?
[12:24:32 CEST] <rcombs> just picks up efficiency gains elsewhere?
[12:24:52 CEST] <nevcairiel> let me see if i can find BBBs explanation from some weeks ago
[12:24:56 CEST] <rcombs> I guess that explains all my WTFs looking at the lavc/libvpx files and wondering where all the timestamp handling is
[12:25:55 CEST] <rcombs> wm4: "where's the fun in that?"
[12:26:14 CEST] <wm4> seriously
[12:26:45 CEST] <wm4> so I guess these "golden frames" (or wtf it was) act as b-frames, and since they're never output, no user-visible reordering is needed?
[12:28:24 CEST] <atomnuker> I think B-frames were patented from MPEG2 days until like 2 or so years ago
[12:28:38 CEST] <rcombs> lovely
[12:31:37 CEST] <nevcairiel> http://forum.doom9.org/showthread.php?p=1756682#post1756682
[12:31:39 CEST] <nevcairiel> found it
[12:32:57 CEST] <nevcairiel> but yeah it comes down to using golden frames/altrefs if it really helps efficiency, and then add a inter frame full of skip blocks in the time position where the output is supposed to be
[12:33:02 CEST] <nevcairiel> that avoids the headache of re-ordering
[12:34:08 CEST] <rcombs> I'd imagine that adds a little overhead, but it's worth it in the lack of pulling out hair
[12:34:44 CEST] <nevcairiel> the advantage is that you could pre-process those invisible ref frames to be better references
[12:35:44 CEST] <rcombs> ah, nice
[12:37:17 CEST] <rcombs> so who remembers Perian
[12:38:58 CEST] <wm4> wasn't it dshow on osx
[12:39:06 CEST] <wm4> ffdshow I mean
[12:39:14 CEST] <nevcairiel> kind of, the devs gave it up a few years back
[12:41:12 CEST] <rcombs> so perian provided an ac3 decoder pre-10.11 (when the OS started shipping with it)
[12:41:26 CEST] <rcombs> and I guess it breaks with audiotoolboxdec
[12:42:09 CEST] <rcombs> so I was poking at explicitly asking for the Apple decoder in audiotoolboxdec (there's an API to pass in a "manufacturer")
[12:42:33 CEST] <rcombs> but apparently they advertise the decoders as manufacturer=appl just like the official ones
[12:43:10 CEST] <wm4> lol!
[12:43:21 CEST] <rcombs> so eh whatever
[12:43:33 CEST] <nevcairiel> tell people that they screwed themself
[12:43:33 CEST] <nevcairiel> :D
[12:43:35 CEST] Action: rcombs tells people to uninstall it
[12:43:56 CEST] <rcombs> or, well, the ac3 one is marked properly, actually
[12:44:08 CEST] <rcombs> but all the others (mp1, mp2, etc) are marked "appl"
[12:44:46 CEST] <rcombs> and I don't feel particularly inclined to add the handling for this if it's not reliable
[12:45:41 CEST] <rcombs> meanwhile, the eac3 decoder actually supports 7.1 (unlike the lavc one)
[12:46:18 CEST] <nevcairiel> why is ordinary 7.1 not supported anyway, or are we talking about the dependent stream business
[12:46:25 CEST] <rcombs> the dependent stream stuff
[12:46:29 CEST] <durandal_1707> Improve lavc 
[12:46:31 CEST] <rcombs> there's no "ordinary" 7.1 afaik
[12:46:42 CEST] <rcombs> always involves dependent streams
[12:47:02 CEST] <rcombs> but you have to tell it the channel count ahead-of-time, and I'm using lavc's ac3 header parser to determine that
[12:47:22 CEST] <rcombs> if you tell it there are 6 channels then it'll decode the 5.1 mix and give you that
[12:47:32 CEST] <rcombs> and doesn't tell you there are actually 8 in any way
[12:48:00 CEST] <nevcairiel> from what I can tell eac3 should support 7.1 without magic
[12:48:30 CEST] <rcombs> I'm not 100% sure on it, but I know all my samples use dependent substreams to code 7.1
[12:48:35 CEST] <wm4> what about those ac3+eac3 in the same stream nightmares?
[12:48:42 CEST] <nevcairiel> probably because they are all from Blu-ray
[12:48:47 CEST] <wm4> lol
[12:48:47 CEST] <rcombs> which makes some sense since it's supposed to be backwards-compatible to some degree
[12:49:37 CEST] <rcombs> like, devices are supposed to be able to strip the dependent substreams and convert the header to a standard ac3 one and shove that in an SPDIF packet
[12:50:01 CEST] <nevcairiel> HD DVD had eac3 as a fully mandatory format, there may be HDDVD EVO samples with eac3 7.1
[12:50:16 CEST] <nevcairiel> blu-ray made like no formats mandatory other than core ac3 and dts
[12:50:37 CEST] <nevcairiel> hence the backwards compatible hackery for eac3 7.1
[12:51:00 CEST] <rcombs> poking around the AudioToolbox binary, I found there's apparently a function that parses an (E)AC3 frame and returns the channel count and sampling rate
[12:51:06 CEST] <rcombs> but it's private API because ??????
[12:51:38 CEST] <nevcairiel> from what I can tell, supporting this in lavc wouldnt be insanely hard either, all the coding tools seem to be present mostly
[12:51:49 CEST] <rcombs> nevcairiel: I don't mean the BD thing with an AC3 frame and then an EAC3 dependent substream frame
[12:51:52 CEST] <nevcairiel> but its so rare in commercial content that personally I just dont care
[12:52:21 CEST] <rcombs> I mean devices are supposed to be able to repack an EAC3 frame into AC3
[12:52:24 CEST] <nevcairiel> rcombs: ac3 and eac3 have slightly different bitstream syntax, modifying an eac3 frame to be ac3 sounds silly otherwise
[12:53:10 CEST] <rcombs> "Dolby Digital Plus is a functional superset of Dolby Digital, and decoders include a mandatory component that directly converts (without decoding and re-encoding) the Dolby Digital Plus bitstream to a Dolby Digital bitstream (operating at 640kbit/s) for carriage via legacy S/PDIF connections (including S/PDIF over HDMI) to external decoders (e.g. AVRs, etc.)."
[12:53:46 CEST] <nevcairiel> eac3 can even have higher btirates than that, must be some arcane magic to get rid of some
[12:53:57 CEST] <rcombs> it's just dropping the dependent substreams
[12:54:08 CEST] <rcombs> and repacking in the ac3 bitstream format
[12:54:08 CEST] <nevcairiel> you can have higher bitrates in 5.1 as well
[12:55:02 CEST] <wm4> "S/PDIF over HDMI" haha
[12:55:08 CEST] <wm4> I like the sound of that
[12:55:09 CEST] Action: rcombs shrugs
[12:55:30 CEST] <wm4> users tend to dislike if passthrough is called spdif, for whatever reasons
[12:55:55 CEST] <rcombs> muh initialisms
[12:56:07 CEST] <rcombs> very scary
[12:57:10 CEST] <rcombs> nevcairiel: but yeah, I took a look at doing dependent substream decoding for eac3 a while back
[12:57:22 CEST] <rcombs> saw that it'd have to involve some awkward logic to remap channels
[12:57:39 CEST] <wm4> does AT not output planar?
[12:57:42 CEST] <nevcairiel> at least we have planar channels now, that makes such things miles easier
[12:57:44 CEST] <rcombs> like, you'd decode one frame, then move the channel data around, then decode the substream
[12:57:56 CEST] <nevcairiel> you can just flip pointers
[12:57:59 CEST] <rcombs> yeah, definitely easier that way
[12:58:12 CEST] <rcombs> and then I decided I didn't care enough to keep going
[12:58:18 CEST] <rcombs> since literally 0 people have requested this from me
[12:58:55 CEST] <rcombs> which is less than the number of people who have requested support for DTS-in-FLAC
[12:59:01 CEST] <rcombs> (1 person)
[12:59:35 CEST] <wm4> who created such a file? the ISIS?
[12:59:41 CEST] <Daemon404> 1:58] <+rcombs> and then I decided I didn't care enough to keep going <-- this speaks to me on a spiritual level
[13:00:15 CEST] <rcombs> ran out of ~effort~
[13:00:17 CEST] <nevcairiel> i tell people to go screw themself if they come with shit like dts in flac
[13:00:26 CEST] <rcombs> me too
[13:00:31 CEST] <nevcairiel> they should be happy that i support dts in wav
[13:01:24 CEST] <rcombs> DTS in FLAC: take a DTS CD, read it like a CDDA (i.e. treat the data as if it were PCM audio), and encode it to FLAC
[13:01:29 CEST] <Daemon404> isnt dts in wav more or less apdif?
[13:01:33 CEST] <nevcairiel> no
[13:01:35 CEST] <Daemon404> spdif*
[13:01:36 CEST] <nevcairiel> its just dts in wav
[13:01:43 CEST] <nevcairiel> no spdif packing
[13:01:49 CEST] <Daemon404> oh.
[13:01:57 CEST] <nevcairiel> its from dts audio cds
[13:01:57 CEST] <rcombs> playback involves decoding the FLAC, then putting the FLAC decoder's output through a DTS decoder
[13:02:22 CEST] <Daemon404> .....
[13:02:27 CEST] <Daemon404> sounds japanese
[13:02:36 CEST] <Daemon404> like their magic aac to wav thing
[13:02:38 CEST] <rcombs> apparently this is all so you can tag the FLAC files
[13:02:52 CEST] <Daemon404> because mka doesnt exis
[13:02:57 CEST] <Daemon404> t
[13:03:03 CEST] <rcombs> Daemon404: most people call an "aac to wav thing" an "aac decoder"
[13:03:13 CEST] <Daemon404> hah. but no.
[13:03:18 CEST] <Daemon404> this is named fakeaacwav
[13:03:21 CEST] <Daemon404> no. really.
[13:03:39 CEST] <rcombs> what, it crams an AAC bitstream in WAV as if it were PCM?
[13:03:47 CEST] <Daemon404> nope
[13:04:02 CEST] <Daemon404> it does some weird conversion to wav such that it can losslessly transform back
[13:04:03 CEST] <rcombs> explain
[13:04:05 CEST] <Daemon404> pcm in wav.
[13:04:16 CEST] <Daemon404> so it cam ne cut with avisynth
[13:04:23 CEST] <Daemon404> amd converted back losslessly to aac
[13:04:29 CEST] <nevcairiel> that sounds bizzare
[13:04:33 CEST] <Daemon404> i can dig up the program when im home
[13:04:43 CEST] <Daemon404> keeb knows what im talking about
[13:04:43 CEST] <nevcairiel> it pads it with zeros to some pcm bitrate for cutting?
[13:04:46 CEST] <Daemon404> jeeb even
[13:04:58 CEST] <Daemon404> i dont know what it does besides magic
[13:10:15 CEST] <JEEB> aac2wav, yeah. I remember that thing
[13:10:48 CEST] <wm4> it could use spdif framing?
[13:10:57 CEST] <JEEB> it basically packages AAC into PCM so you can cut it as if it's raw PCM
[13:11:04 CEST] <JEEB> (within video frame boundaries at least)
[13:11:23 CEST] <JEEB> so you could wavsource() it into avisynth and trim()
[13:11:40 CEST] <JEEB> and then extract the AAC track once again with the same tool so you can mux it into a container
[13:15:13 CEST] <Daemon404> http://aviutl.info/fakeaacwav-faw/
[13:15:18 CEST] <Daemon404> it is apparently still in use.
[13:16:54 CEST] <Daemon404> ... and so is avoutl
[13:17:01 CEST] <Daemon404> aviutl*
[13:23:15 CEST] <JEEB> ugh, not at my e-mail client but can someone tell cehoyos in the PGS thread that since we now know how to handle it correctly, he shouldn't commit a correct-only-for-SD solution :V
[13:23:38 CEST] <JEEB> since the YCbCr-to-RGB function is supposedly only correct for BT.601
[13:26:45 CEST] <rcombs> apparently adding support for non-PCM to avisynth would've been too hard?
[13:26:54 CEST] <wm4> JEEB: send a mail to the ML with those lines
[13:27:08 CEST] <wm4> rcombs: avisynth works on uncompressed data only
[13:27:27 CEST] <rcombs> and evidently this would have been difficult to change
[13:28:57 CEST] <JEEB> wm4: not doing top-posting seems to be problematic with my phone
[13:29:05 CEST] <JEEB> and that's the only mail client I have on hand atm
[13:29:15 CEST] <JEEB> but OK, I will try
[13:30:40 CEST] <wm4> JEEB: no, I meant "sent"
[13:31:03 CEST] <wm4> as in I've sent a mail
[13:48:31 CEST] <JEEB> ah
[13:48:33 CEST] <JEEB> dänks
[14:39:58 CEST] <Daemon404> nevcairiel, wtf is chromium using coded_* for
[14:40:11 CEST] <nevcairiel> dunno
[14:40:16 CEST] <nevcairiel> but it checks if its not zero
[14:40:33 CEST] <Daemon404> wut
[14:41:05 CEST] <nevcairiel> we could just fill it in the legacy compat thing again and be done with it, its not really a big deal
[14:41:35 CEST] <Daemon404> sure
[14:41:38 CEST] <Daemon404> but they ought to fix it
[14:41:46 CEST] <Daemon404> also i read their "system ffmpeg" patch
[14:41:51 CEST] <Daemon404> wtf are they doing with AV*Internal
[14:41:52 CEST] <nevcairiel> once they want to use codecpar they will need to anyway
[14:52:29 CEST] <atomnuker> holy crap I managed to make clang crash
[14:52:48 CEST] <atomnuker> it's asking me with all caps "PLEASE" to send a backtrace
[14:52:57 CEST] <wm4> poor thing
[14:57:03 CEST] <Daemon404> [FFmpeg-devel] FFMpeg/FFServer P2P streaming between ubuntu based embedded device and smartphone
[14:57:11 CEST] <Daemon404> another example of ffserver's existence doing more harm than good
[15:02:00 CEST] <wm4> yeah
[15:02:16 CEST] <wm4> but it will be used as proof that users still have interest in ffserver and that it shouldn't be deleted
[15:42:05 CEST] <cone-016> ffmpeg 03Martin Storsjö 07master:933dec0e29ec: file: Add an option for following a file that is being written
[15:42:06 CEST] <cone-016> ffmpeg 03Derek Buitenhuis 07master:90eb24996913: Merge commit '933dec0e29ec4d2cb83474279a6c52d62fdb7310'
[15:43:55 CEST] <cone-016> ffmpeg 03Lukasz Marek 07master:8833f1508b7b: opt: Add const to av_opt_next
[15:43:56 CEST] <cone-016> ffmpeg 03Derek Buitenhuis 07master:c54d835e2f18: Merge commit '8833f1508b7b6afc3172a8017934a7a54428c686'
[20:20:45 CEST] <cone-016> ffmpeg 03Michael Niedermayer 07master:564b4591bbe2: opt: Add av_opt_copy()
[20:20:46 CEST] <cone-016> ffmpeg 03Derek Buitenhuis 07master:e344646c808c: Merge commit '564b4591bbe223bdc5f36a1131eaef103f23f5d0'
[20:38:50 CEST] <tmm1_> what's the procedure for getting libav patches into ffmpeg?
[20:39:15 CEST] <JEEB> tmm1: usually things get merged (esp. now that TEP2 has been merged)
[20:39:26 CEST] <Daemon404> wait for them to be merged, or send them rebase on ffmpeg if you are impatient
[20:39:35 CEST] <JEEB> pretty much that
[20:39:37 CEST] <Daemon404> there is a merge backlog at the moment due to a very large merge a while back.
[20:41:52 CEST] <tmm1> okay, if i want to submit to the list i can just cherry-pick onto master and fix any conflicts right?
[20:41:59 CEST] <pfelt> speaking as a total noob here&.. could someone walk me through the TS stuff?  i'm working on a modification to a filter and it's sorta working.  now i'm getting "dropping frame x from stream y at ts z" which, if i'm understanding TS right, is expected as i'm not resetting the TS
[20:42:06 CEST] <Daemon404> tmm1, and of course confirm it works
[20:42:12 CEST] <Compn> and doesnt break fate....
[20:42:24 CEST] <Daemon404> that is part of "works"
[20:42:35 CEST] <tmm1> cheers
[20:42:37 CEST] <Compn> well "works 4 me" and "works" ...
[20:42:53 CEST] <Daemon404> bug clsoed as STFUIMDREPPER
[20:43:01 CEST] <Compn> i mean "feature works" v "works fate testing"
[20:43:03 CEST] <Compn> nevermind.
[20:43:08 CEST] <Daemon404> i know.
[20:43:38 CEST] <durandal_1707> anyone to backport few commits for me?
[21:48:45 CEST] <Angus> If there's no header for https://ffmpeg.org/doxygen/3.0/vdpau__h264_8c_source.html
[21:49:10 CEST] <Angus> how can you call av_register_hwaccel(&ff_h264_vdpau_hwaccel) on it from external code?
[21:51:15 CEST] <wm4> you can't
[21:51:42 CEST] <wm4> hwaccels are registered like other codecs etc.
[21:52:23 CEST] <Angus> av_register_all registers the codecs nicely
[21:52:40 CEST] <Angus> but it doesn't seem like it calls av_register_hwaccel at all
[21:53:10 CEST] <fritsch> works for us (in kodi) with ffmpeg 3.0
[21:53:38 CEST] <Angus> oh, totally missed a function call
[21:53:42 CEST] <wm4> Angus: it does, maybe it's just not compiled in
[21:53:42 CEST] <Angus> that solves the mystry.
[21:53:50 CEST] <wm4> or that
[22:07:37 CEST] <rcombs> Angus: by building as a static library and doing `extern AVHWAccel ff_h264_vdpau_hwaccel;` :P
[22:07:49 CEST] <rcombs> (Perian did this for decoders for some reason)
[22:08:14 CEST] <wm4> wat
[22:11:55 CEST] <Angus> rcombs, D:
[22:12:24 CEST] <rcombs> I didn't say it was a good idea
[22:12:45 CEST] <atomnuker> oh hey VP9 finally got a spec officially published
[22:12:58 CEST] <atomnuker> http://www.webmproject.org/vp9/
[22:13:05 CEST] <Angus> I did briefly try that, but realized very quicky that I'd end up including a significant part of FFMpeg into the program I'm building.
[22:15:41 CEST] <Angus> https://ffmpeg.org/pipermail/ffmpeg-user/2012-July/008125.html
[22:15:48 CEST] <Angus> is this still applicable?
[22:16:36 CEST] <Angus> since https://trac.ffmpeg.org/wiki/HWAccelIntro
[22:16:43 CEST] <Angus> seem to indicate otherwise
[22:17:03 CEST] <JEEB> decoders and hwaccels are kind of different
[22:17:14 CEST] <JEEB> one can use a decoder without external initialization or such
[22:17:33 CEST] <JEEB> one cannot use a hwaccel without some sort of special poking to set the ground
[22:18:43 CEST] <Angus> hmmm
[22:18:45 CEST] <Angus> I see
[22:18:47 CEST] <JEEB> ffmpeg (the cli app) has some support for the hwaccels in avcodec
[22:19:12 CEST] <JEEB> but in general they require special code so they're not around in the cli apps
[22:19:49 CEST] <Angus> it does look like this exists:
[22:19:49 CEST] <Angus> https://www.ffmpeg.org/doxygen/3.0/ffmpeg__vdpau_8c_source.html
[22:21:03 CEST] <wm4> yes, it demonstrates most basic API usage
[22:21:43 CEST] <wm4> Angus: it got slightly simpler recently: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg_vdpau.c
[22:21:52 CEST] <wm4> (but uses API not in the 3.0 release, or any release)
[22:22:38 CEST] <Angus> hmmm
[22:24:14 CEST] <Angus> that file seems to be identical to the one found in 3.0's / folder
[22:24:55 CEST] <wm4> consider getting a pair of new eyes
[22:25:09 CEST] <wm4> look e.g. at vdpau_get_buffer
[22:27:49 CEST] <Angus> ah, found my issue
[22:27:50 CEST] <Angus> https://github.com/FFmpeg/FFmpeg/blob/master/ffmpeg_vdpau.c
[22:27:52 CEST] <Angus> is not 3.0
[22:28:16 CEST] <wm4> yes, releases are just outdated snapshots that nobody cares about
[22:28:26 CEST] <wm4> so all branches etc. point not to the release
[22:30:40 CEST] <Angus> I'm may be suffering from the side effects of corperate branch management.
[22:32:59 CEST] <fritsch> wm4: lol
[22:34:14 CEST] <wm4> fritsch: it's true
[22:34:29 CEST] <wm4> on the other hand, master is usually remarkably stable
[22:34:45 CEST] <wm4> we don't even allow incompatible API changes etc.
[22:39:58 CEST] <fritsch> wm4: yeah kodi is always on latest stable ... when filing bugs this one guy always says: reproduce with master ...
[22:40:12 CEST] <fritsch> which is not funny then, if filing bugs for stable releases is not wanted / allowed
[22:40:43 CEST] <wm4> lol
[22:40:58 CEST] <wm4> cehoyos has his own policies anyway
[22:41:32 CEST] <fritsch> for example last time with the aligned buffers
[22:41:42 CEST] <fritsch> that was in no way reproducable with ffmpeg command line
[22:41:54 CEST] <fritsch> so hard to file according to his rules
[22:42:23 CEST] <wm4> "rules"
[22:42:23 CEST] <fritsch> but btw. concerning these aligned buffers. Somehow the docu needs to make clear: if you supply user buffers, make sure that x, y, z
[22:42:28 CEST] <fritsch> which is not documented
[22:42:32 CEST] <wm4> I rarely report bugs because of that
[22:42:51 CEST] <fritsch> we report all of them and when users find new ones ... we let the mreport it
[22:42:52 CEST] <wm4> if I care I try to fix it myself or talk to someone who knows the code in question
[22:43:08 CEST] <fritsch> yeah, that's the short cut, but developers don't always have time
[22:43:20 CEST] <fritsch> and our bugs are often quite special
[23:55:37 CEST] <Angus> wm4: you tested this here: http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6b706ce85fa56564986211b99d34e269066ca3d9
[23:56:00 CEST] <Angus> does vdpau_retrieve_data manage to get the decoded data back from GPU?
[00:00:00 CEST] --- Wed Apr 20 2016