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

[burek]

[04:49:54 CEST] <geri> hi, how can i merge two videos sound and video?
[04:49:55 CEST] <geri> someone here?
[04:50:42 CEST] <geri> i currently do:
[04:50:46 CEST] <geri> ffmpeg -i intro.mov -i final.mp4 -filter_complex "[0:v:0]pad=iw*2:ih[bg]; [bg][1:v:0]overlay=w" -c:v libx264 -tune film -crf 16 -b:a 256k output.mp4
[04:50:57 CEST] <geri> but only 1 audio layer gets selected
[04:50:58 CEST] <geri> :(
[05:08:58 CEST] <kepstin> geri: by default ffmpeg picks one video and one audio track to use in output. If you want something else, you have to use the -map option to pick which tracks you want.
[05:09:39 CEST] <geri> re
[05:09:39 CEST] <kepstin> geri: alternately, if you want to combine both audio tracks into a single audio track, you'll have to use a filter for that (e.g. amix), which could be added to your filter chain
[05:09:56 CEST] <geri> do you see that command: ffmpeg -i intro.mov -i final.mp4 -filter_complex "[0:v:0]pad=iw*2:ih[bg]; [bg][1:v:0]overlay=w" -c:v libx264 -tune film -crf 16 -b:a 256k output.mp4
[05:10:14 CEST] <geri> can you show me how to use that filter amix?
[05:10:54 CEST] <kepstin> in this case you'd add it to the filter_complex option, something like "[0:v:0]pad=iw*2:ih[bg]; [bg][1:v:0]overlay=w; [0:a:0][1:a:0]amix" should do
[05:11:13 CEST] <geri> let me try
[05:11:41 CEST] <geri> it runs now, lets see what it produces
[05:11:53 CEST] <geri> how can i move the overlayed video a bit to the right?
[05:12:18 CEST] <geri> sorry left
[05:13:35 CEST] <kepstin> take a look at the options to the overlay filter in the docs, it has offsets that can be adjusted.
[05:13:53 CEST] <geri> how did the overlay it place now?
[05:13:58 CEST] <geri> its not centered
[05:15:17 CEST] <kepstin> right now, you have "overlay=w" and the first option to overlay is the x offset. So it's moving the top video to the right by 'w', which is a variable containing the width of the top video.
[05:15:24 CEST] <geri> see: blob:https://imgur.com/b84f927c-4ae5-44f6-88bb-a6b749b6c551
[05:15:26 CEST] <geri> ;D
[05:16:22 CEST] <kepstin> this filter chain you have would put the two videos side-by-side if they both had the same width and height
[05:16:43 CEST] <geri> oh
[05:16:47 CEST] <kepstin> (if that's what you want, it's better to use the "hstack" filter instead, which is less complex to use and faster to run)
[05:16:50 CEST] <geri> so what i achieved is wrong? :D
[05:17:00 CEST] <kepstin> i dunno what you want to achieve
[05:17:03 CEST] <geri> i want the video on top
[05:17:07 CEST] <geri> of the other
[05:17:25 CEST] <kepstin> i can't see your image link
[05:17:44 CEST] <kepstin> what are the sizes of your background video and top video?
[05:18:39 CEST] <kepstin> if the top video is smaller, you'd want to use a filter setup like "[0:v][1:v]overlay=10:20" where 10 is the horizontal offset in pixels, and 20 is the vertical offset in pixels.
[05:18:39 CEST] <geri> here: https://i.imgur.com/ai7SK9l.jpg
[05:18:45 CEST] <geri> now u can see it
[05:18:58 CEST] <geri> ?
[05:28:55 CEST] <geri> is the current format good to watch on a phone?
[05:28:58 CEST] <geri> video codec etc
[05:29:02 CEST] <geri> .mp4 ...
[05:29:18 CEST] <geri> kepstin: i will play more with the options you gave me and read more...
[05:30:32 CEST] <kepstin> i'm not sure what you're trying to do, but I suspect you can get it done by using either the hstack and crop filter or overlay and pad, just a matter of getting the parameters and video order correct.
[05:30:43 CEST] <geri> ok
[05:30:52 CEST] <geri> is the current format good to be watched on a phone?
[05:30:54 CEST] <geri> its a mp4
[05:30:59 CEST] <kepstin> the encoding settings should be fine for a phone, although you might want to use -c:a aac
[05:31:28 CEST] <kepstin> the -tune film isn't really necessary
[05:31:41 CEST] <geri> ffmpeg -i intro.mov -i final.mp4 -filter_complex "[0:v][1:v]overlay=0:100; [0:a:0][1:a:0]amix" -c:v libx264 -crf 16 -b:a 256k -c:a aac output6.mp4
[05:31:43 CEST] <geri> like that?
[05:31:59 CEST] <kepstin> if you want to tweak the quality/size, change the value of the -crf option. larger numbers are smaller file & lower quality.
[05:32:20 CEST] <geri> 16 is low compared to 100 ?
[05:32:29 CEST] <geri> low quality
[06:00:32 CEST] <illuminated> geri: you have that backwards 0 would be best quality and 100 would be worst quality.. but I think CRF only goes to like 56 or something
[06:00:39 CEST] <illuminated> on x264 it defaults to 23
[06:08:54 CEST] <geri> h oh yeah
[11:42:53 CEST] <belst> Hi, I am currently trying to create a livestream of an audio spectrum. I have it working as an mp2t stream but I want to play it in browsers.
[11:42:59 CEST] <belst> my current command is: https://ptpb.pw/DANC/bash
[11:43:32 CEST] <belst> I can use libvpx but encoding is WAAAY to slow with it.
[13:35:24 CEST] <Adcock> Hi
[13:35:34 CEST] <Adcock> I am new to ffmpeg.
[13:36:19 CEST] <Adcock> I want to convert a .mkv file to ogg/theora format.
[13:36:46 CEST] <Adcock> Without any loss of video or audio quality.
[13:36:52 CEST] <Adcock> Please help.
[13:37:41 CEST] <BtbN> That's impossible.
[13:37:57 CEST] <Adcock> But why?
[13:38:41 CEST] <BtbN> Every encode loses quality, unless you actually encode losslessly
[13:39:15 CEST] <Adcock> I used this "FFMPEG -i asdhb.mkv  -c:v libtheora -c:a libvorbis out.ogv"
[13:39:58 CEST] <Adcock> But the video quality is unacceptable.
[13:40:49 CEST] <JEEB> welcome to defaults
[13:40:59 CEST] <Adcock> :D
[13:40:59 CEST] <JEEB> what you have learned: don't use defaults for rate control
[13:41:11 CEST] <Adcock> Hmmm......
[13:41:17 CEST] <JEEB> I think the global AVCodecContext default for video is bitrate && 200kbps
[13:41:29 CEST] <JEEB> so yes, that will probably look like poop in addition to theora being really bad at compression
[13:41:32 CEST] <Adcock> :(
[13:41:43 CEST] <JEEB> various specific encoders do override that value though
[13:41:45 CEST] <JEEB> such as x264
[13:41:57 CEST] <durandal_1707> belst: the showspectrum filter recently got legend option
[13:42:30 CEST] <durandal_1707> to show frequency and time and other info
[13:43:37 CEST] <belst> durandal_1707: nice. I'll try that. Still working on getting the resulting stream to show in an html <video> tag though :(
[13:43:41 CEST] <Adcock> How can I tell ffmpeg to convert in a specific way?
[13:44:44 CEST] <Adcock> Like audio biterate, sample rate?
[13:45:08 CEST] <durandal_1707> belst: note: the filter output is yuv444p but web browsers mostly supports only yuv420p, so add format filter at end
[13:49:13 CEST] <belst> durandal_1707: what ffmpeg version/compile flags do I need for legend?
[13:50:03 CEST] <belst> I get [Parsed_showspectrum_2 @ 0x55bcd1245000] Option 'legend' not found
[13:50:06 CEST] <durandal_1707> belst: latest master from git, compile flags can be what you already use
[13:50:26 CEST] <belst> ah ok. so no released version yet.
[13:50:32 CEST] <durandal_1707> yes
[13:58:33 CEST] <Adcock> Can ffmpeg show ETA?
[13:58:40 CEST] <Adcock> Or progressbar?
[14:00:06 CEST] <belst> adding format=yuv420p slows down encoding to about a 4th of the previous speed. can I somehow speed this up?
[14:03:20 CEST] <durandal_1707> ugh, is it that slow?
[14:04:42 CEST] <belst> without it speed is about 5x
[14:04:45 CEST] <belst> with it its about 1.3x
[14:05:31 CEST] <belst> but i'm currently testing with urandom which is not good anyway. need to test with real data.
[14:09:30 CEST] <furq> belst: you probably want to use hls/dash/some custom mse thing for streaming h264 to browsers
[14:09:47 CEST] <furq> i don't know of a way to do it with just a video tag, but hls with hls.js is fairly painless
[14:10:48 CEST] <furq> also you don't need any of the labels in that filterchain between aspectrum and l3
[14:10:49 CEST] <durandal_1707> belst: scale filter does not use threads, and for simple format conversion threads should be used
[14:52:36 CEST] <belst> hmm. is there a way to modify the legend? I don't need the time on the left for example.
[14:59:21 CEST] <durandal_1707> belst: you could modify source code..
[15:07:27 CEST] <belst> I think my selfmade "legend" is good enough for now :D thanks anywayt
[15:18:35 CEST] <w1kl4s> Adcock you can use this: https://github.com/althonos/ffpb
[15:18:41 CEST] <w1kl4s> Or pv pipe
[15:19:19 CEST] <w1kl4s> for pv, if your normal usage looks like that: ffmpeg -i input.avi {arguments}
[15:19:32 CEST] <Adcock> w1kl4s: Thanks.
[15:19:33 CEST] <w1kl4s> then just pipe pv:    pv input.avi | ffmpeg -i pipe:0 -v warning {arguments}
[15:19:36 CEST] <Adcock> :)
[15:21:22 CEST] <furq> that ffmpeg progressbar won't work if you do anything that modifies the duration of the output file
[15:21:29 CEST] <furq> which is mostly why ffmpeg doesn't already have one
[15:22:13 CEST] <furq> i guess pv should work but only for streamable input formats
[15:22:17 CEST] <furq> it's probably not going to play nice with mp4
[15:22:56 CEST] <Adcock> :(
[15:24:57 CEST] <Hello71> on Linux you can do ffmpeg & pv -d $!
[15:26:12 CEST] <Adcock> ffmpeg could lock currently used file.
[15:26:59 CEST] <furq> i don't think it does on *nix
[15:27:11 CEST] <furq> i checked and pv | ffmpeg seems to work with mp4 as long as it's faststart
[15:27:53 CEST] <BtbN> You usually know how long your video is anyway, and you already get an indication how how many frames and what time has been processed.
[15:28:02 CEST] <furq> yeah it's not something i've ever missed
[15:28:46 CEST] <furq> you'd also need to disable the ffmpeg stats output or else it'll mess up the pv output
[15:28:53 CEST] <furq> and i'd usually rather know the average bitrate etc
[15:30:06 CEST] <w1kl4s> Yeah usually if something doesn't have built in progressbar, it's for a reason
[18:25:18 CEST] <q-u-a-n> Where can I read how various codecs work in laymen terms?
[18:25:51 CEST] <JEEB> I recommend the H.264 book - or if you need to go even deeper EBU has a book called "Circles of confusion"
[18:26:13 CEST] <JEEB> circles of confusion starts off with "what is color"
[18:26:25 CEST] <durandal_1707> color is a lie
[18:26:40 CEST] <q-u-a-n> 👍 great
[18:27:00 CEST] <JEEB> https://www.amazon.com/H-264-Advanced-Video-Compression-Standard-ebook/dp/B005UQLIPU
[18:27:07 CEST] <JEEB> this is the "H.264 book"
[18:27:33 CEST] <q-u-a-n> Have you read it yourself?
[18:27:41 CEST] <durandal_1707> that is for h264 codec only, other codecs may not have book(s)
[18:27:59 CEST] <JEEB> yes, of course. but a lot of codecs are block based etc
[18:28:36 CEST] <q-u-a-n> Oh, so what Ill learn will probably help me understand other modern codecs
[18:28:58 CEST] <JEEB> ´HEVC for example did not fall far off from AVC
[18:29:14 CEST] <JEEB> as in, if you understand H.264 you can then see the parts where it got changed
[18:29:20 CEST] <JEEB> then if you want the real dry stuff
[18:29:26 CEST] <JEEB> you have the specifications :P
[18:29:53 CEST] <q-u-a-n> Whats something I can expect to learn about if I read that book
[18:30:23 CEST] <durandal_1707> how to write codecs from scratch?
[21:36:31 CEST] <GuiToris> Hey, I have a question; If I have multiple inputs  like ffmpeg -i %d.png -i %d.jpg -filter_complex "[0:v][1:v] overlay" output, then do I have to specify -framerate 30000:1001 before each -i or just once?
[21:37:04 CEST] <furq> before both
[21:37:38 CEST] <ChocolateArmpits> ehhh 30000/1001
[21:37:52 CEST] <GuiToris> ChocolateArmpits: what's wrong with that?
[21:38:01 CEST] <GuiToris> or it's a slash?
[21:38:02 CEST] <ChocolateArmpits> does 30000:1001 actually work?
[21:38:05 CEST] <furq> it's a /
[21:39:19 CEST] <GuiToris> I may have messed up twice then... the audio and the video don't match... I did : ffmpeg -framerate 30000:1001 -i singleimg.png -i sequence%d.png -filter_complex "[0:v][1:v] overlay output.mp4
[21:39:42 CEST] <GuiToris> I guess framerate before a single image doesn't make much sense
[21:40:24 CEST] <GuiToris> it should be ffmpeg -i single.png -framerate 30000/1001 -i seq%d.png -filters, shouldn't it?
[21:42:16 CEST] <ChocolateArmpits> GuiToris, the first image will default to 25 fps, which I guess can mess up the overlay input as that's also the main input
[21:42:26 CEST] <ChocolateArmpits> overlay filter
[21:42:59 CEST] <GuiToris> so even if it's a single image I should specify the 29.97 twice
[21:43:06 CEST] <ChocolateArmpits> I'd really set the framerate just to be sure
[21:43:49 CEST] <GuiToris> thank you, something was strange indeed, the framerate was 29.97 but the video was a bit longer than the audio
[22:42:37 CEST] <JohnnyonFlame> Hello there, is there any way to force ffplay to catch up with the accumulated buffer, even if that means dropping samples? I'm having issues with an udp stream slowly accumulating and latency slowly increasing
[22:42:54 CEST] <JohnnyonFlame> (the 'aq' meter slowly grows)
[22:44:22 CEST] <JEEB> I don't think it's got the hacks to forget about AV sync
[22:44:30 CEST] <JEEB> mpv got an option to do that methinks
[22:44:40 CEST] <JEEB> https://mpv.io/manual/master/#low-latency-playback
[22:46:02 CEST] <JohnnyonFlame> I'll check it out, thank you
[23:00:31 CEST] <JohnnyonFlame> this is weird, if I skip ahead on a youtube video (on the server) the audio buffer on mpv (client) will grow by the dozens of kilobytes
[23:00:55 CEST] <JohnnyonFlame> simply relaunching mpv is enough to fix it
[23:00:59 CEST] <kerio> DOZENS :o
[23:02:36 CEST] <JohnnyonFlame> eh, you're making fun of it, but it easily grows from low latency to "2 seconds" with a few taps
[23:03:30 CEST] <JohnnyonFlame> I'm wondering if it's related to ffmpeg udp streams or if its a weird interaction between the ffmpeg ''server'' and the pulseaudio null sink
[23:03:42 CEST] <JEEB> no idea
[23:03:48 CEST] <JEEB> I've not used that mode at all myself
[23:04:20 CEST] <JohnnyonFlame> thanks tho, mpv goes give me a better idea of where to poke at
[23:25:29 CEST] <worstadmin> How can I see bits per pixel using ffmpeg?
[23:42:25 CEST] <kepstin> worstadmin: you can determine it from the pixel format, each pixel format has a specific number of and layout of bits per component.
[23:43:17 CEST] <worstadmin> ffprobe -show_entries frame=pkt_size,pkt_pts_time <input>?
[23:43:26 CEST] <worstadmin> I'm new to this video stuff
[23:43:32 CEST] <worstadmin> I specifically want bits per pixel
[23:46:08 CEST] <kepstin> normally "bits per pixel" means "how many bits are there per pixel (or pixel component) in the decoded/raw representation of the video", and I told you how to find that out.
[23:46:23 CEST] <kepstin> if you want something different, you'll have to be more clear
[23:47:50 CEST] <furq> ffprobe doesn't show it
[23:48:10 CEST] <kepstin> e.g. yuv420p has 8bit luminance + 2 quarter subsampled 8bit chroma planes, so it ends up being 12 bits per pixel
[23:49:01 CEST] <furq> mediainfo will normally show it fwiw
[23:49:27 CEST] <furq> i'm assuming you want the bpp measurement that people haven't cared about since xvid
[23:49:42 CEST] <furq> and not the one for rawvideo which is what kepstin just said
[23:51:19 CEST] <kepstin> oh, huh, "bits per pixel" as a measure of, uh, well, hmm. Not sure what that would be useful for.
[23:51:30 CEST] <furq> there was an old rule of thumb for xvid that you should aim for 0.2bpp
[23:51:52 CEST] <furq> i've not heard anyone mention it since then though
[23:52:00 CEST] <kepstin> I guess if you're using the same codec with the same settings on different frame sizes, hitting the same number of bits per encoded pixel would mean approximately the same quality
[23:52:02 CEST] <worstadmin> Why doesn't anyone care about it anymore? It's a good sign that someone's encoding is bad or good right? If Im encoding talking heads video at 320x180 with a frame rate of 30 and a 0.800 bpp then I'm doing something wrong
[23:52:09 CEST] <kepstin> but with x264 you just use crf and it's better
[23:52:24 CEST] <furq> worstadmin: because x264 has a quality-based mode that you should use instead
[23:52:52 CEST] <worstadmin> That doesn't change the usefulness of BPP
[23:53:04 CEST] <kepstin> I mean, it's easy enough to calculate, just divide bitrate (bit/s) by pixel rate (h * w * framerate) and you get it
[23:53:17 CEST] <furq> i mean it was never a particularly useful measure because there's no such thing as a universally good bpp
[23:53:22 CEST] <furq> it always depends on the content
[23:53:29 CEST] <kepstin> but given the amount of tuning you can do with modern codecs, you can have different qualities at the same bpp
[23:53:38 CEST] <worstadmin> Its not about universal but if Im encoding sports and I see that everyone is doing 0.200 in the industry
[23:53:42 CEST] <worstadmin> Then it becomes useful
[23:53:44 CEST] <kepstin> so it's meaningless aside from comparing different encodes with the same encoder and encoder settings
[23:54:08 CEST] <worstadmin> Well I mean industry h.264 shit on ABR with certain BPP is pretty common and useful empirical data
[23:54:23 CEST] <furq> it's not really useful unless you're using the same encoder and settings
[23:54:28 CEST] <kepstin> with "encoding sports", it's just that they target a certain total bitrate because that's the size of their atsc bandwidth or whatever :/
[23:54:33 CEST] <furq> also that
[23:54:55 CEST] <worstadmin> Im still a newbie so some of this is beyond me - but I'll read up
[23:55:08 CEST] <kepstin> quality varies so much depending on frame content - one show will look great at low bitrate, another will block havily
[23:55:12 CEST] <kepstin> so ... :/
[23:55:23 CEST] <furq> and on the encoder and settings
[23:56:27 CEST] <kepstin> anyways: rules of thumb: if you need to encode to a target bitrate due to other constraints, do that, and use the slowest encoder settings you can manage. If you want a target quality, use a quality based encoder mode (like crf in x264) and use the slowest encoder settings you can manage.
[23:56:47 CEST] <furq> if you're using x264 and it's for archival then all you really need to consider is preset and crf
[23:56:47 CEST] <kepstin> crf isn't exactly quality, but it's closer than bpp :/
[23:56:50 CEST] <furq> and maybe tune
[23:57:27 CEST] <furq> and also if that's the case then you'll pretty much always come out below 0.2bpp
[23:59:45 CEST] <kepstin> worstadmin: anyways, saying "most people in the industry are using 10mbit/s at 1080p60" is exactly the same as comparing bpp, since you can calculate bpp from bitrate, frame size, and frame rate.
[23:59:56 CEST] <worstadmin> Makes sense
[00:00:00 CEST] --- Fri Oct 12 2018