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

[burek]

[00:35:23 CET] <ddubya> ok it seems the threads are per-frame and execute/execute2 are not used at all
[07:56:10 CET] <th3_v0ice> Can anyone shed some light on this issue? https://pastebin.com/P0Z6RQkB I am using API and I get the same message with scale_cuda.
[08:29:09 CET] <th3_v0ice> Or how to disable autoscale filter from API?
[09:17:11 CET] <yang> To (re)encode from Matroska to .avi (or a format visible on DVD players) do I just type "ffmpeg video.mkv video.avi" ?
[09:21:48 CET] <yang> seems not to work
[09:43:54 CET] <yang> I did it with "-i" not sure if it's optimal
[10:02:05 CET] <yang> but its actually a not well re-encoded stream
[10:02:09 CET] <yang> it has small cubes
[10:12:14 CET] <th3_v0ice> yang: You can try something like this ffmpeg -i video.mkv -c:v libx264 -crf 23 -c:a copy video.avi
[10:12:25 CET] <yang> thanks I will try
[10:13:23 CET] <yang> what is crf 23 ?
[10:13:25 CET] <th3_v0ice> adjust -crf value to one that suits your needs. Lower number is better but gives bigger file size. Min: 0 [best] -> Max: 51 [worst]
[10:13:56 CET] <th3_v0ice> basically that number is controlling quality
[10:15:49 CET] <yang> Does it matter if I "do work" on computer and lag the machine, does it has any effect on the re-encoding process ?
[10:26:29 CET] <th3_v0ice> It will simply take more time if you "do work" :)
[11:02:02 CET] <lofo> i'm trying to live-stream my Mac's screen over RTP. what am i doing wrong ? ffmpeg -re -f avfoundation -i "0" -c:v mpeg2video -q:v 20 -pix_fmt yuv420p -f rtp rtp://224.0.0.1:8081
[11:26:35 CET] <yang> th3_v0ice: with that command the bitrate goes to 14000kbit/s, while original video capture was around 3000kbit/s...and my load goes to 8 when re-encoding...hmmm
[11:33:17 CET] <BtbN> DVD players don't typically play h264
[11:34:43 CET] <yang> is there a way to re-encode with "slow" options on a very slow computer aswell ?
[11:34:55 CET] <yang> What would I need to apply to teh settings ?
[11:35:20 CET] <BtbN> It would just be slow.
[11:35:57 CET] <BtbN> You want mpeg2 for a DVD player. And mpeg2 is quite terrible.
[11:38:18 CET] <yang> I mean is there a way to re-encode with load not being over 1 with some kind of a ffmpeg "slow" setting ?
[11:44:02 CET] <pink_mist> yang: you don't want "slow" settings ... the "slow" ones all take *more* time. you want "fastest" or something
[11:44:19 CET] <yang> more time is fine, if the machine is slow
[11:44:39 CET] <pink_mist> ..... you just said .... uh, what
[11:44:47 CET] <BtbN> It will always use all available resources. And just finish faster or slower.
[11:44:58 CET] <yang> I mean takng more time to process encoding is fine, if I have a slow machine/CPU
[11:44:59 CET] <BtbN> You can limit the amount of threads it will use.
[11:59:10 CET] <yang> BtbN: Yes, it's using 7 threads seen in "htop"...
[11:59:20 CET] <yang> How can I limit that to 1-2 threads ?
[12:02:31 CET] <yang> ok it seems it's "threads 1"
[12:02:50 CET] <yang> but I still see 4 threads being in use
[12:06:23 CET] <yang> OK I see load going down
[13:31:10 CET] <th3_v0ice> Are there any examples of hardware transcoding using API?
[16:17:10 CET] <ddubya>  th3_v0ice: i don't know of any examples. maybe do the equivalent at the command line using "-loglevel trace" will give clues how the filter chain is built up
[17:17:35 CET] <th3_v0ice> ddubya: Thanks, I will try that.
[17:38:14 CET] <KodiakIT> Not strictly an ffmpeg question, got no response asking ##linux and #archlinux and thought you guys might know. If VCE is properly enabled for an AMD card it'd show up if I were to run 'lsmod | grep vce" right?
[17:41:31 CET] <kepstin[m]> what driver? with the regular open-source drivers i don't think there's a special log, but you can use the va-api tools (e.g. vainfo) to check if it's set up right.
[17:44:00 CET] <KodiakIT> Yeah, the FOSS one; xf86-video-amdgpu. I'll check with vainfo
[17:44:28 CET] <KodiakIT> Or rather I will, as soon as I find which package provides it.
[17:45:13 CET] <kepstin[m]> usually has 'libva' in the name, some distros call it 'libva-utils'
[17:46:10 CET] <KodiakIT> Was the latter. currently getting "
[17:46:18 CET] <KodiakIT> "vaInitialize failed with error code -1 (unknown libva error),exit" when I try to run it though
[17:47:30 CET] <kepstin[m]> hmm. the video decoding/encoding driver is provided by mesa, iirc.
[17:47:49 CET] <KodiakIT> Yep. I checked that mesa-vdpau is there, and pacman shows it is
[17:48:12 CET] <kepstin[m]> vdpau is something different, you want vaapi
[17:48:46 CET] <kepstin[m]> you're on arch? https://wiki.archlinux.org/index.php/Hardware_video_acceleration#ATI/AMD is a helpful page for you :)
[17:49:00 CET] <KodiakIT> Already had it open lol
[17:50:02 CET] <KodiakIT> I'm not exactly well versed on the peculiarities and differences between VA-API and VDPAU though, I was under the impression that the latter was AMD's alternative to Intel's VAAPI
[17:50:10 CET] <kepstin[m]> hopefully it's as simple as installing libva-mesa-driver to get it to work.
[17:51:03 CET] <KodiakIT> Fingers crossed! vainfo shows proper output now at least.
[17:51:40 CET] <kepstin[m]> right then, should be good. https://trac.ffmpeg.org/wiki/Hardware/VAAPI is the docs for how to use ffmpeg with vaapi, btw :)
[17:51:43 CET] <KodiakIT> Now to see if handbrake uses it or if I'll have to switch to Windows to get it to play nice.
[17:52:10 CET] <kepstin[m]> i dunno about handbrake specifically.
[17:52:18 CET] <KodiakIT> (I know it partly uses ffmpeg on the back end, just dunno about config wise if it's set up)
[17:52:45 CET] <kepstin[m]> (note also that amd's hardware video encoder, especially on pre-vega cards, isn't particularly good - if you're not doing e.g. realtime streaming, a software encoder is usually a better option)
[17:53:06 CET] <KodiakIT> Nah, digitizing some old optical media
[17:53:19 CET] <KodiakIT> Or rather attempting to.
[17:53:39 CET] <kepstin[m]> for that, i'd recommend using a software encoder. you'll get smaller files that look better.
[17:53:59 CET] <KodiakIT> If x265 weren't taking ~2h per episode, I would
[17:54:41 CET] <kepstin[m]> for <4k content, better to use x264 probably
[17:55:12 CET] <KodiakIT> Eh, I'm more concerned with space above all
[17:55:47 CET] <kepstin[m]> if you're mostly concerned about space, you should not use the hardware encoder
[17:56:34 CET] <KodiakIT> I mean, I've done tests, the VCE-x265 is smaller than the software-x264 of the same episodes...
[17:56:51 CET] <kepstin[m]> well, you can make anything smaller by setting the bitrate to whatever you like
[17:57:35 CET] <kepstin[m]> how does the visual quality compare?
[17:58:21 CET] <KodiakIT> I'm using RF18 as it stands right now, might re-encode later on with an ABR preset instead
[17:58:44 CET] <bencoh> I kinda doubt a hardware encoder would beat x264 as well, but ...
[17:58:57 CET] <kepstin[m]> note that the hardware encoder doesn't have a constant-quality mode like x264's crf
[17:59:14 CET] <kepstin[m]> (it has a constant-qp mode, iirc, but that's not the same thing)
[17:59:50 CET] <KodiakIT> Ah, in handbrake it's still refered to as RF not CQ like it is on VP8/9
[18:00:39 CET] <KodiakIT> Though AFAICT, this is still using the software encoder seeing as it's still got ~1h40m left and it's only ~7% done.
[18:01:56 CET] <kepstin[m]> i haven't personally done much with amd's video encoder, but in general i think the hardware hevc encoders have tended to get close to software h264 encoders in terms of efficiency?
[18:04:23 CET] <KodiakIT> Ah screw it, I'll just up the RF and do x264 as suggested, and then maybe re-run them with 10-bit x265 to squish em down further later.
[18:05:13 CET] <kepstin[m]> i'd recommend avoiding doing multi generations of lossy encodes :/
[18:06:39 CET] <KodiakIT> Well I don't have anywhere near that kinda space so
[18:07:17 CET] <KodiakIT> I literally just this past year finally got more than 1TB inside my tower (because my buddy gave me his old 2TB)
[18:08:08 CET] <KodiakIT> Hell I'm not sure I've got 4TB total between every device I have in the whole house
[18:09:54 CET] <kepstin[m]> well, your best option, assuming you don't want to keep the original files, is probably to encode each file from the original directly to the best available software encoding method at the quality/size you want.
[18:09:56 CET] <kepstin[m]> It'll be slow, but each time a video finishes you just delete the original then go on and do the next.
[18:12:44 CET] <kepstin[m]> (setting the quality/size tradeoff appropriately is the tricky bit; if you're using x264 or x265 you should start by doing some short sample encodes with different crf to see how small you can go before quality is an issue)
[18:13:49 CET] <KodiakIT> The time/space trade off isn't worth it for me. I need to free up the space from the DVD raws, if that means that my end-result RF18-x265 is slighly lower quality since it was converted from an RF15-x264 instead of the bloated MPEG-2, so be it
[21:49:03 CET] <matto312> Hello! I'm wondering if someone can point me in the right direction to debug a flood of "DTS 4294969402, next:2147485753967 st:1 invalid dropping
[21:49:03 CET] <matto312> PTS 4294969402, next:2147485753967 invalid dropping st:1" messages
[21:50:13 CET] <matto312> Input is live RTMP & output is multi-variant HLS ... I just can't figure out why sometimes the screen gets flooded with the "invalid dropping" messages ... any help that could push me in the right direction would be greatly appreciated
[21:50:32 CET] <matto312> I'm not sure where to begin to debug this
[21:57:45 CET] <matto312> anything thoughts at all on what may be causing this, I can't find anything on google
[21:58:03 CET] <matto312> https://pastebin.com/ZC27A6vY
[22:02:21 CET] <AppAraat> hi, I want to record my screen losslessly using ffmpeg but I can't seem to find the right command. Here it says "Lossless recording" but when I view the video the colors look smudged: https://www.bogotobogo.com/FFMpeg/ffmpeg_video_screencasting_screen_recording_capture.php
[22:04:29 CET] <kepstin> AppAraat: if you want to do actual lossless screen recording, you need to leave it in rgb
[22:04:57 CET] <AppAraat> so "-pix_fmt rgb" ?
[22:05:07 CET] <kepstin> remove the -pix_fmt option, and switch the encoder to -c:v libx264rgb (or another encoder that supports lossless rgb, like ffv1)
[22:06:26 CET] <kepstin> the "smudged" colours are caused by the conversion to yuv420p, which uses subsampled (quarter-resolution) colour data. This is fine for normal video, but causes issues with sharp edges in computer graphics.
[22:06:58 CET] <AppAraat> yeah I mainly want to record terminal text and stuff
[22:07:37 CET] <AppAraat> so now I have: ffmpeg -f alsa -ac 2 -i pulse -f x11grab -r 30 -s 1366x768 -i :0.0 -c:v libx264rgb -vcodec libx264 -preset ultrafast -crf 0 -threads 0 -acodec pcm_s16le -y output.mkv
[22:07:44 CET] <AppAraat> does that look all right?
[22:07:55 CET] <kepstin> no, you didn't do what i told you to do
[22:08:03 CET] <kepstin> er, wait,
[22:08:08 CET] <kepstin> you have redundant video encoders
[22:08:13 CET] <AppAraat> sorry, I'm very noob with ffmpeg
[22:08:14 CET] <kepstin> -c:v and -vcodec are the same option
[22:08:17 CET] <AppAraat> oh
[22:08:20 CET] <kepstin> and the second is overwriting the first
[22:09:21 CET] <AppAraat> so like this then? ffmpeg -f alsa -ac 2 -i pulse -f x11grab -r 30 -s 1366x768 -i :0.0 -vcodec libx264rgb -preset ultrafast -crf 0 -threads 0 -acodec pcm_s16le -y output.mkv
[22:09:30 CET] <kepstin> yeah, that should be fine.
[22:10:25 CET] <kepstin> note that the "-threads 0" option is redundant, that's the default
[22:10:35 CET] <kepstin> (0 means "auto")
[22:10:49 CET] <AppAraat> oh ok, I'll remove that then, thanks.
[22:11:49 CET] <AppAraat> seems to work, thanks :)
[22:19:26 CET] <matto312> Anything at all that could help me figure out what is causing the DTS PTS flood of  "invalid dropping st:1" ... I'll even take guesses, just trying to figure out where to look
[22:49:27 CET] <feettrip> Hi
[00:00:00 CET] --- Fri Jan 10 2020