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

burek burek021 at gmail.com
Mon Jul 25 03:05:01 EEST 2016


[00:00:04 CEST] <KDDLB> I use OS X mainly
[00:00:16 CEST] <KDDLB> and Linux in servers I have access to
[00:00:38 CEST] <JEEB> win for gaming, lunix for work and servers, OS X when having to deal with OS X development (build servers f.ex.) etc
[00:00:45 CEST] <JEEB> s/OS X/iOS/
[00:01:04 CEST] <furq> i use windows, debian and freebsd on a daily basis
[00:01:09 CEST] <furq> it's as enjoyable as you'd imagine
[00:01:34 CEST] <JEEB> it gets fun enough when you can start sharing some of your dotfiles on windows as well with cygwin or whatever else you like
[00:07:37 CEST] <KDDLB> how about __MACOSX and/or .DS_Store
[00:07:42 CEST] Action: KDDLB runs away
[00:07:55 CEST] <JEEB> those tend to end up in archives from ISO/IEC members
[00:08:00 CEST] <KDDLB> yeah
[03:33:05 CEST] <mccc> Hello, I'm cross compiling ffmpeg for the raspberry pi from a Debian development VM.  I was compiling alsa from source and while getting help earlier someone recommended using the libasound2-dev:armhf and libasound2-data:armhf packages to compile ffmpeg against, and use the libasound2:armhf and libasound2-data:armhf packages on the pi.
[03:33:33 CEST] <mccc> I've tried to do that, but I don't think I have alsa support compiling in correctly.
[03:33:42 CEST] <furq> the guy who recommended that sounds like a cool guy
[03:35:59 CEST] <mccc> If it was you I appreciate it :)
[03:36:02 CEST] <mccc> http://pastebin.com/MWDxW1L3
[03:36:21 CEST] <mccc> What I don't think I've been able to find is how to ./configure ffmpeg's build correctly.
[03:36:39 CEST] <mccc> ./configure --help doesn't display anything about alsa,
[03:37:07 CEST] <mccc> and the guide I was using at https://trac.ffmpeg.org/wiki/CompilationGuide/RaspberryPi#CompilingALSAlibrary
[03:37:47 CEST] <mccc> seems to presume an alsa-lib compiled from source, and I'm still not sure what's enabling it (--extra-libs=-ldl?  again, ./configure --help doesn't help..)
[03:38:10 CEST] <furq> try --enable-indev=alsa --enable-outdev=alsa
[03:38:34 CEST] <furq> iirc it's enabled by default but it might give a better error message if you explicitly enable it
[03:38:59 CEST] <mccc> Okay, thank you, trying that now.
[03:39:50 CEST] <mccc> Also, it looks like the libasound2-dev:armhf installed in /usr/include and /usr/lib/arm-linux-gnueabihf,
[03:40:12 CEST] <mccc> is there anything I need to do to get those to ./configure?
[03:41:39 CEST] <furq>  /usr/include is the default include path
[03:41:51 CEST] <furq> you might need --extra-ldflags="-L/usr/lib/arm-linux-gnueabihf"
[03:42:03 CEST] <furq> you also don't need the toolchain on that wiki page if you're on debian testing or unstable
[03:42:10 CEST] <furq> just inatall gcc-arm-linux-gnueabihf from apt
[03:42:15 CEST] <furq> install
[03:43:57 CEST] <mccc> Okay, thank you, but I'm on 8.5 (Jessie)
[03:44:10 CEST] <furq> never mind then
[03:44:17 CEST] <mccc> with --enable-indev and outdev, I do get:
[03:44:43 CEST] <mccc> WARMING: /home/user/x-tools/arm-unknown-linux-gnueabihf/bin/arm-unknown-linux-gnueabihf-pkg-config not found, library detection may fail.
[03:44:51 CEST] <mccc> WARNING: using libfdk without pkg-config
[03:45:02 CEST] <mccc> but otherwise configure ends cleanly.  Compiling and testing now.
[03:45:16 CEST] <furq> check the list of enabled libs in configure before building
[03:45:30 CEST] <furq> you can ignore those warnings but it might still be missing alsa
[03:46:48 CEST] <furq> you can install pkg-config:armhf if you want to get rid of the pkg-config warning
[03:47:11 CEST] <mccc> would it be listed as just "alsa"?  It's not listed.
[03:48:32 CEST] <furq> it should show up in "enabled indevs"
[03:48:38 CEST] <furq> i just tried it and it works here without --extra-ldflags
[03:48:49 CEST] <furq> but i'm using a different toolchain so maybe the lib paths are set up properly
[03:49:44 CEST] <mccc> let me try --extra-ldflags="-L/usr/lib/arm-linux-gnueabihf"..
[03:49:52 CEST] <furq> that's probably the culprit
[03:50:14 CEST] <furq> it looks like it silently disables alsa if libasound2 isn't found
[03:54:51 CEST] <mccc> Unfortunately it's still not listed.  I do have /usr/lib/arm-linux-gnueabihf/libasound.so and libasound.so.2 and libasound.so.2.0.0.
[03:58:57 CEST] <furq> https://wiki.debian.org/CrossToolchains#For_jessie_.28Debian_8.29
[03:58:59 CEST] <furq> maybe try with that toolchain
[04:00:26 CEST] <mccc> Thank you.  I'll try with that.  Also, here's the output of my ./configure:
[04:00:27 CEST] <mccc> http://pastebin.com/Hz72qddy
[04:00:48 CEST] <mccc> The command I used:
[04:02:44 CEST] <mccc> http://pastebin.com/mYZ3WzhJ
[04:05:15 CEST] <furq> http://vpaste.net/aD9qk
[04:08:31 CEST] <furq> you can install libfdk-aac-dev:armhf as well
[04:09:55 CEST] <furq> http://vpaste.net/asYz5
[04:09:58 CEST] <furq> that should be all you need
[04:10:20 CEST] <furq> which is surprising because i figured that would need --enable-nonfree
[04:10:48 CEST] <mccc> I thought so too - and the license is why I didn't think it would be available from a package and that I'd need to compile it from source.
[04:11:09 CEST] <furq> you'll need to enable non-free in apt.conf
[04:11:18 CEST] <furq> https://packages.debian.org/jessie/libfdk-aac-dev
[04:12:25 CEST] <mccc> Will I do this both in the development environment and in the pi, or will libfdk-aac-dev be compiled statically in to ffmpeg?
[04:13:01 CEST] <furq> you'll probably need to install it on the pi as well
[04:14:46 CEST] <furq> you can normally use --extra-ldflags="-static" but it looks like the fdk package doesn't provide a static lib
[04:16:42 CEST] <mccc> Okay, giving this a run now.
[04:16:48 CEST] <mccc> Thank you again.
[05:50:03 CEST] <Mista-D> is there a search option for FFmpeg documentation on the website please?
[05:57:48 CEST] <mrelcee> well - 24+ hours of encoding no crashes running from the git sources.   3.1.1.    crashed every couple hours for me..   same --settings in configuration..      whatever works I'm a happy camper..   :)
[09:49:05 CEST] <Guest_84847> Allah is doing
[09:49:06 CEST] <Guest_84847> sun is not doing Allah is doing
[09:49:10 CEST] <Guest_84847> moon is not doing Allah is doing
[09:49:24 CEST] <Guest_84847> stars are not doing Allah is doing
[09:49:35 CEST] <Guest_84847> planets are not doing Allah is doing
[09:49:52 CEST] <Guest_84847> galaxies are not doing Allah is doing
[09:57:31 CEST] <mccc> Hi furq, thank you, using the toolset and .configure command you recommended, I was able to compile and get this to run with libfdk and alsa on the pi.  Sincerely appreciate the help :)
[10:26:56 CEST] <Fjorgynn> varför?
[17:08:18 CEST] <wuOz> hi, is there an option to stream second per second of a file?
[18:16:43 CEST] <wuOz> wuOz: It is the -re option with ffmpeg
[18:18:59 CEST] <JEEB> also a horrible hack that can break rather easily. so while you can use it and it might work for your use case - make sure you don't get too used to using it (as it can break under your feet for various reasons)
[19:31:39 CEST] <livingBEEF> is there somewhere a list of 3.0 api changes?
[19:32:45 CEST] <livingBEEF> The realease changelog only mentiones that they're there...
[20:06:53 CEST] <JEEB> livingBEEF: there's a file in the repo either in root or under docs
[20:07:00 CEST] <JEEB> apisomething
[20:08:37 CEST] <livingBEEF> thanks
[21:05:10 CEST] <DelphiWorld> YO ffmpegsters
[21:24:51 CEST] <kelnoky> hey, I am at a slight loss. I tried to google, but got confusing results and I am under time contraints. I need to convert an m4b file into an mp3 file, but cant really find a way to do it
[21:25:42 CEST] <kelnoky> ugh, might have solved it
[21:25:44 CEST] <kelnoky> this always happens
[21:33:13 CEST] <furq> m4b?
[21:37:43 CEST] <kelnoky> yeah, that was my initial problem
[21:37:45 CEST] <kelnoky> audiobook format
[21:42:44 CEST] <__jack__> do you have a sample ?
[21:47:11 CEST] <kelnoky> I did indeed solve it
[21:47:26 CEST] <__jack__> ok!
[21:47:31 CEST] <kelnoky> it was as simple as 'faad --stdio INPUT.m4b | lame --preset standard - OUTPUT.mp3'
[21:47:44 CEST] <furq> it looks like it's just an m4a with chapters
[21:47:50 CEST] <furq> ffmpeg opens it fine here
[21:47:51 CEST] <kelnoky> the other google results I found just didnt talk about m4bs that's why I was confused
[21:47:54 CEST] <kelnoky> yeah
[21:48:00 CEST] <kelnoky> it is
[22:28:27 CEST] <harrynoob> hi. when using ffmpeg (from Kodi, in a libreelec build; not sure which version, can find if necessary) to play a HLS stream, the probing seems to sort-of-recognize it as such, but then just borks out. here's a bit of logging related to it http://pastebin.com/VFsjZpG8 anyone have an idea what's going on? i see that the # of bytes read is not increasing
[22:38:32 CEST] <oni> hello there. has anyone tried to build on osx with --enable-frei0r and managed it successfully? So far I have not
[22:38:36 CEST] <oni> ERROR: frei0r.h header not found
[22:38:42 CEST] <oni> I bet this is a common thing
[22:39:12 CEST] <oni> (that header is currently in /usr/local/include)
[23:00:31 CEST] <KDDLB> hmmm
[23:01:07 CEST] <KDDLB> why are the default parameters for video encoder h264_videotoolbox (macOS) make it look horrible? :/
[23:04:18 CEST] <JEEB> I was going to answer to that facetiously, but then I thought again. I mean, it's a 3rd party library based thing which uses the same SW encoder as QT if not a hardware encoder (in case such is even supported non !iOS)
[23:04:37 CEST] <JEEB> and QT's SW decoder and encoder were well known to be not exactly the best in town
[23:04:59 CEST] <KDDLB> hmm
[23:05:16 CEST] <furq> is it even appreciably faster than x264 on osx
[23:05:52 CEST] <JEEB> so unless you have a licensing requirement that requires you to either get a payware license from x264 LLC or use something that isn't GPL (like x264 by default), I would keep away from the videotoolbox one
[23:06:42 CEST] <KDDLB> so, no hardware-accelerated encoding?
[23:07:00 CEST] <JEEB> I think on iOS you might get that, but NFI if any of that is on OS X | macOS
[23:07:25 CEST] <JEEB> and even then, you don't use HW encoders for the quality
[23:07:50 CEST] <JEEB> you use them because your CPU can't handle jack shit and/or because you cannot distribute an AVC decoder and/or encoder for some reason
[23:08:04 CEST] <KDDLB> I have a Mac mini
[23:08:33 CEST] <KDDLB> and I gave up, I just used -vcodec prores
[23:08:37 CEST] <KDDLB> :D
[23:08:44 CEST] <JEEB> so for which use is this anyways?
[23:09:16 CEST] <KDDLB> testing yadif
[23:09:18 CEST] <JEEB> you might want to look into ut video if you're planning on opening it in a video editor or something
[23:09:53 CEST] <JEEB> because I see zero reason to use prores unless you specifically want lossy crapola out of your thing
[23:10:07 CEST] <JEEB> in which case you might as well use -c:v libx264 -preset ultrafast -q:v 0
[23:10:09 CEST] <JEEB> which is lossless
[23:10:49 CEST] <JEEB> of course lossless AVC isn't open'able in commercial editors
[23:11:00 CEST] <JEEB> so if that's what you want, then you will want to use something like Ut Video
[23:11:21 CEST] <KDDLB> it was mostly for testing
[23:11:33 CEST] <furq> KDDLB: is h264_videotoolbox actually hitting the cpu
[23:11:42 CEST] <KDDLB> not sure
[23:11:46 CEST] <furq> googling suggests it might be using quicksync if you have a recent enough cpu
[23:11:53 CEST] <furq> although i can't find anything concrete
[23:11:54 CEST] <JEEB> if you want to test how much using yadif slows you down, then you use `-f null -`
[23:12:08 CEST] <JEEB> which skips everything after input and filtering
[23:12:22 CEST] <JEEB> just pushes shit to /dev/null
[23:12:30 CEST] <furq> if that is the case then the answer is because quicksync is a bad h264 encoder
[23:12:47 CEST] <JEEB> that way you can kind of check how much is the speed with just decoding + yadif
[23:12:55 CEST] <JEEB> instead of having some sort of encoding in the mix
[23:13:04 CEST] <jhu> trying to compile latest ffmpeg using ./configure --prefix=$HOME  --disable-yasm --extra-ldflags='-L/users/jhu/lib' --enable-libmp3lame
[23:13:10 CEST] <JEEB> (you still haven't defined WTF you want to actual achieve and thus it's really hard to recommend anything at all)
[23:13:19 CEST] <KDDLB> dont worry
[23:13:30 CEST] <jhu> but says cannot find lib3lame even though I pointed directly to it using the extra-ldflags above.
[23:13:40 CEST] <JEEB> see what config.log says
[23:13:44 CEST] <KDDLB> Im just experimenting, JEEB
[23:13:53 CEST] <JEEB> and I'm trying to help you experiment
[23:14:12 CEST] <furq> jhu: you need to pass the path to lame/lame.h
[23:14:13 CEST] <JEEB> also if you are on x86 or x86_64 please explain why on earth would you not want the hand-built optimizations to not be built in
[23:14:17 CEST] <furq> presumably with --extra-cflags
[23:14:30 CEST] <JEEB> if he built LAME properly there should be a pkg-config file, no?
[23:14:45 CEST] <furq> if there was a pkg-config file then presumably he wouldn't need extra-ldflags
[23:14:46 CEST] <JEEB> and then if he sets PKG_CONFIG_PATH=/your/prefix/lib/pkgconfig it should JustWork
[23:14:54 CEST] <furq> but yeah that is the actual correct way to solve this
[23:14:54 CEST] <JEEB> furq: don't expect people to know about that stuff
[23:15:17 CEST] <JEEB> I've seen enough people trying to run circles around issues where pkg-config would have helped them
[23:15:22 CEST] <furq> sadly i don't expect people to know about pkg-config
[23:15:30 CEST] <KDDLB> !!
[23:15:38 CEST] <KDDLB> h264_videotoolbox is using the CPU actually
[23:15:39 CEST] <JEEB> + some people don't even set a prefix and `make install`
[23:15:44 CEST] <JEEB> KDDLB: then it's the QT one
[23:15:46 CEST] <jhu> extra-cflags worked!
[23:15:47 CEST] <JEEB> which is also shit
[23:15:49 CEST] <furq> well the prefix should be /usr/local anyway
[23:15:54 CEST] <jhu> thanks for the quick response.
[23:16:08 CEST] <JEEB> jhu: do note my comment regarding --disable-yasm
[23:16:13 CEST] <furq> i've never been so unhappy to be right
[23:16:13 CEST] <JEEB> if you are building for intel arch
[23:16:41 CEST] <JEEB> if you are building for !intel arch then it shouldn't require disable-asm to begin with, though
[23:18:25 CEST] <jhu> I don't have root access.
[23:18:46 CEST] <JEEB> so?
[23:18:58 CEST] <JEEB> build yasm, add to your PATH
[23:19:09 CEST] <JEEB> just like you're doing with whatever you're doing right now
[23:19:19 CEST] <jhu> ok. let me see about that.
[23:19:36 CEST] <JEEB> and this is if and only if yasm isn't packaged for your OS
[23:22:08 CEST] <YLivay> hello, does anyone know why ffmpeg complains about invalid output format when I specify "-f png" but if I just slap a ".png" to the destination file it outputs png just fine?
[23:23:11 CEST] <JEEB> because there is no such container called "png" in FFmpeg
[23:23:26 CEST] <JEEB> see `ffmpeg -formats |grep "png"`
[23:23:49 CEST] <YLivay> I saw that, but I still don't understand why it can't output it if it actually does S:
[23:24:10 CEST] <JEEB> because it either uses the raw data muxer or the apng one most probably?
[23:24:23 CEST] <YLivay> ffmpeg -i /path/to/input -vframes 1 /path/to/output.png works for example
[23:24:48 CEST] <JEEB> yes, because there's a decoder and encoder for that *video* format (as opposed to a "container" format)
[23:25:01 CEST] <JEEB> -f sets containers, -c sets video|audio|subtitle formats
[23:25:18 CEST] <JEEB> see `ffmpeg -codecs |grep "png"`
[23:25:19 CEST] <YLivay> Ahhh I see
[23:25:39 CEST] <JEEB> you could see from the command line output which muxer the png encoding actually uses
[23:26:39 CEST] <YLivay> Lavc56.26.100 png is that it?
[23:27:16 CEST] <JEEB> you can just post the whole output on a pastebin if you don't know what to parse of it, and link here
[23:28:26 CEST] <harrynoob> never mind, my issue seems to be non-ffmpeg related but instead entirely caused by Kodi, as running ffmpeg standalone works fine
[23:30:28 CEST] <YLivay> http://pastebin.com/PsgUU44u
[23:30:46 CEST] <JEEB> Output #0, image2, to 'out.png':
[23:30:48 CEST] <YLivay> this doesnt make much sense to me, is encoder = muxer?
[23:30:53 CEST] <JEEB> so it's using a muxer called image2
[23:31:03 CEST] <JEEB> and the video format is png
[23:31:31 CEST] <YLivay> so -c png for the container and -f would be image2?
[23:31:57 CEST] <JEEB> YLivay: muxer is short for multiplexer, you put streams (video|audio|subtitle) into it and get some container format with those stream(s)
[23:32:06 CEST] <JEEB> encoder is generally the part that generates streams
[23:32:19 CEST] <JEEB> usually from raw data that is provided by a decoder
[23:32:30 CEST] <JEEB> demuxer=>decoder=>encoder=>muxer
[23:32:34 CEST] <JEEB> is the usual flow
[23:32:50 CEST] <YLivay> Oh, thanks a lot man!
[23:33:37 CEST] <JEEB> and no, -c sets the decoder or encoder (decoder before the input (-i) and encoder after it)
[23:33:54 CEST] <JEEB> and -f sets the demuxer or muxer (same thing regarding before/after input)
[00:00:00 CEST] --- Mon Jul 25 2016


More information about the Ffmpeg-devel-irc mailing list