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

[burek]

[00:02:12 CEST] <JEEB> seems so, picked probably by whomever made the FFmpeg filter
[00:02:21 CEST] <JEEB> seems like the zimg author benchmarked lanczos
[00:05:17 CEST] <furq> is zscale lanczos markedly better than swscale lanczos
[00:08:33 CEST] <JEEB> furq: also I think zimg does gamma-correct scaling although don't count me 100% on that
[00:08:45 CEST] <JEEB> while swscale (which scale uses) completely forgets about that
[00:22:51 CEST] <cryptodechange> So lanczos should be considered to have better results than bicubic/bilinear?
[01:16:11 CEST] <illuminated> so I have a couple quad core xeons in this server.  I would like to convert some x265 encoded videos to x264.  Is there a way to make ffmpeg to just hammer the cpu cores and provide a quick, high quality conversion?
[01:19:36 CEST] <furq> x264 doesn't really play nice with numa iirc
[01:19:57 CEST] <furq> aside from that any settings should scale to all the cores you have
[01:20:02 CEST] <furq> so you probably just want to run two at once
[01:24:06 CEST] <illuminated> hmm...k.  I need to figure out how to alter my script to initialize 2 jobs at once, then.
[01:28:43 CEST] <furq> for f; do ffmpeg &; ffmpeg &; wait; done
[01:31:09 CEST] <illuminated> http://termbin.com/nheg
[01:31:13 CEST] <illuminated> my current script
[01:42:16 CEST] <illuminated> guess I could do a ((var++)) expression and an if statement.  if [[ var -ne 2 ]]; then ffmpeg $filename &; else var=0; wait; fi
[01:42:19 CEST] <illuminated> or something like that
[01:51:21 CEST] <Hello71> !check [[ var -ne 2 ]]
[01:51:33 CEST] <Hello71> oh this isn't #bash lol
[01:53:14 CEST] <Hello71> parallelism doesn't work like that
[01:53:23 CEST] <Hello71> neither wait nor variables work like that
[01:54:22 CEST] <illuminated> ok, that's fine.  I'm still learning bash
[01:55:03 CEST] <illuminated> if you would, though, explain why those things won't do what I want.  You should be able to infer what I'm 'wanting' to do.
[01:55:13 CEST] <illuminated> I'm not being an ass or anything.  I just want to learn.
[02:03:53 CEST] <Hello71> you can try gnu parallel or xargs -P
[02:04:21 CEST] <Hello71> make sure you redirect ffmpeg input from /dev/null
[02:04:32 CEST] <Hello71> otherwise it might eat your input files
[02:04:37 CEST] <Hello71> ask #bash
[02:14:53 CEST] <illuminated> ok...
[02:14:53 CEST] <illuminated> ok cool
[02:16:49 CEST] <illuminated> I'm copying some source files first, adding those lines I mentioned to my script, and I plan to run it and see what happens.  part of learning is watching things fail, and then figuring out 'why' they acted in the manner they did when they failed.  so, presently, I want to see what this is going to do.
[02:46:35 CEST] <illuminated> hmmm... well it seemed to have worked
[02:49:43 CEST] <illuminated> it did 1&2, skipped 3, and did 4&5.  Waiting till 4&5 finish to see if it skips 6 and goes to 7&8.
[02:49:56 CEST] <illuminated> have to see what happens
[02:52:53 CEST] <illuminated> but on this test box.. it seems both vids render at about half the fps that a single vid renders at.  So, running 2 instances at a time doesn't seem to be gaining me anything.
[02:59:36 CEST] <illuminated> still.. kinda interested to see what is going to happen, though.  So, I'm letting this thing go
[03:05:54 CEST] <illuminated> ahhh... I get why it skipped 3.  It's going to skip 6 as well, and I understand why.
[04:54:11 CEST] <cryptodechange> Attempted a short test on my 4K HDR to UHD SDR conversion
[04:54:12 CEST] <cryptodechange> https://imgur.com/a/jQVrMGN
[04:54:23 CEST] <cryptodechange> Colours seem really washed out, not sure what went wrong in the filter settings
[04:55:49 CEST] <ariyasu> frame size is 1920x1080 :|
[04:55:55 CEST] <ariyasu> also uncropped
[04:56:02 CEST] <ariyasu> but what were your filter settings?
[04:56:23 CEST] <ariyasu> oh i see
[04:56:26 CEST] <cryptodechange> Included them in the description
[04:56:30 CEST] <cryptodechange> Haven't applied a crop yet
[04:56:33 CEST] <ariyasu> yeah im blind
[04:56:42 CEST] <cryptodechange> :D
[04:57:19 CEST] <cryptodechange> I tried bundling in the downsize when it sets the tonemap to bt709
[04:57:49 CEST] <cryptodechange> I'll try apply the downsize after format=yuv420p
[05:01:11 CEST] <cryptodechange> Following along the lines of this
[05:01:14 CEST] <cryptodechange> https://stevens.li/guides/video/converting-hdr-to-sdr-with-ffmpeg/
[05:33:51 CEST] <cryptodechange> Because it's also converting from x265 to x264, could it be doing that -before- applying the tonemap?
[05:36:58 CEST] <cryptodechange> hm, removing the following makes the issues go away: zscale=t=linear:npl=100,format=gbrpf32le,                                zscale=p=bt709,tonemap=tonemap=hable:desat=0,
[06:13:51 CEST] <illuminated> I can't believe how much better the compression for x265 is.  Have a 20 minute 1080p x265.  Re-encoded it to x264 with a CRF of 23 which, I think, pretty much kept the same bitrate as the source, and the output file was nearly 4 times larger than the input
[06:15:52 CEST] <illuminated> increased crf from 23 to 29.  Resulted in a 200 MB decrease in file size.  Now trying a crf of 35.  I'll see if the quality is acceptable.  I just want decent quality in a decent file size
[06:16:47 CEST] <illuminated> at a crf of 35 the bitrate has been a little more than halved.  So, I reckon we shall see how this turns out.
[06:24:20 CEST] <illuminated> wow, that quality was terrible
[06:29:37 CEST] <illuminated> according to the x264 encoding guide, slowing down the preset should increase the quality.  Why?
[08:34:17 CEST] <fella> illuminated: different presets pass different values to x264 options. slower preset means higher quality options in x264. If you're looking for smaller files, try '-vf hqdn3d' (see 'man ffmpeg-all'). It defaults to '4', which is a bit blurry imho, but '2' works good for me.
[14:09:59 CEST] <rkantos_> any idea how I can get this kind of stuff to work? https://gist.github.com/Brainiarc7/7b6049aac3145927ae1cfeafc8f682c1#gistcomment-2731987
[14:10:12 CEST] <rkantos_> can I use image2pipe somehow?
[14:11:12 CEST] <JEEB> you can't use vf/af and filter_complex together since filter_complex is a global filter chain kind of thing
[14:11:50 CEST] <JEEB> I feel like image2pipe isn't going to help you with that :P
[14:13:40 CEST] <rkantos_> I can't use rawvideo to pipe a complete frame to another ffmpeg instance that could then use the hw encoder?
[14:13:57 CEST] <JEEB> you can but that sounds like a rather roundabout way
[14:14:08 CEST] <JEEB> I mean, you can do the same stuff as with vf or af with filter_complex
[14:14:31 CEST] <JEEB> and vf/af with filter_complex never worked
[14:14:41 CEST] <JEEB> so it's not something that recently changed or so
[14:14:49 CEST] <rkantos_> no I understand this^^
[14:15:34 CEST] <rkantos_> That would also mean that gist is wrong though...
[14:16:03 CEST] <rkantos_> what do you mean by vf & af & filter_complex? how? :)
[14:16:19 CEST] <JEEB> well, filter complex just makes you spell out the whole thing
[14:16:40 CEST] <JEEB> but yea, the example definitely looks incorrect, probably copypasta
[14:16:45 CEST] <JEEB> the webcam overlay + logo
[14:16:47 CEST] <JEEB> thing at least
[14:17:00 CEST] <JEEB> which is the first one I found with both filter_complex and vf
[14:17:35 CEST] <rkantos_> yeah... that is what I need.. How should I really do it? I don't get it
[14:18:11 CEST] <JEEB> I'm going to expect the overlayed thing (called out) is what you want
[14:18:39 CEST] <rkantos_> yes!
[14:19:24 CEST] <JEEB> then it'd be "[out]format=nv12,hwupload,scale_vaapi=w=1920:h=1080[hwupload_out]" and then instead of -map "[out]" you do -map "[hwupload_out]"
[14:19:37 CEST] <JEEB> or you could even remove the yuv420p format from the middle
[14:19:49 CEST] <JEEB> but yea that seems like a mess
[14:19:59 CEST] <JEEB> either copypasta or something else
[14:20:20 CEST] <rkantos_> I just see it as being modified from the nvenc exampl.. hmm
[14:27:16 CEST] <rkantos_> JEEB: whatdo you mean instead of -map? How can I use map without filter_complex?
[14:27:31 CEST] <rkantos_> JEEB: Can you think of a similar example to that?
[14:27:55 CEST] <JEEB> no I mean since you were first picking the output of "out" you instead of that want the output of the hwupload_out
[14:28:07 CEST] <JEEB> the string I posted would go at the end of that filter_complex
[14:28:14 CEST] <JEEB> although I bet that line has other issues :P
[14:28:34 CEST] <JEEB> if it was just copypasted off another example and then hastily modified so that it's not even valid
[14:28:43 CEST] <JEEB> just report the issue to the author and have him fix his shit
[14:29:05 CEST] <rkantos_> well.. when you swap out h264_vaapi for libx264, it works without issues, if that helps
[14:29:29 CEST] <JEEB> probably because x264 doesn't need the hwupload part :P
[14:30:51 CEST] <JEEB> I am not going to sit and use my Sunday to fix up someone's broken example. I already told you how to stick the hwupload at the end of that filter_complex
[14:31:03 CEST] <JEEB> the rest is up to you or if you just have the author fix his shit
[14:32:11 CEST] <rkantos_> JEEB: well... of course not :D
[14:33:08 CEST] <durandal_1707> JEEB: play some computer game with gf
[14:35:49 CEST] <rkantos_> holy shit
[14:36:44 CEST] <rkantos_> JEEB: thanks! where do I donate a beer's worth? :P
[14:38:27 CEST] <rkantos_> JEEB: or whatever your vice is
[14:50:00 CEST] <rkantos_> now the only thing to figure out is how well Skylake+hevc_vaapi+mpegts+udp over 4g works :D:D
[14:50:33 CEST] <rkantos_> a skylake with a 5W TDP too lol
[14:51:36 CEST] <furq> i'm pretty sure quicksync is the same on every cpu of the same generation
[15:18:01 CEST] <kerio> shit?
[15:22:23 CEST] <rkantos_> furq, yeah, no I am more worried about udp,interframe codec and 4g :D
[16:40:57 CEST] <Adcock> Guys.
[16:41:27 CEST] <Adcock> What Video format produces smallest files for same quality?
[16:48:04 CEST] <Hello71> lol
[16:48:21 CEST] <Hello71> JEEB: so would you say hardcoded tables is not recommended anymore?
[16:49:18 CEST] <JEEB> I would say it was never recommended outside of very low-powered devices. also I still don't see a bug report on the FFmpeg trac regarding it if it's still an issue in master because while MIPS etc compilers are not gonna be updated in a while I bet for various misc hardware it's still likely a bug
[17:18:21 CEST] <Hello71> x86 isn't really miscellaneous
[17:32:28 CEST] <Hello71> never mind I just filed a ticket
[17:34:49 CEST] <w1kl4s> Can i convert .sup subtitles to .ass or .srt using ffmpeg?
[17:43:23 CEST] <furq> no
[17:43:31 CEST] <furq> sup is image-based so you'd need some ocr tool
[17:46:13 CEST] <JEEB> Hello71: I meant MIPS etc
[17:46:22 CEST] <JEEB> it was never meant to be used for x86(_64) as far as I can tell
[17:46:40 CEST] <JEEB> and thank you for making a ticket about it :P
[18:09:39 CEST] <the_k> https://youtu.be/uB-ZSbcwzhI
[19:52:35 CEST] <Hello71> I'm trying to re-encode a h264 video with x265. the source material claims to be 29.73 fps, but when I do ffprobe -show_frames | grep '^\[FRAME\]$' | wc -l and divide by the duration I get 76.57, and when I encode it it gives me 120 fps
[19:52:37 CEST] <Hello71> what gives
[19:53:20 CEST] <Hello71> is 120 a lie?
[19:53:50 CEST] <Mavrik> Video recorded with a phone perhaps?
[19:53:57 CEST] <Hello71> yeah, it's probably VFR
[19:54:40 CEST] <Hello71> pkt_duration_time is all different
[19:54:40 CEST] <Mavrik> Yeah, phones will give you VFR
[19:54:47 CEST] <Mavrik> Especially in those 120fps modes
[19:54:54 CEST] <Mavrik> Where you essentially get "best effort"
[19:55:23 CEST] <Hello71> my camera app says 30 fps
[19:56:40 CEST] <Mavrik> *shrug*
[19:56:49 CEST] <Mavrik> Are you sure it's not just misreporting on one side?
[19:57:46 CEST] <Hello71> and when I try to transcode it it runs at 0.1x speed for 3264x1836 with ultrafast on a pretty fast cpu
[19:57:53 CEST] <Hello71> pretty sure x265 should be faster than that
[19:58:55 CEST] <Mavrik> Sounds about right :P
[19:59:12 CEST] <furq> Hello71: -show_frames with no stream specifier will print audio and video frames
[19:59:20 CEST] <Hello71> oh. right.
[20:00:13 CEST] <furq> also there's really no point using x265 ultrafast
[20:00:41 CEST] <Hello71> well I want to use a slower one but then it's even slower
[20:00:52 CEST] <Hello71> is x265 actually that slow on higher resolutions?
[20:01:11 CEST] <furq> generally with x265, if it's running faster than x264 veryslow then it's going to look worse than x264 veryslow
[20:01:22 CEST] <furq> granted 0.1fps at ultrafast sounds broken
[20:01:29 CEST] <Hello71> not fps, speed
[20:01:32 CEST] <Hello71> 3.5fps it says
[20:01:40 CEST] <furq> that's still pretty slow
[20:01:50 CEST] <furq> granted i've never had cause to use it with anything above 1080p
[20:02:49 CEST] <Hello71> I guess I'll just use x264 then
[20:03:11 CEST] <furq> i take it this is some stupidly high rate cbr stream off a camera
[20:03:50 CEST] <furq> also you can just do ffprobe -count_frames and look at nb_read_frames
[20:07:18 CEST] <Hello71> 16 Mb/s for 3264x1836 seems higher than I need
[20:07:22 CEST] <Hello71> although I guess that's not absurd
[20:08:58 CEST] <Mavrik> 16mbps to me sounds like minimum I'd like for 4K :/
[20:09:27 CEST] <Hello71> nah, I want it to be potato quality :P
[20:09:36 CEST] <Hello71> (although I guess I should just resize it then)
[20:10:14 CEST] <Mavrik> Sounds reasonable :)
[20:29:01 CEST] <cryptodechange> HDR to SDR tonemapping (https://forum.doom9.org/showthread.php?t=175205) am I supposed to pipe this into another process (using |), or can I bundle the downscale and crop into the filter too?
[20:31:52 CEST] <JEEB> see the docs for the tone mapping filter
[20:32:18 CEST] <JEEB> it has examples of using the tonemap filter together with zimg
[20:32:22 CEST] <JEEB> *zscale
[20:32:31 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#tonemap
[20:32:49 CEST] <JEEB> and yes, at the point after that you can also scale
[20:35:17 CEST] <JEEB> the tonemap filter doesn't have the dynamic brightness calculation updated into it etc
[20:35:33 CEST] <JEEB> since it's pretty much the mpv stuff before it got updated
[20:36:16 CEST] <cryptodechange> The video filter examples I have found uses hable
[20:36:18 CEST] <cryptodechange> zscale=t=linear:npl=100,format=gbrpf32le,
[20:36:18 CEST] <cryptodechange> zscale=p=bt709,tonemap=tonemap=hable:desat=0,zscale=t=bt709:m=bt709:r=tv,
[20:36:18 CEST] <cryptodechange> format=yuv420p
[20:36:23 CEST] <durandal_1707> there is also opencl version
[20:36:35 CEST] <JEEB> the opencl version was funny enough copied from a newer version of mpv's tone mapping
[20:36:42 CEST] <JEEB> so IIRC it contains the brightness calculation
[20:36:56 CEST] <cryptodechange> and another slightly expanded (not sure the semantics of it) with the following as a prefix:
[20:36:57 CEST] <cryptodechange> zscale=tin=smpte2084:min=bt2020nc:pin=bt2020:rin=tv:t=smpte2084:m=bt2020nc:p=bt2020:r=tv,
[20:37:18 CEST] <JEEB> also yes, in that zscale you can also scale
[20:38:12 CEST] <cryptodechange> But I'm comparing it to mpv screenshots, the filter along with the ripped HDR HEVC version and ripped native SDR X264 version
[20:39:20 CEST] <cryptodechange> I've encoded a few sample frames to show me what each section of the filter does, I can upload an imgur in a second, but I don't think it really make a desired result
[20:39:24 CEST] <cryptodechange> It's still pretty saturated
[20:40:45 CEST] <JEEB> the tonemap filter is based on an old version of what mpv *used* to do
[20:41:00 CEST] <JEEB> it hasn't been synchronized since
[20:41:16 CEST] <JEEB> the intel guy who did an opencl filter for tone mapping later is based off of what mpv currently does
[20:44:52 CEST] <cryptodechange> aha, is it something I can use currently?
[20:45:48 CEST] <JEEB> it's in master as far as I remember
[20:47:08 CEST] <JEEB> wonder if it was completely ignored in the manpage
[20:47:15 CEST] <JEEB> since it's not on ffmpeg-all.html
[20:47:32 CEST] <durandal_1707> yes, documenttion failed in review process
[20:47:34 CEST] <JEEB> but yes, master has .name           = "tonemap_opencl"
[20:47:42 CEST] <JEEB> so tonemap_opencl is a thing
[20:47:44 CEST] <JEEB> in master
[20:48:00 CEST] <Hello71> does anyone know of open source video stabilization better than vidstab? in particular I'm looking for rolling shutter compensation
[20:48:10 CEST] <Hello71> seems like there's just deshake for virtualdub but that's not OSS
[20:48:11 CEST] <JEEB> and it's funny how haasn's work for mpv has become the de facto tone mapping thing in open source :P
[20:48:53 CEST] <JEEB> cryptodechange: not sure which dependencies you need for the opencl filters or the exact usage of it, but it's there in master branch at least :P
[22:05:08 CEST] <haasn> cryptodechange: share screenshots
[22:05:19 CEST] <haasn> or ideally share clips of the HDR and SDR versions of whatever movie you're testing with
[23:03:16 CEST] <oct_opus> hi. I am trying to setup ffserver to stream opus encoded audio (in mkv/webm)... unfortunately, when I open the stream, there is no sound... just plain silence but the counters run :/ Has anyone experienced similar pitfalls?
[23:04:00 CEST] <furq> probably not because nobody uses ffserver
[23:04:06 CEST] <furq> especially not since it got deprecated
[23:04:12 CEST] <furq> for opus you'd be better off using icecast
[23:06:05 CEST] <oct_opus> furq: oh, i totally missed that >.<
[23:16:32 CEST] <Hello71> wasn't ffserver removed in 4.0
[23:18:19 CEST] <BtbN> it was deprecated since forever, and was eventually finally removed, yes
[23:29:16 CEST] <atomnuker> there's a replacement https://github.com/klaxa/ffserver
[23:30:28 CEST] <BtbN> it's far from the same featureset though
[00:00:00 CEST] --- Mon Oct 15 2018