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

burek burek at teamnet.rs
Wed Dec 25 03:05:03 EET 2019


[00:02:21 CET] <cehoyos> A good starting point is likely to remove "-ar 192k"
[00:07:15 CET] <LFSVeteran> but then it won't sample at 192k
[00:07:26 CET] <LFSVeteran> 192kHz is a must
[00:37:09 CET] <cehoyos> I wonder if your hardware (that doesn't encode mp3 in realtime) is really able to record 192k, more likely is that you request alsa to resample to 192k (which takes cpu cycles), later it has to be resampled again because mp3 does not support 192k
[00:38:02 CET] <cehoyos> maximum is 48k
[00:46:56 CET] <Hello71> but the sound is so much warmer
[00:51:31 CET] <LFSVeteran> mp3 doesn't support 192kHz....ok mp3 isn't option then
[00:52:15 CET] <LFSVeteran> I guess it's resampling
[01:46:05 CET] <cehoyos> Hello71: You know that the human ear is limited to 48kHz 16bit?
[01:46:31 CET] <Hello71> but, like, the sound is crisper
[01:46:41 CET] <LFSVeteran> not using it for audio...
[01:46:43 CET] <Hello71> obviously you don't have the requisite diamond directional ethernet cables
[01:47:14 CET] <LFSVeteran> :D
[01:47:29 CET] <LFSVeteran> the usual audio nonsens
[02:22:41 CET] <kepstin> if you're not using it for audio, you shouldn't be using a lossy audio codec
[02:23:21 CET] <kepstin> lossy audio codecs remove stuff that humans are unlikely to perceive, but if you're not working with audio, that "stuff" might be important signal
[02:24:08 CET] <LFSVeteran> My goal is to sample at 192kHz and stream the signal to the world
[02:24:37 CET] <LFSVeteran> icecast/darkice wasn't the option
[02:24:48 CET] <LFSVeteran> maybe icecast/ffmpeg can do the job
[02:26:44 CET] <LFSVeteran> don't know if ogg/vorbis would be an option
[02:41:12 CET] <Hello71> but I would still be skeptical that this "embedded" can actually sample at 192k
[02:51:53 CET] <kepstin> well, if you have a signal generator you can trust which can generate signals up to 96kHz, you could test it I guess?
[02:57:46 CET] <Hello71> reminds me of the guy who wanted to calibrate his speakers with an uncalibrated microphone
[03:08:13 CET] <kepstin> a lot of modern hifi systems actually ship with a microphone for doing speaker/room calibration, presumably the mic is built to spec and a "typical" response curve is stored in the hifi system firmware.
[03:08:25 CET] <kepstin> mine has one, but I haven't bothered trying it.
[03:14:11 CET] <Hello71> wouldn't such systems just come with calibrated speakers
[03:14:31 CET] <Hello71> or do you mean the sound boxes are sold separately from the speakers
[03:14:59 CET] <nicolas17> Hello71: maybe stuff that depends on speaker distance and such?
[03:15:06 CET] <Hello71> right
[03:15:13 CET] <Hello71> but my point is you wouldn't be calibrating the speakers
[03:15:21 CET] <nicolas17> "room calibration"
[03:25:27 CET] <AiNA_TE> does ffmpeg support burning picture based subs?
[03:25:34 CET] <AiNA_TE> or do i need to ocr them first
[03:30:40 CET] <nicolas17> AiNA_TE: do have subtitles already in a picture format and you want to burn them into the video stream?
[03:31:52 CET] <AiNA_TE> yeah, they are vobsub as .idx/.sub
[03:34:26 CET] <nicolas17> hmm I think you can use the overlay filter
[03:53:21 CET] <igssl> https://pastebin.com/DL5LEnQR any idea what i'm doing wrong? trying to batch convert + upscale some webms to 1080p MP4s on windows
[04:00:22 CET] <AiNA_TE> igssl, dont use %04d.webm as input
[04:00:46 CET] <AiNA_TE> if your doing this in windows cli, either explicitly state input each time
[04:00:50 CET] <AiNA_TE> or use a for loop
[04:03:45 CET] <AiNA_TE> for %%a in ("*.webm") do (ffmpeg -i "%%a" -vf scale=1920x1080:flags=lanczos -c:v libx264 -crf 16 -preset slow -c:a copy %%a.mp4 )
[04:03:51 CET] <AiNA_TE> somthing like that
[04:04:30 CET] <AiNA_TE> can you load the scaler like that also?
[04:05:05 CET] <AiNA_TE> i always use "sws_flags spline" for example, outside of -vf
[04:07:04 CET] <nicolas17> igssl: ffmpeg can't do "batch conversions", the %d stuff is to do stuff like load multiple images as frames and encode them into a single video
[04:07:22 CET] <nicolas17> you have to make a script that runs ffmpeg separately for each file
[04:08:10 CET] <igssl> well, FOR /F "tokens=*" %G IN ('dir /b *.webm') DO ffmpeg -i "%G" -vf scale=1920x1080:flags=lanczos -c:v libx264 -crf 16 -preset slow -c:a copy "%~nG.mp4" seems to be working
[04:09:00 CET] <AiNA_TE> you should put your command after DO in () brackets
[04:09:20 CET] <igssl> i am somewhat surprised at lanczos being better than every AI video rescaler i have tried, btw... waifu2x, topaz etc. all produce inferior results for these video files (overwatch gameplay)
[04:09:36 CET] <nicolas17> AiNA_TE: the bracket-less way is how it worked in DOS so I guess it still works in modern systems :)
[04:09:45 CET] <igssl> there isn't a better scaler i'm missing, is there? i know stuff like MadVR uses some kind of neural net jazz
[04:10:01 CET] <AiNA_TE> i always use spline and like it's results
[04:10:10 CET] <AiNA_TE> but diffrent scalers are better in diff situations
[04:10:30 CET] <AiNA_TE> like waifu2x you mention is great for anime, but not live action for example
[04:10:55 CET] <igssl> it has photo model too
[04:12:22 CET] <nicolas17> waifu2x uses a neural network, right?
[04:12:39 CET] <igssl> yep
[04:12:55 CET] <nicolas17> I think for gaming you'd have to train it yourself with content from that particular game :P
[04:58:59 CET] <AiNA_TE> nicolas17 i am playing around with the overlay filter but im getting the error "Filter overlay has an unconnected output"
[04:59:02 CET] <AiNA_TE> you got any ideas
[05:01:27 CET] <AiNA_TE> https://pastebin.com/raw/ubuG3W9b
[05:01:38 CET] <analogical> how do I remove cover art from an audiofile??
[05:03:45 CET] <relaxed> analogical: ffmpeg -i input -map 0:a -c copy output
[05:03:50 CET] <AiNA_TE> ffmpeg -i in.mp3 -vn -codec:a copy -map_metadata -1 out.mp3
[05:35:48 CET] <AiNA_TE> i worked it out, thx for pointing me in the right direction nicolas17
[10:02:19 CET] <Haemogoblin> Morning
[10:03:02 CET] <Haemogoblin> Would here be a good place to pose a question about finding an old 32bit version of ffmpeg?
[10:14:42 CET] <fling> Haemogoblin: how old?
[10:16:02 CET] <Haemogoblin> old enough to function with audacity 2.0.6
[10:16:43 CET] <Haemogoblin> on a Apple mac running OS 10.4
[10:17:58 CET] <Haemogoblin> I've tried the 32bit 2.2.2-mac zip but audacity doesn't see the file and identify it is present
[10:26:15 CET] <Haemogoblin> the audacity wiki led me to the ffmpeg project page, when I saw there was an IRC channel. I thought it might be worth a shot asking around.
[10:28:32 CET] <Haemogoblin> I'm afraid I don't actually know which version of FFMPEG complimented version 2.0.6 of Audacity. However the build date is 2014, so I would imagine a version of FFMPEG from that time?
[11:18:30 CET] <Haemogoblin> Hello?
[11:58:18 CET] <kurosu> barhom: regarding your question in -devel that should have been in this channel, is it pixelation with some kind of pattern (GPU texture format or whatever at play) or too low a bitrate?
[11:58:55 CET] <barhom> kurosu: Pixelation and, how do I explain, repeating frames - does that make sense?
[11:59:09 CET] <barhom> Like its stuck between two frames jumping back and forth and then after 2 seconds it continues
[11:59:30 CET] <kurosu> ok, maybe indeed some kind of data transfert issue
[11:59:43 CET] <kurosu> or are you hitting some kind of profile+level bound in your decoder ?
[12:00:15 CET] <kurosu> not like I think I can help you fix this, but what are is the level, profile and bitrate of the resulting video ?
[12:01:09 CET] <barhom> Im transcoding with nvenc fast 900k, I havent specified level/profile
[12:01:20 CET] <barhom> its a SD live transcode, 720x576 mpeg2 input source
[12:25:13 CET] <kurosu> BtbN: ^ (also, output seems to be h264_nvenc, and I do hope pixelation isn't in the input)
[12:27:43 CET] <BtbN> Are you swapping channels or am I missing messages?
[12:28:51 CET] <BtbN> 0.9M encoding with nvenc won't look good though. Thats way too low of a bitrate. And why use fast? There's virtually no reason to ever use something other than the slowest preset.
[12:29:19 CET] <JEEB> basically technically his stuff was end user discussion so technically kurosu was correct to pull him over here
[12:37:24 CET] <barhom> JEEB: If we think its a bug should the discussion go here or in -devel? (I generally get way better answers in -devel)
[12:38:00 CET] <barhom> kurosu: I found the bug, the problem was decoding on GPU is creating the pixelation
[12:38:28 CET] <JEEB> well yea, unfortunately many developers don't want to be anywhere near users
[12:38:35 CET] <JEEB> it's just masochists like me who are in here :P
[13:02:50 CET] <kurosu> so it's true some hardware decoders have issue when they do not have enough to do/the resolution is too low
[13:02:59 CET] <kurosu> *issues
[13:03:31 CET] <kurosu> but mpeg2 & pal SD should be a pretty common place
[13:03:31 CET] <BtbN> Hardware Decoders are generally perfect though
[13:03:44 CET] <JEEB> the issue could be anywhere between the hwdec wrapper, driver, hardware and glue code
[13:03:48 CET] <BtbN> There's a defined result for how to decode video. Not like encoders, where there is a quality difference
[13:04:15 CET] <kurosu> thanks for explaining this to me :D
[13:04:34 CET] <kurosu> yeah sorry, I meant, I did hear of that before
[13:04:49 CET] <kurosu> not trying to shift blame somewhere/to someone
[13:59:29 CET] <barhom> BtbN: Btw, when you said why use fast vs slowest. It is to cram in as much GPU transcodes as possible into 1 GPU at the cost of quality
[14:00:08 CET] <BtbN> It's probably more cost effective to buy CPUs for that
[14:07:39 CET] <barhom> BtbN: I decided on GPU after calculating costs. I ofc like x264 better, but it all depends on what the intended purpose is.
[14:08:20 CET] <BtbN> You need a 2k¬+ GPU for more than two parallel sessions anyway
[14:08:33 CET] <BtbN> and for 2k¬ you get a mad amount of CPU cores
[14:08:53 CET] <barhom> The quadro p2000 isnt that expensive
[14:09:55 CET] <barhom> p2000 combined with a cheap e3-v2 cpu
[14:10:39 CET] <barhom> But I'm all ears, used hardware is no problem, what CPU are you thinking is the most cost effective?
[14:10:44 CET] <DHE> v2? that's like 3 generations behind..
[14:12:19 CET] <barhom> DHE: Yeh but you get them cheaply. ¬200 for e3-1270v2 with 16gb ram. Slam in a quadro p2000 and you got a good encoding machine.
[14:19:15 CET] <DHE> well, I've heard good things about the nvenc chips on Turing cards, and I did just happen to get an rtx2060 series card... but I would still want to test and validate it. I'd done that for older model cards though...
[14:27:46 CET] <Abdullah> Is it possible to set an image with mp3 for first some minutes, and then another image for some minutes?
[14:27:59 CET] <Abdullah> thus creating mp4 from them?
[14:28:49 CET] <BtbN> Something like a server with Dual EPYC 7302. 32 cores, 64 thread.
[14:29:09 CET] <BtbN> You can run a ton of lower quality x264 encodes on that.
[14:29:18 CET] <DHE> can confirm (though I'm using intel right now)
[14:29:36 CET] <BtbN> 32 Intel Cores cost slightly more than 2k¬ though
[14:29:40 CET] <Abdullah> I'm using this command. ffmpeg -loop 1 -r 1 -i input.png -i input.mp3 -vcodec libx264 -acodec copy -shortest output.mp4
[14:29:53 CET] <DHE> 28 cores cost ~10,000 USD retail...
[14:30:07 CET] <BtbN> Yeah, AMD wipes the floor with Intel then
[14:30:13 CET] <BtbN> a 16 core Rome Epyc is 1k
[14:30:25 CET] <Abdullah> Is it possible to set an image with mp3 for first some minutes, and then another image for some minutes?
[14:30:46 CET] <DHE> oh absolutely, and it'll have more cache (probably?) and more memory channels and I believe higher speed memory support and more PCI-E lanes (not relevant to encoding unless you want 8 GPUs in a system) etc
[14:31:10 CET] <BtbN> 128MB L3
[14:31:15 CET] <BtbN> 8 Channel memory
[14:31:21 CET] <BtbN> 128 PCIe lanes
[14:31:35 CET] <BtbN> PCIe 4.0 lanes even
[14:32:47 CET] <Abdullah> offtopic  ?
[14:32:57 CET] <Abdullah> Is it possible to set an image with mp3 for first some minutes, and then another image for some minutes?
[17:57:33 CET] <familiyaF> Hi, I want to mux SCC to mxf container as vanc. Is it possible to achieve the requirement via ffmpeg
[18:00:06 CET] <JEEB> SCC is the text format with 608 captions?
[18:00:17 CET] <familiyaF> yes
[18:00:55 CET] <JEEB> also VANC as in actually in the video stream, or in f.ex. H.264 or MPEG-2 Video stream as separate packets? I do also know that MXF supports US captions as a separate stream?
[18:02:03 CET] <johnjay> kepstin: interesting this video happened to come up for me: https://www.youtube.com/watch?v=3XDyQnY5GHI
[18:02:21 CET] <familiyaF> No its not embedded in the video as side car. I have a SCC file which I want to mux in mxf container
[18:02:54 CET] <JEEB> no I mean how do you want it exactly? or you do not care as long as it's in the MXF?
[18:05:17 CET] <familiyaF> I want to insert it as a seperate stream within mxf
[18:06:05 CET] <JEEB> oh wow
[18:06:09 CET] <JEEB> we actually have an SCC reader now? :o
[18:06:24 CET] <JEEB> I mean the format isn't too complex
[18:06:34 CET] <JEEB> just caption packets with timecodes
[18:07:03 CET] <JEEB> but yea, then you should be able to mux that into MXF unless the MXF muxer hasn't been updated accordingly
[18:07:08 CET] <JEEB> the MXF reader at least supports caption tracks
[18:09:07 CET] <familiyaF> I think we do have SCC reader in ffmpeg
[18:09:56 CET] <JEEB> yes, that is what I was kind of surprised at :P
[18:10:19 CET] <JEEB> since I found sccdec.c having mention of the codec id
[18:13:59 CET] <familiyaF> I guess then I would need to update mxf muxer to add support mux 608 and 708 into MXF
[18:14:33 CET] <JEEB> well you can just try
[18:14:37 CET] <JEEB> if it works it works
[18:16:29 CET] <familiyaF> Thanks
[19:57:17 CET] <aughey> Using hwaccel, is it possible to access the texture on the video card to render directly without having to transfer to the main memory then back to the gpu?
[19:57:58 CET] <JEEB> in general yes
[19:58:18 CET] <JEEB> might be that some interfaces don't let you do that, but looking at how things were implemented in mpv etc with using the libavcodec hwaccels
[19:58:34 CET] <JEEB> you can get d3d9 textures from dxva2 and d3d11 textures from d3d11va f.ex.
[19:58:57 CET] <JEEB> vaapi has some sort of EGL interop thing with GL
[20:04:41 CET] <aughey> Thanks. I'll take a look at those resources to see if I can find anything. I might be able to double buffer the processing/ copying so that I can keep the gpu busy
[20:58:15 CET] <wondiws> hi furq
[23:46:21 CET] <a8_> i want to convert a folder full of videos into H265 with half the bitrate, but after doing some googleing i am confused
[23:46:54 CET] <a8_> How do i make ffmpeg target a certen bitrate and try not to go above it?
[23:49:07 CET] <a8_> i found documentation but it confused me
[23:50:01 CET] <JEEB> the average bit rate over the whole clip is -b:v for video. how well that works and how many passes are required depends on the encoder
[23:51:43 CET] <JEEB> -maxrate and -bufsize are when you are also caring about fluctuations all the time (the buffer of X bits to which encoded pictures are added and removed). mostly used to keep bandwidth in line with some bandwidth limitations (so that if you have X amount of bandwidth, you should always be able to buffer fast enough etc)
[23:54:43 CET] <a8_> can i set -maxrate to the same as i set -b:v?
[23:54:50 CET] <kepstin> there's usually no reason to use -maxrate and -bufsize unless you're dealing with specific hardware or specification limitations (like upload bandwidth on a low-latency live stream, a fixed-bandwidth broadcast tv channel, or a blu-ray drive's specified read speed)
[23:55:03 CET] <a8_> ok thanks guys so mutch
[23:56:21 CET] <JEEB> yea, that was what I was trying to say :P it's for keeping within an alotted amount of bandwidth all the time
[23:57:15 CET] <kepstin> in general with most software encoders, if all you want is to have the output file to be a certain size, then you should set -b:v and do a 2-pass encode.
[23:57:21 CET] <JEEB> while without it encoders such as libx264 (which have proper rate control) will utilize a lot more bits in the spots where they're needed, and a lot less where they're not needed
[23:59:40 CET] <a8_> ffmpeg -i h264Input.mp4 -c:v libx265  -b:v 6 -output h265output.mp4
[23:59:42 CET] <a8_> is this good?
[00:00:00 CET] --- Wed Dec 25 2019


More information about the Ffmpeg-devel-irc mailing list