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

[burek]

[00:01:07 CEST] <BtbN> I don't think it's possible
[00:01:17 CEST] <alphabitcity> Is there a "crop if bigger otherwise scale" filter? I want to use ffmpeg to resize videos to 1280x720, but if the video is larger, I want it to crop and use the center, and if it's smaller, stretch it
[00:01:53 CEST] <kepstin> alphabitcity: you can build it yourself by using scale & crop filters with math expressions rather than static values
[00:03:18 CEST] <kepstin> BtbN: hmm, I guess you're right. I dunno how flexible the frame reordering is in h264.
[00:03:39 CEST] <BtbN> I don't think B frames can exist with _only_ forward references
[00:03:54 CEST] <alphabitcity> kepstin: thanks! i'm failing at googling this .. can you point me in the right direction? what should i search for to learn more about math expressions w/ filters?
[00:04:01 CEST] <BtbN> Your usual gop is something like IPB...BP
[00:04:14 CEST] <nicolas17> Threads: B means bidirectional, there's only one direction if it's the first frame... what would the reference frames be?
[00:04:34 CEST] <BtbN> the I frame after it, but like you set, it needs forward and backward references
[00:04:38 CEST] <BtbN> *said
[00:05:17 CEST] <kepstin> right, a typical gop is often like IBBPBBPBBP or something in pts order, which is saved as IPBBPBBPBB in dts order (so the forward reference is available before the B frame is decoded)
[00:05:29 CEST] <nicolas17> if B frames were that flexible, maybe you could reverse a video without reencoding :P
[00:07:30 CEST] <kepstin> alphabitcity: read the docs for the scale filter https://www.ffmpeg.org/ffmpeg-filters.html#scale-1 and crop filter (same page), they list the parameters that take expressions and the available variables you can use. Some examples there too.
[00:07:51 CEST] <kepstin> alphabitcity: full expression syntax info is at https://www.ffmpeg.org/ffmpeg-utils.html#Expression-Evaluation
[00:07:58 CEST] <alphabitcity> kepstin: tyvm
[00:09:04 CEST] <jkqxz> The forward/backwardness in referencing is entirely specified by the stream.  You can make references to any frames you like, they don't need to have any particular POC order.
[00:09:32 CEST] <nicolas17> jkqxz: can a P frame only reference a 'previous' frame?
[00:09:35 CEST] <nicolas17> and if so how is 'previous' defined?
[00:09:45 CEST] <jkqxz> And the frames needn't even be unique.  You can send an I frame and then a B frame with lower POC which refers to the I frame for all references.
[00:09:56 CEST] <jkqxz> No, a P frame can reference any other frames it likes.
[00:10:01 CEST] <jkqxz> (One or more.)
[00:10:04 CEST] <kepstin> alphabitcity: the basic construction i'd recommend is have a scale filter first which resizes larger if the video is small, then a crop that takes the center bit (and implicitly does nothing on a video already the right size)
[00:10:16 CEST] <nicolas17> jkqxz: with that flexibility, what's the difference between P and B?
[00:10:46 CEST] <kepstin> nicolas17: number of other frames that can be referenced, I guess? P is max 1, B is more.
[00:11:04 CEST] <nicolas17> ah, jkqxz said "one or more" and confused me :)
[00:11:09 CEST] <jkqxz> B frames can use bidirection prediction, with two input frames for a given macroblock (selecting any two frames from the available references).  P frames can only use one frame for the reference for a single macroblock, but it can again be any of the available frames.
[00:11:14 CEST] <alphabitcity> kepstin: that sounds right, ty. the semi-tricky part there is implementing the conditional logic for scale .. but doesn't seem to bad. thanks again
[00:11:28 CEST] <nicolas17> oh it's per MB
[00:12:01 CEST] <kepstin> and h264 of course lets you mix different types of macroblocks in the same frame, too
[00:12:09 CEST] <jkqxz> Yes.  The B vs. P only influences the set of prediction modes you are allowed to pick, and how the reference picture lists work by default.  The second of those can be completely overridden replacing the lists with anything you like.
[00:13:20 CEST] <nicolas17> so in theory could you reverse a video without fully decoding and reencoding? if you have an I and a P based on it, make it PI where the P depends on the I in the future :P
[00:13:21 CEST] <jkqxz> So a P frame can reference up to 16 frames which were previously encoded (but may be in the future in presentation order), but only one in each macroblock.
[00:13:47 CEST] <jkqxz> A B frame can do the same thing, but has additional modes to reference any two of the 16 frames.
[00:14:45 CEST] <jkqxz> Yes, except the amount of reordering is limited.  You can't make 100 frames each referring to the following one in presentation order, because that would need to buffer 100 frames which isn't allowed by the level limits.
[00:15:00 CEST] <nicolas17> oh sure, it would turn into a pretty horrible output file
[00:15:21 CEST] <kepstin> so in theory it could be done, if the video is closed gop and the gop size is 16 frames or less, I guess?
[00:15:36 CEST] <jkqxz> If your GOP is short enough, then yes you can reverse a video like that.
[00:16:32 CEST] <jkqxz> Limit is probably more than 16 if you have unreferenced frames, but it deepends on your GOP structure.  For IPPPP... only, then yes.
[00:17:29 CEST] <nicolas17> reversing a video even with full reencoding is more annoying than it should be
[00:17:41 CEST] <jkqxz> Though note that your first frame must be an I frame, not an IDR frame (since you're not allowed to define frames which follow an IDR frame in encode order but get presented before it).
[00:18:41 CEST] <nicolas17> it could be done one GOP at a time (from the last one), but I haven't seen tools that can do that, all guides I saw decode the entire video into images on disk and then encode it back
[00:20:22 CEST] <kepstin> reversing a video like that doesn't really fit into how ffmpeg is built, either; it could be done in ffmpeg.c i guess, or some pseudo-format
[00:20:34 CEST] <nicolas17> yeah it would need a separate tool
[01:37:50 CEST] <_Vi> How do I refer to another video's width and height in "scale" filter?
[01:38:12 CEST] <_Vi> I want two input video to be scaled to the same size.
[02:42:11 CEST] <c_14> _Vi: You write a script
[02:42:31 CEST] <_Vi> c_14, So no inline way?
[02:42:38 CEST] <c_14> nope
[02:42:43 CEST] <_Vi> OK.
[02:44:01 CEST] <kazuma_> use media info to script it _vi
[02:44:38 CEST] <c_14> ffprobe might be easier, that can output json/csv etc
[02:45:16 CEST] <_Vi> Actually already hardcoded fixed width and height, so no need anymore.
[03:49:23 CEST] <kerio> does ffvhuff fit in flv
[03:49:28 CEST] <kerio> for the purpose of rtmp
[04:39:39 CEST] <kepstin> _Vi: if you're running both videos through ffmpeg, look at the 'scale2ref' filter
[05:41:00 CEST] <kerio> how do i rtmp a gray16 video D:
[05:47:06 CEST] <furq> you don't
[05:57:59 CEST] <kerio> furq pls gibe lossless gray16 on rtmp
[06:22:50 CEST] <thebombzen> Alright, I just enabled my Skylake's GPU in the bios. With FFmpeg do I have to do something fancy to use it as an hwaccel (like -vf hwupload) cause I'm not sure how to use it
[06:32:45 CEST] <atomnuker> -hwaccel vaapi -vaapi_device /dev/dri/renderD128 before input to decode
[06:33:36 CEST] <thebombzen> atomnuker: does it matter that I have /dev/dri/renderD128 and /dev/dri/renderD129?
[06:33:45 CEST] <atomnuker> probably not
[06:34:00 CEST] <thebombzen> do I need -codec:v h264_vaapi or similar?
[06:34:25 CEST] <atomnuker> no
[06:34:34 CEST] <atomnuker> to decode anyway
[06:34:38 CEST] <thebombzen> I've discovered in my experiences that using -hwaccel cuvid does not use cuvid decoding, but using -codec:v h264_cuvid before -i does
[06:35:02 CEST] <atomnuker> cuvid sucks and its not a hwaccel, vaapi os
[06:35:11 CEST] <atomnuker> *is
[06:35:40 CEST] <atomnuker> h264_vaapi is only needed to encode, and that's when you need -vf hwupload
[06:36:57 CEST] <thebombzen> atomnuker: do I also need -vaapi_device?
[06:37:33 CEST] <atomnuker> only if you use wayland I think
[06:37:54 CEST] <thebombzen> also, cuvid is printed out by ffmpeg -hwaccels, so what do you mean when you say it's not an hwaccel
[06:40:47 CEST] <atomnuker> fucked if I know, it requires nonfree nvidia cancer
[06:43:59 CEST] <thebombzen> atomnuker: I'm decoding at about 150 fps with my Skylake's gpu and about 400 with my Skylake cpu using ffh264's software decoder
[06:44:03 CEST] <thebombzen> is this expected?
[06:44:19 CEST] <thebombzen> this is 1920x1080 H.264 video with a very high bitrate
[06:51:38 CEST] <furq> i would have expected that
[06:53:27 CEST] <atomnuker> yep, that's normal
[06:54:23 CEST] <thebombzen> is vaapi's hwdec useless for Skylakes without QSV?
[06:54:33 CEST] <thebombzen> should I just expect to use ffh264 + vaapi's encoder without QSV?
[06:55:22 CEST] <thebombzen> interestingly, I tried it again on a 10-bit HEVC file with a lower bitrate (17M as opposed to like 100M) and they decoded about the same
[06:55:41 CEST] <thebombzen> not sure if it's because ffmpeg fellback to ffhevc or if the lower bitrate made all the difference on my Skylage GPU
[06:59:37 CEST] <thebombzen> Hm, I'm trying vaapi hardware encoding, and I'm getting a weird error:
[06:59:40 CEST] <thebombzen> [h264_vaapi @ 0x5559980db960] Failed to end picture encode issue: 6 (invalid VASurfaceID).
[06:59:44 CEST] <thebombzen> http://sprunge.us/RRbH
[07:00:56 CEST] <thebombzen> I'm not sure what I'm doing wrong here :P
[07:02:15 CEST] <thebombzen> setting the bitrate to something sane (-b:v 2000k), setting -qp, and using a real muxer rather than -f null, none of these did anything
[07:12:23 CEST] <atomnuker> you still need -hwaccel vaapi
[07:15:31 CEST] <ffpure> guys, does anyone know why colorkey filter is not working for me? I'm trying to do this:
[07:15:33 CEST] <ffpure> ffmpeg -i green_rabbit.jpg -vf colorkey=0x2fc145:0.4:0.2 -y green_rabbit_fixed.jpg
[07:15:51 CEST] <ffpure> but it won't remove the green areas
[07:16:20 CEST] <ffpure> this is the image: https://il6.picdn.net/shutterstock/videos/3548021/thumb/1.jpg
[07:17:06 CEST] <ffpure> if i do an overlay, it works
[07:18:04 CEST] <thebombzen> ffpure: most likely it's an alpha channel thing. try writing it to a PNG and see what happens
[07:18:44 CEST] <ffpure> yeah, i thought so too. same thing...
[07:19:21 CEST] <ffpure> do we have a filter to make the jpg an alpha channel BEFORE the colorkey filter?
[07:23:56 CEST] <thebombzen> ffpure: try using -vf format=yuva444p,colorkey=blah
[07:25:36 CEST] <ffpure> no change. same with ffplay:
[07:25:38 CEST] <ffpure> ffplay green_rabbit.jpg -vf "format=yuva444p,colorkey=0x2fc145:0.4:0.2"
[07:29:15 CEST] <durandal_1707> ffpure: you need overlay
[07:30:26 CEST] <ffpure> but i don't have two videos. I just want the green colors to become transparent, so that i can put the output file as an overlay later
[07:31:44 CEST] <durandal_1707> ffplay doesnt display transparent colors
[07:32:32 CEST] <ffpure> yeah but at least it should show black...
[07:32:46 CEST] <ffpure> right now it does not change green pixels at all
[07:33:42 CEST] <furq> that command works for me
[07:34:45 CEST] <ffpure> furq: which one?
[07:34:52 CEST] <furq> ffmpeg -i 1.jpg -vf colorkey=0x2fc145:0.4:0.2 1.png
[07:34:56 CEST] <furq> http://i.imgur.com/LwKSsfF.png
[07:35:23 CEST] <ffpure> wow!
[07:36:11 CEST] <thebombzen> furq: imagine that
[07:37:35 CEST] <ffpure> furq: you are right, but now try to play it: ffplay 1.png
[07:37:50 CEST] <furq> 06:31:44 (@durandal_1707) ffplay doesnt display transparent colors
[07:38:13 CEST] <furq> you shouldn't base any knowledge off what ffplay does
[07:38:31 CEST] <furq> it's intentionally very basic
[07:38:35 CEST] <ffpure> but how does it know those colors were green? haha
[07:38:53 CEST] <ffpure> 1.png has them transparent
[07:38:56 CEST] <furq> colorkey probably isn't changing the colours of those pixels
[07:38:59 CEST] <furq> it's just setting the alpha channel
[07:39:08 CEST] <ffpure> hmmm i see...
[07:39:26 CEST] <furq> it should still work fine with overlay
[07:40:07 CEST] <ffpure> ok that's good for me because i'm not using ffplay... I just didn't check them with another app...
[07:40:11 CEST] <ffpure> thanks guys!
[07:55:41 CEST] <thebombzen> furq: you stealing my advice kudos? :)
[09:11:04 CEST] <kerio> hm, is nginx my best bet for a rtmp server nowadays?
[09:13:31 CEST] <furq> yes
[09:18:14 CEST] <kerio> but i dont wanna :>
[09:18:15 CEST] <kerio> :<
[09:18:39 CEST] <kerio> is ffserver actually that bad
[09:24:10 CEST] <_Vi> kepstin, Thanks. Expected that this mode is just some special parameter of scale, like "scale=in[b]_w" or "b_w" or "in_b_w", not a separate filter.
[09:34:41 CEST] <thebombzen> kerio: ffserver is deprecated
[09:34:47 CEST] <thebombzen> so yea, you should use nginx
[09:39:41 CEST] <furq> kerio: ffserver is an unusable piece of shit
[09:39:51 CEST] <furq> and it has been for years
[10:34:44 CEST] <kerio> ayy it takes like 20 hours to build ffmpeg on pi0
[10:37:10 CEST] <furq> of course it does
[10:37:13 CEST] <furq> what did you expect
[10:37:24 CEST] <furq> this is why god gave us cross compilers
[10:46:30 CEST] <kerio> fuck it i'll gstreamer
[10:57:49 CEST] <furq> "six weeks to get a doctor's appointment to get my ear syringed? fuck it, i'll just cut my leg off"
[10:57:58 CEST] <furq> that's you. that is an impersonation of you
[10:59:13 CEST] <kerio> ye i gave up on gstreamer
[11:01:09 CEST] <furq> cross compiling is easy and fun
[11:01:26 CEST] <kerio> ayyy
[11:39:00 CEST] <thebombzen> durandal_1707: do you read DOA? or is that a different durandal who commented on the DOA thread?
[11:50:41 CEST] <durandal_1707> thebombzen: what is doa?
[12:31:49 CEST] <thebombzen> durandal_1707: Dumbing of Age. http://0x0.st/GO0.png
[12:33:31 CEST] <durandal_1707> thebombzen: he stole my identity, i will report that to higher authorities
[12:36:27 CEST] <furq> lol
[12:36:32 CEST] <furq> i always knew durandal_1707 was a big doctor who fan
[12:38:19 CEST] <thebombzen> what does the 1707 even mean? I assume this is durandal from Marathon but where does 1707 come from
[12:38:52 CEST] <furq> http://durandaljs.com/get-started.html
[12:39:58 CEST] <thebombzen> ah, I see
[12:39:59 CEST] <thebombzen> https://vignette2.wikia.nocookie.net/marathongame/images/c/c7/Durandal_Logo.gif/revision/latest?cb=20071016151637
[13:36:25 CEST] <Asuran> hi, im using: ffmpeg -i %1 -c:v libx265 -preset:v slow -crf 19 -x265-params rd=6:psy-rd=0.01:psy-rdoq=0.41 -c:a libopus -b:a 96k -vbr on -packet_loss 0 -compression_level 10 -application audio "%~n1".mkv - my question is: how can i better achieve to disable psycho visual options? -tune psnr didnt really worked, just file blown up
[14:18:11 CEST] <Fig1024> what are psycho visual options?
[14:34:55 CEST] <thebombzen> Fig1024: human-vision-specific visual optimizations
[14:35:41 CEST] <thebombzen> human eyes don't see everything objectively. We see minor differences in lightness better than differences in color. We see differences in lightness better in very dim areas than very bright areas
[14:36:54 CEST] <Fig1024> and there are options to tune that behavior?
[14:36:58 CEST] <thebombzen> Asuran: x265's psy tunings are messed up
[14:37:02 CEST] <thebombzen> the AQ is bad
[14:37:30 CEST] <Asuran> i try to achieve original result
[14:37:33 CEST] <Asuran> nothing more
[14:37:33 CEST] <thebombzen> Asuran: consider using x264 if you want to disable psy optimizations
[14:37:39 CEST] <Asuran> so i dont want it better then it was
[14:37:45 CEST] <thebombzen> also, you probably don't want to disable psy optmizations
[14:37:46 CEST] <Fig1024> what about VP9
[14:38:03 CEST] <thebombzen> Asuran: unless you know why you want to turn them off, you probably don't want to turn them off.
[14:38:07 CEST] <thebombzen> What are you actually trying to do.
[14:38:07 CEST] <Asuran> well i tried vp9 too but idk cant find documention about psy rd options and such there
[14:38:17 CEST] <Asuran> reencode stuff
[14:38:23 CEST] <thebombzen> Be more specific
[14:38:31 CEST] <Asuran> h264 and other to h265
[14:38:33 CEST] <thebombzen> What do you want to accomplish? Why do you need to re-encode?
[14:38:38 CEST] <Asuran> and achievbe 95% similarity
[14:38:48 CEST] <thebombzen> Why do you need H.265? What is 95% similarity?
[14:38:54 CEST] <thebombzen> Why can't you use the existing H.264 stream?
[14:39:00 CEST] <Asuran> 95% quality of the original
[14:39:18 CEST] <Asuran> h265 does more savings on space
[14:39:23 CEST] <Asuran> so i can set crf higher
[14:39:26 CEST] <Asuran> and get better result
[14:39:35 CEST] <thebombzen> Higher CRF is lower quality.
[14:39:42 CEST] <thebombzen> What are you actually trying to accomplish? Because "I need an H.265 stream that is 95% quality of the original" is not a goal.
[14:39:58 CEST] <thebombzen> You're trying to do something - but why do you need H.265?
[14:40:19 CEST] <Asuran> i mean higher in terms of quality
[14:40:32 CEST] <thebombzen> Higher CRF produces lower quality videos.
[14:41:58 CEST] <Fig1024> I guess he wants to reduce file size while keeping almost same quality
[14:42:35 CEST] <thebombzen> Asuran: because if you're just trying to re-encode the video at a lower bitrate, you don't want to disable psy tuning.
[14:43:22 CEST] <thebombzen> What videos are you trying to recompress? What's the current bitrate? What do you want to get it to?
[14:43:49 CEST] <Fig1024> you should contact Pied Piper, I heard they have excellent compression algorithm
[14:44:52 CEST] <thebombzen> Fig1024: completely unrelated.
[14:53:29 CEST] <Asuran> idc the bitrate tbh i use crf
[14:53:54 CEST] <Asuran> Fig1024, do you got vp9 expierence?
[14:55:33 CEST] <thebombzen> Asuran: what videos are you trying to recompress? What are the dimensions? What is the bitrate?
[14:55:39 CEST] <Fig1024> not practical, but on user level, it seems like you can achieve better compression with higher quality if encoding time isn't an issue
[14:56:21 CEST] <thebombzen> Asuran: I ask because HEVC and VP9 are not worth it for smaller videos
[14:57:13 CEST] <Asuran> thebombzen, is there even an alternative for them?
[14:57:26 CEST] <thebombzen> Yes. Like H.264, for example.
[14:57:50 CEST] <Asuran> well but as i said hecv is more effiecent then h264 so i can set due that alone crf higher
[14:57:51 CEST] <thebombzen> HEVC's advantage over H.264 primarily occurs at larger resolutions. At smaller resolutions it's generally not worth it to use HEVC.
[14:58:17 CEST] <thebombzen> Same with VP9 over VP8. They're worth it for 4k content and the like but for small videos it's not worth it.
[14:58:29 CEST] <thebombzen> Which is why I'm asking you, how big are the videos you're trying to recompress, and what is their bitrate?
[14:58:44 CEST] <Asuran> different
[14:58:58 CEST] <thebombzen> Approximately is good enough
[14:58:59 CEST] <Asuran> my only problem is understand psy-rd and rdoq
[14:59:03 CEST] <thebombzen> Asuran: don't touch that.
[14:59:05 CEST] <Asuran> how they actually work out together
[14:59:16 CEST] <Asuran> but i touched it and it seemed to helped a lot
[14:59:27 CEST] <thebombzen> Don't touch those settings unless you know what they do and why. The defaults are fairly sensible.
[14:59:37 CEST] <colde> Yeah, i dont think that is your only problem, right now your problem is not cooperating with people who are helping you
[14:59:41 CEST] <thebombzen> If you changed them and it "helped" it's because you got lucky.
[14:59:46 CEST] <Asuran> the defaults make it blurry except you maybe use source (raw video)
[15:00:16 CEST] <thebombzen> Asuran: you don't know that those are making it blurry. You could have just set the quality too low, for all I know.
[15:00:35 CEST] <Asuran> crf 19
[15:00:45 CEST] <Asuran> and yea thats why i want to disable them
[15:00:54 CEST] <Asuran> to preserve the original as much as possible
[15:01:12 CEST] <thebombzen> I'm telling you, don't change them unless you know why you want to.
[15:01:13 CEST] <Asuran> or reduce them as much as it is good for picture quality
[15:01:27 CEST] <thebombzen> I'm also telling you, turning off psy tuning does not help picture quality.
[15:01:45 CEST] <Asuran> but it does already, it looks less blurry
[15:01:47 CEST] <Asuran> more sharp
[15:01:51 CEST] <Asuran> more than the original
[15:01:54 CEST] <Fig1024> Youtube uses VP9 even for small videos
[15:02:04 CEST] <thebombzen> Fig1024: that's because it batch processes them.
[15:02:10 CEST] <Asuran> they use vp9? i thought they use h264 only
[15:02:22 CEST] <thebombzen> Fig1024: they dont' have a human decide what's there and what's not. Easier and simpler to have uniform settings for them.
[15:02:50 CEST] <thebombzen> Asuran: and I'm asking you again, what are the dimenions of the videos are you trying to re-encode, and what is their bitrate?
[15:03:00 CEST] <Asuran> different on each video
[15:03:07 CEST] <thebombzen> Approximately
[15:03:13 CEST] <Asuran> from full hd to sd
[15:03:28 CEST] <thebombzen> What is Full HD. Is that 1080p or 720p?
[15:03:37 CEST] <Asuran> 1080p
[15:03:53 CEST] <Asuran> 720p is hd ready if i dont get the brandings on televisions in past wrong
[15:04:06 CEST] <thebombzen> it's just marketing
[15:04:11 CEST] <Asuran> i know
[15:04:21 CEST] <thebombzen> for the 1080p videos what bitrates do they have typically?
[15:04:34 CEST] <thebombzen> Also, to answer your earlier question, try this:
[15:04:35 CEST] <Fig1024> most TV people still use 1080i. I hate dealing with interlaced video
[15:05:00 CEST] <Asuran> Fig1024, is interlaced even useful? isnt it just good for fps 30 and less?
[15:05:34 CEST] <thebombzen> Asuran: try this: ffmpeg -i input.mkv -c:v libx264 -preset:v veryslow -crf:v 18 -c:a libopus -b:a 96k output.mkv
[15:05:37 CEST] <Fig1024> it was made due to old bandwidth limitations. There's no reason to keep using it, but so many people have old hardware
[15:05:46 CEST] <Asuran> i did, didnt helped much
[15:05:53 CEST] <thebombzen> Well then you're SOL
[15:06:06 CEST] <thebombzen> And did you try veryslow? or did you try slow?
[15:06:09 CEST] <thebombzen> Veryslow is much better.
[15:06:13 CEST] <Asuran> it was jsut bit better cuz veryslow changes psy-rd or such a bit too
[15:06:17 CEST] <Asuran> i use slow
[15:06:20 CEST] <thebombzen> Veryslow does not change psy-rd
[15:06:34 CEST] <thebombzen> and notice, I typed libx264. Not libx265
[15:06:34 CEST] <Asuran> it changes something, idk, its maybe rd
[15:06:40 CEST] <thebombzen> did you try libx264?
[15:06:45 CEST] <Asuran> nope
[15:07:02 CEST] <Asuran> is libx265 still that behind?
[15:07:29 CEST] <thebombzen> so when you said "I did try that" you lied
[15:07:34 CEST] <thebombzen> Don't dot hat
[15:07:37 CEST] <thebombzen> Just don't
[15:07:44 CEST] <Asuran> i didnt lied, i assumed its h265
[15:07:50 CEST] <thebombzen> I literally typed libx264
[15:08:32 CEST] <Asuran> i just focused on the value that matters, and they were indentical, like the ones i posted, so i assumed they not much change
[15:08:38 CEST] <Asuran> so no, i didnt lied
[15:08:46 CEST] <thebombzen> So you didn't read, okay
[15:08:47 CEST] <Asuran> i just didnt read it with full care
[15:08:56 CEST] <thebombzen>  try this: ffmpeg -i input.mkv -c:v libx264 -preset:v veryslow -crf:v 18 -c:a libopus -b:a 96k output.mkv
[15:08:56 CEST] <Asuran> cuz i thought its almost same
[15:09:13 CEST] <Asuran> and i assumed this due i posted my batchline before this conversation
[15:09:25 CEST] <Asuran> and the 96k opus part looked identical like the rest
[15:09:40 CEST] <thebombzen> well, keep in mind, I already said that HEVC is not worth it for you.
[15:09:51 CEST] <thebombzen> x265 is not mature enough to bother with HEVC.
[15:09:58 CEST] <Asuran> okay
[15:10:11 CEST] <thebombzen> because the advantage of HEVC over H.264 is primarily at higher resolutions (>1080p)
[15:10:17 CEST] <thebombzen> (like 1440p+)
[15:10:38 CEST] <Asuran> vp9 is bad documented, or i couldnt find the right one on their homepage, i would give it a try but i need to adjust that psycho visual optimizations
[15:10:48 CEST] <thebombzen> NO, you don't
[15:11:01 CEST] <thebombzen> You shouldn't change those settings unless you don't know why you want to change them.
[15:11:12 CEST] <thebombzen> unless you know* why you want to change them
[15:11:23 CEST] <thebombzen> Have you tried the command I suggested yet
[15:12:16 CEST] <Asuran> no, if i use h264 i dont even need to reencode them
[15:12:21 CEST] <Asuran> no use, then i can let them be
[15:13:10 CEST] <Asuran> i will try it myself out i will try and fail learn the psy-rd stuff
[15:13:28 CEST] <Asuran> psy-rd 2.0 and psy-rdoq 15.0 seem to be almost what i want
[15:13:58 CEST] <Asuran> i wish i would understand why they behave like this in this range but well i figure it maybe out
[15:14:05 CEST] <thebombzen> Asuran: Not necessarily, because x264 could re-encode them with a lower bitrate than they were encoded before.
[15:14:14 CEST] <Asuran> but without gurantee im right about it
[15:14:19 CEST] <Asuran> (the interpration i mean)
[15:14:41 CEST] <thebombzen> x264 is a very efficient encoder, so it's worth a try to re-encode H.264 to H.264 if you're encoding it with x264
[15:15:08 CEST] <thebombzen> Often times you can re-encode it at a much smaller size with minimal quality loss if you re-encode it with libx264
[15:15:10 CEST] <Asuran> hmm
[15:15:30 CEST] <Asuran> so the point is libx265 is inmature
[15:15:41 CEST] <Asuran> and even h264 would give better result with lesser file
[15:15:43 CEST] <Asuran> ?
[15:16:04 CEST] <Fig1024> why not just test it for yourself
[15:16:16 CEST] <Asuran> i believe him Fig1024 no need
[15:16:24 CEST] <thebombzen> Yes, there is a need.
[15:16:28 CEST] <thebombzen> You should try the command I suggested.
[15:16:45 CEST] <Asuran> thebombzen, if you didnt lied to me, i already know due what you said
[15:17:02 CEST] <Asuran> so i should stick h264 or give vp9 a try is my conclusion
[15:17:12 CEST] <thebombzen> First of all, I said, "it's worth a try" because"often times" it works
[15:17:27 CEST] <thebombzen> I didn't say it was guaranteed to improve anything in your case
[15:17:39 CEST] <Asuran> ye i understand why
[15:17:43 CEST] <Asuran> it same codec
[15:17:44 CEST] <thebombzen> I said that it's worth trying
[15:18:00 CEST] <Asuran> i cant expect 50% file saving, except if the first encode was high bitrate
[15:18:09 CEST] <Asuran> and they just avoided with it much encoding time
[15:18:29 CEST] <thebombzen> You can't expect 50% with H.264 -> HEVC either unless you're allowing yourself to kill the quality.
[15:18:41 CEST] <thebombzen> Even the people who are marketing HEVC don't claim that it's that good.
[15:37:30 CEST] <CounterPillow> I've heard this is the channel for masochists
[15:38:01 CEST] <flux> thebombzen, hmm, the 50% is an often repeated number, though :)
[15:38:49 CEST] <thebombzen> flux: at UHD and up, yea
[15:38:58 CEST] <thebombzen> not relevant here
[15:39:19 CEST] <thebombzen> nobody is saying it's that much better for dvd-quality movies
[15:39:31 CEST] <flux> thebombzen, cool, that's nice to know
[15:39:40 CEST] <thebombzen> in practice it's not really 50%
[15:39:52 CEST] <thebombzen> but the 50% number that's marketed is for very large frames
[15:40:11 CEST] <thebombzen> x264 is still very competitive at smaller sizes and slower presets
[15:42:28 CEST] <JEEB> the %-wise HEVC claims are theoretical based on various tests with the reference encoder. and yes, most likely there's a difference between the such theoretical capabilities between resolutions. that said, we're dealing with actual implementations
[15:42:35 CEST] <JEEB> like, actual production implementations
[15:42:55 CEST] <JEEB> and fighting against x264 is hard :P
[15:43:05 CEST] <JEEB> since x264 had a lot of love put into it during its life time
[15:43:21 CEST] <JEEB> while x265 for example is a single-company effort with almost zero outside contributions
[15:51:38 CEST] <thebombzen> #x264savesfansubbing
[16:37:33 CEST] <iive> JEEB: I think BBB also had a chart or presentation that supported the 50% claim.
[16:37:58 CEST] <JEEB> the claims themselves are not incorrect, the reality is just different due to actual real encoders
[16:38:41 CEST] <flux> is the 50% theoretical gain comparison to the h264 practical or theoretical encoders?
[16:38:53 CEST] <JEEB> it's the theoretical capability of a similar encoder to a similar encoder ("similar" as in usually "reference encoder") under specific similar parameters
[16:39:03 CEST] <JEEB> flux: the encoder does actually exist but is the reference one usually
[16:39:11 CEST] <JEEB> so JM for AVC and HM for HEVC for example
[16:39:23 CEST] <iive> the presentation I speak about was empirical. it compared a number of encodes, including vp9
[16:40:22 CEST] <JEEB> anyways, whatever the specific graph actually meant, I will not do guesswork. I do know what the ISO/IEC numbers more or less based on
[16:41:09 CEST] <JEEB> just like the case of "libvpx is not /that/ much slower! (if you're only doing single threaded encoding)", things can be true under specific circuimstances
[16:41:45 CEST] <iive> but I do agree that x264 is perfectly polished encoder, and no h265 comes close to it.
[16:43:27 CEST] <dino82> Hey all o/ Trying to get ffmpeg to run in windows server core 2016.  Noticing there are problems with running it at all, reference:  https://emby.media/community/index.php?/topic/46254-windows-server-2016-core-emby/
[16:43:50 CEST] <kerio> does the image2 muxer overwrite the old image atomically, in update mode?
[16:44:13 CEST] <dino82> I get zero output from running ffmpeg.exe
[16:47:03 CEST] <c_14> kerio: if you add -atomic_writing
[16:50:03 CEST] <iive> dino82: if you don't get any imput, then there might be something even before ffmpeg itself starts. check the admin logs and try running ffmpeg in compatibility mode.
[16:50:31 CEST] <kerio> c_14: ty
[16:50:35 CEST] <iive> dino82: i haven't used windows for a very long time... so i'm not sure what tool you can check for missing libraries.
[16:51:32 CEST] <iive> also, antivirus might block execution and etc...
[16:53:04 CEST] <dino82> It's a barebones server install, no AV or windows defender
[16:55:38 CEST] <dino82> In the security logs I see a "A new process has been created..." log every time I run it.  Nothing else appears.  I'd much rather run this in linux :[
[16:56:30 CEST] <c_14> can you tell if the process is crashing?
[16:56:38 CEST] <c_14> does windows have some sort of strace replacement?
[16:56:59 CEST] <iive> sysinternals do a good job of tracing processes
[16:57:30 CEST] <iive> microsoft aquired them long ago and they are now available from ms site
[16:57:43 CEST] <dino82> I am limited to what I can do in Powershell, this is a headless box with no GUI
[16:58:12 CEST] <dino82> I'll check to see if there's a stack tracer built-in
[16:58:17 CEST] <iive> windows can run on such a thing?!
[16:58:40 CEST] <dino82> yeah Windows server core is like the 'alpine linux' of Windows
[16:59:07 CEST] <iive> no, i mean, windows running withoug GUI
[16:59:39 CEST] <dino82> Oh, yeah.  It's all powershell/cmd.exe
[17:00:12 CEST] <dino82> In fact I'm running it inside of a docker container for portability
[17:00:38 CEST] <iive> hum? containers can now run windows?
[17:01:08 CEST] <dino82> yep, Windows-only containers, so you can't run ubuntu on a container unless you involve some virtualbox trickery
[17:17:40 CEST] <Dovid> hi. I am using ffmpeg to watch a stream using m3u8 where it seems sending the files in chunks of a few seconds). I have found on my simple box that when ever it goes to get a new chunk the CPU jumps from 2% to 20-20% for a moment then comes down. I assume this is when it's grabbing the last chunk. What is the reason for the CPU spike and is there any way to get around it?
[17:19:23 CEST] <kepstin> Dovid: ffmpeg isn't really a player, how are you using it to watch a stream?
[17:20:19 CEST] <kepstin> if you're using ffmpeg to transcode, spiky cpu behaviour like that is probably expected, since it'll grab a chunk, encode that as fast as possible, then grab the next chunk.
[17:48:18 CEST] <DHE> kepstin: almost. unless it's changed recently, I find ffmpeg just streams data over HTTP as it goes and forces TCP and the HTTP server to buffer
[17:48:34 CEST] <DHE> rather than downloading a whole file as quickly as possible and running it from RAM
[17:49:07 CEST] <kepstin> DHE: but with segmented media, it has to do separate http requests per segment; does this temporarily block it or slow it down?
[17:49:39 CEST] <DHE> kepstin: the HTTP setup might slow it down, but unless SSL handshaking was involved I wouldn't expect a CPU usage spike
[17:49:53 CEST] <DHE> even then client-side SSL is pretty light on CPU
[17:50:31 CEST] <DHE> HLS treats it mostly like a tcp stream source with HTTP headers involved periodically
[17:50:34 CEST] <kepstin> well, we have no idea what Dovid is actually doing, so speculating it... :/
[17:50:40 CEST] <DHE> true
[17:51:17 CEST] <Dovid> kepstien: The url is https. I am using it on a phone system to play an audio stream
[17:51:54 CEST] <kepstin> https on a phone with a non-reused ssl connection could cause cpu spikes for rsa :/
[17:51:58 CEST] <Dovid> kepstien:I have logging enabled. the spikes happen exactly when it goes o get the next chunk
[17:52:30 CEST] <alphabitcity> Hi, I'm trying to use ffmpeg to change input video size to 720p. If the input is smaller, I want it to scale, and if it's larger, I want it to crop. I'm using `-vf scale=max(iw\,1280):max(ih\,720),crop=1280:720`, which seems to work fine on an image, but I'm getting an "Error initializing filter 'scale'" when the input is an RTSP video: https://gist.github.com/maxstoller/825787bd3757b03766b0f360e565dc97
[17:52:42 CEST] <Dovid> kepstien: well the phone does not do it. in my case ffmpeg gets it and passes it to mplayer. so the https is prob what is causing the spike or is it something else?
[17:52:45 CEST] <alphabitcity> Is it possible it doesn't know the iw/ih for the first frame?
[17:53:42 CEST] <kepstin> Dovid: ouch, you're using ffmpeg to read the hls stream then passing to mplayer over a pipe? That's a bit weird. Why can't you just use a player that can read hls directly and avoid the extra step?
[17:54:26 CEST] <kepstin> Dovid: also make sure your ffmpeg command isn't doing any transcoding. CPU spikes could also happen if there's some buffering going on in the pipe, I guess.
[17:54:39 CEST] <Dovid> kepstin: If I spent the time on it probably. regardless the jump is from ffmpeg so I want to adress the CPU spike.
[17:55:48 CEST] <kepstin> alphabitcity: we need to see the ffmpeg command you're running, but it looks like a syntax error in your command line from this line in the output: [AVFilterGraph @ 0x31eb040] Error initializing filter 'scale' with args 'max(iw:flags=bicubic'
[17:55:58 CEST] <kepstin> alphabitcity: might be a command line string escaping issue.
[17:56:58 CEST] <alphabitcity> kepstin: the introduction of the scale/crop filter broke it. `-vf scale=max(iw\,1280):max(ih\,720),crop=1280:720,my`
[17:57:23 CEST] <adhawkins> Is there any way to use ffprobe to report the maximum bitrate of a file? Currently it's just reporting 'N/A'.
[17:57:27 CEST] <kepstin> alphabitcity: please pastebin the complete ffmpeg command, copy/pasted exactly from the command line where you ran it.
[17:58:36 CEST] <kepstin> adhawkins: "maximum" is tricky to define, over what timescale? I think the maximum field that ffmpeg reports is just some metadata from the file container, if the container stores such info (and the encoder set it)
[17:58:56 CEST] <adhawkins> Over the whole file. Ideally read the entire file and report what the maximum bitrate is that it sees.
[18:00:46 CEST] <DexterF> hi
[18:01:15 CEST] <alphabitcity> kepstin: here's the full cmd https://gist.githubusercontent.com/maxstoller/3c50475df3207937f8231a06fa4fa462/raw/9578ece2417d7a4ab5d04a477e6c903cdef0ec70/gistfile1.txt
[18:01:19 CEST] <DexterF> wanted to rotate a cell vid (shot with a Google Pixel) and get this: https://pastebin.com/3pT5MHPK
[18:01:45 CEST] <kepstin> adhawkins: "maximum bitrate over the whole file" makes no sense, "over the whole file" is just average bitrate
[18:02:01 CEST] <adhawkins> Ok, perhaps 'peak' bitrate is the term I mean?
[18:02:02 CEST] <DexterF> so mainly [aac @ 0xcdfee0] The encoder 'aac' is experimental but experimental codecs are not enabled, add '-strict -2' if you want to use it.  <-- adding the strict option is simply ignored
[18:02:36 CEST] <kepstin> DexterF: upgrade to ffmpeg 3.0 or later
[18:02:50 CEST] <adhawkins> So it reads (say) a second worth of video, works out how much data that was, and calculates a bitrate from that. then does the same with the next second. Whichever one comes out as hte highest value is the peak bitrate.
[18:03:15 CEST] <kepstin> adhawkins: you'd have to calculate it yourself (you can use ffprobe to get the info) by getting the size in bits of each frame, deciding what time period you want to average over (e.g. 1s), and doing the calculation.
[18:03:28 CEST] <adhawkins> Yeah, that's what I feared :)
[18:03:48 CEST] <kepstin> and you'd probably want to do a rolling average, not by segment, although it's probably close enough in most cases i guess.
[18:04:13 CEST] <adhawkins> Just thought that there being a 'max bitrate' field in the results, there was some way of getting this filled in.
[18:06:10 CEST] <DexterF> kepstin, yay, thanks
[18:06:48 CEST] <kepstin> adhawkins: encode the file with vbv max bitrate limits and save in a format that preserves the values used as metadata? :)
[18:07:39 CEST] <adhawkins> This is on files that could come from anywhere, so that's not an option sadly.
[18:11:01 CEST] <kepstin> at least you don't have to decode the files, just demux them, so it should be reasonably quick to calculate
[18:14:22 CEST] <RationalCoding> Hello. I am trying to merge an indefinite stream of webm files (they are being generated from a live stream), and output an RTMP stream. Is this possible with the -concat option? How do I specify which codecs are being used, and which ones I want? Any clues to how this might be done would be very helpful. Thanks.
[18:23:26 CEST] <Fenrirthviti> Pretty sure concat is a static list and can't be used dynamically
[18:33:41 CEST] <RationalCoding> Ah, that's what I was afraid of. Well thanks anyways, it seems I'll have to write my own transcoder for this strange case. Regards.
[18:42:26 CEST] <alphabitcity> I'm using ffmpeg to scale/crop a live RTSP stream. According to top, ffmpeg is taking about 50% of an 8 vCPU machine (a "high" CPU machine on Google Cloud) for 1 stream. Is that expected? Any way to optimize? Thanks!
[18:45:53 CEST] <c_14> probably reencoding to H.264
[18:46:11 CEST] <c_14> you can make it use less if you don't mind dropping quality or upping bitrate
[18:46:32 CEST] <JEEB> right, I've gotten so used to people meaning optimize as "use more CPU"
[18:46:42 CEST] <JEEB> :)
[18:46:56 CEST] <JEEB> (esp. when people mention core counts)
[18:48:03 CEST] <alphabitcity> c_14: i was under the impression that if you're scaling/cropping you have to re-encode. we also have a custom filter that's adding a watermark
[18:48:19 CEST] <alphabitcity> c_14: here's our full cmd: https://gist.githubusercontent.com/maxstoller/3c50475df3207937f8231a06fa4fa462/raw/9578ece2417d7a4ab5d04a477e6c903cdef0ec70/gistfile1.txt
[18:48:47 CEST] <c_14> alphabitcity: you do have to reencode
[18:50:02 CEST] <c_14> but you can use a faster preset if you want to use less cpu (-preset fast/veryfast/ultrafast)
[18:50:20 CEST] <alphabitcity> c_14: ok, i will give that a shot. thank you
[18:58:53 CEST] <Dovid> kepstin: I just checked and it's http NOT https. The URL is: http://radio.sa-media.com:1935/shoutcast/_definst_/radiostation.stream/chunklist_w68566006.m3u8
[19:02:48 CEST] <Asuran> thebombzen, what you think about netflix claims about hevc tuning (x265)?
[19:18:34 CEST] <DHE> Dovid: oh, it's a live audio channel. so what you're seeing it ffmpeg processing the ~10 second burst of data in an instant, and then waiting 10 seconds for the next burst.
[19:19:38 CEST] <Dovid> DHE: Correct. That is what I meant by "chunks"
[19:20:43 CEST] <kepstin> Dovid: expected behaviour, yep. To fix it, use a player that can open hls directly, rather than ffmpeg in the middle with a pipe.
[19:21:07 CEST] <DHE> which is odd because I'd expect a phone to play it okay.
[19:21:09 CEST] <kepstin> You could try playing around with the -re input option to slow ffmpeg down, but it'll probably cause a desync from the live stream over time.
[19:21:35 CEST] <Dovid> kepstin: Why does the CPU spike there? Is it just the process of the get to the server?
[19:21:59 CEST] <Dovid> kepstin: Pardon my ignorance. what is HLS?
[19:22:03 CEST] <kepstin> Dovid: nah, it's just a result of ffmpeg being a batch tool and the size of the pipe buffer between it and the player.
[19:22:28 CEST] <kepstin> HLS is the name of the segmented media streaming format you're trying to play (with the m3u8 playlist)
[19:22:52 CEST] <Dovid> btw when I say phone I mean a SIP phone.
[19:23:27 CEST] <Dovid> kepstin: I dont know streaming well. This is what I am feeding to the PBX:
[19:23:34 CEST] <Dovid> .       /usr/bin/ffmpeg -report -i http://radio.sa-media.com:1935/shoutcast/radiostation.stream/playlist.m3u8 -vn -c:a libmp3lame -b:a 320k -joint_stereo 0 -y -f mp3  pipe:1 |/usr/local/bin/madplay -Q -o raw:- -1 -R 8000 -a -10 -
[19:23:52 CEST] <Dovid> madplay can not play aac
[19:24:13 CEST] <Dovid> unless I can get ffmpeg to output raw but i would still then have the CPU issue
[19:24:18 CEST] <kepstin> Dovid: ffmpeg sits around waiting for the next segment to be available, then once it is it'll download and transcode it quickly, storing the result in the pipe buffer, which the next application will read at its leisure
[19:24:59 CEST] <Dovid> kepstin: So I would need to have ffmpeg slow down the download and transcode since it tries to do the entire segman at once
[19:25:19 CEST] <kepstin> Dovid: why bother? it should be working fine as it is...
[19:25:41 CEST] <Dovid> kepstin: Its working except for the spike every 10 seconds
[19:25:57 CEST] <kepstin> Dovid: I have no idea why you're using madplay in there tho, ffmpeg should be able to output the raw format you need for the pbx directly.
[19:26:17 CEST] <Dovid> kepstin: So I can send you a few shekels to help me out?
[19:26:22 CEST] <kepstin> Dovid: sure, but why is a cpu spike every 10s a problem?
[19:27:19 CEST] <Dovid> kepstin: Because I am pulling multiple streams. It's a system where people can call in and listen to church sermons so if we have say 5 churches on there 9/10 seconds the CPU is idle but for 1/10 the CPU load from 5 streams kills the box
[19:28:06 CEST] <kepstin> Dovid: well, first thing first is that you should drop the extra transcode to mp3 you're doing and have the audio only be decoded by ffmpeg
[19:28:11 CEST] <kepstin> should save a chunk of cpu
[19:28:42 CEST] <Dovid> so the PBX needs 8khz mono as you can see in the output from madplay. how would I modify the ffmpeg part to do that?
[19:28:44 CEST] <kepstin> and second, fix your thread priorities so the pbx software is high or even soft realtime, then it shouldn't matter that the ffmpegs are bursting cpu.
[19:29:14 CEST] <kepstin> 16bit signed 8khz mono?
[19:29:14 CEST] <Dovid> can you explain " fix your thread priorities". r u talking about nice?
[19:29:28 CEST] <kepstin> Dovid: check with the pbx software provider about that
[19:29:46 CEST] Action: kepstin knows that when started as root, freeswitch does thread priorities correct by default
[19:30:08 CEST] <Dovid> kepstin: I am using asterisk :(
[19:30:31 CEST] <Dovid> so I need to modify:  /usr/bin/ffmpeg -report -i http://radio.sa-media.com:1935/shoutcast/radiostation.stream/playlist.m3u8 -vn -c:a libmp3lame -b:a 320k -joint_stereo 0 -y -f mp3  pipe:1
[19:30:46 CEST] <Dovid> so that it will send it out as raw 9khz mono. correct?
[19:31:29 CEST] <relaxed> maybe something like, .... -vn -c:a pcm_s8 -ac 1 -
[19:31:39 CEST] <kepstin> Dovid: anyways, "ffmpeg -i <streamurl> -vn -ar 8K -ac 1 -f s16le -" should do that.
[19:31:49 CEST] <Dovid> let me try. one mometn
[19:32:05 CEST] <kepstin> but check whether 16 bit is correct, if you need 8bit it'll be different
[19:32:21 CEST] <relaxed> -f s8
[19:33:06 CEST] <kepstin> that'll drop the cpu load a fair bit simply by avoiding the extra encode step, which might be enough.
[19:33:09 CEST] <Dovid> so for 16 bit "ffmpeg -i <streamurl> -vn -ar 8K -ac 1 -f s16le -" and for 8 but "ffmpeg -i <streamurl> -vn -ar 8K -ac 1 -f s8 -"
[19:34:11 CEST] <relaxed> it would help if you knew what the pbx called for
[19:34:29 CEST] <kepstin> if that existing madplay command works, s16le is probably correct
[19:34:55 CEST] <kepstin> note that the madplay command is also reducing gain by 10dB, if you want to do the same in ffmpeg, add "-af volume=-10dB"
[19:35:51 CEST] <Dovid> kepstin: Wow. not using madplay helps a lot!. Thank you. Your fav charity is?
[19:36:16 CEST] <kepstin> well, what helped a lot was not encoding mp3 audio :/
[19:36:25 CEST] <kepstin> encoders are cpu intensive :)
[19:37:27 CEST] <Asuran> thebombzen, i tried now libx264
[19:38:10 CEST] <Asuran> thebombzen, just 10% bigger size hmm
[19:38:40 CEST] <Dovid> kepstin: Your favorite charity is?
[19:39:45 CEST] <relaxed> Dovid: maybe ffmpeg?  http://ffmpeg.org/donations.html
[19:40:53 CEST] <kepstin> Dovid: also EFF and archive.org are up there for me :)
[19:41:23 CEST] <Dovid> bah. seems like the wife has my cc. one sec
[19:46:43 CEST] <Dovid> kepstin: and they dont take amex. Just made a donation to both ffmpeg and FFmpeg - OPW (Outreach Program for Women)
[19:47:54 CEST] <DexterF> how come that after not doing more than: -vf "transpose=2"  the output video is half in size? (The original was shot with a mobile phone in wrong orientation)
[19:48:22 CEST] <furq> DexterF: because it'll use the default x264 settings
[19:48:32 CEST] <kepstin> DexterF: in order to apply the transpose filter, the video is being re-encoded, and the newer settings are probably smaller than what the phone uses
[19:48:37 CEST] <furq> or the default settings for whatever encoder is default for the container you used
[19:48:41 CEST] <furq> which is probably mp4 and x264
[19:49:02 CEST] <kepstin> assuming it's using x264, that's a way better encoder than the phone's hardware encoder, so the quality loss is probably minimal, too.
[19:49:06 CEST] <furq> also you might be able to fix that losslessly
[19:49:34 CEST] <kepstin> hmm, by adding metadata, yeah. Not all players will respect it, but it might be good enough?
[19:49:38 CEST] <furq> mp4 has widely-supported rotation metadata for this exact scenario
[19:49:45 CEST] Action: DexterF checks source 
[19:49:51 CEST] <furq> it might be as simple as just removing that from your source file
[19:50:07 CEST] <DexterF> well, mpv and smplayer played it in proper orientation, but youtube borked
[19:50:07 CEST] <furq> but if it was actually encoded the wrong way up, you can try adding it
[19:50:21 CEST] <furq> oh right
[19:50:26 CEST] <furq> yeah that sounds bad then
[19:50:48 CEST] <furq> check with ffprobe anyway
[19:51:42 CEST] <DexterF> Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc, smpte170m), 1920x1080, 32998 kb/s, SAR 1:1 DAR 16:9, 60.02 fps, 60 tbr, 90k tbn, 180k tbc (default)
[19:52:31 CEST] <DexterF> shot at whatever a Google Pixel considers default, I didn't touch any settings
[19:53:25 CEST] <DexterF> audio is Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, mono, fltp, 96 kb/s (default)
[19:54:28 CEST] <DexterF> re-encoded I have Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuvj420p(pc), 1920x1080 [SAR 1:1 DAR 16:9], 16204 kb/s, 60 fps, 60 tbr, 15360 tbn, 120 tbc (default)
[19:54:53 CEST] <furq> it should namedrop the rotation flag in there
[19:54:57 CEST] <furq> if not then try adding -show_format
[19:55:48 CEST] <DexterF> "displaymatrix: rotation of -90.00 degrees" . so the video stream lost half its bandwidth. what is tbr, tbn, tbc, btw?
[19:58:09 CEST] <DexterF> https://pastebin.com/CTkYhmFs  <- with show_format
[19:58:25 CEST] <DHE> timebase info for the stream in various ways
[19:58:30 CEST] <DHE> tbc is the codec's timebase for example
[20:25:31 CEST] <Asuran> kepstin, you use h264 because x265 isnt good enough today?
[20:25:55 CEST] <Asuran> it seems due that people wait for av1 or im wrong?
[20:26:07 CEST] <Asuran> thebombzen, ffmpeg -i %1 -c:v libx264 -preset:v placebo -crf 19 -tune film -c:a libopus -b:a 96k -vbr on -packet_loss 0 -compression_level 10 -application audio "%~n1".mkv is now i use
[20:31:09 CEST] <kepstin> I use x264 because it's a really good encoder and I'm mostly dealing with sub-4k content where hevc encoders aren't really worth the speed loss.
[20:31:50 CEST] <kepstin> although if you're willing to use the 'placebo' option in x264 (which isn't guaranteed to actually be more efficient than 'veryslow'...), x265 might be ok for you?
[20:33:11 CEST] <Asuran> kepstin, what you mean ok for me? i would love to use it, but i cant get it done
[20:33:23 CEST] <Asuran> kepstin, its not bad yea, im almost impressed
[20:37:13 CEST] <Asuran> kepstin, forget it, i now understood
[20:37:19 CEST] <Asuran> kepstin, no, in x265 its very slow
[20:37:23 CEST] <Asuran> i get less then 1 fps
[20:37:28 CEST] <Asuran> around 0.7 fps
[20:37:30 CEST] <Asuran> or lesser
[20:39:26 CEST] <Asuran> i cant go beyond slow even with that i risk at full hd slow frames
[20:40:02 CEST] <Asuran> but since i cant get it working it doesnt matter, no one shares the settings tbh so idk what to set and try and fail doesnt work well
[20:40:07 CEST] <Asuran> atleast with me
[21:12:30 CEST] <lindylex> Does ffmpeg know the values of the video dimension and duration?  This is what i am trying to code.  https://pastebin.com/dLQBPAEe  I want to get the values dynamically. I am trying to avoid the python programmatic way.  If needed I will.
[21:14:08 CEST] <Dovid> when using -report for ffmpeg can I change the file name?
[21:20:09 CEST] <kepstin> lindylex: some filters have variables available for certain things like video dimensions etc. (for example, scale crop and overlay do). But ffmpeg filters don't have any way to know the video duration - because other filters can change the duration in unpredictable ways, or the video source might not have the info, or other reasons.
[21:20:53 CEST] <kepstin> lindylex: you'd probably be best off programatically generating the filters string for this case.
[21:22:56 CEST] <lindylex> kepstin: That is what I remember from yesterday kepstin.  Yesterday the W and H were the values of the main video I used for the base height and width.   I thought that their were built in way that ffmpeg always stored this information.
[21:26:42 CEST] <furq> they're only exposed to certain filters
[21:27:12 CEST] <furq> and also only to filters that take an input, which doesn't include sources
[21:31:19 CEST] <lindylex> Thanks so much for the explanation.
[21:55:39 CEST] <ioan> I'm trying to stream from an IP camera to youtube without sound and I always get the error "Cannot select sample rate for the link between filters Parsed_anullsrc_0 and out.anullsrc: Invalid argument" from ffmpeg. With sound works fine, but I can't figure out how to do it without sound
[21:56:04 CEST] <ioan> here is the everything: https://pastebin.com/A2zj3n2V
[21:58:15 CEST] <ChocolateArmpits> ioan, did you try setting sample rate for the anullsrc ?
[21:59:44 CEST] <BtbN> Pretty sure youtube wants you to send aac audio
[22:00:02 CEST] <BtbN> and 712kbps for audio is super exzessive
[22:00:12 CEST] <nicolas17> ...lol
[22:00:26 CEST] <ChocolateArmpits> youtube can deal with with mp3, or at least did a year ago
[22:00:45 CEST] <BtbN> I also don't think using qscale is a good idea, if x264 even cares about it
[22:01:04 CEST] <nicolas17> isn't ~1Mbps enough for uncompressed PCM?
[22:01:20 CEST] <nicolas17> to put that 712kbps compression bitrate in perspective...
[22:01:44 CEST] <ioan> :-) so what should I change? how should my parameter list look like?
[22:09:11 CEST] <ioan> I guess this works the best: https://pastebin.com/1NcdtD5A but with sound. I tried -an to remove the sound from source, but youtube (I think) needs sound. So I tried "-f lavfi -i anullsrc=channel_layout=stereo:sample_rate=44100" and "-map 0:a -map 1:v" but then I get that error: "Cannot select sample rate for the link between filters Parsed_anullsrc_0 and out.anullsrc: Invalid argument"
[22:11:14 CEST] <ChocolateArmpits> ioan, did you try adding -re before the null audio input ?
[22:14:09 CEST] <kepstin> ChocolateArmpits: there's no null audio input there, so that wouldn't do anything useful. The timing will be synced by the muxing code so no problem with that.
[22:14:55 CEST] <kepstin> er, wait, no, i misread that
[22:15:05 CEST] <ioan> ChocolateArmpits, like this: https://pastebin.com/v52mFgun
[22:15:07 CEST] <ioan> ?
[22:15:56 CEST] <kepstin> ioan: don't use -re on an input that's already realtime like an rtsp camera, that'll cause problems
[22:16:26 CEST] <kepstin> and i'd recommend not using -re on the other input here either, it might cause the camera to drop frames, and the audio will be synced fine by the muxer anyways
[22:16:54 CEST] <Vaska> Hello - I've noticed that quite a few options (with ffplay specifically) aren't available using the windows build binary.  -fps and -video_size for example result in "Option video_size not found."
[22:17:36 CEST] <kepstin> Vaska: you need to provide more context about the command you're trying to run and where the options are being placed. Those options are mostly applied to specific input or output drivers.
[22:19:02 CEST] <Vaska> kepstin: ah, sorry, I'm playing a video stream and was hoping I could resize the video playback "ffplay.exe -video_size 320x240 http://192.168.1.22/videofeed"
[22:19:47 CEST] <kepstin> Vaska: yeah, the -video_size option only applies to some types of inputs like webcams where you can request a specific size of frame for the camera to return, it doesn't apply to things like http streams.
[22:20:30 CEST] <kepstin> Vaska: you can use "-vf scale=320:240" in this case to downscale the video before displaying it
[22:20:41 CEST] <kepstin> or you could just resize the window, I suppose...
[22:21:12 CEST] <ioan> kepstin, dropped the -re. Any idea on the error I'm getting? "[Parsed_anullsrc_0 @ 0225a7a0] Cannot select sample rate for the link between filters Parsed_anullsrc_0 and out.anullsrc=channel_layout=stereo:sample_rate=44100: Invalid argument" if I drop the arguments for anullsrc I get: "Cannot select sample rate for the link between filters Parsed_anullsrc_0 and out.anullsrc: Invalid argument"
[22:22:18 CEST] <Vaska> kepstin: ok got it, the -vf scale=320:240 option works perfect, I'm kicking myself for not trying that since I'm familiar with it from mplayer's syntax, thanks for the help
[22:23:08 CEST] <kepstin> ioan: i dunno, that's really strange. Have you tried putting the anullsrc in a -filter_complex string rather than using it as an input?
[22:23:59 CEST] <ioan> I did not, I have to read about that because I don't know what it means :-)
[22:24:34 CEST] <kepstin> that said,  using "-f lavfi -i anullsrc=channel_layout=stereo:sample_rate=44100" works perfectly fine as an input for me
[22:25:04 CEST] <kepstin> can you please pastebin the full and complete output from running the command?
[22:25:53 CEST] <kepstin> (well, remove your stream key if it's in the output of course)
[22:27:25 CEST] Action: kepstin notes that anullsrc defaults to stereo 44.1kHz, so the options should be doing nothing
[22:28:16 CEST] <kepstin> the command you pasted is obviously not what you're actually running, because it's full of newlines - double check that the command you're really running doesn't have any syntax or escaping issues
[22:28:17 CEST] <ioan> https://pastebin.com/qgmEbFFp
[22:29:11 CEST] <kepstin> and, uh, before doing anything else, get yourself an ffmpeg from within the past couple years maybe?
[22:29:58 CEST] <kepstin> this could very well just be a bug that was fixed in modern ffmpeg.
[22:30:06 CEST] <ioan> fair point. when I searched for ffmpeg windows binary, I got to this one. Let me do that first, just realized the date too
[22:30:28 CEST] <kepstin> for windows, grab one from https://ffmpeg.zeranoe.com/builds/
[22:32:50 CEST] <Asuran> kepstin, is ffmpeg suitable for image conversion?
[22:32:57 CEST] <Asuran> like jpg
[22:33:21 CEST] <kepstin> Asuran: it can do it, but I'd recommend other tools which are more image-oriented
[22:33:26 CEST] <ioan> that's what I'm using and it shows -version as "ffmpeg version N-50911-g9efcfbe built on Mar 13 2013 21:26:48 with gcc 4.7.2 (GCC)"
[22:33:27 CEST] <Vaska> Asuran: ImageMagick is probably better suited for image manipulation
[22:33:28 CEST] <Asuran> ok thx
[22:34:47 CEST] <kepstin> ioan: you're not running the correct ffmpeg binary then - do you have another old one in your path, maybe?
[22:35:14 CEST] <ioan> probably, I'll have to dig a little
[22:35:27 CEST] <kepstin> the git commit 9efcfbed9dd64679145f5f39d9a812dfeea97172 that the one you're running is built from is in fact from 2013.
[22:35:41 CEST] <kepstin> it's definitely not the zeranoe build you just downloaded
[22:36:23 CEST] <Vaska> ioan: if you have ImageMagick installed it also comes with a copy of ffmpeg.exe that optionally gets added to your path statement
[22:36:47 CEST] <ioan> YES, just found it. It is the one from ImageMagick
[22:37:16 CEST] <Vaska> ioan: while you're updating you could update your ImageMagick binary too ;)
[22:38:37 CEST] <ioan> Vaska, that would take more work, some of the software I developed for the company depends of imagemagick and I can't just change the version without checking first. But I'm sure my software doesn't use ffmpeg, so I can just rename that file
[22:42:47 CEST] <ioan> YAY! success, it was the version I was using... I can't believe I didn't' see the date from the beginning. Thanks ChocolateArmpits, kepstin, Vaska!
[22:46:05 CEST] <ioan> Anyone konws if a Raspberry Pi is powerful enough to run ffmpeg 24/4 without setting the house on fire?
[22:46:14 CEST] <ioan> 24/7
[22:47:10 CEST] <alphabitcity> Is there any way to get the capture time of a frame from an AVFrame object?
[22:50:44 CEST] <kepstin> ioan: I think that a raspberry pi is not powerful enough, and has sufficient thermal throttling applied, that it should not normally be a cause of fires. Do make sure you're using a decently quality power supply tho, those are sometimes nasty.
[22:51:48 CEST] <kepstin> alphabitcity: depends what the frame came from. I think (most of?) the webcam and screen capture input devices just use the time of frame capture as the pts...
[22:52:36 CEST] <ioan> I'll have to try with a Pi and see what happens... if not, maybe EC2 T2.nano would do the trick
[22:52:37 CEST] <alphabitcity> kepstin: hm, i was under the impression that the pts would be some relative number and not an absolute timestamp
[22:53:51 CEST] <kepstin> alphabitcity: it typically is, but some of the frame grabbers put real time in there because it's simpler.
[22:54:25 CEST] <alphabitcity> kepstin: i'll check .. that would be great. in that case, pts would be the capture time?
[22:54:55 CEST] <kepstin> alphabitcity: yeah, it'll be in the same format as av_gettime() returns in that case.
[22:55:12 CEST] <kepstin> I dunno how much i'd rely on this tho - it's an implementation detail of a few input drivers.
[22:55:47 CEST] <alphabitcity> is there a better way? our workflow is webrtc > rtp > ffmpeg
[22:56:09 CEST] <kepstin> oh, yeah, that won't work on rtp.
[22:57:14 CEST] <kepstin> what would "capture time" even mean on a frame received over rtp anyways?
[22:58:03 CEST] <alphabitcity> kepstin: yea, sorry, that terminology is a lil bit confusing. we're using a custom filter to stamp a timestamp on each frame of a video with ffmpeg. ideally we want that timestamp to be the time the frame was captured in the user's browser (again, webrtc ingest) or as close to it
[22:58:32 CEST] <alphabitcity> kepstin: right now we're just stamping the wall clock, but it's about ~300ms behind the actual capture time (not precisely measured but somewhere in that range)
[22:59:35 CEST] <alphabitcity> kepstin: the dream is each AVFrame having some sort of source timestamp attached to it that we could use
[22:59:37 CEST] <kepstin> alphabitcity: yeah, there's no way to really know the real time that a frame on the remote side was captured from the receiving side. You could *maybe* estimate it from the delay that rtcp computes, but I don't think that's exposed anywhere in ffmpeg's api
[23:00:00 CEST] <alphabitcity> kepstin: makes sense, thank you.
[23:01:23 CEST] <kepstin> if possible, you could try sending (out of band) info from the client about what its local clock was when it captured the first frame, maybe.
[23:01:35 CEST] <oerg866> Hi, I have a question about the 3GP file format
[23:01:50 CEST] <kepstin> but if the client's on wifi, then the delay will be changing constantly anyways... :)
[23:02:04 CEST] <alphabitcity> kepstin: right. hoping to keep it in band, but not sure it's possible
[23:02:18 CEST] <oerg866> as far as I understand it there's some way of telling the player which orientation to play the content in, like phones use... if I for example film upside down on my phone, the Windows 10 movie player plays it correctly, while it is upside down in MPC-HC
[23:02:34 CEST] <oerg866> can i change that information with ffmpeg and if yes, how?
[23:03:05 CEST] <alphabitcity> kepstin: our current solution is only ~300ms off, which is not terrible .. perhaps we can squeeze more precision out of it. we're using -vf myfilter .. where myfilter takes the wallclock and stamps the timestamp on. are there any flags that you could suggest we try that might cause frames to hit the filter earlier?
[23:04:36 CEST] <ioan> thanks for helping. See you all later!
[23:06:18 CEST] <kepstin> oerg866: yeah, you should be able to set it with the -metadata option. e.g. "ffmpeg -i orig.3gp -c copy -metadata s:v:0 rotate=90 output.3gp"
[23:06:31 CEST] <kepstin> oerg866: replace 90 with 0, 90, 180, 270
[23:06:53 CEST] <kepstin> er, "-metadata:s:v:0 rotate=90" i made a typo
[23:08:10 CEST] <oerg866> ahhh cheers
[23:08:13 CEST] <oerg866> :)
[23:10:20 CEST] <kepstin> oerg866: note that this should work on mp4 as well, I'm not sure about other formats.
[23:32:43 CEST] <realnc> hello! got a quick question: how do I rip the raw vorbis audio from an ogg vorbis file?
[23:33:04 CEST] <realnc> this doesn't work: ffmpeg -i file.ogg -acodec copy file.vorbis
[23:37:02 CEST] <drv> I don't think there is any such thing as a raw Vorbis format - it is always encapsulated in some kind of container
[23:41:34 CEST] <realnc> there is no raw vorbis "format". there is raw vorbis. mime type is "audio/vorbis". I'm trying to somehow produce a file with raw vorbis in it.
[00:00:00 CEST] --- Fri Jul 14 2017