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

[burek]

[06:29:50 CEST] <ausjke> .
[06:33:40 CEST] <ausjke> beginner to use ffmpeg libs, any good pointers?
[09:22:57 CEST] <ausjke> avio_open(&pAVContext->pb, pFileName, AVIO_FLAG_WRITE)
[09:23:33 CEST] <ausjke> i have one stream that is saved to pFileName, the filename size keeps at 9900Byte until the end when it's closed
[09:23:51 CEST] <ausjke> it's like all the buffer is not flushed to the file itself until it closes, why is that
[09:24:08 CEST] <ausjke> my other stream uses the same avio_open worked as expected, just the second stream does not
[09:24:37 CEST] <ausjke> debugging for two days to no avail
[09:39:06 CEST] <durandal_1707> ausjke: to what output container?
[10:00:53 CEST] <garrett3> hey guys. Is there a way to cut a fragment out and get the rest as a result in one command?
[10:06:41 CEST] <ausjke> durandal_1707: http://pastebin.ca/3056928
[10:07:45 CEST] <ausjke> I'm to maintain this code, new to ffmpeg, the same code works for the first video stream, not the second(file size stuck with 9900Byte until it's closed, the size will suddenly jump to a correct size then)
[10:09:31 CEST] <ausjke> my first try is to do avio_open(AVIO_FLAG_WRITE), no help, it seems like the buf allocated may not be flushed to the file until it's closed, at that time av_free is called indeed
[10:43:35 CEST] <zer0byte_> hey
[11:39:50 CEST] <durandal_1707> ausjke: can you flush?
[12:11:53 CEST] <ausjke> durandal_170: drop_cache on linux, sync etc has no effect, any other way to flush?
[12:12:38 CEST] <ausjke> AVIO_FLAG_DIRECT no effect either
[13:01:40 CEST] <kubast2> Hey does ffmpeg uses multithreading by default ,or do I need to add "-threads:stream_index threads"[5.1 ffmpeg documentation] to the command to make use of multicore system?
[13:02:55 CEST] <c_14> It's automatic for many codecs. For some you'll need to specify -threads [num] as an output option
[13:03:15 CEST] <JEEBsv> if your ffmpeg is new enough (AKA summer 2011 or newer), many things default to auto threads, yes
[13:04:18 CEST] <JEEBsv> and in general if you don't get threading by default the thing most probably has no threading :)
[13:06:32 CEST] <durandal_170> frame threading for audio decoders is by default disabled
[13:07:32 CEST] <JEEBsv> yes, but audio decoding in general isn't what you really need threading with :)
[13:08:27 CEST] <kubast2> And for audio converting you can always use "--enable-opencl"
[13:08:36 CEST] <kubast2> to speed things up right?
[13:09:02 CEST] <kubast2> *only intel and amd gpus*
[13:09:17 CEST] <JEEBsv> wat :D
[13:09:36 CEST] <kubast2> the nvidia cards have poor opencl performance
[13:09:56 CEST] <JEEBsv> no, what the hell did you smoke is what I meant
[13:10:06 CEST] <kubast2> the --enable-opencl?
[13:10:14 CEST] <JEEBsv> yes, that barely does anything
[13:10:18 CEST] <JEEBsv> it has some filters I think?
[13:10:24 CEST] <JEEBsv> but that's really it
[13:10:27 CEST] <JEEBsv> generally useless
[13:12:56 CEST] <kubast2> I think it isn't even enable in windows version
[13:13:03 CEST] <kubast2> "unrecognized option"
[13:13:23 CEST] <JEEBsv> it's a configure option, not a command line option
[13:14:54 CEST] <JEEBsv> ok, with a quick git grep on a probably month old git clone there's a deshake and unsharp filter for it
[13:14:58 CEST] <JEEBsv> that's it :P
[13:16:38 CEST] <JEEBsv> and I'm not even sure if those are faster than the CPU variants, although they hopefully are because they are doing what in theory GPUs are good at - actually processing image data (not decoding or encoding, because for those you have to actually create the formats around the limitations of what you can do well with GPUs)
[13:17:05 CEST] <JEEBsv> tl;dr where the flying fuck did you get the idea that opencl would be used for anything at all in ffmpeg :P
[13:28:59 CEST] <kubast2> I dunno ,I think I through so because my gpu have h.264 decoder(maybe) & encoder(100%)[through it uses a diffrent api that isn't opencl]. And I sometimes heard about cuda/opencl video encoding[from some sony vegas pro and premiere pro cs6 test and I see it barelly does anything if not performs worser than cpu].
[13:29:16 CEST] <kubast2> *I checked now a test
[13:31:01 CEST] <kubast2> *beetwen sony vegas pro premiers cs6 that shows that opencl/cuda does nothing if doesn't performs worser than cpu only
[13:34:35 CEST] <JEEBsv> kubast2: the GPUs have had dedicated hardware for decoding video for ages, because it makes no sense to do it on the actual GPU hardware
[13:34:41 CEST] <JEEBsv> and lately they did the same for encoding
[13:35:25 CEST] <JEEBsv> they tried to sell encoding with the actual GPU parts for a while, and people actually paid good bucks for very expensive heating
[13:36:45 CEST] <kubast2> I mean I can even see it while watching youtube videos ,where at 4k my pc chills wiht 0% of cpu usage.
[13:39:21 CEST] <JEEBsv> x264 actually has a lookahead thing made with opencl, but it's just a Proof of Concept, and generally ends up just being slower than doing the lookahead on your CPU. yet it has the magic of gpgpu and I bet quite a few companies sold machines running x264 with that stuff enabled and took good bucks for it 8) (for little to no result)
[13:39:25 CEST] <well0ne> hi guys  i have 3 seaons from a series i want to "stream",  2 seasons are in 23.976 fps format , the third has 25fps, my problem is that i want to stream the files. but i need to change the fps from the thirds season, so i did with -r 23.976 and atempo the result is quite well but there is some little (whats normal) difference, the audiostream is some miliseconds longer than the video. but i'm going to make a live stream so with my t
[13:39:47 CEST] <JEEBsv> well0ne: why would you have to change the frame rate?
[13:39:54 CEST] <JEEBsv> all sane containers have timestamps
[13:40:05 CEST] <well0ne> well
[13:40:08 CEST] <JEEBsv> so even if it's a single stream it should switch seamlessly
[13:40:14 CEST] <well0ne> i'm streaming to an rtmp server
[13:40:18 CEST] <JEEBsv> which means FLV
[13:40:24 CEST] <JEEBsv> which has a 1ms timescale
[13:40:32 CEST] <well0ne> no it doesnt with my thinking
[13:40:43 CEST] <JEEBsv> no, rtmp is FLV
[13:40:47 CEST] <well0ne> i know
[13:40:59 CEST] <JEEBsv> and FLV has a 1/1000 timescale (1ms)
[13:41:25 CEST] <well0ne> well i just concat the files
[13:41:31 CEST] <JEEBsv> so?
[13:41:35 CEST] <well0ne> when the first file has for example 1280x720
[13:41:41 CEST] <well0ne> and the next 7xxXxxx
[13:41:49 CEST] <well0ne> the video is streched to 1280x720
[13:42:00 CEST] <JEEBsv> yeah, but that's resolution
[13:42:02 CEST] <well0ne> because the header is not beeing regenerated
[13:42:17 CEST] <well0ne> do you think the 25fps wont fuck it up
[13:42:26 CEST] <well0ne> if the first seasons have 23.976
[13:42:32 CEST] <JEEBsv> it should be just fine
[13:42:42 CEST] <well0ne> i'm not that sure
[13:42:44 CEST] <JEEBsv> as long as the input timestamps are OK, you don't have to give a flying fuck :P
[13:42:58 CEST] <JEEBsv> the FLV muxer will just mux the input timestamps with FLV precision and that's it
[13:43:15 CEST] <well0ne> but the wowza (rtmp) will tell that the stream has 23 fps or am i wrong
[13:43:58 CEST] <JEEBsv> it doesn't matter what it tells as long as it doesn't touch the actual encapsulated FLV
[13:44:12 CEST] <well0ne> okay
[13:44:13 CEST] <JEEBsv> I'm pretty sure it doesn't
[13:44:17 CEST] <well0ne> i'll give it a try
[13:44:21 CEST] <well0ne> thank you
[13:44:47 CEST] <JEEBsv> basically the idea of a "frame rate" for a container is only a thing that is in pretty much AVI
[13:45:02 CEST] <JEEBsv> everything else has a timebase and a timestamp on that timebase
[13:45:48 CEST] <JEEBsv> FLV just happens to have a timebase of 1/1000, but that should more or less work for both 24000/1001 and 25 pictures per second content
[13:47:34 CEST] <JEEBsv> and so many streams use variable rate with FLV that if your streaming server actually borks the stream, then that's a thing worth reporting there ;)
[13:48:00 CEST] <JEEBsv> often used for stuff like static frames etc
[13:48:39 CEST] <well0ne> ok nice
[13:49:08 CEST] <JEEBsv> but most probably it isn't doing anything to the data within the stream
[13:49:23 CEST] <JEEBsv> and probably reads the frame rate from the difference of some timestamps
[13:49:33 CEST] <JEEBsv> whether or not it updates it depends on how that server is coded :)
[13:51:49 CEST] <well0ne> yeah, well i dont know exactly right now, never tested it
[13:52:00 CEST] <well0ne> but it should be FMS or Wowza
[16:15:48 CEST] <whald> hi! i'm trying to convert some videos from 8-bit 1080p to 10-bit 720p (x265), and i'd like to make sure the scaling happens in 10bpp format. i can't find the relevant info in ffmpeg's logging output. can anyone help me to get some insight what exactly ffmpeg's processing pipe looks like?
[16:17:08 CEST] <BtbN> use filter_complex and put the format conversion in front of the scale filter, if you want to be sure.
[16:17:37 CEST] <BtbN> But is there realy a point in going 10bpp for downscaling? Where should any new colors come from?
[16:18:19 CEST] <JEEBsv> I don't think you even need filter_complex for that
[16:18:24 CEST] <JEEBsv> you just put the format= first
[16:18:28 CEST] <JEEBsv> and then the scale
[16:18:31 CEST] <whald> BtbN, i assume the "averaging" can result in new color valus
[16:19:02 CEST] <JEEBsv> although if you want high-quality conversions and scaling I recommend looking at vapoursynth's fmtconv and zlib
[16:19:07 CEST] <JEEBsv> or libz or whatever it is called
[16:21:20 CEST] <whald> JEEBsv, i'm currently using: -vf "$CROP, scale='if(gt(a,16/9),1280,-16)':'if(gt(a,16/9),-16,720)'"   for the cropping / scaling part (the cropping is determined in a separate step)
[16:22:19 CEST] <whald> JEEBsv, can you point me to some documentation about the "format" thing? is it something that goes into "-vf"?
[16:24:32 CEST] <JEEBsv> format=yuv420p10 for 4:2:0 YCbCr for example
[16:25:36 CEST] <whald> also, how can i verify that ffmpeg is actually handing 10bpp buffers to x265? i feel a bit uneasy about this, because "turning on" 10bpp encodning was just a matter of renaming "libx265_main10.so" to "libx265.so" -- they both offer the same API and ABI, but how would ffmpeg know that the 10bit encoder actually consumes 10bpp buffers?
[16:26:21 CEST] <JEEBsv> just use -v debug and look at what your filter chain outputs
[16:26:29 CEST] <JEEBsv> that is what is then passed to the encoder
[16:29:09 CEST] <JEEBsv> seems like I used format=pix_fmts=NAME_OF_PIX_FMT
[16:29:19 CEST] <JEEBsv> probably format=NAME_OF_PIX_FMT could be a shorthand for it
[16:39:20 CEST] <whald> JEEBsv, thanks a bunch, that "format=yuv420p10" or "format=pix_fmts==yuv420p10" both equally seem to do the trick. without it, the last filter step is "[Parsed_scale_1 @ 0x29457c0] w:1920 h:1024 fmt:yuv420p sar:1/1 -> w:1280 h:688 fmt:yuv420p sar:129/128 flags:0x4", and when forcing the conversion earlier it's "[Parsed_scale_2 @ 0x1895e20] w:1920 h:1024 fmt:yuv420p10le sar:1/1 -> w:1280 h:688 fmt:yuv420p10le sar:129/128 flags:0x4"
[16:39:54 CEST] <JEEBsv> yeah, although if you care as much you should probably be using something else than swscale
[16:40:06 CEST] <JEEBsv> like those two vapoursynth modules I mentioned
[16:40:30 CEST] <whald> JEEBsv, oh, I missed that. i'll look it up..
[16:42:09 CEST] <JEEBsv> I wonder how hard it'd be to stick fmtconv or something into avfilter
[16:42:26 CEST] <durandal_1707> JEEBsv: what is libz?
[16:42:47 CEST] <JEEBsv> https://github.com/sekrit-twc/zimg
[16:44:00 CEST] <JEEBsv> fmtconv also has a git repository these days https://github.com/EleonoreMizo/fmtconv
[16:44:24 CEST] <JEEBsv> I have been using fmtconv myself more
[16:45:18 CEST] <JEEBsv> although I hear z has a better implementation of "reverse-scaling" (according to its creator)
[17:08:47 CEST] <whald> JEEBsv, thanks for your input, mutch appreciated. i think i'll stick with "simple" lanczos scaling and be happy with the 10bpp processing pipeline I have now. if I'd care too much about quality, I wouldn't do the conversion anyway. :-)
[17:09:24 CEST] <whald> my estimate is that this batch job will take ~2years anyway, so I better get started. :-)
[17:43:46 CEST] <livingBEEF> so I have an overlay, but some edges have weird white-ish border, which wasn't in the original. I'm using png -> scale -> overlay with video. The fully transparent parts behave correctly, but not the borders. Any idea how to fix this?
[18:01:05 CEST] <durandal_1707> livingBEEF: how to reproduce it?
[18:01:39 CEST] <livingBEEF> just found out it was scale causing the problems...
[18:02:18 CEST] <livingBEEF> scaling it beforehand solved it
[18:49:40 CEST] <livingBEEF> how do I set multiple scaler flags in -filter_complex? I tried mixture quoting with ",', separating with , : and | and nothing worked
[18:54:34 CEST] <BtbN> filter=firstParam:secondParam:thirdParam or filter=namedParam=value:otherNamedParam=otherValue
[18:55:13 CEST] <BtbN> https://ffmpeg.org/ffmpeg-filters.html#Filtergraph-syntax-1
[19:00:03 CEST] <livingBEEF> no, I'm talking about scaler flags, so it's like -filter_complex "...,[2:v]scale=-1:40:flags=(I want to specify multiple lags here)[vo]"
[19:01:46 CEST] <livingBEEF> those are not flags for the "scale" filter, those are flags for libwscale
[19:03:08 CEST] <livingBEEF> I would set them globally, but I can't, because I'm using the scale filter elsewhere and I don't want those extra flags tehre
[19:03:20 CEST] <durandal_1707> + ?
[19:03:36 CEST] <livingBEEF> can try
[19:04:21 CEST] <livingBEEF> yup, works
[19:04:23 CEST] <livingBEEF> thanks
[19:28:37 CEST] <livingBEEF> documentation is a bit lacking in this... it's not mentioned anywhere in the relevant parts; the only indication I found was some default in completely unrelated option (not even filter). Didn't find any documentation "contribute" link and I'm not sure if it's bug report worthy
[19:30:26 CEST] <durandal_1707> its documented in swscale documentation I guess
[19:32:19 CEST] <livingBEEF> it's not in the ffmpeg-scaler documentation either
[19:34:22 CEST] <durandal_1707> about flags separation? Then it must be in generic help somewhere
[19:35:22 CEST] <livingBEEF> I've been looking for it almost 20 minutes and I did not find anything
[19:36:20 CEST] <durandal_1707> than it should be added, never enough manpower...
[19:36:21 CEST] <livingBEEF> and I was even specifically looking for "+" with context search, someone who is looking for flag separator would have even harder time trying to find anything
[19:39:15 CEST] <c_14> livingBEEF: I'm pretty sure you can just specify them like -vf scale=w:h:sws_dither=dither:sws_flags=flags
[19:39:22 CEST] <c_14> At least, that's what my history is telling me.
[19:43:07 CEST] <livingBEEF> c_14: yeah, but the question was, how does "flags" look like?
[19:43:34 CEST] <livingBEEF> (with answer flag1+flag2+flag3)
[19:44:56 CEST] <c_14> mhm, right. That manpage is seriously missing some correct indentation.
[21:29:54 CEST] <DeadSix27> how do you prevent ffmpeg from creating a empty file if an error appears?
[21:30:35 CEST] <BtbN> I don't think you can.
[21:31:03 CEST] <BtbN> I rembmer reading something about that case very recently on the ml, related to the file-management api.
[21:31:32 CEST] <DeadSix27> alright
[23:46:45 CEST] <Dimtree> Stupid question, does FFMPEG support AC3 at all? If so, what's the ./configure flag?
[23:47:33 CEST] <BtbN> Not entirely sure, but isn't that dts?
[23:50:57 CEST] <Dimtree> I've seen it referred as ac3, a52, and dolby something-or-another
[23:51:58 CEST] <BtbN> The decoder is just named ac3 though
[23:52:19 CEST] <Dimtree> That's fine, I only need the decoder
[00:00:00 CEST] --- Sun Jul 12 2015