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

[burek]

[00:06:14 CET] <alexpigment> hey all of you not-lawyers. do you know if VIA's AAC licensing is for encoding, or encoding + decoding?
[00:07:29 CET] <TheRock> where are you from alexpigment?
[00:07:56 CET] <alexpigment> US
[00:10:32 CET] <TheRock> Ah, ok . In my country software patents are illegal.
[00:10:38 CET] <TheRock> I wouldn't need licensing :P
[00:11:22 CET] <alexpigment> well, I think you should be able to make money off of your software patents, although clearly the US has a bunch of problems with dealing with patents
[00:11:35 CET] <alexpigment> anyway, no worries
[00:11:45 CET] <alexpigment> just trying to read between the lines on this VIA licensing
[00:12:08 CET] <alexpigment> very legalese as expected
[00:12:09 CET] <TheRock> i'd pay anyway
[00:12:21 CET] <alexpigment> you'd pay what?
[00:12:34 CET] <TheRock> when i would use for example h264, i'd contact them and pay
[00:12:46 CET] <TheRock> although the patent is not valid in my country
[00:13:07 CET] <alexpigment> well, h264 has a minimum number of units that most companies don't hit
[00:13:46 CET] <alexpigment> aac doesn't have a minimum number of units
[00:14:38 CET] <TheRock> yeah, then you would need to pay from begin
[00:15:07 CET] <TheRock> mpeg-la (I guess) has 100k ilmit yearly, after that you need pay
[00:15:17 CET] <alexpigment> right
[00:15:23 CET] <alexpigment> 100k is a lot
[00:15:34 CET] <TheRock> definitely, but if you share you software online as trial
[00:15:41 CET] <TheRock> you can hit it fast
[00:15:58 CET] <alexpigment> yeah, a lot of people disable that sort of functionality
[00:16:06 CET] <alexpigment> or at least track trial usage
[00:16:20 CET] <TheRock> that stuff is mostly available in the paid version
[00:16:32 CET] <TheRock> so they are within the free limit
[00:18:17 CET] <TheRock> they couldn't sue me in my country, if i ignore it. but they may come with the argument it was used by US computer so US law applies
[00:18:25 CET] <TheRock> :]
[00:42:43 CET] <SortaCore> if they have enough money, they could sue you in any country
[09:28:26 CET] <Clinton> downloading a video with ffmpeg is taking way too long
[09:29:18 CET] <Clinton> a m3u8 playlist
[09:53:20 CET] <SortaCore> Clinton: as opposed to downloading it how?
[09:53:28 CET] <SortaCore> maybe youtube-dl will be faster?
[09:54:42 CET] <Clinton> ffmpeg -i link.m3u8 -c copy video.mkv SortaCore
[09:59:11 CET] <furq> youtube-dl just uses ffmpeg for hls anyway
[09:59:27 CET] <furq> it pretty much just finds the playlist url and then passes it to the ffmpeg binary
[09:59:58 CET] <furq> Clinton: if you can't get it faster with some other tool then chances are the httpd is just rate limiting it
[10:00:35 CET] <furq> i know a few hls vod providers that do that
[10:01:49 CET] <Nacht> Its good to know we've come to an age where we actually have to rate limit video downloads :)
[10:03:54 CET] <bencoh> :)
[10:50:15 CET] <dragmore88> hi! im doing some archiving benchmarks with a 422-10bit pro-res source and x264 crf 10bit 422 target, and the results look excellent.. But, the ssim and psnr values are way off.. SSIM: 0.89ish and psnr avg. 31.6.. anyone know why ?
[10:51:09 CET] <dragmore88> Could it be that -lavfi ssim/Psnr calculator doesnt support 10bit or 4:2:2 chroma?
[10:51:47 CET] <dragmore88> Cause a 31.6 psnr avg value should show crap on the screen, and the screening is excellent
[11:04:20 CET] <durandal_1707> dragmore88: pastebin full output uncut
[11:05:02 CET] <durandal_1707> ffmpeg command lines
[11:05:18 CET] <dragmore88> sure; check this post : https://forum.doom9.org/showthread.php?p=1827842#post1827842
[11:05:22 CET] <dragmore88> put em all there
[11:05:32 CET] <dragmore88> scratching my head on this one
[11:06:01 CET] <dragmore88> any help apriciated
[11:08:11 CET] <durandal_1707> dragmore88: but ffmpeg output is most important
[11:08:41 CET] <dragmore88> encoding output or ssim/psnr calc ?
[11:09:03 CET] <durandal_1707> the ffmpeg output in console, text
[11:10:15 CET] <dragmore88> sec, ill give u 2 examples
[11:13:16 CET] <dragmore88> https://pastebin.com/Ckf0BNRf
[11:13:22 CET] <dragmore88> thats from the calculation
[11:15:57 CET] <dragmore88> https://pastebin.com/Xv2MbXbB
[11:16:06 CET] <dragmore88> from the encode
[11:16:19 CET] <dragmore88> let me know if u need any more examples
[11:19:10 CET] <furq> dragmore88: x264 tends to score poorly on psnr/ssim if you leave psy optimisations on
[11:19:39 CET] <furq> if you have a build with libvmaf you might want to use that instead
[11:19:44 CET] <furq> !filter libvmaf
[11:19:44 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#libvmaf
[11:20:33 CET] <dragmore88> furq: i agree in general, but ive used this method before with 8bit and 4:2:0 and gotten very good ssim and psnr scores
[11:20:49 CET] <dragmore88> ssim 0,89 is terrible
[11:21:10 CET] <dragmore88> and when im watching the result, i cannot see any difference..
[11:21:20 CET] <dragmore88> gonna do a test with x265 now
[11:21:22 CET] <illegal> how come I can't see stream size in mediainfo whenever I mux with ffmpeg?
[11:21:48 CET] <illegal> I wonder how does mediainfo even get the stream size to begin with
[11:23:49 CET] <termos> A good way to not let the `idet` filter run forever but just on the first say 500 frames? I tried with something like `idet=-1:-1:0:0:500` to make it run only on the first 500 frames, but it seems it's not detecting correctly
[11:24:55 CET] <furq> termos: if you mean run on 500 frames and then stop processing, then use -t
[11:24:56 CET] <durandal_1707> dragmore88: perhaps its because pts get messed up
[11:25:43 CET] <termos> I want to keep processing, just want to save CPU on running idet for the whole duration
[11:25:53 CET] <furq> https://ffmpeg.org/ffmpeg-filters.html#Timeline-editing
[11:26:06 CET] <furq> hopefully idet supports that
[11:26:50 CET] <dragmore88> durandal_1707: hmm. please elaborate
[11:28:01 CET] <termos> ah timeline editing looks really cool, didn't know about that! unfortunately idet does not support it
[11:31:41 CET] <durandal_1707> dragmore88: use setpts  filter on each input before passing to ssim filter
[11:32:28 CET] <durandal_1707> are both outputs cfr?
[11:33:40 CET] <dragmore88> durandal_1707: would u be so kind to provide the syntax for setpts? and all outputs are CRF yes (or did u mean something else with cfr?
[11:34:08 CET] <durandal_1707> dragmore88: constant frame rate
[11:34:46 CET] <dragmore88> havnt touched the setting
[11:34:50 CET] <dragmore88> running default
[11:35:54 CET] <durandal_1707> dragmore88: run master file like this: ffmpeg -i master -f null -
[11:36:08 CET] <durandal_1707> and report ffmpeg console output
[11:37:32 CET] <dragmore88> https://pastebin.com/XSbD6E0c
[11:42:51 CET] <durandal_1707> dragmore88: extract for example 200th frame from both files, are they same shot?
[11:44:02 CET] <dragmore88> durandal_1707: ill check (need to figure the syntax), btw, did the same test in x265, same problem
[12:30:23 CET] <durandal_1707> dragmore88: i seem cant repro this, and rgb you uploaded are almost same and give high score
[13:36:24 CET] <ubitux>  /g 19
[15:29:14 CET] <wtiger> Hi! how do I record the audio being outputted to the speakers via ffmpeg?
[15:29:26 CET] <wtiger> can I do it solely with ffmpeg?
[15:36:54 CET] <SortaCore> yes
[15:38:44 CET] <SortaCore> wtiger: https://trac.ffmpeg.org/wiki/Capture/Desktop#Windows
[15:40:09 CET] <wtiger> SortaCore: want to capture only the audio and not the desktop
[15:40:20 CET] <SortaCore> yes, use logical deduction
[15:40:55 CET] <SortaCore> ffmpeg -f dshow -i video="screen-capture-recorder" output.mkv is video
[15:40:55 CET] <wtiger> haha
[15:41:02 CET] <SortaCore> ffmpeg -f dshow -i video="UScreenCapture":audio="Microphone" output.mkv is both
[15:41:22 CET] <SortaCore> logically, deduct one from the other, you get ffmpeg -f dshow -i audio="Microphone" output.mkv
[15:41:32 CET] <SortaCore> (but mkv is video format so not ideal)
[15:42:04 CET] <wtiger> SortaCore: gotcha
[15:42:14 CET] <SortaCore> test if that works, I've not used it
[15:42:21 CET] <SortaCore> I'm just being sassy because I'm tired
[15:53:44 CET] <garyserj> given two files, both have container mpeg4, video codec AVC, audio codec AAC.  One is .mp4 one is .3gp What is the difference?
[16:00:11 CET] <Nacht> garyserj: the container
[16:00:42 CET] <JEEB> garyserj: 3gp and mp4 are subsets of ISOBMFF
[16:01:34 CET] <JEEB> so you have a specification that says "ISOBMFF with identifier XXXX can use the following features"
[16:01:58 CET] <JEEB> ISOBMFF is of course "ISO Base Media File Format", which itself bases on MOV
[16:46:43 CET] <dave0x6d> Exception (St13runtime_error): Failed to read frame: Invalid data found when processing input
[16:47:41 CET] <dave0x6d> Getting that on a h264 file.
[16:47:48 CET] <dave0x6d> Also, I see: [mov,mp4,m4a,3gp,3g2,mj2 @ 0x61b00001f180] stream 0, offset 0x30: partial file
[16:50:40 CET] <kepstin> dave0x6d: most mp4 files store some important data at the end, so if the file is incomplete, you can't decode it
[16:52:47 CET] <dave0x6d> kepstin: hmm. It works with ffmpeg on macOS.. Odd.
[16:53:24 CET] <kepstin> are you sure it's the same file / that it copied completely between os?
[16:54:22 CET] <dave0x6d> yeah, both have 18263ee610994deb429e66d3e40e1fb4 as their hash.
[16:56:14 CET] <dave0x6d> kepstin: https://paste.debian.net/hidden/1228b62b/
[16:57:58 CET] <kepstin> dave0x6d: ok, so it works in ffmpeg - what's this "recode" thing?
[16:58:13 CET] <dave0x6d> https://github.com/dropbox/avrecode
[16:58:14 CET] <garyserj> thanks. Also, I understand there are certain codecs that are certain valid combinations of codec for example  MPG container can have MPEG1 Video,  and MP2 audio.   Mp4 can have video codecs of x264 or xvid, and audio codec of aac or mp3.   Is there anywhere that lists these?
[16:59:51 CET] <kepstin> dave0x6d: looks like a bug in that tool - i suspect that it doesn't implement seekable input correctly.
[17:00:22 CET] <kepstin> dave0x6d: a workaround might be to remux the file to be streamable before using that tool on it, e.g. do "ffmpeg -i file.mp4 -c copy -movflags faststart file-streamable.mp4"
[17:00:44 CET] <dave0x6d> kepstin: i'm pretty new to codecs, aren't all h264 streams seekable?
[17:01:12 CET] <kepstin> dave0x6d: it would be a problem with the code in the tool, not the file itself.
[17:01:54 CET] <kepstin> since regular mp4 files have important info at the end of the file, you have to seek to the end of the file, read the info, then seek back to the start.
[17:02:26 CET] <kepstin> if the tool's not set up right, then ffmpeg will say "hey, can I get the data from the end", the tool goes "i don't know how to do that", then ffmpeg gives up.
[17:03:05 CET] <kepstin> the command example I gave with "-movflags faststart" works around that by moving the important info to the front of the file.
[17:03:29 CET] <dave0x6d> ahh, thanks! Running into a new issue; definitely not ffmpeg's fault now, but do you have any more workaround suggestions? :) https://github.com/dropbox/avrecode/issues/2
[17:04:05 CET] <kepstin> dave0x6d: no idea about that. I suggest contacting them about it.
[17:04:54 CET] <dave0x6d> er, already have? hence it being on github :p
[17:05:19 CET] <kepstin> dave0x6d: well, then you should provide a sample like they asked for :)
[17:10:31 CET] <dave0x6d> kepstin: heh, you're probably more experienced with ffmpeg than some of the devs there
[17:10:51 CET] <kepstin> that's not ffmpeg code tho
[17:11:06 CET] <kepstin> that's a problem with their internal code that does the h264 recompression stuff
[17:11:21 CET] <dave0x6d> yeah, but they're choking on ffmpeg output it seems.
[17:11:43 CET] <dave0x6d> https://github.com/dropbox/avrecode/blob/0749548cc337c59933da84063c1edc97ac11d259/recode.cpp#L1033
[17:12:08 CET] <kepstin> well, x264 output, not ffmpeg output
[17:12:19 CET] <kepstin> which is weird, considering how common of an encoder x264 is
[17:12:40 CET] <kepstin> maybe this tool is just intended for recompressing stuff made by hardware encoders (phones & whatnot)
[17:13:04 CET] <kepstin> x264 is such a good encoder that the gains would be miniscule anyways
[17:14:01 CET] <dave0x6d> I know, but seems fun to try, no? :)
[17:14:30 CET] <kepstin> who knows, it might work if you purposefully run x264 in a non-optimal mode, like limiting it to baseline or something
[17:15:24 CET] <dave0x6d> yeah, my use-case was compressing h264 videos that I didn't encode myself.
[17:17:10 CET] <khali> hello everybody
[17:17:41 CET] Action: dave0x6d blindly comments out asserts 
[17:18:19 CET] <khali> I have an h.264 video with 2 aspect ratios, one at the video stream level, one at the container level; the one at video stream level is correct, the one at container level is bogus
[17:18:54 CET] <khali> can I convince ffmpeg to copy that video stream but ignore the container-level aspect ratio information?
[17:19:45 CET] <kepstin> khali: using the '-aspect' output option in ffmpeg along with '-c copy' should allow you to override the container-provided aspect when rewriting the file.
[17:25:06 CET] <dave0x6d> kepstin: sadly seeing a 0% difference on my working samples ;P
[17:33:37 CET] <khali> kepstin: you're a genius :-) thank you very much!
[17:36:14 CET] <khali> I was looking for an option to explicitly remove the aspect, but simply setting the container aspect to the same as the video stream aspect does the trick :-)
[17:36:28 CET] <khali> as it turns, "-c copy" wasn't even needed
[17:36:47 CET] <kepstin> without -c copy, it'll do a lossy re-encode of the video, which I wouldn't recommend
[17:36:55 CET] <kepstin> (unless that's what you wanted to do)
[17:37:30 CET] <khali> not at all
[17:37:51 CET] <khali> but -codec:v copy -codec:a copy was already on my command line
[17:38:41 CET] <khali> sorry I should have mentioned that before; then I though -c was for container level but it's not, just it was the same I was already doing
[17:39:08 CET] <khali> I didn't know the -c shortcut, thanks for teaching me that as well :)
[17:47:10 CET] <dave0x6d> kepstin: off topic, but hey fellow ottawa person.
[17:47:45 CET] <kepstin> heh, you found my website, i guess? cheers :)
[17:51:04 CET] <khali> and now I still have one last mystery to solve: how can avidemux produce a file 25% smaller than my ffmpeg command line, for the same x264 codec and version, same x264 tuning settings, same frame rate, same resolution... same everything
[17:51:09 CET] <dave0x6d> kepstin: yea, your github profile photo looks like carleton or uOttawa chairs?
[17:51:17 CET] <khali> this makes no sense and is getting me crazy :(
[17:52:38 CET] <kepstin> dave0x6d: yeah, that was a lounge in one of the carleton science buildings.
[17:53:24 CET] <kepstin> khali: hmm. pixel format the same? a file in e.g. 4:2:2 or 4:4:4 will usually be bigger than 4:2:0
[17:54:27 CET] <khali> kepstin: yuv420p for both, yes
[17:54:53 CET] <kepstin> both files have audio? :)
[17:55:34 CET] <dave0x6d> kepstin: ah yes, computer science society lounge :)
[17:55:54 CET] <khali> kepstin: yes, the difference is on the video stream size only
[17:56:25 CET] <khali> I looked for differences using mediainfo
[17:56:28 CET] <kepstin> no, actually it wasn't. ccss didn't have those chairs, that was a... teacher's lounge on the 5th floor iirc.
[17:56:53 CET] <kepstin> well, ccss probably had similar chairs at some point
[17:57:46 CET] <khali> the only difference is "Frame rate mode" which is constant on the large file (produced by ffmpeg) and variable on the smaller file (produced by avidemux)
[17:58:19 CET] <khali> but I checked the frame count and it's the same... I even checked the I/P/B numbers and they match
[17:58:29 CET] <dave0x6d> kepstin: a very random question, does your motherboard allow enabling SR-IOV?
[17:58:56 CET] <kepstin> khali: hmm. open the file in a hexeditor and look at the list of x264 options stored int he header, maybe? :/
[18:01:21 CET] <kepstin> dave0x6d: i don't know about sr-iov. I know that after a few bios updates, the iommu layout was improved quite a bit, so regular pcie passthrough should be doable.
[18:02:23 CET] <khali> kepstin: would it be different from the "Encoding settings" reported by mediainfo?
[18:02:42 CET] <kepstin> khali: i'm not familiar with mediainfo, it might pull that out for you.
[18:03:00 CET] <khali> it shows all the x264 knobs
[18:03:16 CET] <khali> which I have already completed to be the same in both files
[18:04:22 CET] <furq> they're the same thing, yeah
[18:04:35 CET] <khali> compared, not completed, sorry
[18:04:58 CET] <dave0x6d> kepstin: my asus b350 worked out of the box. Only problem is that the USB 3.1 and main SATA controller are bundled together, as well as the audio and FCH SATA controller.
[18:52:45 CET] <alexpigment> klahi: you didn't mention bit rate
[18:52:49 CET] <alexpigment> er
[18:52:58 CET] <alexpigment> khali: you didn't mention bit rate when you said everything is the same
[18:53:12 CET] <alexpigment> if you download bitrate viewer (windows only i believe), what does it say the bitrate is for each?
[18:53:29 CET] <alexpigment> for context, the only thing that determines file size is the bitrate
[18:53:56 CET] <alexpigment> the other things like frame rate, resolution, etc, don't actually have an impact on file size for x264
[18:58:57 CET] <alexpigment> khali: the other thing to do in mediainfo is go into View > Tree and see if there are multiple audio (or video) streams in one and not the other
[19:06:07 CET] <khali> alexpigment: obviously bitrate is different
[19:06:20 CET] <khali> otherwise files would be the same
[19:06:41 CET] <alexpigment> khali: right, so you're trying to figure out what's different. what are the rate controls set to?
[19:06:51 CET] <alexpigment> are you using CRF or -b:v ?
[19:06:56 CET] <khali> but the bitrate is supposed to be the consequence of the x264 settings combined with frame size and frale rate
[19:07:04 CET] <khali> alexpigment: CRF=23 in both files
[19:07:17 CET] <alexpigment> preset = ?
[19:07:19 CET] <khali> I'm not asking for any specific bitrate
[19:07:46 CET] <alexpigment> if you don't specify a preset, x264 will use medium by default
[19:08:05 CET] <khali> alexpigment: not sure about preset, it doesn't show in the output of mediainfo
[19:08:32 CET] <alexpigment> yeah, preset is not shown in those settings; it's shown in other settings
[19:08:36 CET] <khali> I know I don't specify it on my ffmpeg command line, but I don't know what avidemux does
[19:09:03 CET] <alexpigment> ok, so in the x264 configuration in avidemux, it's on the general tab
[19:09:46 CET] <khali> ah
[19:10:13 CET] <alexpigment> so CRF will produce a different bitrate depending on the preset
[19:10:13 CET] <khali> I have "preset" : "veryslow" in the avidemux profile I'm using
[19:10:18 CET] <alexpigment> makes sense
[19:10:41 CET] <alexpigment> if you set it to medium (or if you set the preset in ffmpeg to veryslow), you will probably get roughly the same file size
[19:10:58 CET] <khali> I thought preset was just a predefined set of values for other settings, to build more specific profiles on top?
[19:11:35 CET] <alexpigment> yes, it is
[19:11:50 CET] <alexpigment> but it enables or disables things that affect the efficiency of the encoding
[19:12:17 CET] <alexpigment> and if the encoding is more efficient at a given preset, it will need less bits to achieve the same level of quality
[19:12:18 CET] <khali> things which do not show up in the x264 settings string recorded in the file header?
[19:12:48 CET] <alexpigment> khali: have you looked at the "Text" view of MediaInfo
[19:12:54 CET] <alexpigment> that string is very long
[19:13:05 CET] <khali> yes, that's what I do
[19:13:08 CET] <alexpigment> k
[19:13:20 CET] <alexpigment> lemme find the chart of the difference between medium and veryslow
[19:13:23 CET] <khali> I have my own script which splits it to one setting per line for easier comparison
[19:13:36 CET] <alexpigment> http://dev.beandog.org/x264_preset_reference.html
[19:13:58 CET] <khali> and my 2 files have the same "Encoding settings"
[19:14:06 CET] <alexpigment> refs should be different (that's listed in the general mediainfo settings)
[19:14:16 CET] <alexpigment> rc lookahead should be different
[19:14:23 CET] <khali> except for the decimal separator, probably due to different locale being used
[19:14:28 CET] <alexpigment> subme should be different
[19:14:44 CET] <alexpigment> b-frames should be different
[19:14:58 CET] <alexpigment> unless, of course, you've specified settings that override what the preset defines
[19:18:12 CET] <khali> I do
[19:18:44 CET] <khali> still, that's something to look into, in case some settings don't end in the encoder settings string
[19:19:03 CET] <khali> so thank you very much for the hint, I'll check as soon as possible
[19:19:09 CET] <alexpigment> so rc lookahead is 40 in both though?
[19:19:26 CET] <khali> rc_lookahead=60 in both actually
[19:19:30 CET] <alexpigment> weird
[19:19:40 CET] <alexpigment> are you sure you're comparing the right files?
[19:19:46 CET] <khali> I must leave now :/ tennis lesson in 40 minutes
[19:19:49 CET] <alexpigment> ok
[19:19:58 CET] <khali> yes sir
[19:20:01 CET] <alexpigment> when you get back, redo your tests. i think you're looking at the wrong files somehow
[19:20:18 CET] <khali> if I can't figure out, I'll produce shorter samples and share them
[19:20:22 CET] <alexpigment> k
[19:20:40 CET] <khali> it's probably easier to help if you have the files on your own
[19:20:44 CET] <khali> thanks again, see you
[19:20:48 CET] <alexpigment> yep
[19:20:53 CET] <alexpigment> np
[19:32:08 CET] <CoreX> alexpigment the preset slow refrences on that beandog page is wrong
[19:32:26 CET] <CoreX> its hex now not umh
[19:32:29 CET] <alexpigment> CoreX: k
[19:32:40 CET] <alexpigment> maybe it's worth emailing beandog about that
[19:45:12 CET] <thebombzen> does ffmpeg not build with x265 2.6?
[19:47:48 CET] <thebombzen> Arch linux just updated libx265 to libx265.so.146
[19:47:52 CET] <thebombzen> and now it can't find libx265.so.130
[20:07:52 CET] <utack> thebombzen maybe your mirror was out of date, ffmpeg was updated too https://www.archlinux.org/packages/extra/x86_64/ffmpeg/
[20:08:11 CET] <thebombzen> utack: ffmpeg in the arch repos was patched by the arch maintainer
[20:08:17 CET] <thebombzen> git master doesn't build against libx264.so.146
[20:08:24 CET] <thebombzen> and that's what I care about
[20:08:26 CET] <utack> oh...good job then i guess
[20:08:38 CET] <utack> guy knows how to maintain :D
[20:08:46 CET] <thebombzen> sort of
[20:09:02 CET] <utack> we make your own ffmpeg, with libx264 and building!
[20:09:13 CET] <thebombzen> ended up screwing up crap for mpv though with his overzealous pushes
[20:09:30 CET] <thebombzen> it's better to wait until upstream makes it work usually, since ffmpeg is under active development
[20:15:22 CET] <storrgie> I was in here bothering alexpigment a couple days back about recording A+B, A, B stereo pcm channels into an mkv... and what you suggested worked perfectly, thanks!
[20:15:57 CET] <storrgie> I'm wondering now, can I re-encode what I've captured via something like libopus, I think what I'm capturing now is uncompressed, I'd like to compress before sending it off to the archive
[20:22:43 CET] <storrgie> ffmpeg -i raw.mkv -acodec libopus -b:a 256k -vbr on -compression_level 10 opus.mkv appears to decemate the three tracks into one, or maybe only selects the first track
[20:23:12 CET] <c_14> only selects the first track
[20:23:15 CET] <c_14> you need -map 0
[20:23:30 CET] <c_14> and you probably want -c:v copy
[20:23:50 CET] <storrgie> only audio in the container, no video
[20:24:01 CET] <c_14> then you don't need it
[20:24:37 CET] <storrgie> is it possible to name the streams?
[20:24:45 CET] <storrgie> at time of capture, or at time of re-encoding?
[20:25:05 CET] <c_14> -metadata:s:a:0 title="Foobar 1st Stream"
[20:25:07 CET] <c_14> I believe
[20:26:31 CET] <storrgie> that does work perfectly, thanks
[20:27:50 CET] <storrgie> is there any anecdotal recommendations for the parameter of bitrate with libopus? `libopus -b:a 192k`
[20:28:35 CET] <c_14> depends on what the audio is
[20:28:42 CET] <c_14> voice needs less bitrate than say music
[20:29:09 CET] <storrgie> channel one (A+B) is game audio (e.g. music) and voice, channel 2 is just voice, channel 3 is just game audio
[20:29:21 CET] <storrgie> ffmpeg -f dshow -i audio="Microphone (Realtek Audio)" -f dshow -i audio="Stereo Mix (Realtek Audio)" -filter_complex "[0:a][1:a]amerge=inputs=2,pan=stereo|c0<c0+c2|c1<c1+c3[aout]" -map "[aout]" -c:a pcm_s16le -map 0:a -map 1:a output.mkv
[20:29:33 CET] <kepstin> once you get past around 64kbit/channel, gains are pretty minimal.
[20:29:46 CET] <kepstin> (although it depends on content, yeah)
[20:30:14 CET] <storrgie> in this case we're primarily wanting to analyze the voice content afterwards, so we're not entirely interested in the quality of the game audio content
[20:30:18 CET] <storrgie> its just used for time alignment
[20:31:31 CET] <c_14> 192k is probably fine unless you're trying to save space
[20:31:36 CET] <c_14> (assuming stereo)
[20:31:48 CET] <storrgie> yeah, three stereo channels
[20:34:28 CET] Action: kepstin would probably just go with 128kbit for each stereo stream, but throwing some extra bits like 192k obviously won't hurt anything
[20:36:40 CET] <storrgie> thanks a ton, this is really perfect
[21:02:50 CET] <alexpigment> storrgie: just got back from lunch. glad to see you got it back. I had a feeling PCM was going to be too big :)
[21:02:57 CET] <alexpigment> 30MB/min
[21:03:12 CET] <alexpigment> anyway, cool that you got it all figured out
[21:30:03 CET] <Primer> Hi, I have an ffmepg mosaic that stitches 6 separate streams into one. Thing is, ffmpeg opens each stream sequentially. Is there no way to get ffmpeg to open them concurrently? I'm trying to minimize the ramp up time, as this is a mosaic of security cameras, and invoking it takes a good 5-6 seconds before anything is displayed
[21:31:03 CET] <fritsch> might be you opening them sequentially?
[21:31:35 CET] <kepstin> the ffmpeg cli tool code for opening input streams is inherently single threaded - it does one then the next
[21:31:53 CET] <kepstin> would require a pretty significant rewrite to change that
[21:33:14 CET] <fritsch> ah he uses the cli tool
[21:33:19 CET] <fritsch> thought he is coding that himself
[21:33:26 CET] <fritsch> sorry
[21:33:41 CET] <kepstin> that said, in some circumstances you can work around this by spawning a bunch of ffmpeg processes that read from the network and write to pipes, then have the actual video processing done in a separate ffmpeg that reads from the pipes
[21:33:46 CET] <kepstin> or write a custom app, yeah :)
[21:34:59 CET] <Primer> yeah, this is just a very long cli
[21:36:12 CET] <Primer> https://pastebin.com/gwuJ5z5w <-- said script
[21:37:13 CET] <kepstin> hmm, for that sort of use case I'd really just run a bunch of separate mpv processes, if possible. :/
[21:37:31 CET] <kepstin> i guess automatically arranging them on screen might be tricky
[21:37:52 CET] <kepstin> (also, you should be using the 'hstack' and 'vstack' ffmpeg filters - they're faster - lower cpu usage - than overlay)
[21:38:11 CET] <Primer> I have a variant of the script that streams to a remote machine
[21:38:53 CET] <Primer> plus I'm adding cameras, and I don't want to end up running X individual streams
[21:39:06 CET] <Primer> I guess I'll look at doing this with pipes
[21:40:45 CET] <Primer> I mean, if I'm going to split this into individual process, I'd like to keep the end result (i.e. a single video with 6 cameras, soon to be 8)
[21:41:55 CET] <Primer> kepstin: I don't suppose you could give me a hint as to where to start with this?
[21:42:21 CET] <Primer> https://ffmpeg.org/ffmpeg-protocols.html#toc-pipe seems like a good place to start
[21:42:34 CET] <Primer> https://ffmpeg.org/ffmpeg-protocols.html#pipe that is
[21:42:39 CET] <kepstin> hmm, starting this from a bash script?
[21:42:44 CET] <Primer> yeah
[21:42:54 CET] <kepstin> can make use of some of the pipe input spawning stuff then, a moment...
[21:43:27 CET] <Primer> so named pipes in bash?
[21:43:41 CET] <ivan^> really quick question, I'd like to merge webm video and m4a audio and output in mp4 but can't find any details on how to specify output format
[21:43:46 CET] <Primer> i.e. mkfifo /whatever, ffmpeg -i /whatever...?
[21:43:59 CET] <Primer> err, well, pipe to it first from another ffmpeg, then read
[21:44:28 CET] <kepstin> Primer: with bash, I'd build a command like `ffmpeg -i <(ffmpeg -i rtsp://... -c:v rawvideo -f nut) (repeat -i as needed) <filters> <output>`
[21:44:41 CET] <kepstin> the stuff in the <() is a sort of magical pipe subprocess thing
[21:44:47 CET] <Primer> kepstin: ahhh nice
[21:45:34 CET] <Primer> thing is, I'll need 6 input pipes at the start, and I can't see how I'd do that without named pipes
[21:45:37 CET] <ivan^> I have `ffmpeg -i in.webm -i in.m4a -c:v copy -c:a copy out.webm`
[21:45:45 CET] <ivan^> how can I specify I want mp4 output?
[21:45:53 CET] <Primer> because simple redirection is only one pipe, right?
[21:45:56 CET] <Primer> stdin
[21:46:05 CET] <kepstin> ivan^: ffmpeg automatically picks an output format based on the output filename
[21:46:18 CET] <ivan^> oh great
[21:46:19 CET] <ivan^> thanks
[21:46:25 CET] <ivan^> wasn't sure on that
[21:46:54 CET] <kepstin> Primer: that's why I used this bash pipe subprocess stuff - it sets up the pipes for you and substitutes a device filename (it'll be something like /dev/fd/63 ) that the other process can readfrom
[21:47:14 CET] <kepstin> Primer: you can repeat it as many times as you like in a command, and it'll assign unique fds for you
[21:47:52 CET] <kepstin> ivan^: that said, vp9/vp8 (webm video codecs) are not well supported in mp4 files, you probably should transcode the video to h264
[21:48:35 CET] <ivan^> kepstin: does webm not support audio at all?
[21:48:59 CET] <kepstin> ivan^: webm only allows vp8 and vp9 for video and vorbis or opus for audio
[21:49:06 CET] <kepstin> other codecs are not allowed
[21:49:13 CET] <ivan^> I just want to merge these, the format isn't important but I'm using a web player that only supports webm or mp4
[21:49:34 CET] <kepstin> ivan^: you'll either have to convert the video to put it into mp4, or convert the audio to put it into webm
[21:49:45 CET] <kepstin> your choice - audio conversion is faster :)
[21:49:54 CET] <ivan^> will ffmpeg try to warn me if I don't do that?
[21:49:56 CET] <Primer> kepstin: yeah, having a hard time wrapping my head around that. Like, the magic that makes tells me what to read when I do <(
[21:50:26 CET] <ivan^> I've found ffmpeg through the youtube-dl program and am just getting started with it
[21:51:17 CET] <kepstin> ivan^: ffmpeg will give an error message and fail if you try something that's not allowed, but it might not warn you if you're doing something that's merely unconventional.
[21:51:34 CET] <kepstin> Primer: if you want to see what's behind the magic, try running this command: `echo <(printf hello)`
[21:51:53 CET] <Primer> I was thinking of this: for i in $(seq 1 $NUMBER_OF_CAMERAS); do mkfifo /tmp/whatever/$i; ffmpeg -i rtsp://... -o /tmp/whatever/$i &; done; ffmepg -i /tmp/whatever/1 -i /tmp/whatever/2 ...
[21:52:19 CET] <kepstin> Primer: <() is just another "substitution", the whole thing is replaced with a string in the final command line, and the string is a filename that can be read from.
[21:52:50 CET] <Primer> yeah, I see that it outputted the file descriptor
[21:52:59 CET] <Primer> when invoked without interpolation
[21:53:54 CET] <Primer> so, literally: ffmpeg -i <(ffmpeg -i rtsp://...) -i <(ffmpeg -i rtsp://...)... and it'll work
[21:53:58 CET] <kepstin> yep
[21:54:09 CET] <Primer> I imagine I have to background each
[21:54:18 CET] <kepstin> using named pipes (on the filesystem) will work exactly the same, except then you have pipes laying around in the filesystem
[21:54:22 CET] <Primer> so, literally: ffmpeg -i <(ffmpeg -i rtsp://... &) -i <(ffmpeg -i rtsp://... &)... and it'll work
[21:54:33 CET] <Primer> well, I'd have a trap to clean it up
[21:54:38 CET] <kepstin> Primer: no, bash runs them as suprocesses, you don't need to use &
[21:54:40 CET] <Primer> but I like the one-liner approach
[21:54:48 CET] <Primer> kepstin: perfect, thanks
[21:57:47 CET] <Primer> heh, it "worked", but it took way longer to setup
[21:57:53 CET] <Primer> it had to think a lot
[21:58:08 CET] <Primer> I could tell that it ran all the sub processes concurrently
[21:58:15 CET] <Primer> and immediately
[21:58:23 CET] <Primer> I guess it still had to wait for the pipes to fill
[21:59:01 CET] <Primer> https://pastebin.com/YAU11CVt
[21:59:05 CET] <Primer> the updated script
[22:00:01 CET] <kepstin> hmm, did that actually take longer to set up than with a single ffmpeg process?
[22:00:15 CET] <Primer> I suppose I could cout out the -a parts from the streams with no sound
[22:00:29 CET] <Primer> yeah, it took well over 10 seconds before I saw video
[22:00:30 CET] <kepstin> i guess the extra process starting overhead might overwhelm a system, particularly if it doesn't have many cores.
[22:00:44 CET] <Primer> I have 4 cores on a 4th gen Intel
[22:01:19 CET] <kepstin> but yeah, you might be just stuck in a hard place then, unless you write a custom application with ffmpeg libraries :/
[22:02:29 CET] <kepstin> might be interesting to try e.g. a separate subprocess per row of cameras or something as an intermediate step.
[22:02:48 CET] <Primer> well, I've already spent a lot of time on this, but I don't think I'm gonna go that far just to shave a few seconds off a video start up time
[22:03:16 CET] <ivan^> kepstin: thanks for the tips :)
[22:04:09 CET] <Primer> Anyhow, here's the final version: https://pastebin.com/KUgiUz2y it works, but it's no better than the original
[22:04:46 CET] <Primer> hrmm, maybe I need those other pieces like the thread stuff and tcp in the "inner" ffmpegs
[22:06:36 CET] <Primer> that helped a bit, but now the startup is no faster than if it had been sequential
[22:06:42 CET] <Primer> oh well
[22:06:47 CET] <Primer> kepstin: thanks again
[22:07:00 CET] <kepstin> was worth a try, anyways :/
[22:07:27 CET] <Primer> indeed
[22:07:35 CET] <Primer> plus I learned something very cool
[00:00:00 CET] --- Thu Dec 21 2017