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

[burek]

[00:32:07 CEST] <kepstin> M6HZ: no, it would make it harder to use, because making a single complex filter chain which handles multiple streams is more work than doing separate simple "audio" and "video" chains that are applied to all of the relevant streams automatically.
[00:36:39 CEST] <M6HZ> kepstin: Hum, fair enough. It's just that there are at least four ways to apply filters with ffmpeg, -vf, -af, -complex_filer, -lavfi, all of these having their limitations. Trying to unify them into something more intuitive could be a nice idea.
[00:37:03 CEST] <kepstin> you only listed 3 ways, since -filter_complex and -lavfi are the same thing :)
[00:37:19 CEST] <kepstin> (there's also options that load filter chain descriptions from files)
[00:37:26 CEST] <M6HZ> Well, yes, I've read that earlier, but there are two different options.
[00:37:27 CEST] <kepstin> and the lavfi input device
[00:38:14 CEST] <M6HZ> "there's also options that load filter chain descriptions from files" What is that. Can you give me an example?
[00:41:06 CEST] <kepstin> -filter_script is the same thing as -filter (which is the long form of the -af and -vf options), except it reads the filter chain description from a file rather than from the command line.
[00:41:15 CEST] <kepstin> same for -filter_complex_script vs. -filter_complex
[00:41:43 CEST] <M6HZ> ok
[00:43:00 CEST] <furq> what limitations does filter_complex have that vf/af don't
[00:48:15 CEST] <M6HZ> kepstin: And you see there is another source of confusion "-lavfi" and "lavfi input virtual device", I had always conflated both.
[00:48:33 CEST] <M6HZ> furq: kepstin gave at least one of them earlier.
[00:49:20 CEST] <M6HZ> kepstin: It is also the case for the term "codec" in the man page, being either related to an encoder name or to a bitstream format name.
[00:49:24 CEST] <kepstin> hmm? I don't recall saying anything of the sort.
[00:49:44 CEST] <M6HZ> "[18:32] <kepstin> M6HZ: no, it would make it harder to use, because making a single complex filter chain which handles multiple streams is more work than doing separate simple "audio" and "video" chains that are applied to all of the relevant streams automatically."
[00:49:56 CEST] <kepstin> i said that -af/-vf are often easier to use, but that's not really a "limitation"
[00:50:21 CEST] <M6HZ> Alright the word is maybe too strong.
[07:40:52 CEST] <koz_> I'm using (successfully) ffmpeg with Intel's VA-API HEVC encoder. If I wanna do a lot of files (say, 12), does it make sense for me to use something like GNU Parallel to execute ffmpeg in parallel on each one, or will that not really help?
[07:41:14 CEST] <koz_> I assume it won't, because I have only one DRI device, and I guess that all that parallel-hammering won't play very nicely with it.
[07:52:58 CEST] <TikityTik> koz_: there's a -threads option and a -cpu option
[07:53:17 CEST] <koz_> TikityTik: I understand that. I'm asking more about processing multiple files, not one file faster.
[07:53:41 CEST] <koz_> Because I'm not sure that I can hardware encode 12 things in parallel, even though my CPU has 12 hyperthreads.
[07:54:05 CEST] <koz_> I've done some tests, the results are inconclusive, and I'd like to hear from someone who can give me a definitive answer on whether that's a) even possible and b) worthwhile.
[07:54:18 CEST] <koz_> I can give the exact ffmpeg invocations I'm feeding to GNU parallel if that'd help.
[07:57:05 CEST] <furq> i don't think it'll make any difference
[07:57:28 CEST] <koz_> furq: So what you're saying is 'don't bother using GNU parallel,just process the files in sequence'?
[07:57:32 CEST] <furq> yeah
[07:57:49 CEST] <koz_> furq: Could you explain your reasoning for that? Not disagreeing, but just curious why.
[07:57:59 CEST] <koz_> Is it because the hardware can only encode one file at a time anyway?
[08:00:23 CEST] <furq> each encode will slow down pretty much in line with however many streams you're running
[08:00:31 CEST] <koz_> Ah, I see.
[08:00:33 CEST] <furq> plus i assume you lose some more in overhead
[08:00:40 CEST] <koz_> Yeah, I'm _definitely_ noticing that.
[08:00:43 CEST] <furq> although you'd gain a tiny bit from running the decoder closer to capacity
[08:01:09 CEST] <koz_> On just FPS alone, 1 proc = 60fps, 2 procs = 48fps, but 4 already kick me to like, 27.
[08:02:26 CEST] <furq> that sounds better than i thought
[08:02:56 CEST] <furq> unless you mean 27fps in total
[08:06:57 CEST] <koz_> This is per ffmpeg process.
[08:14:01 CEST] <koz_> furq: So I guess either I do it entirely serially, or at most 2 processes at a time?
[09:29:23 CEST] <vishnuyr> Hi
[09:29:57 CEST] <vishnuyr> I need help with encoding of DVCPro HD to XDCAM HD 422.
[09:30:21 CEST] <vishnuyr> has anyone tried it?
[09:37:25 CEST] <KaitoDaumoto> idk
[09:37:25 CEST] <KaitoDaumoto> :(
[10:47:21 CEST] <Hypnotoad90_> hey, is it possible to request a specific frame size AVCodecContext?
[10:48:33 CEST] <Hypnotoad90_> or from the codec
[10:48:37 CEST] <Hypnotoad90_> by frame size i mean a specific nb_samples
[10:50:09 CEST] <Hypnotoad90_> alternatively, is it possible to have swr_convert write to your sample buffers with a sample offset, rather than having it write from the beginning of the buffer?
[13:01:51 CEST] <Hypnotoad90> not sure how to phrase that question properly
[13:46:04 CEST] <Hypnotoad90> or am i only supposed to be writing to new buffers each frame?
[13:49:45 CEST] <JEEB> Hypnotoad90: you're talking about audio, so I know the libavfilter interfaces which behind the scenes utilize swresample has a function to request XYZ samples
[13:49:53 CEST] <JEEB> not sure if swresample itself has that
[13:50:08 CEST] <Hypnotoad90> hmm cool
[13:50:48 CEST] <Hypnotoad90> if i just want to decode and resample an audio stream, libavfilter is a suitable thing to use?
[13:51:26 CEST] <JEEB> yes, it basically wraps around swresample so it's less nitty gritty and more "feed me AVFrames and you get AVFrames back"
[13:51:42 CEST] <JEEB> although I thought swresample also has an AVFrame based API, but I'm now having trouble noticing it :P
[13:51:55 CEST] <Hypnotoad90> sounds great, and i can use it without it actually 'filtering' the audio?
[13:52:14 CEST] <JEEB> well you define the filter chain
[13:52:18 CEST] <JEEB> that can just be "aresample"
[13:52:27 CEST] <JEEB> input -> aresample -> output
[13:52:38 CEST] <Hypnotoad90> aresample is like swrseample?
[13:52:47 CEST] <JEEB> it's the filter that wraps swresample, yes
[13:52:58 CEST] <Hypnotoad90> awesome, i'll def look into that in a bit
[13:53:06 CEST] <Hypnotoad90> is there some good example code showing its usage?
[13:53:25 CEST] <JEEB> doc/examples has an example of using the "just give it a string" interface
[13:53:44 CEST] <JEEB> which builds a filter chain from a string you pass libavfilter
[13:54:20 CEST] <Hypnotoad90> oh btw forgot to mention, i'm forced to use a specific version of ffmpeg, i think it might be 2.4.1 or something, if that matters
[13:54:28 CEST] <JEEB> yes it does
[13:54:39 CEST] <JEEB> you're very unfortunate in various ways :P
[13:54:44 CEST] <Hypnotoad90> yup :(
[13:55:30 CEST] <JEEB> that's old enough for many things to have changed or gotten fixed since
[13:55:53 CEST] <JEEB> ok, and I found the AVFrame based API in swresample for the record. it's indeed documented in swresample.h as I remembered :P
[13:59:08 CEST] <Hypnotoad90> ah i see there's swr_convert_frame
[13:59:48 CEST] <JEEB> and swr_config_frame for reconfiguration in case of changes
[14:00:03 CEST] <Hypnotoad90> JEEB, actually can i explain my overall situation:
[14:00:10 CEST] <Hypnotoad90> basically im dealing with an old code base
[14:00:25 CEST] <Hypnotoad90> the old code base will call a function with a char* buffer
[14:00:34 CEST] <Hypnotoad90> of a given size
[14:00:46 CEST] <Hypnotoad90> basically this codebase has its own 'frame' concept distinct from ffmpeg's
[14:00:53 CEST] <Hypnotoad90> so the char it sends is the buffer size for the whole frame
[14:01:20 CEST] <Hypnotoad90> and i basically need to get audio out of ffmpeg and pack it into this data
[14:02:23 CEST] <Hypnotoad90> now if i could get codec ffmpeg uses to have the same frame size as this function requests, that would be perfect, as it would all match up and i could just use swr_convert to write to the frame directly
[14:02:38 CEST] <Hypnotoad90> write to the char*
[14:02:51 CEST] <Hypnotoad90> i dunno if any of that made sense
[14:03:04 CEST] <JEEB> given that FFmpeg itself has alignment requirements I'm not sure if you can just feed the buffer as-is to  FFmpeg's APIs
[14:03:18 CEST] <JEEB> but you can indeed with various APIs request XYZ samples
[14:03:37 CEST] <JEEB> including that AVFrame API and probably the non-AVFrame one too :P
[14:03:47 CEST] <Hypnotoad90> well this codebase has functions to prepare the sample format etc..
[14:04:12 CEST] <JEEB> so then all you need to do is transfer those samples from f.ex. the received AVFrame to your buffer
[14:04:21 CEST] <JEEB> which should in general be one or multiple memcpys
[14:04:24 CEST] <Hypnotoad90> but anyway, suppose i wanted to request an arbitrary number of samples from an arbitrary sample offset, would that be possible?
[14:04:38 CEST] <JEEB> why do you need the offset?
[14:04:44 CEST] <JEEB> you want to skip samples?
[14:04:54 CEST] <Hypnotoad90> well so the codebase will request a frame as well
[14:04:57 CEST] <JEEB> or do you mean "don't start at the beginning of the output buffer"?
[14:05:01 CEST] <Hypnotoad90> so it might call the function and ask for audio at frame 30
[14:05:15 CEST] <Hypnotoad90> and say frame 30 is 5000 samples in
[14:05:23 CEST] <Hypnotoad90> so i need to get data from the audio stream 5000 samples in
[14:05:36 CEST] <Hypnotoad90> and lets say the frame size its requesting is 1000
[14:05:49 CEST] <Hypnotoad90> so i need to get 1000 samples of audio data beginning at sample 5000 from the stream, if that makes sense
[14:06:30 CEST] <Hypnotoad90> i know i can use av_seek_frame or something like that to find the frame that contains the sample number
[14:06:54 CEST] <JEEB> that's a container level seek to a position
[14:07:02 CEST] <JEEB> time-wise position
[14:07:05 CEST] <JEEB> not in samples
[14:07:08 CEST] <Hypnotoad90> right
[14:07:18 CEST] <Hypnotoad90> but i believe it was possible to calculate the right time position from samples
[14:07:23 CEST] <JEEB> (you can also seek in bytes)
[14:07:25 CEST] <Hypnotoad90> using AV_TIME_BASE or something
[14:07:33 CEST] <Hypnotoad90> oh that might be easier
[14:07:35 CEST] <JEEB> yes, if your definition is number of samples in the input format
[14:07:54 CEST] <JEEB> as opposed to number of samples after whatever conversion you need to do with resampling
[14:07:57 CEST] <JEEB> :P
[14:08:23 CEST] <Hypnotoad90> anyway getting precisely the right frame is secondary atm, the main thing is being able to read an arbitrary number of samples
[14:09:15 CEST] <JEEB> well at least the AVFrame API for swresample and the libavfilter stuff lets you basically request X amount of samples
[14:09:30 CEST] <JEEB> as swr_convert_frame f.ex. notes
[14:09:36 CEST] <Hypnotoad90> theres the decoder i need to deal with too
[14:09:46 CEST] <JEEB> well yes, but decoder will just churn AVFrames for you
[14:10:00 CEST] <JEEB> what you are interested in is that you get the output in XYZ sample chunks
[14:10:09 CEST] <JEEB> which is what these APIs will give you
[14:10:16 CEST] <Hypnotoad90> not sure what you mean by XYZ exactly
[14:10:28 CEST] <JEEB> some arbitrary number of samples
[14:10:43 CEST] <JEEB> see the sentence starting with "The output AVFrame can be NULL or have fewer allocated samples than required."
[14:10:46 CEST] <JEEB> in swresample.h
[14:11:01 CEST] <Hypnotoad90> right, but the decoder still forces a specific nb_samples size it seems
[14:11:08 CEST] <JEEB> of course it does
[14:11:16 CEST] <JEEB> it just outputs decoded AVFrames as-is
[14:12:05 CEST] <JEEB> and read that explanation to the start of which I pointed please, that will probably clear some doubts on your side :P
[14:12:33 CEST] <Hypnotoad90> which explanation sorry?
[14:12:48 CEST] <JEEB> fourth line before the "and read that explanation..."
[14:12:56 CEST] <JEEB> referencing to swresample.h
[14:14:35 CEST] <Hypnotoad90> okay so
[14:16:04 CEST] <Hypnotoad90> so i can see that could be used if my frame is smaller than the one the codec produces, but lets say my frame is the size of 3 frames the codec churns out, i guess i want swr to read to the same frame 3 times with those 3 input frames?
[14:16:06 CEST] <Hypnotoad90> if possible?
[14:16:09 CEST] <Hypnotoad90> write to*
[14:17:31 CEST] <Hypnotoad90> or otherwise i need to just write 3 frames and pack them all into the char* somehow
[14:17:54 CEST] <JEEB> I would think that at least some API will just outright tell you that the internal buffer doesn't yet have enough data
[14:17:59 CEST] <JEEB> if you request a larger frame size
[14:18:33 CEST] <JEEB> although I have not touched swresample and most of my experience has been writing relatively simple stuff with libavfilter in the audio department
[14:19:38 CEST] <Hypnotoad90> okay so i think it sounds like i'll have multiple frames to deal with and i need to write them all into a single char* buffer, im not sure how id do that
[14:19:54 CEST] <JEEB> ? I don't think that's what I said
[14:20:09 CEST] <Hypnotoad90> i cant see what else i could do reading the doc
[14:20:26 CEST] <JEEB> I would rather have f.ex. avfilter handle the buffering (or swresample if it indeed tells you that if you try to request more samples from it than it has in buffer)
[14:21:17 CEST] <JEEB> you can relatively easily test what the thing tells you if you request more samples than you have fed it :P
[14:21:45 CEST] <JEEB> and if that's not possible, you can always copy the buffer and offset the pointer to your output buffer :P
[14:21:46 CEST] <Hypnotoad90> but i'll already know in advance if im requesting more samples than available, not entirely sure why its useful if swresample tells me or not
[14:21:58 CEST] <JEEB> because tehn you can just keep feeding more data in?
[14:22:09 CEST] <Hypnotoad90> right, as in additional frames?
[14:22:11 CEST] <JEEB> it should then buffer internally until it has a full frame's amount of stuff
[14:22:20 CEST] <Hypnotoad90> thats why im saying i'd end up with multiple frames
[14:22:28 CEST] <JEEB> on the input side?
[14:22:29 CEST] <JEEB> yes
[14:22:32 CEST] <JEEB> on the output side? why
[14:22:39 CEST] <Hypnotoad90> are you saying i can write multiple times to the same frame?
[14:22:44 CEST] <JEEB> no?
[14:23:06 CEST] <Hypnotoad90> so how am i supposed to use multiple input frames for one output frame?
[14:23:08 CEST] <JEEB> I'm saying taht you request XYZ samples out of the resampler it should hopefully either tell you it has no such amount of samples yet, or it will be dumb and give what it has
[14:23:47 CEST] <JEEB> Hypnotoad90: it references an internal buffer so you can easily test which the swresample lib does if you ask for more than it's got :P
[14:23:55 CEST] <JEEB> since it does have internal buffering as per the doc
[14:24:03 CEST] <Hypnotoad90> i get that, but i dont know what im supposed to do with that info
[14:24:16 CEST] <JEEB> "I ate your input frame, feed more"
[14:24:19 CEST] <JEEB> is what that means
[14:24:29 CEST] <JEEB> *feed more if you want output
[14:24:41 CEST] <Hypnotoad90> oh so you mean it wont write to the output frame right away until enough input has been added?
[14:24:58 CEST] <JEEB> yes, that is what I'm hoping for since it has the same thing for asking for less samples than it has in buffer
[14:25:03 CEST] <Hypnotoad90> like the "gotframe" thing from the decoder?
[14:25:04 CEST] <JEEB> which is why I said "just try it out"
[14:25:16 CEST] <JEEB> Hypnotoad90: oh boy, those old APIs
[14:25:21 CEST] <JEEB> nowadays we have separate feed/receive
[14:25:23 CEST] <JEEB> functions :P
[14:25:31 CEST] <JEEB> which both report "cannot do that yet"
[14:25:42 CEST] <JEEB> if the internal state isn't ready for your request yet
[14:25:43 CEST] <JEEB> :P
[14:25:54 CEST] <Hypnotoad90> swr_convet_frame, doc says: Returns
[14:25:54 CEST] <Hypnotoad90>     0 on success, AVERROR on failure or nonmatching configuration.
[14:26:25 CEST] <Hypnotoad90> doesnt look like it returns info about needing more data
[14:26:26 CEST] <JEEB> yup, so it will probably return an AVERROR
[14:26:29 CEST] <Hypnotoad90> oh?
[14:26:35 CEST] <Hypnotoad90> hmm
[14:26:36 CEST] <JEEB> or I would guess so
[14:26:41 CEST] <JEEB> test it and it'll be quick
[14:26:43 CEST] <JEEB> then we'll know :P
[14:26:53 CEST] <Hypnotoad90> i'll test in a bit
[14:26:55 CEST] <JEEB> just like it returns AVERROR_{OUTPUT,INPUT}_CHANGED
[14:27:01 CEST] <JEEB> if the input or output config changed
[14:27:02 CEST] <JEEB> :P
[14:27:12 CEST] <JEEB> (and thus a reconfig is needed)
[14:27:56 CEST] <Hypnotoad90> alternatively, in case this doesn't work out, before i was writing directly to the buffer with: av_samples_alloc((uint8_t**) &buffer, NULL, numchans, MAX_AUDIO_FRAME_SIZE, sample_fmt, 0);
[14:28:39 CEST] <Hypnotoad90> is there someway i can offset the buffer pointer so it fills say the end half of the buffer
[14:28:58 CEST] <Hypnotoad90> i couldnt quite figure it out how to do it properly, i was constantly getting bad access errors
[14:29:03 CEST] <Hypnotoad90> if it's even possible
[17:46:39 CEST] <Hypnotoad90> alright lets give this a shot
[17:57:07 CEST] <Hypnotoad90> noooo
[17:57:19 CEST] <Hypnotoad90> JEEB, looks like swr_convert_frame isn't available in my version of ffmpeg :(
[18:36:43 CEST] <JEEB> Hypnotoad90: too bad
[18:36:59 CEST] <JEEB> although I think you could request for XYZ samples in teh buffer based API too?
[18:44:54 CEST] <Hypnotoad90> JEEB, right but how?
[18:46:15 CEST] <Hypnotoad90> oh i pasted the wrong function before
[18:47:11 CEST] <Hypnotoad90> i do the conversion atm with: swr_convert(swr, (uint8_t**)&buffer, frame->nb_samples, (const uint8_t**)frame->data, frame->nb_samples);
[18:47:54 CEST] <Hypnotoad90> id like at least for now to be able to call that swr_convert function multiple times on the same buffer, i.e. writing several frames to one buffer, im assuming i can do that by offsetting the pointer to buffer somehow but not sure how
[00:00:00 CEST] --- Tue Apr 23 2019