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

[burek]

[00:40:08 CEST] <mijofa> Output seeking will always take longer the further in your seeking. Output seeking processes the input from 0 up to the time you're seeking, and processing the input takes time. I have no idea why input seeking isn't working for you though, is there any pattern to what "half of the timesets" works and what doesn't?
[01:02:10 CEST] <chauffer> i haven't taken a close look yet mijofa, but i couldn't see any obvious error from the logs
[01:02:36 CEST] <chauffer> i think the fact it's a remote m3u8 file does not help
[01:06:02 CEST] <nicolas17> I have 4 videos I want to concatenate, but *one* of them is wider and I need to crop it; tips?
[01:06:59 CEST] <nicolas17> I could first crop the video into a temporary file and then use it in the concat, but... I'd rather not add yet another reencoding step
[01:09:01 CEST] <nicolas17> oh there's a concat filter
[04:48:37 CEST] <satoshi2> does anybody knows how to tell ffmpeg to stop skipping expired frames?
[04:48:44 CEST] <satoshi2> *skipping xxx segments ahead, expired from playlists
[04:48:57 CEST] <satoshi2> related question https://stackoverflow.com/questions/44732849/prevent-ffmpeg-from-skipping-expired-frames
[06:58:20 CEST] <garyserj> what is the difference between  ffmpeg -i blah.3gp  blah.mp4  vs  ffmpeg -i blah.3gp -c copy blah.mp4 ?
[07:35:59 CEST] <kerio> the difference is " -c copy"
[07:36:06 CEST] <kerio> about in the middle
[09:46:41 CEST] <garyserj> When you do ffmpeg -i blah.3gp  blah.mp4  vs  ffmpeg -i blah.3gp -c copy blah.mp4 ?  What is the difference e.g. if -c copy copies the same codecs then what does it do without them?
[09:48:06 CEST] <JEEB> garyserj: a default video/audio encoder is selected according to whatever someone decided ~10 years ago for that output container
[09:48:13 CEST] <JEEB> and you get random defaults, like 200kbps for video
[09:48:42 CEST] <JEEB> which is why you always want to define -c specifically. default is not "copy the streams"
[17:19:12 CEST] <Mia> I'm converting .gif files to .pm4 --- is it possible to convert them in a way that - if they're shorter than 5 seconds they'll be looped
[17:19:20 CEST] <Mia> (as many times as necessary to pass that treshold)
[17:35:52 CEST] <kepstin> Mia: do you want to make sure not to cut longer input files at 5s?
[17:36:10 CEST] <Mia> yes
[17:36:21 CEST] <Mia> so if a gif is longer than 5s already, don2t loop, just convert
[17:36:25 CEST] <kepstin> Mia: if so, you're going to have to write a script that checks the gif length in advance, then runs ffmpeg with different options depending on whether you want to loop it or not
[17:36:34 CEST] <Mia> if it's shorter than 5s, repeat it as many times as necessary
[17:38:02 CEST] <kepstin> (this is actually gonna be tricky all around, since I assume you don't want to cut the looped ones off in the middle of a loop either)
[17:38:18 CEST] <Mia> kepstin, mhm
[17:38:41 CEST] <Mia> what I do, currently, involves 3 steps
[17:38:48 CEST] <Mia> 1. create an mp4 from my gif
[17:38:53 CEST] <Mia> 2. check the length of the video
[17:39:06 CEST] <Mia> 3. loop and export it as many times as necessary to pass 5s
[17:39:16 CEST] <Mia> I do this in nodejs, but I'm wondering, if this is all possible with ffmpeg only
[17:39:39 CEST] <Mia> or, with a one liner, basically (does not have to be ffmpeg)
[17:52:39 CEST] <Delta706> Can I use ffmpeg to change a video to 4:3 aspect?
[17:55:37 CEST] <DHE> yes but there are decisions to be made
[17:57:29 CEST] <Delta706> So how can I do the conversion?
[18:32:12 CEST] <Bmber> Hi
[18:32:43 CEST] <Bmber> Simple question if anyone would have information on "bus errorXX"
[18:33:26 CEST] <Bmber> I have a lot of issue streaming and ffmpeg is always crashing with a bus error
[18:34:29 CEST] <Bmber> Here's my pastebin
[18:34:29 CEST] <Bmber> https://pastebin.com/a8Fj3HdQ
[18:35:57 CEST] <DHE> a "Bus error" is a memory access that is legitimate from the application standpoint but not serviceable by the OS. Eg: application gets partially swapped out to a USB stick, then you pull the USB stick out. attempting to swap in will instead result in SIGBUS
[18:38:22 CEST] <Bmber> hum
[18:40:03 CEST] <Bmber> Would if it be cause by not having swap memory on linux?
[18:43:09 CEST] <DHE> no...
[18:45:42 CEST] <furq> Bmber: SIGBUS is most likely caused by your input device
[18:45:47 CEST] <furq> that's about as much as i can tell you though
[18:46:02 CEST] <Bmber> ah ^ thats better
[18:46:02 CEST] <DHE> it might be a fault of the capture device. any other hardware issues should manifest in dmesg
[18:46:16 CEST] <Bmber> I'm using NDI
[18:46:34 CEST] <Bmber> it's seem to only appear when i'm using slow preset
[18:46:47 CEST] <Bmber> i'm at medium now and it look stable
[18:46:47 CEST] <DHE> then your CPU probably can't keep up with realtime
[18:46:57 CEST] <furq> that status line claims 1.03x
[18:46:59 CEST] <Bmber> 20% cpu usage :S
[18:47:05 CEST] <furq> yeah that's odd
[18:47:19 CEST] <Bmber> it's a ryzen 1700 so
[18:47:33 CEST] <Bmber> i should even be hable to 1080p60 medium / slow
[18:47:47 CEST] <Bmber> but i'm doing 720p60 atm
[18:48:03 CEST] <Bmber> because i had the same bus error on 1080p medium/fast
[18:48:34 CEST] <DHE> keep in mind ffmpeg itself is single-threaded. if the IO thread is bottlenecked you might still SIGBUS out even if there's excess CPU usage
[18:48:57 CEST] <Bmber> should i try -threads ?
[18:49:00 CEST] <ChocolateArmpits> Bmber, check against null output
[18:49:02 CEST] <DHE> I might suggest doing an output to "-f null /dev/null" and see how CPU is
[18:49:17 CEST] <Bmber> let me test
[18:49:20 CEST] <furq> just -f null - works
[18:49:26 CEST] <DHE> ah yes
[18:49:44 CEST] <ChocolateArmpits> there may be traffic congestion, stalling everything in line
[18:49:56 CEST] <furq> yeah i guess if it's a network output then that could be it
[18:50:39 CEST] <furq> i'm not sure if -rtbufsize works with that input device
[18:50:43 CEST] <furq> but it's worth trying that
[18:51:00 CEST] <Bmber> frame=  885 fps= 60 q=26.0 size=N/A time=00:00:15.69 bitrate=N/A speed=1.07x
[18:51:27 CEST] <ChocolateArmpits> Bmber, are you getting any errors now?
[18:51:36 CEST] <Bmber> i'll let it run couple minute
[18:51:40 CEST] <Bmber> i put it back to slow
[18:52:03 CEST] <Bmber> let's wait a bit :) i'll go smoke on
[18:52:07 CEST] <iive> i've heard that you can get bus error if you do unaligned access on systems that mandate it, e.g. arm. but on x86 sse unaligned access just causes segfault.
[18:52:37 CEST] <Bmber> i'm mining crypto at the same time but only gpu. cpu is not used
[18:53:21 CEST] <Bmber> and what i'm mining doesnt need OS memory. eveyrthing are on the gpu
[18:53:44 CEST] <DHE> but you are trying to capture video from the GPU, yes?
[18:53:50 CEST] <Bmber> no
[18:54:01 CEST] <Bmber> i'm capturing using NDI Input
[18:54:11 CEST] <Bmber> my gaming PC if doing NDI Output
[18:54:32 CEST] <Bmber> is*
[18:56:00 CEST] <Bmber> Bus error05 fps= 60 q=37.0 size=N/A time=00:05:06.06 bitrate=N/A speed=   1x
[18:56:10 CEST] <Bmber> i'll reboot my routeur between both
[18:58:34 CEST] <Bmber_> im back
[19:00:32 CEST] <Bmber_> Segmentation fault0 q=37.0 size=N/A time=00:02:12.58 bitrate=N/A speed=1.01x
[19:02:30 CEST] <Bmber_> yup keep crashing
[19:06:53 CEST] <Bmber_> i think i found the problem
[19:08:49 CEST] <iive> what is it?
[19:09:45 CEST] <Bmber_> need to overclock
[19:09:54 CEST] <Bmber_> if the image doesnt movce that much it's fine
[19:10:09 CEST] <Bmber_> but when it does, i see the cpu go to the roof
[19:10:17 CEST] <Bmber_> and eventually crash
[19:11:21 CEST] <furq> like i said you can try -rtbufsize if you're just getting short spikes of high cpu
[19:11:29 CEST] <furq> that's a bit of a bandaid though
[19:13:17 CEST] <Bmber_> 40% cpu usage slow 48fps.
[19:13:32 CEST] <Bmber_> rtbufsize will be hard since NDI using around 150mb
[19:32:51 CEST] <Bmber_> thanks for your help guys
[20:23:38 CEST] <GuiToris> hello, can ffmpeg auto rotate and crop images like these? https://ptpb.pw/dkKr
[20:27:09 CEST] <Ke> if you really mean images, perhaps you want imagemagick
[20:27:17 CEST] <Ke> or graphicsmagick
[20:28:11 CEST] <durandal_1707> Ke: please no
[20:28:30 CEST] <Ke> ?
[20:29:18 CEST] <durandal_1707> Ke: please do not promote imagetragic here
[20:29:27 CEST] <furq> GuiToris: by "autorotate" do you mean fix that image so it's correctly oriented
[20:29:36 CEST] <furq> because ffmpeg can't do that but i don't think im can either
[20:29:46 CEST] <furq> you can do it manually
[20:30:00 CEST] <Ke> durandal_1707: can you elaborate?
[20:30:25 CEST] <GuiToris> furq, ahh, I have about 600 images
[20:30:40 CEST] <furq> i take it they're all rotated differently
[20:30:54 CEST] <GuiToris> furq, yes, you're right
[20:30:59 CEST] <furq> fun
[20:31:02 CEST] <GuiToris> otherwise it would be easy :D
[20:31:04 CEST] <furq> i'm sure there is some tool that can do it but i couldn't tell you what
[20:31:06 CEST] <durandal_1707> Ke: https://imagetragick.com/
[20:31:56 CEST] <Ke> if it's just vulnerability, it's mostly software in general
[20:32:04 CEST] <Ke> and horrible coding practices
[20:32:17 CEST] <GuiToris> furq, photoshop has such tool but it would take hours. I still have to edit them one by one
[20:32:40 CEST] <GuiToris> but the background is empty, it's a transparent alpha channel
[20:32:58 CEST] <GuiToris> it would be easy for a software
[20:34:21 CEST] <ChocolateArmpits> GuiToris, photoshop has scripting
[20:34:32 CEST] <ChocolateArmpits> you can record and replay macros as well
[20:36:10 CEST] <GuiToris> ChocolateArmpits, would it be my job to write these scripts? I'm really bad at photoshop anyways, I just looked it up on the internet and I found this 'crop and straighten photos'
[20:36:30 CEST] <GuiToris> it isn't perfect, I don't know why, but it's much closer to straight than now
[20:36:55 CEST] <ChocolateArmpits> GuiToris, you can record macros aka actions
[20:37:03 CEST] <ChocolateArmpits> and then replay them in order recorded
[20:37:06 CEST] <ChocolateArmpits> https://helpx.adobe.com/photoshop/using/creating-actions.html
[20:37:14 CEST] <GuiToris> I'll take a look, thanks ChocolateArmpits
[20:37:15 CEST] <Ke> durandal_1707: do you dare to recommend running ffmpeg on hostile input?
[20:37:50 CEST] <Ke> I would not dare to do this for any software that is not specifically designed for this
[20:38:05 CEST] <Ke> sadly people still want to push things like webgl
[20:40:13 CEST] <kepstin> ffmpeg gets lots of help on untrusted input by people (in particular google, iirc?) who fuzz the inputs
[20:40:37 CEST] <Ke> I know, but it's afaik not primary design goal
[20:40:54 CEST] <Ke> I am watching chromium security every now and then
[20:41:21 CEST] <Ke> chromium also sandboxes
[20:41:41 CEST] <JEEB> anything taking in hostile input should be sandboxed and minimized as much as possible
[20:41:49 CEST] <kepstin> yeah, i'd expect anyone doing e.g. uploaded video processing (ala youtube) to sandbox the input ffmpeg
[20:42:05 CEST] <ChocolateArmpits> kepstin, there's even a bitstream filter for doing that https://ffmpeg.org/ffmpeg-bitstream-filters.html#noise
[20:42:13 CEST] <JEEB> in case of FFmpeg that would be to sandbox as well as possible + disable as many features as required per requirements
[20:42:20 CEST] <JEEB> or well
[20:42:26 CEST] <JEEB> to be honest this is basics for any software
[20:42:27 CEST] <JEEB> :P
[20:43:45 CEST] <Ke> almost everyone writes software thinking "I don't do untrusted inputs" then someone uses it for security
[20:44:01 CEST] <Ke> just like bash and dhcp
[20:44:13 CEST] <GuiToris> ChocolateArmpits, this seems very promising, let's see how it works, thank you for your help btw
[20:58:47 CEST] <GuiToris> ChocolateArmpits, I don't wanna count my chickens before they hatched but PS is doing a pretty decent job now... what a bummer that GIMP lags behind
[20:59:40 CEST] <ChocolateArmpits> GIMP is meant for home use
[20:59:51 CEST] <ChocolateArmpits> that's what I heard from the devs
[21:00:16 CEST] <ChocolateArmpits> so they aren't really interested in competing against commercial products
[21:00:23 CEST] <ChocolateArmpits> (a copout)
[21:07:03 CEST] <Ke> I would bet they were trying to scale your expectations to their resources
[21:07:18 CEST] <Ke> GIMP is not even managing to keep up with gtp
[21:07:20 CEST] <Ke> GTK
[21:09:08 CEST] <Ke> though world has shown that if you just make your product extensible and create your own appstore you will pile up tons of miscellaneous functionality in dubious surroundings
[21:10:08 CEST] <Ke> if someone wrote ffmpeg today, it had its own package manager
[21:10:16 CEST] <Ke> would have
[22:44:55 CEST] <SortaCore> fellas, I just converted a 1hr long, 16 kb/s, 22kHz mono WMA file to FLAC max compress level, and it's gone from 8.9mb to 175mb
[22:45:36 CEST] <SortaCore> I would guess if it's like a zip it'd not find much pattern to save with that tiny bitrate, but that's a bit excessive
[22:45:40 CEST] <SortaCore> anything I could have done wrong?
[22:45:42 CEST] <nicolas17> you converted a lossy, low-bitrate audio file to a lossless format and it *obviously* went up in size
[22:46:24 CEST] <SortaCore> I was expecting the bitrate to be lower, or maybe a bit higher, not nearly ten times the size
[22:46:40 CEST] <nicolas17> it's like converting a low-quality JPEG to PNG
[22:47:54 CEST] <SortaCore> lack of bytes would lower how many patterns you can find, yeah, but even without patterns it's that much larger to store the bytes as-is?
[22:49:16 CEST] <nicolas17> is it 8-bit or 16-bit?
[22:49:37 CEST] <SortaCore> 16-bit
[22:50:17 CEST] <SortaCore> "flac, 22050 Hz, mono, s32 (24 bit), 128 kb/s"
[22:50:30 CEST] <satoshi2> use aac lc
[22:50:33 CEST] <nicolas17> ah it got resampled to 24-bit FLAC
[22:50:37 CEST] <nicolas17> that explains why it's even larger than uncompressed!
[22:50:54 CEST] <SortaCore> dunno why it's 128 kb/s when input file is 16 kb/s
[22:51:09 CEST] <nicolas17> that's irrelevant
[22:52:24 CEST] <nicolas17> any reencoding will first decompress it (which will result in like 350kb/s) and then re-compress it, so the input bitrate is irrelevant to the output size
[22:53:15 CEST] <_Mike_C_> Hello again, I'm using the API to re-encode a video file.  I've gotten everything working correctly and I'm using the hevc_nvenc encoder.  I have the encoding context set to {4:3} aspect ratio but my output video is {16:9} can anyone explain the reason for this?
[22:53:24 CEST] <SortaCore> I read "FFmpeg's FLAC encoder supports sample bit depths of 16 and 24 bits, the latter padded to 32-bit."
[22:53:41 CEST] <SortaCore> why'd it boost to 24?
[22:53:58 CEST] <kepstin> SortaCore: the wma decoder probably outputs float samples
[22:53:59 CEST] <nicolas17> maybe because it's the default, you can probably set it to 16-bit with another option
[22:54:15 CEST] <nicolas17> but there's no way you'll get a FLAC smaller than the original *lossy* file anyway
[22:54:18 CEST] <Mavrik> _Mike_C_, anamorphic video?
[22:54:51 CEST] <_Mike_C_> Mavrik, It's originally 4:3
[22:55:38 CEST] <SortaCore> yea, I wouldn't expect it to be smaller, I'm just going to convert so I can demo the guy who asked me there's no point
[22:56:42 CEST] <SortaCore> just if I go back with 9x bigger he'll say I did it wrong >.>
[22:57:24 CEST] <nicolas17> again the input size is irrelevant, FLAC is designed to be smaller (while losing no quality) than the uncompressed WAV :)
[22:57:41 CEST] <kepstin> hey, the flac has to preserve all of the encoding artifacts added when the wma was encoded, that's hard work ;)
[22:57:50 CEST] <SortaCore> lol, I have the WAV too
[22:58:22 CEST] <nicolas17> if you have the WAV you should be using it as input to compress to FLAC, that way you don't have the WMA artifacts
[22:58:40 CEST] <SortaCore> yea, some files we have WAV too, some just WMA
[22:59:00 CEST] <SortaCore> I'm just demoing for the WMA ones, be more efficient to leave as is
[22:59:01 CEST] <_Mike_C_> the encoder is actually stretching the image to make it 16:9
[22:59:23 CEST] <_Mike_C_> I don't know if there are settings somewhere I'm unaware of that keep track of aspect ratio other than in the encoding context
[22:59:54 CEST] <kepstin> SortaCore: to avoid the 24bit stuff, you can use the -sample_fmt s16 output option. that'll make the flac a bit smaller, probably.
[23:00:03 CEST] <SortaCore> yea, I just tried that
[23:00:06 CEST] <SortaCore> manually setting as s16:22050 results in 93.4 mb, quite a bit better than 175mb...
[23:00:44 CEST] <nicolas17> cool, FLAC turned the original 151MB down to 93MB
[23:01:13 CEST] <SortaCore> nah, that's comparing the default 24-bit FLAC and the 16-bit FLAC
[23:01:41 CEST] <SortaCore> I'd compare to the WAV, but the WMA has worse settings like bitrate, mono, etc so it's not a fair comparison anyway
[23:01:54 CEST] <nicolas17> 1 hour * 22kHz * 2 bytes = 151MB
[23:01:58 CEST] <SortaCore> had to check which was made from which
[23:02:31 CEST] <SortaCore> (65 mins, strictly speaking, but I think my query is all sorted)
[23:02:39 CEST] <SortaCore> ciao
[23:02:43 CEST] <SortaCore> and thanks
[23:04:58 CEST] <_Mike_C_> Does anyone know about what factors affect output video aspect ratio aside from encoding context aspect ratio?
[23:13:11 CEST] <kepstin> _Mike_C_: well, the things that affect output video aspect ratio are 1. sample aspect ratio, and 2. video size in pixels.
[23:14:15 CEST] <kepstin> there's some weirdness with particular containers having overrides tho
[23:14:22 CEST] <_Mike_C_> kepstin: video pixel size is 640 x 480, aspect ratio 4:3, encoding ctx is 4:3... but with the output ratio is 16:9 any idea where to look to debug?
[23:14:27 CEST] <kepstin> and some old codecs not really supporting sample aspect ratio
[23:14:38 CEST] <kepstin> _Mike_C_: what's the sample aspect ratio set to?
[23:15:16 CEST] <kepstin> _Mike_C_: for that, it should be set to 1/1 (square pixels) to get the expected output
[23:15:52 CEST] <_Mike_C_> kepstin: Oh wow, ok I think I understand could you explain to me a bit more about how those values interact?
[23:17:00 CEST] <kepstin> video pixel size (width/height) * sample aspect ratio = display aspect ratio
[23:17:34 CEST] <_Mike_C_> Got it, thanks for the help!
[23:17:50 CEST] <nicolas17> are W, H, and SAR the only values stored in the file?
[23:17:59 CEST] <nicolas17> or is DAR stored too?
[23:18:28 CEST] <kepstin> nicolas17: depends on the format, some containers also store a dar value, and if it's set in the container, that's normally considered to override the stream's sar
[23:18:49 CEST] <kepstin> nicolas17: I think you can do that in mkv with some muxing tools, for example
[23:19:40 CEST] <kepstin> and sometimes not even the sar is stored (e.g. vob files from a dvd use an external indicator)
[23:19:56 CEST] <nicolas17> DVD SAR is stored in the .ifo?
[23:20:00 CEST] <_Mike_C_> kepstin: do you know how to set up the AVRational for frame rate to accurately get 29.97 fps instead of 30?
[23:20:15 CEST] <kepstin> _Mike_C_: you don't want 29.97 fps, you want 30000/1001 fps
[23:20:48 CEST] <nicolas17> 29.97 is rounded off, it's not the correct number :)
[23:21:28 CEST] <_Mike_C_> kepstin: can you explain the calculation a bit to get the 30000 and 1001 (so I could adjust if I wanted 15 or something)
[23:21:55 CEST] <kepstin> _Mike_C_: by defininition of the NTSC colour video standards, the field rate is 60 * 1.001
[23:22:03 CEST] <kepstin> er, sorry
[23:22:08 CEST] <kepstin> 60 / 1.001
[23:22:39 CEST] <kepstin> so adjust the 60 to whatever subdivision you're using for framerate, and multiply both sides of the fraction to get integers
[23:23:02 CEST] <_Mike_C_> Thank you so much
[23:23:37 CEST] <ChocolateArmpits> you can just input "ntsc" https://ffmpeg.org/ffmpeg-utils.html#Video-rate
[23:24:22 CEST] <ChocolateArmpits> though that won't get you 60hz
[23:24:32 CEST] <kepstin> that doesn't work if you're just programmatically filling in an AVRational, but I suppose you could call the parser from the utils functions
[23:31:56 CEST] <_Mike_C_> Sorry for the abundance of questions, I'm just excited to be getting real answers.  If I'm streaming a video to a UDP address, do I have to manually insert sleeps to achieve the correct output rate?
[23:36:26 CEST] <furq> _Mike_C_: if you're streaming from a file over a network then use -re
[23:36:47 CEST] <_Mike_C_> I'm doing it programatically, not using command line
[23:39:18 CEST] <furq> http://www.ffmpeg.org/doxygen/trunk/ffmpeg_8c_source.html#l04127
[23:39:24 CEST] <furq> that's how ffmpeg does it
[23:39:32 CEST] <JEEB> _Mike_C_: if your input is a file, yes
[23:39:44 CEST] <JEEB> as in, lavf+lavc will do their stuff as fast as they can
[23:40:09 CEST] <JEEB> you will have to synchronize the chain in some way to do the timing
[23:41:20 CEST] <_Mike_C_> thank you guys for the help, have a great day
[00:00:00 CEST] --- Wed Sep  5 2018