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

[burek]

[03:12:19 CEST] <jarred> can someone help me with the correct filter_complex incantation? https://gist.github.com/Jarred-Sumner/6e5a7c3eb80f7d01c0cd19fa04c55644
[06:39:14 CEST] <pk08> can anyone please correct CC error logic in libavformat/mpegts.c (https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mpegts.c#L2627)
[06:39:47 CEST] <pk08> because i see error msg in ffmpeg but not in other analyser
[06:40:27 CEST] <pk08> and ffmpeg shows CC error even when tss->last_cc == cc
[06:41:58 CEST] <pk08> and according to DVB standard H.222, tss->last_cc and cc can be same
[08:42:04 CEST] <dwqq> hello guys
[08:42:35 CEST] <dwqq> ffmpeg -f lavfi -i anullsrc -rtsp_transport tcp -i ${RTSP_URL} -tune zerolatency -vcodec libx264 -preset medium -crf 24 pix_fmt + -c:v copy -c:a aac -strict experimental -f flv ${YOUTUBE_URL}/${YOUTUBE_KEY} -nostdin -nostats 2> frames.log &
[08:43:22 CEST] <dwqq> i am using the command above to stream to youtube channel, how can i set 480p and remove sound?
[08:43:39 CEST] <dwqq> there is no sound at all
[10:43:08 CEST] <Radiator> Hi, does anybody knows what would be the equivqlent of this line : mpv --no-cache --untimed --no-demuxer-thread --vd-lavc-threads=1 udp://224.0.1.1:10001/
[10:43:27 CEST] <Radiator> using ffmpeg instead of mpv
[10:44:14 CEST] <JEEB> see what options mpv sets and mimic that
[10:44:29 CEST] <JEEB> also I think the untimed option just disables vsync, so it just reads as fast as possible
[10:47:20 CEST] <Radiator> Yeah that's what I saw from the documentation. The no-cache also forces goes alonf with no-demuxer-thread which helps to go even faster. The decoding on a thread helps too. I just can't figure out how to replicate that behavior with ffmpeg or ffplay
[12:29:56 CEST] <lain98> kepstin: because vfr
[12:30:28 CEST] <lain98> how does av_seek_frame/avformat_seek_file behave with vfr files ?
[12:30:46 CEST] <JEEB> just fine if the container is indexed
[12:31:01 CEST] <JEEB> like, you could just take the "VFR" part out of the equation
[12:31:08 CEST] <JEEB> like, if you have a horribly VBR MPEG-TS mux
[12:31:19 CEST] <JEEB> it will fsck your seeking up even without VFR
[12:31:36 CEST] <JEEB> which is why I have noted that indexing on the container level is the only way to get frame-exact results
[12:31:47 CEST] <lain98> ok but another problem. my application's purpose is to extract based on frame numbers
[12:31:49 CEST] <JEEB> you don't have to decode, just index on the container level which is mostly IO
[12:31:54 CEST] <JEEB> yes
[12:31:59 CEST] <JEEB> I wonder why you still haven't utilized ffms2
[12:32:11 CEST] <JEEB> that gives you access on frame level after indexing
[12:32:36 CEST] <lain98> theres a flag avseek_flag_frame which doesnt work for me in vfr
[12:33:07 CEST] <lain98> because i want to decode through my app
[12:33:29 CEST] <JEEB> ffms2 is a C++ library with A C API utilizing FFmpeg APIs
[12:33:32 CEST] <JEEB> so you can use it in your app, yes
[12:33:54 CEST] <JEEB> anyways, I think I'll stop at this point. I probably sound annoying as hell since you probably have a Very Good Reason not to look at ffms2
[12:48:25 CEST] <lain98> JEEB: will ffms allow me to use nvdec ?
[12:49:01 CEST] <JEEB> I don't remember; if not it sounds like contributing to it might be the less hard way out
[12:49:11 CEST] <JEEB> but what do I know
[12:51:13 CEST] <lain98> my only reason for not using ffms is perf
[12:51:45 CEST] <lain98> i did look into ffms source code
[12:52:11 CEST] <lain98> and they do a lot of stuff that i dont want to waste cycles for
[12:53:50 CEST] <JEEB> as far as I remember it's 99% I/O indexing rather than CPU cycles. CPU only comes up when decoding or if you have audio enabled at all
[12:54:16 CEST] <JEEB> but sure. in any case, enjoy implementing something that sounds very similar yourself
[13:23:01 CEST] <lain98> :(
[13:25:50 CEST] <sopparus> hello, im trying to restream a ts stream to m3u8, it mostly works
[13:25:55 CEST] <sopparus> but sometimes stutters
[13:25:57 CEST] <sopparus> i can see this
[13:25:59 CEST] <sopparus> [http @ 0x55a8355f0700] Will reconnect at 84386208 in 0 second(s), error=End of file.
[14:57:15 CEST] <sfan5> why can't ffmpeg handle 16384x16384 pngs?
[14:58:29 CEST] <Radiator> It could giving proper parameters. But that vary large!
[14:58:51 CEST] <durandal_1707> because it takes 4gb memory
[14:59:27 CEST] <sfan5> Radiator: unfortunately imgutils refuses to [IMGUTILS @ 0x7ffd5868a5c0] Picture size 16384x16384 is invalid
[15:00:37 CEST] <Radiator> Not suprising given the size of the picture
[15:01:59 CEST] <pink_mist> durandal_1707: why is it a problem that it takes 4GB of memory? with 64bit operating systems that's no longer a limit ... and most people these days will have quite a bit more available than that
[15:02:28 CEST] <DHE> it also means that any offset variables need to be 64 bit as well
[15:02:48 CEST] <durandal_1707> and it is fuzz problem
[15:03:27 CEST] <xdudi> after call this command: ffmpeg -i 'rtsp://....' -c:v copy -c:a copy -f rtp rtp://127.0.0.1:12345 I expected that ffmpeg will open a port but netstat doesn't show it. what did I wrong?
[15:03:28 CEST] <pink_mist> DHE: oh, you mean that PNG internal offsets are 32bit?
[15:03:48 CEST] <sfan5> uncommenting the "stride*(uint64_t)(h+128) >= INT_MAX" check in imgutils.c makes it work
[15:03:54 CEST] <Radiator> Where can I find a key / value list for av_dict_set ?
[15:03:55 CEST] <sfan5> though probably unsafe, since the check exists for a reason
[15:06:23 CEST] <DHE> pink_mist: no. I don't know about PNG internals...
[15:06:53 CEST] <DHE> pink_mist: but if you wrote something like "int offset = y*png->height + x;" you are in for a world of hurt as offset risks overflow
[15:07:48 CEST] <DHE> that's not literally how it works as a user of ffmpeg libs, but you could see how there could be a hidden bug somewhere when dealing with this stuff
[15:08:19 CEST] <pink_mist> yeah, I can
[16:20:34 CEST] <Radiator> A simple link to compile with the libav* should work right ? I installed ffmpeg, tried to just call avformat_alloc_context() with -lavformat but it doesn't link
[16:20:50 CEST] <Radiator> Using gcc
[16:21:13 CEST] <pink_mist> check the pkgconfig files
[16:21:57 CEST] <Radiator> Where would it be ?
[16:24:56 CEST] <pink_mist> you installed ffmpeg yourself, you should be able to check
[16:25:05 CEST] <pink_mist> I don't know how you installed it
[16:25:21 CEST] <Radiator> On ubuntu using apt-get
[16:25:58 CEST] <pink_mist> well then you probably didn't even install the dev stuff, which includes the pkgconfig files and the headers you need in order to link to it at all
[16:26:42 CEST] <another> pkg-config --path libavformat
[16:26:44 CEST] <Radiator> Oh ok. Is there a documentation where I could find how to do that ?
[16:27:40 CEST] <pink_mist> another: without the pkgconfig files even included, that'd do little to help
[16:27:48 CEST] <another> i know
[16:27:49 CEST] <pink_mist> Radiator: like I said, the dev stuff
[16:28:32 CEST] <pink_mist> Radiator: perhaps you should ask in an ubuntu help forum if you don't know where to find such things in ubuntu
[16:29:26 CEST] <Radiator> I'll figure it out, it's just that there's nothing in the documentation explaining how to configure or install the libs
[16:30:32 CEST] <pink_mist> you can't expect ffmpeg to have documentation for every single different linux distribution out there, or all the other operating systems ffmpeg works on
[16:30:44 CEST] <pink_mist> it's up to your linux distribution to do that shit
[16:32:16 CEST] <Radiator> I don't think it is about my distribution itself but more like a getting started for devs
[16:32:22 CEST] <pink_mist> I'm telling you it is, though
[16:32:55 CEST] <pink_mist> whether or not you believe me doesn't change reality
[00:00:00 CEST] --- Sat Sep  7 2019