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

Thu Jan 23 03:05:02 EET 2020

[03:18:25 CET] <gregorycu> "An email was sent to --- with a token to verify your new address. Please check your email and enter the token in the form below."
[03:18:34 CET] <gregorycu> I haven't got an email in 2 hours. Think something is busted.
[06:22:57 CET] <SirNapkin1334> hi, I want to update ffmpeg with apt-get, and launchpad.net reports that ffmpeg has pushed 4.2, however, apt-get still says that 3.4.6 is the newest version, even after sudo apt-get update
[06:28:28 CET] <kepstin> ah, you're using ubuntu bionic (18.04). ubuntu generally doesn't update to new major versions of ffmpeg within a release
[06:28:51 CET] <kepstin> you can either switch to a newer ubuntu release, or install it from elsewhere
[06:30:26 CET] <kepstin> fwiw, the only ubuntu version with ffmpeg 4.2 is focal, which hasn't even reached beta yet (comes out in april)
[08:39:18 CET] <void09> anyone here that can help me try to figure out why ffmpeg selects a video  segment (encoding, not -copy) with 1 frame difference given the same -to time , but different -ss time ? 1 frame extra at the end of one of the encodes
[09:37:28 CET] <vlt> void09: Can you show the command you used?
[09:37:34 CET] <void09> vlt: sure
[09:38:29 CET] <void09> ffmpeg -i "video.mkv" -ss 00:02:15.844 -to 00:02:16.845 -crf 0 1.mkv
[09:39:09 CET] <void09> this one produces the extra frame
[09:40:49 CET] <void09> wait no, reset
[09:41:12 CET] <void09> ffmpeg -i "video.mkv" -ss 00:02:15.844 -to 00:02:16.845 -crf 0 short.mkv <-  ends up at the correct frame
[09:41:29 CET] <void09> ffmpeg -i "vide.mkv" -ss 00:01:59.619 -to 00:02:16.845 -crf 0 long.mkv <-  ends up at +1 frames
[09:41:36 CET] <void09> video.mkv*
[09:42:14 CET] <void09> I can give the video link if you want to try
[09:46:59 CET] <termos> do I still have to subtract stream.start_time from every packet.pts when reading from UDP, since it can have a random start pts?
[10:39:49 CET] <lavaflow> how can I create a video from several image files without using a single -i and wildcards?
[10:40:00 CET] <lavaflow> using one -i for each image file doesn't seem to do what I want
[10:40:14 CET] <lavaflow> I assume there is a way to tell it to concat them all, but I'm not sure how to do that
[11:08:03 CET] <durandal_1707> lavaflow: see image2 demuxer documentation, assuming images are correctly numbered and same format and size
[11:08:34 CET] <lavaflow> durandal_1707: the images are not in alphanumerical order
[11:09:26 CET] <durandal_1707> thatn use multiple -i  and concat filter?
[11:20:47 CET] <funnybunny2> With avio_alloc_context, is a read function necessary as in the following example? I imagined ffmpeg could just read from the passed in buffer itself if no custom behavior is necessary https://ffmpeg.org/doxygen/trunk/avio_reading_8c-example.html#a22
[11:21:33 CET] <funnybunny2> In the above example, all the read does is memcpy into another buffer
[11:21:39 CET] <funnybunny2> *read function
[11:22:29 CET] <funnybunny2> What I'd like to know is whether avio_alloc_context(file_contents, file_size, 0, NULL, NULL, NULL, NULL); is wrong. I get a segfault, so I guess so
[11:31:00 CET] <lavaflow> is there a way to use the concat filter without specifying each input explicitly?
[11:48:03 CET] <funnybunny2> Sorry, I dced
[12:02:28 CET] <funnybunny2> Nevermind. It seems to work without a custom read function
[12:02:42 CET] <funnybunny2> I just forgot to allocate a format context
[12:54:07 CET] <BabySoda> guys how can i reduce the size of my gif while retaining sharp edges?
[12:54:37 CET] <BabySoda> i tried creating it using ffmpeg, and initially the file size was good, but the edges were all fuzzy
[13:00:22 CET] <durandal_1707> BabySoda: do you use palettegen and paletteuse?
[13:01:05 CET] <BabySoda> durandal_1707: er yeah, but i'm not sure if i did it correctly
[13:01:28 CET] <BabySoda> i mean its in my filter_complex flags, but...
[13:02:15 CET] <BabySoda> durandal_1707: and also, does the size of each frame PNG matter?
[13:02:31 CET] <BabySoda> (as in can it be too high res)
[13:02:53 CET] <BabySoda> at the moment each component frame is about 12K
[13:10:38 CET] <BabySoda> anyone know how to improve this/
[13:10:40 CET] <BabySoda> ?
[13:17:29 CET] <cehoyos> Please use pastebin or similar to provide the command line you tested together with the complete, uncut console output: FFmpeg is supposed to produce high-quality gifs
[13:25:07 CET] <BabySoda> cehoyos: oh, i got it working somehow :)
[13:25:19 CET] <BabySoda> oh wait, no i didn't
[13:26:13 CET] <BabySoda> for some reason when i use this command (https://dpaste.org/VJxp), the gif only uses like 7 of the frames before reseting
[13:27:20 CET] <BabySoda> cehoyos: any idea why that is?
[13:28:27 CET] <BabySoda> cehoyos: the output of ffmpeg -> https://dpaste.org/J53v
[13:29:06 CET] <BabySoda> ah it even sames frame=7 in that output
[13:29:13 CET] <BabySoda> but i don't know why though
[13:32:23 CET] <cehoyos> Please test current FFmpeg git head before requesting support here - you cannot scale pal8 input (you can but it produces the effects you see)
[13:32:51 CET] <durandal_1707> why you use reverse? it uses lot of memory
[13:35:22 CET] <BabySoda> what is pal8?
[13:35:30 CET] <BabySoda> is that related to why its only giving me 7 frames?
[13:36:01 CET] <BabySoda> durandal_1707: as in it takes ffmpeg longer to run?
[13:36:07 CET] <durandal_1707> pal8 is palette pixel format used internally
[13:36:19 CET] <durandal_1707> BabySoda: nope, more RAM
[13:36:26 CET] <BabySoda> durandal_1707: ah ok
[13:36:49 CET] <BabySoda> not really sure what that sentence means, "cannot scale pal8 input"
[13:37:09 CET] <BabySoda> also, why does ffmpeg output say 256 colors generated
[13:37:17 CET] <BabySoda> when my gif only has 2
[13:50:55 CET] <BabySoda> not sure what's going on tbh
[13:52:09 CET] <c_14> BabySoda: the palette you're generating is 16x16, i.e. it defines 256 colors
[13:52:37 CET] <BabySoda> c_14: ah, can i make it smaller?
[13:52:37 CET] <c_14> and for the pal8 thing, try putting a format=rgb filter before the scale filter
[13:52:40 CET] <BabySoda> 2x2?
[13:53:04 CET] <c_14> no point, gif uses a 256-color palette
[13:53:32 CET] <c_14> you can add max_colors=2 to the options for the palettegen filter if you want though
[13:53:47 CET] <c_14> that just sets all unused palette entries to black
[13:54:00 CET] <pink_mist> wouldn't 2x2 be 4 colours
[13:54:29 CET] <BabySoda> pink_mist: sure, but i thought maybe it has to be an nxn format
[13:54:47 CET] <BabySoda> pink_mist: also allows me to use more colors if i need
[13:55:07 CET] <BabySoda> c_14: do i just add 'format=rgb,scale=...'?
[13:55:13 CET] <c_14> yeah
[13:55:30 CET] <BabySoda> gives me 'invalid pixel format "rgb"'
[13:55:54 CET] <c_14> eeh, rgb24
[13:56:06 CET] <c_14> rgb0, rather
[13:56:19 CET] <c_14> though rgb24 would also work
[13:56:44 CET] <c_14> although, if your pngs have transparency you'll want rgba
[13:57:12 CET] <BabySoda> c_14: ah yeah they do
[13:57:16 CET] <BabySoda> let me try that
[13:58:12 CET] <BabySoda> c_14: thanks, i think that works, only problem is the gif still is only using 7 frames
[13:58:26 CET] <BabySoda> (even though the images/ directory has 100 images in it)
[13:58:52 CET] <c_14> probably the glob messing up, try using cat *.png | ffmpeg -f png_pipe -i pipe:0
[14:01:00 CET] <BabySoda> c_14: er now my gif is mostly a single color, with the other color in the edges
[14:01:11 CET] <BabySoda> is that a palette issue?
[14:01:18 CET] <c_14> sounds like it
[14:01:31 CET] <c_14> did you add the max_colors option? just remove it
[14:01:42 CET] <BabySoda> c_14: hadn't added that yet
[14:03:04 CET] <BabySoda> c_14: that's my command btw -> https://dpaste.org/8iES
[14:03:16 CET] <BabySoda> ah crap wait
[14:03:20 CET] <BabySoda> i think i know what i did
[14:03:42 CET] <BabySoda> c_14: my bad, all working now
[14:03:49 CET] <BabySoda> but still getting the 7 frames
[14:04:06 CET] <BabySoda> only now the gif shows each frame a lot faster
[14:04:44 CET] <c_14> does the ffmpeg output mention drop= somewhere?
[14:05:20 CET] <BabySoda> c_14: doesn't look like it
[14:05:52 CET] <BabySoda> c_14: can i have a filename like "my_first_frame.png"?
[14:06:01 CET] <BabySoda> can ffmpeg not handle underscores or something?
[14:06:17 CET] <c_14> nah, that should be fine
[14:06:32 CET] <c_14> is one of the frames a different format or resolution perhaps?
[14:06:45 CET] <c_14> or it might be the reverse filter?
[14:06:51 CET] <c_14> try removing the reverse filter and using tac instead of cat
[14:08:02 CET] <BabySoda> c_14: hmm that gives -> https://dpaste.org/8tKR
[14:08:17 CET] <BabySoda> "Cannot determine format of input stream 0:0 after EOF"
[14:08:28 CET] <c_14> zsh: no matches found: images/*.png
[14:08:35 CET] <BabySoda> ah crap
[14:08:43 CET] <furq> that's not how tac works
[14:09:01 CET] <c_14> wait, you're right
[14:09:08 CET] <c_14> you'd have to cat *.png | tac | ffmpeg
[14:09:21 CET] <c_14> can you just rename the files so the glob picks them up in the intended order?
[14:09:25 CET] <furq> ls -r * | xargs cat | ffmpeg
[14:09:40 CET] <c_14> or try that^ if you don't have spaces in the filenames
[14:09:54 CET] <BabySoda> c_14: i could, not it's not ideal
[14:10:36 CET] <BabySoda> hmm still getting 7 frames, but not the non-reversed frames
[14:11:00 CET] <BabySoda> c_14: these are composited .PNGs btw
[14:11:14 CET] <BabySoda> i.e. they .PNGs made from other PNGs, could that be why it's not working?
[14:11:21 CET] <BabySoda> *they are
[14:12:18 CET] <c_14> maybe
[14:12:30 CET] <c_14> if ffmpeg's png decoder doesn't like it
[14:12:41 CET] <BabySoda> what's odd is that the file sizes are oh these images are different
[14:12:53 CET] <BabySoda> for example the last 7 files are 21/21K, while the one before that is 14K
[14:13:02 CET] <furq> png is compressed
[14:13:16 CET] <BabySoda> furq: right but they should all be similar size
[14:13:48 CET] <BabySoda> i'll try removing the ones that are "outliers"
[14:13:54 CET] <furq> if they're only two colors then i wouldn't be surprised if there were big differences in compressibility
[14:14:23 CET] <BabySoda> furq: but if the contents of each PNG is very similar, that shouldn't cause these big differences right?
[14:15:50 CET] <c_14> BabySoda: if you try encoding without reversing the order, how many frames does it encode?
[14:15:53 CET] <BabySoda> c_14, furq: ok that worked, removing the "odd" images now fixes the frames
[14:16:38 CET] <furq> ffmpeg should be throwing an error somewhere if some of the files are broken
[14:17:02 CET] <BabySoda> doesn't seem to
[14:17:14 CET] <c_14> furq: don't think it does with the image2 demuxer
[14:19:37 CET] <BabySoda> c_14: i think i stitched these other PNGs together using imagemagick, should i do this with ffmpeg instead?
[14:22:51 CET] <c_14> if it works with that I guess
[14:37:42 CET] <BabySoda> c_14: ok that seems to work, i think i was doing something wrong with imagemagick to concat the PNGs
[14:38:09 CET] <BabySoda> c_14: would a faster cpu speed up this process of concatting images?
[14:38:25 CET] <c_14> it shouldn't be that cpu intensive
[14:38:34 CET] <c_14> so maybe, but probably not that much
[14:39:39 CET] <BabySoda> c_14: ah, is it more gpu dependent or something?
[14:40:08 CET] <c_14> it's probably mainly io and the scale filter
[14:40:12 CET] <c_14> which is single-threaded
[14:40:42 CET] <cehoyos> GPU is not involved
[14:41:00 CET] <BabySoda> c_14: ah i see, so if i wanted to speed up this process significantly, i would have to use a group of machines or something?
[14:41:16 CET] <BabySoda> each with the fastest single-threaded processor
[14:41:24 CET] <cehoyos> You would first have to check which part of the process takes time
[14:41:26 CET] <BabySoda> e.g. 9900K or something
[14:42:34 CET] <cehoyos> If your images always use the same colours, you could speed the process up by pre-calculating the palette and not using palettegen for all frames
[14:43:12 CET] <BabySoda> cehoyos: yeah they do use the same palette, like 4 colors max
[14:43:19 CET] <BabySoda> *the same colors
[14:43:33 CET] <cehoyos> It is likely that paletteuse is the cause for the slow encode, you cannot speed that up (only the other steps in the pipeline)
[14:44:30 CET] <BabySoda> is my palette stuff optimized with this command? https://dpaste.org/LORL
[14:44:47 CET] <BabySoda> do i have to generate the palette seperately or something?
[14:45:54 CET] <cehoyos> You can pre-calculate the palette to avoid running palettegen
[14:47:04 CET] <BabySoda> cehoyos: and i do that by running "ffmpeg -i frames/1.png -vf palettegen=16 palette.png"?
[14:49:17 CET] <cehoyos> I am not sure if limiting it to 16 has any advantage but yes
[14:49:47 CET] <BabySoda> and then i just add another "ffmpeg ... -i palette.png" and remove the palettegen from "...; [a] palettegen=resever_transparent=on:..."?
[14:50:06 CET] <cehoyos> and the split
[14:50:54 CET] <BabySoda> er what does "No output pad can be associated to link label 'b'" mean?
[14:51:51 CET] <furq> you don't need the split any more
[14:52:01 CET] <BabySoda> i removed it, but i still get that error
[14:52:14 CET] <BabySoda> do i have to remove [b] from that same part?
[14:52:23 CET] <BabySoda> or i remove [b] from the whole command?
[14:53:42 CET] <BabySoda> this is my command btw -> https://dpaste.org/WRzW
[14:54:29 CET] <BabySoda> i removed the "split" after "falgs=lanczos" and the palettegen before "reserve_transparent
[15:03:10 CET] <BabySoda> got it working by removing that section after flags=lanczos
[15:07:30 CET] <BabySoda> thanks for the help so far guys, really appreciate it
[16:19:01 CET] <SirNapkin1334_> thank you kepstin, out of curiosity, how can I switch to a new version of the ubuntu? both on WSL and on an actual linux installation, since I use both
[18:18:53 CET] <chaosblade> SirNapkin1334, in WSL its mostly just "sudo do-release-upgrade" iirc
[18:19:14 CET] <chaosblade> i never recall if thats a ubuntu thing in general or a WSL thing
[18:33:03 CET] <chaosblade> hmk, basic static binary with x264 and the other usual suspects compiled and working. Now to somehow hack nvidiot support in as non-static while maintaining the rest
[18:58:09 CET] <kepstin> do-release-upgrade is a general ubuntu thing, is how you do release upgrades on bare metal systems too.
[18:59:03 CET] <kepstin> If you're starting on an lts release like 18.04 it might need extra options to update to a non lts release
[19:00:07 CET] <chaosblade> iirc i had to just apt update/upgrade before it would let me jump to 19.04
[19:00:16 CET] <chaosblade> the message says that when you try anyway, so thats friendly enough
[19:00:40 CET] <chaosblade> you also need to edit a file somewhere between LTS and non-LTS upgradability, message points at that as well
[21:44:22 CET] <chaosblade> hm, looks like my issue is very much like this https://trac.ffmpeg.org/ticket/6431
[21:44:44 CET] <chaosblade> only neither of the first two workarounds seem to work these days
[21:44:54 CET] <chaosblade> maybe the way params flow to gcc changed a bit since
[21:46:57 CET] <cehoyos> Please paste a backtrace
[21:47:04 CET] <chaosblade> just about to
[21:58:46 CET] <chaosblade> ah damn, didn't keep the last ffmpeg_g binary, ill rebuild and see
[22:12:42 CET] <chaosblade> i'll have the rest up in a moment, but this is the last bit : #0  0x00007fffd35d01c1 in __GI__dl_allocate_tls_init (result=0x7fffd2d90700) at ../elf/dl-tls.c:465
[22:13:04 CET] <chaosblade> so seems like the known issue of static linking glibc breaking things? im not entirely sure
[22:23:44 CET] <cehoyos> You could test with musl which is better suited for static linking and faster
[22:29:50 CET] <chaosblade> thats an option, yeah. no experience with that toolchain at all though.
[00:00:00 CET] --- Thu Jan 23 2020