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

[burek]

[01:46:05 CEST] <rrva> in mpeg-ts streams, for a certain GOP, is there anything else than PTS to correlate which audio packets belong to a certain GOP of video frames packets?
[01:50:48 CEST] <cone-557> ffmpeg 03Pavel Nikiforov 07master:413c842a6978: avformat/udp: Add a delay between packets for streaming to clients with short buffer
[01:50:49 CEST] <cone-557> ffmpeg 03Michael Niedermayer 07master:9b7a8bddac52: avformat/udp: redesign threaded udp tx code
[01:50:50 CEST] <cone-557> ffmpeg 03Michael Niedermayer 07master:9591ca704b0e: avformat/udp: Close the socket after destroying the thread using the socket
[02:28:49 CEST] Action: llogan thanks claws-mail for re-downloading 41.5k emails for no reason
[03:42:26 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vr6gl
[03:42:26 CEST] <KGB> 13FFV1/06master 142a4c5ba 15Jérôme Martinez: Multi-threading support and independence of slices...
[04:13:25 CEST] <Compn> llogaaan
[04:13:27 CEST] <Compn> huh
[04:14:06 CEST] Action: Compn will never understand why croatia has .hr tld
[04:15:19 CEST] <durandal_1707> something happened?
[04:31:16 CEST] <bofh_> Compn: (Republika) Hrvatska? I guess either they explicitly wanted native name, or the usual ones were already taken.
[04:54:23 CEST] <Compn> durandal_170 : i was going to ask him why he keeps 40,000 mails on his server for his client to redownload them :D
[04:54:34 CEST] <Compn> [20:28] * llogan thanks claws-mail for re-downloading 41.5k emails for no reason
[04:54:55 CEST] <Compn> also what email server allows that kind of storage
[04:55:08 CEST] <Compn> i think my isp filled up after 300 last time i was on vacation :D
[05:20:55 CEST] <jamrial> Compn: gmail
[12:36:45 CEST] <BtbN> andrey_turkin, when merging to libav, don't get too close on how they handle options.
[12:37:16 CEST] <BtbN> I'm not a fan of that, I'd very much prefer getting closer to how libx264 works, specially for crf.
[12:37:49 CEST] <BtbN> It's entirely non-obvious that one has to use -global_quality to trigger that mode at the moment.
[12:40:20 CEST] <andrey_turkin> oh, why? It seemed pretty nice to me
[12:40:33 CEST] <andrey_turkin> maybe ratecontrol stuff is a bit weird
[12:40:55 CEST] <BtbN> Primarily because it breaks compatiblity.
[12:41:05 CEST] <andrey_turkin> ah, that )
[12:41:13 CEST] <andrey_turkin> yeah, totally would break
[12:41:35 CEST] <BtbN> People are used to to libx264, and staying close to that was my original idea.
[12:42:06 CEST] <andrey_turkin> I'll have to rework those patches then later
[12:42:46 CEST] <BtbN> I'm not entirely sure anymore how it ended up using avctx->global_quality for crf/constqp mode, but a crf parameter that matches the libx264 one might be something to add later.
[12:42:50 CEST] <andrey_turkin> though I'm not a big fan of how it used to be. Too fragile and interconnected
[12:43:15 CEST] <andrey_turkin> actually crf/constqp code seemed similar in both libav and ffmpeg
[12:43:24 CEST] <andrey_turkin> vbr is different
[12:43:37 CEST] <BtbN> yes, except that you have to specify -rc constqp for it
[12:43:42 CEST] <BtbN> instead of just -global_quality
[12:44:04 CEST] <andrey_turkin> I think you don't need to specify rc, it should do the right thing
[12:44:15 CEST] <andrey_turkin> in both libav and ffmpeg code as is
[12:44:53 CEST] <BtbN> ah, they have that only to override it, if the automagic decision which mode to use fails.
[12:45:03 CEST] <andrey_turkin> yeah
[12:45:23 CEST] <BtbN> That doesn't seem too bad. If it's possible to add it in a way that doesn't break existing commandlines, it would be nice to have.
[12:45:57 CEST] <andrey_turkin> actually no. If you specify -rc then it is forced to use that. If you don't specify it then it does autodecision
[12:46:45 CEST] <andrey_turkin> I can try to rework those patches to have both -rc and ffmpeg's cbr/twopass options
[12:48:38 CEST] <BtbN> Didn't find any problems with your first chunk of patches, as far as I can test on my Kepler hardware. Did some minor formatting fixes to make patcheck happy, otherwise unmodified.
[12:49:01 CEST] <andrey_turkin> I just pushed the rest.
[12:49:04 CEST] <BtbN> Do you want to change something, or can I push them?
[12:49:15 CEST] <andrey_turkin> Let me see one more time
[12:49:44 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commits/master
[12:50:59 CEST] <andrey_turkin> ah, those 4. I am happy with thouse
[12:51:35 CEST] <BtbN> And one small change on top, rebasing on it should be trivial.
[12:51:46 CEST] <andrey_turkin> I actually have some doubts about nvenc registration cache but it is from libav code
[12:52:38 CEST] <BtbN> I'm not so sure anymore if a 100% merge is desirable. Just focus on the stuff that seems like a good idea to have for now, don't aim to have the exact same code in the end.
[12:53:15 CEST] <cone-803> ffmpeg 03Andrey Turkin 07master:82d705e24505: avcodec/nvenc: split large functions into smaller ones
[12:53:16 CEST] <cone-803> ffmpeg 03Andrey Turkin 07master:e1691c44f045: avcodec/nvenc: combine input and output surface structures
[12:53:17 CEST] <cone-803> ffmpeg 03Andrey Turkin 07master:cfb49fc6f797: avcodec/nvenc: replace custom FIFOs with AVFifos
[12:53:18 CEST] <cone-803> ffmpeg 03Andrey Turkin 07master:a8cf25dd9233: avcodec/nvenc: CUDA frames support
[12:53:19 CEST] <cone-803> ffmpeg 03Timo Rothenpieler 07master:24fcb2335184: avcodec/nvenc: Require Maxwell for lossless
[12:57:28 CEST] <andrey_turkin> I was aiming for 100% merge when doing the rest of the patches (as obvious from first "rename" commit). I can go throuth the patches again and probably can rework most of them so they make code nicer (or bring code closer to libav) while not breaking compatibility
[12:58:39 CEST] <andrey_turkin> anyway, you can fetch my branch and compare it to libav; rest of the stuff there are changes I'm not sure about how to handle. Some of that difference should probably go to libav
[14:18:27 CEST] <BtbN> I really need to setup some automated tests for nvenc.
[14:18:39 CEST] <BtbN> I guess fate tests are just fine, they only need a special machine to run on.
[14:26:49 CEST] <nevcairiel> unfortunately testing something like this in fate is .. problematic, because you cant really test the precondition of hardware existing
[14:31:08 CEST] <andrey_turkin> funny fact - apparently swscale nv12-nv12 without any actual scaling is broken, and apparently have been for some time
[14:31:22 CEST] <BtbN> shouldn't it just.. do nothing?
[14:31:26 CEST] <andrey_turkin> it should
[14:31:46 CEST] <andrey_turkin> or rather it should copy data around
[14:31:48 CEST] <nevcairiel> now that you mention it, i noticed that a long time ago as well
[14:31:54 CEST] <nevcairiel> never really bothered to test again tho
[14:32:13 CEST] <BtbN> I really need to get myself new hardware...
[14:32:19 CEST] <BtbN> not being able to test most of this is annoying
[14:32:48 CEST] <andrey_turkin> instead it copies Y plane and fills UV plane with zeros. Something to do with wrongly assuming it is a GRAY8 or something
[14:32:49 CEST] <nevcairiel> buy pascal, so you can get hevc10 encoding going =p
[14:32:49 CEST] <BtbN> Maybe I'll get my Christmas present "slightly" early this year.
[14:32:59 CEST] <BtbN> Yes, I will get myself a 1080
[14:33:11 CEST] <BtbN> But for Christmas, which is still half a year
[14:33:47 CEST] <BtbN> I'm also still hoping for Intel to get Kaby Lake out, so I can add VAAPI hevc10 stuff as well.
[14:34:18 CEST] <andrey_turkin> I got me GTX 960 last Christmas and I was happy; latest hardware and stuff. And then they went ahead and presented entire new generation (
[14:34:41 CEST] <BtbN> at least you got the 2nd gen Maxwell
[14:34:49 CEST] <andrey_turkin> yeah, that's good
[14:34:50 CEST] <BtbN> 960 is better than 970/980
[14:34:54 CEST] <BtbN> for video stuff
[14:35:01 CEST] <andrey_turkin> it was like 2 times cheaper too
[14:35:16 CEST] <BtbN> kinda silly how the 970/980 are able to hw-encode HEVC, but can't decode it.
[16:04:19 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vri9f
[16:04:19 CEST] <KGB> 13FFV1/06master 149c92e4b 15Jérôme Martinez: Byte alignment is made explicit...
[16:23:00 CEST] <philipl> BtbN: Are you looking at those nvenc cuda patches?
[16:23:21 CEST] <philipl> I see they've just been pushed :-)
[16:33:13 CEST] <cone-803> ffmpeg 03foo86 07master:72a9a7e9cbc2: avcodec/dca_exss: prepare to be called from parser context
[16:33:14 CEST] <cone-803> ffmpeg 03foo86 07master:cb55c5b49e6d: avcodec/dca_parser: set duration for core-less streams
[16:33:15 CEST] <cone-803> ffmpeg 03James Almer 07master:493db04c4e49: avcodec/Makefile: add missing dependencies to dca parser
[16:36:29 CEST] <kierank>     {"txt_duration",    "display duration of teletext pages in msecs",       OFFSET(sub_duration),   AV_OPT_TYPE_INT,    {.i64 = 30000},    0, 86400000, SD},
[16:36:30 CEST] <kierank> ???
[16:36:38 CEST] <kierank> why 30 seconds
[16:41:14 CEST] <andrey_turkin> somebody probably decided under normal conditions each page would be retransmitted somehow more frequenct than 30 seconds
[16:43:15 CEST] <kierank> ok
[16:44:17 CEST] <andrey_turkin> which is a reasonable default for subtitles (you don't want subtitle to be on the screen forever if commands stop coming in)
[16:49:11 CEST] <cone-803> ffmpeg 03Matthieu Bouron 07master:fbc9359d859f: lavc/mediacodec: factorize static fields initialization
[16:49:12 CEST] <cone-803> ffmpeg 03Matthieu Bouron 07master:d14deeb6bcf4: lavc/mediacodec: add missing MediaCodec.Get{Input,Output}Buffer() checks
[16:53:56 CEST] <JEEB> hmm, I wonder if this improves some stuff
[16:53:59 CEST] <JEEB> for fallbacks
[17:04:50 CEST] <mateo`> JEEB: I don't think it will improve things in this matter
[17:05:12 CEST] <JEEB> ok
[17:05:25 CEST] <JEEB> so I guess the best way would be to create profile checks in the AVC decoder
[17:06:44 CEST] <mateo`> I'll send a patch later that removes the arbitrary resolution limit of the decoders
[17:07:40 CEST] <mateo`> As it's totally arbitrary and hardcoded somewhere on the system
[17:08:31 CEST] <mateo`> I should also try to export which profiles an encoder support (this might help regarding fallbacks)
[17:09:15 CEST] <BtbN> philipl, there's more work on the way, essentialy a merge of the libav and ffmpeg nvenc implementations.
[17:10:06 CEST] <mateo`> I will have some time to work it next week (and port the decoder to the new bsf api, update the hwaccel patch, ...)
[17:12:22 CEST] <BtbN> philipl, and I'm also planning to add a cuvid hwaccel, but that might take a while
[17:13:27 CEST] <andrey_turkin> BtbN: what will it give in terms of gains?
[17:13:45 CEST] <BtbN> full hw transcode on nvidia hardware, without the frames ever leaving the vram
[17:15:06 CEST] <BtbN> and also accelerated video decoding on nvidia hardware without a running X server.
[17:15:15 CEST] <BtbN> As vdpau needs X
[17:16:49 CEST] <andrey_turkin> right. I wondered a bit if it may be more lucrative to take a stab at d3d11va/dxva/vdpau->cuda interop; but in the end it probably would mean more work than one more decoder
[17:17:02 CEST] <BtbN> The stupid thing is, cuvid only comes with a h264 NAL parser on windows.
[17:17:09 CEST] <BtbN> So it can't be a simple decoder.
[17:17:11 CEST] <andrey_turkin> and it won't help with headless linux
[17:17:20 CEST] <BtbN> It has to be another hwaccel like vdpau and vaapi are.
[17:17:27 CEST] <BtbN> as ffmpeg has to do the h264 parsing
[17:21:43 CEST] <cone-803> ffmpeg 03Muhammad Faiz 07master:defab0825f41: avfilter/src_movie: add various commands
[17:27:37 CEST] <andrey_turkin> BtbN: Here are some reworked patches which should be ready for inclusion in ffmpeg: https://github.com/tea/FFmpeg/tree/nvenc .
[17:31:04 CEST] <philipl> BtbN: Jolly good. In that context, it's probably worth revisting the patches from Agatha eventually, as you'll have the infrastructure to do it properly
[17:31:35 CEST] <BtbN> i think those will be obsolete then, as these features are already present.
[17:35:12 CEST] <philipl> The cuda scaling is?
[17:35:32 CEST] <BtbN> there are patches for libav somewhere that add those filters
[17:35:39 CEST] <BtbN> and I think they are planned to be merged
[17:36:00 CEST] <philipl> cool beans.
[17:38:35 CEST] <andrey_turkin> isn't scale_npp already merged?
[19:23:09 CEST] <kierank> BBB: http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=111296
[19:24:37 CEST] <JEEB> yeah, it's not surprising that companies are looking into VP9 given the HEVC landscape being so weird
[19:27:19 CEST] <BBB> I should go and be good friends with many of these people ;)
[19:28:28 CEST] <jamrial> seeing how they are complaining about encoding speeds, you should :p
[19:28:31 CEST] <BBB> is brightcove what used to be known as zencoder?
[19:29:22 CEST] <kierank> brightcove bought zencoder
[19:30:31 CEST] <BBB> aha I see
[19:33:58 CEST] <jamrial> what's the deal with this AV1? and will it replace VP10 or live alongside it as a derived format like sorenson 3 seems to be for h264?
[19:34:23 CEST] <RiCON> av1 is a mix of thor + vp10 + daala
[19:34:52 CEST] <jamrial> so it will live alongside all those instead?
[19:34:59 CEST] <nevcairiel> perhaps
[19:35:01 CEST] Action: jamrial is reminded of a certain xkcd strip
[19:35:10 CEST] <nevcairiel> the dalaa people said they will use dalaa more as a testbed for now
[19:35:27 CEST] <nevcairiel> not sure how vp10 people see that
[19:48:10 CEST] <rcombs> call me back when something has an encoder that actually competes with x264
[19:48:27 CEST] <rcombs> or when hardware encoders aren't bad
[19:49:26 CEST] <BBB> I think we had this discussion on #x264dev a while ago
[19:49:47 CEST] <BBB> on the high end, which is where netflix arguably lives (computing time is essentially free), hevc/vp9 clearly beat h264
[19:49:56 CEST] <BBB> especially at high resolutions
[19:50:11 CEST] <JEEB> the formats beating AVC isn't a surprise to anyone, really
[19:50:19 CEST] <rcombs> well sure
[19:50:24 CEST] <BBB> x264 competes well on the end where computing time is expensive
[19:50:24 CEST] <JEEB> the psychovisual optimizations for libvpx on the other hand...
[19:50:30 CEST] <rcombs> ^
[19:50:51 CEST] <rcombs> and on psy
[19:50:55 CEST] <JEEB> basically, I'm OK with 0.1fps if the result is good and the rate control isn't bad
[19:50:59 CEST] <JEEB> which I think BBB's encoder does
[19:51:01 CEST] <BBB> libvpx != vp9, as awesome developers of competing, commercial vp9 encoders would no-doubt say
[19:51:21 CEST] <JEEB> yes, which is why I specified that the formats beating AVC isn't a surprise
[19:51:33 CEST] <JEEB> the thing that people have currently for VP9 is libvpx though, which is what it is
[19:53:24 CEST] <jamrial> BBB: so i take your encoder, much like your decoder, is also replicating libvpx bugs that sneaked into the bitstream, right?
[19:53:39 CEST] <BBB> hm & well ...
[19:53:40 CEST] <BBB> so ...
[19:54:14 CEST] <BBB> most of these bugs are in obscure corners of the bitstream that were either sneaked in to make third parties happy, or as palceholders for unfinished features
[19:54:35 CEST] <BBB> if they were sneaked in to make third parties happy, like the whole scalable mess, I just dont support it, because nobody cares
[19:54:51 CEST] <BBB> if theres bugs in unfinished placeholders for features, then & well & its hard to say what I would do
[19:55:05 CEST] <jamrial> i see
[19:55:06 CEST] <BBB> I mean, I could reproduce the bug, but likely that makes the placeholder useless
[19:55:19 CEST] <BBB> theres a few bugs that are in the base bitstream that I reproduce, yes
[19:55:33 CEST] <BBB> I mean, I dont have a choice, otherwise the files would not decode
[19:55:44 CEST] <BBB> but mostly these are innocent and have no coding impact, theyre just silly
[19:58:58 CEST] <Compn> werent we skipping vp* and going for hevc? :P
[19:59:00 CEST] Action: Compn ducks
[20:00:50 CEST] <andrey_turkin> apparently hevc is old news now )
[20:04:17 CEST] <jamrial> Compn: patents happened, it seems. but hevc isn't dead, knowing it's used for broadcasting and uhd blu ray
[20:06:44 CEST] <andrey_turkin> people are conservative. I've seen something that wasn't MPEG4 or AVC (with 4:2:0 JPEG pixelformat) 2 or 3 times in the last two years
[20:07:57 CEST] <andrey_turkin> I mean MPEG colorspace. And one of those 2 or 3 times was same old AVC just with JPEG colorspace
[20:10:30 CEST] <Compn> andrey_turkin : you havent seen webm ? 
[20:10:46 CEST] <BBB> some people just dont watch youtube :-p
[20:10:50 CEST] <Compn> i guess :P
[20:10:51 CEST] <BBB> or they watch it on internet explorer
[20:10:54 CEST] <Compn> hue hue hue
[20:11:10 CEST] <andrey_turkin> well I mostly work with broadcasting but OTT translations I've seen were in AVC as well
[20:11:28 CEST] <andrey_turkin> I guess in VoD domain things might be different
[20:12:46 CEST] <andrey_turkin> but then there is youtube and...? any other major providere does vp8/vp9?
[20:13:09 CEST] <BBB> that article mentions a few
[20:13:21 CEST] <BBB> kierank: wasnt there a streamingmedia.com conference or so?
[20:13:24 CEST] <BBB> what was that again
[20:13:33 CEST] <kierank> there are loads of those
[20:13:38 CEST] <kierank> not very technical imo
[20:14:00 CEST] <BBB> any useful ones?
[20:15:22 CEST] <kierank> nothing on par with vdd
[20:15:43 CEST] <kierank> but you should probably go to streamingmedia blah blah
[20:16:34 CEST] <BBB> well, look, I should go to both
[20:16:56 CEST] <BBB> the problem (between quotes for a good reason) with vdd is that its not very suitable for corporate software like my encoder (and it shouldnt be)
[20:17:09 CEST] <BBB> I think its good to keep vdd intentionally focussed on opensource
[20:17:48 CEST] <kierank> I know, i'm just saying there aren't conferences at the same technical level as vdd
[20:18:01 CEST] <kierank> there are in other related fields (siggraph etc)
[20:18:12 CEST] <kierank> but multimedia seems to have a lot of blah blah and not much technical stuff
[20:18:59 CEST] <BBB> its easy to blah blah with a madonna video in the background
[20:19:09 CEST] <BBB> nobody pays attention to the blah blah because oooo soooo awesooooome
[20:22:27 CEST] <BBB> I did get a comment once, that someone liked my marketing material because it didnt contain the characters 50%
[20:33:41 CEST] <JEEB> BBB: yeah... those numbers come up so many goddamn times I'm surprised more people haven't noticed that it's a theoretical figure
[20:46:34 CEST] <rcombs> so apparently some versions of mingw-w64 (no clue which) open files in mkstemp() with `_O_TEMPORARY`
[20:47:03 CEST] <rcombs> ar proceeds to close that fd and open a new one at the same path
[20:47:11 CEST] <rcombs> lovely race condition there
[20:47:14 CEST] <JEEB> oh yeah
[20:47:17 CEST] <JEEB> I think I know that one :P
[20:48:06 CEST] <rcombs> got a sane solution?
[20:48:37 CEST] <rcombs> I was planning to (make somebody else) rebuild binutils with ar patched to reopen the file without `_O_TEMPORARY` and then close the original fd
[20:48:40 CEST] <JEEB> not really
[20:48:58 CEST] <rcombs> q why is mingw so bad
[20:51:40 CEST] <BBB> oh god I just saw a youtube video and it looked so grossly poorly compressed I wanted to kill myself
[20:51:45 CEST] <BBB> I right-clicked, and it was avc1 :-p
[20:52:00 CEST] <JEEB> well youtube eff's everything
[20:52:01 CEST] <rcombs> at least it's not random webms on sankaku or 4chan
[20:52:03 CEST] <JEEB> be it AVC or VP9
[20:52:57 CEST] <iive> rcombs: i don't understand, why both temp files race condition. isn't mkstemp supposed to generate different names for the open files?
[20:53:43 CEST] <rcombs> iive: right, but ar closes the fd it gets from mkstemp and reopens at the same path
[20:53:59 CEST] <rcombs> so since mkstemp opens with _O_TEMPORARY, the file is deleted on close
[20:54:04 CEST] <rcombs> (WTF?)
[20:54:28 CEST] <rcombs> so if another mkstemp happens between that close and the subsequent open, you're fucked
[20:54:52 CEST] <rcombs> the worst part being that both processes think everything's fine until they try to rename later
[20:55:15 CEST] <rcombs> also apparently ar doesn't seed rand() with anything useful
[20:57:24 CEST] <JEEB> :D
[20:57:39 CEST] <JEEB> "waiter, where is my whiskey!?"
[21:01:04 CEST] <iive> so, there are actually 2 separate problems. using _O_TEMPORARY that deletes file at close and having bad rand that generates same pattern.
[21:02:43 CEST] <durandal_1707> libavar
[21:09:19 CEST] <rcombs> iive: well rand() is supposed to generate the same pattern for the same seed
[21:09:35 CEST] <rcombs> and ar apparently doesn't seed it at all, so I'd imagine there's some fixed default (0?)
[21:09:56 CEST] <iive> that's patently bad idea.
[21:10:24 CEST] <rcombs> not seeding?
[21:11:15 CEST] <rcombs> the docs don't specify what RNG function mkstemp() uses, so the application developer can't know what they're supposed to seed
[21:11:26 CEST] <iive> "If no seed value is provided, the rand() function is automatically seeded with a value of 1."
[21:11:49 CEST] <rcombs> but it shouldn't matter since mkstemp() retries until it hits a file that doesn't already exist
[21:12:14 CEST] <rcombs> (or until the int storing the number of tries overflows, but that's not especially likely)
[21:12:46 CEST] <iive> well, if int overflows.. you might not have space in the directory for more files :D
[21:13:41 CEST] <rcombs> yeah
[21:13:53 CEST] <rcombs> and then whether or not rand() is seeded isn't really relevant
[21:19:25 CEST] <iive> it's quite relevant, if you run two ar in parallel... 
[21:19:54 CEST] <Plorkyeran> that should only make it slower
[21:20:05 CEST] <Plorkyeran> you have to handle collisions regardless of whether or not you properly seed it
[21:24:28 CEST] <iive> if we assume that ar are running in perfect sync, then both mkstemp would make the check for existence at the same time and then attempt to create it at the same time.
[21:25:02 CEST] <iive> unless windows have flag that makes file creating fail if the file already exists
[21:32:20 CEST] <rcombs> iive: O_CREAT + O_EXCL does that
[21:33:39 CEST] <iive> mkstemp does mention that it does use the exclusive flag.
[22:30:31 CEST] <andrey_turkin> BtbN: where should I send a CUDA-related patch if it is meant for both libav and ffmpeg? just libav-devel, just ffmpeg-devel, both?
[22:31:00 CEST] <BtbN> I'd say both.
[22:31:10 CEST] <andrey_turkin> ok
[22:31:29 CEST] <BtbN> The CUDA stuff in ffmpeg doesn't realy have a maintainer though, as it was just merged from libav.
[22:31:43 CEST] <BtbN> I'll try to have a look at it
[22:31:59 CEST] <Compn> make sure you mention that it was sent to both
[22:32:09 CEST] <andrey_turkin> ah, ok
[22:32:11 CEST] <Compn> sometimes devs get weird ideas ... and fail to cooperate
[22:32:27 CEST] <Compn> then code differs between projects for idiot reasons
[22:32:42 CEST] <Compn> then we have two decoders for the same codec hah!
[00:00:00 CEST] --- Thu May 26 2016