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

Sat May 25 03:05:01 EEST 2019

[00:00:28 CEST] <Shezi> Ok let me grab you the local file output test.
[00:07:47 CEST] <Shezi> I am running it for a min
[00:10:44 CEST] <Shezi> cehoyos, https://pastebin.com/Mxjdxiwz
[00:10:51 CEST] <Shezi> Here is local file output with verbose
[00:11:14 CEST] <cehoyos> 6529 seeks
[00:11:22 CEST] <cehoyos> Yes, that's a lot
[00:11:34 CEST] <cehoyos> There is no option to increase a buffer (to avoid the seeks)
[00:11:43 CEST] <cehoyos> You can only change a constant in the source file:
[00:12:11 CEST] <cehoyos> IO_BUFFER_SIZE in libavformat/aviobuf.c
[00:12:25 CEST] <cehoyos> ... a lot for 100 seconds.
[00:15:25 CEST] <Shezi> cehoyos, what should be the IO_BUFFER_SIZE
[00:15:35 CEST] <Shezi> I mean I am having issue with file over http only.
[00:15:52 CEST] <cehoyos> Sorry, I don't understand
[00:16:35 CEST] <Shezi> I am having issue with this kind of file streaming over http. You have seen both outputs , local file and over http.
[00:16:51 CEST] <Shezi> What can I do to resolve this issue for http?
[00:16:52 CEST] <cehoyos> Or are you saying you are surprised that seeking locally on your harddrive is fast while seeking via http is slow?
[00:17:13 CEST] <Shezi> No that's normal of course.
[00:17:21 CEST] <cehoyos> Did you already try to increase IO_BUFFER_SIZE (as there is no option to do this at runtime)?
[00:17:41 CEST] <Shezi> No I didn't but what is a good value for IO_BUFFER_SIZE?
[00:17:50 CEST] <cehoyos> I have no idea
[00:18:55 CEST] <Shezi> Why the same file If I copy streams to another output file with same extension works fine on http.
[00:19:21 CEST] <cehoyos> Just run the new file locally with -loglevel verbose and see if there is any visible difference
[00:19:44 CEST] <cehoyos> in the last line of the console output
[00:23:00 CEST] <Shezi> Ok I can check. Seems I will be writing some new encoders soon after spending time here :D
[00:26:45 CEST] <Shezi> cehoyos, one quick question. While streaming from http, you might have seen >> [tcp @ 0x3be5bc0] Starting connection attempt to 95.216.102.150 port 443.2kbits/s speed=0.386x
[00:27:06 CEST] <Shezi> It repeats again and again. Is it for seeking?
[00:27:31 CEST] <cehoyos> I don't have a better suggestion
[00:28:00 CEST] <Shezi> Ok, I can try with IO BUFFER SIZE
[05:09:55 CEST] <christo_m> hello
[05:10:18 CEST] <christo_m> im wondering if its possible to use force_original_aspect_ratio inside the -filter_complex option, but i can't seem to figure it out
[05:10:46 CEST] <christo_m> -vf "scale=1280:1280:force_original_aspect_ratio=decrease,pad=1280:1280:(ow-iw)/2:(oh-ih)/2,setsar=1" im trying to replicate this inside -filter_complex, because im unable to use both vf and filter_complex without errors.
[05:19:44 CEST] <christo_m> oh
[05:20:02 CEST] <christo_m> is there a slack or discord or something?
[05:20:41 CEST] <CounterPillow> no
[05:20:49 CEST] <CounterPillow> but there is a mailing list
[05:21:18 CEST] <TheAMM> I heard rumors about an IRC channel, too
[05:36:18 CEST] <christo_m> TheAMM: right. im in it.
[05:36:38 CEST] <christo_m> but i guess out of the 700 people here nobody is active to help?
[05:41:08 CEST] <TheAMM> There's just around 450
[05:42:42 CEST] <christo_m> oh that must be why
[05:56:59 CEST] <TheAMM> http://ffmpeg.org/ffmpeg.html#Examples has some -filter_complex examples
[05:57:16 CEST] <TheAMM> Here's me, doing the work of seven hundred
[05:57:59 CEST] <christo_m> well done, you've linked me to the manual that I've already perused
[05:58:09 CEST] <christo_m> unfortunately what I'm describing is shown there.
[05:58:17 CEST] <christo_m> isn't*
[05:58:51 CEST] <christo_m> -filter_complex "[1:v]scale=1280:-1[bg];[bg][2:v]overlay=(main_w-overlay_w) - 10:(main_h-overlay_h) - 20" this is about as close as i got.
[05:58:58 CEST] <christo_m> tried with :-2[bg] as well
[05:59:14 CEST] <christo_m> doesn't give me what  -vf "scale=1280:1280:force_original_aspect_ratio=decrease,pad=1280:1280:(ow-iw)/2:(oh-ih)/2,setsar=1" gives me though.
[05:59:38 CEST] <christo_m> i thought i could just put the same "scale=" as the vf flag. but it doesn't like "force_original_aspect_ratio"
[06:41:46 CEST] <furq> christo_m: what do you mean by "doesn't like"
[06:41:50 CEST] <furq> that should work fine
[10:05:50 CEST] <inna> hi
[10:06:06 CEST] <inna> is there a way to automatically stop capturing after say 60 minutes?
[10:07:26 CEST] <furq> inna: -t 60:00
[10:07:56 CEST] <inna> purfect! thanks and have a nice day!
[11:46:39 CEST] <Redfoxmoon> attempting to convert a concatenated VOB image to mpeg and ffmpeg is spewing out thousands of [mpeg @ 0x74e0fc0] buffer underflow st=0 bufi=52915 size=64680 with various sizes
[11:46:45 CEST] <Redfoxmoon> is my ffmpeg borked
[13:30:05 CEST] <sruli> hi, i am trying to speed up a 34 minutes video but the output file size is huge it seems like its taking the same space as if it would have been the full 34 minutes. i am using "ffmpeg -i in.MP4 -filter_complex "[0:v]trim=0:2012,setpts=0.10*PTS[v];[0:a]atrim=0:2012,atempo=1.25,atempo=2.0,atempo=2.0,atempo=2.0[a];" -map '[v]' -map '[a]' -c:v libx264 -crf 26 -c:a aac out.mp4"
[13:51:41 CEST] <BtbN> crf 26 is already relatively bad quality
[13:52:20 CEST] <BtbN> How huge is huge?
[13:52:34 CEST] <BtbN> If it's a high motion video, it just is gonna be larger to look good
[13:53:37 CEST] <sruli> its ~550MB
[13:54:01 CEST] <sruli> it ends as a ~3 minute clip but 550MB
[13:54:10 CEST] <sruli> it is high motion
[13:54:25 CEST] <sruli> but 550MB, something is not right
[13:54:33 CEST] <durandal_1707> no, speeding things up, will not reduce size
[13:54:43 CEST] <BtbN> Looking at your filters, it might end up with the full original frames, just at a super high framerate
[13:54:47 CEST] <BtbN> so size won't change indeed
[13:55:10 CEST] <BtbN> You'll want to throw in a fps filter into the video, to drop frames
[13:55:12 CEST] <sruli> i also tried adding "-r 60" didnt help
[13:55:29 CEST] <durandal_1707> -r 60 is huge
[13:56:20 CEST] <sruli> i tried fps=fps=60 but same, yes 60fps is big, but a regular 3 min video i export with libx264 and 60fps is not 550MB
[13:56:39 CEST] <bencoh> 3mn or 34mn?
[13:57:06 CEST] <sruli> i am speeding up a 34 minutes vid, end clip = ~3min 550MB
[13:57:09 CEST] <BtbN> You're getting more like 1000 FPS or something with your current approach
[13:57:15 CEST] <bencoh> ah
[13:57:22 CEST] <durandal_1707> sruli: fps filter needs to be last
[13:57:30 CEST] <sruli> i tried fps=fps=60 that did not make a difference
[13:57:37 CEST] <BtbN> You did it wrong then
[13:57:49 CEST] <durandal_1707> last in filtergraph
[13:59:07 CEST] <sruli> i just tried "[0:v]trim=0:2012,setpts=PTS/10,fps=fps=60[v]" smae redult
[13:59:54 CEST] <BtbN> Have you verified it works?
[13:59:56 CEST] <sruli> output before i cancelled "frame=  187 fps= 19 q=34.0 size=    5888kB time=00:00:03.00 bitrate=16035.5kbits/s speed=0.298x"
[14:00:11 CEST] <BtbN> That's the encoding speed
[14:00:35 CEST] <sruli> 3 seconds almost 6MB is same as output i had before adding the fps filter
[14:01:01 CEST] <sruli> this is the actual output file details "size=    5888kB time=00:00:03.00"
[14:01:47 CEST] <sruli> i am using ffmpeg version 3.4.6-0ubuntu0.18.04.1
[14:04:00 CEST] <sruli> any ideas?
[14:05:48 CEST] <durandal_1707> no ideas here, use latest ffmpeg and post full uncut ffmpeg command & output via pastebin or similar
[14:07:05 CEST] <sruli> hmmm, if i remember correctly from a few years ago to install latest build is not s quick proccess, still the same?
[14:07:23 CEST] <furq> sruli: https://www.johnvansickle.com/ffmpeg/
[14:43:50 CEST] <sruli> will check that now, thanks
[15:15:46 CEST] <sruli> BtbN: I am using latest version from johnvansickle.com, when i try with "fps=fps=60" on a 20 seconds segment speed up 10x the output is a 20 second clip only the first 2 seconds plays the remaining 18 seconds is static image, file size=7.2MB  terminal output https://termbin.com/34hx
[15:16:58 CEST] <durandal_1707> i guess you need to use settb before setpts? to adjust pts so they are not all the same, and just being dropped
[15:18:02 CEST] <sruli> BtbN: when i try with " -r 60" on the 20 seconds segment speed up 10x the output is a 2 second clip, file size=5.7MB  terminal output https://termbin.com/pq2m
[15:18:12 CEST] <sruli> that is still way to big for a 2 second clip
[16:41:01 CEST] <termos> it seems there's no way of getting the gop size out of the C api after opening the input? The codec_context->gop_size is always 12 which is the default, so it seems it's not set
[16:41:51 CEST] <DHE> that's correct for really old codecs, like mpeg2video
[16:44:14 CEST] <termos> it makes sense to not expose it in the API, there can be a lot of input streams that have no concept of GOP
[16:44:27 CEST] <termos> so I guess there's no way of getting it?
[16:45:04 CEST] <termos> well it would be nice if it was set for codecs where it makes sense
[16:50:38 CEST] <DHE> avcodec_alloc_context3(codec), where codec is not null, will initialize it will codec-specific defaults. how this is implemented varies a bit.
[16:51:10 CEST] <DHE> eg: libx264 sets a gop size of -1 which means the library's own gop default applies, which is something like 250 iirc
[16:54:39 CEST] <termos> hmm i see, so i guess the best way to find it out is to do some av_read_frame's and count distances between AV_PKT_FLAG_KEY flags
[16:56:04 CEST] <DHE> oh... I missed where you said "input". Yeah keyframe interval isn't something the decoder needs to know and it can vary
[16:56:45 CEST] <DHE> hell, H264 has a mode with no discrete keyframes (typically).
[16:57:28 CEST] <termos> that's true, the encoder producing the input could have done scentcut detection and whatever it wants
[22:42:00 CEST] <degenerate> uhhhh
[22:42:05 CEST] <degenerate> so i set: -threads 2
[22:42:07 CEST] <degenerate> and i get:
[22:42:14 CEST] <degenerate> ```cat /proc/$(pgrep ffmpeg)/status | grep Threads
[22:42:14 CEST] <degenerate> Threads:        38```
[22:42:23 CEST] <degenerate> why?
[22:43:22 CEST] <JEEB> where did you set it?
[22:43:45 CEST] <degenerate> on execution like: ffmpeg -threads 2  .... rest of command ...
[22:43:51 CEST] <JEEB> so in the beginning?
[22:43:53 CEST] <JEEB> before input
[22:44:06 CEST] <JEEB> that means you have configured the input decoding threads to 2
[22:44:19 CEST] <degenerate> yes before input.
[22:44:22 CEST] <degenerate> and: oh!
[22:44:27 CEST] <JEEB> I think htop if you enable the thread name showing will show you what those threads are
[22:45:10 CEST] <degenerate> so can i limit output threads too?
[22:45:13 CEST] <JEEB> yes
[22:45:23 CEST] <JEEB> after input come the encoder options for the output that comes
[22:45:25 CEST] <JEEB> (after)
[22:49:37 CEST] <degenerate> thanks
[23:11:35 CEST] <hans_> can i tell ffmpeg/showinfo to output in json or xml or something slightly easier to parse?
[23:12:37 CEST] <klaxa> ffprobe supports:
[23:12:38 CEST] <klaxa> >-print_format format  set the output printing format (available formats are: default, compact, csv, flat, ini, json, xml)
[23:13:21 CEST] <hans_> o/ long time no see
[23:13:45 CEST] <JEEB> yea, you shouldn't be using ffmpeg.c to get media information and parsing the output
[23:13:54 CEST] <JEEB> ffprobe has formatted output for that
[23:14:12 CEST] <JEEB> (you need -show_xxx for it to work, such as -show_streams or -show_packets)
[23:23:45 CEST] <hans_> what does pts: 1800 mean? http://paste.debian.net/plain/1082960
[23:24:13 CEST] <JEEB> pts is the presentation time stamp
[23:24:44 CEST] <hans_> i am confusion, what's the difference between pts and pts_time ?
[23:25:05 CEST] <JEEB> pts_time applies the time base to it so it becomes seconds
[23:25:14 CEST] <JEEB> pts is the actual value of the AVFrame I would guess?
[23:25:34 CEST] <JEEB> you get the same things from ffprobe's -show_frames
[23:26:17 CEST] <JEEB> ffprobe -of json -show_streams -show_frames -i blah.mp4 -vframes 20
[23:26:20 CEST] <shadoxx> Is anyone in here using AMD AMF hardware encoding on Linux?
[23:26:22 CEST] <JEEB> I think vframes worked with ffprobe?
[23:26:29 CEST] <JEEB> so you can get a glimpse of how it looks
[23:26:33 CEST] <hans_> gotcha, thanks (still not sure what an AVFrame is but i can google it)
[23:26:48 CEST] <JEEB> AVFrame is the internal API decoded frame structure
[23:27:07 CEST] <JEEB> as opposed to AVPacket which is something you read from a container
[23:27:33 CEST] <JEEB> like, when you read an mp4 file you get AVPackets with an index of the stream they come from, which you can then feed to a decoder for the format mentioned in the AVStream
[23:27:41 CEST] <JEEB> and the decoder would then output AVFrames :P
[23:28:25 CEST] <JEEB> ah no, vframes not a thing with ffprobe
[23:28:35 CEST] <JEEB> I need to check the ffprobe docs every time for this :P
[23:28:38 CEST] <JEEB> also for stream selection
[23:29:59 CEST] <JEEB> https://ffmpeg.org/ffprobe.html
[00:00:00 CEST] --- Sat May 25 2019