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

burek burek021 at gmail.com
Mon Dec 19 03:05:01 EET 2016


[00:02:01 CET] <ThomasEgi> some random windows build from 2011 appears to run, but doesn't feature gdigrab as input
[00:28:39 CET] <ThomasEgi> limited success, version build 2.7.something seems to run on xp and at least outputs sane values for the screencap.
[00:50:31 CET] <furq> building yourself with mingw and copying across should work
[00:50:40 CET] <furq> the reason the zeranoe builds no longer support xp is because of libmfx
[00:51:05 CET] <furq> you have no use for that anyway so it shouldn't be an issue
[01:32:47 CET] <ThomasEgi> furq, i got it working .. somewhat. at least ffmpeg is now the better working part. the application displaying that old thing appears to be very very picky when it comes to switching to fullscreen mode. puzzles me a bit. i'll report back on ultimate failure/success
[01:32:55 CET] <ThomasEgi> thanks for all your shared brain capacities
[01:37:38 CET] <Kam> Hello, I'm trying to decode a VP9 video in yuva420p and get the following error, any ideas? "Failed to decode frame: Corrupt frame detected" -- "Additional information: Keyframe / intra-only frame required to reset decoder state". I'm using the latest git version of libvpx and ffmpeg. The file has been encoded with ffmpeg before and I'm forcing to use libvpx-vp9 for decoding.
[04:04:52 CET] <damdai> how do i playback  hddvd (not bluray)
[08:32:06 CET] <thebombzen_> Kam: It sounds like you have a corrupt file
[08:32:32 CET] <thebombzen_> and that libvpx's vp9 decoder is more forgiving than ffmpeg's vp9 decoder.
[08:57:31 CET] <thebombzen> JEEB: I read that article you wrote on github gist about 10bit H.264
[08:58:16 CET] <thebombzen> I'm still a bit confused how upscaling a yuv420p source to yuv420p10le with swscale before feeding it to x264 can save quality per bitrate.
[08:59:44 CET] <thebombzen> the article explained that losing 3 bits in 10-bit space is the same as losing 1 bit in 8bit space so there's more error tolerance, but why does that matter if we introduced two bits
[09:04:43 CET] <thebombzen> the ateme pdf linked says that it's because of the prediction, but that again is confusing.
[09:07:48 CET] <thebombzen> afaik when you run the DCT to decompose a block into a liner combination of waves, most of the coefficients are zero (that's the point of jpeg-like stuff, right?) but I'm not sure how introducing 2 extra bits per pixel will make the quantization more accurate. like will it make it so we will generally have more zeroes after quanization? does it make it so we can have more zeroes?
[09:07:51 CET] <thebombzen> I'm just a bit confused
[10:39:34 CET] <thebombzen> uh, so there appears to be a problem with VDA autodetection. It says --disable-vda to disable apple's vda [autodetect]
[10:39:49 CET] <kerio> heh
[10:39:56 CET] <thebombzen> but when I try to configure, it says "vda requested but unable to find vda_framework" or something very similar
[10:40:00 CET] <thebombzen> which is weird
[10:40:12 CET] <thebombzen> cause if it can't find vda then it should just autodisable it. that's what autodetect means right
[10:40:18 CET] <thebombzen> for the record, I don't have VDA. I'm on Arch Linux
[10:40:31 CET] <kerio> ...wat
[10:40:32 CET] <thebombzen> that sounds like it's a bug in the configure script
[10:40:54 CET] <kerio> yeah ok
[10:40:59 CET] <thebombzen> ERROR: vda requested, but not all dependencies are satisfied: vda_framework pthreads
[10:41:00 CET] <kerio> it's hardly a showstopper
[10:41:09 CET] <thebombzen> that's the exact error message
[10:41:11 CET] <thebombzen> word for word
[10:41:24 CET] <thebombzen> I mean definitely not a big deal. I just addded --disable-vda and went on my way
[10:41:37 CET] <thebombzen> but it was annoying because I have a script set to git pull and rebuild ffmpeg every day
[10:42:05 CET] <thebombzen> and sometimes it fails for no reason. in this case it failed because I didn't have --disable-vda and it became necessary.
[10:42:09 CET] <thebombzen> which tbh sounds like a regression
[10:42:52 CET] <thebombzen> is this the right place to takl about this or would #ffmpeg-devel be a better one
[10:44:26 CET] <thebombzen> oop, looks like nvidia 375.20 is acting up... again... Dx
[10:44:38 CET] <thebombzen> sometimes it just doesn't want to work and I have to reboot
[10:45:20 CET] <thebombzen> it becomes really obvious when you pull up a video in MPV and it cannot create the opengl context so it defaults to x11, and the tearing is really awful
[14:24:35 CET] <blubee> hi guys i have a quesiton about ffmpeg and recording x11
[14:24:54 CET] <blubee> there's a new xcb screen grab because it says x11grab is legacy
[14:25:19 CET] <blubee> what do i pass to ffmpeg -f instead of x11grab to use the new xcb flag?
[14:27:17 CET] <relaxed> I think it's the default not, see "ffmpeg -devices"
[14:27:29 CET] <relaxed> s/not/now/
[14:29:17 CET] <blubee> hmm
[14:29:31 CET] <blubee> the devices show
[14:29:44 CET] <blubee> bktr, lavfi, oss, v4l2, video4linux2
[14:29:55 CET] <relaxed> I see "D  x11grab         X11 screen capture, using XCB"
[14:30:15 CET] <blubee> hmm
[14:30:16 CET] <blubee> nope
[14:30:32 CET] <blubee> i guess i'll just enable the legacy x11
[14:30:58 CET] <DHE> XCB mode still uses the same name. just keep using x11grab
[14:31:24 CET] <relaxed> did you configure ffmpeg with --enable-x11grab ?
[14:33:33 CET] <blubee> okay
[14:33:42 CET] <blubee> well thanks i'll just configure x11grag
[14:33:45 CET] <blubee> thanks
[14:56:43 CET] <N_ick> Hi there ! i'm  attempting to replace first two audio streams within a MXF File with two WAV audio streams + the ideal would be to keep the existing stream IDs. i've read the documentation and tried for a few hours now but i'm still stuck. I understand i have to use the -map option but can't succed to map only the first two streams and keep the others.
[15:06:30 CET] <ChocolateArmpits> N_ick: Why do you need to keep the others if you don't want that originally?
[15:09:29 CET] <N_ick> the imput .mxf contains one video and 8 audio streams in total. i need to replace the first two. i've tried this : ffmpeg -i input.mxf -i audio1.wav -i audio2.wav -map 0 -map -0:a:0 -map -0:a:1 -map 1:0:1 -map 2:0:2 output.mxf
[15:10:18 CET] <N_ick> but that looks like rubbish and doesn't work. my idea was first to map everything, then to use negative mapping (as suggested in documentation) to exclude the first two streams i want to replace
[15:10:48 CET] <N_ick> do i have to explicitely specify each of the 8 audio streams to keep them in the output file?
[15:11:10 CET] <ChocolateArmpits> N_ick: map 0 will map the entirety of the first input
[15:11:41 CET] <ChocolateArmpits> you need -map 0:v instead of that
[15:12:19 CET] <ChocolateArmpits> Do those wav files contain only one audio stream per file?
[15:12:34 CET] <ChocolateArmpits> then you only need to specify each like this -map 1:a -map 2:a
[15:13:41 CET] <N_ick> yep', that's mono! great, i'll try that, thank's dude. the tricky part is i have to keep the remaining 6 audio streams from the input...
[15:14:25 CET] <ChocolateArmpits> Then don't write -map 0 as I said
[15:14:44 CET] <ChocolateArmpits> because that will pass along every stream from the first input to the output
[15:15:16 CET] <N_ick> well, that's what i want (except the first two audio streams that i need to replace... )
[15:15:33 CET] <ChocolateArmpits> oh then specify each stream separately
[15:16:06 CET] <ChocolateArmpits> so it would be -map 0:v -map 1:a -map 2:a -map 0:a:2 -map 0:a:3 -map 0:a:4 -map 0:a:5
[15:16:28 CET] <ChocolateArmpits> the sequence of maps will determine the stream order in output
[15:16:50 CET] <ChocolateArmpits> though it's possible to tell it via text too
[15:17:01 CET] <N_ick> via text? what do you mean?
[15:18:29 CET] <ChocolateArmpits> well nevermind
[15:18:33 CET] <ChocolateArmpits> just follow the order thing
[15:20:08 CET] <N_ick> okay i'll try. but i'd like to understand because i was afraid of the long -map sequence, Lol. isn't there a 'cleaner' way?
[15:21:50 CET] <ChocolateArmpits> not cleaner and more complex but there are others
[15:23:04 CET] <ChocolateArmpits> like reading streams via filters or via text files with file names and stream indexes
[15:23:21 CET] <ChocolateArmpits> more advanced stuff imo
[15:24:39 CET] <N_ick> sorry, something strange hapened here, i sort of lost my connection -_-
[15:25:13 CET] <N_ick> ChocolateArmpits: okay i'll try. but i'd like to understand what you meant 'via text' because i was afraid of the long -map sequence, Lol. isn't there a 'cleaner' way?
[15:26:42 CET] <ChocolateArmpits> I maybe forgot but I think there was a way to point where a specific map should fit, like should it go to the stream index 1 or 2 you know ,  independent of the placement of the command itself in relation to other map commands
[15:29:34 CET] <N_ick> mh, i see, something like specifying the map order in some text file?
[15:29:46 CET] <ChocolateArmpits> no that's different
[15:30:28 CET] <ChocolateArmpits> you input a text file via a concat formatter, inside the text file are links to files and streams
[15:31:00 CET] <N_ick> okay then, i think i'll have a go with my long -map sequence and see what it does :) tkx.
[15:31:05 CET] <ChocolateArmpits> it's useful when you need to concatenate several files and doing it via command line would be more troublesome
[15:32:08 CET] <Kiicki> 4 hours elapsed and got 30 min too go for a movie -.-
[15:32:36 CET] <N_ick> well, i'm on Windoze writing a batch script so.....
[15:37:12 CET] <N_ick> ChocolateArmpits: think i need more infos on the -map usage : i understand the first number is the file index starting at 0, v for video or a for audio, what's the last number used for? i thought that was the output's stream number but i feel i'm misunderstanding something...
[15:38:11 CET] <ChocolateArmpits> N_ick: when you reference things like this -map 0:a:1 you are telling ffmpeg to look at the second audio stream of the first input
[15:38:40 CET] <N_ick> Ah okay, now i get it, thanks for the refresh ! :D
[15:38:43 CET] <ChocolateArmpits> -map 0:a means all audio streams of the first input
[15:38:53 CET] <yati> Hi, I'm piping video to an avconv process on a *raspberry pi*. This is the avconv command: https://dpaste.de/JWnL Now the video thus produced plays much faster than reality. I measured how fast the source process is able to produce frames, and it is ~9fps. Using -r 8 for the output (with -re for the input) also does not help. What could I be missing? :)
[15:54:42 CET] <yati> ok, just figured the output framerate is somehow set to 25fps, and this is why time is shrunk. How do I make sure the output frame rate is the same as the input frame rate?
[15:55:48 CET] <ChocolateArmpits> yati: by not setting -r at the output of course
[16:04:13 CET] <N_ick> ChocolateArmpits: It works ! :D thanks dude
[16:04:21 CET] <ChocolateArmpits> N_ick: np
[16:05:14 CET] <N_ick> now the best would be to keep the original input stream id's, should i use -map_metadata for that?
[16:05:20 CET] <N_ick> or specify them 'by hand'?
[16:09:05 CET] <ChocolateArmpits> i'm not sure about that, sorry
[16:48:09 CET] <yati> ChocolateArmpits: Tried that (not keeping -r at the output, also removing -r from both input and output). The fps is still 25 :(
[16:48:54 CET] <ChocolateArmpits> yati: so you want the file framerate to be that of the actual source ?
[16:49:04 CET] <ChocolateArmpits> Try the fps filter
[16:49:13 CET] <ChocolateArmpits> -vf fps=8
[16:50:00 CET] <ChocolateArmpits> it'll drop/duplicate frames to match the number you request
[16:51:21 CET] <yati> ChocolateArmpits: Yes, I want it to be the same (or about the same, since the source drops frames sometimes). Trying the filter nw
[16:58:14 CET] <yati> ChocolateArmpits: No luck. Here's the incantation: https://dpaste.de/8PrL (I first using another -vf, but that got rid of the timestamps, so added it in the chain after drawtext, is that how it's supposed to be done?)
[16:58:27 CET] <yati> *I first tried using...
[16:59:00 CET] <N_ick> Does anyone know if preserving Track IDs from input to output is ever possible?
[17:01:26 CET] <ChocolateArmpits> yati: yeah, but that will draw the timestamps before dropping frames, so you should probably have fps happen first
[17:07:02 CET] <yati> ChocolateArmpits: Heh, tried that too. It still produces a 25 fps video. I tried this on my Fedora box with a v4l2 (/dev/video0 as the source) and it does work. I am tempted to try getting video4linux2 on the pi and try, but exactly what is wrong with the current approach is the interesting question :D
[17:07:47 CET] <ChocolateArmpits> yati: What do you mean works? the command line ?
[17:08:14 CET] <yati> ChocolateArmpits: yep. works == produces 8fps vid from the /dev/video0 input
[17:08:32 CET] <yati> the same command line, (of course s/avconv/ffmpeg/ on fedora)
[17:34:35 CET] <taliptako> Heyyyy
[17:34:44 CET] <taliptako> can i use ffmpeg for MPEG DASH encoding
[18:24:27 CET] <Kuun-Lann> Hello guys, i try to convert some .al files to .mp3 (or .flac). I try the simplest way with ffmpeg -i file.al file.mp3 but the sound is just awful. Any idea of options to get a decent sound ?
[18:27:40 CET] <thebombzen> Kuun-Lann: you should set the bitrate with -b:a bitrate
[18:27:53 CET] <thebombzen> such as ffmpeg -i input -b:a 128k output.mp3
[18:28:02 CET] <Kuun-Lann> okay i see
[18:28:08 CET] <thebombzen> the default bitrate is very low
[18:28:23 CET] <kerio> 128k is also very very very low for mp3
[18:28:28 CET] <thebombzen> it is
[18:28:34 CET] <thebombzen> but it depends on the source
[18:28:39 CET] <Kuun-Lann> so i could try -b:a 320 ?
[18:28:41 CET] <Kuun-Lann> at least
[18:28:42 CET] <thebombzen> 320k
[18:28:43 CET] <kerio> -q:a 0
[18:28:46 CET] <thebombzen> 320 is 320 by itself
[18:28:51 CET] <thebombzen> 320k is 320 thousand
[18:28:57 CET] <Kuun-Lann> okay
[18:29:01 CET] <kerio> it's 2016, use VBR
[18:29:05 CET] <thebombzen> that works too. to be honest I don't see any reason to use mp3
[18:29:07 CET] <Kuun-Lann> kerio what is -q:a 0 ?
[18:29:20 CET] <thebombzen> constant quality
[18:29:28 CET] <Kuun-Lann> (sorry for the noobish question, first time i use fmmpeg this wayà
[18:29:33 CET] <Kuun-Lann> oh ok
[18:29:43 CET] <thebombzen> it's fine. -q is quality and 0 is the quality setting
[18:29:54 CET] <thebombzen> usually lower numbers are higher quality which is counterintuitive at first
[18:30:06 CET] <kerio> with lame, vbr with quality 0 is pretty damn good
[18:30:12 CET] <kerio> ...for a shit codec like mp3, at least
[18:30:16 CET] <thebombzen> I still don't know why you'd be using mp3
[18:30:22 CET] <Kuun-Lann> errr
[18:30:41 CET] <thebombzen> mp3 is extremely old and primitive
[18:30:44 CET] <thebombzen> like early 90s old
[18:31:04 CET] <Kuun-Lann> so .. flac ?
[18:31:08 CET] <Kuun-Lann> is it better ?
[18:31:10 CET] <thebombzen> well flac is literally lossless
[18:31:24 CET] <thebombzen> so yes the audio will be identical to the input
[18:31:30 CET] <Kuun-Lann> that sound great to me
[18:31:35 CET] <thebombzen> but lossless audio is large (although nowadays it's not unmanageably large)
[18:31:41 CET] <thebombzen> flac = Free Lossless Audio Codec
[18:31:56 CET] <thebombzen> uncompressed audio is around 1500k
[18:32:20 CET] <thebombzen> but depending on the source, I've seen flac achieve between 400k and 1100k
[18:32:33 CET] <Kuun-Lann> and what i need to input in -b:a for convert in flac ?
[18:32:37 CET] <thebombzen> nothing
[18:32:42 CET] <thebombzen> it's lossless so don't set the bitrate
[18:32:54 CET] <thebombzen> that one if you're trying to be simple you can just do ffmpeg -i input output.flac
[18:33:04 CET] <kerio> i wonder if there's a compression setting tho
[18:33:08 CET] <thebombzen> there is
[18:33:11 CET] <thebombzen> but one step at a time
[18:33:12 CET] <kerio> trading longer encoding/decoding for space
[18:33:18 CET] <thebombzen> there is definitely
[18:33:20 CET] <thebombzen> but the default is fine
[18:33:25 CET] <kerio> fair enough
[18:33:26 CET] <Kuun-Lann> i'll try for flac
[18:33:34 CET] <thebombzen> and the gains/losses are not noticable unless you set it to the fastest
[18:33:35 CET] <Kuun-Lann> hum
[18:33:37 CET] <kerio> Kuun-Lann: if you're used to mp3, flac is going to feel insanely big
[18:33:38 CET] <Kuun-Lann> i got an error at the end
[18:33:44 CET] <thebombzen> what error?
[18:33:48 CET] <Kuun-Lann> draam1.al: Input/output error
[18:33:48 CET] <Kuun-Lann> size=   24411kB time=00:32:40.16 bitrate= 102.0kbits/s speed= 124x
[18:33:48 CET] <Kuun-Lann> video:0kB audio:24403kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.033168%
[18:33:53 CET] <thebombzen> that's not an error
[18:33:55 CET] <thebombzen> oh
[18:33:57 CET] <thebombzen> input/output error
[18:34:02 CET] <Kuun-Lann> ? :/
[18:34:02 CET] <thebombzen> that means it couldn't read your input file
[18:34:07 CET] <Kuun-Lann> oO
[18:34:10 CET] <Kuun-Lann> oh
[18:34:17 CET] <thebombzen> becaues it's corrupt or you deleted it or something
[18:34:17 CET] <Kuun-Lann> weird
[18:34:30 CET] <thebombzen> although if it's corrupt it probably wouldn't say that
[18:35:14 CET] <furq> pcm_alaw to flac should be pretty small
[18:35:24 CET] <thebombzen> I mean in general yea
[18:35:32 CET] <thebombzen> but again it depends on what you have as the source
[18:35:33 CET] <kerio> furq pls
[18:35:40 CET] <thebombzen> if it's speech it'll be small
[18:35:44 CET] <thebombzen> if it's metal music it won't be
[18:36:45 CET] <thebombzen> speaking of converting
[18:36:51 CET] <Kuun-Lann> weird i try with anoter file but same error
[18:36:55 CET] <thebombzen> Kuun-Lann: is there any particular reason you need to convert it
[18:37:05 CET] <Kuun-Lann> thebombzen yes indeed
[18:37:13 CET] <thebombzen> what is that reason
[18:37:36 CET] <kerio> what's .al anyway?
[18:37:48 CET] <Kuun-Lann> in fact, my .al files comes from a game. This is the soundtrack of this game. And i want to listen it. But the files are in .al files and i didn't find the origginal soundtrack on steam or on game's editor website
[18:37:59 CET] <kerio> Kuun-Lann: first step, ffprobe
[18:37:59 CET] <Kuun-Lann> :/
[18:38:08 CET] <kerio> figure out what ffmpeg thinks is inside the files
[18:38:16 CET] <thebombzen> Kuun-Lann: ffprobe input_file
[18:38:21 CET] <thebombzen> it'll spit out info on the file
[18:38:32 CET] <thebombzen> second of all, if ffmpeg can read it, you can play it with mpv
[18:38:51 CET] <Kuun-Lann> https://zerobin.net/?59683b335583f56f#QuhpEBg+kP1RbrZAwSnBJIf5bECNLiwrswKX95yZoHQ=
[18:38:56 CET] <Kuun-Lann> result of ffprobe
[18:39:34 CET] <thebombzen> sounds like the file has the wrong extension ^_^
[18:39:38 CET] <Kuun-Lann> oO
[18:39:40 CET] <Kuun-Lann> really ?
[18:39:44 CET] <Kuun-Lann> wow
[18:39:57 CET] <kerio> no it doesn't
[18:40:04 CET] <Kuun-Lann> but what is the good extension in this case ?
[18:40:09 CET] <thebombzen> it doesn't? hm
[18:40:17 CET] <kerio> according to https://www.reddit.com/r/Dominions4/comments/45lmxn/dominions_music/czypen6/
[18:40:18 CET] <thebombzen> I'm wrong then. TIL the correct extension for gsm audio
[18:40:31 CET] <kerio> it's a-law
[18:40:44 CET] <thebombzen> either way you can play it with mpv
[18:40:48 CET] <furq> 17:35:14 ( furq) pcm_alaw to flac should be pretty small
[18:40:49 CET] <furq> ahem
[18:40:51 CET] <thebombzen> you don't need to convert it first
[18:40:51 CET] <kerio> furq pls
[18:40:52 CET] <Kuun-Lann> kerio : exactly this is the sondtrack from dominion xD
[18:40:59 CET] <thebombzen> or you can play it with ffplay too
[18:41:03 CET] <kerio> furq: ffprobe is misguessing tho
[18:41:05 CET] <thebombzen> ffplay input_file
[18:41:13 CET] <furq> well it might be the wrong file extension
[18:41:23 CET] <thebombzen> ffplay is a very primitive media player that comes with ffmpeg
[18:41:29 CET] <kerio> nah, "sampled at 22050 Hz"
[18:41:33 CET] <kerio> that ffprobe says 8kHz
[18:41:39 CET] <furq> all bets are off when it comes to games
[18:41:48 CET] <thebombzen> why don't games just like
[18:41:51 CET] <thebombzen> use vorbis or opus audio
[18:41:51 CET] <furq> if it's only intended to be read by one custom player, it could be anything
[18:41:56 CET] <furq> most modern games do
[18:41:59 CET] <thebombzen> okay
[18:42:04 CET] <thebombzen> cause afaik that was the primary thing they did
[18:42:15 CET] <furq> older games are all over the map though
[18:42:20 CET] <thebombzen> speaking of opus
[18:42:27 CET] <furq> old games use just about every obscure pcm format you can imagine
[18:42:28 CET] <thebombzen> how good is libopus compared to libfdk_aac
[18:42:34 CET] <furq> it should be better
[18:42:45 CET] <furq> that multiformat listening test ranks it above apple aac
[18:42:52 CET] <furq> and apple aac is supposed to be the best aac encoder
[18:42:58 CET] <thebombzen> is libopus the best (lossy) audio encoder in libavcodec?
[18:43:03 CET] <furq> i should have thought so
[18:43:18 CET] <thebombzen> is there any reason not to use it as long as the target supports it
[18:43:38 CET] <furq> hardware decode?
[18:43:44 CET] <thebombzen> hm. I guess. but audio is not super relevant there
[18:43:56 CET] <thebombzen> also does opus go inside mp4
[18:43:59 CET] <thebombzen> cause for some reason vorbis does
[18:44:00 CET] <furq> idk how much difference it makes but pretty much every phone has hardware aac decode
[18:44:11 CET] <furq> iirc opus does in theory but doesn't in practice
[18:44:18 CET] <thebombzen> what does that mean
[18:44:19 CET] <c_14> There's a spec, but it's not final yet
[18:44:23 CET] <furq> yeah
[18:44:23 CET] <thebombzen> as in what roadblocks happen
[18:44:26 CET] <thebombzen> ah
[18:44:35 CET] <furq> it is or will soon be part of the spec but nothing supports it yet
[18:44:38 CET] <thebombzen> so it could if someone does the heavy lifting
[18:44:42 CET] <thebombzen> but nobody's fleshed it out yet?
[18:44:47 CET] <furq> and hardware players rarely have fixes backported
[18:45:10 CET] <thebombzen> anothe question (lots of questions)
[18:45:31 CET] <thebombzen> what's the best intermediary format for WIP stuff
[18:45:35 CET] <thebombzen> file format I mean
[18:45:41 CET] <thebombzen> I've been using matroska
[18:45:44 CET] <furq> probably mkv or nut
[18:45:59 CET] <furq> depends what you're loading it into though
[18:46:02 CET] <thebombzen> nut is supposed to hold anything ffmpeg can produce but in my experiences there's stuff that's gone in mkv that's not in nut
[18:46:10 CET] <furq> i imagine a lot of commercial NLEs won't accept either of those
[18:46:10 CET] <thebombzen> feeding it back into lavf
[18:46:24 CET] <furq> i think nut is streamable, if that makes a difference
[18:46:30 CET] <thebombzen> mkv is to if you use -live 1
[18:46:38 CET] <thebombzen> when muxing I mean
[18:46:42 CET] <furq> oh
[18:47:05 CET] <thebombzen> essentially what I'm saying is, I've been using mkv and I havne't had any problems
[18:47:10 CET] <furq> i imagine you'd want to redo it from the start anyway
[18:47:25 CET] <thebombzen> -live 1 is nice if you're dumping a 1 minute thing
[18:47:28 CET] <thebombzen> and you want to preview it
[18:47:37 CET] <kerio> opus doesn't do 44100Hz
[18:47:42 CET] <kerio> which could be an issue
[18:48:02 CET] <furq> i can only imagine that wouldn't be the case if resampling to 48khz was a big deal
[18:48:08 CET] <furq> i'm pretty clueless when it comes to audio though
[18:48:43 CET] <thebombzen> uhhh
[18:48:48 CET] <thebombzen> why does opus not do 44.1 kHz
[18:48:51 CET] <thebombzen> that sounds like a design flaw
[18:48:58 CET] <thebombzen> given that that's what comes off of a CD
[18:49:02 CET] <furq> https://en.wikipedia.org/wiki/Opus_(audio_format)#Sample_rates
[18:49:08 CET] <kerio> the high-res release of supercollider/the butcher by radiohead had one song at 48khz and the other at 44.1khz
[18:49:12 CET] <kerio> :|
[18:49:17 CET] <furq> nice
[18:49:43 CET] <thebombzen> also
[18:49:46 CET] <furq> Note that it's generally preferable for a decoder to output at 48kHz, even when you know the original input was 44.1kHz. This is not only because you can skip resampling, but also because many cheaper audio interfaces have poor quality output for 44.1kHz.
[18:49:50 CET] <furq> that's their justification for it
[18:50:03 CET] <fritsch> furq: haha
[18:50:04 CET] <thebombzen> hm
[18:50:14 CET] <furq> https://wiki.xiph.org/OpusFAQ#But_won.27t_the_resampler_hurt_the_quality.3F_Isn.27t_it_better_to_use_44.1_kHz_directly.3F
[18:50:18 CET] <furq> and that as well
[18:50:30 CET] <thebombzen> another question
[18:50:35 CET] <thebombzen> is there any reason to use TS over mkv
[18:50:36 CET] <thebombzen> in general
[18:51:06 CET] <thebombzen> the MKV muxer in OBS's recording is bugged so if you seek you lose the audio stream
[18:51:13 CET] <thebombzen> but I'm not sure any other reason
[18:51:16 CET] <kerio> lmao
[18:51:16 CET] <furq> i use ts if i want something streamable, but idk if it's actually more reliable than mkv with -live 1
[18:51:31 CET] <thebombzen> I know ts is concatenation-friendly
[18:51:35 CET] <thebombzen> but that's like it
[18:51:47 CET] <kerio> that bit about resampling being way more precise than any lossy compression is a fair point
[18:52:18 CET] <furq> yeah i trust the xiph guys to have not made a major oversight like that without being able to justify it
[18:52:30 CET] <thebombzen> that's a reasonable justification
[18:52:44 CET] <thebombzen> "we didn't want to support 44.1 kHz because yall idiots shouldn't be using it"
[18:52:49 CET] <kerio> :D
[18:52:51 CET] <furq> all my music is flac or mp3 anyway
[18:52:56 CET] <thebombzen> mp3 :P
[18:53:00 CET] <thebombzen> feels bad man
[18:53:05 CET] <kerio> "we didn't want to support 44.1kHz because it's $current_year and srsly now"
[18:53:12 CET] <furq> i'll gladly upgrade to flac if you can find me a source for it
[18:53:26 CET] <furq> i didn't choose mp3, mp3 chose me
[18:53:34 CET] <thebombzen> I actually have most of my collection as alac-in-mp4
[18:53:39 CET] <furq> eww
[18:53:40 CET] <thebombzen> becaues I'm weird and have an iPhone
[18:53:41 CET] <kerio> furq: http://downloads.xiph.org/releases/flac/flac-1.3.1.tar.xz
[18:53:48 CET] <kerio> here's the source for flac :^)
[18:53:48 CET] <furq> you sicken me
[18:53:49 CET] <furq> both of you
[18:53:57 CET] Action: kerio has alac because itunes
[18:54:03 CET] <thebombzen> same
[18:54:13 CET] <kerio> also because the alac encoder gave me *slightly* more compression than flac
[18:54:16 CET] <thebombzen> I need iTunes to put stuff on my iphone
[18:54:21 CET] <furq> really?
[18:54:23 CET] <thebombzen> well alac is generally worse that flac
[18:54:26 CET] <furq> yeah
[18:54:34 CET] <kerio> was better here, idk :|
[18:54:34 CET] <thebombzen> it's an inferior codec
[18:54:40 CET] <thebombzen> although
[18:54:48 CET] <thebombzen> I'm loving the VLC iphone app
[18:54:49 CET] <furq> it's a codec that has no reason to exist
[18:55:03 CET] <furq> it is worse than flac in every measurable way
[18:55:04 CET] <thebombzen> the VLC iphone app works through afc
[18:55:06 CET] <thebombzen> so like
[18:55:12 CET] <thebombzen> I can plug it into my linux box
[18:55:21 CET] <kerio> D; flac was better here
[18:55:28 CET] <furq> that reminds me, i should get mpv running on my phone
[18:55:28 CET] <thebombzen> using gvfs I can transfer an lavf/lavc compatible file
[18:55:29 CET] <kerio> 1823kbps vs 1826kbps
[18:55:38 CET] <thebombzen> all on linux
[18:55:40 CET] <thebombzen> and I don't have to sync
[18:55:41 CET] <furq> what is this 24-bit bullshit
[18:55:43 CET] <thebombzen> and I can play it on vlc
[18:55:50 CET] <thebombzen> 24-bit bullshit?
[18:55:54 CET] <thebombzen> what do you mean
[18:55:56 CET] <furq> 17:55:29 ( kerio) 1823kbps vs 1826kbps
[18:55:59 CET] <thebombzen> haha
[18:56:09 CET] <thebombzen> 24-bit flac is useful if you're going to be editing the audio
[18:56:12 CET] <kerio> furq: sing a song of sixpence that goes BUUUUUURN THE WIIIITCH
[18:56:20 CET] <thebombzen> but straight up it's convereted to 16  anyway before it's sent to the hardware
[18:56:35 CET] <thebombzen> it's like 96 kHz audio
[18:56:41 CET] <kerio> i have a 1077kbps 16bit 44.1khz
[18:56:48 CET] <thebombzen> you can't hear the difference cause the hardware supports 48
[18:56:54 CET] <thebombzen> but it's useful for editing
[18:56:56 CET] <furq> anyway yeah
[18:56:57 CET] <furq> https://xiph.org/flac/images/all-tracks-encode.png
[18:56:59 CET] <furq> https://xiph.org/flac/images/all-tracks-decode.png
[18:57:14 CET] <thebombzen> 1000k is on the high end for cd quality lossless
[18:57:24 CET] <thebombzen> most of my cd quality flacs are ~800k
[18:57:24 CET] <furq> cue somebody saying "wtf is wma lossless"
[18:57:30 CET] <thebombzen> is that a thing
[18:57:34 CET] <furq> it sure is
[18:57:38 CET] <thebombzen> why would anyone use it
[18:57:38 CET] <kerio> why wouldn't it be
[18:57:51 CET] <furq> well i've heard that some people use alac
[18:57:55 CET] <kerio> o/
[18:57:57 CET] <furq> so why wouldn't microsoft think they can pull the same bullshit
[18:58:07 CET] <thebombzen> becaues nobody has windows phones
[18:58:07 CET] <kerio> because microsoft doesn't have the hardware to support it
[18:58:11 CET] <kerio> where are you going to play that shit
[18:58:12 CET] <kerio> on a zune?
[18:58:16 CET] <furq> yes
[18:58:19 CET] <furq> i will play it on my zune
[18:58:21 CET] <kerio> fair
[18:58:31 CET] <kerio> thebombzen: my hardware claims to support 96/24
[18:58:35 CET] <kerio> it's like a mode i can set
[18:58:36 CET] <thebombzen> haha
[18:58:44 CET] <thebombzen> that's specialty hardware right there
[18:58:45 CET] <kerio> idk
[18:58:50 CET] <thebombzen> my speakers don't
[18:59:05 CET] <kerio> to be fair i don't necessarily doubt it does
[18:59:09 CET] <thebombzen> lol APE
[18:59:15 CET] <thebombzen> I'm not sure why anyone uses monkey's audio
[18:59:16 CET] <furq> i still see a ton of ape
[18:59:17 CET] <thebombzen> when flac is a thing
[18:59:21 CET] <thebombzen> I see it all the time
[18:59:23 CET] <kerio> it's just that when on speakers i hear a lot of farting if i crank up the volume
[18:59:24 CET] <thebombzen> I just don't know why
[18:59:30 CET] <thebombzen> ape is weird cause it's symmetric
[18:59:32 CET] <furq> people use it because it compresses ~3% better according to that chart
[18:59:34 CET] <kerio> so frankly the distinction between 48khz and 96khz is probably lost on me
[18:59:35 CET] <thebombzen> like decoding is just a slow as encoding
[18:59:37 CET] <furq> and they think that's important
[18:59:39 CET] <thebombzen> haha
[18:59:47 CET] <thebombzen> those are people with too much time on their hands
[18:59:53 CET] <furq> although i see plenty compressed with the faster presets
[19:00:01 CET] <thebombzen> that makes no sense XD
[19:00:02 CET] <thebombzen> like
[19:00:03 CET] <kerio> i want opus lossless :<
[19:00:09 CET] <thebombzen> opus lossless is kinda silly?
[19:00:12 CET] <thebombzen> like what's the point
[19:00:14 CET] <thebombzen> why not just flac
[19:00:31 CET] <furq> ape beats flac -8 for encoding speed and compression at the faster presets
[19:00:37 CET] <furq> but then the decoding speed is trash
[19:00:53 CET] <thebombzen> yea idk what the ponit is
[19:01:01 CET] <thebombzen> speaking of lossless is there any consensus on the best lossless video codec
[19:01:12 CET] <furq> i've seen probably half of those codecs in the chart in the wild
[19:01:16 CET] <thebombzen> I've been using ffv1 but I'm not sure how good it is relative to x264 -crf 0
[19:01:16 CET] <kerio> ffv1 i guess
[19:01:30 CET] <furq> never seen la, optimfrog, mp4 als or wma lossless
[19:01:37 CET] <kerio> x264 doesn't support a lot of pixel formats tho
[19:01:42 CET] <thebombzen> so
[19:01:50 CET] <thebombzen> who needs a lot of pixel formats
[19:02:03 CET] <thebombzen> what do people use to record the screen btw?
[19:02:16 CET] <furq> it does yuv420/422/444 and bgr
[19:02:24 CET] <furq> i guess if you're some gray16-using weirdo that's not good enough
[19:02:26 CET] <thebombzen> I actually discovered that utvideo-in-matroska is pretty decent
[19:02:39 CET] <thebombzen> cause my cpu can't do ffv1 in realtime
[19:02:51 CET] <thebombzen> what do other people use to record the screen
[19:02:52 CET] <furq> x264 lossless seems decent
[19:02:59 CET] <thebombzen> x264 -preset ultrafast -crf 0?
[19:03:02 CET] <furq> i haven't recorded the screen in a long time though
[19:03:03 CET] <furq> -qp 0, but yeah
[19:03:19 CET] <furq> you will get noticeable gains with slower presets, but obv it's slower
[19:03:22 CET] <thebombzen> is x264 not smart enough to automatically do -qp 0 from -crf 0
[19:03:31 CET] <furq> -crf 0 == -qp 0 with 8-bit x264
[19:03:34 CET] <furq> it's not the same with 10-bit
[19:03:58 CET] <furq> it's a minor nitpick but it's best to mention it now
[19:04:20 CET] <furq> i wonder if 10-bit x264 is noticeably better at lossless
[19:05:04 CET] <fritsch> try to find out on a raspberry pi2
[19:05:14 CET] <furq> sounds like a plan
[19:05:21 CET] <fritsch> it won't be able to decode it
[19:05:27 CET] <fritsch> like not any other hw decoder
[19:05:31 CET] <furq> sure it will
[19:05:35 CET] <fritsch> no it won't
[19:05:39 CET] <thebombzen> hm I'm testing hevc_nvenc's lossless right now
[19:05:40 CET] <furq> it'll decode the shit out of it at 1fps
[19:05:41 CET] <thebombzen> I wonder how awful it is
[19:05:48 CET] <fritsch> furq: hehe
[19:05:50 CET] <fritsch> yeah
[19:05:57 CET] <thebombzen> probably not bad given that I'm just typing into KVIrc
[19:06:06 CET] <fritsch> I really like hevc, even 8 bit makes some good results
[19:06:08 CET] <fritsch> see: 2.2 MB
[19:06:33 CET] <furq> isn't nvenc's hevc generally worse than x264
[19:06:35 CET] <fritsch> https://dl.dropboxusercontent.com/u/55728161/servus-extracted.ts
[19:06:41 CET] <furq> that's what i've heard from people in here anyway
[19:07:27 CET] <thebombzen> welp
[19:07:45 CET] <thebombzen> I got 2.5 Mbps with hevc_nvenc's lossless
[19:07:47 CET] <thebombzen> that's not bad
[19:07:59 CET] <thebombzen> but I've also got very minimal movement
[19:08:05 CET] <furq> yeah record a game or something
[19:08:05 CET] <thebombzen> x264 probably could do it with 800 kbps
[19:08:19 CET] <thebombzen> record a game? but then I have to reboot into windows XD
[19:08:36 CET] <furq> mame works just fine on linux
[19:08:38 CET] <thebombzen> I could try something like Mincraft but x11grab doesn't liek grabbing it
[19:08:54 CET] <thebombzen> I've had isues grabbing minecraft with x11grab. lots of flickering a zfighting and stuff
[19:08:55 CET] <thebombzen> it's weird
[19:09:25 CET] <furq> mame supports mng output iirc
[19:09:34 CET] <furq> actually why am i still talking as if you have mame there
[19:09:59 CET] <kerio> why wouldn't they have mame
[19:10:06 CET] <furq> i always forget that normal people don't have mame and 50GB of roms installed on all their machines
[19:10:06 CET] <thebombzen> wow I'm getting a really annoying spam of effors
[19:10:12 CET] <thebombzen> errors*
[19:10:17 CET] <kerio> but furq
[19:10:18 CET] <thebombzen> or rather warnings I should say
[19:10:24 CET] <kerio> the t7z-split set is only 35gb
[19:10:25 CET] <thebombzen> apparently when I record with hevc_nvenc to matroska
[19:10:33 CET] <thebombzen> it spams that the past duration is whatever
[19:10:39 CET] <furq> or more than 50GB of roms in my case because i have the 148 roms and then diffs of every version above that
[19:10:49 CET] <thebombzen> liike I get "past duration 0.95 is too large" spam
[19:10:53 CET] <thebombzen> do yo know how to fix that
[19:10:59 CET] <kerio> 32 versions behind? 😓
[19:11:04 CET] <furq> that message doesn't necessarily mean anything iirc
[19:11:12 CET] <thebombzen> I agree that it's harmless
[19:11:17 CET] <furq> kerio: shmupmame
[19:11:23 CET] <thebombzen> but it's annoying because it makes the status hard to read
[19:11:25 CET] <furq> unless the lagless drivers made it into mainline now
[19:11:28 CET] <furq> i've not been keeping up
[19:11:38 CET] <thebombzen> you know how ffmpeg prints a line of status
[19:11:43 CET] <thebombzen> and then a \r and keeps going
[19:11:50 CET] <furq> -v error -stats
[19:11:51 CET] <thebombzen> well because the past duration warning prints a \n it spams the terminal
[19:11:57 CET] <thebombzen> uh
[19:11:57 CET] <kerio> but the best game ever (dfkbl) was only added since a couple of versions D;
[19:12:09 CET] <thebombzen> oh okay I didn't know you could print stats with -v error
[19:12:20 CET] <thebombzen> I've always thought that setting the verbosity lower suppressed stats. thank you :)
[19:12:21 CET] <furq> well yeah that's why i have newer versions so i can use newer mame to play zero team 2000
[19:12:30 CET] <thebombzen> also what's mame
[19:12:44 CET] <kerio> arcade game emulator
[19:12:48 CET] <furq> but i need the 148 roms so i can play battle garegga (the actual best game ever) with one frame less lag
[19:12:57 CET] <kerio> smh
[19:13:12 CET] <furq> and dangun feveron, unquestionably cave's magnum opus
[19:13:17 CET] <furq> it's all been downhill from there
[19:13:52 CET] <kerio> has it
[19:14:33 CET] <kerio> esprade was pretty good
[19:16:43 CET] <furq> this is reminding me that i should play strania
[19:18:36 CET] <kerio> you should play pokemon sun/moon ;o
[19:18:42 CET] <kerio> it's the greatest pokemon of all time
[19:24:39 CET] <thebombzen> nope x11grab still hates minecraft
[19:24:58 CET] <furq> who can blame it
[19:25:06 CET] <kerio> it's an opengl game
[19:25:13 CET] <kerio> use syphon or whatever it's called
[19:26:23 CET] <thebombzen> what should I use to grab the screen?
[19:26:24 CET] <thebombzen> syphon?
[19:26:31 CET] <thebombzen> does it have an avdevice input
[19:27:36 CET] <kerio> hold on whats the reason you're not using OBS
[19:30:28 CET] <thebombzen> cause I like ffmpeg?
[19:34:14 CET] <kerio> OBS uses ffmpeg
[19:55:00 CET] <thebombzen> well I figured out why not to use obs
[19:55:02 CET] <thebombzen> it can't stop recording
[19:58:22 CET] <ThomasEgi> thebombzen, most opengl applications record fine if you don't run them in native fullscreen.
[19:58:33 CET] <thebombzen> okay
[19:58:34 CET] <ThomasEgi> a borderless window at the screen resolution often does a great job
[19:58:51 CET] <thebombzen> sure
[19:58:52 CET] <ThomasEgi> given you'r not running anything fancy like 3d-accelerated desktops
[19:59:00 CET] <thebombzen> lol MATE
[19:59:27 CET] <ThomasEgi> i'd recommend lxde. or awesomewm (later makes it really easy to run borderless windows in fullscreen
[20:04:47 CET] <thebombzen> well I use MATE
[20:05:11 CET] <thebombzen> I can just use Ctrl+Alt+F11 to borlessly fullscreen a window
[20:05:20 CET] <thebombzen> or rather. Alt+F11 my bad.
[20:42:56 CET] <phillipk> trying to learn more about ffmpeg to make my conversion project function.  I think I need to see some variations--for example, the filter_complex I created (to put  a fake mouse cursor in a different location of every frame) is too long for the cmd to work.
[20:43:32 CET] <phillipk> in case anyone has a minute, I am eager to solve: http://ffmpeg.gusari.org/viewtopic.php?f=11&t=3329
[21:34:09 CET] <phillipk> as for my question above, I've found how I can put a dynamic expression inside my overlay=x=2 vs. overlay=x=t*100,  but what I'd like to do is dump all the x coordinates into a text file and then have something like "overlay=x=getLineFromFile(2)"   and "getLineFromFile()" serves as a function that reads from file.  Is there a way to put subroutines inside a command?
[21:49:19 CET] <thebombzen> phillipk: it sounds like if you use -vf tile you can do this easily
[21:49:37 CET] <phillipk> i'll check it out...
[21:50:24 CET] <thebombzen> I already have the docs up so here's a link: https://ffmpeg.org/ffmpeg-filters.html#tile
[21:50:53 CET] <furq> you could maybe do it with sendcmd
[21:50:55 CET] <furq> https://ffmpeg.org/ffmpeg-filters.html#sendcmd_002c-asendcmd
[22:34:53 CET] <phillipk> @furq it looks like that should work, I'm just having issues...
[22:35:32 CET] <phillipk> ffmpeg -i input.mp4 -i cursor.png -filter_complex sendcmd=f=test.cmd  output.mp4
[22:35:39 CET] <phillipk> then, the test.cmd:
[22:35:49 CET] <phillipk> 00:00:01.000-00:00:03.00 [enter] overlay=x=20:y=30; 	    [leave] overlay=x=20:y=40;
[22:36:55 CET] <phillipk> I think I should be able to forgo the [leave].... but the issue with sendcmd that's confusing it that it's supposed to be inbetween two exisiting filters
[22:38:20 CET] <phillipk> this (ffmpeg -i input.mp4 -i cursor.png -filter_complex sendcmd=f=test.cmd  output.mp4) gives me "error configuring filters"
[22:38:56 CET] <furq> i think you need sendcmd=f=test.cmd,overlay
[22:39:10 CET] <furq> otherwise there's no overlay filter in the chain to send commands to
[22:39:27 CET] <furq> i've never had much luck with sendcmd though
[22:39:57 CET] <phillipk> I think I'm closer--this helps.
[23:09:18 CET] <phillipk> filter_complex_script  looks promising, I just have to format my file correctly it seems.
[23:13:26 CET] <MoonOwl> hi
[23:14:01 CET] <phillipk> hey, I'm trying to make filter_complex_script (pointing to a file containing the filter)
[23:14:46 CET] <durandal_1707> script is fIle with filtergraph
[23:14:49 CET] <MoonOwl> I am new to FFMPEG and wanted to know how I can prevent the bitrate from rising exponentially during encoding to x264 and x265 using the crf option
[23:16:19 CET] <MoonOwl> Using crf 20 with x265 the bitrate rises from the 200 - 300 kbps region to close to 4 Mbps from MPEG2 source
[23:16:51 CET] <MoonOwl> The output bitrate never goes down again
[23:19:47 CET] <MoonOwl> I tried setting -preset to placebo just to test if it's got anything to do with that setting but it seems not to
[23:30:50 CET] <furq> MoonOwl: pastebin the full command and output
[23:37:02 CET] <kerio> MoonOwl: aiui placebo is mostly harmful
[23:40:03 CET] <MoonOwl> That is the most ironic thing I have read today lol. Let me redirect the output of a sample just to illustrate what I'm referring to
[23:40:13 CET] <MoonOwl> Thanks btw guys and gals
[23:41:27 CET] <kerio> well
[23:41:45 CET] <kerio> it's just that it's appreciably slower than veryslow whilst not delivering many improvements
[23:46:57 CET] <BtbN> the bitrate ffmpeg shows is the average overall bitrate.
[23:47:15 CET] <BtbN> If it's low in the beginning it's because of initial blackness, the intro, or something
[23:48:15 CET] <MoonOwl> http://pastebin.com/EdGUFC87
[23:48:24 CET] <MoonOwl> That's the command
[23:48:48 CET] <DHE> what's the resolution of the video and what is it? (video game play? security camera footage?)
[23:48:54 CET] <MoonOwl> I suspect ffmpeg writes to stderrr like git and redirecting the output is a bit of a problem
[23:49:00 CET] <MoonOwl> It's 720x540
[23:49:05 CET] <MoonOwl> after cropping
[23:49:16 CET] <BtbN> why is that a problem? Just redirect stderr
[23:49:28 CET] <DHE> stdout is reserved for pipe outputs and stuff
[00:00:00 CET] --- Mon Dec 19 2016



More information about the Ffmpeg-devel-irc mailing list