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

[burek]

[02:59:36 CEST] <cone-129> ffmpeg 03Mark Reid 07master:d74cc6157478: libavformat/movenc: remove unnecessary null check
[06:49:41 CEST] <Admin__> DHE , patch did not work. Still crashed at 26 hours and 30 minutes.
[08:43:38 CEST] <andrey_turkin> hmm, for some reason I get garbled output when using nvenc with yuv420p format on Windows
[10:59:49 CEST] <ubitux> is anyone is working on the merging of libav? next commit is 3176217
[11:00:14 CEST] <ubitux> i'd like to have a look; is there a WIP, some stuff to know about this?
[11:00:18 CEST] <ubitux> nevcairiel?
[11:01:31 CEST] <nevcairiel> the next commit is rather tedious, which is why I didnt do it yet, didnt have the motivation yet to figure it out
[11:03:30 CEST] <ubitux> i'll try to do it
[11:03:41 CEST] <ubitux> do we have written directives about how to proceed with the merge?
[11:05:03 CEST] <nevcairiel> no
[11:05:30 CEST] <nevcairiel> (1) make sure nothing is broke; (2) see 1
[11:07:49 CEST] <mateo`> nevcairiel: I've heard about a script regarding the merges. Is there actually one ?
[11:08:15 CEST] <nevcairiel> i just wrote one myself to pick the next commit
[11:08:43 CEST] <nevcairiel> http://pastebin.com/TJSgHdr9
[11:09:37 CEST] <mateo`> i'm also interested in helping
[11:09:42 CEST] <mateo`> nevcairiel: thanks
[11:10:45 CEST] <nevcairiel> merging often requires quite a thorough understanding of the code in question, especially in the current commits needing merging in the h264 decoder
[11:11:43 CEST] <ubitux> i'm more concerned about how to test all the hwaccels
[11:12:04 CEST] <nevcairiel> and one should be aware of future commits coming in, so that if there is a compile fix for the current merge, it should be fixed right here instead of pushing a broken merge, for example
[11:12:10 CEST] <mateo`> nevcairiel: I know, I guess it's time to learn new things :)
[11:12:14 CEST] <nevcairiel> (which is actually relevant for the merge on top right now)
[11:12:32 CEST] <iive> ubitux: do you have radeon video card? mesa3d support vaapi and vdpau
[11:12:48 CEST] <ubitux> i only have intel
[11:12:51 CEST] <ubitux> and linux only
[11:13:02 CEST] <mateo`> I have one
[11:13:31 CEST] <nevcairiel> so in short: don't rush anything :)
[11:13:57 CEST] <iive> ubitux: mesa3d is the linux hw acceleration for opengl direct3d9 , egl , etc...
[11:14:25 CEST] <iive> what does the new h264 changes do?
[11:14:43 CEST] <ubitux> iive: git log --oneline --reverse master..libav/master
[11:15:05 CEST] <iive> ubitux: don't they have web interface?
[11:15:33 CEST] <ubitux> git.libav.org
[11:16:43 CEST] <iive> and the name of the commit?
[11:17:20 CEST] <ubitux> http://sprunge.us/ZUea 
[15:42:34 CEST] <BtbN> andrey_turkin, 901b48b looks like it breaks compile on windows. There are at least some TEXT() blocks missing for the LoadLibrary calls.
[15:49:12 CEST] <Admin__> DHE you around?
[15:49:29 CEST] <DHE> a bit busy
[15:50:00 CEST] <Admin__> sorry i don't mean to bother you .. just wanted to tell you the patch did not work. at exact 26.30 of runtime it stopped working
[15:53:48 CEST] <BtbN> What exactly does the SKIPHEADERS Makefile variable do?
[16:00:05 CEST] <jkqxz> It stops the header from being test-built by "make checkheaders".  It should be set for a header with an external dependency which might not be present if the given option is not set (headers with only internal dependences will always be tested).
[16:03:05 CEST] <DHE> Admin__: dammit...
[16:05:01 CEST] <Admin__> :(
[16:05:14 CEST] <Admin__> i am still stuck
[16:50:03 CEST] <prelude2004c> DHE, BtbN , anyone have any further recommendations?
[17:02:00 CEST] <DHE> not right now...
[17:45:08 CEST] <andrey_turkin> BtbN: it compiled for me with native msvc. I guess I should try to setup crosscompilation toolchain
[17:51:07 CEST] <BtbN> strange, it shouldn't. LoadLibrary expects a wchar_t*
[17:53:00 CEST] <andrey_turkin> maybe it was defaulting to ansi build
[17:54:53 CEST] <prelude2004c> DHE , do you know anyone that I could contact and pay for programming time to get these things resolved ? I need to move on this stuff and understand how busy everyone is. I would not mind paying for it in order to get it done asap. If you know anyone please let me know.
[17:55:17 CEST] <BtbN> Are you still going on about your hacky streaming thing?
[17:55:36 CEST] <prelude2004c> I also have some other work that I need done. Once it is done I have no issue with the code going back to the open source community so no loss there. 
[17:55:42 CEST] <DHE> BtbN: there is definitely an ffmpeg issue when the duration of the video exceeds the range of the timestamps of the format
[17:55:47 CEST] <prelude2004c> um.. currently its not about my hacky streaming thing :) 
[17:55:52 CEST] <BtbN> ah, so not the same issue anymore.
[17:56:32 CEST] <BtbN> Well, is there a sane way to handle that case anyway?
[17:56:35 CEST] <prelude2004c> actually BtbN this is a major issue.. the rest are small little things.. eg.. http:// webdav i already pulled that out.. i dont need it.. i only used it to test if it had anything to do with the stream stopping but soon as i found out there was an issue at 26.5 that http doesn't really help so i took it out 
[17:56:37 CEST] <JEEB> I have a feeling we are exporting a bit too much stuff into general avformat
[17:56:59 CEST] <JEEB> mpegts demuxer should handle the wrapping in itself and just output timestamps that are rising
[17:57:12 CEST] <JEEB> avformat itself would just see those
[17:57:20 CEST] <BtbN> For how long can it keep doing that until the 64bit timestamps overflow?
[17:57:20 CEST] <DHE> BtbN: I tried making a patch (hacky I admit) that tracks wrap-around of the DTS and adds (1 << pts_wrap_bits) to it, once per wrap-around.
[17:57:24 CEST] <DHE> apparently that didn't work
[17:57:37 CEST] <JEEB> BtbN: at that point we're eff'd anyways
[17:58:11 CEST] <DHE> mpegts uses a timebase of 1/90000, which is still plenty big assuming you don't have something gone completely crazy and spewing garbage timestamps
[17:59:01 CEST] <JEEB> [mpegts: handles mpeg-ts specifics] => general avformat gets general rising timestamps => [mpegtsenc: handles the rollovers inside itself]
[17:59:27 CEST] <kierank> 64-bit timestamp overflow is rather large
[17:59:30 CEST] <JEEB> IMHO it should generally go like that and if it doesn't we have an issue
[17:59:40 CEST] <kierank> can't remember if it's ~heat death of universe large
[17:59:48 CEST] <kierank> but yes I agree JEEB 
[17:59:53 CEST] <kierank> that's how other demuxers do it
[18:02:59 CEST] <prelude2004c> I am told to use gstreamer and that it doesn't have that issue.... i refuse to do that :) i like ffmpeg... just have to be able to stabalize this probelm
[18:09:17 CEST] <iive> if i remember correctly, mpegts ts are 33 bit, not 64. and that's with 90kHz clock. if 27MHz clock is used, 9 bit are added to the 33 ones.
[18:11:42 CEST] <iive> JEEB's idea is reasonable. I'm just not sure what would happen on seeking.
[18:12:13 CEST] <iive> that is, in the case where we don't know if we've had wrap arounds
[18:13:01 CEST] <nevcairiel> seeking in wrapping files is not really something you can expect to produce expected timestamps, but thats not any worse than today
[18:13:42 CEST] <andrey_turkin> iirc mpegts timestamps wrap once every day or so
[18:13:52 CEST] <nevcairiel> 26 hours or so
[18:14:32 CEST] <andrey_turkin> right. So not really possible to do a seek inside a very long file
[18:17:49 CEST] <kierank> not easily
[18:18:10 CEST] <kierank> the "proper" way is to generate timestamps on receive
[18:28:19 CEST] <prelude2004c> kierank , when you say generate timestamps on receive do you mean " -fflags +genpts ?
[20:54:48 CEST] <prelude2004c> kierank , i didn't get a reply because i got disconnected :( sorry about that
[21:28:07 CEST] <DHE> prelude2004c: probably not getting CC in nvenc, boss isn't interested
[21:29:42 CEST] <prelude2004c> CC in nvenc ?  ( closed caption ) , you know the problem though ? 
[21:30:02 CEST] <prelude2004c> can it be fixed is what i want to know... that way i can get someone to fix it 
[21:31:04 CEST] <DHE> it can be. libx264 is already doing it
[21:31:11 CEST] <prelude2004c> for now i suspect cc can work if we move the code to use nvenc instead of piping out to Nvtranscoder.. the only thing that seems to have to be fixed is to check the quality comparison and also the decoding 
[21:32:24 CEST] <prelude2004c> if anyone knows anyone interested in helping me fix this and charging me for it please message me on skype " prelude2004c "
[21:32:39 CEST] <prelude2004c> DHE, what about this bug of 26.5 .. do we have an approach to it ?
[21:33:31 CEST] <prelude2004c> DHE, can you get the nvenc that is in ffmpeg to also push decoding into the card instead of having to use vdpau ?
[21:33:58 CEST] <prelude2004c> vdpau requires X  where as the NvTranscoder does not and makes ffmpeg so much more efficient 
[21:34:23 CEST] <DHE> prelude2004c: I'm still on the 26.5 thing myself. the nvenc decode thing doesn't directly align with my own needs - I'm kinda doing this because it's what I need as well
[21:35:44 CEST] <prelude2004c> DHE, much appreciate you helping with this stuff... + i have learned quite a bit just listening to the chat here.. i wish i could just program to help you guys out and make these things all become a reality.. but i think i am too old :P 
[21:35:56 CEST] <BtbN> Is that NvTranscoder thing open source?
[21:36:02 CEST] <prelude2004c> yes open source
[21:36:06 CEST] <BtbN> where is it?
[21:36:18 CEST] <BtbN> Because there is no API I know about which supports what you claim it can do.
[21:36:36 CEST] <prelude2004c> https://developer.nvidia.com/nvidia-video-codec-sdk
[21:36:47 CEST] <BtbN> No, the NvTranscoder you are using.
[21:36:54 CEST] <prelude2004c> yes.. download the one for linux.. just make and run it
[21:37:01 CEST] <BtbN> well, where is it?
[21:37:07 CEST] <prelude2004c> NvTranscoder is a sample inside the " https://developer.nvidia.com/nvidia-video-codec-sdk " 
[21:37:24 CEST] <DHE> it ships with the API for nvenc as a sample app
[21:37:30 CEST] <prelude2004c> there are a bunch of differnet stuff there.. for perl , decode, encode, transcode
[21:38:20 CEST] <prelude2004c> nvtranscoder takes care of encoding/decoding and i get less than 20% cpu usage when using it and improved quality at lower bit rates. It seems that it is able to respect QP while maintaing the bit rate min/max
[21:38:35 CEST] <prelude2004c> and when i use nvenc, my cpu usage on ffmpeg is well over 100% 
[21:38:40 CEST] <BtbN> So I guess you are on windows?
[21:38:44 CEST] <prelude2004c> 110-120% by comparison
[21:38:48 CEST] <prelude2004c> no i am on ubuntu
[21:39:01 CEST] <prelude2004c> the apis are linux based
[21:39:04 CEST] <BtbN> That's basically impossible then. The API it's using for decoding is documented as windows-only.
[21:39:16 CEST] <prelude2004c> nope... see it for youserlf .. it works 
[21:42:41 CEST] <BtbN> It's litteraly in #ifdef _WIN32 in the cuda headers.
[21:43:07 CEST] <prelude2004c> i dont know the details to be honest with you.. but it just works
[21:44:29 CEST] <BtbN> And even if it was supported, the only API I see takes a filename as input, and gives you frames.
[21:44:34 CEST] <BtbN> So not overly suitable for ffmpeg.
[21:46:25 CEST] <DHE> what are you looking at anyway? (sorry, just finished copying the sdk locally)
[21:46:35 CEST] <nevcairiel> full hardware pipelines are easy if you use a tool thats designed to work with exactly one piece of hardware and does exactly one thing
[21:46:47 CEST] <nevcairiel> ffmpeg works with everything and does everything
[21:46:50 CEST] <nevcairiel> so hardly easy
[21:46:55 CEST] <DHE> and then you lose things like filters
[21:49:05 CEST] <prelude2004c> i believe what you guys are saying..... but asside from that 26.5 hour thing it works well... the issue i have with nvenc ( assuming i can tweak quality further to match that of nvtranscoder which should be possible ), is the decoding.. using up CPU power to decode is  a problem when adding 10 - 15 channels per server.
[21:49:19 CEST] <prelude2004c> having the cards decoder take care of it , seems like a natural solution 
[21:52:34 CEST] <prelude2004c> the nvidia cards put in decoders / encoders for this purpose  and created the api's for this purpose.. i am sure there is some work to be done but it can be done and once complete , i think effeciency will be soo much more improved... assuming nvenc that is currently built into ffmpeg is working well .. the only thing left to do is send off the decoder to the hardware decoder too ( eg. nvenc ) .. right now vdpau is supposed to do 
[21:52:34 CEST] <prelude2004c> that but i hvae to install X and i had a few other issues with vdpau and getting it working correctly. It was not clean and simple .. so here i am :) and forgive my ignorance on some of this stuff i am trying to make sense of everything and some stuff is not a simple as it seems
[21:52:44 CEST] <DHE> found a PDF in the SDK that describes Cuda-based decoding (GL in the name)
[21:53:21 CEST] <DHE> I might turn this into a raw decoder...
[21:54:07 CEST] <BtbN> The hw de/encoders get pretty bad when handling multiple streams, they're not exactly made for that.
[21:54:45 CEST] <DHE> the encoder actually does fairly well. can't say about the decoder
[21:54:58 CEST] <prelude2004c> BtbN , asside from this 26.5 hour thing.. they been rock solid... i run approx 10-15 streams per card 
[21:55:28 CEST] <prelude2004c> DHE, the channel link i sent you , that is being decoded on card too from H264 > and then converting back to H264
[21:56:04 CEST] <prelude2004c> it's taking a 1080p 15Mbit/s stream and converting it to 720p ( 1.8-2.2Mbit/s ) 
[21:56:17 CEST] <prelude2004c> quality is very good
[21:56:32 CEST] <BtbN> I highly doubt quality with nvenc will be any good at that bitrate.
[21:56:33 CEST] <prelude2004c> i still have the link decrypted so.. you guys can check it out
[21:56:39 CEST] <prelude2004c> :) watch this
[21:56:55 CEST] <BtbN> "this"
[21:56:56 CEST] <DHE> I only saw a bit of talking-heads. not bad for the bitrate/quality
[21:57:00 CEST] <prelude2004c> http://67.55.3.103/ctvvancouverhd1151/ctvvancouverhd1151.m3u8
[21:57:41 CEST] <prelude2004c> and ignore the video from space
[21:57:52 CEST] <prelude2004c> :P it can't make space station closer :) 
[21:58:13 CEST] <BtbN> there is nothing happening in those scenes. So of course it looks bearable
[21:58:33 CEST] <prelude2004c> let me see if i can find you a better one
[21:58:34 CEST] <prelude2004c> sec
[21:58:53 CEST] <BtbN> And even with those low-motion scenes you can already see artifacts
[22:00:24 CEST] <prelude2004c> http://67.55.3.103/cbcvancouverhd1150/cbcvancouverhd1150.m3u8
[22:00:44 CEST] <prelude2004c> this is live TV ... we have to keep bit rates down for streaming.. its not something i can filter 10 x and go with VOD .. these sources are live streams
[22:01:16 CEST] <prelude2004c> look at http://67.55.3.103/cbcvancouverhd1150/cbcvancouverhd1150.m3u8 .. its more inline with what normally people watch on tv
[22:01:44 CEST] <prelude2004c> and yes, its not 1080p.. but its better quality than i got using nvenc ( not sure why ) 
[22:03:03 CEST] <prelude2004c> going to show you guys something else..
[22:03:11 CEST] <prelude2004c> there are 6 channels running on this server
[22:03:15 CEST] <DHE> I don't think it's going to help at this point
[22:03:28 CEST] <prelude2004c> http://imgur.com/xxTkUy8
[22:04:11 CEST] <prelude2004c> i am only trying to provide as much good evidence as possible .. i want to see ffmpeg improve too... i rely on it and i know people do too.. its a great product... so 
[22:04:46 CEST] <BtbN> Use the exact same settings for ffmpeg as you use for the nvTranscoder, and you get the exact same results.
[22:04:59 CEST] <DHE> so apparently with the opengl driver you can extract raw YUV out of the hardware decoder. Is that something ffmpeg would be interested in having? I suspect it does require X11 to work though even if you don't render anything
[22:07:06 CEST] <prelude2004c> yes tried to get same quality.. only thing is ( and not sure if this makes sense but ) ... my NvTranscoder settings are simply -qp 21  vbr 1.8 - 2.2 .. it seems to respect both .. not sure why... but with nvenc if i use qp=21 it doesn't stay within bw boundaries.. and if i use bw boundaries.. it wont give me the same quality of qp=21 
[22:07:14 CEST] <prelude2004c> so another reason i pushed for nvTranscoder 
[22:07:23 CEST] <prelude2004c> and i am not saying i am wrong.. its just my observation
[22:07:30 CEST] <DHE> yep, GLUT required
[22:07:33 CEST] <prelude2004c> i am NOT wrong * i mean
[22:07:35 CEST] <BtbN> constqp and vbr at the same time makes no sense.
[22:08:20 CEST] <prelude2004c> yup BtbN.. everyone says that and I agree sure.. but i am not sure how NvTranscoder is doing it :( 
[22:08:26 CEST] <BtbN> It can't.
[22:08:34 CEST] <BtbN> Which rcmode did you pass to it?
[22:08:38 CEST] <prelude2004c> i dont mind changing to be honest and using nvenc .. if we can solve the decoding issue ... then i am ready to change
[22:08:48 CEST] <prelude2004c> whatever gets me great results and better support
[22:09:48 CEST] <prelude2004c> i am not stuck on Nvtranscoder.. i am only trying to solve it and it has the best results so far. 
[22:10:14 CEST] <BtbN> <BtbN> Which rcmode did you pass to it?
[22:10:25 CEST] <prelude2004c> 32
[22:10:35 CEST] <prelude2004c> ( 2pass ) .. and llhq
[22:10:47 CEST] <BtbN> 32?
[22:10:48 CEST] <DHE> ... low latency?
[22:11:29 CEST] <prelude2004c> yup.. quality went up with it too
[22:11:37 CEST] <DHE> ... I find that hard to believe
[22:11:41 CEST] <prelude2004c> llhq gave me the best quality
[22:11:53 CEST] <DHE> unless there is something catastrophically wrong with the bframe code
[22:13:44 CEST] <prelude2004c> DHE, i wish i could help.. but i dont know 
[22:14:02 CEST] <BtbN> llhq yielding better quality is no news
[22:14:28 CEST] <BtbN> hq has a better psnr, but llhq visually looks better.
[22:14:48 CEST] <prelude2004c> yes llhq looks way better for me so i used it
[22:16:54 CEST] <BtbN> qp_inter_p = (avctx->qmax + 3 * avctx->qmin) / 4; // biased towards Qmin
[22:17:02 CEST] <BtbN> is it only me or are the + and * swapped?
[22:18:23 CEST] <prelude2004c> BtbN, this could be a reason why my quality is reduced on nvenc ? not sure if we are still on the same topic here :) 
[22:18:31 CEST] <BtbN> no.
[22:18:42 CEST] <BtbN> you're just using it wrong.
[22:18:59 CEST] <prelude2004c> oh.. that's good then 
[22:19:25 CEST] <prelude2004c> so ok.. let's asume i can use nvenc and all is well in the world... and it uses the nvidea card... what should i do about the decoding?
[22:19:51 CEST] <BtbN> Ask nvidia to implement propper non-Windows APIs.
[22:20:03 CEST] <prelude2004c> how can we properly use the card instead of the CPU's
[22:20:42 CEST] <prelude2004c> ya like that will happen :) .. i suspect i have to find another way... 
[22:20:45 CEST] <BtbN> There is only cuvid, which is only available in a usefull form on windows.
[22:20:52 CEST] <BtbN> Or just use VDPAU.
[22:20:56 CEST] <BtbN> Which already exists.
[22:21:02 CEST] <prelude2004c> ya vdpau requires X and has other issues too
[22:21:18 CEST] <prelude2004c> + cpu usage was a lot higher with vdpau vs just pipping to the nvtranscoder
[22:21:42 CEST] <prelude2004c> eg. with vdpau it was improved for sure over CPU's but not even close to the nvtrancoder usage.
[22:22:05 CEST] <BtbN> NvTranscoder itself is even documented as Windows-Only.
[22:22:28 CEST] <prelude2004c> reallY? wow.. seems to have worked for me.. is the version i have differnet ? because it works great on my ubuntu with my video card.
[22:22:32 CEST] <DHE> the SDK sample compiles under Linux
[22:22:37 CEST] <DHE> that's all I've done though
[22:23:02 CEST] <BtbN> So either their documentation is outdated or it works but is unsupported.
[22:23:21 CEST] <prelude2004c> it def. works 
[22:23:33 CEST] <DHE> I have trouble believing it's unsupported if the latest SDK includes it in their list of samples (I downloaded this about 2 weeks ago)
[22:23:36 CEST] <prelude2004c> asside from the timeout sisue.. its flawless
[22:23:44 CEST] <BtbN> It is supported on Windows
[22:23:55 CEST] <BtbN> But the high-level cuvid APIs are documented as Windows-Only.
[22:24:13 CEST] <prelude2004c> BtbN, i don't think it uses cuda cores though
[22:24:31 CEST] <BtbN> why would it?
[22:24:40 CEST] <prelude2004c> the new cards ( eg. my M4000 ) card... has a built in encoder/decoder that is separate from the cuda cores.. ( from my understanding )
[22:24:51 CEST] <prelude2004c> if i am making sense.. not sure if i am :) 
[22:25:24 CEST] <prelude2004c> it used to be cuda cores before they moved the encoder/decoder stuff to the built in hardware.  my old cards and platform use the cuda cores of the old cards
[22:25:34 CEST] <prelude2004c> but no longer support the new ones.. hence the work required to create new encoders
[22:25:40 CEST] <DHE> afk for an hour or so
[22:26:29 CEST] <prelude2004c> DHE , thank you for your continued support in this stuff
[22:26:33 CEST] <prelude2004c> much appreciated
[22:26:46 CEST] <BtbN> http://developer.download.nvidia.com/assets/cuda/files/NVIDIA_Video_Decoder.pdf doesn't even document the functions _at all_
[22:26:57 CEST] <BtbN> Not a single reference to cuvidCreateVideoParser in there
[22:27:32 CEST] <prelude2004c> BtbN, whatever it is... it works.. can we take advantage of the fact that it works to pull that code and get it into nvenc ?
[22:27:39 CEST] <BtbN> No
[22:27:42 CEST] <prelude2004c> so nvenc will also support decoding without requiring vdpau
[22:27:46 CEST] <BtbN> It takes a filename as input
[22:27:49 CEST] <BtbN> so it's useless for ffmpeg.
[22:28:01 CEST] <prelude2004c> i pushed stdin to it and it worked
[22:28:14 CEST] <BtbN> I'm not going to implement that kind of hack-around
[22:28:42 CEST] <prelude2004c> http://pastebin.com/raw/QcLgPjUG
[22:29:00 CEST] <BtbN> ffmpeg decoders get raw bitstream
[22:29:01 CEST] <BtbN> not files
[22:29:04 CEST] <prelude2004c> that is the code i am using for it.. and i played around with a lot of settings on ffmpeg so please excuse if there are things wrong there
[22:29:17 CEST] <BtbN> And a decoder that dumps to a temporary file would be horrible, specialy as it needs a muxer for that.
[22:32:54 CEST] <jkqxz> pipe() + /dev/fd/N, maybe...  (If it can take stdin then it does not require the input to be seekable.)
[22:33:05 CEST] <BtbN> Good luck with that on windows.
[22:33:44 CEST] <jkqxz> Is this some sort of horrible licensing hack?  They have GPL code and proprietary code and have to create multiple processes and weird separation because their lawyers tell them to.
[22:34:08 CEST] <BtbN> That's all proprietary and within their cuda library.
[22:34:30 CEST] <BtbN> It either has a super low level API, that would need to be implemented as another hwaccell in ffmpeg.
[22:34:39 CEST] <BtbN> Or one that takes a path
[22:34:52 CEST] <BtbN> There does not seem to be any middle-layer that takes raw bitstream.
[22:39:29 CEST] <prelude2004c> i am going to change up my code to use vpau  and nvenc to compare.
[22:40:00 CEST] <prelude2004c> just to test the difference
[22:40:19 CEST] <prelude2004c> i loaded up vdpau already so let's see what happens
[22:44:29 CEST] <BtbN> prelude2004c, "-b:v 2200k -2pass 1 -qmin 23 -qmax 23" is what you are telling nvTranscoder to do.
[22:44:53 CEST] <BtbN> But it makes no sense. It's asking it to do basically constqp with a fixed bitrate.
[22:45:29 CEST] <prelude2004c> you may be right so i am going to switch up to nvenc and compare the quality of the twho
[22:45:41 CEST] <prelude2004c> then i will provide you two streams... you decide which looks better
[22:59:37 CEST] <prelude2004c> dealing with this shit right now ( Xlib:  extension "NV-GLX" missing on display ":0". ) .. 
[22:59:40 CEST] <andrey_turkin> BtbN:  > qp_inter_p = (avctx->qmax + 3 * avctx->qmin)
[22:59:47 CEST] <prelude2004c> vdpau is a pain in the @##@
[23:00:01 CEST] <andrey_turkin> it does that the comment says
[23:41:47 CEST] <cone-885> ffmpeg 03ZhouXiaoyong 07master:2c7fd0e36b6d: avcodec/mips/h264qpel_mmi.c: Version 2 of the optimizations for loongson mmi
[00:00:00 CEST] --- Tue May 31 2016