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

[burek]

[00:01:00 CET] <ElePHPhant> All of those steps are a mystery to me. :/
[00:02:00 CET] <faLUCE> what I don't understand is that if I exec "ffmpeg -f v4l2 -i /dev/v4l/by-id/usb-046d_0825_9C957210-video-index0 -c:v libx264 -f mpegts test.ts"   the bytes at the beginning of the produced file are "ffmpeg service". Is this a sorft of "ffmpeg header" or a part of another header?
[00:02:32 CET] <JEEB> latter
[00:03:10 CET] <JEEB> by default in the MPEG-TS metadata the program is called Service01 and the provider name is FFmpeg
[00:03:23 CET] <faLUCE> JEEB: so, it's a part of the MPEGTS header...
[00:03:45 CET] <faLUCE> JEEB: is this a "global" header?
[00:04:00 CET] <faLUCE> WIth global I mean a header that has to be put on each frame
[00:04:16 CET] <JEEB> I thought that meant the other way?
[00:04:28 CET] <JEEB> global headers were only written once and non-global were in-band?
[00:04:45 CET] <JEEB> anyways, it should be written every now and then again
[00:04:53 CET] <JEEB> as it's part of PMT I think
[00:04:55 CET] <JEEB> or PAT
[00:05:03 CET] <faLUCE> JEEB: me too. But IIRC avcodeccontext->flags |= GLOBAL_HEADER means a header on each frame
[00:06:11 CET] <JEEB> libavcodec/avcodec.h- * Place global headers in extradata instead of every keyframe.
[00:06:14 CET] <JEEB> libavcodec/avcodec.h- */
[00:06:16 CET] <JEEB> libavcodec/avcodec.h:#define AV_CODEC_FLAG_GLOBAL_HEADER   (1 << 22)
[00:06:22 CET] <JEEB> so yes, it means what I thought it did
[00:06:39 CET] <JEEB> and then AVFormat has its own field for that since you should set that field according to your muxer
[00:06:58 CET] <JEEB> see the transcoding example
[00:07:05 CET] <JEEB> it checks if the oformat has that flag
[00:07:12 CET] <JEEB> and if yes, sets that flag for the enc_ctx
[00:07:22 CET] <faLUCE> JEEB: but it says "on every keyframe", not "once"
[00:07:41 CET] <JEEB> Extradata instead of every keyframe
[00:07:49 CET] <JEEB> extradata is avctx global field
[00:08:10 CET] <faLUCE> I see but, in each case, it's not a header that must be written once at beginning of the stream
[00:08:10 CET] <JEEB> what it means is that you should only get a single set of extradata, and that is in the avctx's extradata :P
[00:08:36 CET] <faLUCE> for example, mkv needs a header that must be put at the beginning of the stream
[00:08:58 CET] <JEEB> does matroska have AVFMT_GLOBALHEADER ?
[00:09:15 CET] <faLUCE> JEEB: it needs it, yes
[00:09:18 CET] <faLUCE> it's necessary
[00:09:26 CET] <JEEB> yes, and you already got me fucking confused
[00:09:36 CET] <faLUCE> but other than that, it also needs a header at the beginning of the stream
[00:09:40 CET] <JEEB> I already said it meant "put into a global header" (extradata)
[00:09:46 CET] <JEEB> what do you mean with that?
[00:10:01 CET] <JEEB> matroska definitely does not need in-band headers
[00:10:05 CET] <JEEB> of H.264 or so
[00:10:13 CET] <JEEB> you can put them there if you really really want
[00:10:17 CET] <JEEB> but they are not required to be there
[00:10:44 CET] <faLUCE> I mean:  maybe (but I could be wrong) mkv needs a header at the beginning of the stream, which is different than the header on the keyframes
[00:11:18 CET] <JEEB> if you're talking about the matroska container then yes, it has different stream-specific structures yes. but it has nothing to do with decoding init data in extradata and the stream-global header
[00:11:58 CET] <JEEB> global header = extradata should be put into encoder's extradata field and it will get written into a place in the container (usually a structure per stream)
[00:12:01 CET] <faLUCE> ok, that is what I was saying. There is a "global-global header" (at the beginning of the stream) and a "global header" on each keyframe
[00:12:11 CET] <JEEB> that is fucking completely different semantics
[00:12:49 CET] <JEEB> I was talking about the lavf/lavc flag which I thought you were talking about
[00:13:02 CET] <JEEB> if you want to talk about container structure's that separate
[00:13:12 CET] <JEEB> please tell so if you're going to switch the talk
[00:13:26 CET] <JEEB> that just confuses the fuck of me because you're using the same "global header" terminology
[00:13:50 CET] <faLUCE> JEEB: as said before, I don't know how to call this header
[00:14:11 CET] <faLUCE> libavformat calls it "header"
[00:14:42 CET] <faLUCE> anyway, what I want to understand is:
[00:14:57 CET] <faLUCE> 1) does MPEGTS need this "container header" ?
[00:15:10 CET] <faLUCE> 2) doese MPEGTS need GLOBAL header?
[00:15:21 CET] <JEEB> ok, now you're using the word global header agian
[00:15:28 CET] <JEEB> please tell me what the meaning of that for you is
[00:15:58 CET] <faLUCE> Global header = header at the beginning of each encoded keyframe
[00:16:14 CET] <JEEB> ok, so different to lavf/lavc flag
[00:16:15 CET] <JEEB> got it
[00:16:23 CET] <JEEB> although that doesn't make any sense
[00:16:30 CET] <JEEB> anyways, mpeg-ts is simple
[00:16:41 CET] <JEEB> it has no real concept of headers or footers
[00:16:52 CET] <JEEB> a parser will start reading MPEG-TS packets (188 bytes)
[00:16:59 CET] <JEEB> it will keep reading until it gets PAT
[00:17:10 CET] <faLUCE> so, it doesn't need a container header, although some strange players want it (IIRC)
[00:17:18 CET] <JEEB> wait until I finish
[00:17:32 CET] <JEEB> PAT is a packet that tells it "this stream has these programs in it" (think of "program" as in a channel on TV)
[00:17:42 CET] <faLUCE> I remember that, just want a confirmation
[00:18:08 CET] <JEEB> then it gets PMT, and that is the mapping of streams within programs
[00:18:13 CET] <JEEB> after that it can start reading
[00:18:39 CET] <faLUCE> but I also remember that some weird players wanted a header also for the container, at the beginning of the stream. But I could be wrong
[00:18:41 CET] <JEEB> most likely FFmpeg's MPEG-TS muxer puts PAT+PMT at each keyframe, or possibly more often. not sure what the spec was. every 0.5s?
[00:18:53 CET] <JEEB> there's no header. you just need to have PAT+PMT
[00:19:01 CET] <JEEB> I know some stupid stream dumpers cut out PAT+PMT
[00:20:12 CET] <JEEB> so in FFmpeg terms, MPEG-TS is not a format with the global header flag. because you put the decoding initialization packets in-band, into the stream. into your AVPackets
[00:20:38 CET] <faLUCE> then, calling av_write_header() for MPEGTS is needed only for internal stuff, but not for writing a header on the container, right?
[00:21:02 CET] <faLUCE> or it is not needed  at all?
[00:22:51 CET] <JEEB> you should still call it because the framework expects it, but there is no write_header function in the mpegts muxer :P
[00:23:36 CET] <faLUCE> JEEB: in fact I said "for internal stuff".... maybe it allocates stuff needed for the stream?
[00:23:54 CET] <JEEB> that probably happens in init
[00:24:07 CET] <JEEB> because you are supposed to not add streams after you call init()
[00:24:18 CET] <JEEB> but anyways, yes
[00:24:22 CET] <JEEB> internally it's part of the flow
[00:24:29 CET] <JEEB> in the worst case it just does nothing :P
[00:24:37 CET] <JEEB> because the muxer doesn't have such a function
[00:25:08 CET] <JEEB> although mpegtsenc does have a write_trailer, which is peculiar
[00:25:26 CET] <JEEB> oh, that just flushes :P
[00:25:37 CET] <faLUCE> so I can call it safely
[00:25:57 CET] <faLUCE> (this is very confusing anyway)
[00:26:05 CET] <JEEB> well it's part of the flow so you should be calling it at the end anyways :P
[00:26:10 CET] <JEEB> it's part of the framework flow
[00:26:23 CET] <JEEB> different containers do different things in different parts of it
[00:26:31 CET] <JEEB> some might just not have some steps
[00:26:35 CET] <faLUCE> ok. In case of matroska, it writes the container's header too
[00:26:59 CET] <JEEB> yes, that's 100% up to the muxer what it does
[00:27:10 CET] <JEEB> and if you're trying to expect something from those then just please don't
[00:29:18 CET] <faLUCE> now, if  I mux h264 with matroska, this means that I CAN put the GLOBAL_HEADER flag on the muxer's avcodeccontext if I don't put it on the encoder's avcodeccontext, right?
[00:29:33 CET] <faLUCE> sorry:
[00:29:42 CET] <faLUCE> now, if  I mux h264 with matroska, this means that I NEED TO put the GLOBAL_HEADER flag on the muxer's avcodeccontext if I don't put it on the encoder's avcodeccontext, right?
[00:30:24 CET] <faLUCE> so the muxer can add the extradata to the packets incoming to av_write_frame
[00:31:55 CET] <JEEB> not muxer
[00:32:03 CET] <JEEB> you are getting the flag from the muxer and setting the flag accordingly in encoder
[00:32:45 CET] <JEEB> if you are not encoding in lavc then you have to make sure that your headers are in the extradata field of the avcodecparameters of the AVStream
[00:32:57 CET] <JEEB> as in, the stream extradata
[00:33:05 CET] <faLUCE> are you sure? if for example with the same encoder I want to feed a mpegts muxer and mkv muxer?
[00:33:26 CET] <faLUCE> mpegts doesn't want global header, but mkv does
[00:33:54 CET] <JEEB> not sure if matroskaenc.c takes in Annex B
[00:34:03 CET] <JEEB> if it does and auto-converts then it's kind "OK"
[00:34:10 CET] <JEEB> (it's not, but you get away with it)
[00:34:35 CET] <JEEB> another alternative is to have a bit stream filter where needed
[00:34:40 CET] <JEEB> so you get AVCc for matroskaenc
[00:34:47 CET] <JEEB> and Annex B for mpegtsenc
[00:35:18 CET] <JEEB> although I think in some cases nowadays bit stream filters get auto-inserted in some cases
[00:36:21 CET] <JEEB> yea, I think *_mp4toannexb gets inserted automagically nowadays in various cases
[00:36:23 CET] <faLUCE> JEEB: I could set globalheaderextradata and extradata_size to 0 for mpegts, or is it unsafe?
[00:36:38 CET] <faLUCE> sorry:
[00:36:58 CET] <faLUCE> JEEB: I could set globalheader  for the eancoder +   extradata and extradata_size to 0 for mpegts, or is it unsafe?
[00:38:24 CET] <JEEB> faLUCE: libavformat/mpegtsenc.c auto-inserts to annex b bit stream filter, so I think you should be OK with global header if one of your formats requires global header, and the other is mpegts
[00:38:33 CET] <JEEB> with H.264 and HEVC at least
[00:39:30 CET] <faLUCE> JEEB: but AVPacket has "side_data" field
[00:39:38 CET] <JEEB> side data is different
[00:39:42 CET] <faLUCE> I see
[00:39:47 CET] <JEEB> side data is additional metadata etc
[00:39:55 CET] <faLUCE> then, extra_data is computed by the codecpar
[00:40:46 CET] <JEEB> well if you are encoding with lavc it should be easy :P
[00:40:57 CET] <JEEB> since you have the to and from params functions
[00:41:11 CET] <JEEB> and in this case you want from your AVCodecContext to the AVstream's AVCodecParameters
[00:42:25 CET] <faLUCE> JEEB: I know, but you think it's not necessary to "reset" the extradata and extradata_size params for the mpegts muxer, after copying avcodec params?
[00:42:42 CET] <JEEB> I'm not sure if mpegtsenc cares
[00:44:02 CET] <JEEB> also remember, mpegtsenc auto-inserts the bit stream filter
[00:44:08 CET] <JEEB> although I'm not sure if that touches extradata
[00:44:20 CET] <faLUCE> from what I see mpegtsenc.c uses codec->extradata for AAC and H264
[00:44:28 CET] <JEEB> I see that mpegtsenc has an Annex B check for extradata
[00:44:47 CET] <JEEB> but the question is, since you get the mp4 to annex-b bit stream filter applied
[00:44:52 CET] <JEEB> does that touch your extradata, too
[00:45:48 CET] <faLUCE> this "extradata" field is used for different things
[00:46:13 CET] <JEEB> h264_extradata_to_annexb
[00:46:39 CET] <JEEB> extradata in general is supposed to be the initialization data for a codec, and in cases where such a thing doesn't exist it covers other internal usages
[00:47:06 CET] <JEEB> and what I wanted to say, the bit stream filter does touch your extradata
[00:47:13 CET] <JEEB> it will convert it to annex b
[00:47:29 CET] <JEEB> so no, you don't have to clear it yourself
[00:47:38 CET] <faLUCE> JEEB: I see
[00:48:24 CET] <JEEB> at least looking at the fact that there's h264_extradata_to_annexb in the h264_mp4toannexb bsf
[00:48:26 CET] <faLUCE> but if I set GLOBAL_HEADER for h264, does it touch extradata for annex_b ?
[00:48:33 CET] <JEEB> ?!
[00:48:38 CET] <faLUCE> I mean:
[00:48:52 CET] <faLUCE> when I set GLOBAL_HEADER,  I see that extradata becomes not null
[00:49:17 CET] <JEEB> yes, libx264 writes the parameter sets to extradata in your AVCodecContext
[00:49:25 CET] <JEEB> I think it writes AVCc extradata there
[00:50:10 CET] <faLUCE> ok, now, given that x264 needs other extradata, I could  "corrupt" the extradata content if I write GLOBALHEADER on it
[00:50:16 CET] <faLUCE> ?
[00:50:23 CET] <JEEB> wat
[00:50:42 CET] <faLUCE> I mean:
[00:52:11 CET] <faLUCE> [00:47] <JEEB> and what I wanted to say, the bit stream filter does touch your extradata  <--- is it supposed to touch an extradata set by the encoder, or the extradata set with GLOBAL_HEADER?
[00:52:38 CET] <JEEB> what do you mean with the latter part?
[00:53:17 CET] <faLUCE> I mean that setting GLOBAL_HEADER affects "extradata".  But when the encoder inits, extradata is affected as well for other things, right?
[00:53:30 CET] <JEEB> ?!
[00:53:41 CET] <JEEB> also what is supposed to be touching extradata?
[00:54:12 CET] <faLUCE> avcodeccontext->flags |= AV_GLOBAL_HEADER  <----- this touches extradata
[00:55:26 CET] <faLUCE> shortly, I don't understand if I can set safely AV_GLOBAL_HEADER on the h264 encoder's context, for mpegts
[00:56:00 CET] <faLUCE> given that it affects extradata, and extradata is then touched by mpegts for other reasons
[00:56:52 CET] <JEEB> ok, let's go step by step
[00:58:15 CET] <faLUCE> ok
[00:58:29 CET] <JEEB> 1) setting AV_CODEC_FLAG_GLOBAL_HEADER to an encoder AVCodecContext tells the encoder that if it cares about that flag, that it should write the decoder initialization data into its extradata field (AVCodecContext)
[00:58:46 CET] <JEEB> that is why the extradata starts existing for libx264 for example
[00:59:09 CET] <JEEB> libx264 being one of the encoder wrappers that care about this flag
[00:59:22 CET] <faLUCE> ok
[01:00:39 CET] <JEEB> 2) Yes, you should be OK to set that flag safely for libx264 if you know all of your muxers will work with it. MPEG-TS should work because it auto-inserts a bit stream filter.
[01:01:36 CET] <faLUCE> JEEB: this is the point. It checks specific bit(s), not the complete extradat
[01:01:39 CET] <faLUCE> a content
[01:01:40 CET] <JEEB> 2.1) the bit stream filter does not touch the encoder AVCodecContext.extradata as it is called by the muxer, it only touches the AVStream's
[01:01:55 CET] <JEEB> faLUCE: yes, it checks it for the Annex B start code
[01:02:13 CET] <JEEB> if it has Annex B start codes no bit stream filter and you should be OK
[01:02:21 CET] <JEEB> if it has no, it will auto-insert the bsf
[01:02:35 CET] <JEEB> at least that is how it looks to me looking at mpegts.c
[01:02:38 CET] <JEEB> *mpegtsenc.c
[01:02:48 CET] <faLUCE> ok, thanks, then it won't care about the  AV_CODEC_FLAG_GLOBAL_HEADER bit in extradata
[01:02:53 CET] <JEEB> ?!
[01:02:59 CET] <JEEB> the flag will not be in extradata
[01:03:26 CET] <JEEB> AVCodecContext.extradata is a buffer of data
[01:03:32 CET] <JEEB> AVCodecContext.flags is separate
[01:03:44 CET] <JEEB> I probably got those wrong but you understand me :P
[01:03:50 CET] <JEEB> *what I mean
[01:04:55 CET] <faLUCE> I understand, the result is that in extradata the avcodeccontext puts different things
[01:05:12 CET] <faLUCE> as a buffer
[01:05:13 CET] <JEEB> depends on the encoder, and you are specifically requesting it with the flag
[01:05:22 CET] <JEEB> because your output format requested it
[01:05:27 CET] <JEEB> I don't see what hte problem is
[01:05:41 CET] <JEEB> anyways, I give up now. I need sleep.
[01:05:45 CET] <faLUCE> I thought that extradata was not a buffer
[01:05:51 CET] <faLUCE> but a "all in one field"
[01:05:56 CET] <faLUCE> ok, many thanks
[01:27:29 CET] <bintran2812> I have a problem with muxing HLS segments manually using ffmpeg
[01:27:54 CET] <bintran2812> detail description is here: https://pastebin.com/F0eedCbu
[01:28:23 CET] <bintran2812> I think I need to specify more information from m3u8 file in ffmpeg command
[01:29:30 CET] <net|> is there a flag to write ffmpeg in playable chunks for live streaming that overwrite themselfs ?
[01:29:53 CET] <net|> do i need webm chunks for that or is there a filesize limit flag
[01:31:53 CET] <DHE> the hls muxer should take care of everything. normally the sequence counts up forever. just use the delete_segments flag so it cleans up after itself.
[01:32:22 CET] <DHE> oh these aren't related I assume...
[01:32:36 CET] <bintran2812> yeah
[01:33:20 CET] <bintran2812> I mean in case I do it manually, like if I have video_segment.mp4 and audio_segment.mp4
[01:33:20 CET] <DHE> don't mind me...
[01:34:06 CET] <bintran2812> I cannot mux them manually with ffmpeg -i video_segment.mp4 -i audio_segment.mp4 ....
[01:34:44 CET] <bintran2812> Don't know if there is a special flag that can mimic what HLS muxer doing
[02:01:24 CET] <bintran2812> actually it should be how hls demuxer work
[02:16:13 CET] <net|> is there a way to stop recording video when it hits 1M filesize ?
[02:16:45 CET] <net|> i had a look at the man pages and found max_size and chunk_size but neither worked
[02:22:47 CET] <another> -fs 1M
[02:24:35 CET] <KombuchaKip> Why does the ffmpeg write it's own ./configure manually instead of using the autotools? Isn't it more work to reinvent its functionality?
[02:32:11 CET] <iive> KombuchaKip, quite the opposite
[02:32:39 CET] <KombuchaKip> iive: Care to elaborate?
[02:34:29 CET] <net|> thank you
[02:36:33 CET] <iive> KombuchaKip, autotools is language on its own. ffmpeg configure is written entirely on bash script.
[02:37:28 CET] <KombuchaKip> iive: Yes, I'm aware of that. But autoconf generates a POSIX shell script that is more portable than bash and with much less work. So the question still is why?
[02:37:40 CET] <KombuchaKip> iive: I'm not questioning their reasoning, I just would like to know it.
[02:37:57 CET] <KombuchaKip> iive: They'd obviously have had to have had a good reason to do what they did.
[02:39:16 CET] <iive> it takes quite an effort to make autotools do what you want. you can use some pre-existing things, but trying anything custom and you start fighting it.
[02:39:31 CET] <KombuchaKip> iive: Isn't that what M4 macros are for?
[02:39:54 CET] <iive> m4 are the pre-existing stuff.
[02:40:40 CET] <iive> writing your own configure is simpler. and you don't depend on another project to fix their own bugs.
[02:40:43 CET] <KombuchaKip> iive: No, you can write your own M4 macros which are effectively just plugins.
[02:40:55 CET] <iive> well... what's the point then?
[02:41:35 CET] <iive> why involve two languages, to get one job done?
[02:41:52 CET] <KombuchaKip> iive: Is your reasoning shared with the rest of the ffmpeg maintainers?
[02:42:01 CET] <iive> ask them yourself.
[02:42:09 CET] <KombuchaKip> iive: I did above.
[02:43:18 CET] <iive> this is user channel
[02:43:26 CET] <iive> a lot of developers are not here.
[02:45:27 CET] <iive> hum, ffmpeg configure is actually just /bin/sh .
[02:48:03 CET] <iive> KombuchaKip, ask in #ffmpeg-devel
[02:48:12 CET] <KombuchaKip> iive: Ok
[02:48:43 CET] <iive> any reason to ask that? do you want to rewrite it to use autoconf?
[02:50:10 CET] <KombuchaKip> iive: No. But I use both the Autotools daily and ffmpeg as well. It just seemed very counter intuitive what they had done, so I was curious to know their reasoning given that they surely had some. Based on what you shared, although I think your reasons are quite out dated, I can see how they would have made sense a long time ago back when the Autotools were more of a black art with no good books on them.
[02:51:03 CET] <iive> it's possible ffmpeg configure is older than autotools
[02:52:48 CET] <iive> so the cost of maintaining has always been lower than rewriting it.
[02:52:58 CET] <KombuchaKip> iive: Yes, that would make sense.
[02:53:24 CET] <KombuchaKip> iive: And of course it's not just ./configure that would have to be rewritten as configure.ac, but also all the makefile templates too.
[02:55:38 CET] <iive> maybe mason would be good enough to warren a switch. I see it used for a number of projects.
[02:57:03 CET] <KombuchaKip> iive: I've not much experience with it.
[02:59:25 CET] <iive> me either. But seeing how mesa3d transitioned to using it, almost effortlessly... makes me quite optimistic.
[02:59:42 CET] <iive> and they already had autoconf and cmake in place.
[03:49:25 CET] <xxxmaker> anybody here who is expert in video/camera/photo
[04:53:20 CET] <xxxmaker> what is the command to  extract  just the audio.wma file  out of   video-audio.wmv  file
[04:59:56 CET] <TheAMM> ffmpeg -i file.wmv -map 0:a -c copy audio.wma, possibly
[05:00:35 CET] <xxxmaker> what does -map 0:a do
[05:00:38 CET] <xxxmaker> never seen that command
[05:04:14 CET] <another> it selects all audio from input 0 for the output
[05:06:07 CET] <xxxmaker> you mean 0 video for output?
[05:07:05 CET] <another> specifying a map disables automatic stream selection
[05:07:17 CET] <another> https://ffmpeg.org/ffmpeg-all.html#Stream-selection
[05:07:25 CET] <another> so it only maps audio
[05:08:18 CET] <xxxmaker> is it normal that seeking is super slow on  .opus audio
[05:08:31 CET] <xxxmaker> it takes like 5 seconds after seeking to hear a sound
[07:42:02 CET] <xxxmaker> why do i get so many of this error:  Non-monotonous DTS in output stream 0:0; previous: 17928, current: 16656; changing to 17929. This may result in incorrect timestamps in the output file.
[07:42:13 CET] <xxxmaker> when i try to convert wma to opus
[09:04:50 CET] <xxxmaker> [libfdk_aac @ 040536e0] Note, the VBR setting is unsupported and only works with some parameter combinations
[09:05:00 CET] <xxxmaker> why am i getting this error
[09:06:13 CET] <ritsuka> are you sure you are converting wma to opus?
[09:06:43 CET] <xxxmaker> ritsuka yes
[09:06:44 CET] <ritsuka> libfdk_aac is a aac encoder
[09:07:00 CET] <xxxmaker> ritsuka i get 100 errors when i do  wma to opus
[09:07:10 CET] <xxxmaker> i get 2 errrors  when i do  wma to aac
[09:07:16 CET] <xxxmaker> i get 0 errors when i do wma to flac
[09:07:42 CET] <xxxmaker> why is that?
[09:07:54 CET] <ritsuka> well, post the whole output (in a pastebin) and maybe someone will know the reason
[09:08:26 CET] <xxxmaker> what is the command to  output a log
[09:09:28 CET] <JEEB> 2> ffmpeg_sucks.log
[09:09:47 CET] <JEEB> 2> is "redirect standard error" and then the file name
[09:09:49 CET] <xxxmaker> huh
[09:10:02 CET] <JEEB> standard wnidows command line or linux shell stuff :P
[09:10:22 CET] <JEEB> ffmpeg.c outputs to standard error since standard input/output can be utilized for piping stuff in/out
[09:10:38 CET] <xxxmaker> ffmpeg.exe -i extra.wma -acodec libopus -vbr on  extra.opus
[09:10:58 CET] <xxxmaker> where do i put  output a log to extra.txt file
[09:16:47 CET] <xxxmaker> ritsuka  https://pastebin.com/pE62qS52
[09:24:34 CET] <xxxmaker> ritsuka  https://pastebin.com/HVGutYGx
[09:25:00 CET] <xxxmaker> ritsuka so?
[10:30:05 CET] <xxxmaker>  x265 2.1:[Windows][GCC 5.4.0][64 bit] 8bit
[10:30:05 CET] <xxxmaker> Encoding settings              : wpp / ctu=64 / min-cu-size=8 / max-tu-size=32 / tu-intra-depth=1 / tu-inter-depth=1 / me=3 / subme=3 / merange=57 / rect / no-amp / max-merge=3 / temporal-mvp / no-early-skip / rskip / rdpenalty=0 / no-tskip / no-tskip-fast / no-strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / no-temporal-layers /
[10:30:05 CET] <xxxmaker> interlace=0 / keyint=300 / min-keyint=30 / scenecut=40 / rc-lookahead=25 / lookahead-slices=4 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=4 / limit-refs=3 / limit-modes / weightp / no-weightb / aq-mode=1 / qg-size=32 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=4 / psy-rd=2.00 / rdoq-level=2 / psy-rdoq=1.00 / log2-max-poc-lsb=8 / no-rd-refine / signhide / deblock=0:0 / sao / no-sao-non-deblock
[10:30:05 CET] <xxxmaker> / b-pyramid / cutree / no-intra-refresh / rc=crf / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ipratio=1.40 / pbratio=1.30
[10:30:05 CET] <xxxmaker> Default                        : Yes
[11:51:35 CET] <xxxmaker> i need help :  https://pastebin.com/pE62qS52
[12:31:26 CET] <faLUCE> I'm trying to decouple encoders from muxers as much as I can. With mpegts-video I can do that:  the avcodeccontext of the muxer only requires width, height and the codecId params, without having to allocate a full avcodeccontext for it.  But it seems that matroska, for example, requires much more params and a full avcodeccontext allocation: why? which params does matroska really need by the avcodeccontext?
[12:32:43 CET] <DHE> it just has way more metadata than mpegts, which has little more than codecid and some minimal non-codec information like audio language, etc.
[12:35:29 CET] <faLUCE> DHE: but which params exactly? it needs a global header... and what else? I don't know which params from avcodeccontext I have to set
[12:35:30 CET] <DHE> ...if the mkv muxer is actually requiring an AVCodecContext, there's something wrong. or you're using a version pre-codecpar
[12:35:43 CET] <faLUCE> I'm using 4.1.1
[12:38:02 CET] <DHE> that seems new enough..
[12:38:17 CET] <JEEB> he means copying values/buffers from avctx to codecpar
[12:38:22 CET] <JEEB> just putting it badly :P
[12:39:44 CET] <faLUCE> I use:  avcodec_parameters_from_context(mVideoStream->codecpar, mVideoCodecContext);
[12:40:25 CET] <faLUCE> mVideoCodecContext is not allocated. It's only filled with width, height, and codecId
[12:40:30 CET] <DHE> so you're decoding the video just enough to get the codeccontext parameters, then copying that to the actual output->streams[x]->codecpar ?
[12:41:22 CET] <faLUCE> I get that parameters not by the decoded video
[12:42:24 CET] <faLUCE> I set them manually on an avcodeccontext object, then I copy them on the stream with  avcodec_parameters_from_context
[12:43:26 CET] <faLUCE> JEEB: why do you think I put badly the params?
[12:43:38 CET] <JEEB> I meant you worded it badly
[12:43:42 CET] <JEEB> just like I can word things badly
[12:43:50 CET] <JEEB> you made him think that you were using avctx in avstream
[12:43:57 CET] <JEEB> which is an old thing that hasn't been in FFmpeg for a while
[12:43:58 CET] <faLUCE> I see
[12:44:29 CET] <DHE> and I'm confused. you can set values on the avcodecparameters object yourself as well. it's not an opaque structure. don't need to fill in a codeccontext and then use the copy function
[12:44:59 CET] <JEEB> I think he was more wondering what he exactly needed to be put into the codecpar because he wanted to minimize his code orso
[12:45:07 CET] <JEEB> which of course "depends on the format"
[12:45:34 CET] <faLUCE> JEEB: exactly
[12:45:50 CET] <faLUCE> for mpegts I only needed width, height and codecId
[12:46:01 CET] <JEEB> yes, because the container level stuff that's put in is minimal
[12:46:16 CET] <faLUCE> but for matroska it seems that I need much stuff
[12:46:19 CET] <JEEB> matroska on the other hand needs to generate stuff that contains the decoder initialization stuff
[12:46:28 CET] <DHE> I don't think you actually need width and height for mpegts either
[12:47:06 CET] <faLUCE> matroska seems to need all the parameters I set for the x264 encoding... tune, bitrate etc.
[12:49:45 CET] <faLUCE> is this true? It seems overkill
[12:50:40 CET] <DHE> mkv is the overkill format. chapters, multi-track, supports nearly any codec and subtitles,
[12:51:02 CET] <JEEB> I don't think it utilizes bit rate nor tune
[12:51:16 CET] <JEEB> I would think having extradata and width/height etc should be enough?
[12:51:23 CET] <JEEB> you wouldn't know exactly without looking at the muxer, though :P
[12:51:29 CET] <JEEB> see the write_header function
[12:51:58 CET] <DHE> tune seems excessive from a need-to-know standpoint. profile (baseline, main, high) could make sense if you're including resolution
[12:52:27 CET] <faLUCE> by looking at matroscaenc.c it uses par->extradata
[12:52:44 CET] <JEEB> that one we could guess by the format's requirements, yes
[12:53:01 CET] <JEEB> since you have the decoder initialization data structure which is out-of-band
[12:56:02 CET] <faLUCE> [12:51] <JEEB> I would think having extradata and width/height etc should be enough?  <---- but is extradata affected by tune, preset, bitrate, profile ?
[12:57:02 CET] <JEEB> it is literally a set of bytes you get from an encoder or a stream you're copying through
[12:57:17 CET] <JEEB> thus your question doesn't make sense
[12:57:36 CET] <JEEB> even if it is affected, what does that matter if you are properly passing it through from your input stream
[12:58:02 CET] <faLUCE> JEEB: if my initial question was "how can I decouple the muxer from the encoder"
[12:58:57 CET] <DHE> sadly you can't. if you know the codec, you probably have a usable AVCodecPar, either because you are encoding it, or are demuxing it from something that can provide its own AVCodecPar for you to copy
[12:59:54 CET] <faLUCE> DHE: but with mpegts I can...
[13:00:27 CET] <JEEB> because mpeg-ts is a format that doesn't require more info
[13:00:43 CET] <JEEB> if you want to decouple from the encoder then just add a parser of your own
[13:00:48 CET] <DHE> if the input is mpeg-ts, I suggest avformat_find_stream_info() which will fill in the codecpar for all the input streams which you can copy
[13:00:49 CET] <JEEB> which extracts the parameter sets
[13:01:40 CET] <faLUCE> [13:00] <DHE> if the input is mpeg-ts, I suggest avformat_find_stream_info()  <--- do you mean if the input is matroska?
[13:02:09 CET] <faLUCE> with mpegts I just need the codecId....
[13:02:26 CET] <DHE> that works too. point is avformat_find_stream_info does its best to fill in all the codecpar fields for all the streams
[13:03:10 CET] <DHE> then avcodec_parameters_copy(outputctx->streams[x]->codecpar, inputctx->streams[y]->codecpar); // regardless of formats
[13:08:19 CET] <faLUCE> DHE: in this case I would not need to use an AVCodecContext for filling the params, right?
[13:29:31 CET] <DHE> no
[13:43:44 CET] <faLUCE> DHE: so the procedure would be that: I alloc an AVFormatContext with a specific format (for example: matroska). Then I av_write_frame() some incoming packets and call, after each av_write_frame(), avformat_find_stream_info() until it returns >= 0. At this point I'm sure that the codecpars are filled and then I can mux the packets with that format, right?
[14:26:24 CET] <dongs> dongs
[14:27:00 CET] <pink_mist> pink_mist
[16:32:21 CET] <faLUCE> I don't get the point yet. With avformat_find_stream_info() I can get infos of a MUXED stream. But I can't use it for filling the codecparameters of an output stream if I don't have a muxed input stream but I have only encoded packets. There seems to be a bad coupling of the matroska format with avcodeccontext. I mean: why would  this format require a full allocated avcodeccontext with all its parameters for working?
[16:32:53 CET] <drew32> Hey all!
[16:33:45 CET] <drew32> https://www.ffmpeg.org/ffmpeg-formats.html#dash-2 shows a -streaming 1 option but when I added it, it tells me option not found.  Was it removed?
[16:34:31 CET] <faLUCE> matroska format should work regardless of all the codec's infos, like bitrate, tune etc.
[16:34:59 CET] <JEEB> faLUCE: it doesn't need *all*
[16:35:03 CET] <JEEB> it does need extradata
[16:35:10 CET] <JEEB> which you can get by parsing the stream that you are going to pass to it
[16:35:19 CET] <JEEB> mp4 does the same thing, it needs H.264 etc initialization data
[16:35:27 CET] <JEEB> different formats are different
[16:35:41 CET] <JEEB> like, if you want to completely black box what you're passing to the muxer
[16:35:55 CET] <Ducky^> I'm trying to do a two pass encode from asf to mp4 with a very old version of ffmpeg (which can't be upgraded..)
[16:35:56 CET] <JEEB> then you just add a parser in front of the muxing thing that gets the required stuff from the bit stream you're passing
[16:36:02 CET] <Ducky^> https://pastebin.com/Y5Skjjij
[16:36:11 CET] <JEEB> drew32: the AVOption is still there
[16:36:16 CET] <Ducky^> I want to target a file size of 2MB
[16:36:32 CET] <Ducky^> I get the error - [libx264 @ 0x7c41430]Error: 2pass curve failed to converge
[16:36:37 CET] <JEEB> drew32: libavformat/dashenc.c:    { "streaming", "Enable/Disable streaming mode of output. Each frame will be moof fragment", OFFSET(streaming), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E },
[16:36:43 CET] <JEEB> so you might actually have a too old version?
[16:37:11 CET] <Ducky^> and the log file is empty
[16:37:20 CET] <Ducky^> the resulting file is 10MB
[16:37:23 CET] <faLUCE> JEEB: and how could I parse that stream for getting the extradata value? they are only encoded packets
[16:37:33 CET] <JEEB> yes, for H.264 you use a H.264 parser
[16:37:36 CET] <JEEB> for HEVC you use a HEVC parser
[16:38:10 CET] <faLUCE> JEEB: I see, but is there such a parser wrapped in lavc? or do I need to call x264 natively ?
[16:38:41 CET] <drew32> ah I think you are right I have version 3.4.4-0ubuntu-.19.04.1
[16:38:42 CET] <JEEB> lavf has a raw H.264 parser. but seriously, if you have an encoder yourself under your control, just pass the extradata from the encoder forwards
[16:39:14 CET] <JEEB> also if you are using lavf for input reading then you can pass the extradata from there
[16:39:24 CET] <JEEB> if you are having some custom input that doesn't use lavf
[16:39:28 CET] <JEEB> then you will have to parse the stream
[16:39:36 CET] <JEEB> either with lavf or by yourself
[16:39:38 CET] <JEEB> sorry
[16:39:59 CET] <faLUCE> JEEB: right
[16:44:26 CET] <faLUCE> JEEB: you are right, but it seems a sort of hack/workaround. I mean: the extradata depends on the encoder's settings (bitrate,tune etc.) but the extradata needed by the format doesn't have to depend by them. I don't know how to explain better, but you can get it
[16:47:40 CET] <faLUCE> it seems a bug of the matroska muxer
[16:50:15 CET] <faLUCE> the problem is not if I have or not have custom input. Even if the input is made by lavc, the container's initialization should not be coupled with the encoder
[17:05:21 CET] <faLUCE> so, JEEB no: I don't want to black box what I'm passing to the muxer. I just want to pass the muxer the right number of params, not  an obscure field wich mixes together stuff not associated with the matroska container
[17:05:59 CET] <faLUCE> let's try to ask to the devel channel
[17:38:27 CET] <cj> o/
[17:39:18 CET] <cj> I'm looking to convert an .mkv to .mp4 and re-order the audio tracks - or mark the second audio track as default, while keeping the subtitles tracks.
[17:39:30 CET] <cj> could I get some help building up my command?
[17:39:58 CET] <cj> it looks something like this:
[17:39:59 CET] <cj> ffmpeg -i "$in" -map 0:v:0 -map 0:a:1 -map 0:a:0 -c:v libx264 -preset veryslow -crf 22 -c:a libmp3lame -qscale:a 2 -ac 2 -ar 44100 "$out"
[17:40:38 CET] <cj> wait, that's the one going from ogm to mp4
[17:40:43 CET] <furq> cj: -disposition:a:0 0 -disposition:a:1 default
[17:40:50 CET] <furq> or the other way round. 0 clears the flag, default sets it
[17:40:57 CET] <cj> thanks, furq!
[17:41:08 CET] <furq> this is assuming you've already tried it and the wrong track is selected
[17:41:16 CET] <furq> otherwise just the -maps you have will work
[17:41:35 CET] <furq> also you would normally use aac audio in mp4
[17:41:38 CET] <cj> so maybe `ffmpeg -i "$in" -disposition:a:0 0 -disposition:a:1 default -codec copy "$out"` ?
[17:41:47 CET] <furq> well you still want the maps as well
[17:41:49 CET] <DHE> also, unless you have codec problems you probably just want to copy the coded video/audio from the source.
[17:41:57 CET] <cj> okay, do I replace libmp3lame with libaac ?
[17:42:02 CET] <furq> DHE: if the source is ogm then that's vorbis
[17:42:05 CET] <Ducky^> ffmpeg -y -i /tmp/test.mpeg -b 270k -vcodec libx264 -an test.mp4
[17:42:07 CET] <furq> idk if that muxes into mp4 but probably not
[17:42:23 CET] <Ducky^> I'm using this line with an old version of ffmpeg, but the video bitrate comes out to around 1700k instead of 270k
[17:42:27 CET] <DHE> would ogm have h264, or would it be something like theora
[17:42:30 CET] <Ducky^> is there a limit to how low the bitrate can be?
[17:42:32 CET] <furq> cj: -c:a aac -vbr 5 or -c:a aac -b:a 128k
[17:42:37 CET] <furq> er
[17:42:39 CET] <furq> actually just the second one
[17:42:45 CET] <cj> thanks
[17:42:48 CET] <furq> -vbr 5 is for libfdk_aac which you won't have unless you built ffmpeg yourself
[17:43:37 CET] <Ducky^> if I set the bitrate to something like 3000k it actually comes out as 3000k
[17:43:43 CET] <cj> I had debian build it for me.  is it a better codec?
[17:44:07 CET] <cj> coder, I suppose
[17:47:41 CET] <furq> cj: yes but it's not gpl compatible so you can't distribute binaries with it
[17:47:48 CET] <furq> also it's not that much better for cbr, the builtin encoder is fine
[17:58:54 CET] <faLUCE> well, DHE, from what I see the matroska header is strictly coupled with the encoder's params:   https://lists.matroska.org/pipermail/matroska-devel/2012-April/004196.html . So, DHE, you were wrong when you said  "<DHE> it just has way more metadata than mpegts, which has little more than codecid and some minimal non-codec information like audio language, etc."
[17:59:06 CET] <faLUCE> or do I miss something? (I could be wrong as well)
[17:59:26 CET] <cj> maybe I don't understand streams or maps correctly... this command results in the error "Stream map '0:a:1' matches no streams.
[17:59:29 CET] <cj> ffmpeg -i "$in" -map 0:v:0 -map 0:a:1 -map 0:a:0 -disposition:a:0 0 -disposition:a:1 default -codec copy "$out"
[18:00:53 CET] <cj> Stream #0:1(jpn): Audio: aac (HE-AAC), 32000 Hz, stereo, fltp (default) and Stream #0:2(eng): Subtitle: ass (default)
[18:00:55 CET] <DHE> cj: ffmpeg should output a quick analysis of the input file including the streams in the orders and identities. it only shows 0:0, 0:1, ... names though
[18:01:00 CET] <DHE> yeah that
[18:01:18 CET] <DHE> that's presumably 0:0 as video, 0:1 as audio (japanese) and 0:2 as subtitles (english)
[18:01:26 CET] <cj> I guess I should disable default on the eng stream.  that might be sufficient maybe
[18:01:55 CET] <DHE> here (default) is more an indication that if ffmpeg had to select one audio stream (eg: simply 0:a) this would be its selection
[18:02:41 CET] <cj> why might it be telling me that "Stream map '0:a:1' matches no streams ?
[18:03:40 CET] <DHE> because you only have 1 video stream, 1 audio stream, and 1 subtitle stream (based on what you pasted above). there is no second audio stream
[18:03:46 CET] <cj> oh, I see.  only a single audio stream in this one, apparently.  I thought they all had two audio streams
[18:03:58 CET] Action: cj opens with vlc to verify
[18:04:41 CET] <cj> so I guess my script needs to determine whether there is one or two audio stream/s.
[18:04:56 CET] <cj> and do the re-order and mapping only if there are two
[18:05:18 CET] <cj> I was hoping there would be something to dump json or something more easily parsable than `ffmpeg -i $in -no_banner`
[18:05:28 CET] <cj> does anything like that exist, or shall I write a parser function? :-)
[18:05:34 CET] <furq> ffprobe has a json output format
[18:05:41 CET] <cj> \o/
[18:05:52 CET] <furq> also yeah if your source already has aac or mp3 audio then you should just use -c:a copy
[18:08:57 CET] <faLUCE> well, they are telling to me that matroska's header does need h264 encoder's params...
[18:09:38 CET] <faLUCE> so, there's no way to decouple the muxer from the encoder. It's not a ffmpeg problem, but it's a spec of matroska
[18:17:50 CET] <faLUCE> I don't understand why, in each case, the matroska header wants that infos, if a raw h264 video can be played as well
[18:22:01 CET] <kepstin> a "raw" h264 stream requires the same information, it's put into a packet at the start of the data.
[18:23:02 CET] <kepstin> iirc with mpeg-ts, the codec initialization data is supposed to repeated periodically through the stream so you can jump in at an arbitrary point.
[18:24:12 CET] <kepstin> matroska (and mp4/mov too) store that information in a spot defined by the container.
[18:24:35 CET] <faLUCE> kepstin: they are  answering to me in the #matroska channel
[18:24:48 CET] <kepstin> with mp4, that's not written until the *end* of the stream, which is why mp4 files that were interrupted/truncated are not playable
[18:30:58 CET] Action: DHE patches lavf/udp.c for realtime threading. :/
[18:44:46 CET] <faLUCE> kepstin: finally I got the point. Matroska is coupled with the encoder's params because it's not "bytestream". Then, all the infos for decoding frames are in the header. Then you can start decoding immediatly
[18:47:45 CET] <faLUCE> in this way, for example, if the codec's params change, you can tune the decoder soon
[18:54:54 CET] <drew32> Hey so I followed a guide to compile a newer version of ffmpeg on ubuntu.  My version now shows N-93414-g4602456.  looks like this is what I compiled: https://ffmpeg.org/releases/ffmpeg-snapshot.tar.bz2
[18:55:05 CET] <drew32> Anyone know if this is an up to date version or did I follow an incorrect guide
[18:56:05 CET] <DHE> that's dated today. how new do you need it?
[18:56:22 CET] <drew32> I think that's new enough lol, how did you tell it was dated today?
[18:56:23 CET] <kepstin> there's only been 1 commit since that tarball :)
[18:56:28 CET] <DHE> I see 2, but still
[18:56:35 CET] <kepstin> drew32: the stuff after the g on the end is the git commit hash
[18:56:42 CET] <DHE> go to my git dir, and run: git log 4602456
[18:56:49 CET] <drew32> ahh thanks! I'm still new to this stuff
[18:58:45 CET] <DHE> of course its' so new I have to `git fetch origin` first. :)
[19:00:39 CET] <BtbN> Put the commit ID into github, and it's pretty clear: https://github.com/FFmpeg/FFmpeg/commits/4602456
[19:02:06 CET] <drew32> Hopefully this version fixes some of the DASH issues ive been having
[19:06:39 CET] <cj> hurm.  so the map / disposition thing didn't change the default audio stream from english to japanese.  how would I go about doing this?  I extracted the stream metadata with ffprobe, so I have that info to throw in to the command if needed.
[19:10:10 CET] <another> cj: maybe your player has a lang preference?
[19:13:07 CET] <drew32> wow finally the dash stream no longer crashes after a few mins!
[19:13:16 CET] <drew32> i'm loving this new version lol
[20:20:02 CET] <retal> faLUCE, Hi i still have problem with compiling with nvresize and x264
[20:20:13 CET] <retal> what can i do ?
[20:25:59 CET] <BtbN> nvresize? Are you using that ancient patch from nvidia? If so, just don't. There are two CUDA based scaling filters that are actually part of ffmpeg.
[20:26:33 CET] <retal> BtbN, yes i patched
[20:26:52 CET] <BtbN> Don't.
[20:27:26 CET] <retal> How to using CUDA resize in ffmpeg ?
[20:29:02 CET] <BtbN> Don't use that ancient pointless patch.
[20:30:30 CET] <retal> BtbN, ok, thank you. But how use scaling filters with CUDA acceleration ?
[20:30:49 CET] <BtbN> "There are two CUDA based scaling filters that are actually part of ffmpeg."
[20:31:20 CET] <BtbN> scale_cuda for the simple case, and the npp based on for more features but more of a hassle to get a working
[20:31:49 CET] <retal> BtbN, thank you
[20:34:34 CET] <ginel> I'd like to build a live video stream with ffmpeg and I'd like to include multiple layers
[20:35:19 CET] <ginel> is there a way to have ffmpeg dynamically load text from a file each frame?
[20:36:40 CET] <ginel> I'm trying to figure out how to have a progress bar fill up with color and a text label as the value increases
[20:38:05 CET] <ChocolateArmpits> That sounds like something Avisynth would do more easily
[20:38:12 CET] <ChocolateArmpits> but if it's a live one
[20:38:15 CET] <ChocolateArmpits> ..
[20:40:15 CET] <ginel> I will experiment with 'textfile="/path/file.txt":reload=1' here
[20:40:23 CET] <retal> BtbN, should i install https://git.videolan.org/git/ffmpeg/nv-codec-headers.git ?
[20:40:45 CET] <BtbN> You'll have to if you want to build ffmpeg with any kind of CUDA/nvenc/nvdec features.
[20:41:08 CET] <retal> thank you
[20:58:12 CET] <ginel> what does this mean:
[20:58:14 CET] <ginel> Cannot find a matching stream for unlabeled input pad 0 on filter Parsed_drawtext_1
[20:58:19 CET] <ginel> when trying to run this:
[20:58:48 CET] <ginel> http://paste.debian.net/1073998/
[21:06:35 CET] <retal> libavformat/libavformat.a(allformats.o):(.data.rel.ro+0x398): undefined reference to `ff_kux_demuxer'
[21:06:35 CET] <retal> collect2: error: ld returned 1 exit status
[21:06:35 CET] <retal> Makefile:108: recipe for target 'ffmpeg_g' failed
[21:06:35 CET] <retal> make: *** [ffmpeg_g] Error 1
[21:06:56 CET] <retal> how to fix ?
[21:09:27 CET] <ChocolateArmpits> ginel, you need to use a comma instead of a semicolon between the two filters
[21:10:26 CET] <ginel> gotcha
[21:23:03 CET] <retal> guys, how to fix error: libavformat/libavformat.a(allformats.o):(.data.rel.ro+0x398): undefined reference to `ff_kux_demuxer'
[21:23:03 CET] <retal> collect2: error: ld returned 1 exit status
[21:23:03 CET] <retal> Makefile:108: recipe for target 'ffmpeg_g' failed
[21:23:03 CET] <retal> make: *** [ffmpeg_g] Error 1
[21:24:50 CET] <faLUCE> hello retal :-)
[21:25:48 CET] <faLUCE> in order to fix the error you shuld tell what kind of configure you want
[21:27:24 CET] <faLUCE> and which patches you applied
[21:31:43 CET] <retal> faLUCE, Hi, i am configuring: ./configure --enable-nonfree --enable-nvenc --enable-libx264 --enable-gpl --enable-cuda --enable-cuvid
[21:31:43 CET] <retal> So i need CUDA transcoding and software 264 codec.
[21:31:43 CET] <retal> BtbN told me i dont need use ancient patches for nvresize, instead i can use "scale_cuda"
[21:31:43 CET] <retal> So i didnt apply patches
[21:32:43 CET] <furq> ginel: replace the ; with ,
[21:32:54 CET] <ginel> yeah done
[21:33:04 CET] <furq> oh christ this is that french gist again isn't it
[21:33:09 CET] <furq> i thought i'd finally seen the last of that thing
[21:33:36 CET] <faLUCE> retal: are you sure the error tells "ff_kux_demuxer" ?
[21:34:06 CET] <faLUCE> did you copy/paste it ?
[21:34:41 CET] <furq> ginel: get rid of pretty much the entire second line of that gist (-acodec to 512k) because basically all of it is wrong or stupid
[21:35:01 CET] <furq> and replace it with -c:a aac -b:a 128k
[21:35:22 CET] <retal> faLUCE, may be i shuld tri install on clean system
[21:35:24 CET] <retal> look https://pastebin.com/geczWC1i
[21:35:46 CET] <ginel> how much of that second line is defaults?
[21:35:50 CET] <ginel> out of curiosity
[21:35:56 CET] <furq> none of it except possibly -ar
[21:36:04 CET] <faLUCE> retal: it seems that some patch is still in memory
[21:36:16 CET] <furq> depending on the source sample rate
[21:36:16 CET] <ginel> ok well I need the preset
[21:36:28 CET] <retal> faLUCE, may be
[21:36:31 CET] <furq> i meant the line starting with -acodec
[21:36:40 CET] <ginel> ok
[21:37:05 CET] <faLUCE> retal: you just have to grep "ff_kux_demuxer" in the src
[21:37:06 CET] <furq> also it looks like you already got rid of -deinterlace but definitely don't ever use that
[21:37:09 CET] <furq> not even if the source is interlaced
[21:37:11 CET] <ginel> this is going to be sent to an RTMP ingest for what it's worth
[21:37:15 CET] <faLUCE> then, tell me the file where you find it
[21:37:18 CET] <furq> yeah there's no other reason to use flv
[21:37:46 CET] <furq> if it was just a file i'd also say to get rid of -g but youtube recommends two seconds for some reason so why not
[21:38:03 CET] <ginel> -vcodec libx264 -pix_fmt yuv420p -preset ultrafast -r 30 -g $((30 * 2)) -b:v 2500k -a:c aac -crf 23\
[21:38:08 CET] <ginel> how about that
[21:38:14 CET] <furq> -b:v and -crf are incompatible
[21:38:26 CET] <furq> i assume it uses whichever comes last
[21:38:29 CET] <ginel> ah yeah that makes sense
[21:38:33 CET] <ginel> didn't catch that
[21:39:17 CET] <ginel> surprised it didn't warn me
[21:40:09 CET] <furq> if you do use crf you'll probably want something like -maxrate 2500k -bufsize 5000k
[21:40:22 CET] <furq> it's not a bad idea to set that with -b:v either but you'll definitely want it for crf to avoid rate spikes
[21:42:33 CET] <ginel> any idea why YouTube says it's receiving data then pretty much immediately says it's not?
[21:43:40 CET] <ginel> http://paste.debian.net/1074006/
[21:43:47 CET] <ginel> new paste, minus my damn stream key
[21:43:53 CET] <ginel> didn't notice I'd included that
[21:45:18 CET] <furq> probably because there's no audio source
[21:45:34 CET] <ginel> ah might be
[21:45:35 CET] <furq> -f lavfi -i anullsrc
[21:47:33 CET] <ginel> for the curious I'm trying to put a countdown and "raised funds" progress bar on a VPS and run the stream from there
[21:51:08 CET] <cj> another: good point.  I'll check the docks.
[21:51:15 CET] <cj> s/k//
[21:51:49 CET] <ginel> it looks like YouTube doesn't want to archive the 60 second test stream I did using this command. the archive is stuck at processing in the old dashboard and in the new dashboard it's not even there
[21:52:07 CET] <ginel> can anyone see any issues with the command that YouTube might be having an issue with?
[22:15:04 CET] <retal> faLUCE, Binary file libavformat/libavformat.a matches
[22:15:05 CET] <retal> libavformat/demuxer_list.c:    &ff_kux_demuxer,
[22:15:05 CET] <retal> Binary file libavformat/allformats.o matches
[22:15:05 CET] <retal> libavformat/allformats.c:extern AVInputFormat  ff_kux_demuxer;
[22:18:32 CET] <furq> retal: looks like that line was added three hours ago and there's no corresponding symbol yet
[22:18:36 CET] <furq> so maybe that latest commit is broken
[22:18:53 CET] <retal> :))))
[22:19:04 CET] <retal> what can i do ? :)
[22:19:26 CET] <retal> how to clone right commit ?
[22:21:02 CET] <furq> if you already cloned the repo then git checkout 4602456c4f18d111131d4d6a1d0a150474c74d58
[22:21:20 CET] <retal> friki, thanks
[22:22:10 CET] <furq> http://fate.ffmpeg.org/
[22:22:12 CET] <furq> looks like it's not just you
[22:22:41 CET] <retal> :)
[22:28:50 CET] <faLUCE> retal: in each case, I would not use the git image
[22:29:00 CET] <faLUCE> use the stable image, instead
[22:29:12 CET] <faLUCE> why are you using the git one?
[22:30:31 CET] <retal> faLUCE, i am cloning from git://source.ffmpeg.org/ffmpeg.git, stabile image i shuld download from ffmpeg website ?
[22:32:02 CET] <faLUCE> retal: yes, download it from the home page, don't use git, you don't need the git image
[22:33:06 CET] <retal> faLUCE, thank you,  in next time i will use home page, anyway i just aplyed: git checkout 4602456c4f18d111131d4d6a1d0a150474c74d58, and compile without error
[22:33:35 CET] <faLUCE> ok
[22:33:59 CET] <faLUCE> but you should use the stable image in any case
[22:34:28 CET] <faLUCE> git is for development or for experimental stuff, or if you really need something that you don't have in the stable image
[22:34:37 CET] <faLUCE> but it's not stable
[22:36:26 CET] <retal> faLUCE, you right i just a user :)
[22:41:08 CET] <BtbN> don't use git:// urls. They are inherently insecure and entirely unencrypted.
[23:03:20 CET] <cj> git+ssh ftw
[23:04:53 CET] <faLUCE> do you know if avcodec_parameters_from_context() are all copies? I see that extradata is a pointer and I wonder if it's a reference or a copy of the stuff
[23:05:59 CET] <faLUCE> sorry, just checked: it's a copy (memcpy)
[23:08:09 CET] <faLUCE> then I wonder: what's the best way to free it? manually or is it freed by the cleanup avstream's stuff ?
[23:20:39 CET] <DHE> avcodec_parameters_free() obviously
[23:21:17 CET] <DHE> I assume avformat will call that during its own cleanup as it cleans up the streams
[23:21:37 CET] <faLUCE> yes, I thought about avformat, not avstream
[23:51:41 CET] <retal> guys how to enable scale_cuda ?
[23:54:56 CET] <furq> --enable-cuda-nvcc
[23:54:59 CET] <furq> or just use scale_npp
[00:00:00 CET] --- Thu Mar 21 2019