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

Wed Jan 22 03:05:02 EET 2020

[00:00:27 CET] <cehoyos> SirNapkin1334: See https://ffmpeg.org/download.html "Linux static builds"
[00:46:19 CET] <DHE> SirNapkin1334: there's a shell builtin command called `hash` which bash uses to remember where binaries are for future runs. you'll need to flush its cache
[01:10:02 CET] <SirNapkin1334> DHE thanks, coming back later and having closed the shell earlier, it now works
[01:16:38 CET] <DHE> that also works
[01:16:45 CET] <DHE> :)
[08:56:01 CET] <void09> anyone here that can help me try to figure out why ffmpeg cuts a video with 1 frame difference given the same -to time , but different -ss time ?
[08:56:14 CET] <void09> 1 frame difference at the end, of course
[11:50:55 CET] <BabySoda_> WHO HERE?
[13:00:29 CET] <cybex1> hi all. I am trying to stream my USB camera to network multicast (udp) using `ffmpeg -i /dev/video4 -s 1280x720 -r 30 -g 60 -f mpegts udp://238.0.0.1:5000` but the quality is absolutely shite. Imagine a 256k modem with interference streaming a 144p video. I am using 5G wifi for this. Any idea why this is happening?
[13:01:36 CET] <JEEB> you did not set any encoding parameters and wondering why you're getting something weird?
[13:02:00 CET] <JEEB> you only said that you want MPEG-TS and over UDP
[13:02:09 CET] <JEEB> and that your GOP an frame rate and video size are set
[13:02:23 CET] <JEEB> everything else is some automagic logic, which can be mpeg-2 video with 200kbps :P
[13:02:52 CET] <JEEB> you should preferably set the encoder you want to utilize, and the required minimum settings for that
[13:03:43 CET] <JEEB> and yea, default video encoder for MPEG-TS is MPEG-2 Video and that most likely defaults to 200kbps
[13:03:46 CET] <JEEB> :)
[13:03:51 CET] <cybex1> Hi JEEB. Let me explain. I have a Intel RealSense D435 USB camera, and I want to get the RGB feed broadcasted over the network. To do this, I have a Raspberry Pi 4 with 5G capability.
[13:03:59 CET] <JEEB> default audio encoder is mp2 audio
[13:04:04 CET] <cybex1> The raspberry pi has hw encoding ability
[13:04:15 CET] <cybex1> I thus used the following to recompile ffmpeg:
[13:04:31 CET] <cybex1> but in short, I added OMX and enabled MMAL in my configuration
[13:04:46 CET] <furq> you need to actually specify that you want to use mmal and omx
[13:04:50 CET] <cybex1> ffmpeg setup script: https://pastebin.com/ci3KVqRc
[13:04:58 CET] <cybex1> yeah, so I tried omx and mmal
[13:04:58 CET] <JEEB> in general: don't let FFmpeg pick your encoder and at the very least know what parameters your encoder needs at the very least
[13:05:03 CET] <cybex1> the problem is:
[13:05:15 CET] <JEEB> -c:v encoder_name , and the parameters needed depend on the encoder
[13:05:22 CET] <JEEB> -c:a for audio
[13:05:39 CET] <cybex1> I kept getting this error:
[13:05:39 CET] <cybex1> [video4linux2,v4l2 @ 0x1be1210] Cannot find a proper format for codec 'h264' (id 27), pixel format 'yuv420p' (id 0) Assertion *codec_id != AV_CODEC_ID_NONE failed at src/libavdevice/v4l2.c:811
[13:05:41 CET] <cybex1> when using:
[13:05:48 CET] <cybex1> ffmpeg -f v4l2 -c:v h264_mmal -pix_fmt yuv420p -i /dev/video4 -s 1280x720 -r 30 -c:v h264_omx -b:v 4000k -f mpegts udp://0.0.0.0:5000
[13:05:56 CET] <cybex1> testing with local streaming only^
[13:06:09 CET] <cybex1> this is where I described my problem
[13:06:09 CET] <cybex1> https://superuser.com/questions/1518680/stream-intel-realsense-camera-feed-to-networking-using-raspberry-pi-4-with-ffmpe
[13:06:10 CET] <furq> does your webcam support h264
[13:06:23 CET] <cybex1> uhm...
[13:06:29 CET] <cybex1> *how do I check that*
[13:06:31 CET] <furq> v4l2-ctl --list-formats
[13:06:32 CET] <cybex1> xD
[13:06:39 CET] <cybex1> oh right
[13:06:42 CET] <cybex1> sec
[13:07:02 CET] <cybex1> my video feed: v4l2-ctl --list-formats -d /dev/video4
[13:07:06 CET] <cybex1> ioctl: VIDIOC_ENUM_FMT
[13:07:06 CET] <cybex1> 	Type: Video Capture
[13:07:06 CET] <cybex1> 	[0]: 'YUYV' (YUYV 4:2:2)
[13:07:06 CET] <cybex1> 	[1]: '' (36315752-1a66-a242-9065-d01814a)
[13:07:28 CET] <cybex1> so my pix_fmt I set to yuv420p which seemed to work with libx264 sw encoder
[13:07:36 CET] <cybex1> but got my CPU up to 100% usage
[13:08:51 CET] <JEEB> because the default is preset medium and you're on an ARM box, yes
[13:08:59 CET] <cybex1> yup
[13:09:00 CET] <cybex1> armhf
[13:09:06 CET] <furq> not sure why that list is so truncated
[13:09:15 CET] <furq> try ffmpeg -f v4l2 -list_formats all -i /dev/video4
[13:09:20 CET] <furq> (also use a pastebin)
[13:09:27 CET] <cybex1> oh
[13:09:28 CET] <cybex1> sec
[13:09:32 CET] <cybex1> getting pastebin redy
[13:11:05 CET] <cybex1> well that is quite alot
[13:11:05 CET] <cybex1> https://pastebin.com/aM8h2BDj
[13:11:58 CET] <cybex1> also, not sure if this will help at all
[13:11:58 CET] <cybex1> pi at raspberrypi:~ $ v4l2-ctl --list-devices
[13:11:58 CET] <cybex1> bcm2835-codec-decode (platform:bcm2835-codec):
[13:11:58 CET] <cybex1> 	/dev/video10
[13:11:58 CET] <cybex1> 	/dev/video11
[13:11:58 CET] <cybex1> 	/dev/video12
[13:11:59 CET] <cybex1> Intel(R) RealSense(TM) Depth Ca (usb-0000:01:00.0-2):
[13:11:59 CET] <cybex1> 	/dev/video0
[13:12:00 CET] <cybex1> 	/dev/video1
[13:12:00 CET] <cybex1> 	/dev/video2
[13:12:01 CET] <cybex1> 	/dev/video3
[13:12:01 CET] <cybex1> 	/dev/video4
[13:12:02 CET] <cybex1> 	/dev/video5
[13:12:14 CET] <cybex1> (for clarity)
[13:12:54 CET] <furq> not sure what's going on with "unsupported" but i've never really used v4l2 much
[13:13:05 CET] <cybex1> :|
[13:13:11 CET] <furq> either way -f v4l2 -input_format yuyv422 -i /dev/video4
[13:13:14 CET] <cybex1> thanks for the help though :)
[13:13:16 CET] <furq> and then the output args as you had before
[13:13:21 CET] <furq> should work ok on a pi 4
[13:13:28 CET] <furq> assuming this webcam does usb3
[13:13:33 CET] <cybex1> yup
[13:13:41 CET] <cybex1> has usb3 (usb type c calbe)
[13:15:47 CET] <cybex1> well, when using ffplay udp://238.0.0.1:5000 (streaming address), I get alot of errors, not sure if this means something but I see alot of `ac-tex damaged at`, `Warning MVs not available` and `invalid cbp -4 at`
[13:16:03 CET] <cybex1> google doesn't provide that much assistance, thoughts on this?
[13:16:46 CET] <cybex1> pastebin of ffplay: https://pastebin.com/tNYvmh7W
[13:16:50 CET] <JEEB> just means that the decoder cannot properly decode it right away. if that says, then you might have issues
[13:16:58 CET] <JEEB> but if it is until you get a rnadom access picture, then it's OK
[13:17:09 CET] <furq> Stream #0:0[0x100]: Video: mpeg2video (4:2:2) ([2][0][0][0] / 0x0002)
[13:17:10 CET] <furq> uh
[13:17:14 CET] <JEEB> just the decoder complaining that before you get a random access picture, it cannot properly decode the images (d'uh)
[13:17:16 CET] <cybex1> I get a picture, but then I get a helluva log of them
[13:17:32 CET] <JEEB> furq: means he didn't specify an encoder :)
[13:17:40 CET] <JEEB> since mpeg2video is the default for mpeg-ts
[13:17:42 CET] <furq> yeah i meant the output args with h264_omx
[13:18:03 CET] <furq> and add -pix_fmt yuv420p as an output option
[13:18:50 CET] <cybex1> so, I should try -c:v h264_omx (after inpuit file option for encoder setting) and add -pix_fmt yuv420p after the encoder setting?
[13:19:35 CET] <cybex1> e.g. ffmpeg -f v4l2  -i /dev/video4 -c:v h264_omx -pix_fmt yuv420p -s 1280x720 -r 30 -g 60 -f mpegts udp://238.0.0.1:5000 ?
[13:19:38 CET] <cybex1> that look good?
[13:19:55 CET] <furq> yeah
[13:20:04 CET] <cybex1> well, trying that give a warning (in yellow) : [mpegts @ 0x1f22e20] Non-monotonous DTS in output stream 0:0; previous: 0, current: 0; changing to 1. This may result in incorrect timestamps in the output file.
[13:20:09 CET] <cybex1> not sure if that is good or bad
[13:20:15 CET] <furq> you probably also want -input_format yuyv422 -video_size 1280x720 as input options
[13:20:40 CET] <furq> you can normally ignore non-monotonous dts errors
[13:20:52 CET] <furq> unless the output is actually broken obviously
[13:21:04 CET] <cybex1> trying that, seems like ffplay doesn't like that:
[13:21:18 CET] <cybex1> using: ffmpeg -f v4l2 -input_format yuyv422 -video_size 1280x720 -i /dev/video4 -c:v h264_omx -pix_fmt yuv420p -s 1280x720 -r 30 -g 60 -f mpegts udp://238.0.0.1:5000
[13:21:24 CET] <cybex1> output of ffplay:
[13:22:03 CET] <cybex1> https://pastebin.com/XWjB0PEx
[13:22:11 CET] <cybex1> see the middle of the output, some warning:
[13:22:31 CET] <cybex1> Could not find codec parameters for stream 0 (Video: h264 ([27][0][0][0] / 0x001B), none): unspecified sizeConsider increasing the value for the 'analyzeduration' and 'probesize' options
[13:22:41 CET] <cybex1> should I change the analyzeduration and probesize?
[13:33:34 CET] <squ> what is omx?
[13:34:10 CET] <cybex1> openmax libraries used for accessing hardware encoding ability of devices
[13:34:16 CET] <squ> thanks
[13:34:24 CET] <cybex1> Want to use OMB-RPI for my raspbery pi 4
[13:34:27 CET] <cybex1> but having trouble with that
[13:36:55 CET] <funnybunny2> I'm using avformat_open_input(&format_context, argv[1], NULL, 0) to read a file from disk. How do I read from a buffer in memory instead?
[13:37:32 CET] <funnybunny2> (Assuming I have char *file_contents containing the file contents)
[13:39:28 CET] <funnybunny2> The Doxygen search is not very good.
[13:41:43 CET] <funnybunny2> Is there just like a function that takes a pointer to a buffer and size instead?
[13:52:01 CET] <c_14> funnybunny2: https://ffmpeg.org/faq.html#I-have-a-file-in-memory-_002f-a-API-different-from-_002aopen_002f_002aread_002f-libc-how-do-I-use-it-with-libavformat_003f
[13:52:17 CET] <funnybunny2> I hope this is the current way: https://ffmpeg.org/doxygen/trunk/avio_reading_8c-example.html#a22
[13:54:37 CET] <funnybunny2> c_14: Thanks
[13:54:58 CET] <funnybunny2> Going through the ffmpeg docs, it's not very clear sometimes what is an internal function and what is an API function
[14:01:52 CET] <funnybunny2> Why is there an av_malloc when there is already malloc?
[14:02:26 CET] <funnybunny2> Why is there an av_file_map when there are already functions like fgets and read?
[14:03:04 CET] <funnybunny2> I guess these functions are meant to be internal, but the examples use them, so it's confusing
[14:08:40 CET] <c_14> funnybunny2: av_malloc handles alignment afair
[14:08:57 CET] <c_14> funnybunny2: everything with an av_ prefix is public
[14:13:44 CET] <funnybunny2> c_14: OK, that's good to know. Thanks
[16:29:42 CET] <void09> anyone here that can help me try to figure out why ffmpeg cuts a video with 1 frame difference given the same -to time , but different -ss time ?
[16:29:43 CET] <void09> 1 frame difference at the end, of course
[16:39:10 CET] <JEEB> void09: look at result of -debug_ts which outputs all packets it handles? if your ss is different it might cause differing seeks? should be visible in the debug_ts output
[16:40:01 CET] <void09> well shouldn't be frame accurate if operating on a properly indexed mkv ?
[16:40:38 CET] <void09> it's only one frame off, but i found it happening two times in 3 minutes (in 2 scenes in the video)
[16:41:34 CET] <JEEB> depends on a whole lot of things so look at the demux+ffmpeg etc lines' differences in the output
[16:41:50 CET] <JEEB> also are you sure -tois not from the start pooint?
[16:42:20 CET] <JEEB> not that I know, you would have to check how ut us implemwnted
[16:42:31 CET] <void09> -ss 00:01:59.619	-to 00:02:16.845
[16:42:31 CET] <void09> -ss 00:02:16.845	-to 00:02:23.643
[16:42:56 CET] <void09> i have no idea myself , how it's implemented.
[16:43:12 CET] <JEEB> i don't have your files, i don't know the rest of your stuff and i am on a train :p
[16:43:23 CET] <void09> trying the debug thingie now
[16:43:31 CET] <JEEB> that is why i tell yputo look at diffwrences in debug_ts
[16:43:58 CET] <nicolas17> if -to was from the starting point set in -ss, then there would be no difference between -to and -t
[16:45:01 CET] <void09> how to redirect ffmpeg console output to file please ?
[16:45:12 CET] <void09> oh sorry nvm, you're on a train
[16:45:24 CET] <void09> phone typing sucks :)
[16:45:43 CET] <JEEB> yes, ut does
[16:48:42 CET] <void09> ok, got the logs.. now what
[16:56:34 CET] <friki> Hi, "ffmpeg ... -n -f tee a.mp4|b.mp4" does't seems to respect -n param. And efective overwrite ocurrs.
[17:07:24 CET] <cehoyos> I created ticket 8492
[17:09:30 CET] <friki> cehoyos: thanks!
[17:13:05 CET] <friki> cehoyos: may be -n should be added at the ticket
[17:29:38 CET] <cehoyos> The option "-n" is an option of the cli, ffmpeg. The tee muxer doesn't know about the cli, the question is if the current behaviour (forced overwrite) makes sense or if a new option should be created (not for ffmpeg but for the tee muxer) that allows overwriting
[17:35:58 CET] <friki> cehoyos: OK. In case of new "do not overwrite" option to 'tee' muxer it should be "linked" with -n option at the cli :-p
[17:36:27 CET] <friki> default is overwrite at cli, so current tee behavour is good for defaults
[17:40:07 CET] <nixonix> when i downloaded some videos with a browser addon (they showed as HLS, but they were pre-recorded, not live stream), the result was shown as h264/aac videos, but the sound was choppy every 4-5 seconds (i used VLC to watch)
[17:40:31 CET] <nixonix> is it possible to get rid of the choppiness by using ffmpeg somehow? or any other solutions?
[17:44:33 CET] <waleee-cl> nixonix:  if you can, try youtube-dl and try different format strings. Eg: youtube-dl -f audio[ext==opus]+bestvideo URL_HERE
[17:45:43 CET] <waleee-cl> * reservations for misstyped or miss-remembered syntax
[17:46:28 CET] <nixonix> its not youtube, i used video downloadhelper that gets them fine otherwise, but with those sound choppiness. (i tried VDH's conversion options too, but for sound only couple of choises of the long list - didnt help)
[17:47:30 CET] <waleee-cl> nixonix:  youtube-dl is a program that works on far, far more than just youtube
[17:48:04 CET] <waleee-cl> nixonix:  and it allows for more control over the downloaded formats
[17:49:31 CET] <nixonix> ok. still interested if those already downloaded files could be fixed afterwards, because there is no guarantee youtube-dl will work, and there might be endless list of different choises to try (like there is with conversion options if VDH)
[17:49:54 CET] <nixonix> ..of VDH)*
[17:52:53 CET] <nixonix> i noticed that converting them to mp4 straight in VDH (those videos then showed as mpeg4 / aac in ffprobe), the choppiness reduced a bit, but it was still there
[17:53:04 CET] <nixonix> i suspect some kind of sync problem, but not sure
[17:54:08 CET] <nixonix> and if it was a sync problem, there might be a solution to fix them afterwards, that would be a perfect solution
[18:12:26 CET] <nixonix> i made more tests. first, just downloading with VDH produced sound chops couple times a second (i remembered it wrong above), but when i converted them straight with VDH's convert options either to re-encoded h264/aac or to mp4, those sound chops only appeared every 4 or 5 seconds
[18:13:48 CET] <nixonix> without re-encoding, the result was also h264/aac, but there is option to re-encode it to the same format, and somehow that reduces the chops, but doesnt totally remove them (the result file only decreases by 20% for some reason, probably bit rate reduced)
[18:15:27 CET] <nixonix> converting them in VDH to avi (result is mpeg4/mp3 according to ffprobe) removes the sound problems, but the video quality reduces
[18:16:23 CET] <nixonix> now i tried to separate audio track from downloaded (choppy sound) videos - and it produced mp3 sound files with no chops
[18:17:32 CET] <nixonix> the next i will try to produce a vide file without sound, then create a file with non-problematic sound file and the video-only file together, and see how it goes
[18:18:17 CET] <nixonix> or just use ffmpeg to convert those straight, that should do the same, if i find the right way to use it...
[18:49:57 CET] <chaosblade> Hi all. I've been following the generic, ubuntu and nvidia guides to get a (static) ffmpeg binary with nvenc enabled. I'm on an Azure VM starting from a Ubunutu Data Science (fancy name for 18.04 LTS with 440.30 nvidia drivers and CUDA) image. No matter what i do, --enable-libnpp causes "libnpp not found using pkg-config".
[18:50:11 CET] <chaosblade> I'm suspecting a mismatch somewhere that im not picking up; Was anyone successful with that recently?
[18:51:24 CET] <BtbN> chaosblade, does nvidia even offer a static libnpp?
[18:51:42 CET] <chaosblade> That's why im putting static as an optional part here, i'll start with a dynamic one that builds and works
[18:52:01 CET] <chaosblade> i dont mind that part staying dynamic and requiring the CUDA toolkit/sdk as long as the rest of ffmpeg stays static
[18:52:08 CET] <BtbN> libnpp is also not part of just the driver. It needs the full CUDA SDK
[18:52:28 CET] <BtbN> And as long as libnpp is on the linker path, it will "just work"
[18:52:34 CET] <chaosblade> indeed, i followed nvidia's ffmpeg compile guide and installed the CUDA sdk as they supposedly say how to
[18:52:51 CET] <BtbN> Well, libnpp is in fact the only remaining thing needing the CUDA sdk
[18:55:07 CET] <BtbN> I'd say just use scale_cuda and call it a day.
[18:55:33 CET] <chaosblade> Probably. My main use case is just the nvenc parts, h264_nvenc etc
[18:55:38 CET] <chaosblade> so i can probably get by with that for now
[18:56:11 CET] <chaosblade> i also failed to get (--enable-)libass to work, but that might be the same reason of a broken/missing linker path
[18:56:30 CET] <chaosblade> that was an afterthought though, just because some of the other static builds ive been using include it, i don't do .ass subtitles anyway
[19:01:14 CET] <chaosblade> Anyhow, if anyone managed to get nvidia hwaccel'd ffmpeg building and running lately with libnpp, do let me know, please.
[19:01:48 CET] <BtbN> I can't see any reason why it wouldn't work.
[19:01:59 CET] <BtbN> Check the config log and see what fails, and fix the issue.
[19:02:16 CET] <chaosblade> Well, I'm suspecting something moved and their instructions mismatch with the actual versions on offer.
[19:02:39 CET] <BtbN> Don't suspect, check the log
[19:04:14 CET] <chaosblade> I did, gcc/linker not finding the three npp* libraries despite having an include and lib param that contains the right path to them. Leaves me a little confused.
[19:07:43 CET] <nixonix> videos downloaded from that site produce files that ffprobe say are h264/aac, but it seems they are not quite standard or correctly encoded (audio chops couple of times a second). when i re-encode them with ffmpeg to the same h264/aac, the results is less audio chops but there are still those, and ffmpeg gives errors like this:
[19:07:49 CET] <nixonix> "Number of bands (52) exceeds limit (42)." "decode_band_types: Input buffer exhausted before END element found" "Multiple frames in a packet." "invalid band type" "channel element 0.0 is not allocated" "Scalefactor (-1) out of range." "Prediction is not allowed in AAC-LC." "Scalefactor (-5) out of range."
[19:09:57 CET] <nixonix> video works then, but still audio is choppy. now only every 4 or 5 seconds. any way to adjust the parameters given to ffmpeg so that it would produce a result with no audio chops (i gave the audio and video bitrates that ffprobe told me)?
[19:13:28 CET] <chaosblade> without npp it builds and segfaults on using h264_nvenc, hm. more investigation required.
[19:13:35 CET] <BtbN> chaosblade, what's your configure line?
[19:14:26 CET] <chaosblade> currently, "configuration: --prefix=/home/USERNAME/ffmpeg_build --extra-cflags='-I/home/USERNAME/ffmpeg_build/include -I/usr/local/cuda/include' --extra-ldflags='-L/home/USERNAME/ffmpeg_build/lib -L/usr/local/cuda/lib64' --extra-ldexeflags=-static --pkg-config-flags=--static --bindir=/home/USERNAME/bin --disable-shared --enable-static --enable-gpl --enable-nonfree --enable-version3 --enable-libfreetype --enable-libmp3lame
[19:14:26 CET] <chaosblade> --enable-libfdk-aac --enable-libopus --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-cuda-nvcc --enable-cuvid --enable-nvenc"
[19:14:58 CET] <chaosblade> the cuda pathes are symlinks to cuda-10.2 in the same location, made by the cuda package installer nvidia points you at
[19:16:00 CET] <chaosblade> i need to check if my forcing of statics here is breaking something, it probably is.
[19:16:16 CET] <chaosblade> i.e. drop disable-shared first
[19:16:55 CET] <BtbN> The -static extra flag might prevent it from linking to shared libs
[19:18:01 CET] <BtbN> --disable-shared --enable-static has no effect on linking
[19:18:10 CET] <BtbN> it's the default even
[19:18:43 CET] <chaosblade> yeah, i think that was a copy-pasta error in my experiments from the actual static builds of other libs (where no -dev/-devel package with .a is provided)
[19:18:56 CET] <chaosblade> i seem to recall getting messages about those being ignored
[19:21:53 CET] <chaosblade> BtbN, yeah, that was it. now i have a lot of dynamic deps for vorbis, theora, etc tho. But that's progress at least, thanks.
[19:26:06 CET] <chaosblade> also, without --disable-shared, --enable-libnpp works as well
[19:26:21 CET] <chaosblade> which makes sense
[19:44:11 CET] <c_14> chaosblade: yeah, adding -static to the link flags disables dynamic linking. And if you want to link other deps statically except for cuda you'll have to edit the configure/pkg-config files to surround the deps with -Wl,-static -Wl,-no-static (or something like that)
[19:44:20 CET] <c_14> it's been a while since I last touched that
[19:51:43 CET] <cehoyos> I always (temporarily) remove the so files if I need static linking
[19:52:00 CET] <cehoyos> the so symlinks...
[20:09:20 CET] <LFSVeteran> I modified transcode_aac and now I get "Could not allocate output frame samples" (error 'Invalid argument')
[20:09:21 CET] <LFSVeteran> https://pastebin.com/zckjEhLw
[20:09:30 CET] <LFSVeteran> only the differences: https://pastebin.com/mWvGBrJE	
[20:49:07 CET] <nixonix> i got the sound work without chops by extracting the audio, then reattaching the extracted audio (using ffmpeg with both operations). but using either mp3 or aac for audio extract, the result was not not in sync, but audio was around 4-5% faster than video
[20:49:41 CET] <nixonix> so i should now try to get them combined with ffmpeg so they would be in sync, i wonder how...
[20:54:34 CET] <nixonix> there seems to be "-async" for that. i was looking for something to "stretch" the audio to the same time lenght than the video automagically, though...
[21:01:18 CET] <durandal_1707> nixonix: atempo filter
[21:10:08 CET] <nixonix> it seems it has changed, used to be -async, then i guess its atempo now. but it requires to calculate the length first, any way to make it automatically, if the start points are correct, so that it would either shrink or stretch the sound length to the same than the video?
[21:10:52 CET] <durandal_1707> nope, you need to calculate factor by hand
[21:11:16 CET] <nixonix> yeah. or by a script, but lets try by hand if it works
[21:34:05 CET] <nixonix> seems like the speed difference is around 24/25 fps or vice versa, like i have used to fix when resyncing subtitles... in fact the other one was not exactly 24 but slightly less, if i just could remember the exact number...
[21:35:03 CET] <nixonix> ah, probably that 23.976 (always wondered why not 24 but slightly under)
[21:43:51 CET] <klaxa> nixonix: https://www.youtube.com/watch?v=3GJUM6pCpew i think that's a good explanation
[21:44:18 CET] <klaxa> although it talks about 29.97 fps, this relates to the 23.976
[21:46:07 CET] <klaxa> the 23.976 is related to this: https://en.wikipedia.org/wiki/Three-two_pull_down
[21:49:42 CET] <nixonix> thanks, i checked the wiki fast, but will read more in near future and put the youtube link in my notes
[22:20:00 CET] <cehoyos> nixonix: The correct framerate is 3000/1001
[22:20:07 CET] <cehoyos> Or 24000/1001
[22:28:19 CET] <nixonix> ok. btw, resync worked. for some reason, although i extracted both mp3 and aac audio, then ended up using the aac as in my combining, the needed factor to get the lip sync was very close (but not exactly) to the result i got when calculated the length of mp3/video (not the aac, although i used the aac audio file). i wonder why
[23:45:22 CET] <chaosblade> c_14, i'll look into that, much appreciated :]
[23:45:39 CET] <chaosblade> also cehoyos :]
[23:46:14 CET] <chaosblade> bit more of a nightmare than i imagined, getting an ffmpeg built "properly" when you don't have extensive experience with building under linux/gcc
[00:00:00 CET] --- Wed Jan 22 2020