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

burek burek021 at gmail.com
Mon Nov 19 03:05:02 EET 2018

[00:25:32 CET] <Rick627> turn off notifications
[01:59:03 CET] <analogical> why doesn't FFmpeg accept wildcards in filenames?
[01:59:55 CET] <pink_mist> that's not up to ffmpeg, that's up to your shell
[02:00:26 CET] <pink_mist> shells are the things that expands wildcards into a bunch of filenames. never utilities themselves
[02:01:39 CET] <pink_mist> however, I'm pretty sure ffmpeg does support some kinds of wildcards, such as numbers going up sequentially
[02:06:10 CET] <pink_mist> oh, actually, even actual wildcard globbing if you've compiled ffmpeg with that option and specify it on the commandline -- http://ffmpeg.org/ffmpeg-all.html#Examples-7
[05:07:09 CET] <GlenK> hiya.  I was kinda hoping to get ffmpeg to not use all my cpus.  neither -threads 1 and -filter_threads 1 seems to do the trick.  any help?
[05:40:03 CET] <GlenK> eh.  oh well.  cpulimit is my friend at least.  =)
[06:39:47 CET] <KombuchaKip> I am writing a unit test for my custom AVIOContext. In order to test that it is working, I'd like to pull all data that its surrounding AVFormatContext can without doing any decoding. I just want to read all the data and verify the checksum to ensure it's what was expected of the source input data.
[11:33:53 CET] <amosbird> Hello, how can I debug avformat_open_input returning Invalid data found when processing input ?
[13:45:57 CET] <ariyasu> [dshow @ 000001e28f38afc0] real-time buffer [AVerMedia BDA Analog Capture Secondary] [video input] too full or near too full (81% of size: 3041280 [rtbufsize parameter])! frame dropped!
[13:46:07 CET] <ariyasu> is there someway to increase the buffer size?
[13:51:21 CET] <furq> -rtbufsize
[13:52:25 CET] <ariyasu> ty
[19:09:28 CET] <KombuchaKip> I am writing a unit test for my custom AVIOContext. In order to test that it is working, I'd like to pull all data that its surrounding AVFormatContext can without doing any decoding. I just want to read all the data and verify the checksum to ensure it's what was expected of the source input data.
[19:09:53 CET] <JEEB> probably opening some raw demuxer is the best way to go about that
[19:10:35 CET] <JEEB> most demuxers parse the input and effectively only give you the packets within but not the actual full data :P
[19:48:20 CET] <KombuchaKip> JEEB: What about avio_read(3)?
[19:48:49 CET] <JEEB> if an API client can actually utilize those, I guess... just not sure if those are public
[19:49:45 CET] <JEEB> https://www.ffmpeg.org/doxygen/trunk/avio_8h.html#abb4e58439be0bff0dc2e2974ee5fb6a3
[19:49:59 CET] <JEEB> well, if that's usable by public API clients then sure
[19:50:19 CET] <JEEB> and yes, we've seemingly got an example using that
[19:50:24 CET] <JEEB> so I think you're good with that
[19:50:32 CET] <JEEB> I'm way too used to just passing the thing through to AVFormat XD
[19:51:56 CET] <KombuchaKip> JEEB: Yes, of course. Thank you.
[19:52:18 CET] <KombuchaKip> JEEB: It's just for a unit test to verify all my pointer arithmetic and expected behaviour is correct in my custom AVIOContext
[19:55:08 CET] <JEEB> KombuchaKip: yea, makes sense to keep it limited to the AVIO context then
[19:57:03 CET] <KombuchaKip> JEEB: =)
[20:43:45 CET] <wwp> hi
[20:45:06 CET] <wwp> any idea why my ffmpeg 4.1 compiled from the sources, static, (following https://trac.ffmpeg.org/wiki/CompilationGuide/Centos) on my centos7 is 2.5 slower than the centos7's one (2.8.15)?
[20:45:48 CET] <wwp> I experience the same perfs differences on a centos6 (4.1 vs centos' 0.6.5)
[20:46:21 CET] <JEEB> are you sure you are actually enabling SIMD?
[20:46:26 CET] <JEEB> in both dependencies and FFmpeg itself
[20:46:37 CET] <JEEB> also which modules are you finding slowness in?
[20:46:38 CET] <wwp> hm. I'm not sure at all
[20:46:55 CET] <wwp> I did a basic flac->mp3 convertion in a loop to measure timings
[20:46:56 CET] <JEEB> FFmpeg and x264 at least would require disable-asm to be defined to let you build for x86
[20:48:09 CET] <wwp> the instructions at the link I pasted above doesn't mention any --disable-<> optimiization-related switch
[20:48:48 CET] <wwp> s/doesn/don/
[20:51:03 CET] <wwp> config.h shows HAVE_SIMD_* -> 1
[20:52:48 CET] <furq> there's no builtin mp3 encoder so maybe the lame config is different
[20:53:27 CET] <wwp> lame-3.100 in that case
[20:54:26 CET] <wwp> lame is configured with --enable-nasm
[20:54:56 CET] <furq> fun
[20:55:03 CET] <furq> you should probably use an internal encoder anyway
[20:55:12 CET] <furq> aac or ffv1 are probably good choices
[20:56:24 CET] <wwp> my point was to compare the perfs of the ffmpeg 4.x compiled from the sources and the distro's default one
[20:56:54 CET] <wwp> do you mean that the same ffmpeg command may use different encoders following how ffmpeg is compiled?
[21:45:26 CET] <markweston> can you convert a video to use only 16 colors/
[21:49:16 CET] <markweston> I mean I know you can, I'm interested whether it can be easily done with ffmpeg?
[21:56:42 CET] <durandal_1707> yes, pelettegen & paletteuse
[22:01:52 CET] <markweston> thanks
[22:34:38 CET] <taliho> Hello, I've been doing some reading on the HEVC bit stream syntax. I'm wondering if I could ask a clarification question on this forum?
[22:37:36 CET] <taliho> My question is whether the NAL units generated by x265 are directly compatible with the definition of PES stream?
[22:40:52 CET] <taliho> Also, if I would like mux a video stream with general binary data, do the packets of the binary data need to be in the PES syntax? (i.e https://en.wikipedia.org/wiki/Packetized_elementary_stream)
[22:41:55 CET] <taliho> if the muxer is mpegts
[22:45:16 CET] <JEEB> the H.222 specification has notes about AVC/HEVC (NAL unit based video formats)
[22:45:39 CET] <JEEB> https://www.itu.int/rec/T-REC-H.222.0-201703-S/en
[22:45:45 CET] <JEEB> see this document, the PDF is freely available
[22:46:00 CET] <JEEB> and it's a new enough version to have AVC and HEVC there
[22:48:19 CET] <hola1> I've got some footage from a goXtreme action cam which doesn't play fluently. How do I change the codec?
[22:49:30 CET] <taliho> thanks JEEB, I'll read this document
[22:49:59 CET] <JEEB> but I think what you put into MPEG-TS PES streams were just Annex B NALUs
[22:50:12 CET] <JEEB> not that I'm sure but that's how it felt like :P
[22:56:02 CET] <taliho> JEEB, that's what I thought too. The wiki article on PES got me confused though, because the ANNEX B NAL unit syntax is a bit different to PES syntax on wiki
[22:56:55 CET] <JEEB> just read the H.222 document, that's the MPEG-TS/PS spec :P
[22:57:11 CET] <JEEB> and as far as I remember it has parts on NAL unit based video (AVC/HEVC)
[22:57:20 CET] <JEEB> at least I've seen the IDs there
[23:14:18 CET] <kjy> Can anyone help me do rgb color operations using the "program_opencl" filter? I've got the filter itself working, but no matter what combination of format filters I use it always seems like I'm working in yuv.
[23:14:27 CET] <kjy> Here is the basic command without any format filters: https://pastebin.com/61KYn4zX
[23:18:00 CET] <jkqxz> kjy:  It should do the right thing if you put a 'format=rgba' before the hwupload and after the hwdownload.
[23:23:58 CET] <kjy> jkqxz: I've tried that, and although it does seem to change the pixel format. It doesn't seem to be working as rgba in the kernel.
[23:24:29 CET] <kjy> This kernel, https://pastebin.com/ngKnwBkG, yields white. However, you would expect blue or red (depending on where alpha gets put)
[23:27:44 CET] <jkqxz> Why do you have any inputs at all?
[23:29:58 CET] <kjy> jkqxz: I'm just testing the waters. Normally I would be doing something with them.
[23:34:08 CET] <jkqxz> Oh, duh, stupid CL trap.  You need to write "(float4)(0.0f, 1.0f, 0.0f, 1.0f)".  Just "(0.0f, 1.0f, 0.0f, 1.0f)" is a comma expression which evaluates to 1.0f which then gets assigned to all four components of the float4.
[23:35:19 CET] <jkqxz> Works for me with that fixed.
[23:38:13 CET] <kjy> jkqxz: Oh wow, thanks for that. I guess I should've spent more time reading CL tutorials.
[23:38:55 CET] <kjy> jkqxz: It *seemed* straightforward so I got ahead of myself.
[00:00:00 CET] --- Mon Nov 19 2018

More information about the Ffmpeg-devel-irc mailing list