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

[burek]

[00:00:28 CET] <furq> use -filter_complex
[00:00:34 CET] <DHE> to specify your own streams use a complex filter with labels
[00:03:00 CET] <Durandal> right, -filter:a:1 works. I guess I was just confused when -af:1 didn't
[00:18:07 CET] <furq> oh really
[00:52:56 CET] <TheRock3> Guys
[00:53:45 CET] <TheRock3> why no bsd license ?
[03:26:29 CET] <zash> Is there a minimal container format where I can include a rawvideo stream and timestamps?
[03:35:11 CET] <furq> zash: .nut
[03:35:34 CET] <furq> or mkv if you want things other than ffmpeg to actually support it
[03:36:14 CET] <furq> https://www.ffmpeg.org/~michael/nut.txt if you need to implement it yourself
[03:37:33 CET] <zash> This is the thing that generates video from memory allocations. I kinda just want some cheap way of making it possible have it somehow related to real time
[03:37:39 CET] <furq> yeah i figured
[03:38:12 CET] <furq> i'm not aware of anything simpler for rawvideo
[03:38:24 CET] <furq> there is a standalone lib for nut but idk if it still works
[03:38:34 CET] <furq> https://github.com/Distrotech/libnut
[03:40:55 CET] <zash> I rewrote the thing to LuaJIT with FFI, where I keep a 1024x1024 array of color structs, and now ffmpeg looks like the bottleneck :)
[03:40:56 CET] <furq> what you could maybe do is have your thing spit out a timecode file and then use that when reencoding
[03:41:22 CET] <furq> idk how to feed that to ffmpeg but there are definitely tools that do it
[03:42:53 CET] <zash> or spit out a marker into the alloc/realloc/free stream once per n time
[03:45:00 CET] <furq> well yeah l-smash and mkvmerge will definitely take timecode files as input, so if nothing else you can encode it with ffmpeg and then remux it with the timecodes
[03:45:50 CET] <furq> i assume mkvmerge will deal with webm
[03:46:23 CET] <furq> https://mkvtoolnix.download/doc/mkvmerge.html#mkvmerge.external_timestamp_files
[04:06:32 CET] <Dilip> Which is the most beginner comfortable GUI for Ubuntu 16.04 for ffmpeg ?Can you suggest a good GUI for ffmpeg in 16.04 Ubuntu
[04:13:26 CET] <Dilip> recommend a good GUI for 16.04 Ubuntu
[06:29:57 CET] <blap> i need a gui for my refrigerator
[06:30:31 CET] <zash> and a twitter app?
[06:33:01 CET] <blap> yessir, and microtransactions so it can pay my coffee machine
[06:33:26 CET] <zash> please sir, may I have some milk?
[06:33:47 CET] <blap> "that will be 0.00381 ethereum, have a nice day"
[06:34:40 CET] <blap> also we need cryptocurrency microtransactions so my linux programs can pay each other
[06:35:15 CET] <zash> did you just solve the scheduling problem with economics?
[06:37:58 CET] <zash> please mr kernel, would you lend me some money so I can feed my starving children?
[06:41:28 CET] <Inge-> Insert Coin
[07:41:04 CET] Action: blap invents the coin-operated cellphone
[08:42:02 CET] <Jaxx_> hey, I need some tips how to use apple's aac_at audio codec from coreaudio on windows. I have itunes installed, latest static build of ffmpeg from its site and I get "Unknown encoder 'aac_at'" message when try to call it
[08:44:53 CET] <teratorn> Jaxx_: your build wasn't built with that codec enabled
[08:47:26 CET] <Jaxx_> tetratorn : hmm do you mean ffmpeg form https://ffmpeg.zeranoe.com/builds/ is compiled without it?
[08:48:14 CET] <Jaxx_> sad news, thanks for info
[08:58:20 CET] <furq> Jaxx_: you can't use the audiotoolbox codecs on windows
[09:03:56 CET] <Jaxx_> furq: meanwhile i found this, but im not into compiling https://github.com/dantmnf/AudioToolboxWrapper
[09:46:43 CET] <minru> Hello, Could someone give me a suggestion. I have a very unstable UDP source, there is a lot of lost packets.. Is it possible somehow to generate null packets in place of lost packets? For example if there is no input, to generate a blank screen with silence. Or if the audio is missing the just output the video with silence, if the video is missing then just output blank screen with audio. What
[09:46:44 CET] <minru> I get now, ffmpeg just stops encoding when one of streams (audio or video) is missing and waits for an input...
[09:49:21 CET] <JEEB> minru: yes, unless you set a timeout it will keep waiting for the UDP socket to get something. if you were making an API client you could do a whole load of stuff, but with ffmpeg.c you're rather limited
[09:55:41 CET] <minru> JEEB: so with standard ffmpeg.c is it impossible?
[09:59:41 CET] <JEEB> pretty much
[09:59:51 CET] <JEEB> I mean it's a very specific tool :P
[10:01:09 CET] <JEEB> although on the other hand it has the issue of so many people extending it for various things, which means that people will try to use it for various things :P
[10:05:01 CET] <minru> Thank You JEEB, so I guess the only way to get it working is to look into the code... :). Cuz with ffmpeg.c the video/audio sync is always lost later or sooner when UDP source is unstable
[10:05:18 CET] <zash> Does it speak RTP or somesuch?
[10:06:01 CET] <minru> udp multicast
[10:06:04 CET] <JEEB> you basically have to have an API client which uses async UDP input, and you have to have some time zone within which if you didn't get your input you will have to grab an empty AVFrame and feed that ot the encoder (you have an API for this)
[10:06:24 CET] <JEEB> so most likely you cannot use the UDP input from lavf since libavformat abstracts that a lot from you
[10:06:41 CET] <JEEB> you can then use libavformat on the UDP packets you got (MPEG-TS or whatever) of course
[10:07:02 CET] <JEEB> it's an interesting problem to handle and possible with your own application
[10:08:23 CET] <minru> yes MPEG-TS.. All professional encoders/transcoders inserts empty frames when an input is missing
[10:10:28 CET] <JEEB> so you have to decide when you're "too late"
[10:10:51 CET] <JEEB> but yea, ffmpeg.c was not made for such fancy things :)
[10:10:59 CET] <JEEB> it just blocks until it gets more packets
[10:13:20 CET] <minru> I had a hope that ffmpeg.c can do this, but you have broken it like a glass to the wall :D
[10:14:16 CET] <JEEB> you can get very far with ffmpeg.c, which is the scary part :P
[10:14:30 CET] <JEEB> because then you hit the wall and you've already made a PoC or so with ffmpeg.c
[10:15:21 CET] <JEEB> that's why I generally tend to recommend people to /really/ not try to depend on ffmpeg.c too much
[10:15:29 CET] <JEEB> not that it's bad
[10:15:44 CET] <JEEB> it's that its design limitations start hitting you at some point :D
[10:16:12 CET] <zash> this sounds vaguely relevant for my messing with gc visualization
[10:18:33 CET] <JEEB> with MPEG-TS the "fun part" is that the demuxer gives you the timestamps right out of the stream :D which is nice for someone who wants to replicate input timestamps, but YOOOOOOOO for most users
[10:18:39 CET] <JEEB> and as you know
[10:18:46 CET] <JEEB> MPEG-TS timestamps not only roll over
[10:18:53 CET] <JEEB> they can go forwards and backwards pretty much freely
[10:18:55 CET] <JEEB> like a troll
[10:22:31 CET] <minru> :D yea exactly
[13:28:22 CET] <blap> MantisTek GK2 Mechanical Keyboard Comes with Free Keylogger
[14:00:57 CET] <Nacht> Anyone has an idea why I get a difference in clip length between the output at the end of ffmpeg vs ffprobe on the same file ?
[14:01:23 CET] <Nacht> rame=  900 fps=0.0 q=-1.0 Lsize=   10236kB time=00:00:36.02 bitrate=2327.3kbits/s speed= 255x   --- vs --- Duration: 00:00:36.05, start: 0.000000, bitrate: 2326 kb/s
[14:01:59 CET] <BtbN> ffprobe will probably just make an educated guess, while ffmpeg after having processed the entire file knows the exact time
[14:05:22 CET] <Nacht> ok, so ffmpeg is the reliable one in this case
[14:28:14 CET] <dreamp> Hi there, how are you? Is it possible to use the same 1st pass log file to generate n different renditions (with different resolutions)? Or should I always generate a 1st pass for my target transcoding ?
[14:29:07 CET] <dreamp> Intuitively I think we always need to generate 1st pass for each and every target rendition we'd work.
[14:29:36 CET] <dreamp> * possible / feasible / right
[14:29:57 CET] <dreamp> am I right?
[14:30:25 CET] <sfan5> you will always want a different 1st pass log for each res as scaling does change encoding decisions considerably
[14:30:45 CET] <sfan5> so yes
[14:32:49 CET] <dreamp> Thank you very much sfan5 :)
[14:33:11 CET] <dreamp> This IRC and ffmpeg community is so great, people like are so friendly and helpful.
[16:32:31 CET] <thebombzen> is there a way to make ffmpeg.c's status output less human readable but more easily parsed by a parser?
[16:32:42 CET] <thebombzen> I'm referring to the time= stuff
[16:33:49 CET] <dreamp> -v debug
[16:34:32 CET] <thebombzen> dreamp: that doesn't change the format of the status line
[16:38:47 CET] <devinheitmueller> thebombzen: at least for ffprobe, you can output in a variety of formats, including JSON and XML, IIRC.
[16:38:59 CET] <thebombzen> I'm aware of that
[16:39:06 CET] <devinheitmueller> thebombzen: ok.
[16:39:12 CET] <thebombzen> I was specifically referring to the status line of ffmpeg.c's conversion
[16:39:40 CET] <thebombzen> I'm using ffmpeg's CLI rather than linking to the libraries because I'm not writing in a native language and bindings to libavcodec from python etc. go out of date quickly
[16:40:00 CET] <thebombzen> I'm trying to use the time= parameter to display a % complete on my application's UI
[16:40:53 CET] <thebombzen> parsing the status line is a pain and I've written a parser for it but I'm worried it's subject to breakage with minor status-line changes because it's intended to be human-readable, not robot-parseable
[16:43:31 CET] <dreamp> my bad thebombzen
[16:43:56 CET] <JEEB> yea, I don't think there's any mode that is machine readable
[16:44:13 CET] <JEEB> although I'm not sure what commands there are in the file descriptor input mode
[16:44:19 CET] <JEEB> if you can get that info from that
[16:44:44 CET] <JEEB> also I think at some point I looked into generation of python mappings for libav* and I think I even succeeded
[16:45:05 CET] <JEEB> you will always have to have a "build" step for your thing then, but I think that's much better than doing manual corrections to the mapping layer anyways :P
[16:47:51 CET] <thebombzen> I'm writing a cross-platform GUI thing that uses ffmpeg internally. I'm packaging binaries of ffmpeg.c for macOS and Windows but I'm expecting Linux users to deal with that themselves (it checks PATH)
[16:48:56 CET] <JEEB> ok
[16:48:58 CET] <thebombzen> so because of that it's going to be iffy if that line ever changes
[16:49:06 CET] <JEEB> you might want to look into the commands you can give ffmpeg.c
[16:49:17 CET] <JEEB> you can also do stuff like raise/lower the verbosity
[16:49:26 CET] <JEEB> but it might also give you stuff like the current position
[16:49:29 CET] <thebombzen> I'm unfamiliar with those. how do you pass commands to ffmpeg.c at runtime?
[16:50:03 CET] <JEEB> I think it's either through the terminal or something else, not fully sure
[16:50:15 CET] <JEEB> you mostly notice it if you have ffmpeg.c running and press, say, +/-
[16:51:08 CET] <JEEB> I haven't really used those interfaces myself, but I guess they *might* be useful
[16:51:38 CET] <thebombzen> I was under the impression they just read stdin
[16:51:50 CET] <JEEB> that could be it
[16:51:55 CET] <thebombzen> because I don't think pressing "q" works when reading from a pipe
[16:51:56 CET] <JEEB> I just don't remember :P
[16:52:17 CET] <JEEB> also signals might be another way
[16:53:18 CET] <thebombzen> cat /dev/zero | ffmpeg -f rawvideo -video_size nhd -i pipe: -f rawvideo -y /dev/null
[16:53:23 CET] <thebombzen> this doesn't respond to 'q'
[16:53:27 CET] <thebombzen> it does respond to ^C though
[17:00:24 CET] <durandal_1707> thats normal behavior
[17:10:37 CET] <pomaranc> thebombzen: how could it since it reads input from /dev/zero
[17:11:07 CET] <pomaranc> thebombzen: ^C is a signal so that works anyway
[17:11:20 CET] <thebombzen> this is what I expected yes
[17:11:39 CET] <thebombzen> I was just doublechecking to confirm to JEEB that it did indeed behave this way
[17:12:16 CET] <pomaranc> sorry, I've should read the scrollback
[17:16:25 CET] <pgorley> thebombzen: is compiling ffmpeg with a custom av_log callback an option?
[17:16:40 CET] <thebombzen> not practical
[17:16:48 CET] <thebombzen>  <thebombzen> I'm writing a cross-platform GUI thing that uses ffmpeg internally. I'm packaging binaries of ffmpeg.c for macOS and Windows but I'm expecting Linux users to deal with that themselves (it checks PATH)
[17:16:59 CET] <thebombzen> so I have to support upstream
[17:17:36 CET] <pgorley> wait, that wouldn't work, as it doesn't change what's printed :/
[17:38:51 CET] <kepstin> at least on linux, you have the option of piping input on an fd other than stdin (you can give an fd number to pipe: or open /dev/fd/N as a file)
[17:39:00 CET] <kepstin> then you can still use stdin for commands if you like
[19:41:53 CET] <kiroma> Is AV_PIX_FMT_VDA_VLD deprecated?
[19:44:48 CET] <BtbN> I think all the _VLD ones are, but not sure
[19:45:33 CET] <kiroma> I can't compile obs-studio, gcc throws an undeclared error.
[19:47:14 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/commit/2b320318273b74df6e1b712fb33544d6a1b26be1#diff-86e3336f7f2a0c615e9e7b173b277585
[19:47:40 CET] <kiroma> Thanks
[19:47:43 CET] <BtbN> master is doing a major bump right now, and is dropping deprecated stuff
[19:48:13 CET] <BtbN> Apple removed VDA long ago, so it's nothing too terrible or surprising
[19:48:27 CET] <kiroma> I'll report it to the people at obs.
[19:49:11 CET] <BtbN> I'm a bit surprised that commit did not bump at least the micro version
[19:49:19 CET] <kiroma> Looks like it already started to affect people.
[20:49:56 CET] <godofgrunts> I'm trying to find the exact number of frames in a video. Documentation (https://ffmpeg.org/ffprobe.html) seems to suggest that I should use ffprobe -count_frames and that will "Count the number of frames per stream and report it in the corresponding stream section". However, that doesn't appear to be any different than what shows up normally when I do ffprobe input.mp4
[20:51:32 CET] <durandal_1707> godofgrunts: because it may not be available always
[20:51:44 CET] <godofgrunts> If I do ffprobe -show_streams, one of the entries is nb_frames which is what I think I want, but when I try to parse it with ffprobe -v error -show_entries format=nb_frames it doesn't show anything
[20:52:05 CET] <godofgrunts> durandal_1707: Is nb_frames not what I want?
[20:52:29 CET] <durandal_1707> nb frames is what you want
[20:53:30 CET] <godofgrunts> Okay so I'm trying to write a script that will give me this data for a bunch of files. How can I pro grammatically get ffprobe to tell me what I need? I know I can use grep to find it, but I rather not if ffprobe can do it for me
[20:53:57 CET] <godofgrunts> Like ffprobe -v error -show_entries format=size -of default=noprint_wrappers=1 is exactly what I want, but for nb_frames
[20:54:56 CET] <godofgrunts> But ffprobe -v error -show_entries format=nb_frames -of default=noprint_wrappers=1 returns nothing
[20:56:00 CET] <durandal_1707> you probabbly did some kind of mistake
[20:56:28 CET] <godofgrunts> Does it work on your build?
[20:56:37 CET] <kepstin> nb_frames is in stream, not format. So you need to do -show_entries stream=nb_frames
[20:57:45 CET] <godofgrunts> kepstin: that worked. I'm dumb lol
[20:58:37 CET] <kepstin> note that nb_frames will return "N/A" for containers which don't store the number of frames in a header somewhere.
[20:59:00 CET] <godofgrunts> kepstin: yeah I was getting that with my mkv files, it does work with my mp4 files
[20:59:16 CET] <kepstin> in that case, you'll need to use the "-count_frames" option, and look at the nb_read_frames field instead
[20:59:25 CET] <kepstin> it'll be a fair bit slower :)
[20:59:53 CET] <godofgrunts> So how do I use count_frames correctly? I was trying to as an alternative but it doesn't return anything
[21:00:20 CET] <godofgrunts> ffprobe -count_frames input.mkv doesn't seem to be any different than ffprobe input.mkv
[21:00:52 CET] <kepstin> godofgrunts: look up to my message 2 lines above?
[21:01:55 CET] <godofgrunts> Yeah but I don't see nb_read_frames is what I mean
[21:02:44 CET] <kepstin> nb_read_frames in the stream section should be N/A without -count_frames, and filled in with a value with -count_frames
[21:04:25 CET] <godofgrunts> Okay well that isn't working for me then. Performing ffprobe -count_frames input.mkv and then running ffprobe -v error -show_entries stream=nb_read_frames input.mkv returns nb_read_frames=N/A still
[21:05:39 CET] <godofgrunts> oh wait
[21:05:52 CET] <godofgrunts> do I need to do ffprobe -v error -count_frames -show_entries stream=nb_read_frames
[21:06:13 CET] <godofgrunts> That did work
[21:06:20 CET] <godofgrunts> kepstin: Thanks for all the help
[21:07:25 CET] <godofgrunts> Last question, can I specify which stream it's looking at?
[21:13:45 CET] <kepstin> godofgrunts: sure, use the -select_streams option, helpfully described in the manual.
[21:15:19 CET] <godofgrunts> Awesome thank you
[21:42:45 CET] <Mick> hey, i have 2 video files, one of them has high quality video but wrong audio(different language), the other has terrible video quality but the right audio stream
[21:43:17 CET] <Mick> im trying to make out something half decent, but when i tried it the audio and video got out of sync
[21:43:35 CET] <Mick> is there any way to "stretch" the audio to match the video?
[21:44:10 CET] <Mick> the original audio file was Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s (default)
[21:44:36 CET] <Mick> the new audio is Audio: mp3, 48000 Hz, stereo, s16p, 128 kb/s
[21:46:17 CET] <sfan5> both audio tracks are of roughly same duration?
[21:46:35 CET] <Mick> somewhat... the original is slightly longer
[21:46:51 CET] <Mick> the original is 01:25:56.99
[21:47:02 CET] <Mick> the other one is 01:22:30.12
[21:47:40 CET] <Mick> i think that they should fit if i stretch them... the videos dont have any extra parts in the begining or end
[21:51:43 CET] <alexpigment> Mick: I'm going to guess that one of the videos is 25fps and one is 24fps (or 23.976), right?
[21:52:14 CET] <Mick> yeah alexpigment, i think thats accurate
[21:52:16 CET] <furq> yeah the short one looks like a pal conversion
[21:52:28 CET] <furq> !filter atempo @Mick
[21:52:28 CET] <nfobot> Mick: http://ffmpeg.org/ffmpeg-filters.html#atempo
[21:52:49 CET] <alexpigment> yeah, PAL often doesn't do a pulldown to convert 24 to 25; instead, they change the frame rate and speed up the audio
[21:52:58 CET] <furq> -af atempo=(25025/24000)
[21:53:02 CET] <alexpigment> a weird tradeoff, but I can kinda see the point
[21:53:03 CET] <furq> or the other way round depending on which is the good file
[21:53:25 CET] <alexpigment> furq: out of curiosity, why 25025?
[21:53:47 CET] <furq> because that's the same as 25/(24000/1001)
[21:54:06 CET] <furq> 25 * 1001 / 24000
[21:54:11 CET] <alexpigment> ah, just taking the imperfection out of 23.976
[21:54:17 CET] <furq> yeah
[21:54:42 CET] <furq> Mick: 25025/24000 to speed up, 24000/25025 to slow down
[21:54:47 CET] <alexpigment> well, i guess on that note, it's best to make sure that the other file is actually 24000/1001 or if it's 24fps exactly. pretty rare, but worth looking at
[21:54:52 CET] <furq> or just 25000 if it's actually 24fps
[21:54:53 CET] <furq> yeah what he said
[21:55:18 CET] <Mick> hm... so it would be something like  ffmpeg -i goodvideo.mkv -i goodaudio.avi -map 0:0 -map 1:1 -af atempo=(25025/24000) out.mkv
[21:55:23 CET] <Mick> something like that?
[21:55:27 CET] <furq> something like that yeah
[21:55:39 CET] <JOJOJ> who can help me with stream rtsp pleaes?
[21:55:43 CET] <furq> there's also librubberband which does higher quality timestretching
[21:55:46 CET] <furq> but most ffmpeg builds don't have it
[21:56:25 CET] <Mick> hm
[21:56:57 CET] <JOJOJ> I want to stream rtsp like h264 but when i run it I got error
[21:57:30 CET] <JOJOJ> I run this ffmpeg -i input.mp4 http://x.x.x.x:8090/out.h264  and get error stream ends prematurely al 0 should be
[21:59:13 CET] <buhman> when I try to encode vp9 on "ffmpeg version 3.4" I get: Stream #0:0: Video: vp9 (Profile 1), gbrp(pc, gbr/unknown/unknown, progressive), 571x163, SAR 1:1 DAR 571:163, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default)
[21:59:34 CET] <buhman> when I do the same arguments on libav: Stream #0:0: Video: vp9 (Profile 0), yuv420p(tv), 571x163, SAR 1:1 DAR 571:163, 29.97 fps, 29.97 tbr, 1k tbn, 1k tbc (default)
[21:59:55 CET] <buhman> the former stream is either played with a green tint (chrome) or not at all (firefox)
[22:00:13 CET] <furq> buhman: add -pix_fmt yuv420p
[22:00:59 CET] <buhman> hmm, shouldn't that be default if that's required?
[22:01:13 CET] <furq> it's not required
[22:01:31 CET] <JOJOJ> furq  can you pleaes help me?
[22:01:36 CET] <furq> the source is rgb, the encoder supports rgb, so ffmpeg doesn't convert unless you ask it to
[22:01:50 CET] <furq> JOJOJ: i've never streamed rtsp with ffmpeg
[22:02:00 CET] <JOJOJ> ok can i ask another ?
[22:02:02 CET] <buhman> so chrome and firefox just don't implement rgb/
[22:02:20 CET] <furq> buhman: apparently not
[22:02:27 CET] <JOJOJ> furq: do you stream mjpg with ffmpeg ?
[22:02:32 CET] <furq> nope
[22:02:39 CET] <alexpigment> buhman: yuv420p is kinda the only safe bet with video, browsers or otherwise
[22:03:03 CET] <DHE> a lot of hardware decoders (eg: TV media players) also only accept yuv420
[22:03:16 CET] <Mick> furq: nope, its out of sync :(
[22:04:05 CET] <furq> do the durations match nwo
[22:04:06 CET] <furq> now
[22:05:02 CET] <Mick> no, they dont
[22:05:09 CET] <Mick> the audio cuts too early
[22:05:22 CET] <JOJOJ> Misk , do you stream with ffmpeg?
[22:05:35 CET] <Mick> what you mean stream?
[22:05:40 CET] <furq> you can add adelay if it's a constant offset
[22:05:46 CET] <furq> !filter adelay @Mick
[22:05:46 CET] <nfobot> Mick: http://ffmpeg.org/ffmpeg-filters.html#adelay
[22:05:53 CET] <Mick> no theres no delay
[22:06:07 CET] <Mick> it starts fine, but gets worse with time
[22:06:09 CET] <furq> oh
[22:06:11 CET] <alexpigment> Mick: maybe you should just demux the good audio track and the good video track, then convert the audio until the lenghts of the two elementary streams match
[22:06:15 CET] <JOJOJ> Mick:  use with ffserver to send a video to client
[22:06:29 CET] <furq> yeah there's not much you can do other than atempo
[22:06:45 CET] <buhman> furq: thanks!
[22:06:46 CET] <furq> i guess just play around with the parameters
[22:06:48 CET] <Mick> JOJOJ: no, im not streaming anything
[22:07:40 CET] <Mick> maybe i did the division incorrectly
[22:07:46 CET] <Mick> and it should maybe be other way around
[22:17:53 CET] <fds_> what can i do to fix File for preset 'baseline' not found File for preset 'default' not found when i run ffserver
[22:39:43 CET] <leech> is there a way to force ffmpeg to keep bitrate the same when encoding? let's say I want to mass apply a filter to a bunch of files, is there a way to re-encode them but keeping the previous bitrate?
[22:40:02 CET] <leech> I can't possibly check the bitrate for each file and set it manually
[22:43:25 CET] <BtbN> the previous bitrate is meaningless
[22:43:55 CET] <BtbN> It could be encoded with a diffrent encoder, at another preset, or various other things that influence filesize/quality
[22:45:55 CET] <leech> these are files I made using only c:v and b:v without presets
[22:46:12 CET] <leech> simply leaving the bitrate out of the command make horrible quality results
[22:46:57 CET] <leech> instead by specifying a bitrate I can roughly keep same quality
[22:47:02 CET] <BtbN> The default for libx264 is crf mode. The quality should be ok.
[22:48:09 CET] <leech> I'll try experiencing with crf values and see what value has the bast quality/size
[22:48:15 CET] <leech> thanks
[22:49:42 CET] <kiroma> For reference I find that crf 24 on preset fast is roughly equal to YouTube's quality.
[22:51:58 CET] <BtbN> youtubes quality is horrible though
[22:52:21 CET] <leech> looks like crf is useless if I don't use it with b:v
[22:52:31 CET] <leech> at least this is the case for libvpx
[22:53:45 CET] <kiroma> For libvpx it's specified in documentation that in order to use crf you need to set explicictly -b:v 0.
[22:54:34 CET] <kiroma> And yes, the quality is awful but well known, hence why I used it as a comparasion point.
[22:56:12 CET] <leech> oh it worked. thanks for the b:v tip
[22:56:13 CET] <alexpigment> for what it's worth -b:v is actually a little more useful with libvpx
[22:56:18 CET] <alexpigment> -b:v 0 is no limit
[22:56:24 CET] <leech> the final result is like 400kb when the source is 600
[22:56:34 CET] <alexpigment> -b:v 20M means it's supposed to limit at 20mbps
[23:00:48 CET] <leech> using -crf 5 gives me the result that most-likely match the previous file size
[23:01:25 CET] <kiroma> crf 12 should be visually lossless, crf 5 is a bit of an overkill.
[23:02:20 CET] <kiroma> Oh and thanks for the clarification alex
[23:02:54 CET] <alexpigment> no problem. setting the -b:v to something prevents you from getting ridiculous file sizes if you're specifying a high CRF (like 5 :))
[23:03:43 CET] <leech> well I was looking for roughly same file size but this is just because I don't know how filesize works and how much it affects quality so I just assumed that an output file of the same size would be the best
[23:04:25 CET] <leech> well my -crf 5 made a 629kb file when the source was 614kb
[23:04:28 CET] <alexpigment> leech: well, I can tell you that it's complicated enough that there is no way to specify a CRF that will give you the same file size as the source :)
[23:04:28 CET] <leech> it's not that bad
[23:05:22 CET] <alexpigment> if the source is detailed enough and compressed sufficiently to begin with, crf 5 will make the final file size bigger in most cases
[23:06:13 CET] <leech> does vf affect the audio codec?
[23:06:37 CET] <kiroma> No, it functions like an alias to -filter:video
[23:06:46 CET] <kiroma> *-filter:v sorry
[23:07:07 CET] <alexpigment> -af is for audio
[23:07:07 CET] <leech> so I can technically use whatever source no matter if it has audio streams right?
[23:07:31 CET] <kiroma> Yes.
[23:08:46 CET] <leech> if I don't specify a c:a what does ffmpeg do with the audio and its bitrate?
[23:08:53 CET] <leech> does it simply put c:a copy?
[23:09:09 CET] <alexpigment> it uses a default codec from what i recall
[23:09:15 CET] <kiroma> No, it uses a codec that's default for the file you're using.
[23:09:16 CET] <alexpigment> it's because to use -c:a copy if that's what you want to do
[23:09:56 CET] <kiroma> i.e. if you're using a .webm extension (-f webm), it will use by default libopus.
[23:10:07 CET] <kiroma> Regardless of input codec.
[23:10:08 CET] <leech> I want to alter the output as less as possible
[23:10:19 CET] <leech> and I may work with files with audio and without audio
[23:11:02 CET] <leech> using c:a and b:a can give me error if the video has no audio stream right?
[23:11:03 CET] <alexpigment> leech, as long as the format/container you're using officially supports the input audio type, and your player/browser supports that configuration as well, use -c:a copy
[23:11:56 CET] <kiroma> No, if the source has no audio stream I'm fairly sure it will just create a silent track at the output.
[23:12:21 CET] <leech> isn't that "bad"?
[23:12:34 CET] <leech> what's the point of a silent audio stream if I can just remove the audio stream
[23:12:34 CET] <alexpigment> actually, i just did a test with this
[23:12:42 CET] <alexpigment> it doesn't create an audio track in my test
[23:12:46 CET] <leech> oh
[23:12:48 CET] <leech> that's neat
[23:12:54 CET] <alexpigment> nor does it fail/warn
[23:12:58 CET] <causasui> I'm trying to write a python script that does a two-pass encode on video files using ffmpeg. But I'm getting an error with my second pass: Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height -- here's the command my script executed: ffmpeg -y -i /media/crypt/incoming/KV155_1.mp4 -pass 2 -passlogfile /tmp/tmpo2nnguwa-0.log -b:v 632K -ss
[23:12:59 CET] <causasui> 00:03:33 -to 00:04:18 -threads 3 -auto-alt -ref 1 -lag-in-frames 0 -crf 10 -f webm -c:v libvpx -speed 1 -c:a libvorbis -b:a 96k /tmp/tmpc5l88grr.webm
[23:13:27 CET] <leech> guess I'll give it a try. thanks for helping me with some tests
[23:13:30 CET] <kiroma> In my case it warns that -b:a hasn't been applied to any stream.
[23:13:43 CET] <leech> a warning it's still better than an error
[23:13:45 CET] <kiroma> But yeah, no stream at the output if the input doesn't have anything as well.
[23:14:34 CET] <kiroma> There's a space in "-auto-alt -ref 1"
[23:14:58 CET] <BtbN> -crf and cbr/two-pass makes no sense, causasui
[23:15:23 CET] <BtbN> I'm also fairly sure libvpx has no notion of crf
[23:15:40 CET] <alexpigment> BtbN: it definitely does, although it's not 100% analogous to x264's CRF
[23:15:43 CET] <causasui> BtbN: I found it on https://trac.ffmpeg.org/wiki/Encode/VP8 but this guide isn't doing 2-pass, true
[23:16:04 CET] <causasui> kiroma: sorry, that was a transcription error (line wrapped there)
[23:16:16 CET] <kiroma> Ah okay, anyways, try https://sites.google.com/a/webmproject.org/wiki/ffmpeg/vp9-encoding-guide
[23:16:22 CET] <BtbN> it seems to just use the name for its cq mode, because x264 compat
[23:16:35 CET] <alexpigment> BtbN: yes, it's a constant quality mode
[23:16:39 CET] <causasui> kiroma: yeah I based it on that page. what I don't understand is why I'm getting this error, since the command seems right
[23:16:51 CET] <alexpigment> in which case, doing a 2 pass with a bitrate isn't a terrible idea i suppose
[23:17:02 CET] <alexpigment> although i still would just do 1 pass
[23:17:16 CET] <BtbN> constant-quality and two-pass at the same time just makes no sense
[23:17:39 CET] <causasui> BtbN: maybe not, but does it explain the error?
[23:17:58 CET] <BtbN> I wouldn't be surprised if it does, yes
[23:17:59 CET] <alexpigment> causasui: one of the parameters is not understood. just eliminate each parameter 1 by 1 until it works
[23:18:19 CET] <BtbN> Telling it to do a second pass while also setting it to CQ mode might confuse it
[23:20:44 CET] <causasui> I'm suspicious it has more to do with parameter ordering... this used to work before I changed some of that logic
[23:21:04 CET] <causasui> but I'm not very good at ffmpeg
[23:21:15 CET] <kiroma> Shouldn't it be "-libvpx-vp9"?
[23:21:39 CET] <BtbN> not for vp8
[23:21:40 CET] <causasui> kiroma: I'm using vp8 because of reasons
[23:22:05 CET] <causasui> I think I fixed it
[23:22:08 CET] <alexpigment> does auto-alt work without an integer?
[23:22:15 CET] <alexpigment> -auto-alt 1 ,etc?
[23:22:44 CET] <causasui> There was actually a problem with the 1st pass command, lul
[23:22:50 CET] <alexpigment> hell, i'll stay out of this. i've never used half of these parameters
[23:22:50 CET] <causasui> it caused the error to manifest in the second pass
[23:24:29 CET] <kiroma> Next time post full command to a pastebin, much more readable that way.
[23:52:16 CET] <Mista_D> Is there any way to output filter's outptut similar to FFprobe's JSON/XML outptut? looking at mpdecimate, cropdetect, ebur128, etc.
[00:00:00 CET] --- Wed Nov  8 2017