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

[burek]

[00:03:38 CEST] <zamba> i have an old video that's got some interlace issues.. i grab this from /dev/video0 and video4linux2.. should i do the deinterlacing when capturing?
[00:09:55 CEST] <llogan> zamba: you can give it a try. see yadif, w3fdif, and bwdif filters. I've only used yadif
[00:10:04 CEST] <zamba> i settled for yadif
[00:10:13 CEST] <zamba> it's just simply -vf yadif, right?
[00:10:24 CEST] <llogan> yes, if you just want to use the defaults
[00:10:34 CEST] <zamba> i don't have the knowledge to not use the defaults :)
[00:11:14 CEST] <zamba> i also have some artifacts at the edges of the video.. how can i just remove this when capturing?
[00:11:27 CEST] <zamba> the source is 720x576
[00:12:00 CEST] <llogan> as for yadif the mode option is likely the most important in your case. just try yadif=1 or yadif=0 and see what looks better. default is 0 but i find 1 looks better with some content
[00:12:28 CEST] <llogan> what are the artifacts? just black padding?
[00:13:59 CEST] <zamba> one sec.. i'll create a screenshot
[00:16:32 CEST] <zamba> http://i64.tinypic.com/27wrgpx.png
[00:17:47 CEST] <llogan> that's typical overscan from analog sources. the bottom looks like the usual head switching noise.
[00:18:22 CEST] <zamba> how should i best handle it?
[00:18:50 CEST] <llogan> i mean the overscan in broadcast monitors (and your old tv) will crop out the black border
[00:19:18 CEST] <llogan> you can just leave it, you can cover it, or you can crop it
[00:20:06 CEST] <zamba> well.. if i open it on a computer - which most people do these days, then they're a bit annoying
[00:20:28 CEST] <llogan> if you're just viewing on a computer then feel free to crop that stuff
[00:20:55 CEST] <furq> zamba: there's a new deinterlacing filter in 3.0 which should be better than yadif
[00:20:58 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#nnedi
[00:21:30 CEST] <llogan> i wonder how slow it is
[00:21:40 CEST] <furq> probably fairly slow
[00:22:25 CEST] <zamba> well.. it should still be usable for SD video in real time encoding, or?
[00:22:46 CEST] <zamba> too many options here.... :)
[00:23:02 CEST] <furq> actually i wonder if it's multithreaded
[00:23:07 CEST] <kepstin> it'd be... iffy on realtime, even if sd
[00:23:12 CEST] <kepstin> it's not multithreaded
[00:23:17 CEST] <furq> yeah that sounds bad
[00:23:24 CEST] <llogan> zamba: also consider a little bit of denoising: see hqdn3d filter. then end the filterchain with format=yuv420p if your output is H.264
[00:23:26 CEST] <zamba> ok, we'll drop that, then
[00:23:28 CEST] <furq> i get 40fps tops using multithreaded QTGMC, which is nnedi3-based
[00:23:34 CEST] <furq> zamba: give it a try and see how slow it is
[00:23:39 CEST] <zamba> llogan: now we're getting there
[00:23:40 CEST] <furq> i would expect much better quality than yadif
[00:23:53 CEST] <zamba> hm.. i have to get 3.0
[00:23:55 CEST] <kepstin> the nnedi3 filter *can* do realtime - if you use the windows implementation, which can be gpu-accellerated (it runs the neural net on a gpu)
[00:24:24 CEST] <kepstin> the ffmpeg implementation is plain c with no gpu support.
[00:24:59 CEST] <furq> with that said i've been dealing with DVDs
[00:26:13 CEST] <furq> if it's a straight 50i signal and you want to convert it to 50p then yadif might do an ok job
[00:26:31 CEST] <zamba> furq: how do i know if it is?
[00:26:34 CEST] <furq> you could also just encode it interlaced and let the player do the job
[00:27:05 CEST] <llogan> also, it is old analog stuff. may not make a huge difference which deinterlacer you use.
[00:27:16 CEST] <zamba> furq: i thought the same, but i was going to preview it using the video tag in html5.. that has nothing like that, right?
[00:27:53 CEST] <kepstin> yeah... i wouldn't expect the browser renderers to deinterlace. you'll want to do it before encoding.
[00:27:53 CEST] <zamba> llogan: i'm sorry to bother you move, but could you provide me with an example of a full recommended list of options?
[00:28:20 CEST] <zamba> llogan: you mention the hqdn3d filter, for instance.. but i have no idea about the optins
[00:28:23 CEST] <zamba> options*
[00:28:45 CEST] <zamba> currently i'm just doing: ffmpeg -f video4linux2 -i /dev/video0 -f alsa -i default -vf yadif <outputfile>.mp4
[00:28:47 CEST] <llogan> http://ffmpeg.org/ffmpeg-filters.html#hqdn3d-1
[00:28:49 CEST] <kepstin> to be honest, if it's VHS stuff, you might as well just halve the vertical resolution, dropping every other line. That'll turn the 50i into 50p without really removing any detail.
[00:29:11 CEST] <kepstin> depends on the source quality tho
[00:29:14 CEST] <furq> yadif does a halfdecent job of that without costing much speed though
[00:30:52 CEST] <zamba> llogan: which of those options should i be using?
[00:31:05 CEST] <furq> denoising is a bit of a black art
[00:31:11 CEST] <furq> it's very much dependent on the source quality
[00:31:11 CEST] <llogan> try the default first. if that doesn't work then monkey with it
[00:31:32 CEST] <furq> basically, increase those numbers to remove more noise but also remove more fine detail
[00:31:59 CEST] <zamba> llogan: what is the default? just -vf hqdn3d?
[00:32:02 CEST] <furq> yeah
[00:32:11 CEST] <zamba> so the command line will then look like?
[00:32:12 CEST] <furq>  -vf yadif,hqdn3d
[00:32:16 CEST] <zamba> aight
[00:32:30 CEST] <zamba> and then the stuff about ending the filterchain?
[00:32:32 CEST] <llogan> didn't you want to crop? also, you forgot format
[00:32:46 CEST] <furq> yeah put crop in the middle of those
[00:32:58 CEST] <zamba> yeah, i think i want to either crop or replace it with some black parts
[00:33:00 CEST] <zamba> what is "best"?
[00:33:09 CEST] <kepstin> hmm, i'd put the crop before the yadif - it would reduce bad matches on edge noise.
[00:33:13 CEST] <zamba> i guess there's a point in maintaining the aspect ratio, or?
[00:33:57 CEST] <kepstin> zamba: most analog video captures intentionally capture an image wider than the standard "4:3" area, and for computer video you're pretty much intended to crop it or hide the extra during playback.
[00:34:02 CEST] <furq> i figured it might screw with the field order but i guess it's set to autodetect anyway
[00:34:23 CEST] <kepstin> hmm, if you crop an odd number of lines off the top, yeah :/
[00:34:39 CEST] <zamba> hehe, you're talking a bit over my head now.. :)
[00:34:42 CEST] <llogan> zamba: are you going to make DVDs? or just files for watching on a computer and uploading to 'tube 'n stuff?
[00:35:09 CEST] <zamba> llogan: i think maybe both.. but in today's age, primarily the latter.. meaning files for watching on a computer..
[00:35:16 CEST] <furq> zamba: it's probably best to just crop whatever you can unless you need a particular target resolution (e.g. for DVD)
[00:35:35 CEST] <llogan> take a crop, if it's shitty you can dump it, wipe the file, and start over
[00:35:55 CEST] <furq> the source AR isn't really significant, and you can set the DAR of the output file independently
[00:36:05 CEST] <zamba> haha.. if you replace "crop" with "crap" there, then the whole sentence has a whole new meaning :)
[00:36:23 CEST] <kepstin> if you do make a dvd later, you can always just put black borders back later.
[00:36:24 CEST] <llogan> yeah, it was a bad joke...
[00:36:31 CEST] <zamba> kepstin: yeah, i was thinking the same
[00:36:38 CEST] <zamba> so.. what options do i end up with?
[00:36:38 CEST] <furq> what would you do if your crop wasn't shitty
[00:36:44 CEST] <furq> see a doctor?
[00:38:10 CEST] <furq> i guess -vf crop=0:0:0:0,yadif,hqdn3d
[00:38:23 CEST] <llogan> ,format=yuv420p
[00:38:27 CEST] <furq> oh yeah
[00:38:32 CEST] <kepstin> that would give you a 0x0 image, which would certainly compress well.
[00:38:49 CEST] <furq> it'll compress even better after denoising
[00:39:01 CEST] <iive> actually, it would compress infinitely bad :)
[00:39:12 CEST] <furq> it'll be -1 bytes
[00:39:55 CEST] <zamba> crop=0:0:0:0 is autocrop?
[00:40:01 CEST] <furq> no
[00:40:06 CEST] <furq> replace the 0s with your actual crop values
[00:40:09 CEST] <zamba> ah
[00:40:16 CEST] <iive> -vf cropdetect
[00:40:23 CEST] <zamba> ah! i remember that one
[00:40:49 CEST] <kepstin> lets see. I'd do crop=696:560:4:0 with the example image you posted
[00:40:51 CEST] <furq> cropdetect tends to be too conservative
[00:41:01 CEST] <llogan> cropdetect won't account for the ~10 px head switching noise
[00:41:30 CEST] <zamba> -vf crop=720:560:0:6
[00:41:34 CEST] <zamba> it suggested that
[00:42:01 CEST] <iive> you can quick test options with ffplay
[00:42:09 CEST] <zamba> kepstin: yeah, i agree with you
[00:42:11 CEST] <furq> http://oi64.tinypic.com/27wrgpx.jpg
[00:42:13 CEST] <kepstin> zamba: yeah, cropdetect will give bad results with that video. I'd crop manually.
[00:42:14 CEST] <furq> for that?
[00:42:18 CEST] <furq> yeah that's no good
[00:42:24 CEST] <zamba> kepstin: maybe even remove another pixel or two from the right side
[00:43:03 CEST] <kepstin> zamba: make sure you crop with multiples of 2, at a minimum :)
[00:43:27 CEST] <kepstin> (multiples of 8 are typically recommended, but that's not really an issue with modern codecs as much, any more)
[00:43:39 CEST] <furq> it'll throw an error if you don't anyway
[00:43:51 CEST] <iive> still, it is good to have it on block boundary
[00:44:15 CEST] <kepstin> tell that to the people who picked 1080 as a standard vertical res for HD ;)
[00:44:55 CEST] <kepstin> well, I guess that is a multiple of 8, but the block size of most of the codecs used for that is 16 now, iirc?
[00:45:04 CEST] <iive> no
[00:45:08 CEST] <zamba> so is that crop=694:560:2:0 ?
[00:45:09 CEST] <iive> that's macroblock
[00:45:43 CEST] <kepstin> zamba: I'd probably still take 4 off the left, since there's a bit of ringing there, but sure.
[00:46:38 CEST] <zamba> so crop=694:560:4:0?
[00:46:50 CEST] <furq> 692
[00:47:16 CEST] <kepstin> zamba: up to you, of course :) You'll want to preview it in at least a couple places over the video to make sure it looks good
[00:48:02 CEST] <zamba> kepstin: well.. i don't know what i'm not seeing.. and i haven't fully understood the values and it's practical use
[00:48:10 CEST] <zamba> height:width:x:y
[00:48:13 CEST] <zamba> the x and y confuses me
[00:48:28 CEST] <furq> x and y are offsets from the left and top
[00:48:29 CEST] <kepstin> x is the offset from the left, y is the offset from the top
[00:48:50 CEST] <kepstin> and it's width:height:x:y :)
[00:49:57 CEST] <furq> the crop from the left side is x, the crop from the right side is input_width - (width + x)
[00:50:04 CEST] <zamba> yeah, this looks good: crop=692:560:2:0
[00:50:48 CEST] <furq> i still find left:top:right:bottom more intuitive but it's probably a bit late now
[00:51:12 CEST] <iive> btw, ffmpeg crop filter have another syntax. e.g. you can do stuff like `-vf crop=h=ih-6:y=4 `
[00:51:33 CEST] <iive> aka you can use formulas to calculate stuff. ih is input height
[00:53:38 CEST] <zamba> ok, i tried with the new command and i immediately see that the bitrate has dropped quite significally
[00:53:54 CEST] <furq> yeah denoising will do that
[00:53:59 CEST] <zamba> $ ffmpeg -f video4linux2 -i /dev/video0 -f alsa -i default -vf crop=694:560:2:0,yadif,hqdn3d,format=yuv420p <output>.mp4
[00:54:11 CEST] <zamba> but that's a "good thing"? :)
[00:54:23 CEST] <furq> it can be
[00:54:26 CEST] <zamba> hehe
[00:54:26 CEST] <furq> it sounds like it probably is in this case
[00:57:08 CEST] <zamba> hm, no.. there's something very odd about the new video
[00:57:13 CEST] <zamba> now the audio is out of sync
[00:57:30 CEST] <iive> btw, i think that when you work with interlaced images, you have to round to 4, not just 2
[00:58:05 CEST] <iive> that is if you do work in yuv420 format.
[00:58:37 CEST] <zamba> i don't know if i work in yuv420 format :)
[00:59:00 CEST] <iive> i mean, about cropping image, or more precisely, the x,y (starting cut off)
[00:59:14 CEST] <iive> you do have format=yuv420 in there :P
[00:59:38 CEST] <zamba> so i should have crop=692:560:4:0?
[00:59:47 CEST] <iive> i'm just not sure if it converts to yuv
[01:01:08 CEST] <iive> hum, it converts to it
[01:01:41 CEST] <iive> if your input is yuv444 or yuv422, then you can cut by 2
[01:02:11 CEST] <zamba> Stream #0:0: Video: rawvideo (YUY2 / 0x32595559), yuyv422, 720x576, 165888 kb/s, 25 fps, 25 tbr, 1000k tbn, 1000k tbc
[01:02:20 CEST] <zamba> but there's something odd about the audio here
[01:02:23 CEST] <iive> no problem then
[01:02:48 CEST] <zamba> if i start playing the file with mplayer, then the video is all black.. i can hear the audio, but i have to seek to get the actual video
[01:03:22 CEST] <zamba> oh, no.. i don't get video at all.. totally black video
[01:03:27 CEST] <iive> the ffmpeg output result?
[01:03:44 CEST] <zamba> yeah
[01:04:46 CEST] <zamba> but the conclusion about the cropping is that i can round to 2?
[01:05:41 CEST] <iive> zamba:  you know that yuv420 have smaller resolution for chroma samples.
[01:06:20 CEST] <iive> this means that for 4 pixels you have 4 luma samples (y) , 1 u and 1 v samples.
[01:06:33 CEST] <iive> the 4 pixels are aranged in 2x2 block.
[01:06:40 CEST] <zamba> *blank stare*
[01:06:44 CEST] <zamba> what is chroma and luma? :)
[01:07:05 CEST] <iive> luma is luminance, basically light intensity, or gray level
[01:07:12 CEST] <iive> chroma is color
[01:10:35 CEST] <zamba> i'll try removing the noise reduction and also the format thingy.. see if i have better results from playback
[01:11:12 CEST] <iive> the noise won't change anything about playback
[01:11:54 CEST] <zamba> well, something made the video unplayable
[01:12:06 CEST] <iive> you do generally want to encode in yuv420, as it is most commonly used video format
[01:21:04 CEST] <zamba> huh.. the problem was mplayer
[01:23:43 CEST] <zamba> all of a sudden i had to specify -vo x11
[01:27:02 CEST] <zamba> heh.. sound is gone
[01:27:20 CEST] <zamba> $ ffmpeg -f video4linux2 -i /dev/video0 -f alsa -i default -vf crop=694:560:2:0,yadif,hqdn3d,format=yuv420p <output.mp4>
[01:27:23 CEST] <zamba> anything wrong with that?
[01:28:04 CEST] <iive> zamba: are you with intel video as primary card?
[01:28:28 CEST] <zamba> iive: the playback issue is no issue.. i can live with specifying -vo x11 for now
[01:29:59 CEST] <zamba> just now i need to figure out how to get sound in my video again
[01:31:37 CEST] <furq> pastebin the ffprobe output just in case
[01:31:40 CEST] <zamba> http://pastebin.com/58VP3hCG
[01:32:18 CEST] <furq> i guess that works too
[01:32:21 CEST] <furq> looks fine
[01:32:37 CEST] <furq> wait did you build that ffmpeg yourself
[01:32:47 CEST] <zamba> furq: nope
[01:32:53 CEST] <furq> is that from ubuntu repos?
[01:33:00 CEST] <zamba> furq: well, i get no sound.. neither from ffplay, mplayer or vlc
[01:33:09 CEST] <furq> it shouldn't have --enable-libfdk-aac if you downloaded the binary
[01:33:29 CEST] <furq> although as far as you're concerned, that's a bonus, because that's the best aac encoder
[01:33:45 CEST] <zamba> well, this is the machine doing the playback.. not the same as the one doing the encoding
[01:33:53 CEST] <furq> oh
[01:35:09 CEST] <furq> are you sure it captured any audio
[01:35:15 CEST] <furq> it could just be silent rather than not playing
[01:35:45 CEST] <furq> with that said, if that audio track is 134k VBR then it obviously contains something
[01:37:35 CEST] <zamba> hehe, you're right
[01:37:42 CEST] <zamba> somehow the alsamixer changed the capture source
[01:40:16 CEST] <furq> fun
[01:40:31 CEST] <furq> also you should make sure you're encoding with either libfdk-aac or the post-3.0 builtin aac encoder
[01:40:39 CEST] <furq> all of the other aac encoders are crap
[01:44:09 CEST] <zamba> err..
[01:44:20 CEST] <zamba> Stream #0:1: Audio: aac (libfaac) ([64][0][0][0] / 0x0040), 48000 Hz, stereo, s16, 128 kb/s
[01:44:28 CEST] <furq> yeah libfaac is pretty bad
[01:44:32 CEST] <zamba> oh, come on
[01:44:48 CEST] <furq> if it sounds ok to you then it'll be fine
[01:45:12 CEST] <furq> or you could use -c:v libmp3lame
[01:45:16 CEST] <furq> er, -c:a
[01:45:43 CEST] <zamba> this is an mp4 container
[01:45:48 CEST] <zamba> mp3 will work fine there?
[01:46:04 CEST] <furq> actually you mentioned playing it back in a browser didn't you
[01:46:07 CEST] <furq> it's safest to stick with aac then
[01:46:13 CEST] <zamba> exactly
[01:46:25 CEST] <furq> mp3 should work anywhere in mp4, but i've had issues with it in browsers
[01:46:58 CEST] <zamba> can i get a good version of ffmpeg from an apt source somewhere?
[01:47:07 CEST] <zamba> so i can get a proper aac encoder?
[01:47:15 CEST] <furq> where did you get that ffplay from
[01:47:22 CEST] <furq> that apparently has fdk-aac
[01:48:02 CEST] <zamba> hm.. how do i check that again? :)
[01:48:30 CEST] <zamba> Version: 7:3.0.0+git1~trusty
[01:49:03 CEST] <furq> https://launchpad.net/~mc3man/+archive/ubuntu/trusty-media
[01:49:05 CEST] <furq> from there, by the looks
[01:49:37 CEST] <furq> that should have both decent aac encoders then
[01:49:40 CEST] <furq> or rather it does
[01:50:03 CEST] <furq> it shouldn't have fdk-aac because you're not allowed to distribute ffmpeg binaries with fdk because of a fun license party
[01:50:17 CEST] <furq> but apparently it does so you might as well make use of it
[01:50:54 CEST] <furq> -c:a libfdk_aac -b:a 128k
[01:50:59 CEST] <furq> or -c:a libfdk_aac -vbr 5
[01:51:44 CEST] <zamba> argh.. my encoding machine is running mint
[01:52:16 CEST] <furq> you should still be able to use ubuntu PPAs on mint
[01:52:29 CEST] <furq> failing that: http://johnvansickle.com/ffmpeg/
[01:52:36 CEST] <furq> that has the new builtin encoder (-c:a aac)
[01:53:28 CEST] <zamba> ah.. static built ones
[01:55:33 CEST] <zamba> what's ffmpeg-10bit?
[01:56:41 CEST] <zamba> hm.. this new version complains a lot
[01:56:53 CEST] <zamba> [alsa @ 0x3eb7780] ALSA buffer xrun.
[01:56:55 CEST] <zamba> [alsa @ 0x3eb7780] ALSA buffer xrun.  29kB time=00:00:02.08 bitrate= 115.6kbits/s speed=0.517x
[01:56:57 CEST] <zamba> [alsa @ 0x3eb7780] ALSA buffer xrun.  55kB time=00:00:04.24 bitrate= 106.5kbits/s speed=0.702x
[01:56:59 CEST] <zamba> [alsa @ 0x3eb7780] ALSA buffer xrun.  84kB time=00:00:06.40 bitrate= 108.0kbits/s speed=0.792x
[01:57:12 CEST] <furq> 10-bit has high-bit-depth encoders
[01:57:21 CEST] <furq> if you care about compatibility you don't want those
[01:58:07 CEST] <zamba> $ /usr/local/bin/ffmpeg -f video4linux2 -i /dev/video0 -f alsa -i default -vf crop=694:560:2:0,yadif,hqdn3d,format=yuv420p -t 01:05:00 12-jeppeturne.mp4
[01:58:09 CEST] <zamba> here we go
[01:58:22 CEST] Action: relaxed wonders if anyone even uses ffmpeg-10bit
[01:58:52 CEST] <furq> i use something called ffmpeg-10bit but not your binaries
[01:59:05 CEST] <furq> i would if i wasn't on windows
[01:59:11 CEST] <zamba> getting lots and lots of these "Past duration X too large" messages again
[01:59:23 CEST] <zamba> it's probably just me, but i hate warnings that flood the screen
[01:59:33 CEST] <furq> https://github.com/qruf/ffmpeg-10bit
[01:59:49 CEST] <furq> in case anyone wants non-infringing windows binaries with 10-bit x264
[02:00:05 CEST] <furq> i should probably update those
[02:02:38 CEST] Action: kepstin has his x264 set up so he can switch between the two by setting LD_LIBRARY_PATH :/
[02:04:09 CEST] <furq> that's nice but it doesn't really help people using static binaries
[02:04:40 CEST] <kepstin> yeah, I'm still kind of annoyed that the x264 folks haven't looked at supporting both in one library
[02:04:47 CEST] <furq> yeah
[02:04:51 CEST] <furq> x265 seems to manage it just fine
[02:05:43 CEST] <kepstin> it should be as simple as building it twice with symbol mangling, then have the initialization functions pick the implementation to use based on requested bit size.
[02:05:57 CEST] <kepstin> but.. more work than I want to put into it, at least :(
[02:06:23 CEST] <furq> i don't really mind having two ffmpeg binaries
[02:24:59 CEST] <Prelude2004c> hey guys.. godo day
[02:25:17 CEST] <Prelude2004c> having a serious problem and would like some help with it.. i am transcoding some data .. and i keep getting the system doing this
[02:25:18 CEST] <Prelude2004c> [hls @ 0x295cf60] Non-monotonous DTS in output stream 0:1; previous: 8535563676, current: 8535043243; changing to 8535563677. This may result in incorrect timestamps in the output file.
[02:25:18 CEST] <Prelude2004c> [aac @ 0x29c4720] Queue input is backward in time
[02:25:30 CEST] <Prelude2004c> i already put in the copytb 1
[02:25:42 CEST] <Prelude2004c> still keeps coming up with that randomly.. can anyone help?
[02:28:38 CEST] <Prelude2004c> anyone?
[02:40:26 CEST] <davidmichaelkarr> I'm trying to play a mp4 on centos7, and it says I need a H-264 decoder.  I installed "gstreamer-ffmpeg" because a SO posting said that would fix it, and it only changed where I got the message about needing that decoder.  I have the nux-desktop repo.
[02:41:00 CEST] <c_14> davidmichaelkarr: with what video player?
[02:41:09 CEST] <llogan> c_14: centos7
[02:41:41 CEST] <c_14> Last time I checked that was an OS and not a video player.
[02:42:06 CEST] <llogan> that was a joke
[02:42:14 CEST] <c_14> ah :p
[02:43:21 CEST] <c_14> long day
[02:44:46 CEST] <davidmichaelkarr> c_14: Well, I first just tried double-clicking from file-roller, but someone just told me about "vlc", which appears to work.  Any way to configure file-roller to open mp4s with vlc?
[02:46:53 CEST] <davidmichaelkarr> c_14: I saw a page that talked about setting defaults when installing vlc, but I just installed it through yum.  Is there a way to do this in the vlc interface?
[02:47:50 CEST] <c_14> Probably. This isn't related to ffmpeg though. ask in #videolan or #centostnos exists)
[02:48:02 CEST] <JPorter> hello, i was wondering if i can get clarifcation about using the ffmpeg library in proprietary software, it's not clear to me if that's allowed or not
[02:48:13 CEST] <c_14> *#centos if that exists
[02:48:33 CEST] <davidmichaelkarr> c_14: "centostnos"? That doesn't exist.
[02:49:01 CEST] <c_14> davidmichaelkarr: X ate my input, I meant #centos
[02:49:58 CEST] <c_14> JPorter: depends, the (L)GPL doesn't restrict use. It just places restrictions on redistribution
[02:50:05 CEST] <davidmichaelkarr> c_14: Yeah, that's where I first asked this. That's where I heard about vlc.
[02:50:09 CEST] <c_14> i.e. if you distribute your program linked against ffmpeg
[02:50:52 CEST] <JPorter> c_14: do i have to do dynamic linking?
[02:52:57 CEST] <furq> yes
[02:52:58 CEST] <c_14> It's not a matter of _how_ you link, but _that_ you link. afaik you can link against an LGPL FFmpeg and redistribute so long as you also distribute the source code of FFmpeg along with it, and any modifications of the FFmpeg source code and make it possible for users to link your proprietary code against their version of FFmpeg (provided they patch it assuming you added patches)
[02:53:06 CEST] <furq> https://www.ffmpeg.org/legal.html
[02:53:09 CEST] <furq> there's a checklist here
[02:53:31 CEST] <furq> you don't have to distribute the source of your application as long as you're using ffmpeg libraries compiled without --enable-gpl
[02:53:36 CEST] <c_14> Note: we are all not lawyers, your lawyer knows best
[02:53:48 CEST] <furq> and yeah, what he said
[02:54:19 CEST] <JPorter> but would i be able to use these builds for instance: https://sanje2v.wordpress.com/2014/04/15/ffmpeg-lgpl-v3-binaries-for-windows/
[02:54:52 CEST] <furq> i guess
[02:54:56 CEST] <furq> those are pretty old though
[02:56:28 CEST] <furq> also that guy isn't distributing ffmpeg and library sources, which he's obliged to do
[02:56:40 CEST] <JPorter> im confused why this guy provides static builds though
[02:56:45 CEST] <furq> so i wouldn't trust him to be an expert on license compliance given he hasn't managed to comply himself
[02:56:51 CEST] <JPorter> wouldnt .dll's be far more useful?
[02:57:04 CEST] <furq> that is also a good point
[02:57:30 CEST] <furq> i guess that's for people who want to distribute the binary with their application
[02:58:25 CEST] <JPorter> to interact via command line?
[02:58:30 CEST] <JPorter> is that allowed under LGPL?
[02:58:33 CEST] <furq> if your app relies on an external ffmpeg binary for a significant part of its functionality it could be argued that it's a derived work
[02:58:49 CEST] <furq> it's as allowed as linking is
[02:59:33 CEST] <furq> you should probably just compile ffmpeg yourself, it's not that hard
[02:59:47 CEST] <furq> especially if you don't need any external libraries
[03:00:46 CEST] <JPorter> ive heard its quite a pain
[03:02:21 CEST] <JPorter> is that why Zeranoe offers Quote Request
[03:02:25 CEST] <JPorter> do they charge?
[03:02:37 CEST] <furq> what else would quote mean
[03:04:38 CEST] <JPorter> ive noticed you can only have windows builds with that
[03:05:19 CEST] <furq> ?
[03:07:00 CEST] <JPorter> on the quote request page
[03:07:15 CEST] <JPorter> only windows build architecture is available
[03:07:27 CEST] <furq> oh right
[03:07:43 CEST] <furq> i doubt there's much money in offering linux builds
[03:08:09 CEST] <JPorter> well i intend my software to be cross platform
[03:08:16 CEST] <JPorter> particular mac & windows
[03:08:47 CEST] <furq> like i said, it's not that difficult to build ffmpeg
[03:09:02 CEST] <furq> on *nix, with no external libraries, it's three commands
[03:09:10 CEST] <furq> and you can cross compile for windows and osx from *nix
[03:09:26 CEST] <JPorter> hmm, well im on win tho have *nix vm
[03:09:45 CEST] <JPorter> but i will need external libraries for mp3
[03:10:06 CEST] <furq> https://github.com/qruf/ffmpeg-mingw
[03:10:09 CEST] <furq> you can give that a try if you want
[03:10:22 CEST] <furq> it doesn't produce shared libs though
[03:10:41 CEST] <kepstin> I actually found it easier to build ffmpeg for windows on a linux machine than natively on windows, when I was doing it :/
[03:10:49 CEST] <furq> yeah i've always cross compiled
[03:10:49 CEST] <kepstin> dunno if that's changed since
[03:10:57 CEST] <furq> i always had issues building libraries with msys
[03:11:45 CEST] <furq> i've got a branch of ffmpeg-mingw which does produce shared libs but i've not finished or tested it yet
[03:11:47 CEST] <JPorter> hmm, i guess i could do that in my vm then
[03:11:50 CEST] <furq> i should probably finish it up
[03:11:55 CEST] <kepstin> was kind of funny, the last time i was doing windows stuff with ffmpeg, I did all the dev on linux with mingw32 and wine.
[03:13:59 CEST] <JPorter> what happens if i just build my application with shared ffmpeg GPL libraries, but don't distribute the libraries/dlls with my application and ask the user to obtain the dll and drop it into the application folder himself?
[03:19:32 CEST] <JPorter> is that legal?
[03:23:15 CEST] <c_14> I think so, but ianal
[04:03:26 CEST] <JPorter> why do you need to literally include the source code rather than just provide a link to where you can obtain it, isnt that a little antiquated for LGPL projects?
[04:04:57 CEST] <furq> because the link might die
[04:05:48 CEST] <furq> you don't have to include the source code, you just need to make it available in the same place as the binaries are downloaded from
[04:06:35 CEST] <furq> iirc it's sufficient to make it available on request, but if you're going to ensure you have it available if requested then you might as well just upload it
[04:06:48 CEST] <furq> since you'd need the correct version etc
[05:15:01 CEST] <Guest12199> Hi all
[06:15:10 CEST] <Samsam> Hiiiiiiiiii
[06:15:40 CEST] <Samsam> Could u please guide me what is the command line to encode a video to hevc?
[06:30:48 CEST] <Samsam>  Could u please guide me what is the command line to encode a video to hevc?
[07:22:38 CEST] <pinPoint> does anyone know whether I could export from premiere cc bridge the export(temp file_ to ffmpeg and have ffmpeg do prores out?
[07:23:01 CEST] <pinPoint> like  a proxy
[07:44:31 CEST] <pzich> pinPoint: you want to export from premiere in an intermediate codec, then re-render into a final prores encoding with ffmpeg?
[07:46:36 CEST] <prago_1> hi. I try to extract all images of a video via "ffmpeg -f image%d.png myvideofile.avi" . How can I be sure to get the best image quality/resolution? because the videos are all of different qualities/resolutions?
[07:49:02 CEST] <pzich> if you're using PNG as your output, the quality should already be "lossless", as best as it can decode it
[07:49:58 CEST] <prago_1> ok. simple answer. thank you very much. thats what I wished to know. bye
[08:19:36 CEST] <Gringe> Hey, I'm trying to do a low latency streaming from one Pc in my local Network to another. At the Moment the latency is about 1-2 Seconds. Therefor on the host side I run
[08:19:50 CEST] <Gringe> ffmpeg -f dshow  -framerate 24 -i video=screen-capture-recorder -vf scale=1280:720 -vcodec libx264 -force_key_frames "expr:gte(t,n_forced*2)" -pix_fmt yuv420p -tune zerolatency -preset ultrafast -f mpegts udp://239.255.1.2:1234
[08:20:00 CEST] <Gringe> and on clientside :
[08:20:09 CEST] <Gringe> ffplay -fflags nobuffer -infbuf -fast -framedrop -vf "setpts=(PTS*0.95)" udp://239.255.1.2:1234
[08:20:20 CEST] <Gringe> any Ideas, how I could improve this ?
[08:20:57 CEST] <Gringe> I am running host and client at the same Pc for testing
[08:22:01 CEST] <zamba> furq: there's something seriously wrong with that static ffmpeg you linked me yesterday.. it only produced hiss and clicks for the audio..
[09:49:56 CEST] <pinPoint> pzich: I want to export to a proxy while picking it up with ffmpeg
[09:50:08 CEST] <pinPoint> since premiere has not prores output
[09:51:25 CEST] <pzich> I guess I don't know what you mean by proxy. In the past I've exported from Premiere or AE to something high quality, then had a script to watch for new .mov files and create a corresponding .mp4
[09:51:42 CEST] <pinPoint> ok
[11:15:31 CEST] <Gringe> Hey, I'm trying to do a low latency streaming from one Pc in my local Network to another. At the Moment the latency is about 1-2 Seconds. Therefor on the host side I run
[11:15:42 CEST] <Gringe> ffmpeg -f dshow  -framerate 24 -i video=screen-capture-recorder -vf scale=1280:720 -vcodec libx264 -force_key_frames "expr:gte(t,n_forced*2)" -pix_fmt yuv420p -tune zerolatency -preset ultrafast -f mpegts udp://239.255.1.2:1234
[11:15:52 CEST] <Gringe> and on clientside :
[11:16:01 CEST] <Gringe> ffplay -fflags nobuffer -infbuf -fast -framedrop -vf "setpts=(PTS*0.95)" udp://239.255.1.2:1234
[11:16:18 CEST] <Gringe> any Ideas, how I could improve this ?
[11:21:45 CEST] <zamba> furq: nah, the result is very disappointing.. there's something very off with the audio
[12:13:26 CEST] <momomo> does this make sense ?   -b:v 2048k -bufsize 2048k -maxrate 300k ?
[12:13:48 CEST] <momomo> maxrate should be the same no, but this has a different effect
[12:14:34 CEST] <JEEB> how the effect is seen depends on the encoder. basically you are setting a rate control mode and then you are further limiting the max rate over bufsize to be 300k
[12:17:11 CEST] <momomo> but the file output now is about 700kb .. when maxrate is at 2048 and bufsize the same i am hitting 2.7 mb
[12:17:21 CEST] <JEEB> of course
[12:17:32 CEST] <JEEB> maxrate in any sane encoder overrides your main rate control
[12:17:36 CEST] <momomo> so it is not +- bufsize
[12:17:54 CEST] <JEEB> bufsize is just the amount of bits during which the VBV/HRD rate is calculated
[12:17:59 CEST] <momomo> libx264
[12:18:15 CEST] <JEEB> in layman terms, maximum allowed in VBV/HRD is maxrate over bufsize
[12:18:35 CEST] <momomo> ook .. is a high bufsize good for cpu performance ?
[12:18:47 CEST] <momomo> so i should go for maxrate to determine the output size
[12:19:04 CEST] <momomo> i want to keep cpu usage low
[12:19:15 CEST] <momomo> but be able to control filesize
[12:19:46 CEST] <momomo> within say +- 100kb .. to around 2048 mb for 10 seconds
[12:19:50 CEST] <momomo> kb
[12:30:58 CEST] <momomo> high bufsize, performance implications ?
[12:31:04 CEST] <momomo> anyone?
[13:05:45 CEST] <Eiken_> anyone else getting a green border on the bottom of the output when encoding dnxhd .mxf files?
[13:06:05 CEST] <Eiken_> input is 1920x1080 and dnxhd should always be that but becomes 1920x1088
[13:11:33 CEST] <Eiken_> lol
[13:11:41 CEST] <Eiken_> i am stupid, that seems to be correct for those files
[17:40:45 CEST] <momomo> how can I select the english audio track if there are multiple on the source ?
[17:41:11 CEST] <furq> -map 0:a:language:eng
[17:41:11 CEST] <c_14> -map 0:m:lang:eng
[17:41:22 CEST] <furq> m?
[17:41:32 CEST] <c_14> I'm pretty sure you need the m to match metadata
[17:41:40 CEST] <furq> ah
[17:41:43 CEST] <c_14> Says so in the manpage anyway
[17:44:13 CEST] <momomo> is there a quick command to get the metadata only? right now, the first command is the ffmpeg to hls command
[17:44:27 CEST] <momomo> i tried -map 0:a:language:eng .. i got the same audio but the picture is gone
[17:44:37 CEST] <c_14> you also have to map the video stream
[17:44:42 CEST] <c_14> -map 0:v:0 probably
[17:44:49 CEST] <furq> using -map enables manual stream selection
[17:45:00 CEST] <furq> unless you use it to deselect a stream
[17:53:36 CEST] <zamba> furq: are you able to help me out a bit more?
[17:54:01 CEST] <zamba> furq: running with the static ffmpeg gives me choppy audio.. lots of hiss and encoding static..
[17:54:30 CEST] <momomo> -map 0:m:language:eng -map 0:v:0  worked
[17:54:35 CEST] <momomo> the others not
[17:55:02 CEST] <momomo> zamba, maybe using libacc ... i upgraded to aac
[17:55:16 CEST] <momomo> i was getting the same before .. i think it's gone
[17:55:31 CEST] <furq> zamba: pastebin the command
[17:56:27 CEST] <zamba> furq: oh, i have to run.. i'll check back over the weekend.. thanks :)
[18:10:06 CEST] <SixEcho> so i'm using "ffmpg -f concat" - but would like it to copy the metadata from the first video& how to specify?
[18:11:10 CEST] <SixEcho> actually these videos are from a gopro& and have a tmcd stream which concat does not work with  is there any way to preserve the tmcd(timecode) streams and concat them?
[18:12:47 CEST] <SixEcho> here is the concat warning:  [concat @ 0x7f8e02800800] Could not find codec parameters for stream 2 (Unknown: none): unknown codec;  Consider increasing the value for the 'analyzeduration' and 'probesize' options
[18:13:08 CEST] <SixEcho> and the stream info:
[18:13:09 CEST] <SixEcho>     Stream #0:2(eng): Data: none (tmcd / 0x64636D74) (default)
[18:13:09 CEST] <SixEcho>     Metadata:
[18:13:09 CEST] <SixEcho>       creation_time   : 2016-04-05 18:34:43
[18:13:09 CEST] <SixEcho>       timecode        : 18:33:36:31
[18:44:55 CEST] <himura> hi
[18:46:50 CEST] <durandal_170> Hi
[18:48:45 CEST] <himura> I am facing an "Unknown encoder 'libvo_aacenc' 'when trying to convert a file to .mp4 .webm
[18:49:03 CEST] <furq> himura: which ffmpeg version
[18:49:13 CEST] <furq> if it's newer than 3.0 then libvo_aacenc was removed
[18:49:17 CEST] <furq> use -c:a aac
[18:51:44 CEST] <himura> I use the versio 2.8.6
[18:51:50 CEST] <himura> on fedora 23
[18:54:51 CEST] <furq> himura: ffmpeg -codecs | grep aac
[18:54:54 CEST] <klaxa> webm suports aac?
[18:54:58 CEST] <klaxa> that's news to me
[18:55:10 CEST] <furq> i assume he means to mp4 from webm
[18:55:33 CEST] <klaxa> aah
[19:09:22 CEST] <himura> problem solved furq
[19:09:46 CEST] <himura> thank you
[19:24:14 CEST] <rrva> is there any tool like http://gopchop.sourceforge.net/ but for h264?
[19:28:49 CEST] <furq> you can cut on gop boundaries with ffmpeg
[19:29:06 CEST] <furq> i don't know of any gui for it though
[19:30:14 CEST] <furq> maybe avidemux
[20:31:18 CEST] <ZeNEX> Hello guys. I am following a guide on how to use ffmpeg for development. A source file includes the header file ffmpeg/swscale.h however I do not find the ffmpeg libraries in Debian. What package should I look for?
[20:32:27 CEST] <furkan> ZeNEX: try apt-file search swscale.h
[20:32:35 CEST] <furkan> ZeNEX: in ubuntu the package name is libswscale-dev
[20:32:59 CEST] <ZeNEX> furkan, apt-file command not found
[20:33:15 CEST] <furkan> ZeNEX: you'll need to apt-get install apt-file, and then run apt-file update to download the database of files
[20:33:34 CEST] <ZeNEX> Thanks
[20:33:37 CEST] <furkan> i guess apt-file isn't a default package
[20:33:39 CEST] <furkan> np
[20:36:31 CEST] <furkan> i want to set up a computer that acts as a VoIP phone, so that anybody can call the computer's extension, and then the computer will stream the phone call to the internet via RTMP, does anybody know if ffmpeg can do this?
[20:38:25 CEST] <c_14> If you can setup a SIP client to automatically accept all incoming calls and then feed the audio to an ffmpeg process it spawns, sure.
[20:39:51 CEST] <c_14> eh
[20:39:54 CEST] <c_14> you'll also need an rtmp server
[20:40:05 CEST] <furkan> rtmp server is no problem
[20:40:31 CEST] <furkan> i guess if there is a sip client that can stream to rtsp://localhost
[20:40:50 CEST] <furkan> i could spawn the ffmpeg process myself and take the local stream as input, and then stream it to a remote rtmp server...
[20:40:59 CEST] <c_14> You could check if there's a sip client with a "record command" option or something
[20:43:06 CEST] <furkan> oh interesting, SIP uses RTP to carry the audio stream
[20:43:13 CEST] <furkan> so i guess there must be a way to sniff that
[20:51:02 CEST] <t4nk036> i failed compiling ffmpeg on ubuntu 14.04
[20:51:22 CEST] <t4nk036> problem starts here: pastebin.com/EuPTSCKK
[20:52:28 CEST] <t4nk036> from following this guide: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
[20:54:17 CEST] <c_14> did you ever run ./configure?
[20:55:57 CEST] <t4nk036> yes, i copied the full command from the guide
[20:57:25 CEST] <c_14> maybe your shell is fucking up. try only copying the part related to the configure
[20:58:43 CEST] <t4nk036> im starting again from scratch
[20:59:03 CEST] <kepstin> t4nk036: do one command at a time, and make sure it completes successfully before going on to the next.
[21:00:34 CEST] <strk> given a set of .ts files, being the video and the audio streams in pieces, how can I get them played in sync and one after the other ?
[21:00:56 CEST] <strk> like: segment262_1_av.ts  segment429_0_av.ts  segment595_1_av.ts  segment761_1_av.ts  segment99_1_av.ts
[21:01:24 CEST] <kepstin> strk: cat segment262_1_av.ts  segment429_0_av.ts  segment595_1_av.ts  segment761_1_av.ts  segment99_1_av.ts >combined.ts
[21:02:37 CEST] <strk> cat segment*_0_av.ts > combined_0_av.ts; cat segment*_1_av.ts > combined_1_av.ts
[21:02:58 CEST] Action: strk just hopes the bash does the right thing
[21:03:24 CEST] <strk> assuming it did, now how do I put togheter the two streamns ? (one is audio, the other is video)
[21:03:47 CEST] <c_14> ffmpeg -i audio -i video -c copy out.ts
[21:04:00 CEST] <c_14> assuming there's only 1 audio and 1 video stream
[21:04:19 CEST] <kepstin> oh, it's separate audio and video files?
[21:04:44 CEST] <furq> strk: glob expansion in bash should be in alphabetical order
[21:04:54 CEST] <furq> so `cat *.ts > out.ts` should work
[21:06:09 CEST] <furq> or should have worked, rather, since you already did that
[21:06:42 CEST] <t4nk036> PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure
[21:06:47 CEST] <t4nk036> is that supposed to be one line? ^
[21:07:03 CEST] <furq> yes
[21:07:23 CEST] <strk> segment1_ segment9_ segment111_
[21:07:30 CEST] <strk> alphabetical, unfortunately, won't work
[21:07:42 CEST] <strk> also, therels _0_ and _1_ (two streams)
[21:07:55 CEST] <strk> are you saying I should concatenate stream 0, stream 1 and back ?
[21:08:13 CEST] <strk> kepstin: I _think_ they are separated, but not sure now
[21:08:13 CEST] <c_14> cat segment*0* > a.ts; cat segment*1* > b.ts
[21:08:23 CEST] <c_14> eeeh
[21:08:25 CEST] <c_14> wait
[21:08:46 CEST] <c_14> might need some better globs there
[21:09:54 CEST] <kepstin> segment*_0_av.ts and segment*_1_av.ts would be better :)
[21:10:14 CEST] <kepstin> I assume the 0 and 1 at the end refer to the stream, where one of them is audio, th other video
[21:10:27 CEST] <kepstin> but yeah, you have to check and make sure that's correct :)
[21:11:47 CEST] <strk> actually, stream _0_ seems to be all
[21:11:55 CEST] <strk> maybe _1_ is another quality
[21:14:55 CEST] <furq> ls -v segment*_0_av.ts | xargs cat >> out.ts
[21:14:56 CEST] <furq> there
[21:15:10 CEST] <furq> now you can delete everything you've done so far and run a slightly better command. hooray
[21:17:08 CEST] <kepstin> ls with a glob is completely redundant...
[21:17:19 CEST] <furq> -v is natural sort order
[21:17:32 CEST] <furq> natural being 9 < 10
[21:17:37 CEST] <kepstin> ah, in case you have e.g. both 567 and 1234 ?
[21:17:40 CEST] <furq> yeah
[21:28:17 CEST] <strk> so stream 1 is higher quality, great
[21:28:27 CEST] <strk> I used seq(1) to put order :)
[21:48:59 CEST] <rrva> furq: how to cut on GOP boundaries, without any remuxing preferably
[21:49:31 CEST] <rrva> furq: ssegment ?
[21:49:42 CEST] <furq> just use -ss and -t
[21:49:48 CEST] <furq> it'll seek to the nearest idr frame
[21:50:26 CEST] <furq> if you want every gop as a separate file then use segment
[21:59:15 CEST] <Prelude2004c> hey guys.. good day
[21:59:17 CEST] <Prelude2004c> can anyone help me
[21:59:28 CEST] <Prelude2004c> [20:24:14] <Prelude2004c> [hls @ 0x295cf60] Non-monotonous DTS in output stream 0:1; previous: 8535563676, current: 8535043243; changing to 8535563677. This may result in incorrect timestamps in the output file.
[21:59:28 CEST] <Prelude2004c> [20:24:14] <Prelude2004c> [aac @ 0x29c4720] Queue input is backward in time
[21:59:42 CEST] <Prelude2004c> not sure what to do about it.. i tried the async 1 but ti overloads the server and cpu
[21:59:55 CEST] <t4nk036> can soneone link me to a good guide to cross compiling ffmpeg with mxe?
[22:04:35 CEST] <BtbN> well, fix your source so it doesn't have non-monotonous DTS
[22:07:27 CEST] <furkan> i can't seem to find a solution to my SIP problem... is there any way for ffmpeg to connect to a SIP URL? looks like mplayer can do it
[22:08:13 CEST] <BtbN> ffmpeg is not a sip client, i'd be surprised if that works.
[22:09:50 CEST] <furkan> and i can't find a SIP client i could use to pipe the RTP stream to ffmpeg...
[22:10:11 CEST] <furkan> i'm sort of confused that there's no easy way to do this
[22:10:16 CEST] <c_14> Well, sip uses both sdp and rtp and ffmpeg supports both. So on a certain level there isn't _that_ much missing.
[22:12:24 CEST] <c_14> You're probably going to go furthest by finding an SIP library for your favorite scripting language which accepts calls and then forwards the rtp to ffmpeg
[22:13:39 CEST] <furkan> c_14: hmm interesting idea... i'll see if there's a way i can do that with python, thanks for the suggestion
[22:14:08 CEST] <furkan> if all else fails... maybe i should try to implement it myself in ffmpeg lol
[22:14:35 CEST] <furkan> it can't be that bad, most of the pieces are in place as you pointed out
[22:22:51 CEST] <Prelude2004c> BtbN , i can't fix the source
[22:22:56 CEST] <Prelude2004c> it comes from satelite
[22:23:14 CEST] <BtbN> well, nothing you can realy do then
[22:31:21 CEST] <kurtcobain> I'm experiencing significantly slower encoding speeds with ffmpeg's VP9 encoder vs. the VP8 encoder (all else being equal). Is this a known problem?
[22:31:48 CEST] <JEEB> vp9 and vp8 are both handled by libvpx
[22:31:55 CEST] <JEEB> libavcodec just has wrappers for those
[22:32:00 CEST] <furq> what makes you think two different codecs would be the same speed
[22:32:02 CEST] <JEEB> the encoding that is
[22:32:09 CEST] <hpp> VP9 and h.265 are soo slow
[22:32:14 CEST] <JEEB> and yes, the vp9 encoding will be slow
[22:33:11 CEST] <kurtcobain> I can't say I thought they would be the same speed, but I just wanted to confirm what I was seeing.
[22:33:43 CEST] <kurtcobain> Only saw a couple of rumblings about it through searching Google, so thought it best to check here.
[22:33:45 CEST] <kurtcobain> Thanks!
[22:37:21 CEST] <andross> oops
[22:37:40 CEST] <andross> im looking for help cross compiling from linux to windows
[22:38:40 CEST] <furq> what kind of help
[22:39:48 CEST] <JEEB> just install a mingw-w64 toolchain (either targeting 32bit or 64bit windows) and add it to your PATH
[22:39:53 CEST] <JEEB> then set cross-prefix
[22:40:11 CEST] <andross> is msx one of those tool chains?
[22:40:17 CEST] <JEEB> no idea
[22:40:25 CEST] <JEEB> probably someone distributing a toolchain, maybe
[22:40:39 CEST] <JEEB> for specifics for specific toolchains, resort to their documentation or support
[22:40:59 CEST] <JEEB> I can only say that you set the cross-prefix and maybe the OS?
[22:41:12 CEST] <JEEB> and you can get FFmpeg itself built
[22:41:16 CEST] <andross> set it where, on configure?
[22:41:19 CEST] <JEEB> yes
[22:41:26 CEST] <JEEB> ./configure --help | less
[22:41:29 CEST] <JEEB> and seach for cross-prefix
[22:41:32 CEST] <furq> andross: https://github.com/qruf/ffmpeg-mingw
[22:41:35 CEST] <furq> you can try that if you want
[22:41:37 CEST] <andross> also i wish to build shared/dynamic link libraries
[22:41:38 CEST] <furq> it's pretty simple though
[22:41:44 CEST] <furq> well that fell through quickly
[22:41:48 CEST] <andross> heh
[22:41:50 CEST] <JEEB> --disable-static --enable-shared
[22:41:54 CEST] <JEEB> is all you need for shared-only
[22:41:58 CEST] <JEEB> default is static
[22:42:07 CEST] <furq> i should really fix up this shared library branch
[22:42:12 CEST] <andross> well it cant be static for lgpl right?
[22:42:29 CEST] <JEEB> it can but it makes it much less simple to be in general LGPL compliant :P
[22:42:43 CEST] <JEEB> and you mean in a context where LGPL is used from a proprietary thing that is
[22:42:51 CEST] <andross> yea
[22:43:08 CEST] <JEEB> because LGPL is a license that gives the user the right to replace the library if he/she so wants
[22:43:19 CEST] <JEEB> so for static you have to give everything required to link it :P
[22:43:25 CEST] <JEEB> which includes your object files
[22:43:51 CEST] <JEEB> for shared it's usually just the source code used to generate the library so the same kind can be built by the user and used instead
[22:44:40 CEST] <JEEB> andross: http://fatebeta.ffmpeg.org/history/x86_64-mingw-w64-windows-native so you need cross-prefix, arch and target-os
[22:44:47 CEST] <JEEB> those are three main params :)
[22:45:05 CEST] <JEEB> the rest are stuff related to the configuration or testing setup
[22:47:29 CEST] <JEEB> the toolchain you would want to have would either have i686-w64-mingw32-TOOL or x86_64-w64-mingw32-TOOL
[22:47:41 CEST] <JEEB> depending on win32 vs win64
[23:04:27 CEST] <andross> sorry was away
[23:05:35 CEST] <andross> hold on which one is win32
[23:05:55 CEST] <JEEB> mingw-w64 for win32 is i686-w64-mingw2-
[23:06:18 CEST] <JEEB> mingw-w64 being the fork of mingw which is kind of updated
[23:06:18 CEST] <andross> thats confusing :S
[23:06:30 CEST] <JEEB> well, it's either i686 or x86_64 :P
[23:06:45 CEST] <JEEB> although the name of the fork is kind of confusing because it started off as just having 64bit support
[23:06:55 CEST] <JEEB> then "ye olde mingw" kind of withered off
[23:07:03 CEST] <JEEB> so now mingw-w64 is the alive mingw
[23:09:35 CEST] <andross> what is the package name for i686-w64-mingw32-TOOL?
[23:11:07 CEST] <BtbN> package name?
[23:11:41 CEST] <andross> how/where do i grab that toolchain
[23:11:43 CEST] <TD-Linux> depends on distribution
[23:11:59 CEST] <BtbN> emerge crossdev and instruct it to build you that toolchain
[23:12:53 CEST] <andross> also just to clarify, im a windows user running an ubuntu virtual machine so i dont have much experience with linux
[23:15:18 CEST] <furq> if you're on ubuntu just apt-get install mingw-w64
[23:15:25 CEST] <furq> you'll probably also need build-essential and yasm
[23:16:50 CEST] <JEEB> yeah, which are standard compilation tools and yasm is to be used when building stuff for intel architectures
[23:17:15 CEST] <JEEB> and yeah, git of course to get the source code :P
[23:18:13 CEST] <furq> you can just get the snapshot
[23:18:36 CEST] <JEEB> yeah, but what's the fun in that
[23:18:54 CEST] <JEEB> not to mention you can jump between versions if you really require, as well as tag versions you've used before
[23:21:52 CEST] <andross> okay i got mingw-w64
[23:22:46 CEST] <andross> can i just follow this guide until the final configure step https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
[23:28:44 CEST] <JEEB> no
[23:29:12 CEST] <JEEB> also you shouldn't start off building a kitchen sink included build
[23:29:57 CEST] <JEEB> just get ffmpeg's source code with git, get the mingw-w64 i686-w64-mingw32 toolchain (if you want win32 builds) and build-essential + yasm
[23:30:04 CEST] <JEEB> then do a very basic configuration
[23:31:03 CEST] <JEEB> ./configure --cross-prefix=i686-w32-mingw32- --arch=i686 --target-os=mingw32 --disable-static --enable-shared
[23:31:28 CEST] <JEEB> you could even drop the last two for a test, but that should let you get shared FFmpeg built as LGPL (default)
[00:00:00 CEST] --- Sat Apr  9 2016