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

[burek]

[00:00:03 CEST] <kepstin> if you're comparing encoders, encoding to precise size is a good idea tho :)
[00:00:08 CEST] <Diag> ^
[00:00:33 CEST] <Diag> hey man, going from slower to placebo shaved off an extra 60k from 2.4 megs
[00:00:43 CEST] <Diag> thats important bandwidth
[00:00:48 CEST] <kepstin> most of that probably came from the slower to veryslow change
[00:01:13 CEST] <Diag> I remember yall sayin placebo is redundant almost
[00:01:27 CEST] <kepstin> and also changing the preset shouldn't change the size
[00:01:30 CEST] <Diag> now to compare it to vce         /s
[00:01:34 CEST] <kepstin> since you're targetting a bitrate :/
[00:01:43 CEST] <Diag> It did tho :S
[00:02:09 CEST] <kepstin> some sort of rate control issue then :/
[00:02:15 CEST] <BtbN> That probably means that the given target bitrate is more than it needs for "perfect" quality
[00:02:15 CEST] <furq> preset and size are pretty much never related
[00:02:24 CEST] <furq> or they shouldn't be
[00:02:29 CEST] <kepstin> yes, but this is a bitrate-target 2-pass encode
[00:02:34 CEST] <kepstin> so size should be fixed
[00:02:36 CEST] <kepstin> quality changing
[00:02:43 CEST] <Diag> obviously yall needa write yo shit better
[00:02:53 CEST] <furq> sure, i'm just saying it wouldn't be true in crf mode either
[00:03:03 CEST] <furq> any changes in final bitrate are coincidental
[00:03:08 CEST] <kepstin> i wouldn't be surprised if the rate control in placebo mode just undershot :)
[00:03:12 CEST] <FooNess> Diag, if you have a two-pass encode and you're targetting a specific bitrate and you know how long the stream is, I am not sure where the size difference is coming from.
[00:03:29 CEST] <Diag> :shrug:
[00:03:36 CEST] <kepstin> probably placebo mode rate control isn't as well tested as the other options
[00:03:37 CEST] <Diag> its actually a little more than i thought
[00:03:40 CEST] <BtbN> the encoder not needing as many bits as you gave it is the most likely reason
[00:03:44 CEST] <furq> it wouldn't surprise me if rc in placebo was less accurate just because those settings have been tested a lot less
[00:03:46 CEST] <FooNess> Hmmmm.
[00:03:49 CEST] <Diag> 2.43 megs vs 2.34
[00:04:09 CEST] <BtbN> That's so tiny, it's little more than noise
[00:04:15 CEST] <furq> yeah
[00:04:34 CEST] <Diag> well i did say 60k, jeez
[00:04:41 CEST] <furq> i know 60KB of 2.4MB is quite a lot but that's not going to scale as the file gets larger
[00:05:33 CEST] <kepstin> hmm, interesting. some stuff in a netflix tech blog post suggest they're using eve-vp9
[00:05:35 CEST] <furq> also bear in mind you'll likely be clamped on refs if you want hwdec compatibility
[00:05:47 CEST] <furq> which limits the gains you'll get from veryslow/placebo
[00:05:54 CEST] <Diag> heh
[00:06:08 CEST] <furq> you get like 3 refs at 1080p for level 4.1 compliance
[00:06:15 CEST] <furq> or 4.2 or whatever you're supposed to use
[00:06:28 CEST] <Diag> im actually like
[00:06:41 CEST] <Diag> really surprised at how "ok" this looks
[00:06:44 CEST] <kepstin> https://medium.com/netflix-techblog/performance-comparison-of-video-coding-standards-an-adaptive-streaming-perspective-d45d0183ca95 has some comparisons including eve that might actually be valid.
[00:06:54 CEST] <furq> i know you started with x264 slower hours ago and you don't want to have gone through all of this to end up back there
[00:07:01 CEST] <furq> but you really were right the first time
[00:07:06 CEST] <Diag> hmm?
[00:07:10 CEST] <Diag> Im just experimenting
[00:07:21 CEST] <Diag> and im cold so i need cpu load
[00:07:25 CEST] <furq> lol
[00:07:35 CEST] <Diag> ive already got solidworks rendering
[00:07:39 CEST] <furq> what's the use case for this anyway
[00:07:48 CEST] <Diag> yes
[00:07:54 CEST] <Diag> http://tyronesbeefarm.com/images/20192ca48392-b5ec-410c-94f0-41aa388ae74d.jpg
[00:07:56 CEST] <Diag> >solidworks
[00:08:08 CEST] <Diag> >12690 iterations
[00:08:35 CEST] <Diag> there is no 'real' use case
[00:08:53 CEST] <Diag> i just wanted to make my little recorded snippits look nicer because ive got too much cpu power to care
[00:09:23 CEST] <kepstin> huh, when you zoom in on that you see squares from the edges of the noise texture, it guess it doesn't tile well? :/
[00:09:40 CEST] <Diag> Yeah idunno what that is
[00:09:44 CEST] <Diag> its an issue with prorender
[00:09:56 CEST] <Diag> thats just a bullshit material slapped on a model i made
[00:09:59 CEST] <kepstin> some bad looking stretching (uv issue?) around the bends too.
[00:10:05 CEST] <Diag> heh
[00:10:07 CEST] <Diag> thats solidworks
[00:10:24 CEST] <Diag> you can go through and let it do proper projections but i just needed something to render
[00:10:35 CEST] <Diag> http://tyronesbeefarm.com/images/2018195105.jpg
[00:10:40 CEST] <Diag> this is a more proper render of that
[00:13:24 CEST] <Diag>  http://tyronesbeefarm.com/images/2018002304.png
[00:13:25 CEST] <Diag> internals
[00:13:52 CEST] <Diag> http://tyronesbeefarm.com/images/2018164350.jpg
[00:14:01 CEST] <Diag> another quick render with materials just slapped on
[15:32:31 CEST] <Fyr> guys, how do I cut a video file into pieces with a single command? I need:
[15:32:31 CEST] <Fyr> -i "input.mp4" -ss XX -t Y out1.mp4 -ss ZZ -to WW out2.mp4
[15:32:31 CEST] <Fyr> etc
[15:51:20 CEST] <DHE> Fyr: there's a 'segment' muxer you might like
[15:51:29 CEST] <DHE> https://ffmpeg.org/ffmpeg-formats.html#segment
[15:53:10 CEST] <pink_mist> I mean .. shouldn't what Fyr already showed work fine?
[15:53:33 CEST] <DHE> "with a single command" would be the operative bit
[15:53:49 CEST] <pink_mist> how is that not a single command?
[15:53:56 CEST] <DHE> well that give 1 piece
[15:54:05 CEST] <pink_mist> ?
[15:54:30 CEST] <DHE> oh I misread it...
[16:00:41 CEST] <Fyr> thanks
[16:00:54 CEST] <Fyr> but -f segment is a complicated thing.
[16:29:49 CEST] <Classsic> Hi, any freelancer expert on -complex_filter?
[16:30:06 CEST] <chauffer> what's a freelancer expert
[16:30:49 CEST] <durandal_1707> expert that do things for free or underpaid?
[16:31:46 CEST] <Classsic> ok somebody interest, please sendme pm.
[16:36:37 CEST] <rocktop> I used this to split the video but I have a problem with audio is not synced
[16:36:44 CEST] <rocktop> this : /usr/local/bin/ffmpeg -i 'in.mp4' -ss 600 -t 301 -c copy -async 1 'out.mp4'
[16:37:06 CEST] <rocktop> anyidea how to fix this issue ?
[16:37:28 CEST] <JEEB> depends, in general the things should just work. as the first thing I would disable advanced edit list code by GOOG
[16:38:04 CEST] <JEEB> -advanced_editlist 0 before input
[16:38:15 CEST] <JEEB> also why are you setting async :P
[16:38:26 CEST] <JEEB> I thought that only does something if you actually resample audio
[16:38:29 CEST] <JEEB> which -c copy will not be doing
[16:51:56 CEST] <dastan> hello people
[16:52:07 CEST] <JEEB> ohai
[16:53:11 CEST] <dastan> i am creating a shell script with ffmpeg
[17:05:58 CEST] <dastan> this is mi script
[17:06:02 CEST] <dastan> https://pastebin.com/jTmQDrzZ
[17:06:39 CEST] <dastan> but i am receiving a This gives me an error saying "No such file or directory".
[17:06:53 CEST] <dastan> can someone help me?
[17:08:10 CEST] <Classsic> do you have the url for testing?
[17:09:18 CEST] <BtbN> Is raw pcm in hls even supported?
[17:09:39 CEST] <BtbN> And nvenc without any quality parameters will not yield something nice
[17:09:47 CEST] <BtbN> Can't you just copy?
[17:17:12 CEST] <dastan> if i send the command without scripting works ok
[17:18:35 CEST] <another> dastan: you are trying to write to /home/build/MSS-ONE/temp/cache/$project-$intnumber
[17:18:50 CEST] <another> that directory probably doesn't exist
[17:21:29 CEST] <dastan> ok, i missed up the mkdir command
[17:27:38 CEST] <dastan> it gives me the same error
[17:30:18 CEST] <dastan> https://pastebin.com/mMtX0EVK
[20:10:14 CEST] <Classsic> hi everybody.
[20:10:43 CEST] <Classsic> is there a way to sync two input rtmp to use with vstack?
[20:11:56 CEST] <Classsic> I try use -use_wall_clock_as_timestamps and copyts option, and it works, but get stuttering playback
[20:13:52 CEST] <cehoyos> Command line and complete, uncut console output missing / try the buffer filter or a larger network buffer
[20:24:33 CEST] <Classsic> how long command I can paste here?
[20:24:46 CEST] <JEEB> use pastebin.com or gist or something
[20:24:48 CEST] <JEEB> and link here
[20:24:54 CEST] <JEEB> that way you can have the command and the full terminal output
[20:34:41 CEST] <durandal_1707> vstack expect normal timestamps
[20:35:17 CEST] <durandal_1707> rtmp is not generally providing one
[21:47:59 CEST] <intrac> I'm encoding an image sequence + audio where the audio is longer. although ffmpeg will extend the last frame to match the audio, it doesn't appear to be repeating it as such
[21:48:55 CEST] <intrac> as I'm using the noise filter which becomes static on the last frame of the image sequence
[21:49:30 CEST] <intrac> is there a way to get ffmpeg repeat the last input frame so that the noise animates right to the end?
[21:49:56 CEST] <durandal_1707> noise filter can be set to temporal
[21:55:48 CEST] <intrac> yes, it already is but the grain becomes static when the last input frame is reached (audio continues for some seconds more)
[21:56:00 CEST] <intrac> -vf noise=c0s=4:c0f=t
[21:56:54 CEST] <intrac> I guess because the noise filter only applies grain to different incoming frames
[21:58:01 CEST] <durandal_1707> no, you will need to use tpad filter
[21:58:25 CEST] <durandal_1707> in addition with -shortest option
[22:00:45 CEST] <intrac> I can't see a mention of tpad. is it a recent addition?
[22:00:54 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#tpad
[22:01:05 CEST] <furq> new in 4.2 apparently
[22:01:21 CEST] <intrac> yep, not recognised as a video filter here. 3.4.4. drat
[22:01:33 CEST] <furq> https://www.johnvansickle.com/ffmpeg/
[22:01:42 CEST] <durandal_1707> 3.4.4 is very old
[22:05:49 CEST] <intrac> yep. I'm still on suse leap 15.0
[22:06:33 CEST] <intrac> I'll try and plan in an upgrade this weekend
[22:06:41 CEST] <intrac> thanks for the tpad suggestion
[22:28:36 CEST] <Classsic> cehoyos here get the command+log https://gist.github.com/Classsic/49b00d4e68dc54a342f54a6cffb0823f
[22:32:00 CEST] <cehoyos> Looks like a performance issue
[22:46:45 CEST] <cpusage> Hi
[22:47:13 CEST] <cpusage> I have a quick question in regards to optimizing ffmpeg for a 3900x (12 core, 24 thread)
[22:47:46 CEST] <cpusage> for some reason, when I was utilizing a 1800x and a 3800x, the CPU usage would be at 100%
[22:48:17 CEST] <cpusage> when I switched to the 3900x, CPU usage lingers around 60%
[22:48:46 CEST] <cpusage> (using the same transcoding/encoding commands)
[22:49:42 CEST] <furq> pastebin the command
[22:49:46 CEST] <furq> and output
[22:53:14 CEST] <cpusage> the command is extremely simple, just transcoding/encoding some h264 content into h265
[22:53:50 CEST] <cpusage> https://pastebin.com/KVWCYWgt
[22:54:44 CEST] <ritsuka> you've got too many cores
[22:55:38 CEST] <cpusage> so, it's a limitation of ffmpeg?
[22:58:15 CEST] <furq> it's a limitation of whatever encoder you're using
[22:59:02 CEST] <cpusage> ah, so it's a limitation of libx265
[22:59:42 CEST] <cpusage> any idea why there are random frame drops as well?
[22:59:43 CEST] <cpusage> https://imgur.com/a/wsr9vRx
[23:04:43 CEST] <cehoyos> (The command line withoutthe complete, uncut console output is useless and FFmpeg does not contain a hevc encoder)
[23:05:07 CEST] <cehoyos> The x265 developers once wrote a patch that raises the cpu consumption for cases like yours to 100%
[23:05:18 CEST] <cehoyos> The patch had a disadvantage though:
[23:05:39 CEST] <cehoyos> It reduced overall encoding speed, the decision was therefore not to include the patch
[23:20:25 CEST] <cpusage> cehoyos would this suffice?
[23:20:55 CEST] <cpusage> https://pastebin.com/TC4muXjF
[23:22:37 CEST] <cpusage> Any suggestions or advice to fully utilize the 3900x during encodes, and to stop the dropping of frames would be much appreciated
[23:24:19 CEST] <cehoyos> Again: Not using the full cpu power is a property of a sane encoder
[23:24:31 CEST] <cehoyos> Frame dropping is of course not encoder-related.
[23:24:58 CEST] <cehoyos> (No, very obviously not)
[00:00:00 CEST] --- Sun Aug 25 2019