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

[burek]

[00:08:15 CET] <Taity> hi
[00:09:12 CET] <Taity> i am using ffmpeg with cuvid accel and nvenc, and i getting a green vertical green line, the video size is 854 x 480
[00:09:32 CET] <Taity> this is the command line i am using: ./ffmpeg -v debug -y -hwaccel cuvid -c:v h264_cuvid -deint adaptive -resize 864x480 -i ./54voONSXMrc.mkv -vcodec h264_nvenc /mnt/disk2/hls/video/out.mp4
[00:09:46 CET] <Taity> is a bug on h264_cuvid ?
[00:10:29 CET] <Taity> here https://live01.tvpublica.com.ar/video/ you can get original and the trancoded video
[00:10:37 CET] <Taity> to view the results
[00:13:09 CET] <Taity> some body can help me?
[00:13:19 CET] <Taity> Thanxs
[00:15:02 CET] <FishPencil> So it looks like FFmpeg is unhappy with the version of AMF that's found. I'm using version 1.4.4. Here's the output: https://paste.ubuntu.com/26150370/
[00:15:49 CET] <JEEB> looks like it needs just something newer than 1.4.4
[00:15:54 CET] <JEEB> (1.4.4.1+)
[00:16:51 CET] <FishPencil> Sooo git? I don't see a 1.4.4.1
[00:21:00 CET] <JEEB> most likely
[00:24:05 CET] <FishPencil> Looks like yes, it's building now
[00:25:44 CET] <Sun> Seems, my problem is solved, thank You all very much :)
[01:00:18 CET] <furq> oh wow, amf
[01:08:33 CET] <ArsenArsen> anyone got a C x11grab example. I'm wondering how to do it programatically
[01:09:09 CET] <ArsenArsen> (I meant to put a question mark there, oops)\
[01:12:21 CET] <DHE> ArsenArsen: to a certain degree ffmpeg features all operate the same way. you can specifically requst the x11grab demuxer, specify ":0.0" like it was a filename and pass your other input command-line parameters in the AVDictionary
[01:13:18 CET] <ArsenArsen> I've noticed they operate the same, and it's amazing, but the real thing killing me right now is how do I manage to sync up the timings properly so it's neither slower nor faster than the required speed.
[01:14:32 CET] <DHE> that's handled by x11grab itself, as long as you pull data from it fast enough that it doesn't backlog internally. specify a "framerate" in the AVDictionary to specify how fast
[01:15:02 CET] <DHE> ffmpeg -h demuxer=x11grab # and see what's available
[01:16:32 CET] <ArsenArsen> alright, so I assume it'll wait until the time's right?
[01:23:22 CET] <ArsenArsen> but, another one, does the same apply with GDIGrab or whatever it is on windows
[01:23:34 CET] <ArsenArsen> and avifoundation, the mac one
[01:24:01 CET] <DHE> don't see why not. query them in the same way (on their respective platforms) to see what options they offer
[01:26:52 CET] <ArsenArsen> alright, thank you!
[02:50:51 CET] <kepstin> The timing code in gdigrab is just borrowed from x11grab, yeah
[02:52:00 CET] <kepstin> other interfaces like webcams and avfoundation, dshow? do timing externally, so ffmpeg just blocks until a frame is available iirc.
[04:41:12 CET] <TheRock> Hello i was in the channel #ffmpe, but it doesnt exist
[04:43:00 CET] <furq> i don't know what to do with this information
[04:44:33 CET] <DHE> I've noted it for future reference and will assign someone to idle in that channel
[04:51:46 CET] <TheRock2> if we put 100 idler in #ffmpe, #ffmp, #ffm, #ff. we could cover typing mistakes
[04:51:58 CET] <DHE> 2 should be sufficient...
[04:52:01 CET] <DHE> I have one
[04:58:00 CET] <TheRock2> how do you control the bots ?
[04:58:15 CET] <TheRock2> Assuming 350 bots in this channel, anyone must have access to them
[05:01:11 CET] <rajkosto> so theres absolutely no way to 1. get frames as soon as they are decoded in decode order 2. have each frame be marked with picture_number
[05:01:46 CET] <rajkosto> in ffmpeg ? i can get that stuff off hardware decoders, and i had to do horrible buffering hacks for the ffmpeg way to accomplish this, since it doesnt fill in display_picture_number in avframe (only coded_picture_number)
[05:17:38 CET] <kepstin> rajkosto: the libavcodec apis all return frames in presentation order (they're buffered and reordered in the decoder). Why do you want them in decode order?
[05:18:11 CET] <kepstin> that said, the dts values should be passed through to the decoded frames, so you should be able to re-sort them yourself
[05:18:14 CET] <aiena1> I have wbm video and m4a audoio gow do I merge these into one file?
[05:18:19 CET] <aiena1> *webm
[05:18:23 CET] <aiena1> *audio
[05:18:28 CET] <aiena1> what container is appropriate
[05:18:41 CET] <kepstin> you just want it for local playback?
[05:19:07 CET] <kepstin> probably use mkv container then, so something like "ffmpeg -i video.webm -i audio.mp4 -c copy combined.mkv"
[05:21:36 CET] <aiena1> kepstin: yes
[05:22:02 CET] <aiena1> also just curious if given a choice between vp9 and mp4 if size was not a concern which would provide better quality?
[05:22:39 CET] <kepstin> if size isn't a concern it doesn't matter, because you can do lossless with both :)
[05:22:54 CET] <aiena1> actually that is a bad question would be based on how the encoding was done
[05:23:31 CET] <aiena1> just curious about whether youtube vp9 videos are better quality than the mp4 equivalents or the same
[05:23:58 CET] <kepstin> it looks like vp9 provides comparable or somewhat better efficiency (quality per bit) than h264, but the libvpx encoder for vp9 is a lot slower than the x264 encoder for h264
[05:24:29 CET] <kepstin> in youtube's case specifically, I think the vp9 encode is usually their highest quality encode.
[05:25:43 CET] <kepstin> (If you're downloading videos from youtube, just use youtube-dl and let it pick the "best" format, it can even merge the result into an mkv for you)
[05:27:47 CET] <aiena1> kepstin: I am using youtube-dl only I use d acomma instead of a plus
[05:32:21 CET] <furq> 04:24:28 ( kepstin) in youtube's case specifically, I think the vp9 encode is usually their highest quality encode.
[05:32:24 CET] <furq> yeah it is
[05:32:39 CET] <furq> they use roughly the same bitrate for both and i would assume they're using the best settings for libvpx
[05:32:52 CET] <furq> on account of they want to push it as a superior format and also on account of how long it takes for vp9 to show up
[05:44:31 CET] <rajkosto> kepstin, pts/dts are passed as opaque values yes
[05:44:38 CET] <rajkosto> but what if im just decoding an annex-b NAL stream
[05:44:56 CET] <rajkosto> and i still want the frames in decode order so that i can reorder them myself
[05:45:51 CET] <rajkosto> so i need decode order and reordering info, if i dont need the latter (if im getting the NALs via RTP or similar) then im ok with just 1. which i can already do by giving avcodec_decode_frame a NULL pkt
[05:46:38 CET] <kepstin> i'm still a bit confused as to why you want the frames out of order in the first place, rather than just letting ffmpeg reorder than into presentation order
[05:49:58 CET] <aiena1> kepstin: when I merge the webm and the mkv I get some artifacts in the video
[05:50:05 CET] <aiena1> *webm and m4a
[05:53:10 CET] <aiena1> kepstin: I get this one second pixelation in between which on playing the original webm video is not there
[05:53:46 CET] <kepstin> aiena1: that's really strange, i'm not sure what could cause that :/
[05:54:25 CET] <rajkosto> kepstin, i just do. its not a very strange use case for the application to want to reorder the frames itself
[05:54:44 CET] <aiena1> kepstin: actually sorry it is there in the original video it was hard to find the exact point
[05:56:14 CET] <kepstin> rajkosto: it is a pretty strange use case, really; there's hundreds of apps out there using ffmpeg in part because they don't want to have to care about internal codec details like out-of-order predicted frames :/
[05:57:42 CET] <kepstin> either way, there's no way to get un-reordered frames from libavcodec using public apis, afaik.
[05:58:17 CET] <kepstin> you might be able to do it using internal apis, e.g. by calling the specific video decoder directly, but i honestly wouldn't know where to start.
[05:59:08 CET] <rajkosto> i told you how i can do it
[05:59:19 CET] <rajkosto> but you broke that in 3.3 and later
[05:59:48 CET] <rajkosto> in 3.2 it works though, just feed a null avpkt to the "deprecated" decode2 interface after youre sure you fed it enough for a full frame
[06:00:09 CET] <rajkosto> but it doesnt mark the resulting avframe in any way about the reodering info, neither can i get it with internal contexts
[06:01:15 CET] <kepstin> sending a null packet is how you indicate end of stream tho, so you couldn't use that for continuous decoding anyways?
[06:01:30 CET] <rajkosto> it works on 3.2
[06:01:37 CET] <rajkosto> i put one frame in, get one frame out
[06:01:56 CET] <rajkosto> its not marked with reordering info in any way though, so if im playing a raw annex-b stream i have no clue what its presentation order is
[06:02:38 CET] <rajkosto> the solution would be for the decoder to just mark the avframe with display_picture_number like it does with coded_picture_number
[06:02:54 CET] <rajkosto> display_picture_number is always 0 for me, maybe im doing something wrong
[06:04:16 CET] <kepstin> well, if you're only decoding one frame, of course it'll always be the first frame?
[06:05:24 CET] <rajkosto> im not
[06:05:30 CET] <rajkosto> and this happens even if i dont do the null packet dance
[06:05:43 CET] <rajkosto> also how is it "the first frame" when coded_picture_number is increasing ?
[06:06:28 CET] <kepstin> sending a null packet means "end of stream, flush the decoder", and continuing to use the encoder after that is undefined behaviour
[06:06:55 CET] <kepstin> and if you don't do that, you should be getting frames in presentation order, with *something* useful in the pts and probably dts fields.
[06:07:10 CET] <aiena1> kepstin: does ffmpeg have a vp9 encoder?
[06:07:29 CET] <aiena1> vp9 has creates really small file sizes with very little loss in quality
[06:07:32 CET] <kepstin> aiena1: not built-in, but it can encode vp9 using the libvpx library
[06:07:41 CET] <rajkosto> kepstin, no, what i get in pts/dts is just what i put in the avpacket pts/dts
[06:07:47 CET] <aiena1> so how do I do that on say ubuntu?
[06:07:50 CET] <rajkosto> if i put nothing there or AV_NOPTS_VALUE i still get that back
[06:08:22 CET] <rajkosto> kepstin, before 3.3, sending a null packet does not do that. you have to manually do avcodec_flush_decoder
[06:08:25 CET] <kepstin> rajkosto: oh, you're putting nals directly into the decoder, rather than going through ffmpeg's parser?
[06:08:38 CET] <rajkosto> im putting annex-b chunks of nals for exactly one frame each time
[06:09:03 CET] <aiena1> kepstin: oh ffmpeg needs to be compiled with vp9 support?
[06:09:06 CET] <rajkosto> even with ONLY this information, it KNOWS how to reorder the frames if i dont flush it with NULL each time
[06:09:12 CET] <aiena1> so I need to build from source?
[06:09:16 CET] <kepstin> aiena1: with libvpx support, yes.
[06:09:30 CET] <kepstin> most ffmpeg packages should have that by default nowadays...
[06:09:52 CET] <rajkosto> i just want to get this reordering information out WITHOUT actually introducing the max_num_b_frames latency beefore i can get pixels out
[06:09:56 CET] <aiena1> kepstin: how do I check if mine has it?
[06:10:29 CET] <kepstin> aiena1: "ffmpeg -h encoder=libvpx-vp9" should print several pages of options if you have it
[06:13:01 CET] <aiena1> kepstin: hmm there is a  --enable-libvpx
[06:13:11 CET] <aiena1> but no -vp89
[06:13:16 CET] <aiena1> is libvpx vp8?
[06:13:24 CET] <kepstin> aiena1: libvpx encodes both vp8 and vp9
[06:13:26 CET] <rajkosto> i just need to fill hardware buffers with frames  as soon as i decode the input frame, it doesnt matter if its not in presentation order as long as i can mark it
[06:13:37 CET] <aiena1> kepstin: ok so I have it that means
[06:13:50 CET] <aiena1> now ned to see how to rencode an mp4
[06:13:55 CET] <aiena1> need
[06:14:02 CET] <aiena1> let me dig up documentation
[06:14:08 CET] <aiena1> ffmpeg is huge though
[06:14:12 CET] <kepstin> aiena1: don't re-encode an mp4 if you don't have to, it'll *always* drop in quality since it's a lossy-lossy decode
[06:14:17 CET] <rajkosto> there's no need for ffmpeg to reorder the frames for me as i will be doing it myself, right now i have to hack around this "feature"
[06:14:38 CET] <kepstin> rajkosto: it sounds like you're trying to do something that the ffmpeg api doesn't support, and were previously making use of undocumented/undefined behaviour to do it, which broke.
[06:14:44 CET] <rajkosto> by lying to the API user and stashing buffers around until i can fill them, and the performance isnt consistent because of it
[06:14:52 CET] <aiena1> kepstin: ok
[06:14:57 CET] <rajkosto> kepstin, no. i was NEVER able to get the reorder info out !
[06:15:02 CET] <rajkosto> im fine with staying on 3.2
[06:21:03 CET] <kepstin> rajkosto: at this point, the best I could suggest is filing a ticket saying "please add an api to get un-reordered frames (with reordering info)" and hoping that you can find someone other than you who wants this to help out :/
[06:21:15 CET] <kepstin> but it would be really painful to add, would require modifications to all the decoders
[06:21:58 CET] <rajkosto> or they could just not have the decode2 api be a wrapper around the new push/pull apis (which are the first one to designate null packets as end of stream), and then just fill in display_picture_number
[06:22:20 CET] <rajkosto> actually it might be pretty easy to fill in display_picture_number myself by editing the decoder, but ffmpeg is written in an entirely "mess of C code" way that its indecipherable
[06:33:06 CET] <Aelius> I found a very weird bug
[06:33:12 CET] <Aelius> https://i.imgur.com/yuGZ5ny.png
[06:37:01 CET] <Aelius> context: I have Windows set to use jpn locale for non unicode programs
[06:37:24 CET] <Johnjay> i dunno where else to ask this
[06:37:27 CET] <Aelius> somehow, ffprobe is taking that and running with it unnecessarily
[06:37:35 CET] <Johnjay> but i can't seem to use my video download extension on mp2t stuff
[06:37:37 CET] <Aelius> clearly the environment can display russian
[06:38:02 CET] <Johnjay> is there a way to download those things somehow, like with curl or something?
[06:38:27 CET] <Aelius> "download those things" where from?
[06:39:02 CET] <Aelius> but as with all things media-scraping, go try youtube-dl. It'll probably work.
[06:39:03 CET] <Johnjay> from a webpage with embedded video
[06:39:10 CET] <Johnjay> i tried it
[06:39:25 CET] <Johnjay> at least with the main url
[06:39:25 CET] <Aelius> then there is no hope
[06:39:31 CET] <Johnjay> maybe i can get a url from the page somehow it will accept
[06:39:46 CET] <kepstin> if youtube-dl doesn't get it, then you'll have to manuall attempt to find a stream url, yeah
[06:40:15 CET] <Johnjay> well my video download plugin shows a dozen links
[06:40:22 CET] <Johnjay> all about a few KB or 1 MB in size
[06:40:25 CET] <Johnjay> instead of one video link
[06:40:33 CET] <Johnjay> i guess that's somehow related to the mp2t part
[06:40:43 CET] <kepstin> Johnjay: it might be segmented video, you should look for an 'm3u8' file
[06:41:04 CET] <kepstin> that's the playlist, which you can use ffmpeg to download and put into a container.
[06:50:32 CET] <Johnjay> hmm there was an m3u8 on the other one
[06:51:52 CET] <Johnjay> ffmpeg can download it?
[06:52:37 CET] <Johnjay> hmm i tried feeding it to -i and it rejected it
[06:52:57 CET] <Johnjay> unknown error
[07:37:53 CET] <dystopia_> hello
[07:38:23 CET] <dystopia_> im trying to downscale a video and stream it from one pc on my lan to another one
[07:39:31 CET] <dystopia_> https://pastebin.com/raw/dZ5K5Ju0
[07:40:09 CET] <dystopia_> No application or playpath in URL!
[07:40:09 CET] <dystopia_> RTMP_Connect0, failed to connect socket. 10061 (Unknown error)
[07:40:09 CET] <dystopia_> rtmp://localhost:2345: Unknown error occurred
[07:40:19 CET] <dystopia_> does anyone know what im doing wrong?
[09:36:23 CET] <dystopia_> got it working
[12:33:44 CET] <Fyr> guys, I'm trying to convert WAV or FLAC into ALAC in MP4 container. I get:
[12:33:44 CET] <Fyr> [mp4 @ 0000000000389e20] Could not find tag for codec alac in stream #0, codec not currently supported in container
[12:34:16 CET] <Fyr> it always worked like a charm, now I get this error.
[12:34:22 CET] <Fyr> what has been changed?
[12:34:39 CET] <durandal_1707> what version?
[12:34:53 CET] <Fyr> stable 3.4 and one of the latest from git.
[12:35:45 CET] <durandal_1707> i think you want .mov?
[12:35:52 CET] <Fyr> mp4
[12:35:55 CET] <Fyr> or m4a
[12:37:33 CET] <durandal_1707> m4a should work
[12:38:36 CET] <Fyr> strange, but it works.
[12:39:06 CET] <Fyr> durandal_1707, why does FFMPEG see difference between mp4 and m4a?
[12:41:16 CET] <Fyr> durandal_1707, now I need to mux a video and an ALAC m4a into mp4.
[12:41:37 CET] <Fyr> how can I do that?
[12:54:35 CET] <durandal_1707> Fyr: i dont think mp4 supports alac
[12:54:53 CET] <Fyr> MP4 and M4A is the same thing.
[12:54:58 CET] <durandal_1707> nope
[12:55:09 CET] <durandal_1707> find mp4 with alac
[12:55:10 CET] <Fyr> what's the difference?
[12:55:34 CET] <durandal_1707> see source code
[12:55:44 CET] <Fyr> I muxed many ALAC files into MP4 with FFMPEG a few years ago.
[13:12:02 CET] <Netun0> sorry, ffmpeg are still working with youtube live?
[13:16:45 CET] <Netun0> it's why IRC is almost dead, channel is full of people but no talks.
[13:17:29 CET] <durandal_1707> lol
[13:18:35 CET] <durandal_1707> Netun0: what you use for youtube live?
[13:21:47 CET] <Netun0> ffmpeg -re -f x11grab -video_size 1024x768 -i :1 -c:v libx264 -preset slow -crf 18 -c:a copy -pix_fmt yuv420p \
[13:21:47 CET] <Netun0>   -acodec libmp3lame -ar 44100 -b:a 128k -f flv -s 426x240 \
[13:23:03 CET] <Netun0>   -f tee "rtmp://a.rtmp.youtube.com/<key>|rtmp://live.twitch.tv/app/<key>
[13:23:07 CET] <Netun0> durandal_1707: thanks
[13:24:53 CET] <Netun0> ffmpeg -re -f x11grab -video_size 1024x768 -i :1 -c:v libx264 -preset slow -crf 18 -c:a copy -pix_fmt yuv420p -f flv -s 426x240 rtmp_url/key
[13:26:18 CET] <Netun0> I have tried all kind of arguments, if I output to file works nicely.
[13:42:34 CET] <c_14> and what's the problem?
[13:42:47 CET] <c_14> I know twitch for one has hard gop size requirements, which you don't seem to be setting at all
[13:43:13 CET] <c_14> can your computer encode preset slow in realtime?
[13:46:37 CET] <Netun0> c_14: changed to medium.
[13:49:40 CET] <Netun0> Trying periscope It seems better to diagnose. so, It now shows in red the msg "Max keyframe interval: 3.0 s."
[13:50:01 CET] <Netun0> ffmpeg -re -f x11grab -video_size 1024x768 -i :1 -c:v libx264 -preset medium -crf 3 -c:a aac -b:a 64k -pix_fmt yuv420p -r 30 -g 15 -b:v 800k -bufsize 512k -f flv -s 960x540 rtmp://or.pscp.tv:80/x
[13:53:32 CET] <c_14> your probably want to pass -x264-params keyint=60 since I think that's a harder limit than -g
[13:54:13 CET] <c_14> ah, no
[13:54:17 CET] <c_14> -g 60 maps to that
[13:56:56 CET] <Netun0> c_14: let me see here, thanks.
[14:10:16 CET] <Netun0> switched from 800k to 2500k too.
[14:36:13 CET] <Netun0> at periscope now it goes live but black screen.. :(
[14:59:18 CET] <Netun0> give up
[15:01:02 CET] <Fyr> guys, what is the least harmful way to change yuv444p to yuv420p?
[15:08:40 CET] <kerio> average U and V?
[15:09:02 CET] <DHE> I was going to say "at the last possible second"...
[15:09:45 CET] <dystopia_> stick "-pix_fmt yuv420p" on your line and hope it looks good
[15:11:01 CET] <Fyr> dystopia_, FFMPEG will use standard parameter set, like CRF 23, profile auto, preset medium etc.
[15:11:01 CET] <durandal_1707> Fyr: use zscale filter
[15:12:26 CET] <Fyr> thanks
[15:13:53 CET] <JEEB> Fyr: only for those lossy encoders that people have cared about, btw. the global libavcodec defaults are still 200kbps and some mpeg-1 level parameters :) (generally relevant to the internal ones)
[15:14:40 CET] <JEEB> I think libx264 still has a check in its code base that errors out if the old FFmpeg defaults are used :D
[15:15:36 CET] <JEEB> (before libx264 wrapper overrode the lavc defaults)
[15:28:36 CET] <kerio> lmao
[15:49:26 CET] <Tester_> can I ask about ffmpeg commands here? I imagine yes.. so
[15:49:51 CET] <Tester_> basically I wanna batch convert .wav to .mp4 , adding a still image
[15:50:19 CET] <Tester_> i know examples of this are all over the internet
[15:50:31 CET] <Tester_> but I'm getting error after error
[15:51:55 CET] <Tester_> https://pastebin.com/v5jruaTc
[15:52:00 CET] <Tester_> I'm on windows 10
[15:52:23 CET] <dystopia_> https://trac.ffmpeg.org/wiki/Slideshow worth a read Tester_
[15:52:50 CET] <c_14> Tester_: that doesn't show the output
[15:52:58 CET] <durandal_1707> you pasted command but not and output
[15:54:18 CET] <Tester_> https://pastebin.com/RXHpxyC6
[15:55:05 CET] <durandal_1707> use video with width divisible by 2
[15:55:10 CET] <Tester_> that`s the error only, but I think I`ll follow dystopia_ `s advice
[15:55:19 CET] <Tester_> hmmm
[15:55:23 CET] <Tester_> will try that
[15:56:43 CET] <dystopia_> load a scaler and scale it to like 1920 while maintaining mod2
[15:58:03 CET] <dystopia_> -sws_flags spline -vf scale=1920:-4,setsar=1/1
[15:58:12 CET] <dystopia_> add that to your line for example
[16:08:38 CET] <Tester_> dystopia_: that worked, thanks. It's pretty slow now though. I'll keep tweaking
[17:39:59 CET] <therage3> so i've been doing some research on this cartoon i've been trying to rip properly for a while now
[17:40:05 CET] <therage3> i came across this today
[17:40:07 CET] <therage3> https://www.animemusicvideos.org/guides/avtech31/video-analyze.html
[17:40:43 CET] <therage3> it seems parts of the cartoon use a Partial Field Blended Source method
[17:40:53 CET] <therage3> which, as the page states, is pretty much impossible to fix <.<
[18:17:12 CET] <furq> therage3: http://avisynth.nl/index.php/Srestore
[18:18:06 CET] <therage3> furq: interesting, looks pretty fiddly though
[18:18:29 CET] <furq> i've used that before on a really shit field blended pal dvd and got decent results
[18:18:44 CET] <furq> i might still have the script somewhere but iirc i pretty much used the defaults
[18:18:51 CET] <therage3> furq: interesting
[18:19:04 CET] <furq> you're obviously never going to get comparable results to a good source though
[18:19:12 CET] <therage3> right
[18:36:15 CET] <Lunchbox> anyone have suggestion on how to maintain the same colors in a video being upscaled from 360p to 720p? i change the color matrix from 601 to 709 after scaling but it still looks off
[18:36:36 CET] <ritsuka> either use the same color matrix as the input
[18:36:45 CET] <ritsuka> or use the colorspace conversion filter
[18:37:15 CET] <Lunchbox> if i use the same color matrix the colors look way off after upscaling
[18:37:32 CET] <Lunchbox> ill look up the conversion filter
[18:37:35 CET] <ritsuka> did you set the color primaries and transfer function too?
[18:38:02 CET] <ritsuka> if you don't set them, the player will guess the colorspace
[18:38:34 CET] <Lunchbox> i just used -vf colormatrix=bt601:bt709
[18:39:13 CET] <ritsuka> you need the other values too
[18:39:23 CET] <durandal_1707> colormatrix is old, incorrect and bad
[18:39:30 CET] <ritsuka> color matrix is just for the yuv<->rgb conversion
[18:39:48 CET] <Lunchbox> ok haha well how do i do this correctly then
[18:40:46 CET] <Lunchbox> am i at least correct for using 601 on the initial 360p video?
[18:40:53 CET] <Lunchbox> any other option looks wrong
[18:42:08 CET] <ritsuka> if the file doesn't have any color info, you can only guess&
[18:42:16 CET] <kepstin> assuming that sd sources are bt.601 and using bt.601 for output will generally be correct
[18:42:22 CET] <ritsuka> if you want convert colorspace you can use the colorspace filter
[18:42:27 CET] <kepstin> but if it's a downscale from HD content, then who knows.
[18:43:17 CET] <Lunchbox> i'm just trying to resize 360p in 601 to 720p without the colors changing
[18:44:12 CET] <durandal_1707> and what you use for playback?
[18:44:37 CET] <Lunchbox> final video will mostly be viewed in web browsers
[18:45:30 CET] <durandal_1707> just dont use ffplay
[18:46:42 CET] <kepstin> mpv is known to have good colorspace handling, so use that as a reference player to test stuff, but you'll have to also check the browsers :/
[18:47:24 CET] <Lunchbox> looks like -vf colorspace=bt709 should do the trick? looks like colormatrix doesn't support some stuff like colorspace does according to the documentation
[18:48:16 CET] <kepstin> colorspace has lots of options, but if it's guessing the input correctly, that should suffice to convert to bt709
[18:48:28 CET] <kepstin> if it's not guessing the input correctly, you'll need more options.
[18:48:52 CET] <Lunchbox> what are the other params i can provide to make sure it's correct
[18:49:13 CET] <Lunchbox> i guess i can just see what happens if i use only colorspace
[18:49:27 CET] <kepstin> well, first you need to know what color primaries and transfer characteristics your input has :/
[18:49:37 CET] <kepstin> e.g. is it from an SD NTSC tv source, or what?
[18:50:51 CET] <Lunchbox> it's just a recording of my computer screen
[18:51:06 CET] <kepstin> made with what software?
[18:51:23 CET] <Lunchbox> open broadcaster software
[18:51:48 CET] <Lunchbox> obs studio specifically
[18:51:50 CET] <kepstin> huh, I really have no idea what obs would be doing here
[18:52:05 CET] <Lunchbox> well you can set whatever you want for it to record with
[18:52:22 CET] <Lunchbox> right now the settings
[18:52:24 CET] <kepstin> yeah, but the defaults are bt709, limited range
[18:52:26 CET] <Lunchbox> for 360p
[18:52:28 CET] <Lunchbox> are
[18:52:29 CET] <kepstin> iirc
[18:52:45 CET] <Lunchbox> yuv color space 601 yuv color range partial color format nv12
[18:52:48 CET] <kepstin> i guess they might do something different for 360p?
[18:52:58 CET] <Lunchbox> you can set it to whatever you want
[18:53:03 CET] <Lunchbox> those are the defaults
[19:03:29 CET] <TAFB> can I tell ffmpeg to use all my 12 cores when encoding libx264?
[19:03:43 CET] <BtbN> it will be default
[19:03:47 CET] <BtbN> *by
[19:04:08 CET] <kepstin> TAFB: but note that with smaller video sizes (sd) and faster presets, it might not actually scale to use all those cores.
[19:04:26 CET] <JEEB> or what's more often happening, something else is limiting your speed
[19:04:41 CET] <TAFB> hmmm, only appears to be using "core 19" at the moment, 82% loaded, the rest of the cores are at 0 to 3% :(
[19:04:53 CET] <Fyr> sometimes all cores are not the fastest option.
[19:05:03 CET] <JEEB> have you built x264 with threading?
[19:05:10 CET] <JEEB> have you built FFmpeg with threading?
[19:05:20 CET] <TAFB> just downloaded the pre-build Windows ffmpeg
[19:05:20 CET] <JEEB> are you sure you are not being limited by something *before* libx264?
[19:05:55 CET] <kepstin> if you're hitting single-core limits, it's probably an ffmpeg filter or something that's slowing you down rather than x264, yeah.
[19:06:25 CET] <therage3> if you want to use pastebin.com, try to give us the raw link
[19:06:51 CET] <Fyr> JEEB, how will the conversion will go if -threads is set to 4, but -x264-params is set to 8?
[19:06:57 CET] <Fyr> or 2?
[19:07:11 CET] <TAFB> https://pastebin.com/1UpT4EH3
[19:07:21 CET] <therage3> ...
[19:07:22 CET] <JEEB> not sure in which order those work, but whichever gets applied later wins in init()
[19:07:25 CET] <kepstin> Fyr: settings in -x264-params should override other options (they're applied to x264 after the other options)
[19:07:45 CET] <JEEB> ^ ok, so that's the order then
[19:08:07 CET] <Fyr> kepstin, ok, but -threads 4 will be used when converting the audio stream?
[19:08:09 CET] <kepstin> TAFB: I suspect your bottleneck is the lagarith decoding.
[19:08:21 CET] <TAFB> kepstin: figured as much :(
[19:08:22 CET] <kepstin> Fyr: all the audio encoders are single-threaded
[19:08:23 CET] <JEEB> Fyr: depends on the encoder anyways. most don't
[19:08:32 CET] <JEEB> because audio encoding generally is "fast enough"
[19:08:51 CET] <kepstin> TAFB: you can check this by running "ffmpeg -i "amarec(20171210-1216).avi" -f null -" and see what fps/core usage you get
[19:09:23 CET] <TAFB> checking...
[19:09:30 CET] <JEEB> I like how that one french dude has rencetly added nice optimizations to Ut Video
[19:09:34 CET] <JEEB> <3
[19:11:39 CET] <TAFB> kepstin: that command loads all "real" cores, fps=255!
[19:11:59 CET] <kepstin> alright, so decoding isn't the bottleneck then
[19:12:27 CET] <JEEB> libx264 is properly setting threads to 12
[19:12:35 CET] <kepstin> try "ffmpeg -i "amarec(20171210-1216).avi" -pix_fmt yuv420p -f null -"
[19:12:40 CET] <JEEB> so then it's either the pix_fmt conversion or libx264
[19:12:42 CET] <kepstin> might be the pixel format conversion is slow
[19:12:57 CET] <JEEB> or just the preset veryslow might be heavy on a single thread at that point
[19:13:02 CET] <JEEB> but you should be able to confirm
[19:13:03 CET] <JEEB> with that
[19:13:17 CET] <kepstin> i'd expect 720p with veryslow it should be able to load up the threads pretty good
[19:13:32 CET] <kepstin> might not if e.g. the video is a still image or something tho.
[19:13:52 CET] <JEEB> it's still definitely fast, (13fps)
[19:14:13 CET] <TAFB> -pix_fmt yuv420p still uses all 12 cores, 300fps
[19:16:05 CET] <kepstin> TAFB: right then, either you have a misbuilt libx264 with threading disabled somehow!? or the characteristics of your video just don't allow the threading to work well :/
[19:16:16 CET] <JEEB> well it's preset veryslow
[19:16:31 CET] <JEEB> because I don't think libx264 would set the threads if threading is not enabled
[19:16:33 CET] <JEEB> I think
[19:17:10 CET] <TAFB> freaky. I'll try a slightly older pre-built ffmpeg and see if I see the same thing
[19:17:11 CET] <TAFB> thanks guys
[19:17:34 CET] <JEEB> also do note that sometimes -f null for benchmarking doesn't bring what you need onto the table
[19:17:52 CET] <JEEB> -c:v rawvideo -c:a pcm_XXXX -f nut with output to NUL or something
[19:18:01 CET] <JEEB> that generally tends to give a realistic picture
[19:18:13 CET] <JEEB> (or /dev/null on *nix)
[19:25:46 CET] <TAFB> can you use a cluster of computers to encode with ffmpeg?
[19:26:30 CET] <JEEB> yes but it's not automated of course. it's the "magic sauce" that all of those video sites use
[19:27:08 CET] <TAFB> ahhhh, nice.
[19:27:48 CET] <Fyr> guys, is there a difference between -pix_fmt and -pixel_format?
[19:28:03 CET] <BtbN> one is shorter
[19:28:15 CET] <TAFB> wow, crf 18 sure is pretty
[19:28:23 CET] <Fyr> if I set -pixel_format, FFMPEG responds:
[19:28:23 CET] <Fyr> No pixel format specified, yuv444p for H.264 encoding chosen.
[19:28:23 CET] <Fyr> Use -pix_fmt yuv420p for compatibility with outdated media players.
[19:28:38 CET] <Fyr> if I set -pix_fmt, it's set normally.
[19:28:43 CET] <BtbN> well, then the difference is that the long version doesn't exist
[19:29:02 CET] <Fyr> but it doesn't say that it didn't recognized the option.
[19:32:05 CET] <Fyr> Reading option '-pixel_format' ... matched as AVOption 'pixel_format' with argument 'yuv420p'.
[19:36:21 CET] <durandal_1707> can be raw demuxer option
[19:36:34 CET] <JEEB> yea I see it in avdevice.h
[19:36:57 CET] <JEEB> rawvideo and img2dec have it too
[19:37:31 CET] <JEEB> http://up-cat.net/p/9343135d
[20:01:08 CET] <Fyr> is it worth bugreporting?
[20:01:42 CET] <durandal_1707> Fyr: what is bugggy?
[20:03:14 CET] <Fyr> -pixel_format
[20:03:33 CET] <TAFB> is there something slower than veryslow?
[20:03:52 CET] <Fyr> TAFB, placebo
[20:04:00 CET] <durandal_1707> Fyr: i dont see how that can be bug
[20:04:15 CET] <TAFB> Fyr: I need about 2% more compression, think it would do it?
[20:04:34 CET] <Fyr> durandal_1707, unexpected behavior. a user sets an option, but it's ignored.
[20:04:43 CET] <therage3> TAFB: see here https://trac.ffmpeg.org/wiki/Encode/H.264
[20:04:56 CET] <Fyr> TAFB, try both and compare.
[20:05:01 CET] <TAFB> will do
[20:05:03 CET] <durandal_1707> Fyr: read documentation wisely
[20:05:05 CET] <therage3> TAFB: https://trac.ffmpeg.org/wiki/Encode/H.264#FAQ
[20:05:44 CET] <TAFB> ahh, about 1%. I'ma give it a try and see if it does what I need :)
[20:05:50 CET] Action: therage3 nods
[20:44:03 CET] <TAFB> "-c:a aac -b:a 320k" gets me "Audio: AAC 48000Hz stereo 321kbps [SoundHandler - MPEG-4 Audio (AAC, 48.0 kHz, 2 chn, 16 bit, 321.5 kbit/s)]" is it possible to get it exactly 320.0kbit/s?
[20:46:59 CET] <kepstin> what program is displaying that? it might be including the container overhead
[20:47:14 CET] <TAFB> MPC-BE
[20:49:38 CET] <TAFB> and do you know a program that can tell me how many "real" fps/sec my video is? My capture card does it at 60fps but lots of frames are doubled and tripled.
[20:50:05 CET] <TAFB> sorry, ALL frames are doubled or tripled.
[20:50:54 CET] <TAFB> looks like one frame is doubled, next one tripled, next one doubled, next one tripled
[20:55:15 CET] <Johnjay> I can't get ffmpeg to download a mp2t stream like in this SO thread. suggestions?
[20:55:25 CET] <Johnjay> https://stackoverflow.com/questions/32528595/ffmpeg-mp4-from-http-live-streaming-m3u8-file
[20:55:48 CET] <Johnjay> the command I tried is near the bottom
[20:58:23 CET] <Johnjay> Well there's not really any output
[20:58:27 CET] <Johnjay> it just says unknown error
[20:58:47 CET] <Johnjay> youtube-dl seems to know what to do though. it's involking ffmpeg on the same m3u8 URL
[21:26:56 CET] <TAFB> placebo is MUCH slower than veryslow, lol. 3x slower or so.
[21:27:07 CET] <JEEB> yes
[21:27:16 CET] <JEEB> it's called like that for a reason, more or less
[21:27:17 CET] <furq> the clue's in the name
[21:27:42 CET] <TAFB> looks like my source is 24fps or 25fps, not sure how to tell exactly which
[21:28:32 CET] <TAFB> I guess I could run an encode at 25fps and look for duplicate frames
[21:29:36 CET] <JEEB> if you need to check actual content rate, just use a player to go frame forwards/backwards
[21:29:44 CET] <JEEB> like with ,. in mpv :P
[21:30:17 CET] <TAFB> I use avidemux to check for duplicate frames :)
[21:30:30 CET] <JEEB> well whatever works for you
[21:30:52 CET] <TAFB> "ffmpeg -i input.mp4 -vf mpdecimate -loglevel debug -f null -" seems to mistake some similar frames for duplicate frames :(
[21:34:23 CET] <TAFB> looks like 24fps it is!
[21:55:19 CET] <furq> TAFB: you can adjust the params to mpdecimate if it's being overzealous
[21:55:22 CET] <furq> !filter mpdecimate
[21:55:22 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#mpdecimate
[22:06:43 CET] <TAFB> sweet! thanks!
[22:10:21 CET] <Lunchbox> i'm getting "no such filter 'colorspace'" when trying to use -vf colorspace=bt709
[22:11:24 CET] <JEEB> too old FFmpeg?
[22:14:33 CET] <Lunchbox> version is N-75137-g2c1ec57
[22:14:34 CET] <Lunchbox> lol
[22:15:22 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=2c1ec57
[22:15:39 CET] <JEEB> now you know that you can throw that identifier without the g in front there to see how old it is :P
[22:17:39 CET] <Lunchbox> how can i tell if my version is too old
[22:17:46 CET] <Lunchbox> or should i just update anyways
[22:17:53 CET] <JEEB> well, you just found your own version
[22:18:03 CET] <JEEB> and then you can search the history for the colorspace filter :P
[22:18:35 CET] <JEEB> like this http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=colorspace
[22:19:05 CET] <JEEB> and you can find that the colorspace filter was added in April, 2016
[22:19:11 CET] <Lunchbox> oh dang
[22:19:14 CET] <Lunchbox> yep haha
[22:19:14 CET] <JEEB> while as I linked your version is from somewhere in 2015
[22:19:16 CET] <Lunchbox> thank u
[22:20:11 CET] <Lunchbox> can't believe mine was that old
[22:20:21 CET] <Lunchbox> pretty sure it was the latest when i downloaded it at the time
[22:20:25 CET] <Lunchbox> has it really been that long
[22:20:27 CET] <Lunchbox> sheesh
[22:20:47 CET] <therage3> what OS are you on?
[22:20:57 CET] <therage3> some distros have really old versions of some stuff, Debian in particular
[22:20:57 CET] <Lunchbox> windows 7
[22:21:02 CET] <therage3> o.o
[22:21:10 CET] <Lunchbox> lol
[22:21:11 CET] <therage3> you sure downloaded it a long time ago then :)
[22:22:30 CET] <Johnjay> You mean 2016-04-12 	Ronald S. Bultje	lavfi: new colorspace conversion filter. ?
[22:22:49 CET] <JEEB> yes
[22:23:04 CET] <JEEB> but if you are on such an old thing you just want the latest and go from there
[22:23:27 CET] <Lunchbox> where is the bin folder in the latest release haha
[22:23:33 CET] <Johnjay> my windows 7 box has ffmpeg version N-87353-g183fd30
[22:23:48 CET] <Lunchbox> oh nvm
[22:23:52 CET] <Lunchbox> downloaded the wrong one
[22:26:27 CET] <Lunchbox> what does unsupported input primaries mean?
[22:26:35 CET] <Lunchbox> sorry for the billion questions
[22:31:28 CET] <JEEB> if that comes from the filter (inside the [] in the log) then whatever your input is is not supported by it
[22:33:20 CET] <Johnjay> Lunchbox: don't worry asking annoying questions is pretty much all I do on here
[22:33:57 CET] <Lunchbox> https://paste.ofcode.org/8UxCqqmhFJ8wAwqa7XDSyu
[22:34:22 CET] <JEEB> yea
[22:34:28 CET] <JEEB> your input parameters are unknown
[22:34:47 CET] <JEEB> and new filters that don't want to be guessing (zscale, colorspace) specifically want you be explicit
[22:34:47 CET] <Lunchbox> how can i find them out?
[22:34:52 CET] <durandal_1707> need to specify/set them
[22:35:00 CET] <JEEB> Lunchbox: you know the source, right?
[22:35:01 CET] <Lunchbox> in the command?
[22:35:05 CET] <Lunchbox> yes i do
[22:35:29 CET] <JEEB> ok, so what's the source and how did it end up not being tagged? :)
[22:36:02 CET] <JEEB> so that you can then tag it accordingly so that the filter would be usable
[22:36:08 CET] <Lunchbox> not sure
[22:36:16 CET] <Lunchbox> i mentioned i was using obs earlier for recording the videos
[22:36:22 CET] <JEEB> ok
[22:36:26 CET] <Lunchbox> but idk if it actually tags the video like you're saying
[22:36:31 CET] <Lunchbox> which is something new to me
[22:36:38 CET] <JEEB> it's not tagging, otherwise it'd not say unknown
[22:36:51 CET] <JEEB> I think the simplest is to check with mpv or something
[22:36:56 CET] <Lunchbox> does this mean i'm screwed haha
[22:37:02 CET] <JEEB> ask on #mpv how to switch between BT.709 and BT.601
[22:37:09 CET] <Lunchbox> i dropped it in mediainfo but doesn't really tell me anything i think is useful'
[22:37:15 CET] <JEEB> you can find mpv binaries for windows @ https://mpv.srsfckn.biz/
[22:37:24 CET] <JEEB> well mediainfo can only find out what's tagged in the file
[22:37:30 CET] <JEEB> in this case OBS did not write any metadata
[22:37:31 CET] <JEEB> :P
[22:37:50 CET] <Lunchbox> https://paste.ofcode.org/HD3UHJiZk9vxhxyZm96WQH
[22:38:18 CET] <Lunchbox> didn't look like any of that was what i needed to know
[22:38:29 CET] <JEEB> yup, so unfortunately OBS doesn't tag even though it's doing the colorspace conversion most likely :/
[22:38:36 CET] <Lunchbox> shoot
[22:38:36 CET] <JEEB> it's either BT.709 or BT.601
[22:38:52 CET] <Lunchbox> it's supposed to currently be 601 according to the obs settings
[22:38:55 CET] <JEEB> that's why I said grab an mpv binary and ask #mpv how to set one or the other
[22:38:57 CET] <JEEB> ok
[22:39:09 CET] <JEEB> because the best way to check is to verify which looks correct
[22:39:15 CET] <JEEB> and since you knwo the source you should know the difference
[22:39:27 CET] <Lunchbox> yea it's definitely 601 for sure
[22:39:36 CET] <JEEB> ok
[22:39:39 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#colorspace
[22:39:42 CET] <Lunchbox> i've recorded with both and it's obviously different
[22:39:49 CET] <JEEB> uhh
[22:39:56 CET] Action: JEEB sighs
[22:40:01 CET] <JEEB> it's different because players don't know you switched
[22:40:02 CET] <Lunchbox> i had that page open
[22:40:07 CET] <TAFB> recording to my 64gb ramdrive, see if that gets rid of some dropped frames :(
[22:40:10 CET] <JEEB> that's why I noted mpv
[22:40:15 CET] <JEEB> you could SWITCH which it used
[22:40:27 CET] <JEEB> because when not tagged the players have to guess
[22:40:31 CET] <Lunchbox> ohhh
[22:40:32 CET] <JEEB> which is usually done by resolution or something
[22:40:37 CET] <Lunchbox> that's realyl dumb actually lol
[22:40:39 CET] <JEEB> so to see which it is
[22:40:44 CET] <c3r1c3-Win> The OBs color space settings are in settings->Advanced->Color space
[22:40:45 CET] <JEEB> you switch between them
[22:40:49 CET] <JEEB> and look which is correct
[22:40:49 CET] <Lunchbox> i gtg picking up christmas tree
[22:40:56 CET] <Lunchbox> be back in a little bit
[22:41:16 CET] <Lunchbox> yea that's were i double checked the settings c3r1c3
[22:41:21 CET] <durandal_1707> thats little early for tree?
[22:41:34 CET] <Lunchbox> it's december!!
[22:41:39 CET] <JEEB> c3r1c3-Win: nothing wins learning to check which it is (when you know your source colors)
[22:41:49 CET] <JEEB> but yes, OBS should just darn flag the files
[22:41:52 CET] <Lunchbox> okok brb
[22:41:53 CET] <JEEB> so we wouldn't have this crap :P
[22:42:04 CET] <Lunchbox> ill yell at them later in #obsproject
[22:42:39 CET] <JEEB> funny enough when you use the nvidia encoder from OBS it actually (probably properly) tags the video as BT.601
[22:42:48 CET] <JEEB> but not when it uses libx264?
[22:42:49 CET] <JEEB> lol
[22:44:25 CET] <c3r1c3-Win> You can also yell at them in #obsdev. ;-)
[22:44:44 CET] <JEEB> I have my own set of projects I poke
[22:45:01 CET] <c3r1c3-Win> (on Quakenet, almost no one every visits the freenode one)
[23:32:06 CET] <SolarAquarion> i'm getting a ffmpeg launch failure
[23:32:32 CET] <SolarAquarion> https://paste.debian.net/1000116/
[23:34:02 CET] <TheRock2> Have you double clicked the player ?
[23:34:18 CET] <SolarAquarion> it could be a mpv issue
[23:34:55 CET] <sfan5> something is broken with your cuda
[23:35:49 CET] <SolarAquarion> sfan5: tell me about it
[23:36:04 CET] <sfan5> recently upgraded drivers or something similar?
[23:37:57 CET] <SolarAquarion> sfan5: i use nouveau really, but i only was having the cuda problems recently like in the last few days
[23:38:10 CET] <SolarAquarion> when i upgraded ffmpeg or maybe cuda upgraded
[23:38:40 CET] <SolarAquarion> not cuda
[23:46:34 CET] <sfan5> nouveau supports cuda?
[23:47:27 CET] <SolarAquarion> it did, but i guess i should disable it
[23:47:34 CET] <SolarAquarion> or disable cuda
[00:00:00 CET] --- Mon Dec 11 2017