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

[burek]

[00:24:42 CEST] <storrgie> I have an ignorant noobish question... I'm trying to figure out how to record 20-60 machines visual and audio outputs while they are playing a game. I am OK to record this to their local disk and retrieve it later. When I asked some colleges about this they suggested things like Shadowplay and OBS as solutions... I was thinking, doesn't ffmpeg have desktop capture? Is there any glaring (e.g performance) reason that I should avoid trying to
[00:24:42 CEST] <storrgie> figure out how to use ffmpeg to do this?
[00:25:34 CEST] <JEEB> ffmpeg doesn't have heavily optimized screen capture inputs
[00:26:01 CEST] <storrgie> so there would be a performance impact? We have pretty beefy machines but they are being taxed pretty hard to play this game
[00:26:04 CEST] <JEEB> shadowplay just uses nvidia's internal APIs which bypasses the usual capture APIs at all
[00:26:24 CEST] <JEEB> it's the internal GPU stuff and straight to the hardware decoder chip
[00:26:33 CEST] <JEEB> *encoder chip
[00:26:54 CEST] <storrgie> I believe that there was some preliminary testing that concluded that shadowplay resulted in some form of degraded performance (which surprised me), and OBS was considered better... but I figured it would be using the same underlying subsystems as ffmpeg would be using
[00:27:59 CEST] <JEEB> OBS has various ways of encoding as well and it has a custom hooking thing
[00:28:18 CEST] <JEEB> behind the scenes I'm pretty sure that it uses FFmpeg's libraries to multiplex the output
[00:28:25 CEST] <JEEB> and possibly for encode after capture
[00:28:39 CEST] <JEEB> but the capture part is the primary thing that can bog you down
[00:28:47 CEST] <JEEB> together with the possible RGB to YCbCr conversion
[00:29:51 CEST] <storrgie> so, I might be being reductionist forgive me, your gutfeel is that this isn't a good bath to examine
[00:33:11 CEST] <storrgie> sorry, isn't a good idea to examine ffmpeg as a solution for capturing audio/video during gaming
[00:41:03 CEST] <Mavrik> No, ffmpeg is a horrible idea for gaming capture
[00:41:08 CEST] <Mavrik> There's a reason you have dedicated GPU APIs to do that
[00:41:09 CEST] <storrgie> ok thanks
[00:41:41 CEST] <storrgie> now i'm wondering if there is a programmatic way to drive shadowplay... and despising windows
[00:41:42 CEST] <Mavrik> You'll be starving the game itself of bus bandwidth and CPU
[00:42:03 CEST] <Mavrik> https://developer.nvidia.com/capture-sdk
[00:42:07 CEST] <Mavrik> It's one google away.
[00:42:23 CEST] <storrgie> I'd never heard of this
[00:42:27 CEST] <Mavrik> Or you can just use nVidias broadcasting software.
[00:42:34 CEST] <storrgie> I was hung on shadowplay directly, or GFE
[00:44:00 CEST] <storrgie> Mavrik, when you say 'broadcasting software' do you mean shadowplay?
[00:44:11 CEST] <Mavrik> No idea whats it called these days
[00:44:20 CEST] <storrgie> I think thats what its called now
[00:44:27 CEST] <storrgie> however I'll dig into capture-sdk
[00:44:28 CEST] <storrgie> thanks
[00:44:36 CEST] <Mavrik> I think Steam has its own solution using their APIs
[00:44:38 CEST] <Mavrik> And bunch of others
[00:44:59 CEST] <Mavrik> Might wanna check it before you spend weeks reinventing the wheel
[00:59:14 CEST] <Emerica> I there a way to change the PTS spacing in an encode? I've added B frames to a mpegts, upon doing so my analyzer find the PTS spacing to be over 700ms  by about 66-67ms
[01:01:40 CEST] <llogan> Dealing with the broadcast anal-yzer cartel, eh?
[01:03:06 CEST] <llogan> buy this analyzer so it can tell you it's "wrong" then but our muxer so it will do it right. Only $7000 USD each.
[01:09:14 CEST] <DHE> pfft. I've seen real broadcasts well over 1000 ms
[02:55:59 CEST] <kevinn> DHE: you online by anychance? I have a follow up to my question from yesterday
[02:59:36 CEST] <DHE> sadly not. but it's a big room
[03:02:06 CEST] <kevinn> Okay, well I am having a bit of trouble with latency. Per JEEB's suggestion earlier I can confirm that the frame I pass into libav from x264 is a keyframe that should be immediately decodable. However libav doesn't let me immediately decode it. It only lets me decode it after I send another frame with another picture in it.
[03:02:28 CEST] <kevinn> So I think now I just have libav misconfigured somehow
[03:05:20 CEST] <Tanner_> Hello.  Does ffmpeg currently support webrtc as an output?  Perhaps using openwebrtc signalling server?
[03:05:57 CEST] <Tanner_> If not, is it on the roadmap for future support?
[06:05:32 CEST] <lindenk> Hey, has anyone used ffmpeg for screen recording? For some reason, my fps slowly but consistently drops the further into the recording it gets. My CPU doesn't seem to be struggling either (I've even tried giving it more threads). Is there some bottleneck that I'm not thinking about?
[06:18:10 CEST] <akkad> low memory? slow disk?
[06:34:52 CEST] <teratorn> lindenk: what OS?
[06:36:21 CEST] <lindenk> arch linux. I'm pretty sure it's not a slow disk, it's the second fastest m.2 drive out there running on a 4 pci lanes and can normally write stuff faster than /tmp (well almost)
[06:36:54 CEST] <teratorn> could be xorg being terrible
[06:37:21 CEST] <lindenk> actually, I just tried another recorder and that seemed to work, maybe it's a codec or something?
[06:37:48 CEST] <teratorn> what do you mean another recorder?
[06:38:06 CEST] <lindenk> I tried simplescreenrecorder from the arch repos
[06:38:24 CEST] <lindenk> and it seemed to record at 60 fps without a problem
[06:38:26 CEST] <teratorn> ah
[06:39:04 CEST] <teratorn> well there you go
[06:39:10 CEST] <teratorn> actual software for doing a thing works better
[06:39:11 CEST] <lindenk> the weird thing is ffmpeg reported it was doing pretty well with specifically mp4, but the actual video was definately not the right fps
[06:39:34 CEST] <lindenk> well, I suppose so. I guess I just wanted a cli tool for it though, and ffmpeg is pretty common on everything
[06:40:10 CEST] <teratorn> i've never seen it do x11 screen recording well
[06:40:22 CEST] <teratorn> but that doesn't mean it can't
[06:40:55 CEST] <lindenk> maybe I should make that wayland switch at some point
[06:42:14 CEST] <teratorn> we all should, eventually
[08:08:39 CEST] <kepstin> wayland... doesn't really have any api for screen recording at all, though.
[08:08:50 CEST] <kepstin> (some compositors have built-in recording support)
[08:26:06 CEST] <Johnjay> you can't record the desktop in wayland...?
[10:06:45 CEST] <thebombzen> in theory you could use kmsgrab with wayland but it requires an iGPU
[10:58:38 CEST] <brendan_> Hey there. Quick question. I'm using the zeranoe build of ffmpeg to transcode using h264_qsv. Do I need to install the Intel Media Server Studio Essentials on every machine that I want to use this on?  It's a large download (~900MB). If that is required... is there a lightweight redistributable?
[11:03:37 CEST] <sim590> I have those two commands http://paste.debian.net/990145/ which I'd like to join together. In one, I try to record internal audio monitor (which I have set to default in pulseaudio) and in the second, I record my desktop and microphone.
[11:04:01 CEST] <sim590> The thing is that I don't achieve to join the two audio recording together in one command.
[11:05:16 CEST] <sim590> does it have to do with the fact that I try to use both alsa and pusle?
[11:22:13 CEST] <sim590> I have added -map 0 -map 1 -map 2 and I get:
[11:22:14 CEST] <sim590> Stream mapping:
[11:22:16 CEST] <sim590>   Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
[11:22:18 CEST] <sim590>   Stream #1:0 -> #0:1 (pcm_s16le (native) -> mp3 (libmp3lame))
[11:22:20 CEST] <sim590>   Stream #2:0 -> #0:2 (pcm_s16le (native) -> mp3 (libmp3lame))
[11:22:37 CEST] <sim590> But, I don't both sound inputs at the same time.
[11:48:54 CEST] <nvz> can I (more quickly than total transcode) just transcode only the audio portion of a video file. I have some files that are AVI(MP4/XVID w/ A52/AC3) and the bluray/media player I'm using only seems to support (from manual) MP3, WMA, PCM, Dolby Digital, DTS for audio on avi containers I'd just like to convert as painlessly as possible the audio to mp3
[11:49:16 CEST] <JEEB> yes
[11:49:40 CEST] <JEEB> -c copy (set all other streams to 'copy') -c:a ENCODER <settings>
[11:49:47 CEST] <JEEB> *set all streams to copy
[11:50:00 CEST] <JEEB> and the second is "override encoder for audio to ENCODER"
[11:51:07 CEST] <nvz> so something like ffmpeg -c copy -c:a mp3 video.avi
[11:51:42 CEST] <nvz> it'd still need to create a new file I would imagine, cant be done in place?
[11:53:35 CEST] <JEEB> can't be done in-place, yes
[11:53:55 CEST] <JEEB> so ffmpeg -i input.avi -c copy -c:a libmp3lame -b:a 192k out.avi
[11:54:10 CEST] <JEEB> (I think that's how the mp3 encoder is called)
[11:54:43 CEST] <nvz> I'm more familiar with mplayer/mencoder but ffmpeg seems to be the thing to use these days figured I'd ask rather than try wing it
[11:55:03 CEST] <JEEB> you can check the exact name of encoder a la `ffmpeg -codecs |grep mp3`
[11:55:35 CEST] <JEEB> or actually `ffmpeg -encoders |grep mp3`
[11:55:39 CEST] <JEEB> that limits it to encoders :)
[11:55:45 CEST] <nvz> oh, ok. I'm gonna set some presets in winff I guess to formats specified in this device's manual
[11:56:31 CEST] <nvz> so if I encounter any other files in the future that have been encoded in an incompatible format I can more easily fix em
[11:56:51 CEST] <JEEB> there's also ffprobe for probing files
[11:56:58 CEST] <JEEB> so you can even script things :D
[11:57:04 CEST] <nvz> oh really? I was wondering about that
[11:57:06 CEST] <JEEB> ffprobe -show_streams -of json file
[11:57:13 CEST] <JEEB> outputs the streams in the file as JSON
[11:57:43 CEST] <nvz> hmm.. never parsed json in bash, sounds more like a job for python
[11:57:49 CEST] <JEEB> yes, definitely
[11:57:57 CEST] <JEEB> from json import loads as parse_json
[11:58:08 CEST] <JEEB> then take the stdout and pass that to parse_json and you get a dictionary :)
[11:58:26 CEST] <JEEB> for stream in streams
[11:58:36 CEST] <nvz> I'm vaguely familiar, wrote a little json app to grab xkcd images as a ay to familiarize with it
[11:58:39 CEST] <JEEB> *for stream in dictionary.get("streams")
[11:58:55 CEST] <JEEB> and that lets you loop over the streams :)
[11:59:12 CEST] <JEEB> oh, and you probably want show_format
[11:59:17 CEST] <JEEB> which also shows the container
[11:59:40 CEST] <nvz> yes definately because the player seems to have different support of codecs for different containers
[11:59:53 CEST] <sim590> Ah I get it! Both audio end up in the container, but not mixed in in a single track. That's even better.
[12:00:07 CEST] <nvz> according to its manual anyhow, which from experience I know not to take mfg manuals on these kinda things as gospel :P
[12:00:50 CEST] <JEEB> yea. thankfully anything modern will take H.264 and AAC in mp4
[12:01:02 CEST] <JEEB> mostly just a case of profile support and level being <=4.1
[12:01:09 CEST] <JEEB> profiles = features
[12:01:27 CEST] <JEEB> usually I limit to high profile, level <= 4.1
[12:01:43 CEST] <Mavrik> 4.1 is up to 1080p ?
[12:01:59 CEST] <nvz> well in my experience they are really picky these bluray players with the build in media player.. they have odd requirments for bitrates, framerates, etc
[12:02:36 CEST] <JEEB> Mavrik: I usually don't think of devices that could do more, if I know they do I just feed shit at them :P
[12:02:51 CEST] <JEEB> nvz: blu-ray requires you to support up to 40mbps/40mbps
[12:02:57 CEST] <JEEB> *latter to 40 megabits
[12:03:01 CEST] <JEEB> which most things just don't hit
[12:03:07 CEST] <JEEB> and level 4.1 | high profile
[12:03:18 CEST] <Mavrik> Yeah, just clearing it up
[12:03:30 CEST] <Mavrik> 4.1 is reasonable yea :)
[12:03:30 CEST] <JEEB> of course the non-blu-ray parts can be limited weirdly more than the actual BD playback :P
[12:04:16 CEST] <nvz> I didn't test this file on mine, I'm just reorganizing some files for my neighbor who has a Smasung BD J5100 which seems to have mor features than my LG BP145 and his list said to just delete this file he wasnt real concerned about it but my computer plays it find and the only discrepency I see between what vlc tells me and what the manual pdf says is that it doesnt support A52/AC3 with avi
[12:04:28 CEST] <nvz> mine however would play such a file if only the audio was the problem
[12:04:37 CEST] <nvz> it'd just have no audio playback
[12:05:16 CEST] <nvz> I've even seen mine say "may" be incompatible on files then they work fine despite the error on playback
[12:05:56 CEST] <JEEB> with AVIs and such it's much more problematic
[12:06:07 CEST] <JEEB> since it's usualyl mpeg-4 part 2 and all that jazz
[12:06:18 CEST] <JEEB> I generally tend to limit myself to relatively not insane stuff
[12:06:39 CEST] <JEEB> MP4 container, H.264 video and AAC audio (although I've already verified AC-3 / DTS both work)
[12:10:44 CEST] <nvz> well in this case I didn't encode any of this stuff I'm just sorting files for him, into folders and he marked some files he said didn't play and I just figured if it wont take too long I can ix rather than remove them
[12:10:57 CEST] <nvz> *fix
[12:11:38 CEST] <nvz> he wanted me to rip all his movies and he has a ton of em.. hundreds undoubtedly.. and I just pirated em instead.. its faster :P
[12:11:44 CEST] <Mavrik> Yeah, I also keep to non-insane stuff
[12:12:04 CEST] <Mavrik> MP4 with H.264 (although I keep audio in DD/AC3 due to SPDIF limits)
[12:12:46 CEST] <nvz> I'd got him into this idea cause I was over there and he was saying he was running out of space to store all his dvds, and I mentioned he could get a hdd and use it on his bluray player, then I thought about how f'n long it'd take to rip all those
[12:14:31 CEST] <nvz> the quality would certainly have been more consistant as well as the filesize, but I think it was worth the time tradeoff to wind up with a few odd files
[12:18:19 CEST] <furq> nvz: does the tv not support mp4
[12:18:33 CEST] <furq> it'd be quicker to just remux to mp4 if it does
[12:23:59 CEST] <nvz>  according to the manual it supports AVI (V:Mp4v3,h264; A:mp3,wma,pcm,dts,dolby) MKV(V:VC-1AP,h264; A:mp3) mp4(V:m4v,h264;A:wma) mpg(V:mpg1,2,h264 A:mp1,2) as well as wmv which I have no intention of using
[12:25:14 CEST] <nvz> I figured it'd be quicker to just keep everything the same and just change the audio track since its the only thing I notice that seems incompatible
[13:26:04 CEST] <fx159159> Hey, does someone here have experience with programatically transcoding from dshow into another format and how "audio_buffer_size" affects the generation of frames/avpackets?
[13:27:04 CEST] <fx159159> I encode into opus which by default has a frame duration of 20ms, my code only produces audioframes/packages around every 20ms when audio_buffer_size is set to 20ms, otherwise the audio stutters
[13:27:26 CEST] <fx159159> the ffmpeg cli is fine with an audio_buffer_size of 50 and still puts out an audio frame every 20ms
[13:29:45 CEST] <fx159159> Also I'm using QtAV as a wrapper between qt/c++ and ffmpeg libs
[15:11:02 CEST] <arpu> hi on ffmpeg master what hardware encoder for nvidia and h264 should i use h264_nvenc , nvenc or nvenc_h264 ?
[15:46:39 CEST] <BtbN> arpu, the name that's not deprecated.
[15:47:02 CEST] <arpu> BtbN,  how can i see what is deprecated?
[15:47:19 CEST] <BtbN> It throws a big warning if you pick one that's deprecated.
[15:53:30 CEST] <fx159159> Does ffmpeg buffer packets internally when reading from dshow?
[16:12:06 CEST] <arpu> BtbN, thx
[16:28:41 CEST] <fx159159> Say for example I get a AVPacket from av_read_frame with duration of 50000 but my codec outputs 20000 frames, does the codec split automatically? I'm using opus
[16:51:02 CEST] <sagax> hi all!
[16:51:44 CEST] <sagax> i record video like this -  ffmpeg -y -video_size 1280x800 -framerate 30 -f x11grab -i :0.0 -strict -2 -qscale 0 "$name".flv
[16:52:09 CEST] <sagax> but how to set position video? like as  1280x800+100+100 ?
[16:53:50 CEST] <jkqxz> Append to the display name as "+X,Y".
[17:00:20 CEST] <sagax> how to do this?
[17:01:05 CEST] <sagax> x11grab -i :0.0+100+100 ?
[17:02:44 CEST] <jkqxz> Second '+' should be ','.
[17:02:44 CEST] <sagax> x11grab -i :0.0+100,100
[17:02:48 CEST] <jkqxz> Yes.
[17:02:53 CEST] <sagax> got it, thanks
[17:07:37 CEST] <SpeakerToMeat> Hello peoples
[17:08:23 CEST] <SpeakerToMeat> Question, is there any way to concat and mux two sets of files at once? let's say I have 1.mov and 2.mov with a single stream of video each and 1.wav and 2.wav with a single stream of audio each, can I concat 1+2 of each set and mux them into output at once?
[17:08:49 CEST] <SpeakerToMeat> I think maybe with graphs but not sure how to use them fully yet
[17:08:50 CEST] <Mavrik> Probably yeah
[17:13:58 CEST] <Johnjay> yes using filter_complex. but it's... very complex!
[17:14:37 CEST] <kepstin> for this case, it shouldn't be that bad, actually. Is the audio in 1.wav synced with the video in 1.mov and same for 2.wav and 2.mov?
[17:14:39 CEST] <DHE> https://ffmpeg.org/ffmpeg-filters.html#concat   It's not THAT bad. check the examples
[17:15:05 CEST] <kepstin> should just be a matter of putting the inputs in the right order and using -filter_complex with a single concat filter if that's the case
[17:15:44 CEST] <DHE> for split files, maybe two concat filters like the second example suggests.
[17:16:35 CEST] <DHE> actually never mind that since you need to select your streams anyway
[17:19:42 CEST] <SpeakerToMeat> kepstin: It is
[17:44:19 CEST] <Emerica> @logan /DHE  (PTS spacing)  No , not dealing with  $7000 analyser software (ewww) ,  I have scripts to check files against ETR-290
[17:46:24 CEST] <DHE> wut?
[17:46:56 CEST] <DHE> oh...
[17:46:59 CEST] <Emerica> Yesterday: Is there a way to change the PTS spacing in an encode? I've added B frames to a mpegts, upon doing so my analyzer find the PTS spacing to be over 700ms  by about 66-67ms
[17:47:13 CEST] <Emerica> and you said you've seen them over 1000 I think
[17:47:27 CEST] <DHE> yeah. on real broadcasts
[17:47:55 CEST] <DHE> I have a monitor that checks our multicast-based feeds (I work for a telecom that does TV) and I've seen that happen
[17:48:07 CEST] <Emerica> llogan was mentioning the expensive software, I got sick of that stuff lol
[17:48:50 CEST] <Emerica> Yeah, I'm taking another stab at an ffmpeg approach, it's been a few years, last time the ac3 was failing so we went back to muxing with manzanita
[17:50:27 CEST] <Emerica> Pretty close to replicating the ts structure now and having it stay compliant, things just get pushed out a little if I attempt to use B frames
[17:56:10 CEST] <alexp> Anyone have any word on progress with AMD VCE on Windows?
[19:17:26 CEST] <kevinn__> Hi all, I am having a bit of trouble with libav. Specifically av_parser_parse2. I have tried passing it a single IDR frame encoded with x264 but it never returns renderable data (even though the IDR frame should be renderable by itself). It is important to note that it does become renderable when I pass it in another frame, but it should be immediately renderable.
[19:17:37 CEST] <kevinn__> Any help would be SO greatly appreciated
[19:54:47 CEST] <subli> I've done lots of subtitle extraction but this one I won't understand :(
[19:54:53 CEST] <subli> "Stream #0:12 -> #0:0 (dvd_subtitle (dvdsub) -> ass (ssa))"
[19:55:06 CEST] <subli> "Only SUBTITLE_ASS type supported."
[19:55:34 CEST] <subli> Nvm
[19:55:41 CEST] <subli> They're all dvd_subtitles
[19:56:03 CEST] <subli> I was just trying to figure out my VLC wouldn't play my .ssa subtitles...
[20:21:15 CEST] <Hopper__> Okay, finished my python program to update the data file I will be adding to my ffmpeg stream.  Sadly the atomic method of updating my file doesn't appear to actually be atomic.
[20:21:48 CEST] <Hopper__> Is there a way I can get FFMPEG to ignore when a text file can not be read?
[20:25:10 CEST] <thebombzen> Hopper__: what do you mean? ffmpeg does not check read permissions on a file before reading from it. if it can't read from it, it'll just print an I/O error and exit
[20:25:30 CEST] <thebombzen> however, Python can do this, so why can't you just check in Python
[20:29:00 CEST] <Hopper__> I am using https://docs.python.org/3/library/os.html#os.replace which says it is an atomic file operation.
[20:29:25 CEST] <Hopper__> So I was hoping there might be a simple way to ignore the error in FFMPEG instead.
[20:35:34 CEST] <Hopper__> thebombzen: Is that what you are referring to?
[20:36:11 CEST] <thebombzen> well if the file is not readable, you can't exactly ignore that and read it anyway
[20:38:02 CEST] <kepstin> Hopper__: hmm, you're on windows, right? That function would work properly on linux, ffmpeg would either read the old file or new file :/
[20:40:24 CEST] <kepstin> Atomic file replacement on windows is hard, but you might be able to find some python libraries that can do it with a little googling.
[20:40:32 CEST] <Hopper__> Ugh...
[20:40:55 CEST] <Hopper__> kepstin: Thanks, I'll poke around for a windows library.
[20:43:19 CEST] <kepstin> hmm, although it looks like if you're using python 3.3 or later, the os.replace *should* work on windows
[20:45:10 CEST] <kepstin> you have to be using ntfs, and the temp file has to be on the same drive/filesystem as the detination, of course.
[20:57:06 CEST] <Hopper__> kepstin: I meet all those requirements and I'm still getting failures.
[21:46:53 CEST] <alexpigment> does anyone recall off the top of their head if main 10 x265 encoding is considerably slower than main profile (8-bit)
[21:46:54 CEST] <alexpigment> ?
[21:47:18 CEST] <alexpigment> this encode is taking a long time and if it's the 10-bit part, i'll kill it and start an 8-bit encode instead
[22:10:56 CEST] <kepstin> 10bit is slower in x264, fwiw, i would expect that also to be true for x265
[22:11:17 CEST] <JEEB> x265 is still slow in any case compared to AVC encoding
[22:14:01 CEST] <alexpigment> yeah, I just decided to let it keep going
[22:14:28 CEST] <alexpigment> Since I was already 33% of the way or so, I didn't want to restart unless it was *significantly* slower compared to 8-bit
[22:14:40 CEST] <alexpigment> thanks for the info though
[22:15:13 CEST] <alexpigment> and yes, x265 is slow as hell :) i'm only doing this to test GPU-acclerated decoding on various cards
[22:15:20 CEST] <alexpigment> otherwise, i'd be sticking with good ol' x264
[22:15:29 CEST] <JEEB> I should do my next encoding test one of these days
[22:15:51 CEST] <JEEB> to see if you can findally get some good things from x265 other than in very low bit rate scenarios where you get artifacts
[22:16:33 CEST] <alexpigment> I mean I'm sure x265 is great, but it's just not ready for prime time in terms of streaming content delivery, which is the whole point of x265 imho
[22:16:59 CEST] <alexpigment> if you're not trying to stream or otherwise keep file sizes really small, you would just use x264 and eat the additional bitrate costs
[22:17:50 CEST] <JEEB> well even with network transfer limited stuff the use case where I've so far seen gains from x265 is basicaly "so low that you get major artifacts on both sides"
[22:17:55 CEST] <JEEB> where x265 just ends up having less
[22:18:02 CEST] <alexpigment> right
[22:18:03 CEST] <JEEB> I am not aiming at that level in any case
[22:18:13 CEST] <alexpigment> I mean I still think the same applies to any new video codec
[22:18:20 CEST] <alexpigment> H.264 was the same thing
[22:18:26 CEST] <JEEB> not really
[22:18:31 CEST] <JEEB> mpeg-4 part 2 to AVC
[22:18:39 CEST] <JEEB> I mean sure, at first there was less psychovisual optimization
[22:18:47 CEST] <JEEB> but already circa 2007-8 you had pretty darn good results
[22:19:03 CEST] <JEEB> CABAC and stuff just helps a crapload
[22:19:06 CEST] <alexpigment> well, the point I'm making really is just that it's being used in really low bandwidth situations to justify a new standard
[22:19:14 CEST] <alexpigment> even though higher bitrates of the older standards are just as good
[22:19:58 CEST] <JEEB> well no, I don't mismatch standards and encoders like that. I believe that you can actually optimize an encoder to improve on top of the previous gen stuff on higher bit rate scenarios as well. it's all dependent on where the effort is put
[22:19:59 CEST] <alexpigment> I can barely watch anything on YouTube because they're under this impression that 2-3mbps 1080p H.264 is "OK"
[22:20:28 CEST] <JEEB> with HEVC it's just that a lot of the new tools seem to be really easy to optimize for PSNR :P
[22:20:41 CEST] <kevinn__> Does libav determine whether or not to allow a x264 frame to render based on time stamp? I am having trouble getting just one single x264 IDR frame to render... And if libav does take time into account how to I make it stop doing that?
[22:20:42 CEST] <JEEB> and x265 doesn't have enough people who care about that stuff to do psychovisual optimizations
[22:20:45 CEST] <alexpigment> yeah, I guess I was really just talking about H.265 rather than the encoder itself, but yes, I see your point
[22:20:58 CEST] <JEEB> that's the issue with projects that don't have a wider community around them
[22:21:04 CEST] <JEEB> like libvpx and x265
[22:21:12 CEST] <JEEB> vpx has GOOG, x265 has mcw
[22:21:16 CEST] <JEEB> and that's pretty much it :P
[22:21:39 CEST] <JEEB> that said, x265 *is* the least bad HEVC encoder on the market right now. so as a sales tool it's working
[22:21:49 CEST] <JEEB> (probably, I have no info on MultiCoreWare's income)
[22:23:47 CEST] <alexpigment> whatever encoder Adobe Premiere uses is actually pretty fast and the results are fine at the bitrates I used
[22:24:12 CEST] <alexpigment> I would assume they're one of the bigger players in the H.265 creation market
[22:24:52 CEST] <JEEB> I wouldn't be surprised if that was either a hw encoder, or libx265
[22:25:00 CEST] <JEEB> although I guess adobe is still with mainconcept?
[22:25:10 CEST] <JEEB> mainconcept/divx I tested in 2013 I think?
[22:25:17 CEST] <JEEB> it was... bad, then
[22:25:28 CEST] <JEEB> and since then it's just :effort: to test it
[22:25:39 CEST] <JEEB> alexpigment: also it's not like you can't make x265 faster
[22:25:48 CEST] <JEEB> set the preset to something faster and it can go faster
[22:26:57 CEST] <alexpigment> JEEB: true, I haven't tested the presets' relative speeds in a while
[22:27:14 CEST] <alexpigment> I think I just remember that as the presets get faster, you lose the whole point of using it over x264
[22:27:29 CEST] <JEEB> E_NOT_SURPRISING, but not like you were comparing then either
[22:27:39 CEST] <alexpigment> Admittedly, I don't know. I don't personally believe in the H.265 standard and so I don't use it for my own personal use ever
[22:27:39 CEST] <JEEB> you just noted that you wanted more speed with HEVC, so that way you could get it
[22:27:58 CEST] <JEEB> I like the standard but I don't see it being relevant for my use cases yet
[22:28:18 CEST] <JEEB> as in, the used time and the result don't match :P
[22:28:33 CEST] <JEEB> at this point I'm waiting for AV1 to get frozen
[22:28:47 CEST] <alexpigment> oh, i didn't need more speed earlier. I just wanted to make sure whether I should stop my current encode and change settings, or let it finish out because I was already 33% into it. If someone said it was 2x faster or more to do 8-bit, I would have aborted
[22:29:12 CEST] <JEEB> I've only encoded 10bit with x265 anyways, there IMHO isn't a real reason to not use 10bit with it
[22:29:19 CEST] <JEEB> since pretty much all hwdecs support 10bit even
[22:29:32 CEST] <alexpigment> computers struggle with it though
[22:29:43 CEST] <alexpigment> which is why it's a really confusing standard ;)
[22:29:55 CEST] <JEEB> because the decoder is slow, yes. although 1080p worked for me I think even on my Core 2 Duo
[22:30:14 CEST] <alexpigment> well at least on Windows 7, the files don't really play correctly at all
[22:30:30 CEST] <JEEB> --hwdec=dxva2-copy with mpv WorksForME
[22:30:41 CEST] <JEEB> and if swdec no params needed
[22:30:54 CEST] <JEEB> and mpv pretty much is on top of libavcodec
[22:31:13 CEST] <JEEB> also libavcodec has all those test files in the FATE test suite :P
[22:31:21 CEST] <JEEB> so if the decoder was borked, it would be noticed
[22:31:22 CEST] <alexpigment> maybe the problem is that Windows 7 doesn't correctly push you to hardware for 8-bit and software for 10-bit
[22:31:30 CEST] <alexpigment> (if the hardware doesn't support main 10)
[22:31:32 CEST] <alexpigment> brb
[22:31:42 CEST] <JEEB> Windows 7 doesn't come with hw decoders by default, it's more likely something else in your chain
[22:32:12 CEST] <JEEB> I recommend checking a build from https://mpv.srsfckn.biz/ with --hwdec=dxva2-copy
[22:32:38 CEST] <JEEB> (and there pretty much are *no* windows/lunix hwdecs that don't support 10bit HEVC if they support HEVC at all)
[22:38:43 CEST] <alexpigment> back
[22:39:02 CEST] <alexpigment> pretty sure nvidia, intel, and amd all have generations of GPUs that do HEVC 8 but not HEVC 10
[22:39:28 CEST] <JEEB> as far as I know nvidia at least doesn't
[22:39:34 CEST] <JEEB> I have both 9 and 10 series stuff
[22:39:37 CEST] <JEEB> and 8 series didn't support it
[22:39:40 CEST] <alexpigment> Feature Set E versus F
[22:39:44 CEST] <alexpigment> https://en.wikipedia.org/wiki/Nvidia_PureVideo
[22:40:21 CEST] <JEEB> > partial decoding
[22:40:28 CEST] <JEEB> yea, makes sense since it¨s not actual hwdec
[22:40:48 CEST] <alexpigment> Intel has the same thing on some cards
[22:40:56 CEST] <JEEB> yes, I know. not counting those into hwdec
[22:40:57 CEST] <alexpigment> Braswell at the very least
[22:41:10 CEST] <alexpigment> I think we're probably talking about different things
[22:41:19 CEST] <alexpigment> I'm just saying hardware that is programmed to decode the formats
[22:41:29 CEST] <JEEB> well, it's pretty dang clear that that is not that
[22:41:31 CEST] <alexpigment> at any rate, this is all academic ;)
[22:41:41 CEST] <JEEB> it's using the GPU side of things to try and accelerate something
[22:41:53 CEST] <JEEB> while most if not all of the actual decoding is done on the cPU
[22:41:59 CEST] <JEEB> at least with intel it was pretty much the CPU
[22:42:04 CEST] <JEEB> so calling that hwdec is rather...
[22:42:18 CEST] <JEEB> not even sure if those are exported through DXVA2
[22:42:23 CEST] <alexpigment> I mean they do keep it locked down to the GPU in a way
[22:42:37 CEST] <JEEB> the gpu doesn't have the hardware to decode those formats
[22:42:43 CEST] <JEEB> don't try to wiggle around
[22:42:43 CEST] <alexpigment> Intel's chips that don't have HD Graphics don't have decoder or encoder capabilities
[22:42:45 CEST] <JEEB> it either has or doesn't
[22:43:35 CEST] <JEEB> it's as if I was saying my goddamn GTX 9600 from 2008 had VC-1 hwdec. yes, it would work with nvidia's own decoding API, but it was not hwdec in the least
[22:43:36 CEST] <alexpigment> also what do you mean by "those formats"?
[22:43:43 CEST] <JEEB> HEVC
[22:44:10 CEST] <alexpigment> so my Nvidia 1060 doesn't fully decode HEVC on the GPU?
[22:44:24 CEST] <JEEB> it does, you were trying to bring up goddamn motherfucking feature level E into the play
[22:44:37 CEST] <alexpigment> oh right. I didn't know where you were going with that
[22:44:42 CEST] <JEEB> by trying to say that there's PC hwdecs that don't handle 10bit
[22:44:59 CEST] <alexpigment> I understand what you're saying now
[22:45:11 CEST] <alexpigment> I'll take your word for it on those feature sets
[22:45:16 CEST] <JEEB> you don't have to
[22:45:22 CEST] <alexpigment> I just did
[22:45:25 CEST] <JEEB> just see the fucking wikipedo article you linked
[22:45:59 CEST] <JEEB> I think some ARM things might have had hwdecs that couldn't do 10bit
[22:46:11 CEST] <JEEB> but already in 2015 a lot of them did, and that number only went up
[22:46:30 CEST] <JEEB> because with HEVC and the whole HDR meme 10bit finally hit prime time
[22:47:24 CEST] <alexpigment> right
[22:47:37 CEST] <JEEB> and thus, I have pretty much noted that it makes no sense to HEVC without 10bit (´4@)
[22:47:50 CEST] <JEEB> if you use HEVC at all, that is
[22:48:15 CEST] <alexpigment> fair enough
[22:48:32 CEST] <alexpigment> at the very least, 10-bit support wasn't always there
[22:48:47 CEST] <alexpigment> either it came through an update or a latter generation in the case of some (non-nvidia) cards
[22:48:49 CEST] <JEEB> I agree with ARM SoCs for that
[22:48:53 CEST] <JEEB> but not PCs
[22:48:58 CEST] <alexpigment> k
[22:49:25 CEST] <JEEB> because PCs never had ACTUAL HWDEC that didn't support 10bit (at least in the major producers that you noted, AMD|nvidia|intel)
[22:49:47 CEST] <JEEB> the half-hwdec usually is limited to the vendor-specific APIs too
[22:50:03 CEST] <JEEB> well, even less since I bet they couldn't run a lot of stuff on the GPU parts
[22:50:26 CEST] <JEEB> (as in, there is no ASIC so they have to use the actual shaders)
[22:57:41 CEST] <jkqxz> Um, no.  Intel in Braswell and Skylake, and AMD in GCN 3, had 8-bit but not 10-bit H.265 decode.
[22:58:17 CEST] <JEEB> jkqxz: are those actual hwdecs, though?
[22:58:19 CEST] <JEEB> that was my point
[22:58:30 CEST] <jkqxz> Yes.
[22:58:48 CEST] <JEEB> so they are actual ASIC-based not software-backed commonly dxva2-usable hwdecs?
[22:58:52 CEST] <jkqxz> Yes.
[22:58:56 CEST] <JEEB> huh
[22:59:10 CEST] <JEEB> although wasn't braswell just mentioned as a CPU-based hybrid?
[22:59:12 CEST] <jkqxz> There were shader versions for Haswell and Broadwell, which are... not good.
[23:30:31 CEST] <DocHopper> kepstin: After lots of tinkering, it appears that atomic updates are impossible with python in windows.
[23:32:17 CEST] <DocHopper> Anyone here have a good idea of how to get a live text stream on a live video?
[23:35:51 CEST] <JEEB> your own API client
[23:40:35 CEST] <alexpigment> [reading rest of convo from earlier]
[23:41:04 CEST] <alexpigment> as I mentioned other desktop vendors did the same thing, although it's unclear if AMD's 10-bit HEVC support came from a second generation or from a later update
[23:41:14 CEST] <alexpigment> Intel definitely had a generation of only 8-bit support though
[23:41:30 CEST] <alexpigment> again, this is really just academic at this point - not trying to get into arguments about it ;)
[23:42:43 CEST] <DocHopper> JEEB: There is really no integration between FFMPEG and any other programs/languages?
[23:43:12 CEST] <durandal_1707> yes. C
[23:44:19 CEST] <DocHopper> Is there a good source of documentation on this?
[23:44:28 CEST] <JEEB> yes, doc/examples for example
[23:44:31 CEST] <JEEB> and then there's the doxygen
[23:44:48 CEST] <JEEB> like https://ffmpeg.org/doxygen/trunk/group__lavf__decoding.html
[00:00:00 CEST] --- Thu Oct 12 2017