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

[burek]

[01:12:34 CEST] <cone-824> ffmpeg 03Michael Niedermayer 07master:51080dfa0843: avcodec/s302m: Check for non PCM Streams
[01:12:35 CEST] <cone-824> ffmpeg 03Michael Niedermayer 07master:42c41e96ff6d: avformat/utils: Do not select audio streams with unknown sample rate in av_find_best_stream()
[01:12:36 CEST] <cone-824> ffmpeg 03Michael Niedermayer 07master:802cca5905ab: avcodec/s302m: Only set the sample rate when some data is output
[02:50:20 CEST] <cone-824> ffmpeg 03Michael Niedermayer 07master:f07376402cdd: avformat/mxfenc: Add mxf muxer avclass
[10:08:23 CEST] <ubitux> michaelni: i prefer our version from 81a91269a2fbeb87de53e395c6bed0c70c310cae
[10:08:38 CEST] <ubitux> assuming it doesn't lack anything, i'd prefer if we keep ours when you'll merge the one from luca
[10:09:40 CEST] <ubitux> you might want to take the doxy part
[12:14:52 CEST] <cone-604> ffmpeg 03Clément BSsch 07master:be1862ffb06a: doc/filters: fix inaccuarte/inaccurate typo
[12:17:15 CEST] <cone-604> ffmpeg 03Clément BSsch 07master:c5a08956a3b1: swresample: fix initilaize/initialize typo
[12:50:16 CEST] <kierank> can someone pm me the incoming read password
[12:51:43 CEST] <cone-604> ffmpeg 03Stephan Holljes 07master:aa74401af8a4: lavf/http: Document method option.
[12:51:44 CEST] <cone-604> ffmpeg 03Stephan Holljes 07master:bbcee92b6d59: lavf/http: Process HTTP header before sending response.
[12:51:45 CEST] <cone-604> ffmpeg 03Stephan Holljes 07master:8cfaa76a5e77: lavf/http: Rudimentary error handling for HTTP requests received from clients.
[12:51:46 CEST] <cone-604> ffmpeg 03Stephan Holljes 07master:a7e7c68b0e26: lavf/http: Properly process HTTP header on listen.
[12:51:47 CEST] <cone-604> ffmpeg 03Stephan Holljes 07master:290b23755673: lavf/http: Indent else-clause.
[12:51:48 CEST] <cone-604> ffmpeg 03Stephan Holljes 07master:44d19212008e: lavf/http: Add simple autodetection for client HTTP method, based on AVIO_FLAG_READ.
[12:51:49 CEST] <cone-604> ffmpeg 03Michael Niedermayer 07master:7897ed0d3cb9: Merge remote-tracking branch 'cigaes/master'
[12:53:42 CEST] <kierank> cehoyos: ping, you definitely know
[13:16:31 CEST] <cone-604> ffmpeg 03Ronald S. Bultje 07master:ade5684cda9c: hevc: fix typo (mpv -> mvp).
[13:17:43 CEST] <kierank> lol
[13:18:37 CEST] <cone-604> ffmpeg 03Clément BSsch 07master:0f6118c58169: ffplay: use av_clip() instead of nested min & max
[13:18:38 CEST] <cone-604> ffmpeg 03Clément BSsch 07master:622ef80e3f5f: avcodec/mpegvideo: use av_clip() instead of nested min & max
[13:18:39 CEST] <cone-604> ffmpeg 03Clément BSsch 07master:533c37db8ddb: avcodec/snowenc: use av_clip() instead of nested min & max
[13:18:40 CEST] <cone-604> ffmpeg 03Clément BSsch 07master:272f87fc5ca9: avdevice/x11grab: use av_clip() instead of nested min & max
[13:26:14 CEST] <cehoyos> kierank: ?
[13:26:19 CEST] <kierank> never mind
[13:26:23 CEST] <kierank> 11:50 AM <"kierank> can someone pm me the incoming read password
[13:26:38 CEST] <cehoyos> Sorry, missed it...
[13:26:43 CEST] <cehoyos> Which sample are you interested in?
[13:26:49 CEST] <kierank> elemental one
[13:26:52 CEST] <kierank> but it's corrupt still
[13:27:06 CEST] <cehoyos> Yes.
[13:33:39 CEST] <cehoyos> michaelni: https://trac.videolan.org/vlc/ticket/14811 J-B thinks this is a regression in FFmpeg, I cannot test vlc atm, not reproducible with ffmpeg.
[13:48:54 CEST] <michaelni_> cant reprodue with the vlc ive here
[13:49:13 CEST] <michaelni_> but thats some random git version not 2.2.1
[13:56:11 CEST] <BtbN> Are the RGB to YUV functions this guy on the ml is trying to improve even used anywhere?
[13:56:47 CEST] <kierank> michaelni_: i reported that bug to you
[13:56:52 CEST] <kierank> and a fix
[13:56:57 CEST] <kierank> it has been fixed iirc
[13:59:18 CEST] Action: michaelni_ doesnt remember exactly but if it has been fixed thats good, anything i should backport ?
[14:02:44 CEST] <kierank> https://trac.ffmpeg.org/ticket/4533
[14:02:48 CEST] <kierank> michaelni_: it's that
[14:06:46 CEST] <michaelni_> ok, this only affects 2.6 and fix is already in 2.6.3, vlc 2.2.1 uses a fixed hash based checkout from master it seems
[14:08:29 CEST] <wm4> "ffmpeg -i somefilewithaac.mkv -c:a copy -f spdif out.raw" fails with "Wrong AAC file format"
[14:08:53 CEST] <wm4> so apparently ffmpeg's aac parser uses a different format than spdifenc expects?
[14:09:48 CEST] <nevcairiel> i never tried to use aac over spdif, what devices accept that?
[14:09:49 CEST] <wm4> so if you use ffmpeg's aac encoder
[14:10:05 CEST] <wm4> nevcairiel: I have no idea, and I was curious to see what my receiver does with it
[14:10:23 CEST] <nevcairiel> it needs ADTS, apparently
[14:10:36 CEST] <nevcairiel> thats what the code wants, at least
[14:12:02 CEST] <wm4> there's only a aac_adtstoasc BSF
[14:12:21 CEST] <kierank> use the adts mux
[14:12:21 CEST] <nevcairiel> there is a adts muxer
[14:12:31 CEST] <wm4> can ffmpeg chain that?
[14:12:34 CEST] <kierank> no
[14:12:47 CEST] <kierank> ffmpeg cannot chain anything afaik
[14:12:51 CEST] <kierank> apart from some tricks in rtp
[14:13:01 CEST] <nevcairiel> some formats do that automatically, ie. try to mux raw aac into mpegts, and it'll automatically use the adts muxer to convert it
[14:13:09 CEST] <nevcairiel> but there is no generic chaining support
[14:13:52 CEST] <rcombs> does segment count
[14:14:40 CEST] <wm4> ok let's try what the receiver does with it
[14:15:06 CEST] <nevcairiel> i suppose some may support it, considering that there is a spec for it
[14:15:19 CEST] <rcombs> and ff_write_chained is a thing
[14:15:22 CEST] <rcombs> of some kind
[14:15:32 CEST] <rcombs> (but it's not what mpegtsenc uses)
[14:15:51 CEST] <nevcairiel> mpegtsenc does it manually, since it needs the output itself
[14:16:04 CEST] <nevcairiel> write_chained works for things like segment, where you dont need the output
[14:16:16 CEST] <rcombs> not sure which is the case for spider
[14:16:19 CEST] <rcombs> *spdif
[14:16:30 CEST] <nevcairiel> it would need th mpegts way
[14:16:40 CEST] <rcombs> ~yay~
[14:16:57 CEST] <nevcairiel> its really not that bad
[14:17:07 CEST] <nevcairiel> just no "official" API to do that easily
[14:17:28 CEST] <rcombs> wonder if it'd be worth having if we wanted it for spdif
[14:17:46 CEST] <rcombs> (except as far as I'm aware nobody cares about AAC in SPDIF so&)
[14:17:51 CEST] <nevcairiel> yeah
[14:17:57 CEST] <nevcairiel> i dont think i was ever asked
[14:18:07 CEST] <nevcairiel> i think more people asked me about DSD over HDMI than AAC
[14:18:10 CEST] <nevcairiel> so ...
[14:18:14 CEST] <rcombs> wm4: something sounding rather unpleasant?
[14:18:26 CEST] <rcombs> nevcairiel: how even
[14:18:31 CEST] <rcombs> (same way SPDIF works?)
[14:18:54 CEST] <nevcairiel> how wah
[14:18:54 CEST] <wm4> the receiver is just sitting there and pretends not to receive any data
[14:19:00 CEST] <cehoyos> nevcairiel, kierank: Please elaborate, I am tired and drunk and I would really, really like to understand!
[14:19:18 CEST] <nevcairiel> HDMIs compressed format support works the same way as SPDIF, ie. the same transmission protocol is used
[14:19:29 CEST] <nevcairiel> HDMI just supports a bunch higher-bandwidth modes for HD audio formats
[14:19:31 CEST] <cehoyos> Could you explain the sample you just uploaded?
[14:19:46 CEST] <nevcairiel> its the sample the guy tried to upload to the ftp
[14:19:53 CEST] <nevcairiel> well, shortended a bit to get below 2.5mb
[14:19:56 CEST] <cehoyos> Why do you have it?
[14:20:02 CEST] <cehoyos> (Sorry, I am really just tired.)
[14:20:12 CEST] <nevcairiel> Because I directed him to report it to ffmpeg =p
[14:20:18 CEST] <cehoyos> Ok.
[14:20:19 CEST] <cehoyos> Sorry.
[14:20:25 CEST] <nevcairiel> I send all the people here when they report problems to me xD
[14:21:00 CEST] <nevcairiel> original sample is also here: http://www.mediafire.com/watch/s76856vq2jnx7i5/test_bref.mp4
[14:21:17 CEST] <nevcairiel> the one i uploaded cuts away audio and 5 seconds of video or so
[14:21:25 CEST] <nevcairiel> but the issue is clearly visible anyway
[14:21:36 CEST] <cehoyos> It is a regression.
[14:21:52 CEST] <cehoyos> And your sample is of course much "better" than a longer one.
[14:21:55 CEST] <nevcairiel> not sure, i didnt bother to check older versions
[14:21:55 CEST] <cehoyos> (At least imo)
[14:22:02 CEST] <cehoyos> I did.
[14:22:05 CEST] <nevcairiel> I only checked other decoders, and those work
[14:26:24 CEST] <nevcairiel> in unrelated news, android's exoplayer supports matroska files with h264+opus now, and it got a wrapper for a libopus decoder when no opus hardware support is present, i should really try to use opus now instead of the native aac encoder :d
[14:26:48 CEST] <wm4> sounds pretty nice
[14:26:59 CEST] <wm4> does that mean opus is allowed in webm now? (not that this means much)
[14:27:09 CEST] <nevcairiel> thats been allowed a while now
[14:27:16 CEST] <nevcairiel> vp8/vp9 + vorbis/opus
[14:27:55 CEST] <wm4> apropos webm, did they specify how alpha transparency works yet? (for ages there have been 3 different ways)
[14:28:05 CEST] <nevcairiel> until recently, the exoplayer webm reader didnt allow generic matroska files though, just a couple days ago it learned how to handle matroska with h264 and aac/ac3 audio .. and of course vorbis/opus, since those were supported for webm
[14:28:38 CEST] <nevcairiel> matroska is a odd format for streaming though, but it may just work!
[14:35:05 CEST] <cone-604> ffmpeg 03Michael Niedermayer 07master:440fa7758b68: Changelog: Drop duplicate NVENC entry
[14:43:06 CEST] <nevcairiel> that is one old regression
[14:44:05 CEST] <cehoyos> I was actually one commit wrong, the one I mention is missing the asm file...
[14:48:11 CEST] <cehoyos> Darwin award: http://tirol.orf.at/news/stories/2714860/ (German)
[15:53:16 CEST] <wm4> "If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel at ffmpeg.org)"
[15:53:26 CEST] <wm4> except this file is on sampels.ffmpeg.org
[15:53:29 CEST] <wm4> *samples
[15:55:07 CEST] <cehoyos> ftp upload.ffmpeg.org works fine here...
[15:55:32 CEST] <cehoyos> You cannot upload files to samples.ffmpeg.org
[15:55:34 CEST] <cehoyos> ?
[15:55:39 CEST] <wm4> who said that
[15:57:16 CEST] <cehoyos> You can connect to samples.ffmpeg.org (which may be a bug) but you are not allowed to upload there via anonymous ftp.
[15:59:41 CEST] <wm4> maybe you should read again what I wrote
[16:00:07 CEST] <wm4> it prints this warning for a file which is already somewhere on samples.ffmpeg.org
[16:00:13 CEST] <wm4> so what's the point of that warning
[16:00:24 CEST] <cehoyos> I fail to understand you, sorry.
[16:00:30 CEST] <cehoyos> Which file are you talking about?
[16:00:43 CEST] <cehoyos> And I agree that if we request samples that we don't need, it is a bug
[16:01:11 CEST] <wm4> http://samples.ffmpeg.org/evob/Subtitle-sample.evo
[16:01:13 CEST] <cehoyos> Bug as you certainly know, the only solution that makes sense is to fix the bug by submitting a patch that removes the request for the given case.
[16:03:28 CEST] <cehoyos> Ranting here (and as you know, I also like rants from time to time) makes no sense in this case.
[16:12:12 CEST] <Compn> wm4 : we need more samples, unless you think we have enough ?
[16:13:16 CEST] <cehoyos> wm4: I will commit later, gtg, sorry.
[16:13:34 CEST] <Compn> obviously just not that sample that we already ahve ;p
[17:08:41 CEST] <cone-604> ffmpeg 03James Almer 07master:1b4dd59e5fbd: configure: improve the checks for gmtime_r and localtime_r
[18:03:05 CEST] <cone-604> ffmpeg 03Paul B Mahol 07master:a03b69478b7f: avcodec/exr: fix crash caused by merge
[19:12:55 CEST] <wm4> ah, so we have nvenc_a.c and nvenc_b.c
[19:12:58 CEST] <wm4> just so absurd
[19:14:41 CEST] <jamrial> and nvenc_b is based on nvenc_a, but with some differences and a new name
[19:14:52 CEST] <cone-604> ffmpeg 03Michael Niedermayer 07master:7944b0ce94bc: avutil/colorspace: Remove RGB_TO_Y/U/V
[19:21:08 CEST] <philipl> jamrial: but without proper credit, of course.
[19:23:32 CEST] <jamrial> no, they did give credit, at least. their commit says it's "Partially based on the work of Timo Rothenpieler"
[19:23:44 CEST] <philipl> But not in the file.
[19:24:10 CEST] <philipl> So the copyright statement is dubious at best.
[19:24:22 CEST] <nevcairiel> wm4: send a patch to the ML to remove the new one and rename the original back, i would support it
[19:25:10 CEST] <philipl> Michael asked Timo what he wanted to do and he said drop theirs and see what might be beneficial to backport.
[19:25:17 CEST] <wm4> would result in a useless flame
[19:25:48 CEST] <philipl> who would flame? I don't think anyone is arguing for it to stay.
[19:26:11 CEST] <wm4> what nevcairiel suggested
[19:26:32 CEST] <nevcairiel> not sure anyone would have a reason to flame
[19:26:40 CEST] <philipl> That's what I mean.
[19:26:54 CEST] <nevcairiel> except maybe michael, since it may make future merges harder if libav works on theirs =p
[19:27:00 CEST] <philipl> No one wants this around. The only question is what's the best way to deal with it in the long term.
[19:27:11 CEST] <philipl> Michael merged it for that reason but he's not wedded to it.
[19:28:03 CEST] <philipl> Has libav ever merged anything back properly? As opposed to gratuitous rewrites?
[19:28:20 CEST] Action: michaelni_ iam fine with droping the rewritten nvenc
[19:28:39 CEST] <jamrial> some things
[19:28:57 CEST] <philipl> michaelni_: do you think we should alias the codec names before we release?
[19:29:01 CEST] <jamrial> philipl: we could drop theirs and rename ours (so they are called the same in both projects), but there's the issue of clashing avoptions
[19:29:12 CEST] <philipl> That's the main issue, yes.
[19:29:22 CEST] <wm4> I don't consider it an issue at all
[19:29:29 CEST] <wm4> not for something as obscure as nvenc
[19:29:31 CEST] <michaelni_> philipl, up to you and BtbN
[19:29:33 CEST] <philipl> Well, not rename - we have our own compatibility to think about.
[19:29:54 CEST] <philipl> BtbN: around?
[19:30:15 CEST] <jamrial> ah right, nvenc h264 is already part of a release
[19:30:43 CEST] <jamrial> but not h265
[19:30:46 CEST] <philipl> So, I'd propose the following: 1) Revert the merge, that gets us back to where we started. 2) Add their codec names as aliases to ours. 3) Ignore option compatibility for now. BtbN will look at it at some point.
[19:30:51 CEST] <philipl> 265 was released, I thought.
[19:31:19 CEST] <jamrial> shows up in Changelog as part of version next
[19:31:25 CEST] <philipl> Ok.
[19:31:27 CEST] <BtbN> yeah, i'm around. 265 would be in 2.7, not in a relase yet
[19:31:33 CEST] <philipl> Well, I'm ok with renaming.
[19:31:49 CEST] <philipl> I called in nvenc_h265, but it seems the whole world has gone with hevc, so just as well.
[19:32:05 CEST] <nevcairiel> makes for a cleaner distinction with h264
[19:32:50 CEST] <michaelni_> its h261, h262, h263, h264, hevc, i dont know why, but that is indeed what people prefer
[19:33:06 CEST] <nevcairiel> i dunno, people also use mpeg2 more than h262
[19:33:21 CEST] <nevcairiel> or mpeg4 for h263
[19:33:22 CEST] <BtbN> Propably whatever gets used more first wind
[19:33:26 CEST] <BtbN> *s
[19:33:28 CEST] <philipl> mpegh forever!
[19:33:55 CEST] <michaelni_> i am not 100% sure about mpeg2 but mpeg4 ASP (which people use) is not identical to h263
[19:34:06 CEST] <philipl> it's a superset.
[19:34:29 CEST] <philipl> Anyway, BtbN: is that plan ok with you?
[19:34:44 CEST] <BtbN> Dropping the libav nvenc encoder and adding aliased names to our one, and then continouing to port usefull features?
[19:34:51 CEST] <philipl> yes.
[19:34:56 CEST] <BtbN> Yeah, sounds good
[19:34:57 CEST] <philipl> although for hevc, I'll just rename ours.
[19:35:02 CEST] <philipl> so one alias.
[19:35:16 CEST] <BtbN> Yes, as it's not released yet, that might be better
[19:35:16 CEST] <philipl> Is there a cheap way to do aliases or does it need another codec declaration?
[19:35:20 CEST] <nevcairiel> our hevc and h264 names should be consistent
[19:35:24 CEST] <nevcairiel> whats their name vs ours anyway?
[19:35:42 CEST] <philipl> Ours today are nvenc and nvenc_h265. Theirs are nvenc_h264 and nvenc_hevc.
[19:35:50 CEST] <nevcairiel> ah
[19:35:57 CEST] <nevcairiel> i guess having the codec in the h264 as well is a bit cleaner
[19:36:22 CEST] <philipl> I'll have a patch series up shortly.
[19:36:35 CEST] <BtbN> When i started with this, there was no support for any other codec than h264 in nvenc, so even on short term, it's kind of a historic reason
[19:36:39 CEST] <nevcairiel> unfortunately i dont think t here is a good way to do aliases
[19:36:42 CEST] <nevcairiel> its probably going to be ugly
[19:36:44 CEST] <jamrial> philipl: theirs are h264_nvenc and hevc_nvenc
[19:36:56 CEST] <philipl> they are?
[19:37:06 CEST] <nevcairiel> thats terrible names then
[19:37:13 CEST] <philipl> jamrial: other way round
[19:37:19 CEST] <philipl> I just looked. It's what I wrote.
[19:37:29 CEST] <philipl>     .name           = "nvenc_hevc",
[19:37:34 CEST] <nevcairiel> its ... inconsistent
[19:37:39 CEST] <nevcairiel> AVCodec ff_h264_nvenc_encoder = {
[19:37:39 CEST] <nevcairiel>     .name           = "nvenc_h264",
[19:37:44 CEST] <jamrial> allcodecs and configure show what i mentioned above
[19:37:46 CEST] <jamrial> so meh
[19:37:54 CEST] <philipl> Well, I meant the command line visible name.
[19:37:55 CEST] <nevcairiel> how un-libav of them =P
[19:38:49 CEST] <nevcairiel> they did do the thing we didnt want to do, shoving the levels in the options table, heh
[19:39:50 CEST] <philipl> because it looks neat.
[19:42:11 CEST] <philipl> I just learned how to revert a merge. yay.
[19:51:48 CEST] <philipl> revert patch series sent.
[19:52:44 CEST] <Daemon404> http://blogs.windows.com/buildingapps/2015/06/05/using-ffmpeg-in-windows-applications/
[19:52:47 CEST] <Daemon404> my god.
[19:52:59 CEST] <phh> that's called game
[19:53:10 CEST] <Daemon404> FFmpegMSS = FFmpegInteropMSS::CreateFFmpegInteropMSSFromStream(readStream, false, false);
[19:53:15 CEST] <Daemon404> they somehow made our api even worse
[19:53:44 CEST] <Daemon404> my main issue is that they make it out like they did any work at all making it work on winrt
[19:53:49 CEST] <Daemon404> they wrotet he convouted wiki page.
[19:53:55 CEST] <Daemon404> wbs, bbb, etc did all the work.
[19:54:20 CEST] <kierank> do you want me to troll them
[19:54:41 CEST] <Daemon404> doubt it gets anywhere
[19:55:03 CEST] <Daemon404> that wiki page is :V though
[19:55:07 CEST] <Daemon404> like 90 pages of copypaste
[19:55:18 CEST] <Daemon404> i rejected it from including it in oru texi
[19:55:20 CEST] <Daemon404> our*
[19:55:45 CEST] <wm4> lol https://github.com/Microsoft/FFmpegInterop/issues/2
[19:55:51 CEST] <philipl> I'm sure it does hilarious things if you try and use hardware acceleration.
[19:55:57 CEST] <wm4> (I bet they just massed up API usage)
[19:56:28 CEST] <Daemon404> to be fair, i cant blame them
[19:56:35 CEST] <Daemon404> its not exactly easy
[19:58:21 CEST] <wm4> actually it's pretty simple now
[19:58:42 CEST] <wm4> you just have to ignore all the wrong official ffmpeg examples and all those "tutorials"
[19:58:56 CEST] <Daemon404> i wouldnt call it simple
[19:59:01 CEST] <Daemon404> certainly not ffms2-simple
[20:00:41 CEST] <wm4> IMO the most confusing thing by now is shuffling the data between the sub-APIs
[20:00:45 CEST] <wm4> connecting libavformat and libavcodec
[20:01:03 CEST] <wm4> and then getting the data in a format you want, which may involve other sub APIs
[20:01:56 CEST] <Daemon404> i think youve got a bit of tockhom
[20:02:00 CEST] <Daemon404> stockholm*
[20:02:35 CEST] <wm4> not really... it could be e.g. vaapi-bad
[20:03:01 CEST] <Daemon404> sure worse thigns exist
[20:03:04 CEST] <Daemon404> but it doesnt make it good
[20:03:11 CEST] <Daemon404> or eays
[20:03:14 CEST] <Daemon404> easy even
[20:05:14 CEST] <kierank> personally I would abstract away demux and decode
[20:05:26 CEST] <wm4> abstract away how?
[20:05:35 CEST] <kierank> pipelines I guess
[20:05:47 CEST] <Daemon404> wm4, like ffms2 does maybe
[20:05:49 CEST] <Daemon404> for a higher level api
[20:05:49 CEST] <kierank> it's the only real way you can do chained muxing and demuxing
[20:07:36 CEST] <wm4> well you could just make it a thing with filters and connections between them, like almost every media framework does
[20:20:36 CEST] <philipl> all changes posted.
[21:44:25 CEST] <Compn> i have a questioooon
[21:44:49 CEST] <Compn> what would microsoft use for codecs on winrt if ffmpeg didnt exist ?
[21:44:58 CEST] <Compn> did they port the mediaframework crap ?
[21:45:20 CEST] <Compn> i guess they could compile h264 , wmv stuff for winrt phones and tablets
[21:46:32 CEST] <Compn> https://playerframework.codeplex.com/
[21:46:52 CEST] <Compn> so apple, builds an os on opensource bsd, refuses to share anything?
[21:46:57 CEST] <Compn> microsoft, goes open source ?
[21:47:02 CEST] <kierank> apple do share stuff
[21:47:33 CEST] <Compn> webkit?
[21:50:45 CEST] <Daemon404> most of the os core
[21:50:55 CEST] <Daemon404> its just in terrible apple places
[21:53:45 CEST] <Compn> ah
[21:55:08 CEST] <Mavrik> Compn, all of those have HW decoders
[21:55:21 CEST] <Mavrik> so I guess just like on apple stuff you'd be stuck with whatever hardware supports
[21:57:56 CEST] <Compn> true
[22:16:16 CEST] <nevcairiel> Daemon404: i never found ffmpeg API to be that bad, its about the complexity I expected when dealing with media frameworks ... maybe it "helps" that I wrapped DShow around it, which has similar separation between demux, decode and rendering =p
[22:16:34 CEST] <cone-659> ffmpeg 03Philip Langdale 07master:8a6536cbc0a9: Revert "Changelog: Drop duplicate NVENC entry"
[22:16:34 CEST] <cone-659> ffmpeg 03Philip Langdale 07master:728c82a53253: Revert "avcodec/Makefile: fix checkheaders for nvenc_b"
[22:16:34 CEST] <cone-659> ffmpeg 03Philip Langdale 07master:58b49f78cf34: Revert "nvenc: remove cuda.h requirement for nvenc_a"
[22:16:34 CEST] <cone-659> ffmpeg 03Philip Langdale 07master:d47de79372d3: Revert "Merge commit 'b08caa87c35a768ec0abb16b1e99c3a85f1df28e'"
[22:16:34 CEST] <cone-659> ffmpeg 03Philip Langdale 07master:c10e6bcb43ad: Revert "avcodec: Rename nvenc.c to nvenc_a.c, to avoid conflict with the other implementation"
[22:16:35 CEST] <cone-659> ffmpeg 03Philip Langdale 07master:e79c40fe7247: avcodec/nvenc: Rename nvenc_h265 to nvenc_hevc
[22:16:35 CEST] <cone-659> ffmpeg 03Philip Langdale 07master:7e4661174ae1: avcodec/nvenc: Add 'nvenc_h264' as an alternative name for 'nvenc'
[22:20:23 CEST] <Daemon404> nevcairiel, maybe
[22:20:39 CEST] <wm4> I'm also dealing with my own demux/decode separation
[22:20:49 CEST] <wm4> not having this separation would actually be a pain for me
[22:59:25 CEST] <cone-659> ffmpeg 03Michael Niedermayer 07master:f30a7d9861af: avcodec/mpegvideo: Merge thread context initialization loops
[22:59:26 CEST] <cone-659> ffmpeg 03Michael Niedermayer 07master:7ddedd23625a: avcodec/mpegvideo: Clear thread_context array before allocating
[22:59:27 CEST] <cone-659> ffmpeg 03Michael Niedermayer 07master:46428ea332d8: avcodec/mpegvideo: Use av_memdup() for allocating thread_context
[23:06:08 CEST] <philipl> BtbN: Do you remember the report that our nvenc is noticeably slower than the nvidia reference encoder - particularly, it ends up slower than real time for 4Kp60 content.
[23:07:00 CEST] <BtbN> you mean shadowplay?
[23:07:28 CEST] <philipl> No, there was that guy who was trying to transcode 4k content and he couldn't get it to go at realtime, but the nvidia example app could.
[23:07:33 CEST] <philipl> Just normal nvenc
[23:08:07 CEST] <BtbN> Hm, the only difference i can think of then is that the reference app doesn't use CUDA for interop, but some DirectX/D3D code
[23:08:09 CEST] <philipl> Now, the example app only takes in raw yuv frames, so I wonder if he was decoder bottle-necked.
[23:08:26 CEST] <philipl> I can't remember what his source format was or where the data was coming from.
[23:08:37 CEST] <BtbN> Usualy the bottlenack when using nvenc in ffmpeg is the yv12 to nv12 conversion
[23:09:45 CEST] <BtbN> Someone was here, who made a CUDA based yuv420p->nv12 filter, which resulted in massive speedups
[23:10:00 CEST] <BtbN> Might actualy be worth it do implement something like that, with OpenCL
[23:10:14 CEST] <nevcairiel> using sse2 for yv12->nv12 is usually really not much slower than a memcpy
[23:10:23 CEST] <nevcairiel> because that conversion is so extremely trivial
[23:10:26 CEST] <philipl> Yeah, if that's the difference between realtime and slower than realtime, it's definitely worth it.
[23:10:48 CEST] <philipl> If the input data was nv12, can you avoid a memcpy on the input path? Can it reuse the caller's buffer?
[23:10:48 CEST] <BtbN> hm? nv12 is the least trivial conversion of all, as you have to inverleave the u/b planes
[23:11:14 CEST] <BtbN> no, the buffer has to be allocated by nvenc
[23:11:32 CEST] <philipl> sad.
[23:11:36 CEST] <BtbN> There's no way to make it use a pre-existing buffer
[23:12:04 CEST] <philipl> It seems rather unfortunate that it can't consume the most common surface format...
[23:12:05 CEST] <nevcairiel> yv12->nv12 is a load, a unpack, and a store sse operation
[23:12:16 CEST] <nevcairiel> its super trivial o.o
[23:12:29 CEST] <BtbN> Hm, isn't yv12 3 planes?
[23:12:38 CEST] <philipl> yeah, yv12 is three plans
[23:12:41 CEST] <philipl> planes
[23:12:52 CEST] <nevcairiel> there is a sse2 instruction to interleave bytes
[23:13:21 CEST] <BtbN> I don't have to much of an idea about sse, but even with avx and everything supported, the conversion still is the slowest part of the chain, if you use hw decoding and encoding
[23:13:40 CEST] <philipl> So, rewinding slightly - nvenc is already initialising cuda, so we should just get that guys routine and use it.
[23:13:42 CEST] <BtbN> Can very well be the bottleneck when using 4K60
[23:13:57 CEST] <nevcairiel> so you do: load u, load v, unpack*2 (since it operates on half a reg), store uv into nv12 buffer *2
[23:14:16 CEST] <nevcairiel> not sure thats going to be faster if you copy it back and forth between the gpu
[23:14:29 CEST] <nevcairiel> unless you can keep it on the gpu if done in cuda
[23:14:30 CEST] <BtbN> the copy to GPU happens internaly in nvenc
[23:14:38 CEST] <BtbN> you just memcpy to another system-ram buffer
[23:14:51 CEST] <philipl> can nvenc take a cuda buffer for the input?
[23:15:08 CEST] <BtbN> It should, but i never looked into that
[23:15:15 CEST] <philipl> I thought I read that.
[23:15:30 CEST] <philipl> so yeah, in theory you could use cuda for the conversion and keep the result in GPU memory to pass to nvenc.
[23:15:33 CEST] <BtbN> It can take D3D surfaces, which is interesting if you are using it in a game, or you are steam and are hooked into a game and want to encode it
[23:16:04 CEST] <philipl> I'm on linux, and there's no equivalent GL interop.
[23:16:08 CEST] <philipl> :-P
[23:16:24 CEST] <BtbN> Nope, there's nothing like that on linux
[23:16:32 CEST] <BtbN> although NvFBC should work on linux
[23:16:36 CEST] <BtbN> But it's NDA-Only
[23:17:39 CEST] <BtbN> That's how ShadowPlay works, it basicaly grabs the framebuffer on the GPU, and sends it to the encoder
[23:17:46 CEST] <nevcairiel> I assume the big problem here is that sws just has no optimized yv12->nv12 path, which makes it slow, although since you need to memcpy anyway, it might be ideal to do this conversion in nvenc with a specialized function that transfers "in-flight" with simd if available
[23:18:18 CEST] <BtbN> The "libnvenc" thing does that, although in the most non-optimal way possible
[23:18:23 CEST] <philipl> Yeah. You'd want to do the conversion as part of the copy that you're already committed to
[23:18:26 CEST] <BtbN> just a few for-llops
[23:18:32 CEST] <BtbN> *loops
[23:18:46 CEST] <BtbN> But even that is already slightly faster than was sws does
[23:18:55 CEST] <philipl> I did some brief comparisons between your encoder and the one the nvidia people wrote and they both performed about the same.
[23:19:10 CEST] <nevcairiel> In my decoder, I always convert yv12->nv12, because GPUs are much happier with nv12, and its never had a noticable performance impact, since its such an easy conversion
[23:19:10 CEST] <philipl> (the ffmpeg encoder they wrote)
[23:19:14 CEST] <BtbN> The difference gets more aparent when you are on a non-sse3 CPU
[23:19:34 CEST] <nevcairiel> and sse2 is like present everywhere
[23:19:38 CEST] <BtbN> Someone was here with an AMD Phenom, which doesn't support some sse thing.
[23:19:58 CEST] <BtbN> The conversion was awfully slow for him, couldn't even handle 720p60
[23:20:25 CEST] <jamrial> BtbN: ssse3, not sse3
[23:20:56 CEST] <philipl> BtbN: hang on. nvenc supports yv12 input surfaces.
[23:20:57 CEST] <jamrial> and yeah, amd was late to add that
[23:21:02 CEST] <BtbN> philipl, nope, it doesn't
[23:21:04 CEST] <BtbN> The API does
[23:21:08 CEST] <BtbN> But nvenc doesn't
[23:21:13 CEST] <philipl> ah. lovely.
[23:21:16 CEST] <BtbN> it's not in the list of supported formats if you query i
[23:21:17 CEST] <BtbN> *it
[23:21:23 CEST] <philipl> *groan*
[23:21:46 CEST] <BtbN> I just hardcoded it to nv12, because you have to initialize the nvenc chain quite a bit until you can get that information from it
[23:22:04 CEST] <BtbN> and doing that in the init-static-data function wasn't so pretty
[23:22:12 CEST] <nevcairiel> interestingly the libav encoder offered that in the pixfmt list, what did it do, just fail? :d
[23:22:39 CEST] <BtbN> If they are based on the libnvenc encoder, they do in-place conversion when copying to the nvenc buffer
[23:22:46 CEST] <BtbN> That's what it did
[23:23:23 CEST] <BtbN> If they don't do that, and just send yv12 to nvenc, it will just fail to initialize at some point
[23:23:41 CEST] <BtbN> Or nvidia added support for yv12 with some driver update, and it actualy does work now
[23:23:51 CEST] <philipl> I'm trying to establish that.
[23:24:03 CEST] <BtbN> Easy enough to check, add yuv420p to the list of formats, the code to use it is already in place
[23:24:09 CEST] <philipl> Yes, I saw.
[23:24:15 CEST] <philipl> It's working here, with no difference in speed.
[23:24:18 CEST] <philipl> ...
[23:24:24 CEST] <BtbN> interesting
[23:25:03 CEST] <BtbN> If they did add support for it, that's a bit of a problem.
[23:25:18 CEST] <BtbN> Adding it to the list of supported formats will screw people with older drivers
[23:25:23 CEST] <philipl> Yeah. I'm seriously seeing exactly the same encode framerate.
[23:25:32 CEST] <philipl> How much do we care about that?
[23:26:31 CEST] <philipl> If you're on the nvidia bandwagon, you update drivers monthly, don't you?
[23:26:50 CEST] <BtbN> If you're on some stable distro like ubuntu, you don't :/
[23:26:59 CEST] <BtbN> On Windows it shouldn't be an issue
[23:27:20 CEST] <BtbN> I'll have to check on my hardware, maybe it's a maxwell thing, and not only the driver
[23:27:33 CEST] <philipl> This is probably where you remember that the only legitimate way to get nvenc support is to compile for yourself, so you're probably qualified to use the right ppa for the driver.
[23:27:42 CEST] <philipl> Yeah, maxwell here.
[23:27:56 CEST] <BtbN> I only have Kepler cards here
[23:28:08 CEST] <BtbN> And last time I checked, yv12 didn't work
[23:28:35 CEST] <philipl> Well, the 'good' news is that supporting yv12 doesn't make anything faster :-P
[23:29:16 CEST] <JEEBsv> NV12 seems to be the new favourite child around GPUs, no?
[23:29:27 CEST] <philipl> How do I check if ffmpeg is doing a format conversion implicitly?
[23:29:44 CEST] <JEEBsv> -v debug or so?
[23:29:58 CEST] <nevcairiel> it should tell you the input format on the format line
[23:30:07 CEST] <nevcairiel> input to the encoder
[23:30:11 CEST] <BtbN> It should be quite obvious with debug logging, or even just verbose
[23:30:14 CEST] <philipl> Yeah, it does.
[23:31:02 CEST] <philipl> Anyway, I'm just so puzzled that it's made no difference.
[23:31:19 CEST] <philipl> Might be decoder-bound? My sample source here is a vp9 4k stream from youtube.
[23:31:40 CEST] <BtbN> try disabling the encoder, and check how fast it goes
[23:31:49 CEST] <BtbN> Just pipe raw output to /dev/null or something
[23:32:38 CEST] <BtbN> I can't imediately think of a reason why there would be a major speed difference between the ffmpeg and reference-implementation
[23:33:01 CEST] <philipl> Decodes at ~97
[23:34:05 CEST] <BtbN> hm
[23:34:41 CEST] <BtbN> maybe it's actualy a memory bandwidth thing, and copying that much data around twice just can't get any faster
[23:34:53 CEST] <philipl> and the reference implementation doesn't support yv12.
[23:34:56 CEST] <BtbN> But getting rid of the conversion should have done something about that
[23:35:25 CEST] <philipl> I'd originally suggested to the guy who asked that maybe the hardware performance fell off non-linearly but he swore the reference implementation could do realtime.
[23:36:13 CEST] <BtbN> Did he try to use a diffrent nvenc profile?
[23:36:28 CEST] <BtbN> Maybe the reference one was in some high-performance mode?
[23:37:49 CEST] <philipl> hp preset takes us from 36 -> 43.
[23:38:03 CEST] <philipl> (for hevc)
[23:38:26 CEST] <BtbN> i also think i read somewhere that 4K, 60 fps isn't yet supported?
[23:38:32 CEST] <BtbN> But 4K30 is
[23:38:34 CEST] <philipl> for h264, it goes from ~60 to 75
[23:38:57 CEST] <philipl> The claim was that he was doing 4k hevc.
[23:39:01 CEST] <philipl> but what do I know.
[23:39:09 CEST] <philipl> Heck, the reference encoder doesn't do hevc.
[23:39:49 CEST] <BtbN> That would explain the difference at least
[23:40:34 CEST] <philipl> Ok. so with h264, supporting yv12 gets you ~60fps on hq preset.
[23:40:38 CEST] <philipl> With nv12 only you get ~55.
[23:40:56 CEST] <philipl> For hevc, you see no difference at all and it's stuck around 36.
[23:41:09 CEST] <nevcairiel> and that difference could probably be fixed by improving the conversion
[23:41:39 CEST] <philipl> So, I'm going to conclude the following: hevc encoding simply can't do 4k60 until someone shows me proof that it can somewhere.
[23:41:50 CEST] <philipl> And h264 can do 4k60 if not bottlenecked.
[23:42:23 CEST] <BtbN> I'm quite sure i read somewhere that h265 with 4K60 isn't supported until the next GPU generation
[23:43:47 CEST] <philipl> Well, 35fps would make a lot of sense in that context,
[23:45:05 CEST] <BtbN> I'll check how my gtx760 likes yv12
[23:49:07 CEST] <philipl> I'm on a gtx980 with the linux 352.09 drivers here for comparison.
[00:00:00 CEST] --- Sun Jun  7 2015