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

[burek]

[00:05] <Shootfast> cbsrobot : Here's my command and output http://pastebin.com/LiHcd4g9
[00:07] <cbsrobot> so what colorrange are your jpegs ?
[00:23] <Shootfast> cbsrobot: I have a black square at 0, another square at 64 / 1023, white square at 1, and another at 940/1023 saved in linear colorspace from nuke http://imgur.com/8Fgjs
[00:24] <cbsrobot> as jpeg ?
[00:24] <cbsrobot> thats not 10 bits !
[00:25] <cbsrobot> just saying, so its 8bit full range
[00:28] <Shootfast> It should be 8 bit full range
[00:30] <cbsrobot> so it's 0 16 234 and 255
[00:43] <Shootfast> I'm not very experienced with color, so I'll try my best to explain the issue (im kinda the middle man between artists and editors)
[00:45] <Shootfast> I export that image from Nuke on a mac (using Quicktime), and when loaded into the avid, both black squares will appear to be the same, and both white squares will appear to be the same
[00:45] <Shootfast> On linux, I don't have the option to directly export to dnxhd .mov, so I'm writing the image out as jpgs (or tiffs, or pngs, doesn't seem to make a difference), then turning it into a .mov via ffmpeg.
[00:46] <Shootfast> When I load the ffmpeg version into the avid, I can see the difference between the black squares, and the white squares
[00:49] <Shootfast> The avid appears to know about the full range on the apple quicktimes, as you can do a color comparison between the black squares, and get different values. So It apparently applies this '709' colorspace internally
[00:50] <cbsrobot> Shootfast: I've nuke and dnxhd codec here
[00:50] <cbsrobot> so I'm looking at it
[00:51] <cbsrobot> it seems the output is still sRGB
[00:51] <cbsrobot> even with colormatrix filter applied it stays sRGB
[00:59] <Shootfast> cbsrobot: So does that mean that nuke is my problem? Should I be outputing to a format other than jpg?
[01:00] <cbsrobot> no wait
[01:03] <cbsrobot> you could write directly  rec709 to jpeg within nuke
[01:04] <cbsrobot> when I transcode it to dnxhd with ffmpeg and I load it into nuke as rec709 it matches
[01:05] <Shootfast> cbcrobot: Is your Nuke on mac or linux?
[01:06] <cbsrobot> I have it on mac here
[01:06] <cbsrobot> tomorrow I can check on linux
[01:07] <cbsrobot> does it make a difference ?
[01:08] <Shootfast> Well the linux nuke can't write directly to dnxhd .mov
[01:08] <Shootfast> so that's what I'm trying to match
[01:08] <Shootfast> A mac written dnxhd, and a linux nuke > jpg? > ffmpeg > dnxhd
[01:10] <cbsrobot> f.ex
[01:18] <cbsrobot> Shootfast: you could also output some 16 bit images and encode them to 10 bit dnxhd
[01:20] <cbsrobot> there is also a after render hook in nuke that could trigger the dnxhd encoding
[01:21] <Shootfast> cbsrobot: What would be an appropriate 16 bit image format that ffmpeg can understand?
[01:23] <cbsrobot> you could go with exr or tif
[01:23] <cbsrobot> check first which format ffmpeg decodes faster for your workflow
[01:25] <Shootfast> I had trouble getting ffmpeg to read EXR's from nuke before, but I'll give 16 bit tiff a go
[01:25] <cbsrobot> Shootfast: what kind of trouble ?
[01:29] <Shootfast> actually, just tested it again. It works after changing the compression type, but spews some messages about "Found more than one compression attribute"
[01:33] <Shootfast> Unfortunately my editor isn't around at the moment, So I can't test it in the avid
[01:38] <Shootfast> Thanks for your help though, If this doesn't work I think I'll have to put together a better test case and post to the mailing list
[01:40] <cbsrobot> sure
[10:30] <sebouh_> hi. i am trying to re-stream a vlc rtsp stream to rtmp using ffmpeg. changing the container on vlc to ts is causing ffmpeg to compain: Invalid data found when processing input
[10:31] <sebouh_> the ffmpeg command is: ffmpeg -i rtsp://localhost:8554/test.sdp -acodec copy -vcodec copy -f flv rtmp://localhost/live/mystream
[10:32] <sebouh_> I also get method SETUP failed: 459 Aggregate operation not allowed
[10:47] <jacobs1> hi, I am using ffserver to stream a video file to many clients, is it possible to config ffserver to synchronize all the clients ?
[10:57] <derric> I'm trying to compile ffmpeg with --enablex264 and I keep getting an undefined reference err.
[10:57] <derric> s/--enablex264/--enable-x264/
[10:58] <JEEB> it's --enable-libx264
[10:58] <JEEB> IIRC
[10:58] <JEEB> also what kind of undefined reference?
[10:59] <JEEB> pastebin please
[10:59] <derric> The err comes from the libavcodec section, and it's as if the files in that section are unable to find the header for the external x264 lib.
[10:59] <JEEB> well yes, libavcodec/libx264.c is what uses libx264
[10:59] <JEEB> do you have libx264 installed?
[10:59] <JEEB> also please pastebin the compilation log
[11:00] <JEEB> as much of it as possible
[11:01] <derric> JEEB: yes I have libx264 installed.  Just built it.
[11:01] <JEEB> see what I asked for :P
[11:02] <derric> It ends up like undefined reference 'open_x264_encode_129'
[11:03] <JEEB> show the damn compilation log in a pastebin
[11:03] <JEEB> thank you
[11:04] <JEEB> also how did you compile/install libx264?
[11:04] <derric> That's the open encoder string from the x264 lib I just built, and If the file had the x264 head for that which is in /usr/local/include it would know what that refrence meant.
[11:04] <derric> It's recompiling without x264 option at the moment to see if that even compiles.
[11:04] <JEEB> ...
[11:05] <JEEB> how did you compile x264 and could you please provide more info so I can actually gawd damn help you
[11:05] <derric> I compiled x264 with --enable-shared --enable-static options.
[11:05] <JEEB> ok
[11:05] <JEEB> also which OS are you on?
[11:05] <JEEB> bsd? linux?
[11:05] <derric> linux
[11:06] <derric> 2.6.39.4
[11:06] <derric> On a debian squeeze system
[11:06] <JEEB> ok, so you most probably have /usr/local/include|lib in the search paths
[11:07] <JEEB> now see if you have multiple copies of x264.h on your system
[11:07] <derric> That would be in echo $PATH right?
[11:07] <JEEB> no
[11:07] <sebouh_> Hi. anyone had the chance to look into my issue?
[11:07] <sebouh_> i am trying to re-stream a vlc rtsp stream to rtmp using ffmpeg. changing the container on vlc to ts is causing ffmpeg to compain: Invalid data found when processing input
[11:08] <sebouh_> I also get method SETUP failed: 459 Aggregate operation not allowed
[11:08] <sebouh_> the ffmpeg command is: ffmpeg -i rtsp://localhost:8554/test.sdp -acodec copy -vcodec copy -f flv rtmp://localhost/live/mystream
[11:08] <derric> I have a few different copies, although they are each tagged with a version suffix.  only one x264.h that is for the recently built lib.
[11:09] <JEEB> also I recommend you try out with just a static library first
[11:09] <JEEB> also, ld --verbose |grep "SEARCH" for linking search path, and the header search path for gcc was...
[11:10] <JEEB> `gcc -print-prog-name=cc1` -v
[11:10] <JEEB> should do that
[11:10] <derric> JEEB: It will be a while before I can get you a compile log with the err.
[11:11] <derric> JEEB: I've been at this for a while, I tried with just static, with just shared, with both...
[11:12] <JEEB> I'm not exactly sure which error at which state you were exactly getting, but if it's during linking it's "could not find a library with the specified function name referenced", and if it's during compilation it's "could not find a function defined in headers" -- I think some other libx264 is popping up in your search path and it doesn't contain that function in itself
[11:12] <JEEB> I think it's a linking error in your case
[11:12] <derric> JEEB: /usr/local/include is missing from the search path.
[11:13] <JEEB> then it wouldn't be able to find that function name
[11:13] <JEEB> but if you say so, then you could do --extra-cflags="-I/usr/local/include"
[11:14] <JEEB> also I generally recommend static linking for custom compiles for beginners because shared libraries are generally a gigantic pain in the ass
[11:14] <derric> JEEB: Yes, I saw a post about using a -I compiler option, although I was wondering what it meant.
[11:15] <derric> JEEB: I'll try that.  How would I add /usr/local/include to the linker search path?
[11:16] <JEEB> derric, --extra-ldflags="-L/usr/local/lib"
[11:17] <derric> JEEB: I've only had a problem with x264 and ffmpeg.  I've build a lot of stuff, and besides missing depencencies or occasional version conflicts I'm usually able to sort things out.  x264 and ffmpeg has stopped me in my tracks before.
[11:19] <derric> JEEB: OK I'll kill the current compile and start with with x264 again with that compiler flag.  I meant how to add that permanently with having to use a compiler flag for each compiler invocation.
[11:20] <JEEB> I think it was there by default in debian/ubuntu tho :/
[11:20] <JEEB> also I've relatively always had an opposite thing with regards to compilation of ffmpeg/x264
[11:20] <JEEB> as with this case too I just think it's the wrong library coming up in the search path
[11:21] Action: JEEB has done ffmpeg compilations into his home folder for ages
[11:22] <JEEB> derric, also what I just posted doesn't seem to really show the whole search path for headers
[11:23] <JEEB> you'd have to actually run the compiler with a file and the -v flag
[11:23] <JEEB> echo "#include <bogus.h> int main(){}" > t.c; gcc -v t.c; rm t.c
[11:23] <JEEB> something like this
[11:23] <JEEB> on an ubuntu it then outputs /usr/local/include as the first thing under #include <...> search starts here:
[11:25] <JEEB> and it picking up the 129 x264 header means that it picked up the header at least
[11:25] <derric> JEEB: Alrighty, it's off and running.
[11:27] <JEEB> basically what I'd recommend at the moment is to just compile x264 with ./configure --enable-static --disable-cli (builds a static lib + no command line encoder that might use libavcodec/-format/libswscale that you already have installed
[11:27] <JEEB> (And before that remove all of the custom x264 things you have installed under /usr/local
[11:28] <derric> JEEB:  I put an #include for the external x264 header in the libavcodec Makefile and that one undefined reference err when away, although some other ones popped up about duplicate definations from the internal x264 files.
[11:28] <JEEB> derric, I have no idea what you're doing and you shouldn't be doing it like that
[11:29] <derric> JEEB: I know it was just a debugging thing to see if it was failing to find the header somehow.
[11:29] <JEEB> well if it could find the 129 header it meant it was finding the header
[11:29] <derric> JEEB: I'm pretty much clueless about compiler and linker directives.
[11:29] <JEEB> yes, so stop right there
[11:30] <JEEB> 1) remove all of the currently installed libx264 related thingies in /usr/local/*
[11:30] <JEEB> 2) x264 with enable-static and --disable-cli
[11:31] <derric> JEEB: Yes, although it only found the 129 header when I manually put an #include in the Makefile.
[11:31] <JEEB> it would have NOT said undefined reference to the 129 one if it hadn't found it
[11:32] <JEEB> undefined reference IIRC means that you have the function defined in a header or whatever, but it doesn't find any linked library to have that function available for it
[11:32] <derric> JEEB: Well, I already got ffmpeg compiling again.  If it fails this time, with the extra flags, then I'll do 1 and 2.
[11:32] <JEEB> the whole notion of it giving an error about the 129 means it was finding the header :P
[11:33] <JEEB> (Because the ver number is in the header, you can't find it otherwise)
[11:33] <derric> JEEB: I see.  So it was the binaries it was having trouble finding?
[11:33] <JEEB> yes, the libraries. Or more like it was trying to link to something that didn't have that function available to it
[11:34] <JEEB> anyways, after doing 1) and 2) you could then just add --extra-ldflags="--verbose" and see if that shows which libx264.so/a is getting picked up
[11:34] <derric> JEEB: It takes like a half hour on my machine to see if the error is going to show up again.
[11:38] <JEEB> also, if you think ffmpeg/x264 are hard to compile you've then been very, very sheltered. Almost too sheltered :P
[11:38] <JEEB> anyways, this is just a case of the wrong library being picked up by ld
[11:42] <derric> JEEB: I've compiled linux from scratch.  I have lot's of experience building stuff following directions, although I lack any idea about compiler or linker directives.
[11:43] <derric> JEEB: I've built LFS repeatedly, and lot of apps.
[11:43] <JEEB> which means that you've just conveniently never dealt with this kind of stuff
[11:44] <derric> JEEB: Yes, it's quite a blind spot.
[11:44] <JEEB> anyways, testing that --verbose switch with ld to see if it actually tells me which libraries I'm linking with
[11:47] <derric> JEEB: We're within 10 mins or so of knowing if this compile is going to work.
[11:49] <derric> JEEB: How much extra functionality does the external x264 lib add to ffmpeg?
[11:49] <JEEB> H.264 encoding
[11:49] <derric> JEEB: Oh, it will only decode without it?
[11:49] <JEEB> yes
[11:50] <JEEB> also what on earth are you compiling on that takes so long :P
[11:51] <derric> Well, that'sa what I need then.  I notice some 45min tv shows that are encoded with x264_128 that are about 180mb, very smooth good looking video.
[11:51] <JEEB> yes, x264 is the best video encoder you can get right now
[11:51] <derric> JEEB: My machine is a Athlon about 2Ghz with only 512Mb ram.
[11:54] <JEEB> and yes, --verbose seems to tell you
[11:54] <derric> JEEB: I was glad to see the files included the x264 option settings.  Using those options settings resulte in much better encoding than just setting a target bit rate or quality level in ffmpeg.
[11:54] <JEEB> huh
[11:55] <JEEB> dunno what you're talking about :P
[11:55] <JEEB> /home/jeeb/winstuff/ffmpeg/prefix/lib/libx264.a(encoder.o):encoder.c:(.text+0x2c07): undefined reference to `pthread_self' <- example, here I built x264 with pthreads and ffmpeg without it
[11:55] <JEEB> see how it shows the full path
[11:56] <JEEB> this is with the --verbose extra ldflag
[11:56] <JEEB> that could have saved you a lot of trouble earlier
[11:56] <JEEB> lol
[11:56] <derric> JEEB: You have multicore machine?
[11:57] <JEEB> yes, for quite a few years. My first one was a 1.6GHz AMD Turion64x2 in 2006
[12:00] <derric> JEEB: I believe the compilation has gotten past the sticking point.  Now we'll see if any other errs occur.
[12:10] <derric> JEEB: Does the linker need to know about the header files?
[12:10] <JEEB> no
[12:10] <derric> The compiler needs the header files, and the linker need the lib files.
[12:10] <JEEB> yes
[12:11] <JEEB> which is why -I is added to the compiler to find the headers (cflag) and -L is added to the linker to find the libraries (ldflag)
[12:11] <derric> In /etc/ld.so.conf.d/ there is a file that is suppose to include the /usr/local/lib/ dir.
[12:11] <derric> JEEB: Yes, I got that.
[12:12] <derric> JEEB: You build on a windows machine?
[12:12] <JEEB> this was on a linux box but I decided to just build a windows binary with a cross-compiler :P
[12:12] <JEEB> I do build on windows as well
[12:13] <JEEB> echo "#include <bogus.h> int main(){}" > t.c; gcc -v t.c; rm t.c <- one way to get the definitive answer for the "which path is my compiler checking", and ld's --verbose shows the library path as well
[12:13] <derric> JEEB: Well, it's building the manuals, so I guess it made it all the way through.
[12:13] <JEEB> you can then check ldd ./ffmpeg after compilation to check what it's linking against
[12:14] <derric> Do I need to sub in real files into:  echo "#include <bogus.h> int main(){}" > t.c; gcc -v t.c; rm t.c
[12:14] <JEEB> huh
[12:14] <derric> Oh it's done.
[12:14] <JEEB> you just create a random file with some code and  run gcc with the -v switch over it
[12:14] <JEEB> and since bogus.h pretty sure doesn't exist it doesn't create a binary
[12:15] <JEEB> and then you can remove that random c file
[12:16] <derric> JEEB: Right, I can through together a little something.
[12:16] <JEEB> ...
[12:16] <JEEB> I think you are overcomplicating it
[12:16] <JEEB> by far
[12:17] <derric> http://ompldr.org/vZzlrYQ
[12:17] <JEEB> also if it built check with ldd ./ffmpeg to check the just built ffmpeg binary on what it's linked to
[12:17] <derric> I have a tendency to do that.
[12:18] <JEEB> if that was built with --enable-libx264 it would seem like a static library was linked in
[12:18] <JEEB> check ldd libavcodec.so too
[12:18] <JEEB> since it could be that ffmpeg just links to libavcodec that then links to libx264
[12:20] <derric> Yep, that's better:  http://ompldr.org/vZzlrZQ
[12:21] <JEEB> well, at least it's linking to what you in theory would want it to link to
[12:21] <JEEB> you can now install it and run ldconfig
[12:23] <derric> That is a such a relief.
[12:25] <JEEB> I've never really had problems with finding x264 in my custom compiles, but I generally build as static to not need ldconfig, have a prefix in my home folder because I don't have root at f.ex. universities, and also set PKG_CONFIG_PATH=/my/install/prefix before ./configure
[12:28] <derric> Without the extraflags the compile failed with a static only x264 lib.
[12:28] <JEEB> how did it fail and did it fail at compilation or linking? also did you use the --verbose flag with the linker?
[12:28] <derric> I left ./configure use it's default install path, which is /usr/local
[12:29] <JEEB> or are you just talking about previous cases where you had no idea of how to check what the thing was doing?
[12:29] <JEEB> :V
[12:29] <derric> I'd have to recompile again to answer that. although this time I use the extaflags without the verbose option.
[12:30] <derric> Yes.
[12:30] <derric> This time everything seems to have worked.
[12:30] <hendry> is this running correctly on a 8-core machine ? http://s.natalian.org/2012-11-13/1352806212_1366x768.png
[12:30] <hendry> it doesn't seem to make more than one cpu at a time
[12:31] <JEEB> derric, and as for the extraflags you just set the -I and -L for your install prefix's include/lib folder?
[12:31] <JEEB> if yes, then it just seemingly went and looked there first instead of some other place most probably
[12:31] <JEEB> so whatever was coming up first before wasn't no more
[12:31] <JEEB> you could test with the --verbose ldflag later on if you want to see what exactly was happening
[12:32] <derric> JEEB: yes just the include/lib folder.
[12:33] <derric> I have to recompile x264 now to enable lavf support.
[12:34] <JEEB> uhh
[12:34] <JEEB> do you need x264's command line encoder?
[12:35] <JEEB> because for that you need libav* that is built without libx264 :P
[12:38] <derric> Well, some of the x264 options on the encodings that I liked are only available through x264 directly.
[12:38] <JEEB> what exactly?
[12:39] <derric> You making me looke things up in my notes now...
[12:39] <JEEB> also if you are looking at the mediainfo or whatever output of the SEI string, I'll just say that most of that is just from presets :P
[12:39] <JEEB> not to mention that I'm pretty sure that pretty much everything can be used from ffmpeg nowadays
[12:40] <derric> psy, psy-rd cqm, deadzone, threads, open-gop
[12:40] <JEEB> can be all set via ffmpeg's libx264, but why the hell do you even want to play with those :s
[12:40] <derric> Well, I just built the latest version, I was using an older version.
[12:41] <JEEB> cqm was useful when AQ was less good and psy-rd/trellis were less good
[12:41] <JEEB> deadzones are set by psy-* when psy-* are used
[12:41] <JEEB> threads are set to what x264 sets them by default now
[12:41] <JEEB> open-gop can be set via libx264 afaik
[12:42] <JEEB> (of ffmpeg's)
[12:42] <Mattias> How can I force it to a max of 1Mbit/s ? x264 that is. If I play too fast games and stream, the bandwidth usage gets too big for my connection and it lags, but something like dwarf fortress is fine.
[12:42] <derric> As I said they resulted in a noticably better encoding.  Well, the other one that ffmpeg was able to use actually, those were the ones I omitted.
[12:42] <JEEB> derric, I'm pretty sure you have no idea what you're looking at or setting :|
[12:42] <JEEB> because most of those settings get set to something via the presets system and the tune system
[12:43] <JEEB> but those aren't viewable in the mediainfo-viewable output
[12:43] <Mattias> JEEB: http://sprunge.us/XAUC <-- I have this, how do I set it so it won't go over 1 Mbit/s  ? Is it even possible?
[12:43] <derric> JEEB: That's insightfull of you.  I was just copying verbantum the settings.  I figured I'd learn what they were later...
[12:43] <JEEB> yes, don't do that
[12:44] <JEEB> I've had too many people look at mediainfo output and try to set settings to those ad verbatim
[12:44] <JEEB> Mattias, if you have any kind of transfer constraints you use -maxrate and -bufsize to set the maximum average bit rate over buffer
[12:44] <derric> JEEB: Anyway, using what settings I could from those files did help, maybe because of my encoding naivativity :)
[12:45] <JEEB> derric, you should be just fine by using -crf + -preset + (possibly) -tune
[12:45] <JEEB> that's it
[12:45] <Mattias> JEEB: oh, cbsrobot told me to remove those, I'll check em out again
[12:45] <JEEB> crf sets the "quality level"
[12:45] <Mattias> Maybe he just meant to remove them for the wiki
[12:45] <JEEB> Mattias, probably to troubleshoot something else
[12:45] <Diogo> hi this is possible do a buffer in the publish point../servers/ffmpeg/bin/ffmpeg -re -i "1.mp4" -vcodec copy -acodec libfaac -f flv "rtmp://SERVER" in this command
[12:45] <Mattias> JEEB: no, I added my example to the streaming guide :)
[12:45] <JEEB> if you have transfer rate constraints you /need/ maxrate and bufsize
[12:45] <derric> JEEB: I tried that first.  The result was slightly blocky.
[12:46] <JEEB> derric, the idea is to find the highest crf value that still looks good to you
[12:46] <derric> JEEB: Using the copied setting help get rid of the residual blockiness.
[12:46] <JEEB> so if it looks bad, you lower the crf value you set
[12:46] <derric> JEEB: Yes, I understand that.
[12:46] <Diogo> i want do stream a mp4 do a rtmp server, but this command the player breaks every time, but publish point with flash media live encoder works perfatly...
[12:46] <gehmehgeh> Hi, is there any way to transcode dvb-subtitles with ffmpeg, for example to the srt format?
[12:47] <gehmehgeh> Because last time I tried, it didn't seem to work
[12:47] <JEEB> Mattias, if it is supposed to be an example of streaming over network that is limited then you will /need/ -maxrate and -bufsize set accordingly to your tranfer limits and the amount of buffering the client does
[12:47] <JEEB> you should not hardcode those values to anything, but tell the user to look up the values they need
[12:47] <JEEB> -maxrate and -bufsize are ESSENTIAL to streaming
[12:47] <JEEB> derric, and -preset for encoding speed vs compression ratio
[12:48] <JEEB> http://mewiki.project357.com/wiki/X264_Settings#preset
[12:48] <JEEB> that's it
[12:48] <JEEB> for 99% of all cases
[12:48] <JEEB> you'd be hard pressed to get better results
[12:48] <Mattias> JEEB: ok, I'll add those to the wiki after I figure them out, thanks :)
[12:50] <JEEB> derric, I have myself played around with various options for hours and hours and then after finding a "nice result" I then retried the default with just preset (and possibly tune) set -> defaults give a better result :P
[12:52] <derric> JEEB: Ha.  Due diligence...
[12:57] <derric> Well, I'll have to make some more test encodings.
[13:00] <JEEB> encode a clip of a few thousand frames using -t and -ss with just specifying -c:v libx264 -an and some -crf value, and then find the area of comfort for yourself crf-wise
[13:01] <JEEB> then start upping the -preset as I linked from the listing of that x264 settings page
[13:01] <JEEB> and basically use the slowest that is still "fast enough" for you
[13:02] <JEEB> and then as with the change of algorithms the definition of "quality" differs somewhat, you might want to re-check the crf value
[13:02] <JEEB> and that's it
[13:02] <Mattias> JEEB: so, -maxrate is basically the max limit of the bit /s , but -bufsize is what? do I set them to the same value? or one higher than the other?
[13:02] <Mattias> ratecontrol buffer size
[13:02] <JEEB> -bufsize is the buffer over which maxrate is calculated
[13:02] <Mattias> So how do I know what to set there?
[13:02] <JEEB> also the amount of bits the player side buffers
[13:03] <Mattias> I've set 1048576 on maxrate
[13:03] <Mattias> which is approx 1Mbit/s
[13:03] <JEEB> you should know what the player side uses for that, or if you can set it on player side yourself you generally can then match those. Generally if you are using a third party service they usually show both values
[13:03] <Mattias> twitch.tv ^.^
[13:03] <JEEB> yes, they should then have that information
[13:04] <JEEB> if the buffer amount is defined in seconds, you set it to <amount of seconds>*<maxrate>
[13:04] <Mattias> Well, twitch.tv gives hardly any info :(
[13:04] <derric> Ha, 5 fps...
[13:05] <derric> And that for pass 1!
[13:05] <JEEB> crf doesn't need multiple passes
[13:06] <JEEB> multiple passes are just for bitrate based rate control
[13:06] <JEEB> did I tell you to add -pass 1 :P
[13:06] <JEEB> you'll just have to scroll a few lines up
[13:06] <JEEB> to see what I recommended you do
[13:07] <derric> I tried one pass vs two pass, and found two pass noticably better, at least with what I was trying.
[13:07] <Mattias> JEEB: ok so, if I have no info from twitch.tv, is it fine just setting it to the same value of maxrate? or should I try half that value or something?
[13:07] <JEEB> Mattias, buffering is generally at least one second's worth, and the bigger it is the better quality you can push out
[13:08] <Mattias> oh
[13:08] <Mattias> so I want it bigger
[13:08] <JEEB> just look at their documentation or whatever, they /have/ to have maxrate/bufsize values somewhere :P
[13:08] <JEEB> you are not the only one streaming to that service I bet
[13:08] <Mattias> they only have windows specific stuff, like use xplit or something
[13:08] <Mattias> they do not support linux in any way
[13:09] <JEEB> derric, bullshit. Except for certain very specific cases crf and bitrate-based encoding end up with the same kind of quality
[13:09] <Mattias> except they have a vlc script thingy for linux :P
[13:09] <JEEB> see that :P
[13:09] <derric> JEEB: I did add -pass 1 with -preset veryslow
[13:09] <JEEB> and xsplit uses x264 as well after all, that could have documentation on it as well
[13:09] <JEEB> derric, if you use -pass 1 it will use fast first pass defaults
[13:09] <JEEB> because it thinks you will want to do another pass :|
[13:10] <derric> JEEB: I know, that'
[13:10] <derric> s why I wonding how slow pass 2 is going to be :|
[13:11] <JEEB> derric, also as I said, crf and bitrate based encoding give you the exact same fucking result when the output is of the same rate (more or less, except for certain very special cases and in those generally crf is better off)
[13:11] <JEEB> I'm really getting tired of having to lecture people with weird beliefs
[13:11] <derric> JEEB: I make sure to try all the permutations.
[13:11] <Mattias> bah, "jtvlc" is closed source
[13:12] <JEEB> 2pass bitrate based and 1pass crf are more or less something that ends up in the same result quality-wise (Except for certain border cases like very short clips where the 2pass rate control mode doesn't have enough time to properly "set itself up", and in those cases generally crf is better off)
[13:12] <JEEB> it's just that 2pass is based on the assumption that you want the end result to be of certain file size
[13:13] <derric> JEEB: From my actual test encodes it seemed like 2 pass was noticable better.  Now that I have current version, I'll do all the comparisions again.
[13:13] <JEEB> you were most probably comparing incorrectly
[13:13] <JEEB> where as crf is "I want the output to be of this quality level, more or less"
[13:13] <derric> JEEB: Yes, the highest possible quility for a fixed file size.
[13:13] <JEEB> no, not necessarily the highest possible quality
[13:14] <JEEB> it just limits the rate control to hit a certain file size
[13:14] <JEEB> this is not effing xvid or anything else like that for pete's sake where 2pass is the best just because they have no other good modes for encoding
[13:15] <cbsrobot> Mattias: I just asked why you needed -maxrate -bufsize & I guess you cuold add them to the streamingguide aswell - just note what they are used for
[13:15] <Mattias> yeah, experimenting with them now to get a nice result ^.^
[13:15] <derric> With the slower encoding modes there is lookahead, so multipass is really unnecessary aye?
[13:16] <JEEB> it's unnecessary if you don't care about getting an exact file size in any case
[13:17] <JEEB> if anyone would write a "streaming guide" without mentioning that you ABSOLUTELY POSITIVELY NEED maxrate and bufsize if you are not going over "clearly overboard" transfer rate connections such as HDDs or 100mbps/1gbit network with relatively low bit rates
[13:17] <JEEB> I would just give the person a slap in the face
[13:18] <JEEB> naturally the only problem is that you can't just give a user some random values
[13:19] <JEEB> as the maxrate depends on what exactly is being done and possibly the third party service provider that then retransmits it, and the bufsize depends on the player side of things as well
[13:19] <JEEB> PERKELE
[13:19] <derric> JEEB: The veryslow preset is a very good job.
[13:19] <derric> In one pass I might add.
[13:20] <JEEB> what exactly did you use as the command line?
[13:22] <JEEB> Actually I probably would start the streaming wiki article with something like "I know you just want something to copypasta to your terminal or bash script, but wait for a second there stranger. There is one thing we have to deal with first."
[13:22] <JEEB> and then tell the user about VBV(-maxrate/-bufsize)
[13:23] <JEEB> I know users don't read, but you can deal with that by just having MAXRATE_VALUE and BUFSIZE_VALUE there or something so it couldn't be used just copypasta'd
[13:24] <derric> I'l have to remember because it's running pass two at the moment at < 1fps.
[13:25] <JEEB> ...what
[13:25] <JEEB> oh well suit for yourself damn it
[13:26] <JEEB> (at times I even wonder why the hell I try to help people with their weird beliefs and broken crap)
[13:26] <derric> ffmpeg -i <input.file> -f matroska -acodec mpeg4 -s 640x320 -aspect 16:9 -b:v 660k -acodec ... -preset veryslow -tune film -pass 1 -t 150 <out.file>
[13:27] <JEEB> either you just cut some very important parts from that or you are not setting the video codec at all
[13:27] <derric> I am targeting a 700mB output file.
[13:27] <JEEB> also wtf is -acodec mpeg4
[13:27] <JEEB> well, you should have said that from the beginning then
[13:27] <JEEB> that you are not looking for just quality
[13:27] <JEEB> but for a SPECIFIC MOTHERFUCKING FILE SIZE
[13:27] <derric> s/-acodec mpeg4/-vcodec mpeg4/
[13:27] <JEEB> then yes, naturally 2pass makes sense
[13:28] <JEEB> ...
[13:28] <JEEB> you do know that mpeg4 is the MPEG-4 Part 2 encoder, right
[13:28] <JEEB> you do know that it has no -presets right?
[13:28] <JEEB> it has no tunes either
[13:28] <JEEB> I need vodka and it's only tuesday
[13:28] <JEEB> :V
[13:29] <derric> Well, obviously I ws missing that. How would I specify the x264 encoder then?
[13:29] <JEEB> -vcodec or -c:v libx264... you can scroll up some dozens of lines of chat where I noted it
[13:31] <derric> I think the old version I was using specified to use the mpeg4 tag for the x264 codec.
[13:31] <JEEB> no, it never did that
[13:31] <JEEB> also I have no idea what "mpeg4 tag" is
[13:31] <JEEB> video codec by the name of 'mpeg4' has ALWAYS been mpeg-4 part 2
[13:31] <JEEB> which is the specification that xvid and divx also follow
[13:32] <JEEB> H.264 is MPEG-4 Part 10
[13:34] <derric> I must have read it wrong then, the old ffmpeg was removed so it's just the new one on from now.
[13:37] <divVerent> jeeb: I don't see maxrate/bufsize as THAT necessary, even on 11mbit WLAN... for SD content, that is
[13:38] <JEEB> depends on your rate control
[13:38] <divVerent> for that I don't even reencode, I just mount via sshfs and play with sufficiently large cache
[13:38] <JEEB> and yes, sufficient caching/buffering lets you be quite lenient with maxrate at times
[13:38] <divVerent> and it's necessary anyway
[13:38] <divVerent> because the WLAN is unreliable
[13:38] <divVerent> so I use like 4 or even 8 MB of cache
[13:38] <JEEB> but this is away from general streaming guidelines
[13:39] <divVerent> right
[13:39] <divVerent> for online streaming, you don't even want a big cache
[13:39] <JEEB> tl;dr in your use case and your knowledge of usage
[13:39] <divVerent> you want fast response...
[13:39] <divVerent> and that means small buffer and strong rate control
[13:39] <JEEB> divVerent, it depends if it's live streaming that needs to be quick or not
[13:39] <divVerent> not even just live
[13:39] <divVerent> most people don'Ät want to wait 2 sec on each seek
[13:39] <divVerent> I don't seek much, so for my use case it's ok to not even reencode
[13:40] <JEEB> that depends, I see many services buffer 1-2 seconds for rtmpe and friends
[13:40] <divVerent> in the end, this is basically a question the user has to answer to themselves
[13:40] <JEEB> or even more
[13:40] <JEEB> yes
[13:40] <divVerent> there are some guidelines
[13:40] <JEEB> which is why I noted what I noted
[13:40] <JEEB> for fuck's sake
[13:40] <divVerent> like, maxrate should not be more than half the bandwidth you think you have
[13:40] <divVerent> unless you actually KNOW it ;)
[13:40] <JEEB> and your nitpicking isn't making me any more happy than I am already with these dumb fucks
[13:40] <divVerent> like, for streaming over 11mbit wlan, I wouldn'Ät count on more than 5
[13:40] <JEEB> who skip what I write and think they know what they're doing
[13:40] <divVerent> but on DVD there are even specs about what rate is allowed
[13:40] <JEEB> yes
[13:41] <divVerent> thing is, a good guide would need like 3 to 5 pages to explain all this
[13:41] <JEEB> naturally which is why if you are making the motherfucking stream for something specific you look at that fucking documentation
[13:41] <divVerent> right
[13:41] <JEEB> like I did with that person who is now off the damn backlog
[13:41] <divVerent> and if your player has a buffer size that is configurable, a good guess would be to start at that buffer size
[13:41] <divVerent> typically less, though, as most SW players share buffer for A and V
[13:42] <divVerent> and I am not aware of any ffmpeg feature to account for that :P
[13:42] <divVerent> another factor all this depends on is the reliability you are going for
[13:42] <divVerent> like, are short skips allowed yes/no
[13:43] <JEEB> derric, Also related to your command line. I don't give a fuck about your file names and such so you can just do a.avi or b.mkv or whatever the fuck you want, but please don't fucking leave stuff just blatantly out. I know you don't know if something is meaningful or not, and I am not a fucking esper.
[13:43] <divVerent> you need different reliability if you're a TV station than if you just play videos on your phone
[13:43] <JEEB> I know I'm getting arrogant and using bad language but after a few hours trying to talk to you I just find myself greatly aggravated
[13:43] <divVerent> e.g. my iphone video encodes are crf with maxrate set, but I never verified if it's even right. It sort of works for me.
[13:43] <divVerent> Apple didn't really release specs on that :(
[13:44] <divVerent> also, I am pretty sure I can go higher on the phone I have, because the ffmpeg command line I ripped the settings from was for the iphone 3something
[13:44] <divVerent> and I have the iphone 4 now with ios 6.0.1
[13:44] <divVerent> but I don't care, quality is good enough as is
[13:44] <JEEB> if you are playing from the memory card or whatever you can pretty much forget about vbv and just go high profile level 4.1
[13:45] <JEEB> that's what works on it ever since 3GS
[13:45] <divVerent> high profile didn't when when  I last tried
[13:45] <divVerent> but that was on ios 5
[13:45] <divVerent> maybe should retry
[13:45] <JEEB> it has worked way before ios 5
[13:45] <JEEB> only itunes derps on it
[13:45] <divVerent> odd
[13:45] <divVerent> maybe was an unrelated bug
[13:45] <JEEB> because itunes is herp derp
[13:45] <divVerent> I don't use itunes, though
[13:45] <divVerent> I use a third party app with a ftp server
[13:45] <JEEB> k
[13:45] <divVerent> so I can avoid using itunes
[13:45] <divVerent> because itunes doesn't work on linux
[13:45] <JEEB> yeah, itunes limits you to level 3.x main profile
[13:46] <divVerent> and manually fscking a video into the on-phone itunes collection is POSSIBLE but ANNOYING
[13:46] <divVerent> once did that for audio just so I could set it as ringtone
[13:46] <divVerent> involved editing sql databases and xml files
[13:46] <divVerent> and once you know a method that works, apple changes the format in the next ios version
[13:47] <divVerent> the app I use BTW is UbiDisk, about the only free (no ads either) one that works
[13:47] <divVerent> don't care if it's spyware, though, probably is, or it'd be just too good :P
[13:48] <divVerent> BTW, what is your opinion about resolution vs bitrate?
[13:48] <divVerent> I noticed that if I target a specific bitrate, lowering the resolution can increase the overall quality
[13:48] <divVerent> but how important is it today that the file resolution is a divisor of the device resolution?
[13:49] <divVerent> I still make sure of that, but somehow it seems to matter a lot less now, the scalers apparently work better
[13:50] <JEEB> I really don't care that much about that, my general resolution selection also depends on the specific device. With my phone I generally encode something 720p that I could possibly use for something else too
[13:50] <divVerent> hehe
[13:50] <JEEB> for the PSP I encode something in 720x480 because the chroma upsampling in that is just that bad that you really want to have something upscaled for it
[13:50] <divVerent> main reason I encode at half-screenres is that it's still sharp enough for me, encoding is a lot faster, and the files are smaller at a crf I like
[13:50] <JEEB> (or 720x576)
[13:50] <divVerent> hehe
[13:50] <divVerent> I HATE CHROMA DOWNSAMPLING ;)
[13:50] <divVerent> especially in jpeg
[13:51] <divVerent> wonder if the iphone would play high444 ;)
[13:52] <divVerent> for video it's typically ok, motion hides the artifacts
[13:53] <divVerent> 13:15:46        Mattias | yeah, experimenting with them now to get a nice result ^.^
[13:53] <divVerent> kinda hard to properly try out
[13:53] <divVerent> hm... maybe try a bandwidth limited connection to test it :)
[13:53] <Mattias> divVerent: got nice results :)
[13:53] <Mattias> I'm saving down to a file now when testing
[13:54] <Mattias> work came up though, will try more after. at 1Mbit text is readable, at 0.5Mbit game is watchable (text not readable)
[13:54] <divVerent> best way to find out how exactly these work, is making stuff work with a 64kbit/s connection ;)
[13:55] <Mattias> I could lower the resolution too, doing 1280x800 now
[13:55] <Mattias> Xonotic streams well though ;)
[13:55] <divVerent> hm... wait, you target like 500kbit/s?
[13:55] <divVerent> DO lower the resolution, then
[13:56] <Mattias> I think I can play at the same time if I do it at 0.5
[13:56] <Mattias> ^.^
[13:56] <divVerent> TEH BLUR is better than TEH ARTIFACTS
[13:56] <divVerent> ;)
[13:56] <Mattias> yeah
[13:56] <Mattias> I also noticed, if I have too much FPS in game, I get glitches or something, like an old CTR screen in camera
[13:56] <divVerent> how do you record?
[13:57] <derric> JEEB: ty.
[13:57] <divVerent> BTW, to give you a bitrate reference: I tend to encode my videos for the iphone at crf=23, with some huge maxrate, and get about 50 to 100 MB per file of about 25 minutes at 480x320
[13:58] <divVerent> quality is very good, probably too good
[13:58] <divVerent> i.e. rate could be lowered
[13:58] <divVerent> audio is 96kbit/s
[13:58] <Mattias> divVerent: http://sprunge.us/QjCh  currently
[13:58] <divVerent> so video is somewhere between 177 and 450 kbit/s for this content
[13:59] <divVerent> Mattias: why not use cl_capturevideo?
[13:59] <divVerent> that avoids this problem
[13:59] <Mattias> and how would I stream that?
[13:59] <divVerent> same way as you stream your /tmp/test.flv
[13:59] <Mattias> I mean, I use rtmp, this is just a test file when I try the bufsize and maxrate
[13:59] <divVerent> oh, ok
[13:59] <divVerent> then indeed, you need ffmpeg
[13:59] <divVerent> did you try vid_vsync 1 in Xonotic?
[14:00] <Mattias> yeah, that helped the issue
[14:00] <divVerent> that should avoid the tearing
[14:00] <Mattias> a little
[14:00] <divVerent> not entirely?
[14:00] <divVerent> then either x11grab is broken
[14:00] <Mattias> yeah, not entirely, but it's not that noticebly now
[14:00] <divVerent> I mean, X11's window dumping
[14:00] <Mattias> sometimes you might see a small tear
[14:00] <divVerent> or, no idea
[14:00] <Mattias> it's at constant 60fps
[14:00] <divVerent> try running in a compositing window manager for a test
[14:00] <Mattias> and my target fps is 15
[14:00] <Mattias> maybe that's why?
[14:00] <divVerent> or if you do, try NOT running in one
[14:00] <divVerent> no, that should not be the problem
[14:01] <Mattias> running xmonad now, dual screen
[14:01] <divVerent> ffmpeg does X window grabs, these SHOULD be somewhat atomic
[14:01] <divVerent> if not, what I'd try next is a compositing WM
[14:01] <Mattias> I can stream soon after I'm done with an update
[14:01] <divVerent> i.e. something less minimalistic than xmonad ;)
[14:01] <Mattias> you'll see what I mean then :)
[14:01] <divVerent> I know how tearing looks :P
[14:01] <Mattias> ^.^
[14:01] <divVerent> well, try running in compiz
[14:02] <divVerent> just as a test whether it helps against the tearing
[14:02] <Mattias> The pain of leaving xmonad... is too great~
[14:02] <divVerent> it's just for the streaming sessions
[14:02] <divVerent> also, MAYBE running xcompmgr additionally to xmonad will also cause desktop composition
[14:03] <divVerent> and thus would also help
[14:03] <divVerent> but I am not sure about that
[14:03] <divVerent> the general idea is that enabling/disabling desktop composition adds an extra indirection between game engine and graphics card
[14:03] <divVerent> and also between screenshots and graphics card
[14:03] <divVerent> so the screenshotting (as done by x11grab) maybe is atomic then
[14:05] <Mattias> ok, time to lower resolution :) and I'll try out directly on the stream channel
[14:05] <Mattias> http://www.twitch.tv/mattiasjp  the channel, going to setup the lower res now then start xonotic stream for testing :)
[14:07] <divVerent> and for THIS kind of streaming you BTW do need very careful bandwidth limiting
[14:07] <divVerent> as you can't even know who plays with what settings
[14:08] <JEEB> the flash player handles the buffering
[14:08] <divVerent> doesn't it possibly depend on HTTP proxies and/or flash version?
[14:08] <JEEB> not flash version really, I think the app does it
[14:08] <divVerent> ah, ok
[14:08] <divVerent> still, if not having a spec, I'd assume small buffer sizes
[14:08] <JEEB> http proxies, maybe -- but to be honest if something's too slow that's just it
[14:09] <JEEB> the service gives a limit of ~1mbps it seems for maxrate (as far as that person has understood it)
[14:09] <divVerent> like, 1Mbit total buffer size (128kB)
[14:09] <JEEB> nah
[14:09] <JEEB> it's generally at least 1sec
[14:09] <JEEB> possibly two
[14:09] <divVerent> that'd be quite close to 1 sec ;)
[14:09] <JEEB> depends on the service provider
[14:10] <divVerent> but, basically, a too small buffer typically doesn't hurt much
[14:10] <divVerent> a too small buffer size in ffmpeg, that is
[14:10] <divVerent> because the buffer size is basically a lower bound of the playback buffers
[14:11] <Mattias> divVerent: so, are the settings bad? :P if you're watching
[14:12] <divVerent> can't check from here
[14:38] <Mattias> divVerent: seems to work well, with the lower resolution, but text is not that readable ^.^ but I can play while streaming so.
[14:39] <xroberx> hi there
[14:39] <Mattias> For some reason I can stream high quality when I play dwarf fortress, most likely because there aren't as many frame changes
[14:40] <xroberx> how do I loop a video ? I've tried to call av_seek_frame(pFormatCtx, videoStreamIdx, 1, AVSEEK_FLAG_ANY); when the video ends, but I see a lot of artifacts and eventually all I see is a mess
[15:09] <sebouh> Hi. ffmpeg is not able to process my vlc-rtsp stream.
[15:09] <sebouh> can anyone help me plz?
[15:09] <sebouh> here's the err: http://pastebin.com/g8hjLUTt
[15:10] <sebouh> The VLC command is: :sout=#transcode{vcodec=h264,vb=300,scale=0.25,acodec=mp4a,ab=128,channels=2,samplerate=22050}:rtp{mux=ts,sdp=rtsp://:8554/test.sdp} :sout-keep
[15:10] <sebouh> when i remove the mux=ts it works... but without it, the audio is out of sync
[15:12] <sebouh> anyone?
[15:46] <pulse00> hi all. when transcoding audiofiles to mp3, is there a way to remove existing id3 tags if the input source is already mp3 ?
[15:49] <Mavrik> pulse00: "-map_metadata -1" should do the trick
[15:49] <pulse00> Mavrik: great, thanks. i'll try that
[16:18] <derric> If a source file has more than one audio stream, how does one pick one, the other, or both to transcode to the output file?
[16:19] <derric> Also if the sourse has more then two channels, will just setting the -ac to two reduce the output audio to just the right and left channels?
[16:25] <Mavrik> derric: 1.) by using "-map" parameter. 2.) yes
[16:31] <divVerent> derric: note that you may want to argue about HOW to reduce it ;)
[16:32] <hendry> what does -b:v 500k versus -b:v 2000k mean with libvpx? different video qualities ?
[16:33] <divVerent> the -af pan filter allows you to be more specific
[16:33] <divVerent> but yes, -ac 2 will do "something" which you may or may not like, it usually is ok
[16:34] <divVerent> so try that first, ffmpeg has some builtin means to do something good with multichannel input
[16:34] <divVerent> and use -af pan if that failed, and tell us the command you used in the end then :)
[16:46] <Diogo> this is possible use a image in ffmpeg -i image.jpg -f "rtmp://"
[16:46] <Diogo> ?
[16:52] <DelphiWorld> hey
[16:52] <DelphiWorld> can i rip AudioCD using ffmpeg ?
[16:52] <hendry> anyone know what "-crf 24" does ?
[16:52] <DelphiWorld> hendry: CRF24 Create Radio Frequency (C-R-F) :-P
[17:02] <derric> Mavrik: ty
[19:27] <derric> Is is possible to set the default audio stream, and if so how?
[20:08] <derric> Disregard that last question.
[21:05] <jure> is it better to use AAC+ or AMR-WB to encode speech?
[21:11] <jure> lol AAC+ :D
[21:11] <jacobs1> Hi, I am using ffserver to stream a video file to many clients, but clients are not synchronized. Is it possible to config ffserver to force client synchronization, meaning that they will all show the same frames at the same time ?
[21:38] <Xix19> how can I pass images continuously to ffmpeg and have it stream as webm?
[21:38] <Xix19> I have images sent over the net from a webcam and I want to feed them into ffmpeg
[21:39] <Xix19> then stream it in a webm format that can be seen on a website
[22:12] <StFS> Hi. Does anybody know which package I'm supposed to install in Ubuntu 12.10 to get libfaac encoder to work?
[22:16] <JEEB> seems like libfaac encoder isn't distro'd linked to libavcodec any more as it's nonfree
[22:17] <JEEB> so you'd have to recompile ffmpeg with it in any case, and now we have a better GPL-incompatible aac encoder anyways
[22:17] <JEEB> libfdk
[22:17] <JEEB> https://github.com/mstorsjo/fdk-aac
[22:17] <JEEB> the ubuntu libavcodec package comes with vo-aacenc which is GPL-compatible, but that's not really better than the libavcodec's internal aac encoder
[22:18] <JEEB> so yeah, if you want good aac encoding I recommend you build fdk and ffmpeg yourself into a custom prefix :)
[22:19] <JEEB> (and you probably want to enable libx264 as well)
[00:00] --- Wed Nov 14 2012