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

[burek]

[01:39:04 CEST] <debianuser> Hello. Am I misunderstanding something, or does ffmpeg produces incorrectly interleaved .mkv files? http://pastebin.com/JWTePGgQ - full output of johnvansickle.com/ffmpeg/ build encoding http://peach.themazzone.com/durian/movies/sintel-1024-surround.mp4 and `ffprobe -show_packets | grep ...` for it. Bug in ffmpeg?
[01:39:54 CEST] <debianuser> Works fine if you replace "out.mkv" with "out.mp4" in that command.
[02:39:36 CEST] <limbo_> I have two gif files and a webm, how do I scale all of them to the same resolution and combine them? (I already know how to use the concat filter)
[02:40:14 CEST] <limbo_> So, where do I put the args to scale those two input files?
[02:42:12 CEST] <c_14> Either scale them all individually, or use a giant filtergraph and the concat filter
[05:04:38 CEST] <Vic_> I want to build dev versionfrom source code  like Official does https://ffmpeg.zeranoe.com/builds/ ,and add config options like  --enable-d3d11va \ --enable-dxva2 \ but it doesn't work. Any suggestion is thankful~
[05:10:25 CEST] <Vic_> you idle man
[08:11:31 CEST] <Phantom55> hello
[08:12:34 CEST] <Phantom55> anyone willing to help me solve an installation problem?
[08:19:15 CEST] <relaxed> what's the problem?
[08:22:22 CEST] <Phantom55> I am running CentOS 6.8 and was not able to find a working guide but I did manage to get it installed and it's working on test files but I can't get it to work with ffmpeg-php to run at web level
[08:25:28 CEST] <Phantom55> configure: error: ffmpeg headers not found. Make sure ffmpeg is compiled as shared libraries using the --enable-shared option
[08:27:09 CEST] <relaxed> ffmpeg-php's configure?
[08:29:52 CEST] <Phantom55> yea
[08:31:08 CEST] <relaxed> what prefix did you use for ffmpeg?
[08:33:30 CEST] <Phantom55> I used a guide which shows  --prefix="$HOME/ffmpeg_build"
[08:33:46 CEST] <Phantom55> that puts it at /root/ffmpeg_build
[08:35:01 CEST] <relaxed> CFLAGS="-I $HOME/ffmpeg_build/include"  LDFLAGS="-L$HOME/ffmpeg_build/lib" ./configure ...
[08:35:54 CEST] <relaxed> remove the space after -I
[08:37:01 CEST] <Phantom55> ./configure --prefix="$HOME/ffmpeg_build" --extra-cflags="-I$HOME/ffmpeg_build/include" --extra-ldflags="-L$HOME/ffmpeg_build/lib" --bindir="$HOME/bin" --extra-libs="-ldl" --enable-gpl --enable-nonfree --enable-libfdk_aac --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libfreetype --enable-libspeex --enable-libtheora
[08:37:07 CEST] <Phantom55> that is what I ran
[08:37:52 CEST] <relaxed> run ffmpeg-php's configure like this -->  CFLAGS="-I"$HOME"/ffmpeg_build/include"  LDFLAGS="-L"$HOME"/ffmpeg_build/lib" ./configure
[08:38:01 CEST] <Phantom55> oh
[08:38:38 CEST] <relaxed> that will point it to ffmpeg's headers and libs (because they're in a non-standard location)
[08:38:59 CEST] <Phantom55> same result
[08:39:28 CEST] <relaxed> look at the end of config.log for the error
[08:43:03 CEST] <Phantom55> configure:4476: error: ffmpeg headers not found. Make sure ffmpeg is compiled as shared libraries using the --enable-shared option ?
[08:44:09 CEST] <relaxed> looks like you need to recompile ffmpeg with --enable-shared
[08:44:44 CEST] <Phantom55> I ran that too along with all the libraries
[08:45:09 CEST] <Phantom55> would it help to sinatll it in a different location?
[08:47:48 CEST] <tdr> if its missing headers, wouldnt that be the --devel package?
[08:49:59 CEST] <relaxed> tdr: not when compiling ffmpeg from source
[08:50:49 CEST] <relaxed> they're in $HOME/ffmpeg_build/include
[08:50:57 CEST] <Phantom55> I couldn't even find a working dev package
[08:51:19 CEST] <tdr> ok, missed that, only that headers werent found, thought it was being compiled against an existing ffmpeg binary install
[08:54:37 CEST] <Phantom55> there are 16 lib folders in /ffmpeg_build/include
[08:55:48 CEST] <relaxed> CFLAGS="-I"$HOME"/ffmpeg_build/include"  LDFLAGS="-L"$HOME"/ffmpeg_build/lib" ./configure
[08:55:58 CEST] <relaxed> You ran the above as one command?
[08:57:43 CEST] <Phantom55> yes
[08:59:20 CEST] <relaxed> try,  PKG_CONFIG_PATH="$HOME"/ffmpeg_build/lib/pkgconfig" ./configure
[09:00:11 CEST] <Phantom55> for ffmpeg-php or just ffmpeg?
[09:00:42 CEST] <relaxed> ffmpeg-php
[09:01:39 CEST] <Phantom55> gives me a return prompt
[09:07:52 CEST] <relaxed> sounds like it's time to run make
[09:09:20 CEST] <Phantom55> gives me a > instead of #
[09:10:36 CEST] <relaxed> oh, I didn't quote correctly
[09:10:50 CEST] <relaxed> hit control c
[09:11:11 CEST] <Phantom55> make: *** No targets specified and no makefile found.  Stop.
[09:11:14 CEST] <relaxed> run, PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure
[09:11:45 CEST] <Phantom55> sorry.. I don't use SSH much.
[09:12:56 CEST] <Phantom55> I did run that and still get the same error  for --enable-shared
[09:13:47 CEST] <relaxed> recompile ffmpeg --enable-shared
[09:13:58 CEST] <relaxed> *with*
[09:14:52 CEST] <Phantom55> I tried that too.. no errors and ended with License: nonfree and unredistributable Creating config.mak, config.h, and doc/config.texi...
[09:15:36 CEST] <Phantom55> let me try one more thing
[09:18:06 CEST] <Phantom55> thanks for your help so far.. I really appreciate it! Waiting for this command to run
[09:34:41 CEST] <Phantom55> ok, I ran configure for ffmpeg again and made sure --enable-shared was in the string, then ran make, make install, make distclean
[09:35:21 CEST] <Phantom55> then went back to ffmpeg-php and tried configure and got same error, ran CFLAGS="-I"$HOME"/ffmpeg_build/include"  LDFLAGS="-L"$HOME"/ffmpeg_build/lib" ./configure but same thing
[09:35:59 CEST] <relaxed> try PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure
[09:36:37 CEST] <Phantom55> configure: error: ffmpeg headers not found. Make sure ffmpeg is compiled as shared libraries using the --enable-shared option
[09:36:52 CEST] <relaxed> upload the config.log somewhere
[09:37:08 CEST] <Phantom55> ok
[09:39:05 CEST] <Phantom55> http://www.thebusdrivers.us/config.log
[12:58:32 CEST] <nitenq> Hi, i would like to know the delay of an rtmp stream using multiple clients, is there a way to do that with ffmpeg ?
[13:00:17 CEST] <BtbN> a few seconds
[13:44:58 CEST] <Zibri_> hello!
[13:46:22 CEST] <Zibri_> is anybody alive here? :D
[13:47:13 CEST] <Zibri_> I am making some tests with a bluetooth headset...
[13:47:37 CEST] <Zibri_> to record audio from the headset I just do: ffmpeg -f dshow -i audio="Headset (YE-106 Hands-Free)" test.wav (or mp3)
[13:47:41 CEST] <Zibri_> and it works.
[13:48:02 CEST] <Zibri_> now I am trying to OUTPUT to the headset but everything I try gives an error
[13:48:06 CEST] <Zibri_> any clues?
[13:50:44 CEST] -Zibri_:#ffmpeg- hello there is anybody here?!
[13:52:57 CEST] <Zibri2> hey
[13:53:30 CEST] <DelphiWorld> hi guys
[13:53:37 CEST] <Zibri_> hi
[13:53:41 CEST] <DelphiWorld> ffmpeg -vaapi_device /dev/dri/renderD128 -i http://10.46.1.3:4108/bysid/202 -acodec libmp3lame -ab 64k -vf 'format=nv12,hwupload' -c:v h264_vaapi output.mkv
[13:53:56 CEST] <Zibri_> it seems nobody is here
[13:53:59 CEST] <DelphiWorld> getting this error: [AVHWDeviceContext @ 0x53baa00] No VA display found for device: /dev/dri/renderD 128
[13:54:01 CEST] <Zibri_> only me and you
[13:54:10 CEST] <DelphiWorld> haha Zibri_
[13:54:30 CEST] <Zibri_> I am making some tests with a bluetooth headset...
[13:54:37 CEST] <Zibri_> to record audio from the headset I just do: ffmpeg -f dshow -i audio="Headset (YE-106 Hands-Free)" test.wav (or mp3)
[13:54:45 CEST] <Zibri_> now I am trying to OUTPUT to the headset but everything I try gives an error
[13:54:56 CEST] <DelphiWorld> i see
[13:55:02 CEST] <DelphiWorld> i never use any hw with ffmpeg
[13:55:26 CEST] <Zibri_> i tried to set the samplerate to 8000 and channels to 1
[13:55:33 CEST] <relaxed> Zibri_: are you using ... -f dshow OUTPUT?
[13:55:48 CEST] <Zibri_> but I always get "Requested output format 'dshow' is not a suitable output format"
[13:56:04 CEST] <Zibri_> relaxed: yes
[13:56:34 CEST] <Zibri_> ffmpeg -i test.wav -ac 1 -ar 8000 -ac 1 -f dshow "devicename"
[13:56:49 CEST] <Zibri_> ffmpeg -i test.wav -ac 1 -ar 8000 -f dshow "devicename"
[13:57:25 CEST] <Zibri_> any idea?
[13:57:54 CEST] <relaxed> I don't, sorry
[13:58:01 CEST] <Zibri_> :(
[14:03:47 CEST] <durandal_170> Zibri_: not possible, dshow is capture only
[14:07:16 CEST] <Zibri_> ok.. so how to output to any device and not the default?
[14:08:15 CEST] <DelphiWorld> anyone with hw acceleration
[14:08:30 CEST] <DelphiWorld> can't create display device for /dev/dri/rander128?
[14:09:04 CEST] <DelphiWorld> ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -i http://10.46.1.3:4108/bysid/353 -acodec libmp3lame -ab 64k -c:v h264_vaapi output.mp4
[14:11:48 CEST] <sunny26> Hi, i am seeing a very small memory leak with my custom decoder, I have also posted the same on this link http://libav-users.943685.n4.nabble.com/Libav-user-Memory-leak-while-using-ff-get-buffer-td4662720.html
[14:11:56 CEST] <sunny26> please someone help
[14:14:06 CEST] <jkqxz> DelphiWorld:  Does "vainfo" work?
[14:14:20 CEST] <DelphiWorld> jkqxz: yep it works
[14:14:27 CEST] <DelphiWorld> and i see all profiles
[14:14:29 CEST] <jkqxz> What distribution are you using?
[14:14:30 CEST] <DelphiWorld> even vp8 strangely
[14:14:50 CEST] <DelphiWorld> CentOs 7.1 a per wowza recomandation, qs dont work well in ubuntu & debian
[14:15:21 CEST] <jkqxz> (Older things might not support render nodes, "/dev/dri/card0" may work when the render node doesn't.)
[14:16:16 CEST] <DelphiWorld> same message, jkqxz
[14:16:21 CEST] <jkqxz> Hmm.  That's really talking about the libmfx proprietary driver (which is hard to make work on anything other than the supported CentOS version).  Normal libva with the open source driver should work anywhere.
[14:16:26 CEST] <DelphiWorld> ffmpeg -vaapi_device /dev/dri/card0 -hwaccel vaapi -hwaccel_output_format vaapi -i http://10.46.1.3:4108/bysid/353 -acodec libmp3lame -ab 64k -c:v h264_vaapi output.mp4
[14:16:41 CEST] <relaxed> DelphiWorld: pastebin
[14:16:43 CEST] <jkqxz> Paste the vainfo output somewhere?
[14:16:43 CEST] <DelphiWorld> jkqxz: i didnt compile
[14:17:10 CEST] <DelphiWorld> jkqxz: i did use a pr-built ffmpeg with libva staticaly built
[14:18:18 CEST] <relaxed> DelphiWorld: from https://www.johnvansickle.com/ffmpeg/ ?
[14:19:32 CEST] <DelphiWorld> jkqxz, relaxed: http://pastebin.com/cAVUnL1j
[14:19:44 CEST] <DelphiWorld> relaxed: yes, from there
[14:21:15 CEST] <jkqxz> That is using the Intel proprietary driver, which does not work with h264_vaapi.
[14:21:50 CEST] <DelphiWorld> vainfo: VA-API version: 0.35 (libva 1.3.1)
[14:21:50 CEST] <DelphiWorld> vainfo: Driver version: 16.4.2.1.39163-ubit
[14:21:50 CEST] <DelphiWorld> vainfo: Supported profile and entrypoints
[14:21:50 CEST] <DelphiWorld> VAProfileNone                   :	VAEntrypointVideoProc
[14:21:50 CEST] <DelphiWorld> VAProfileNone                   :	<unknown entrypoint>
[14:22:25 CEST] <DelphiWorld> shit... wrong past :(
[14:22:27 CEST] <DelphiWorld> sory guys
[14:22:34 CEST] <jkqxz> Either remove the media SDK and install the normal driver, or build with libmfx and use that instead.
[14:22:43 CEST] <relaxed> DelphiWorld: Yeah, that's me. I disabled support for libmfx because it doesn't work when built statically.
[14:22:53 CEST] <DelphiWorld> jkqxz: so is there a rpm to install for the Os driver
[14:23:04 CEST] <relaxed> no hwaccel seems to
[14:23:08 CEST] <DelphiWorld> jkqxz and relaxed please recomand a easy & stable solution, i am honestly lost for days
[14:24:10 CEST] <relaxed> I think you need to build ffmpeg by hand
[14:24:47 CEST] <DelphiWorld> will try. can i build it staticaly somewhere and put in my centos?
[14:25:55 CEST] <DelphiWorld> i am lost in this is intel quicksync
[14:26:02 CEST] <DelphiWorld> never got any stable  solution
[14:26:02 CEST] <Zibri_> how to select a different audio output other than default on windows version?
[14:27:24 CEST] <jkqxz> There are two mostly separate ways to use it.  There is the open source way, which uses VAAPI and the i965 driver.  There is the proprietary way, which uses the media SDK, libmfx and the iHD driver.
[14:28:00 CEST] <jkqxz> These overlap in that they have the same libva layer, which causes great confusion between them.  You have installed the media SDK and the iHD driver, but are trying to use VAAPI.
[14:28:55 CEST] <DelphiWorld> so what is the best way to benefit from hw accell in ffmpeg
[14:29:32 CEST] <jkqxz> You can either:  (a) remove the media SDK and install the i965 driver instead, and use VAAPI as in the command line you have above; or, (b) build ffmpeg with libmfx support and use then change all of your commands to use that (somewhat misleadingly called "qsv" in ffmpeg).
[14:30:28 CEST] <DelphiWorld> the libmfx never worked
[14:30:38 CEST] <DelphiWorld> i uninstalled the media sdk
[14:32:35 CEST] <DelphiWorld> jkqxz: the i965 driver is built-in?
[14:34:25 CEST] <jkqxz> It should be packaged by your distribution, yes.
[14:34:39 CEST] <DelphiWorld> ok
[14:36:22 CEST] <jkqxz> Might be called libva-intel-driver?
[14:36:54 CEST] <DelphiWorld> will check
[14:36:57 CEST] <BtbN> forget QSV exists on Linux, way healthier that way.
[14:37:14 CEST] <DelphiWorld> BtbN: ?
[14:37:33 CEST] <BtbN> you need to patch your kernel and half your system for that piece of garbage to work.
[14:38:06 CEST] <DelphiWorld> the kernel allready contain patch by intel
[14:38:34 CEST] <BtbN> then you just need to also patch libva, libdrm and some other libraries it uses.
[14:38:52 CEST] <DelphiWorld> again...
[14:38:56 CEST] <DelphiWorld> so pretty complex
[14:39:04 CEST] <BtbN> It's just bad in every aspect
[14:39:06 CEST] <jkqxz> BtbN:  Please call it libmfx.  QSV is too generic a term.
[14:39:11 CEST] <BtbN> it's a bad API and a nightmare to use
[14:39:25 CEST] <BtbN> Why is QSV generic? It's Intel QuickSync Video.
[14:39:36 CEST] <DelphiWorld> libmfx never work for me at all
[14:39:42 CEST] <BtbN> mfx vs. mxf is way too confusing.
[14:40:36 CEST] <jkqxz> Because you can use the "Intel QuickSync Video" hardware by other routes unrelated to libmfx.
[14:40:53 CEST] <DelphiWorld> yes, that's libva
[14:41:36 CEST] <BtbN> Even ffmpeg itself calls the media SDK one qsv.
[14:42:03 CEST] <jkqxz> Yes.  If ffmpeg had called the thing "libmfx" at the start rather than "qsv", I think we would not have all this confusion over people trying and failing to use the media SDK when they don't need to.
[14:42:18 CEST] <DelphiWorld> h264_qsv
[14:42:39 CEST] <DelphiWorld> it should be libmfx_h264
[14:42:45 CEST] <BtbN> no it shouldn't.
[14:42:47 CEST] <DelphiWorld> or libmfxh264, like libx264
[14:42:49 CEST] <BtbN> codec name is allways first.
[14:42:52 CEST] <jkqxz> ("Intel QuickSync Video" is the branding on the hardware feature, not on the media SDK or library.)
[14:43:01 CEST] <DelphiWorld> -vcodec libx264
[14:43:22 CEST] <BtbN> That's the library name and a huge legacy name.
[14:43:49 CEST] <BtbN> mfx/mxf is just way too confusing. qsv is fine.
[14:43:59 CEST] <BtbN> qsv vs. vaapi is easy to separate
[14:47:53 CEST] <jkqxz> BtbN:  Not when new users arrive wanting to use QSV (the hardware feature) and therefore think the only way to use it is via qsv (the ffmpeg feature).  Not unreasonably, given the name.
[14:50:23 CEST] <BtbN> If it was named mfx, they'd never get the idea ffmpeg would support it, because it's too obscure of a name.
[14:50:35 CEST] <BtbN> And "use vaapi instead" is not too hard to explain.
[14:51:58 CEST] <Mavrik> They're both uttery horrible ways of saying "hey, use the hardware in my machine".
[14:54:02 CEST] <BtbN> There are like a couple dozen APIs to use hardware accelerators. You're not going to be able to add a -hwaccel 1 option.
[14:54:32 CEST] <Mavrik> Reason being?
[14:54:42 CEST] <Mavrik> (I get the complexity.)
[14:54:59 CEST] <BtbN> How do you want to find out which one of them to use?
[14:55:02 CEST] <BtbN> And how?
[14:55:10 CEST] <Mavrik> I'm just kinda against calling "-vcodec <something that has no connection to h264>" a "fine" solution to use a H.264 hardware encoder.
[14:55:28 CEST] <Mavrik> Which will then die due to lack of another library that has nothing connected to h264 in the name.
[14:55:32 CEST] <BtbN> how does h264_qsv and h264_nvenc and so on not have a connection to h264?
[14:55:51 CEST] <BtbN> And that's how all the hardware encoders are called.
[14:58:50 CEST] <Mavrik> So when as a user I wanna HW encode the video.
[14:59:11 CEST] <Mavrik> I need to magically know that h264_qsv corresponds to the intel chip and what libraries I know.
[14:59:21 CEST] <Mavrik> Instead of autoprobing like it's done in AVFormat?
[14:59:30 CEST] <BtbN> yes, because you are the one who knows what hardware you're sitting in front of.
[14:59:32 CEST] <BtbN> ffmpeg does not
[14:59:43 CEST] <Mavrik> Right.
[14:59:47 CEST] <Mavrik> The process running on a machine.
[14:59:56 CEST] <Mavrik> Cannot know what libraries are available in that machine.
[15:00:00 CEST] <BtbN> There is no way to find out which API is the "right" one to use
[15:00:09 CEST] <BtbN> specially if multiple are available, which is the case quite often
[15:00:14 CEST] <Mavrik> Right.
[15:00:30 CEST] <Mavrik> Just like there's no way to use which decoder to use when you see a format right?
[15:00:32 CEST] <Mavrik> But oh wait.
[15:00:42 CEST] <Mavrik> There's an algorithm that resolves that to do a sensible thing.
[15:00:43 CEST] <BtbN> And even if some are not available, to find out it doesn't work you have to spin a full encode/decode session to find out it explodes
[15:01:02 CEST] <Mavrik> Now you switched from "it's impossible" to "it's hard" :)
[15:01:10 CEST] <BtbN> Well, if it's so easy to find out which API is the right in every case. Go ahead and send a patch for it.
[15:01:20 CEST] <Mavrik> Not "every" case.
[15:01:28 CEST] <Mavrik> Just "sensible" case.
[15:01:36 CEST] <BtbN> If it doesn't work in some cases, it's useless
[15:01:38 CEST] <Mavrik> (We have an external resolver atm.)
[15:01:47 CEST] <Mavrik> (Can't be bothered to deal with this tone on mailing list again :/)
[15:01:54 CEST] <Mavrik> Nope.
[15:02:07 CEST] <Mavrik> It's perfectly usable for all of the cases except those "some".
[15:02:27 CEST] <Mavrik> You know, just like defaults for formats are perfectly usable for most cases.
[15:02:30 CEST] <BtbN> And then someone wants to use it on a machine with an odd combination, and it doesn't work, and then it's a bug.
[15:02:33 CEST] <Mavrik> Except those "some" where you override them.
[15:02:39 CEST] <Mavrik> Yes!
[15:02:42 CEST] <Mavrik> And then you fix it.
[15:02:46 CEST] <Mavrik> And then ffmpeg is better!
[15:02:46 CEST] <BtbN> you can't.
[15:02:54 CEST] <Mavrik> Look, software development. :P
[15:02:56 CEST] <BtbN> There is no way to make a sensible guess which hw accel api to use
[15:03:10 CEST] <Mavrik> Of course there is.
[15:03:15 CEST] <BtbN> There can be OMXIL, VAAPI, VDPAU, NVENC, VDPAU and QSV all be available at the same time.
[15:03:23 CEST] <BtbN> Only nvenc and vaapi work
[15:03:24 CEST] <Mavrik> Choose one then.
[15:03:31 CEST] <BtbN> now how are you going to find out which one it is?
[15:03:38 CEST] <BtbN> You can't, without trying a full encode on each and every one.
[15:03:48 CEST] <Mavrik> That's fine.
[15:03:52 CEST] <BtbN> No it's not.
[15:04:41 CEST] <BtbN> If you want something that work allways, use a software encoder.
[15:04:44 CEST] <Mavrik> You're just defending crappy parameters and documentation now because it's a bit hard.
[15:04:55 CEST] <BtbN> Looking forward to your patches then.
[15:05:24 CEST] <BtbN> Parameters is also a good keyword. You're not going to unify all the diffrent parameters all the hw encoders take.
[15:06:06 CEST] <BtbN> Some of them work fundamentally diffrent. So you'd have to somehow manage to make every single encoder in ffmpeg work with a common set of parameters. That's not going to happen
[15:08:07 CEST] <DelphiWorld> BtbN: you know streambuilder?
[15:08:48 CEST] <BtbN> no
[15:08:49 CEST] <Mavrik> BtbN, and I never said that should be it.
[15:08:59 CEST] <Mavrik> Just like it isn't for all the codecs or formats or devices.
[15:09:04 CEST] <DelphiWorld> streambuilder.pro
[15:09:10 CEST] <Mavrik> But that doesn't really prevent you from making a default that's not insane.
[15:09:13 CEST] <DelphiWorld> work out of the box with QuickSync
[15:09:23 CEST] <Mavrik> (Which according to amount of tickets and support questions around it currently is.)
[15:09:34 CEST] <BtbN> Probably bundles all the libraries it needs. Or is just using vaapi and calling it QuickSync.
[15:09:40 CEST] <Mavrik> You could already code something decently sensible just by things that are "broken" you said here.
[15:09:53 CEST] <BtbN> No idea what you're talking about.
[15:10:01 CEST] <BtbN> Encoders have diffrent parameters and interpret them diffrently.
[15:10:02 CEST] <Mavrik> Obviously.
[15:10:09 CEST] <BtbN> You're not going to unify them.
[15:10:17 CEST] <BtbN> Not because something about the parameters is "insane"
[15:10:20 CEST] <BtbN> they just don't match up.
[15:10:22 CEST] <Mavrik> Who exactly is talking about unifying them?
[15:10:25 CEST] <Mavrik> Stop making stuff up.
[15:10:30 CEST] <BtbN> Well, you are.
[15:10:30 CEST] <Mavrik> I'm talking about sensible defaults.
[15:10:34 CEST] <Mavrik> No.
[15:10:42 CEST] <BtbN> If you want generic hardware accelerated encoding, you also need generic parameters.
[15:10:46 CEST] <Mavrik> ffmpeg -i blah output.mp4
[15:10:50 CEST] <Mavrik> This selects sensible defaults.
[15:11:01 CEST] <Mavrik> ffmpeg -i blah -hwaccel 1 output.mp4 can do so as well.
[15:11:06 CEST] <Mavrik> You then tweak it if it doesn't work.
[15:11:16 CEST] <BtbN> It selects presets that are useless for at least 90% of the cases.
[15:11:34 CEST] <Mavrik> No actually, they're useless for 10% of cases.
[15:11:41 CEST] <BtbN> Yeah, sure...
[15:11:41 CEST] <Mavrik> And useful for a huge majority of other people.
[15:11:59 CEST] <BtbN> Because you never want another bitrate, a diffrent set of features, ...
[15:12:33 CEST] <Mavrik> You're deliberately trying to misunderstand what I say.
[15:12:41 CEST] <Mavrik> Or you can't read, can't decide which is which :/
[15:12:59 CEST] <Mavrik> Maybe "sensible defaults" is a term that's problematic?
[15:13:11 CEST] <BtbN> There are no sensible defaults.
[15:13:30 CEST] <BtbN> You essentially allways want to change at least some parameters. The bitrate, in the most simple case.
[15:14:10 CEST] <BtbN> And even for just setting the bitrate, the encoders interpret a simple -b:v 1234k vastly diffrent.
[15:14:15 CEST] <flux> I don't think that's true. sometimes you just want anything produced.
[15:14:33 CEST] <flux> and once you have something, you start to wonder if this is what you wanted, and if not, how to go where you want
[15:15:28 CEST] <BtbN> So you're going to implement a huge hack that does some crazy guessing based on who knows what magic you can make up, which is then maybe usefull for a very small percentage of users
[15:15:49 CEST] <BtbN> It will only confuse users, because parameters don't match up, behave diffrently on diffrent machines, sometimes don't work at all, ...
[15:16:21 CEST] <BtbN> I also don't see the issue with explicitly selecting the encoder you want to use. It's not like you change the hardware every day
[15:17:11 CEST] <BtbN> If you somehow manage to find a good algorithm to find the best encoder to use in every case, and can somehow solve the parameter mismatches, feel free to send a patch.
[15:17:42 CEST] <BtbN> Specially hardware-encoders need a lot of tweaking to output a somewhat useable quality
[15:41:47 CEST] <beastwick> Hi, what are the ffmpeg options minrate and maxrate aliases for when using x264?
[15:42:21 CEST] <beastwick> minrate and maxrate do not appear to be x264 options or maybe I am looking at bad documentation
[15:43:53 CEST] <BtbN> I think minrate and maxrate are just global avcodec options and libx264 uses them.
[15:45:56 CEST] <beastwick> BtbN when you say libx264 uses them, do you know what or where I can find options get set? I tried doing a quick search on the GitHub, but I didn't come up with anything, granted the GitHub repos search kind of sucks.
[15:46:50 CEST] <BtbN> look at the options_table.h for the options, and then search the libx264.c for the field it sets
[15:46:57 CEST] <beastwick> thanks :)
[15:47:17 CEST] <BtbN> So https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/options_table.h#L196 > https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L501
[15:47:49 CEST] <BtbN> minrate seems to be unused though
[15:48:16 CEST] <BtbN> as in, doesn't exist at all for x264
[15:48:20 CEST] <furq> why am i not surprised
[15:48:38 CEST] <BtbN> that x264 doesn't support a minrate?
[15:48:45 CEST] <BtbN> Not much you can do about that i guess
[15:49:06 CEST] <furq> more that all of those "how 2 stream league of dotas to twitch" guides are wrong
[15:49:35 CEST] <BtbN> I wouldn't be surprised if some other part of ffmpeg interprets the minrate option and insert null packets to reach it
[15:49:40 CEST] <BtbN> so it might not be useless
[15:51:33 CEST] <bencoh> x264 has no use for it actually
[15:52:09 CEST] <bencoh> vbv-bufsize/maxrate have a meaning for x264, minrate doesn't
[15:52:38 CEST] <bencoh> muxers on the other hand *have* to pad in certain cases
[15:52:52 CEST] <bencoh> but that belongs to muxers, not encoders
[15:52:55 CEST] <BtbN> i think you can even tell x264 to insert NAL padding with some x264opt
[15:53:12 CEST] <JEEB> x264-params you mean
[15:53:20 CEST] <beastwick> BtbN you can specify to pad the bitrate.
[15:53:25 CEST] <JEEB> x264opt is a custom libavcodec/libx264.c key,value thing
[15:53:34 CEST] <JEEB> which maps *some* things to libx264
[15:53:43 CEST] <furq> well if we're being pedantic then he means x264-param
[15:53:44 CEST] <JEEB> while x264-params passes the key-value pairs straight to libx264
[15:54:03 CEST] <JEEB> ok, if that's the correct naming then that's it:P
[15:54:05 CEST] <beastwick> Basically I am using software that has a "CBR" mode, but it clearly doesn't enforce it. It is just keeping the output to a fixed average, which is what I do not want.
[15:54:22 CEST] <furq> well the option is params but he was using the singular
[15:54:34 CEST] <BtbN> "-nal-hrd cbr"
[15:54:36 CEST] <BtbN> seems to be the option
[15:54:45 CEST] <beastwick> When I say I want only 2 mbps, I don't want to see 2.3 mbps. So I have been working with vbv-bufsize and vbv-maxrate limiting the vbv-bufsize to a single frame.
[15:54:55 CEST] <beastwick> Yes I am using VBV with nal-hrd cbr now.
[15:55:16 CEST] <BtbN> I have never seen x264 go over the bitrate in "cbr" mode
[15:55:17 CEST] <beastwick> It just seems wrong to do it this way, but it is more or less what I want.
[15:55:26 CEST] <BtbN> but it will go below it if there's nothing going on to encode
[15:55:44 CEST] <beastwick> It goes over it all the time with me :(, maybe I set it up wrong.
[15:56:05 CEST] <JEEB> or maybe you are calculating it wrong?
[15:56:17 CEST] <JEEB> are you using a proper VBV/HRD compatible bit rate calculation system?
[15:56:24 CEST] <BtbN> I think x264 aims for the bitrate within one gop interval?
[15:56:27 CEST] <bencoh> cbr/vbv mode works well with x264
[15:56:33 CEST] <beastwick> idk I choose CBR in the software for x mbps, and it definitely goes over in some scenes lol, this is for live streaming
[15:56:39 CEST] <bencoh> yeah, set it for a gop, not for a single frame
[15:56:56 CEST] <BtbN> So if you measure per-second, you will see a peak at each I Frame
[15:57:07 CEST] <JEEB> "and it definitely goes over", in what way are you calculating that?
[15:57:23 CEST] <beastwick> I'm not calculating, I'm observing what the software is reporting in real time.
[15:57:31 CEST] <beastwick> Is that wrong?
[15:57:36 CEST] <BtbN> What software?
[15:57:40 CEST] <beastwick> obs-studio
[15:57:42 CEST] <JEEB> I have no idea what your "software" is and how it reports things
[15:57:49 CEST] <BtbN> Did you take your audio bitrate into account?
[15:57:53 CEST] <JEEB> most things do not even try to calculate things according to HRD/VBV
[15:57:53 CEST] <BtbN> And muxing overhead?
[15:58:16 CEST] <beastwick> yes, I have my bitrate set for 2340, audio at 160. I've seen the bitrate go above that.
[15:58:27 CEST] <BtbN> OBS has a moving average over the last X seconds of outgoing network traffic I think, which is quite ok. But it's not the video bitrate
[15:58:47 CEST] <beastwick> really?, that's... misleading
[15:58:48 CEST] <JEEB> that still doesn't tell if something went over the VBV/HRD limits
[15:58:55 CEST] <BtbN> Why is it misleading?
[15:59:11 CEST] <BtbN> You care about the total bandwidth you send to the server. Not how much of that is the video.
[15:59:24 CEST] <beastwick> because I think we assume that what we see in the lower right corner is the output bitrate
[15:59:29 CEST] <bencoh> beastwick: think of vbv as a model where receiver has a buffer of a determined size
[15:59:41 CEST] <BtbN> beastwick, it is. But that's not only the video bitrate.
[15:59:58 CEST] <bencoh> (and an uplink of a specific throughput)
[16:01:01 CEST] <bencoh> anyway, you probably want to try that with a larger bufsize (~gop)
[16:02:14 CEST] <BtbN> The default OBS uses, vbv-buffsize == target bitrate, is usually quite sensible.
[16:03:42 CEST] <beastwick> ... I think I'm confused hah hah. So let me know if this is just wrong, because I clearly don't understand what's going on. At the moment I am shooting for a video br of 2340 and an audio br of 160. I didn't understand what the lower right was representing so I thought something was wrong. After hours of some things making sense and other things not making sense, I went with a CRF of 23, vbv-bufsize of 117 (i divided maxrate / fp
[16:04:02 CEST] <beastwick> it stays within range now, but this is wrong?
[16:04:17 CEST] <BtbN> CRF is constant-quality encoding
[16:04:31 CEST] <BtbN> It aims for a constant image quality, and will use however much bitrate that needs.
[16:04:44 CEST] <beastwick> right, so I cap what it can use
[16:05:08 CEST] <BtbN> For streaming you usually want plain old CBR.
[16:05:19 CEST] <beastwick> i think you're right hah hah :D
[16:05:40 CEST] <beastwick> so just trust that it is streaming in cbr even tho the reported output may appear higher?
[16:06:22 CEST] <bencoh> no, just don't force a crf if you want a cbr stream
[16:06:38 CEST] <beastwick> I can use my vbv options without crf?
[16:06:46 CEST] <beastwick> like just specify a -bitrate
[16:09:25 CEST] <bencoh> (hm I wonder if that's actually meant to work, since crf+maxrate/bufsize is mentioned in ffmpeg wiki ... never tried that combination)
[16:09:47 CEST] <furq> well minrate is mentioned in the ffmpeg wiki a bunch of times in spite of apparently doing nothing
[16:09:51 CEST] <furq> so i wouldn't trust that too much
[16:09:58 CEST] <bencoh> huhu
[16:11:30 CEST] <beastwick> how come the documentation is kind of all over the place?
[16:11:34 CEST] <beastwick> options that aren't used
[16:11:40 CEST] <beastwick> conflicting answers of what stuff does
[16:11:43 CEST] <beastwick> lol
[16:13:29 CEST] <beastwick> bencoh I can confrim that the crf + maxrate/bufsize thing works, especially when restricting the bufsize allotted to a single frame. However, I think it is intuitively wrong to do it this way. CBR makes sense for live streaming to me, I'm not saying it doesn't. It's like I'm using CRF to achieve what I could just get with CBR.
[16:13:51 CEST] <bencoh> because a lot of people have no clue what's actually going there and/or do not really understand the underlying concepts, but they eventually write a piece of "documentation" based on their own experience, I'd say
[16:14:42 CEST] <beastwick> :( that seriously sucks lol, I guess the x264 devs didn't give official docs? Their option explanations are pretty minimal :(
[16:15:51 CEST] <furq> beastwick: if you mean the wiki then yeah, there's a lot of cargo cult stuff on there
[16:19:52 CEST] <bencoh> beastwick: for x264 I usually check --fullhelp and source code
[16:21:15 CEST] <beastwick> bencoh I am going to do that now. Source code I guess is the best documentation, if available.
[16:21:31 CEST] <beastwick> well... if it's readable hah
[16:43:57 CEST] <TwinTailed> Hi, anyone experienced in the new av_send_frame()/av_send_packet() functions?
[16:48:10 CEST] <TwinTailed> ok, so I am using avcodec_send_packet(), but it is returning  AVERROR(EINVAL) on the video stream
[16:48:46 CEST] <TwinTailed> so I have sent avcodec_send_frame() with NULL as the packet input
[16:49:13 CEST] <TwinTailed> and then made a loop to keep using avcodec_receive_packet() until it returns AVERROR_EOF
[16:49:32 CEST] <TwinTailed> the problem is that it gets stuck in an infinite loop and never returns AVERROR_EOF
[16:53:09 CEST] <flux> so it keeps returning you new frames? or does it return some other error?
[16:53:54 CEST] <TwinTailed> error -22, which is Invalid Argument I guess
[16:53:59 CEST] <TwinTailed> flux: ^
[16:54:30 CEST] <flux> I guess you meant send_packet instead of send_frame?
[16:55:04 CEST] <TwinTailed> flux: http://pastebin.com/mtFA9fge
[16:55:05 CEST] <flux> well, I wouldn't probably expect the receive_frame to rebound after returning an error (so that it would eventually return EOF), maybe this behavior isn't well specified
[16:56:13 CEST] <flux> I would check the avcodec_send_frame error as well, and break on any error. but that's just me :)
[16:56:32 CEST] <TwinTailed> flux: look starting from line 194
[16:56:37 CEST] <TwinTailed> in the pastebin i sent
[16:56:39 CEST] <flux> (also surely you need to av_interleaved_write those frames you receive in the loop)
[16:56:46 CEST] <flux> yes I see it.
[16:57:11 CEST] <TwinTailed> so what should i do?
[16:57:32 CEST] <flux> not call avcodec_receive_packet after it returns an error?
[16:58:04 CEST] <TwinTailed> you mean inside if(eret == AVERROR(EINVAL))?
[16:59:23 CEST] <flux> yes
[16:59:30 CEST] <TwinTailed> flux: but if i use break; then stream 0 will never write anything
[16:59:39 CEST] <TwinTailed> since it always returns AVERROR(EINVAL)
[16:59:49 CEST] <flux> well, I understand you already get an error when decoding the original stream?
[16:59:54 CEST] <flux> isn't that something that should work first?
[17:00:14 CEST] <TwinTailed> flux: what error when decoding?
[17:00:43 CEST] <flux> Wed174809 < TwinTailed> ok, so I am using avcodec_send_packet(), but it is returning  AVERROR(EINVAL) on the video stream
[17:00:54 CEST] <flux> it seems to me you might not even have any material to encode.
[17:01:29 CEST] <TwinTailed> flux: there is always an else with a printf. I mistaken there, I should have written send_frame() instead
[17:01:41 CEST] <BtbN> TwinTailed, you realize EINVAL is an actual error?
[17:01:49 CEST] <BtbN> If it wanted you to read out frames, it would be EAGAIN
[17:02:14 CEST] <TwinTailed> EINVAL  AVERROR(EINVAL): codec not opened, it is an encoder, or requires flush
[17:02:24 CEST] <TwinTailed> requires flush
[17:02:46 CEST] <BtbN> that does not mean "read out frames, "but calling the flush function.
[17:03:13 CEST] <BtbN> it will return EAGAIN if it's "full" and wants you to read frames
[17:03:50 CEST] <TwinTailed> avcodec_flush_buffers() you mean?
[17:04:21 CEST] <BtbN> it most likely means something failed/you passed an invalid parameter.
[17:04:40 CEST] <TwinTailed> BtbN: http://pastebin.com/mtFA9fge
[17:05:01 CEST] <TwinTailed> BtbN: Can you please view my code?
[17:05:06 CEST] <flux> if you have a known valid video file (ie. works with ffplay without warnings), then I think means you are not required to do any flushing
[17:05:10 CEST] <TwinTailed> I have been struggling with encoding H264 for some time
[17:05:58 CEST] <BtbN> So far there is _no_ encoder in ffmpeg that implements this new API
[17:06:10 CEST] <BtbN> so you are allways just using the internal wrapper around the old one
[17:07:02 CEST] <TwinTailed> BtbN: but shouldnt the old ones work?
[17:07:08 CEST] <BtbN> hm?
[17:07:26 CEST] <BtbN> All codecs work, the new api will just internally use the old one if a codec doesn't natively support it.
[17:07:31 CEST] <TwinTailed> BtbN: avcodec_encode_video2 you mean?
[17:07:41 CEST] <BtbN> or decode, yes
[17:07:44 CEST] <flux> but the new interface is nicer IMO anyway, so better just use that one
[17:07:54 CEST] <BtbN> yes, and it's also not deprecated
[17:08:07 CEST] <TwinTailed> thats why i am using it, for long term support
[17:08:09 CEST] <BtbN> but that means the actual flush/eagain/... stuff doesn't happen yet.
[17:08:22 CEST] <BtbN> So if you are getting an EINVAL, that's an actual error from the codec.
[17:08:37 CEST] <TwinTailed> BtbN: why did they add this to the doxygen then http://ffmpeg.org/doxygen/trunk/group__lavc__encdec.html?
[17:08:48 CEST] <flux> I read the documentation as to mean that if the stream encounters an error, you are to reset the stream with avcodec_flush, and then carry on your business
[17:08:59 CEST] <flux> that mechanism doesn't work yet?
[17:09:15 CEST] <BtbN> It does. But if you get an error from the start.. well, there was an error then.
[17:09:28 CEST] <flux> sure, but that's going to be true in the future as well :)
[17:09:31 CEST] <BtbN> TwinTailed, add what?
[17:10:13 CEST] <flux> I think it's reasonable application behavior to just abort if the first packet returns an error, unless you're trying to write some super-robust player
[17:10:33 CEST] <TwinTailed> BtbN: The explanation about the rereading packets and sending null packets
[17:10:38 CEST] <beastwick> hi again, quick question, if I choose to stick with my CRF strategy. Does a lower CRF potentially use more CPU? Or is CPU usage more influenced by the profile and the things it turns on and off?
[17:10:59 CEST] <BtbN> TwinTailed, because that's how it works? Also, that doxy page does not mention EINVAL anywhere.
[17:11:05 CEST] <BtbN> just EAGAIN and EOF
[17:11:14 CEST] <beastwick> I'd like to make sure that when it is compressing stuff, that it's working hard. I guess that's a profile thing.
[17:11:37 CEST] <flux> https://ffmpeg.org/doxygen/3.1/group__lavc__decoding.html#ga58bc4bf1e0ac59e27362597e467efff3 mentions EINVAL
[17:11:37 CEST] <TwinTailed> BtbN: why am i getting AVERROR(EINVAL) when encoding anyway?
[17:11:54 CEST] <flux> twintailed, you have somehow misconfigured the encoder
[17:11:55 CEST] <BtbN> because an error happened.
[17:12:21 CEST] <TwinTailed> Line 63 in my code is the encoder configuration
[17:12:56 CEST] <TwinTailed> I have tried using transcoding.c configurations, but they also give the same error
[17:13:06 CEST] <BtbN> Did you look at the log? It probably complains about something that's wrong.
[17:13:31 CEST] <flux> btw, you don't check return values from avcodec_open2
[17:13:46 CEST] <flux> always when hunting issues like these, check return values :)
[17:14:04 CEST] <BtbN> yes, the codec not being opened is a good reason for decoding to fail.
[17:14:34 CEST] <flux> you should also review what values you're writing to those fields beginning at line 77
[17:14:38 CEST] <flux> perhaps some don't make sense
[17:15:17 CEST] <flux> I seem to recall there's a piece of code in transmuxing.c that sets the global header flag, you dn't seem to set it
[17:15:36 CEST] <TwinTailed> flux: encoder opening returns -542398533
[17:15:56 CEST] <TwinTailed> i will use make error string
[17:16:26 CEST] <TwinTailed> -542398533: Generic error in an external library
[17:16:29 CEST] <BtbN> and look at the log output
[17:16:34 CEST] <TwinTailed> so the problem is not from my side?
[17:16:39 CEST] <flux> also set log level to debug
[17:16:49 CEST] <flux> the problem is almost certainly mentioned there
[17:16:52 CEST] <TwinTailed> what level is that?
[17:16:57 CEST] <TwinTailed> i mean its integer
[17:17:13 CEST] <BtbN> AV_LOG_LEVEL_DEBUG
[17:17:20 CEST] <BtbN> or something like that
[17:17:23 CEST] <TwinTailed> 48
[17:17:28 CEST] <TwinTailed> AV_LOG_DEBUG
[17:17:47 CEST] <BtbN> you should not need to care about its litteral value
[17:18:45 CEST] <TwinTailed> http://pastebin.com/A5pBugKD
[17:18:58 CEST] <TwinTailed> here is the debug output (Mixed with the normal output)
[17:19:10 CEST] <flux> well, there you have it?
[17:19:21 CEST] <flux> at least the messages from libx264 seem very informative
[17:20:21 CEST] <flux> just disable all your options while for the purpose of making it work.
[17:20:59 CEST] <kepstin> I thought libavcodec was fixed to use reasonable defaults for x264 tho, so you shouldn't see that any more...
[17:21:11 CEST] <kepstin> unless TwinTailed is using a really old library...? :/
[17:21:12 CEST] <flux> it doesn't seem like he's using the defaults, though
[17:22:02 CEST] <kepstin> the code for that error message checks something like 8 different options to see if they all match the old ffmpeg "bad defaults", so that would be a lot of poorly set explicit options :/
[17:22:20 CEST] <flux> :)
[17:22:44 CEST] <flux> I guess the ffmpeg cannot be too old, because he's using the api introduced at january? february?
[17:23:02 CEST] <kepstin> oh, huh, it's actually using a score system, where some options are lots of points, and some are just a few
[17:23:13 CEST] <TwinTailed> Its the latest library
[17:23:18 CEST] <flux> quite a magnificent hack
[17:23:21 CEST] <TwinTailed> i have downloaded today in the morning
[17:23:27 CEST] <furq> is it the latest libx264
[17:23:35 CEST] <TwinTailed> furq: Im on windows
[17:23:38 CEST] <kepstin> so e.g. if you set keyint_max to 12 or qp_max to 31, it'll print that message almost guaranteed
[17:24:32 CEST] <TwinTailed> so what should i do now?
[17:24:33 CEST] <flux> it's like hand-written expert system for determining library compatibility. what's next, tensorflow-based neural network?-)
[17:24:44 CEST] <flux> twintailed, did you install a recent libx264 as well?
[17:24:47 CEST] <kepstin> furq: https://git.videolan.org/?p=x264.git;a=blob;f=encoder/encoder.c;h=f733adf2d97a7398e676aa7a549b6eb0ee0e9a5a;hb=HEAD#l617
[17:25:05 CEST] <TwinTailed> flux: I am on windows, libx264 comes with ffmpeg on windows, right?
[17:25:11 CEST] <flux> oh, I don't know
[17:25:19 CEST] <furq> is vpre even still a thing
[17:25:20 CEST] <TwinTailed> Linux dependencies is a different story
[17:25:29 CEST] <BtbN> nothing comes with ffmpeg
[17:25:33 CEST] <flux> I would at least simplify the options you set to the encoder A LOT, like down to the essentialss of width, height and pixel format
[17:25:37 CEST] <BtbN> whatever you build in comes with it
[17:25:40 CEST] <kepstin> furq: those defaults in ffmpeg were fixed a *long* time ago :)
[17:26:01 CEST] <TwinTailed> BtbN: I guess the default windows build has --enable-x264
[17:26:07 CEST] <TwinTailed> or whatever that option was
[17:26:12 CEST] <BtbN> Which "default windows build"?
[17:26:23 CEST] <furq> probably the one linked on ffmpeg.org
[17:26:23 CEST] <BtbN> There is no official one. You probably mean Zeranoe?
[17:26:24 CEST] <flux> does it? I wouldn't think so, because that would require --enable-gpl as well
[17:26:30 CEST] <TwinTailed> BtbN: https://ffmpeg.zeranoe.com/builds/
[17:26:37 CEST] <kepstin> TwinTailed: whoever compiled your windows build (there's no "default") must have explicitly linked it with x264, possibly statically.
[17:26:53 CEST] <TwinTailed> BtbN: yeah, Zeranoe
[17:26:58 CEST] <BtbN> zeranoe even has a list of libs he uses
[17:27:07 CEST] <TwinTailed> he uses libx264
[17:27:12 CEST] <bencoh> indeed
[17:27:12 CEST] <flux> heh, "Custom Build Quote Request"
[17:27:20 CEST] <bencoh> at least, that's what's mentioned
[17:27:43 CEST] <kepstin> if you're using a recent zeranoe build, it should have a decently modern libx264.
[17:27:45 CEST] <flux> I hope he makes a few bucks for that service.
[17:28:48 CEST] <strongcoffee> I wonder how much bandwidth he chews through on his site
[17:29:17 CEST] <strongcoffee> as the static builds are quite large a download
[17:30:37 CEST] <kepstin> probably not that much, since it's mostly devs and enthusiasts who use them. Smallish audience.
[17:30:45 CEST] <furq> yeah
[17:30:56 CEST] <furq> i pay something like $8/qtr for 2TB/month, which would be 50k downloads
[17:31:18 CEST] <furq> you can doubtless get cheaper bandwidth than that
[17:37:49 CEST] <TwinTailed> Guys, I need help here :/
[17:38:05 CEST] <TwinTailed> its a blessing I've got all that attention on this IRC
[17:38:13 CEST] <TwinTailed> I might never get it again
[17:38:18 CEST] <TwinTailed> so please help me :'(
[17:40:13 CEST] <TwinTailed> BtbN: So the problem is in my code or libx264 or ffmpeg?
[17:41:08 CEST] <kepstin> TwinTailed: the problem is almost certainly in your code
[17:41:13 CEST] <flux> twintailed, does transmuxing.c work for you?
[17:41:20 CEST] <flux> or muxing.c
[17:41:49 CEST] <flux> if muxing.c doesn't do H264 out of the box, you can just stick AV_CODEC_H264 into the right place to make that happen
[17:41:59 CEST] <flux> if that works, it means your code is at fault
[17:42:14 CEST] <flux> I don't remember if muxing.c was update to use avcodec_send_frame, though..
[17:43:07 CEST] <TwinTailed> flux: http://pastebin.com/W2JDP6K4
[17:43:11 CEST] <TwinTailed> thats what i get
[17:43:25 CEST] <TwinTailed> h264 doesn't support codec_tags
[17:43:54 CEST] <flux> twintailed, get from what?
[17:44:07 CEST] <TwinTailed> kepstin: I challenge u to find it: http://pastebin.com/mtFA9fge
[17:44:14 CEST] <TwinTailed> flux: transmuxing
[17:44:25 CEST] <TwinTailed> flux: remuxing.c
[17:45:10 CEST] <kepstin> TwinTailed: as a start, drop all the lines like "p2C[i]->rc_max_rate = pC[i]->rc_max_rate;"
[17:45:18 CEST] <kepstin> TwinTailed: that's probably what's causing the x264 error
[17:45:35 CEST] <TwinTailed> kepstin: "like" ?
[17:45:43 CEST] <kepstin> (aside from the minimum ones required to work)
[17:45:58 CEST] <TwinTailed> kepstin: what are the minimum?
[17:46:11 CEST] <kepstin> TwinTailed: I'm just repeating what furq told you do do earlier :/
[17:46:27 CEST] <kepstin> TwinTailed: probably width, height, pixel format
[17:46:33 CEST] <kepstin> time base
[17:47:37 CEST] <TwinTailed> kepstin: still getting the same error
[17:50:25 CEST] <TwinTailed> kepstin: anything else to try?
[17:51:58 CEST] <kepstin> TwinTailed: hmm. looks like you're not initializing the AVCodecContext using the encoder
[17:52:19 CEST] <TwinTailed> I should alloc_Context u mean?
[17:52:47 CEST] <kepstin> TwinTailed: before doing anything else, try doing encoder->init(p2C[i]); maybe?
[17:53:00 CEST] <kepstin> i dunno if there's a more ideomatic way of handling that
[17:53:05 CEST] Action: kepstin doesn't use the api much
[17:53:53 CEST] <kepstin> I could be completely wrong there of course
[17:54:00 CEST] <kepstin> I should be referencing the examples :)
[17:54:50 CEST] <kepstin> yeah, i'm probably wrong there.
[17:57:26 CEST] <kepstin> man, it's hard to follow code when most of the variables are named pC or p2C
[17:58:33 CEST] <platzhirsch> Any idea why -listen 1 would not work? Looks like it trys to connect to the URL given with -i
[17:59:10 CEST] <TwinTailed> kepstin: sorry about that. It seems using avcodec_alloc_context(encoder) for p2C rather than p2C[i] = oStream->codec works for the first packet
[17:59:24 CEST] <TwinTailed> but the header is now returning error -22 invalid argument
[17:59:27 CEST] <platzhirsch> ./ffmpeg -listen 1 -i rtmp://0.0.0.0:1935/stream/default
[17:59:44 CEST] <platzhirsch> works with FFmpeg 3.0 I have here, but just compiled a nightly build and it doesn't here
[18:00:39 CEST] <kepstin> platzhirsch: hmm, it might be a difference between the internal ffmpeg rtmp support and using the 'librtmp' library.
[18:01:02 CEST] <platzhirsch> right, good point. Because I recompiled it with librtmp support kepstin
[18:01:47 CEST] <platzhirsch> tried to dig a bit through the source code, but not luck so far
[18:02:03 CEST] <kepstin> platzhirsch: if it doesn't work with librtmp, try recompiling without it.
[18:02:04 CEST] <BtbN> I don't think the librtmp one supports listen mode at all.
[18:02:21 CEST] <kepstin> i think at this point the internal rtmp is better for most uses.
[18:03:14 CEST] <platzhirsch> hah :-/ well I see. Because I get input/output error when I try to push a RTMP stream from Nginx rtmp module (and also from a hardware encoder). And I don't get any debugs/traces out of this to understand what's wrong with it, so I guess I hoped with librtmp it works better
[18:04:37 CEST] <platzhirsch> But thanks a lot BtbN, kepstin. At least I am not following a dead end
[18:06:14 CEST] <kepstin> platzhirsch: using ffmpeg to pull from external rtmp is probably a lot better tested than acting as a "server". I didn't even know listen mode was available at all :/
[18:06:50 CEST] <BtbN> or just tell nginx-rtmp to spawn ffmpeg for you.
[18:12:12 CEST] <platzhirsch> good point
[18:12:22 CEST] <platzhirsch> thanks. That's some inspiring ideas
[18:18:53 CEST] <TwinTailed> kepstin: I got it working :) You got me the starting line so thank you :)
[18:19:08 CEST] <TwinTailed> kepstin: but the generated video is only 1 second long
[18:19:13 CEST] <TwinTailed> only one frame is shown
[18:20:30 CEST] <TwinTailed> kepstin: http://pastebin.com/sbCZwY30 here is the code
[18:24:11 CEST] <platzhirsch> perfect, that works
[18:31:43 CEST] <TwinTailed> BtbN: What is exactly a PTS? Does it have to do with my video being just 1 second long?
[18:32:04 CEST] <BtbN> The presentation timestamp of a frame/packet.
[18:32:12 CEST] <TwinTailed> BtbN: And how do i set it? I should set the pts in the AVPacket?
[18:32:26 CEST] <BtbN> the decoder/demuxer sets it.
[18:32:48 CEST] <TwinTailed> but my generated video is just 1 second long, only one frame shows
[18:33:02 CEST] <TwinTailed> even though its 30 MB large
[18:33:30 CEST] <BtbN> Well, something went wrong then.
[18:33:55 CEST] <TwinTailed> i have fixed the packet writing and reading problem i had earlier
[18:33:59 CEST] <TwinTailed> it now returns now errors
[18:34:04 CEST] <TwinTailed> the encoder open normally
[18:34:43 CEST] <strongcoffee> I remember having an issue with pts when adding the speed, since trim wasn't calculate correctly, though I haven't read the buffer to see if it's related
[18:35:06 CEST] <strongcoffee> made it look like the video was like a single frame
[18:35:17 CEST] <TwinTailed> did u fix it?
[18:35:47 CEST] <strongcoffee> yeah, someone here helped with the syntax. Are you using such a filter?
[18:36:15 CEST] <TwinTailed> no i am not using a filter
[18:47:07 CEST] <whald> hi! i'm using libav* to decode video stream, which works pretty well for most streams by giving avformat_open_input a proper url and then doing the usual libav* stuff
[18:48:15 CEST] <whald> except for a webcam which provides sdp files over http, where avcodec_send_packet keeps complaining about invalid data forever.
[18:48:55 CEST] <whald> with ffplay the same URL works, so there's likely something i'll have to do for the sdp case that i'm missing. any hints?
[18:54:38 CEST] <beastwick> x264 doesn't drop frames does it? It just degrades quality?
[19:00:41 CEST] <DHE> x264 itself does not drop frames. but ffmpeg/libav may drop frames to meet whatever criteria are necessary for the job
[19:01:26 CEST] <TwinTailed> DHE: When encoding with H264, I am getting a 1 second video with just one frame displaying. Is it a pts/dts problem?
[19:02:42 CEST] <DHE> you're doing this programatically. when you finish reading your input, you are properly flushing the encoder right? The encoder will buffer a lot of frames (sometimes several seconds worth) and you're collecting them all when you're done, right?
[19:03:19 CEST] <DHE> ah, found it in the backlog..
[19:03:28 CEST] <TwinTailed> I decode then encode in the same while loop
[19:04:01 CEST] <TwinTailed> DHE: http://pastebin.com/8m419rE7
[19:04:04 CEST] <TwinTailed> line 188
[19:10:26 CEST] <TwinTailed> Timestamps are unset in a packet for stream 0. This is deprecated
[19:10:31 CEST] <TwinTailed> How to fix that?
[19:20:48 CEST] <TwinTailed> how do i set the pts/ts of the packet/frame i am about to encode?
[19:33:28 CEST] <DelphiWorld> heu
[19:33:30 CEST] <DelphiWorld> hey
[19:33:48 CEST] <DelphiWorld> jkqxz: just fyi: the IPVTL chinese transcoding software is using ffmpeg with libmfx
[19:35:12 CEST] <sunny26> Hi, i am seeing a very small memory leak with my custom decoder
[19:35:36 CEST] <sunny26> I have also posted the same on this link http://libav-users.943685.n4.nabble.com/Libav-user-Memory-leak-while-using-ff-get-buffer-td4662720.html
[19:35:48 CEST] <sunny26> please some one help
[19:38:37 CEST] <TwinTailed> sunny26: put ur code in pastebin.com and paste the link to it here so people can help u
[19:51:40 CEST] <sunny26>  I found out that in some decoders the incoming avframe pointer is unreferenced using av_frame_unref api, and then ff_get_buffer is called
[19:51:56 CEST] <sunny26> Can someone please explain why such things are done ! I am so much confused
[19:52:06 CEST] <Mista_D> can -f concat be used to save three segmants from video fiel as one continious file? If I use multiple "inpoint" and "outpoint" only first set is executed.
[19:54:23 CEST] <BtbN> sunny26, because the decoder takes ownership of the frame and can do whatever it wants? Also, what decoder gets an incoming frame? They get packets.
[19:57:52 CEST] <BtbN> or do you mean the output frame? That's just an output parameter.
[20:03:54 CEST] <sunny26> BtbN, So I have to unref the incoming frame pointer and incoming packets both
[20:04:04 CEST] <sunny26> ??
[20:04:39 CEST] <BtbN> what do you mean? Of course you have to unref the frame you get out of it, if you don't send it somewhere that takes ownership.
[20:06:14 CEST] <sunny26> BtbN, I mean i am unrefing the incoming av frame pointer, do I also have to unref the incoming av packet pointer !
[20:06:39 CEST] <sunny26> before I do any processing on them !
[20:06:43 CEST] <BtbN> incoming? Are you writing a decoder?
[20:06:50 CEST] <sunny26> Yup
[20:07:19 CEST] <sunny26> If you can see this link http://libav-users.943685.n4.nabble.com/Libav-user-Memory-leak-while-using-ff-get-buffer-td4662720.html
[20:07:27 CEST] <sunny26> I have posted my doubts
[20:07:37 CEST] <sunny26> I am very new to ffmpeg
[21:46:22 CEST] <SouLShocK> well this is curious. the same cmdline produces twice the speed in ubuntu as it does in windows. encoding wav file to mp3 with both source and destination being on a samba share
[21:47:18 CEST] <SouLShocK> I wonder if it is windows' network drivers or ffmpeg itself
[21:47:56 CEST] <furq> does it make any difference if you don't write to a cifs share
[21:48:21 CEST] <SouLShocK> yes. if I write to the local sdd it becomes the same speed as ubuntu over cifs
[21:48:33 CEST] <SouLShocK> local ssd*
[21:48:49 CEST] <furq> cifs throughput is generally crap
[21:49:12 CEST] <furq> maybe linux is caching writes more aggressively or something
[21:49:47 CEST] <SouLShocK> any suggestion for better suited protocols for this purpose?
[21:49:56 CEST] <furq> not really
[21:50:17 CEST] <furq> i mean ideally just don't write straight onto a cifs share, write locally and copy
[21:50:49 CEST] <furq> if it's not a bottleneck on linux then maybe there's some stuff you can tune, but knowing windows then probably not
[21:51:22 CEST] <SouLShocK> yeah probably not on windows. I could of course run ffmpeg on linux instances, though that would entail a bit of extra work
[21:51:40 CEST] <furq> maybe nfs has better performance, i don't know
[21:51:48 CEST] <furq> but it's definitely much more hassle to use on windows
[21:52:22 CEST] <SouLShocK> worth a shot
[21:52:41 CEST] <furq> it looks like you can tune the cifs buffer size on windows
[21:52:48 CEST] <furq> https://blogs.msdn.microsoft.com/openspecification/2009/04/10/smb-maximum-transmit-buffer-size-and-performance-tuning/
[21:53:11 CEST] <SouLShocK> ah
[21:53:30 CEST] <tdr> furq, nfs is also less secure on windows since the service for unix lets you map users and its harder to lock down who can't become any user on the share
[21:53:37 CEST] <furq> i wouldn't bother with nfs if you have windows clients
[21:53:45 CEST] <furq> it's just generally bad
[21:54:41 CEST] <tdr> pick somehting neutral like gluster, but also cifs shouldnt be too terrible on linux
[21:54:50 CEST] <furq> yeah cifs on linux is fine
[21:55:18 CEST] <tdr> better performance than nfs on linux anyway
[21:55:32 CEST] <SouLShocK> problem is clients are windows
[21:55:37 CEST] <tdr> er than on windows i mean
[21:55:39 CEST] <DHE> linux's cifs will buffer writes just like you do on disk based systems
[21:56:25 CEST] <tdr> just sucks having to set up creds files etc
[21:57:55 CEST] <SouLShocK> furq that tweak bumped it from 21x speed to 24x. on ubuntu it gets about 45x so not much gained
[22:02:44 CEST] <furq> https://msdn.microsoft.com/en-us/library/windows/hardware/dn567661(v=vs.85).aspx#clients
[22:02:47 CEST] <furq> there's some more stuff there
[22:06:43 CEST] <TwinTailed> [libx264 @ 01ff1940] non-strictly-monotonic PTS
[22:07:16 CEST] <TwinTailed> After the H264 video is encoded and written, I get a 1 second video with 1 frame shown only
[22:07:39 CEST] <TwinTailed> I guess its a problem with settings the pts/dts which I have no idea about how they are set
[22:09:45 CEST] <SouLShocK> those tweaks do nothing for the speed, unfortunately
[22:10:21 CEST] <SouLShocK> I guess I'm down to either write the file to local hd and copy it or use ubuntu
[22:13:06 CEST] <SouLShocK> also tried this https://redmondmag.com/articles/2014/05/16/network-performance-problems.aspx to no avail
[22:25:03 CEST] <SouLShocK> yeah it's definetely the network driver. windows ffmpeg maxes out around 50x speed when writing to both the local hdd and to the null output, but 25x when writing to a windows network share. damn
[22:26:03 CEST] <tdr> sounds like a reason to switch switch platforms for ffmpeg
[22:26:19 CEST] <SouLShocK> yeah that is starting to look more attractive
[22:26:55 CEST] <tdr> alot of people dont move to linux just to like linux, but do it because it works
[22:27:31 CEST] <SouLShocK> the challenge will be to get our IT department to deploy a bunch of linux instances for me to run ffmpeg, since this is for a big corporate installation
[22:27:37 CEST] <SouLShocK> but that I can handle
[22:28:15 CEST] <tdr> SouLShocK, as long as they all need to be pretty much identical, that shouldnt be a hard sell
[22:28:33 CEST] <tdr> you guys a virtual shop or physicals?
[22:29:18 CEST] <SouLShocK> mostly virtuals
[22:29:27 CEST] <tdr> ah should be easy for them then
[22:29:46 CEST] <SouLShocK> yeah. also twice the speed should be motivation
[22:30:06 CEST] <tdr> yeah, a real world reason for the need always helps
[22:33:03 CEST] <SouLShocK> thanks for the help guys, you are always very helpful :)
[22:39:17 CEST] <furq> SouLShocK: i imagine there is some setting buried away on windows that'll do what you want, but it's probably less hassle to just ditch it
[22:39:49 CEST] <mrelcee> any time you can add a windows schwack to your kill record is a good time..
[22:39:53 CEST] <furq> if these are vms just for ffmpeg then windows is a waste anyway
[22:40:07 CEST] <furq> no point running a gui on there at all
[23:04:51 CEST] <SouLShocK> yea they are. well ffmpeg and a .net program. but with .net core that should run fine on linux
[00:00:00 CEST] --- Thu Sep 22 2016