[Ffmpeg-devel-irc] ffmpeg.log.20180129
burek
burek021 at gmail.com
Tue Jan 30 03:05:01 EET 2018
[02:54:55 CET] <kennedy101> I have a scaling question. https://pastebin.com/BBz9rU1b
[03:11:08 CET] <furq> you would do the thing you put in parens
[03:11:39 CET] <furq> unless you're asking how that works with deinterlacing in which case get rid of -deinterlace and -vf yadif=1,scale=-2:720
[03:11:57 CET] <furq> i don't even know what -deinterlace is mapped to these days
[03:38:04 CET] <kennedy101> furq - yes sir, need to append the part in parens. testing it on a short 1080x1920 now.
[03:40:37 CET] <kennedy101> looks like cropdetect might be an option too for 480x720 LD transport streams.
[04:05:35 CET] <moszeusz> hello! I am trying to use rubberband from librubberband library to pitch scale my audio file; it is described in https://ffmpeg.org/ffmpeg-filters.html#rubberband but ffmpeg ver. 3.4.1 doesn't find it
[04:06:22 CET] <moszeusz> what should I do to use it or is there another way to pitch scale my file?
[04:07:46 CET] <moszeusz> I'm sorry if I'm not precise enough but I'm new here and in using ffmpeg
[08:53:18 CET] <yusa> Hello there, i am currently testing to stream a mp4 file from an embedded linux device to a nginx streaming server which runs on my development pc. Testing on my development pc i was fine with the command: "ffmpeg -re -i music.mp4 -c:v libx264 -f flv rtmp://192.168.10.35/live". But on the embedded linux platform unfortunately i only get about 3 fps at max. Any ideas to increase performance? I would consider transmitting less compressed
[08:53:28 CET] <yusa> Bandwidth should not be limiting factor.
[08:54:23 CET] <yusa> I am trying to watch the stream with the vlc player afterwards, so it should a compatible format. Any ideas?
[08:55:58 CET] <furq> what cpu does this embedded device have
[08:57:30 CET] <yusa> the platform is a Xilinx Zynq-7020 with a ARM ® Cortex"-A9 processor CPU
[08:59:39 CET] <furq> yeah you're probably not going to have much luck transcoding video on that
[08:59:56 CET] <furq> if the source is an mp4 then it's probably already h264 and aac
[09:00:02 CET] <furq> in which case you can just use -c copy -f flv
[09:00:48 CET] <yusa> Aha, i see.
[09:01:59 CET] <yusa> Okay, as this is only for test purpose i maybe skip that step. Maybe you remember, i actually use case is to stream raw data images.
[09:02:10 CET] <yusa> my*
[09:02:16 CET] <furq> in that case you can try -c:v libx264 -preset ultrafast
[09:02:33 CET] <furq> downscaling the images will also help a lot if that's acceptable
[09:02:48 CET] <furq> ideally you'd do that before it gets to ffmpeg but otherwise -vf scale=123:456
[09:04:44 CET] <yusa> yes, sounds plausible
[09:06:07 CET] <yusa> cat *.raw | ffmpeg -s 1280x960 -pix_fmt gray -f rawvideo -i - -c:v libx264 -f flv rtmp://192.168.10.35/live
[09:07:45 CET] <yusa> So this command is also pretty weak in performance on my embedded platform. What could increase efficiency?
[09:08:22 CET] <yusa> Ahh, "-c:v libx264 -preset ultrafast" this?
[09:10:02 CET] <furq> yeah
[09:10:13 CET] <yusa> Okay cool, i will give it a try
[09:12:40 CET] <yusa> Unable to find a suitable output format for 'rtmp://192.168.10.35/live' rtmp://192.168.10.35/live: Invalid argument
[09:12:56 CET] <furq> you still need -f flv
[09:15:11 CET] <yusa> so i only added -preset ultrafast, what does it?
[09:17:42 CET] <yusa> I am at 10 fps now.
[09:28:28 CET] <yusa> For me it seems, that ffmpeg still has to encode something. Some outputs: "using cpu capabilities: ARMv6 NEONprofile High 4:4:4 Predictive, level 3.2, 4:4:4 8-bit 264 - core 148 r2748 97eaef2 - H.264/MPEG-4 AVC codec
[09:28:45 CET] <JEEB> > ARMv6
[09:28:47 CET] <JEEB> my condolences
[09:28:57 CET] <JEEB> also 4:4:4 encoding on a low-power device :/
[09:28:58 CET] <pmjdebruijn> yusa: the ffmpeg binary you're using is built for a previous generation of ARM
[09:29:14 CET] <JEEB> I'm pretty sure NEON is runtime checked?
[09:29:30 CET] <JEEB> yusa: is this an ARMv6 device?
[09:29:39 CET] <pmjdebruijn> I though it's ARMv7 (A9)?
[09:29:54 CET] <yusa> yes, should be Cortex-A9
[09:30:02 CET] <yusa> it is defenitely
[09:30:10 CET] <yusa> so i got wrong ffmpeg version?
[09:30:29 CET] <pmjdebruijn> well, at least libx264
[09:30:33 CET] <pmjdebruijn> the question is how much it'll matter
[09:30:42 CET] <JEEB> there is some NEON code in x264
[09:30:44 CET] <JEEB> so it will matter
[09:30:44 CET] <yusa> JEEB: what can i do about 4:4:4 encoding ?
[09:30:46 CET] <pmjdebruijn> considering it seems it's using NEON
[09:30:53 CET] <JEEB> oh, it says NEON
[09:30:53 CET] <JEEB> derp
[09:30:55 CET] <JEEB> ok
[09:30:57 CET] <JEEB> sorry then
[09:31:02 CET] <JEEB> E_NOT_ENOUGH_COFFEE
[09:35:19 CET] <yusa> Okay. cat /proc/cpuinfo says: "ARMv7 Processor rev 0 (v7l)" and ffmpeg says using cpu capabilities: ARMv6 NEON. I installed ffmpeg through package manager, do you have to build it on my own? What impact does it have anyways?
[09:35:47 CET] <yusa> *do I have to...
[09:36:06 CET] <JEEB> well if it says NEON it's at least using NEON instructions
[09:36:12 CET] <pmjdebruijn> https://www.johnvansickle.com/ffmpeg/ you might want to try that
[09:36:13 CET] <JEEB> but 4:4:4 encoding will be slow in any case
[09:36:24 CET] <pmjdebruijn> presumably the armhf
[09:36:40 CET] <yusa> how to change it to a more performant encoding than 4:4:4 ?
[09:36:51 CET] <JEEB> (sw encoding with ARM will be slow in any case, so you will only be able to do low resolution stuff)
[09:37:15 CET] <JEEB> yusa: by making sure your input is not 4:4:4? the problem is that you cannot use software filtering for that because that will just slow you down *more*
[09:37:51 CET] <pmjdebruijn> yusa: those binaries are static, just download and try them
[09:37:56 CET] <furq> his input is gray8 iirc
[09:38:33 CET] <furq> so it probably doesn't make much difference either way
[09:39:17 CET] <yusa> Okay, i actually dont know what 4:4:4 means -.- so ye how could my "gray" format be something like 4:4:4 encoded? :'D
[09:39:41 CET] <pmjdebruijn> it's chroma subsampling
[09:39:44 CET] <furq> https://en.wikipedia.org/wiki/Chroma_subsampling#Types_of_sampling_and_subsampling
[09:39:46 CET] <pmjdebruijn> but you don't have chroma
[09:39:54 CET] <furq> your input is gray8 so you don't have chroma so it won't make a difference
[09:40:05 CET] <furq> you might as well add -pix_fmt yuv420p anyway
[09:47:16 CET] <Daglimioux> I have a command that creates a 3 video and 1 "black screen" in a mosaic (2x2). 2 videos has a duration of 00:01:33 and the third one has a duration of 00:01:32. The video with duration of 00:01:32 has some frames missing from 00:00:24 to 00:00:26. When I do the compilation, the video is played as expected, but at 00:00:26, all videos are freezed while the audio continues being played. Any suggestion why is this behaviour happenin
[09:47:30 CET] <Daglimioux> Here is the command: ffmpeg -i video1.webm -i video2.webm -f lavfi -i color=s=640x360:color=black:d=1 -i video3.webm -i audio1.opus -i audio2.opus -i audio3.opus -filter_complex "amix=inputs=3:dropout_transition=0; [0:v] scale=640x360, setdar=0 [r1c1]; [1:v] scale=640x360, setdar=0 [r1c2]; [3:v] scale=640x360, setdar=0 [r2c2]; [r1c1][r1c2] hstack=2 [r1]; [2][r2c2] hstack=2 [r2]; [r1][r2] vstack=2" -c:a libfdk_aac -b:a 96k -c:v lib
[09:47:31 CET] <Daglimioux> -f mp4 -preset ultrafast -y output.mp4
[10:07:06 CET] <durandal_1707> Daglimioux: probably pts is jumping high
[10:08:40 CET] <Daglimioux> durandal_1707: what does it mean?
[10:11:46 CET] <durandal_1707> Daglimioux: presentation timestamps have big jumps, either use setpts filter to reset pts or fix video so it doesnt have pts jumps
[10:13:09 CET] <Daglimioux> durandal_1707: I cannot fix the video, as it is a recording from another software. I will try the "setpts" option
[10:17:12 CET] <cutechaos> Hello everyone, I have one doubt, Does FFmpeg support srt protocol as input (https://github.com/Haivision/srt)?
[10:17:25 CET] <Daglimioux> durandal_1707: I've tried adding "setpts=PTS-STARTPTS" to each video, but now I get freezed at 00:00:26 seconds and cannot get further. With my command, atleast I could listen the rest of the audio inputs, but now VLC stops playing at 00:00:26 even with a duration of 00:01:33
[10:24:13 CET] <Daglimioux> durandal_1707: I've tried: "setpts=PTS". Same results :( In fact, when I play the "corrupted" video in VLC, sometimes VLC crashes at that timestamp
[10:24:32 CET] <Daglimioux> I mean, the video itself, not the compilation
[10:26:35 CET] <durandal_1707> Daglimioux: you need to completely rewrite pts, not just make it start from 0
[10:27:22 CET] <Daglimioux> Oh! okay, I'm dumb, sorry. Is there a doc about it, so I can learn how to do that?
[10:30:11 CET] <yusa> Okay i tried the given binaries. There is no visible change to me. Still telling me he is using ARMv6 NEON capabilities. A tried to add -pix_fmt yuv420p at the output side, but changed to the bad. I would like to try "-f rawvideo" at output side, but i guess that will not work with my nginx and vlc solution...
[10:36:18 CET] <durandal_1707> Daglimioux: its in examples of documentation
[10:42:16 CET] <pmjdebruijn> yusa: you meant the link I pasted? keep in mind you need to start those binaries with ./ffmpeg right?
[10:42:40 CET] <yusa> yes, i did
[10:42:52 CET] <yusa> downloaded armhf version
[10:42:53 CET] <pmjdebruijn> oh I thought those were ARMv7 built :(
[10:43:08 CET] <pmjdebruijn> my bad
[10:43:23 CET] <pmjdebruijn> still it's a good source of newer ffmpeg outside of your regular distro :D
[10:55:51 CET] <furq> yusa: -pix_fmt gray -i - -pix_fmt yuv420p
[10:55:55 CET] <furq> in case that wasn't clear
[10:57:21 CET] <furq> but yeah it sounds like your only real option is to pipe in lower resolution images
[11:27:12 CET] <yusa> Maybe other option is to forward my raw data using netcat to my dev pc and utilizing ffmpeg only at the dev pc for stream generation.
[11:28:31 CET] <yusa> pmjdebruijn: ok, thanks anyways!
[11:30:14 CET] <yusa> From ffmpeg can i directly pipe into mplayer?
[11:33:53 CET] <furq> yes although you should probably be using mpv now
[11:34:00 CET] <furq> -f rawvideo - | mpv -
[11:34:31 CET] <furq> also you don't need netcat, just cat *.raw | ssh devpc ffmpeg -i - ...
[11:35:50 CET] <durandal_1707> Daglimioux: ffmpeg have documentation at www.ffmpeg.org
[11:36:04 CET] <yusa> yes, cool, that (mplayer pipe) works! Uff, whats wrong about mplayer? :D
[11:37:21 CET] <yusa> cat *.raw | ssh devpc ffmpeg -i - ... (cool, is that performant? )
[11:38:22 CET] <furq> mplayer hasn't been developed for a while
[11:38:34 CET] <furq> mpv is a fork that a lot of the devs jumped ship to
[11:38:41 CET] <yusa> kk
[11:38:51 CET] <yusa> i dont mind using mpv ;-)
[11:39:02 CET] <furq> ssh probably isn't as performant as nc but i'm sure it'll be plenty fast enough
[11:39:09 CET] <furq> you could probably force no cipher if you really want
[11:39:52 CET] <yusa> ok, ill give a try
[11:42:29 CET] <Daglimioux> durandal_1707: Thank you. I've been looking at it, but I still don't know how to properly use it (or which options should I use) to "rebuild" timestamp. Btw, I've been reading a post that it is almost "impossible" to do that and a re-encoding should work. I've tried to re-encode the videos with problems and the compilation completes succesfully, but re-encoding because of bad frames is not a true solution for my problem, as it wil
[11:43:00 CET] <Daglimioux> multiple videos, then do the compilation. If video recordings are about 30 mins length, it will take almost 15-25 mins, which is not our goal
[11:46:05 CET] <kazuma_> anyone having issues with zeranoe builds?
[11:46:06 CET] <kazuma_> https://i.imgur.com/qSAUlqQ.png
[11:46:18 CET] <kazuma_> this is like my 10th crash in a week :(
[11:46:32 CET] <kazuma_> before that it never crashed in years of using his builds
[11:52:52 CET] <Guest46325> Hello everyone I have question about ffmpeg when it make hardsub. my native language is farsi. i have subtite which in a line have mixed english and farsi word. when i make hardsub. subtitle have issue. in line have mixed english and farsi word direction is wrong. for example this screenshot is correct line in libreoffice writer and secend screenshot is output ffmpeg with wrong direction
[11:52:57 CET] <Guest46325> http://uupload.ir/files/mo0q_correct-direction.jpg
[11:53:10 CET] <Guest46325> http://uupload.ir/files/lx30_wrong-direction.jpg
[11:53:42 CET] <Guest46325> is issue related to ffmpeg or my subtitle have issue?
[11:56:44 CET] <relaxed> Guest46325: could be, which ffmpeg version are you using?
[11:58:08 CET] <Guest46325> ffmpeg version 3.4.1
[11:58:55 CET] <furq> i doubt that's an ffmpeg bug, it's probably fribidi
[11:59:25 CET] <JEEB> harfbuzz and fribidi are the two related components IIRC
[11:59:44 CET] <JEEB> make sure both are built into your FFmpeg's subtitle rendering
[11:59:49 CET] <Guest46325> does ffmpeg use fribidi for farsi language?
[12:00:01 CET] <JEEB> depends on which renderer
[12:00:10 CET] <JEEB> I think libass can use fribidi and harfbuzz with freetype2
[12:00:17 CET] <JEEB> *but* I also know it's far from perfect
[12:00:25 CET] <furq> yeah idk if you need to build ffmpeg with fribidi, it should be fine as long as libass is
[12:00:31 CET] <furq> but i guess it couldn't hurt
[12:01:29 CET] <Guest46325> well what am i doing?
[12:02:56 CET] <yusa> "cat *.raw | ssh -p 4422 yusa at 192.168.10.35 ffmpeg -s 1280x960 -pix_fmt gray -f rawvideo -i - -c:v libx264 /home/yusa/out.mp4" principially works, but again, not at sufficient frame rates, 9 fps i am getting. I will check my bandwidth and file operation capabilities and come back or did i messed something up with the command? But mh, im guessing sending data over ssh is too costly... :(
[12:04:53 CET] <Daglimioux> durandal_1707: Tbh this is making me going crazy. I cannot make it work :(
[12:06:25 CET] <Daglimioux> durandal_1707: And as I mentioned earlier, re-encoding doesn't sound a "good" solution. If I have 9 recordings and my system has to re-encode all 9 streams into the same ones to fix frame errors and then do the compilation... It will take years to create the output video :(
[12:07:28 CET] <relaxed> Guest46325: you could try https://www.johnvansickle.com/ffmpeg/
[12:08:45 CET] <durandal_1707> Daglimioux: you are reencoding anyway when stacking videos
[12:09:33 CET] <Guest46325> relaxed: do you means I compile ffmpeg from source?
[12:09:38 CET] <Daglimioux> durandal_1707: yes, but when I reencode with my example, is just one line of code reencoding webm - mp4. The solution I've found is going 1 by 1 reencoding webm to webm, then use the new ones to reencode again webm to mp4
[12:10:47 CET] <Daglimioux> with that, I can fix my webm file errors, but I cannot do it in one line and I have to reencode into the same codec to "fix problems", then reencode again. Sounds really awful
[12:11:41 CET] <relaxed> Guest46325: no, if you run linux those are binaries with everything included
[12:12:20 CET] <Guest46325> ok i got this i will try with new ffmpeg
[12:14:05 CET] <relaxed> be sure and use the new binary, /path/to/new/ffmpeg -i ...
[12:15:10 CET] <yusa> "time cat *.raw > test; time sync;" on my embedded linux platfrom gives me "real 0m11.209s" and "real0m9.063s". Seems to be the bottleneck here. 135 images / 11 sec = 12fps ... So, i know how to adjust my test setup. Thanks for great help anyways @furq. Really appreciate it!
[12:20:45 CET] <Guest46325> i hardsub with new ffmpeg output still have issue on direction mix line
[12:38:02 CET] <furq> relaxed: those binaries don't have fribidi do they
[12:47:13 CET] <Daglimioux> durandal_1707: Okay. Thanks for all the information you provided. After talking with the recording service creator (janus), he says that when you have missing information from RTCPeers, the generated video file might have errors in dts/pts, bad RTP timestamps, etc. and he recommends to re-encode the resulting webm videos to fix some of those errors. It's weird that FFMpeg can't do that when a compilation with filter-complex is mad
[12:48:08 CET] <Daglimioux> but it works when videos are re-encoded then compiled with filter-complex. Btw, I've found how to speed up vp8 re-encoding and it works like a charm. I suppose that I have to do that for all my recordings, but well. Thanks again for all the information and keep up the good work :)
[13:01:12 CET] <th3_v0ice> Hello all. Can somebody please tell me how to properly set timebase for x264 encoder? I tried different combinations that use ticks_per_frame, inverted fps, 1/90000, but nothing seems to be working properly. I get the video as output which is correct in duration but its simply not at the bitrate that I specify using the crf. Changing the timebase gives different values for bitrate. Thanks.
[13:02:46 CET] <BtbN> timebase and bitrate are entirely unrelated.
[13:03:15 CET] <BtbN> of course, if you massively lower the fps, you technically get a super low bitrate. As two frames might play for a minute
[13:05:13 CET] <th3_v0ice> But doesnt the timebase affect the fps?
[13:07:37 CET] <BtbN> There is no fps. Only timestamps to a given timebase
[13:08:05 CET] <yusa> Hey there, just wanted to share my success :) Achieved streaming mp4 video over ssh to PC and utilizing ffmpeg there to pipe through named pipe to mpv. Works like a charme!
[13:08:08 CET] <yusa> Dev PC:
[13:08:13 CET] <yusa> mkfifo fifo.mp
[13:08:17 CET] <yusa> mpv fifo.mp4
[13:08:25 CET] <yusa> Embedded Linux Platform:
[13:08:40 CET] <yusa> cat music.mp4 | ssh julian at 192.168.10.35 "ffmpeg -i - -c:v libx264 -f flv pipe:1 > /home/julian/fifo.mp4"
[13:09:25 CET] <yusa> *mkfifo fifo.mp4
[13:09:43 CET] <th3_v0ice> BtbN: Ok, then I am not properly setting the timebase. How to set one? Can You describe some steps?
[13:10:01 CET] <BtbN> if you need to manually worry about the timebase you are most likely doing something wrong
[13:10:26 CET] <BtbN> yusa, sorry to disappoint, but you are streaming flv in a pipe ending in .mp4, not mp4.
[13:10:35 CET] <BtbN> mp4 cannot be streamed.
[13:10:42 CET] <th3_v0ice> BtbN: But in the examples they are setting the timebase to be inverse of fps. right?
[13:11:24 CET] <yusa> Okay, thanks for pointing out, maybe i should use other name for the named pipe, fifo.flv e.g. right?
[13:11:43 CET] <th3_v0ice> BtbN: Also if I try to not specify it to the encoder my run fails.
[13:12:20 CET] <BtbN> you need a valid timebase, yes. inverse of the fps is the most simple case.
[13:12:31 CET] <BtbN> that makes in increment of 1 be the time of one frame
[13:13:14 CET] <th3_v0ice> So if You include ticks_per_frame in the equasion, everything should be fine?
[13:16:51 CET] <th3_v0ice> BtbN: Lets try a different approach. Should I, or should I not, set the timebase while transcoding?
[13:16:52 CET] <BtbN> your timebase needs to have space for multiple ticks per frame
[13:17:05 CET] <BtbN> Are you using ffmpeg.c?
[13:17:36 CET] <BtbN> so if you have 30 fps, for two ticks per frame your timebase needs to be a multiple of 1/60
[13:17:43 CET] <th3_v0ice> I created my own class with the transcoding.c as a template, but I can look at the ffmpeg.c if You wont to point me to some specific code.
[13:18:02 CET] <BtbN> Some containers also have fixed timebases
[13:18:04 CET] <th3_v0ice> *want.
[13:18:22 CET] <BtbN> but generally video encoders do not care about fps/timebase. They just pass through timestamps.
[13:18:27 CET] <th3_v0ice> I am only using mp4 container.
[13:20:59 CET] <Swervz> Hi how would I transcode a variable framerate video to constant framerate video with ffmpeg? Google results just have people saying to not record in VFR which is not helpful if you have existing videos
[13:21:54 CET] <JEEB> there are filters to convert to a specific frame rate, the basic filters just duplicate or cut off frames to match the request frame rate
[13:22:07 CET] <JEEB> additionally there's a slooow filter that does motion compensation if you want to go fancy
[13:22:25 CET] <JEEB> and of course if you can encode VFR as VFR, that's the least bad alternative
[13:22:39 CET] <th3_v0ice> BtbN: fps=50/2 timebase=1/50 does this seem right?
[13:22:53 CET] <BtbN> for 25 fps, probably
[13:22:53 CET] <Swervz> I just want to import it into adobe premiere but their broken software just chokes on VFR videos
[13:23:20 CET] <furq> Swervz: just -vf fps=25 to do it naively
[13:23:27 CET] <th3_v0ice> Yes, fps is 25, but why does my encoder when I set crf to 0, only achieves 122kbps ?
[13:23:35 CET] <furq> i guess the higher the rate, the less bad it'll look
[13:23:43 CET] <BtbN> th3_v0ice, because it doesn't need more?
[13:23:52 CET] <Swervz> It's a ~60 fps clip
[13:24:05 CET] <th3_v0ice> BtbN, what if I want it to achieve more?
[13:24:11 CET] <BtbN> why would you?
[13:24:28 CET] <BtbN> x264 does not waste bandwidth if it can achive losslessness with that little, it will
[13:24:29 CET] <Swervz> Is there a way to specify cutting frames or duplicating frames?
[13:24:43 CET] <furq> it'll do both
[13:24:51 CET] <furq> whatever it needs to hit the target rate
[13:25:16 CET] <Swervz> Is there a way to just drop frames and like round down the FPS to a constant number
[13:25:58 CET] <furq> that's pretty much what fps will do if you set the target rate lower
[13:26:06 CET] <Swervz> hmm okay thankyou
[13:26:16 CET] <Swervz> yeah videos with duplicates always look more jarring than ones with dropped frames
[13:26:18 CET] <Swervz> at least to me
[13:26:31 CET] <th3_v0ice> BtbN, Hmm, but if the input clip is at 1.2mbps, and I specify crf 0, how can it not loose something when it encodes at 122kbps, because the sequence looks to be worse in qualiy.
[13:26:40 CET] <furq> if you prevented it from duping frames then the output wouldn't be cfr if you have a 100ms discontinuity
[13:26:47 CET] <furq> so that's obviously not something you'd usually do
[13:27:02 CET] <furq> and if you don't have any long gaps then it won't dup anyway
[13:27:16 CET] <Swervz> hmm what about the other filter that does the motion compensation?
[13:27:19 CET] <BtbN> th3_v0ice, you did not properly set it to crf 0 then.
[13:27:21 CET] <furq> minterpolate
[13:27:26 CET] <furq> i've not used that and as JEEB said it's very slow
[13:27:40 CET] <furq> and also all filters like that are prone to creating artifacts
[13:28:08 CET] <furq> if the source is cfr and it has >1-frame gaps then it'll playback as if it had duped frames anyway
[13:28:15 CET] <furq> so i wouldn't worry too much about that
[13:28:35 CET] <furq> i would just try fps=60 and see if it looks jerky
[13:28:56 CET] <furq> if it doesn't then there's not much point messing with minterpolate
[13:29:20 CET] <Swervz> okay thankyou I guess Ill try just doing that first and then use minpolate if it looks werid
[13:30:07 CET] <th3_v0ice> BtbN, I need to investigate a little bit more and will get back to You. Thanks for the help!
[13:30:28 CET] <Swervz> its werid how google never found me this page https://ffmpeg.org/ffmpeg-filters.html when searching earlier
[13:30:42 CET] <Swervz> I only found it because I searched for minterpolate
[13:31:09 CET] <furq> yusa: you shouldn't need a fifo for that, just -f flv - | mpv -
[13:33:16 CET] <yusa> Ok, but then i would be needed to initiate the command from the dev pc as i am not able to open windows (for mpv) through the ssh command form the embedded device i think
[13:34:00 CET] <furq> oh right
[13:34:53 CET] <furq> iirc you can do something like ssh embedded "cat /path/to/*.raw" | ffmpeg ...
[13:35:21 CET] <yusa> yeah, than i would have a one liner :D
[13:44:59 CET] <Swervz> Is there a way to output something that does not require much encoding? if I do ffmpeg -i "input.mp4" -vf fps=60 "output.mp4" it transcodes at 2x speed which is gonna take a really long time
[13:45:34 CET] <Swervz> anything that works in adobe premiere would be fine
[13:45:36 CET] <yusa> furq: thanks again, yes that just worked! Thanks again for simplifying my command ! :)
[13:45:42 CET] <furq> if you just want to test what it looks like then output rawvideo or ffvhuff or something
[13:45:45 CET] <sfan5> -preset ultrafast
[13:45:52 CET] <furq> if it has to be compatible with premiere then yeah i guess preset ultrafast
[13:45:53 CET] <sfan5> alternatively save it in a lossless video format
[13:46:16 CET] <sfan5> adobe probably supports apple ProRes or something similar
[13:46:20 CET] <Swervz> yeah lossless would be fine Its just so I can edit it in premiere then export
[13:46:54 CET] <furq> i guess maybe ut video then?
[13:47:05 CET] <furq> if you're on windows then there's a dshow component you can install that should make premiere load it
[13:47:07 CET] <sfan5> https://helpx.adobe.com/de/premiere-pro/using/supported-file-formats.html prores works according to this
[13:47:14 CET] <sfan5> so add -c:v prores
[13:47:16 CET] <furq> is prores quick to encode
[13:47:19 CET] <sfan5> not sure
[13:47:43 CET] <furq> https://www.videohelp.com/software/Ut-Video-Codec-Suite
[13:47:44 CET] <pmjdebruijn> Swervz: ffmpeg -c:v libx264 -tune:v fastdecode -intra out.mp4
[13:47:51 CET] <furq> uh
[13:47:53 CET] <furq> no
[13:48:22 CET] <Swervz> Yeah I'm on windows 10 sorry I should have specified
[13:48:23 CET] <pmjdebruijn> Swervz: that'll get you good scrubbing compatibity, if you want it as a proxy codec
[13:48:32 CET] <pmjdebruijn> but the video quality will suffer :)
[13:48:38 CET] <furq> Swervz: install the thing i just linked and use -c:v utvideo
[13:48:40 CET] <sfan5> I get 96 fps for 720p with prores here, so no it's not fast
[13:48:42 CET] <pmjdebruijn> otherwise you might want to take a look at dnxhd
[13:48:43 CET] <furq> if you have the disk space for it obviously
[13:48:52 CET] <furq> you won't get any quicker than that
[13:49:12 CET] <furq> premiere should be able to open it but you might need to use avi
[13:49:22 CET] <Swervz> ok thankyou all for helping really appreciate it that codec looks good
[13:51:07 CET] <Swervz> So after installing that codec I'm just transcoding it to a lossless format using avi as a container and the UT codec?
[13:51:12 CET] <furq> right
[13:51:30 CET] <Swervz> ah awesome
[13:51:30 CET] <furq> you only need to install it so premiere can decode it
[13:51:51 CET] <furq> that's the best lossless codec it supports afaik
[13:52:13 CET] <Swervz> ah ok I get it now yeah
[13:52:15 CET] <furq> certainly if you just want something quick
[13:52:38 CET] <Swervz> I was confused at first because I remember using fraps a long time ago to do rawcap and then converting to avi but I guess that used a lossy codec
[13:53:19 CET] <Swervz> unrelated to the current thing of course just an anecdote
[13:53:24 CET] <furq> mkv supports ut video but idk if premiere supports mkv
[13:53:36 CET] <furq> it shouldn't make any difference if this is just a temp file anyway
[13:53:37 CET] <Swervz> nah it doesnt
[14:02:04 CET] <yusa> I can see ffmpeg is a very powerful. Lets see where the limits are! Is ffmpeg cabable
[14:02:18 CET] <yusa> of producing overlays?
[14:03:13 CET] <yusa> e.g. i want add some colored points, rectangles, circles and lines to the images
[14:04:55 CET] <furq> !filter drawbox @yusa
[14:04:56 CET] <nfobot> yusa: http://ffmpeg.org/ffmpeg-filters.html#drawbox
[14:05:07 CET] <yusa> maybe i can transmit these information through vector image format like MVG
[14:05:22 CET] <yusa> Ahaa, okay, thanks for the link, let me have a look
[14:05:25 CET] <furq> no circles though
[14:05:39 CET] <Swervz> furq, does this look right to you? ffmpeg -i "input.mp4" -c:v utvideo -vf fps=60 "output.avi".mp4
[14:05:42 CET] <furq> there's also the overlay filter if you want to prerender an image and overlay it
[14:05:47 CET] <Swervz> um
[14:05:49 CET] <furq> lol
[14:05:52 CET] <Swervz> ignore that mp4
[14:05:54 CET] <furq> other than that yeah
[14:06:44 CET] <Swervz> apparently there is utvideo and libutvideo
[14:07:13 CET] <furq> either should be fine
[14:07:27 CET] <furq> idk which one is faster
[14:07:51 CET] <Swervz> Non-monotonous DTS in output stream 0:1 I guess because I did not specify audio codec?
[14:08:08 CET] <furq> just add -an to drop the audio
[14:08:23 CET] <Swervz> But I want audio
[14:08:30 CET] <Swervz> -codec:a pcm_s16le
[14:08:36 CET] <furq> i guess that works
[14:08:44 CET] <ArsenArsen> anyone got a code example to record x11grab into a file? (inside C/C++
[14:10:17 CET] <Swervz> I still only get 155FPS with that, beginning to think there is something wrong with my pc
[14:12:13 CET] <Swervz> Looks like HDD bottleneck https://i.imgur.com/emUDzCB.png
[14:12:51 CET] <Swervz> I guess its time to buy more SSDS
[14:15:28 CET] <yusa> Is this a static overlay? Can I produce a frame accurant overlay (each frame its own overlay) ?
[14:15:55 CET] <pmjdebruijn> you can overlay a video onto another video
[14:16:20 CET] <Swervz> a different overlay for each frame sounds crazily complex
[14:16:56 CET] <Swervz> I wouldn't even want to do that in a NLE lol
[14:16:58 CET] <yusa> yes, but i do object recognition and want to mark found objects in each frame
[14:18:03 CET] <Swervz> Oh that's a bit beyond me. Sounds fun though
[14:19:20 CET] <Swervz> You making the next skynet or something?
[14:19:26 CET] <yusa> maybe overlaying a video could be useful, mhh.
[14:19:36 CET] <yusa> ;D
[14:20:47 CET] <yusa> I was implementing hardware accelerator for the FPGA Zynq platfrom for real-time object detection. Now i am on my way setting up a nice demonstrator ;-)
[14:23:42 CET] <Swervz> Is this the sort of thing you want to do? https://superuser.com/questions/1172260/ffmpeg-overlaying-images-sent-through-a-pipe-onto-a-video
[14:27:34 CET] <yusa> Swervz: Yes, something like that. But ideally it should be frame accurate, maybe i will have to do it by my own or with libSDL maybe beforehand.
[14:55:17 CET] <yusa> mh, libSDL will not work without creating windows, damn. Need to create my overlays in a smart way :P
[16:31:23 CET] <Tweak> Goody day everyone. Is anyone familiar with the API? Trying to do a crossfade, but a bit lost on how the initialize and use filters
[16:40:54 CET] <azarus> Would it make sense to convert my 720p h264 library to h265?
[16:41:36 CET] <Swervz> hey my command fails with "[h264_nvenc @ 00000000027e1020] EncodePicture failed!: unsupported param (12)" anyone know why? ffmpeg -i "input.mp4" -c:v h264_nvenc -profile high444p -pixel_format yuv444p -preset default -c:a copy "output.mp4"
[16:41:48 CET] <teratorn> azarus: considering storage price/MB over time... probably not
[16:41:56 CET] <lyncher> when encoding from a raw source (SDI/declink) does ffmpeg retains timecodes that can be available in SDI?
[16:42:04 CET] <Swervz> azarus, I assume its already lossy compressed
[16:42:09 CET] <azarus> Swervz: yes
[16:42:13 CET] <Swervz> transcoding it will probably just make it look worse
[16:42:20 CET] <Swervz> for minimal gain in other aspects
[16:42:34 CET] <azarus> I'm not exactly struggling for space either :/
[16:42:46 CET] <teratorn> azarus: are you going to do it again when the next whiz-bang codec comes along?
[16:43:33 CET] <azarus> teratorn: relevant? https://xkcd.com/1683/
[16:43:36 CET] <alexpigment> azarus: i think you've answered your own question with a resounding "no" :)
[16:44:06 CET] <azarus> Hrm. But I might recode the audio! :P
[16:44:11 CET] <alexpigment> why?
[16:44:30 CET] <teratorn> azarus: cute
[16:45:01 CET] <azarus> Kinda want everything uniformely opus, but I suppose it's not really practical
[16:45:17 CET] <alexpigment> there's no benefit to doing all that imho
[16:45:38 CET] <azarus> Just keep it as it is?
[16:45:41 CET] <furq> on the plus side, that will at least run faster than 0.1x like x265 would
[16:45:46 CET] <furq> on the minus side, literally everything else about it
[16:46:11 CET] <azarus> What I find funny is that some movies (of the same length) take up several GBs while others take only like 700MB
[16:46:32 CET] <furq> well yeah some people are bad at encoding movies
[16:46:46 CET] <furq> most people, in fact
[16:46:55 CET] <Swervz> but its a lossy format
[16:46:59 CET] <Swervz> why would you want to transcode
[16:47:18 CET] <furq> yeah you'd generally better have a good reason for transcoding lossy to lossy
[16:47:25 CET] <Swervz> there are zero benefits I can think of unless you have some archaic device
[16:47:36 CET] <azarus> Smaller filesizes?
[16:48:03 CET] <azarus> (but then again, storage is cheap)
[16:48:04 CET] <furq> especially given what you have is probably a bdrip or a dvdrip which is already a lossy transcode
[16:48:16 CET] <Swervz> I think it just comes down to if you care about quality over quantitiy
[16:48:35 CET] <azarus> I don't care that much about quality tbh, my eyes aren't that great
[16:48:44 CET] <Swervz> you should get glasses
[16:48:47 CET] <azarus> (or rather, some blockiness doesn't bother me)
[16:49:00 CET] <kepstin> I mean, if you e.g. want a copy that fits on your phone or something, then transcode to a copy for your phone. But a copy, don't delete the source ;)
[16:49:13 CET] <Swervz> most phones can handle h.264 just fine though
[16:49:18 CET] <Swervz> and have ample storage these days
[16:50:43 CET] <azarus> Oh well. Still leaves me wondering why some files are huge and some tiny without looking that different quality-wise
[16:51:06 CET] <furq> the smaller one was probably denoised to hell
[16:51:40 CET] <furq> if that's 720p then i would also expect it to have a lot of ringing
[16:52:06 CET] <Swervz> I'm not sure what to tell you if you can't see the difference
[16:52:43 CET] <azarus> I'm not a pixel-peeper, if that helps
[16:53:08 CET] <Swervz> I can see the difference like 20 feet away from my tv
[16:53:09 CET] <kepstin> keep in mind also that the *content* of the video highly influences what filesize/bitrate you need to hit a particular quality level
[16:53:26 CET] <Diag> >pixel peeper
[16:53:29 CET] <Swervz> Maybe you don't know what to look for at that point sometimes its best to not know.. Because like with screen tearing you will forever be cursed to notice it after someone shows you what it is
[16:53:29 CET] <kepstin> so you can't really compare two different movies
[16:53:30 CET] <azarus> kepstin: yup; movies with lots of stills take up far less space, right?
[16:53:54 CET] <Diag> Swervs that's why you go with freesync
[16:54:17 CET] <Swervz> or gsync, I have a nvidia gpu
[16:54:23 CET] <Diag> Gross
[16:54:33 CET] <Swervz> I'd buy amd if they had more powerful gpus
[16:54:36 CET] <azarus> Swervz: I do have a FreeSync GPU and monitor; and I do notice a slight difference
[16:54:42 CET] <Diag> It's major
[16:54:58 CET] <Diag> You can't get a shit monitor, get one that can go 35-144
[16:55:07 CET] <azarus> (but I only have a 75Hz monitor)
[16:55:15 CET] <Diag> There's your problem
[16:55:23 CET] <kepstin> does it actually help with video tho? (i.e. will freesync allow adapting to exact video framerates?)
[16:55:30 CET] <Diag> Freesync is the best thing to happen to monitors
[16:55:30 CET] <azarus> I don't ever play any FPSs nowadays
[16:55:50 CET] <azarus> Neither anything that benefits a lot from it
[16:55:50 CET] <Diag> kepstin it will if it's in your monitors range
[16:56:10 CET] <kepstin> Diag: alright, do any players support this? (and I assume if so, it's only in fullscreen)
[16:56:20 CET] <furq> i should hope it's only in fullscreen
[16:56:21 CET] <Diag> Should be anything that uses direct x
[16:56:37 CET] <kepstin> huh. might work with mpv then
[16:56:59 CET] <Diag> I can try when I get home
[16:57:06 CET] <Diag> I haven't done video yet
[16:57:07 CET] <kepstin> I'm running a 4k monitor with no freesync, and using linux, so I guess I'll never know ;)
[16:57:38 CET] <Diag> After you go freesync you don't go back
[16:58:02 CET] <Diag> No tearing. Ever
[16:58:14 CET] <Diag> Ultra smooth low latency shit
[16:58:42 CET] <kepstin> well, i'm running in wayland, so I don't get tearing. The benefit would just be in the lower latency/reduced judder.
[16:58:58 CET] <Diag> Lol
[16:59:09 CET] <Diag> It legit makes 40fps in games very playable
[16:59:21 CET] <Swervz> I've been thinking of buying an amd gpu for a while but they're just not powerful enough. I already have an overclocked titan xp and Im at the limits of the thing almost already
[16:59:34 CET] <Swervz> would be nice to not have to deal with nvidias shit
[16:59:41 CET] <Diag> I have a Vega64 under a water block
[16:59:48 CET] <azarus> I got a R9 Fury, it does everything and anything I want from it
[16:59:58 CET] <Diag> Dead quiet and hauls ass
[17:00:10 CET] <Diag> And it's been getting faster and faster with every driver release
[17:00:12 CET] <azarus> (but my "want" is probably different from yours)
[17:00:22 CET] <Diag> It's consistently ahead of the 1080 now
[17:00:27 CET] <Diag> Reaching at the ti
[17:00:40 CET] <Diag> There's like 2 games where it stomps the ti
[17:00:45 CET] <Swervz> anyone know why I'm getting [h264_nvenc @ 00000000027e1020] EncodePicture failed!: unsupported param (12) with ffmpeg -i "input.mp4" -c:v h264_nvenc -profile high444p -pixel_format yuv444p -preset default -c:a copy "output.mp4"
[17:00:47 CET] Action: kepstin has an rx560 and plays games in 1080p on his 4k monitor, so yeah.
[17:00:52 CET] <Swervz> Feels like I'm doing something wrong
[17:00:53 CET] <Diag> Gross wtf
[17:01:04 CET] <Diag> Nvenc
[17:01:07 CET] <Diag> There's your problem
[17:01:11 CET] <Swervz> what do you feel is wrong with nvenc?
[17:01:18 CET] <Diag> It's made by nvidia
[17:01:20 CET] <Diag> :v
[17:01:21 CET] <kepstin> Swervz: what gpu is that, a 1080?
[17:01:25 CET] <Swervz> Titan xp
[17:01:42 CET] <kepstin> Swervz: which gpu core/generation is that?
[17:01:50 CET] <Swervz> pascal
[17:02:04 CET] <kepstin> hmm, should be able to do 4:4:4 then.
[17:02:18 CET] <Swervz> it can
[17:02:54 CET] <Swervz> Here are the capabilities reported https://i.imgur.com/i3EEPu6.png
[17:03:07 CET] <Diag> Nvidia probably broke it in the current driver release
[17:03:47 CET] <kepstin> Swervz: can you pastebin the *complete* output? I probably can't help you with it, but maybe someone else will see something.
[17:03:59 CET] <Swervz> Sure
[17:06:14 CET] <Swervz> Diag, They didn't. It works in every other program. Fanboism is not healthy for competition between companies. I buy and use the products that best suit my use case and I suggest that is what everyone else does budget permitting. Being loyal to a company is pointless because all they really care about is getting your money and keeping their shareholders happy regardless of if its Nvidia or AMD.
[17:06:52 CET] <sfan5> >Fanboyism is not healthy for competition between companies
[17:07:04 CET] <sfan5> NVIDIA having less marketshare would result in much better competition though
[17:08:11 CET] <Swervz> NVIDIA will lose market share as amd products improve just like how intel lost marketshare after ryzen release
[17:08:32 CET] <Swervz> kepstin, https://pastebin.com/PW3HKsa2 there you go
[17:09:35 CET] <Diag> Amd products are great, albeit slower graphics performance, software is Faaaaaaar Superior, as with business practices as well
[17:10:32 CET] <Diag> In fact
[17:10:35 CET] <Swervz> What issue do you have with nvidias business practices? I've not been following that.
[17:10:43 CET] <Diag> Nvidia has the majority of the fanboys
[17:10:55 CET] <Diag> Can you give me like 10 minutes I'm driving to my shop
[17:11:53 CET] <Diag> In the meantime
[17:12:02 CET] <Diag> Gameworks and mantle
[17:12:54 CET] <Swervz> Was mantle not succeeded by vulkan?
[17:13:30 CET] <kepstin> Swervz: did you mean to convert that from yuv420p to yuv444p? given the options you have, it looks like it's sending yuv420p video to an encoder set up for yuv444p
[17:14:14 CET] <Swervz> Kepstin, I did not realise it was trying to convert it, yeah source is 420
[17:14:27 CET] <kepstin> well, i think the problem is that it's *not* trying to convert it
[17:14:48 CET] <kepstin> does it work if you just drop the -pixel_format option and let the encoder use the automatic value?
[17:14:51 CET] <Swervz> I guess it would be best to use 444 considering its already undergone one round of chroma subsampling
[17:15:10 CET] <Swervz> no I still get the same error if I drop that
[17:15:21 CET] <kepstin> the best is to leave it as-is at yuv420p
[17:15:33 CET] <sfan5> ffmpeg -i "input.mp4" -c:v h264_nvenc -profile high444p -vf format=yuv444p -preset default -c:a copy -y "output.mp4" works here
[17:17:07 CET] <Swervz> hmm that worked but I get a lot of warnings like "Past duration 0.659645 too large" could be because the input is variable frame rate?
[17:17:17 CET] <Swervz> encoding at 2715FPS though
[17:17:39 CET] <Swervz> vs ~650 on cpu with the verfast preset
[17:18:08 CET] <kepstin> Swervz: that error can happen if vfr was misdetected as cfr. Try adding the '-vsync 0' option.
[17:18:20 CET] <kepstin> or -vsync 2
[17:18:54 CET] <Swervz> does it matter what order the options are in?
[17:18:59 CET] <Swervz> as long as they're after the input
[17:19:22 CET] <kepstin> only if you specify the same option twice - then the later one overrides the first
[17:20:04 CET] <Swervz> looks like -vsync 0 did the trick, 2 just gives the same warnings
[17:21:22 CET] <Swervz> Can I do -vf fps=60 now to output a constant framerate?
[17:27:37 CET] <Swervz> ffmpeg -h encoder=h264_nvenc did not list an arg for it but I know it can be specified
[17:28:58 CET] <sfan5> input fps is not something the user should set
[17:29:09 CET] <sfan5> but you can put the vf there to convert to 60 fps
[17:30:22 CET] <Swervz> yeah that's what I wanted to do
[17:31:21 CET] <Swervz> this whole thing was just to convert a video to constant framerate so adobe premiere can handle it, I tried converting to different formats including lossless avi with cpu but its just too slow
[17:39:33 CET] <kepstin> yeah, the fps video filter should work fine (or, equivalently, the -r output option)
[17:41:06 CET] <Swervz> kepstin, Any idea why I'm getting these warnings now? https://pastebin.com/QJMMLvTX
[17:41:30 CET] <kepstin> Swervz: don't use the -vysnc option if you're using the fps filter
[17:41:38 CET] <Swervz> ah okay
[17:41:47 CET] <kepstin> Swervz: also, you're using -vf twice - the second overrides the first
[17:42:10 CET] <kepstin> Swervz: to run two filters, you make a single filter chain with both, e.g. "-vf fps=60,format=yuv444p"
[17:42:41 CET] <Swervz> ah I think I tried that before, but without the comma and thats why it failed
[17:43:15 CET] <kepstin> the , in a filter chain means "take all the outputs from the previous filter and hook them to the inputs of the next filter"
[17:43:48 CET] <Swervz> ah okay thankyou
[17:43:57 CET] <Swervz> I thought a space was enough to seperate them at first
[17:44:42 CET] <Swervz> It works perfectly now! Just have to set my desired bitrate
[17:45:25 CET] <Swervz> -rc cbr=50000
[17:45:51 CET] <kepstin> if you're making a temporary file for input to some other tool, you probably want to encode to quality rather than constant bitrate. I dunno if nvenc has a constant quality mode? or even just constant qp?
[17:47:40 CET] <Swervz> Yeah this is what it reports back when I do ffmpeg -h encoder=h264_nvenc https://pastebin.com/7BQiV3Hx
[17:47:52 CET] <Swervz> Although I assumed a really high CBR would have lost less visual quality
[17:47:56 CET] <Swervz> Something like 100Mbps
[17:48:02 CET] <furq> doesn't nvenc have a lossless mode
[17:48:09 CET] <Swervz> It does iirc
[17:48:28 CET] <Swervz> I don't remember how to use it though
[17:55:46 CET] <Swervz> furq, oh Its the lossless preset lol, I was looking in bitrate for it
[17:56:43 CET] <kepstin> I'd read that output you just pasted and see "oh hey, there's an option -preset lossless" ;)
[17:57:13 CET] <Swervz> sometimes I'm just really bad at reading things when there is a ton of text on screen
[17:58:18 CET] <Swervz> I thought my gpu was at its limits but it seems my HDD is the bottleneck again haha
[17:58:52 CET] <kepstin> with lossless? yeah.
[17:59:04 CET] <Swervz> I think I'm either gonna have to buy more ssds or ram and make a ramdisk
[17:59:46 CET] <Swervz> I've been needing more ram anyway for a while so maybe nows the time to buy
[18:00:32 CET] <sfan5> now is definitely not the time to buy RAM if you've followed the price
[18:01:04 CET] <Swervz> Yeah its crazy
[18:01:19 CET] <Swervz> I think I paid just under $100 for 16GB ddr4 3200mhz back in 2016
[18:01:50 CET] <Swervz> although I'm being limited by ram almost daily now for other tasks like virtualization so I may just cave and buy some
[18:04:00 CET] <Swervz> Here's the final command for anyone who wants it ffmpeg -i "input.mp4" -c:v h264_nvenc -profile high444p -vf fps=60,format=yuv444p -preset lossless -c:a copy -y "output.mp4"
[18:51:01 CET] <Guest3479> who can please help me here? https://video.stackexchange.com/questions/23304/ffserver-filemaxsize-what-does-it-mean , please son't say that ffserver is not recommended , I know it but I ust this help
[18:54:34 CET] <Swervz> Guest3479, It's to set the max size of the feed file in bytes.
[18:54:40 CET] <Swervz> you can do 0 for no limit
[20:49:04 CET] <dradakovic> What would some common values of -muxrate be, if my parameters for streaming digital radio are -maxrate 256k -minrate 192k -bufsize 256k
[21:05:19 CET] <kepstin> dradakovic: you're using mpeg-ts for this?
[21:06:16 CET] Action: kepstin isn't really sure that any audio codecs respect maxrate/bufsize either.
[21:06:23 CET] <kepstin> i could be wrong about that, tho
[21:07:46 CET] <dradakovic> Yes correct. Allow me to post my pastebin
[21:08:52 CET] <dradakovic> https://pastebin.com/zksPDDZb
[21:09:32 CET] <dradakovic> After lets say 2 hours, the digital radio starts skipping. I was hoping muxrate would somehow solve it
[21:09:36 CET] <Diag> uh
[21:09:39 CET] <Diag> it aint in english
[21:09:49 CET] <dradakovic> Oh yeah those are just comments
[21:09:56 CET] <dradakovic> ignore that
[21:10:28 CET] <dradakovic> I could remove them for clearer readability
[21:11:06 CET] <Diag> what language is that
[21:13:16 CET] <dradakovic> Slovenian
[21:13:18 CET] <dradakovic> https://pastebin.com/mei9bFZm
[21:13:25 CET] <dradakovic> Should be clearer now
[21:14:15 CET] <Diag> waaaaaaaaaait a minute, are you running pirate radio
[21:14:24 CET] <dradakovic> No, we are an ISP
[21:14:29 CET] <Diag> oh what lol
[21:14:29 CET] <dradakovic> we have the contract
[21:14:51 CET] <dradakovic> It is that we are disabling the analog radio and we are sending their stream as digital
[21:14:58 CET] <dradakovic> instead
[21:14:58 CET] <kepstin> dradakovic: what is the source? A realtime capture
[21:15:02 CET] <dradakovic> Yes
[21:15:04 CET] <kepstin> dradakovic: if so, remove the -re
[21:15:11 CET] <kepstin> the -re option might be causing the desync
[21:15:38 CET] <dradakovic> If i do that, my radio starts to instantly skip.
[21:15:47 CET] <dradakovic> At least -re keeps it fine for a while.
[21:15:51 CET] <sfan5> hmm that's an interesting way of doing inline comments in bash
[21:15:56 CET] <dradakovic> Some radios sooner some later
[21:15:58 CET] <sfan5> i've never seen that
[21:16:15 CET] <kepstin> The -re option is for use if you have a non-realtime source (e.g. a local file) that you want to stream out in realtime - it makes ffmpeg sleep while reading the file.
[21:17:51 CET] <kepstin> if your source is actually realtime, the extra sleeps can cause desync or missing input
[21:18:29 CET] <dradakovic> Ok i understand that but if i dont use -re option, the radio is played too fast. As in too many udp packets get sent to the pint that it causes buffer overflow
[21:18:52 CET] <kepstin> it should eventually settle down to match the input speed
[21:19:17 CET] <kepstin> ffmpeg cli tool isn't really designed for realtime streaming, so :/
[21:19:31 CET] <dradakovic> Ahh :(
[21:20:01 CET] <dradakovic> Allow me to show you the graph that we monitor while we broadcast
[21:20:04 CET] <dradakovic> give me a min
[21:20:05 CET] <kepstin> sounds like your issue is that you want the output packets to be paced, and ffmpeg is outputting them in bursts then gaps?
[21:22:52 CET] <sfan5> dradakovic: have you looked into the bitrate option of udp:// ? http://ffmpeg.org/ffmpeg-protocols.html#udp
[21:23:14 CET] <sfan5> setting bitrate=256k&burst_bits=256k sounds like it would do exactly what you need
[21:23:46 CET] <dradakovic> Hmmm, ok thank you for this. I shall try it right away. Let me just show you my graph with and without the -re option.
[21:23:50 CET] <dradakovic> Very cool
[21:24:43 CET] <dradakovic> https://imgur.com/a/TESDC
[21:25:02 CET] <dradakovic> on the left you see with -re option. THen i stopped the radio and tried it without -re
[21:25:10 CET] <dradakovic> Going for bitrate now that sfan5 suggested
[21:28:53 CET] <dradakovic> Alright, i added the bitrate as you suggested sfan5. I will also be keeping the -re option because it seems like i have to have it.
[21:29:07 CET] <dradakovic> It will take hours before i can confirm this worked
[21:29:16 CET] <dradakovic> thank you sfan5 and keepstin so far
[21:29:20 CET] <sfan5> if packet rate is limited by udp:// you won't need -re
[21:29:43 CET] <sfan5> slightly unrelated, but don't your digital radios support mp3?
[21:29:57 CET] <dradakovic> it does. I can convert it to libmp3lame
[21:30:06 CET] <dradakovic> It works the same though
[21:30:12 CET] <sfan5> the stream you're reading is mp3 already so -c copy would work
[21:30:27 CET] <sfan5> asking because mp2 generally results in lower quality
[21:30:33 CET] <dradakovic> Ohh no no, that wouldn't work as i said, we are ISP. So this has to be streamed to a cable network
[21:30:47 CET] <dradakovic> pretty much cable tv
[21:31:05 CET] <sfan5> ah, okay
[21:31:21 CET] <kepstin> if the bitrate option works, please do not use -re, the -re option will cause other problems
[21:31:22 CET] <dradakovic> Gotta be mp2 or mp4 but mp2 is preferable
[21:31:47 CET] <kepstin> in particular, the -re option can cause missing input or buffer problems in input on realtime sources
[21:32:27 CET] <dradakovic> You are right. It causes the missing input.
[21:36:13 CET] <dodo> who can please help me here? https://video.stackexchange.com/questions/23304/ffserver-filemaxsize-what-does-it-mean , please son't say that ffserver is not recommended , I know it but I umst this help
[21:36:30 CET] <dodo> Swervz: why do I have temp file to store the stream?
[21:36:52 CET] <JEEB> Guest94413: ok. then I will just tell you that nobody here mos likely knows anything about ffserver :D
[21:41:13 CET] <derbie_> I know nothing of video/audio compression and streaming. Any good resources for beginners?
[21:41:39 CET] <Guest94413> JEEB: witch server can stream over http with ffmpeg ?
[21:41:43 CET] <klaxa> wikipedia is a good start most of the time
[21:45:24 CET] <derbie_> I'm thinking of making something to: take X sources of videos (youtube, vimeo, MIT, khanacademy, etc.) and serve as one seamless video stream
[21:45:59 CET] <derbie_> with the option of specifying different segments and order
[21:46:12 CET] <kepstin> derbie_: well, you certainly picked a hard problem to start with.
[21:46:26 CET] <derbie_> it should solve some really nasty problem though
[21:46:37 CET] <derbie_> drum roll....
[21:46:39 CET] <derbie_> lost time
[21:47:06 CET] <derbie_> i want to cut out useless information from lecture videos
[21:48:18 CET] <derbie_> kepstin, please elaborate on why it is difficult
[21:48:26 CET] <kepstin> honestly, you're gonna spend more time figuring out segment in/out times and setting up the edits than you would just seeking through it in your player :)
[21:48:45 CET] <derbie_> kepstin, but you do it once for thousands or more
[21:49:08 CET] <Swervz> Is that not what chapters are for
[21:49:17 CET] <derbie_> chapters?
[21:51:44 CET] <Swervz> https://video.stackexchange.com/questions/18970/how-to-add-chapters-sections-markers-to-video-files-to-help-direct-access-sk
[21:53:26 CET] <kepstin> derbie_: if you're doing manual editing anyways, you might want to just get a graphical nle program. This sort of thing can be done with ffmpeg, but it's all kind of a pain to set up commands and scripts.
[21:54:17 CET] <Swervz> Imagine if there was a NLE that let you select clips on the timeline and only mux them into the video instead of encoding them
[21:54:25 CET] <Swervz> assuming its the same codec
[21:54:36 CET] <derbie_> i think the user should aim to mark which content is irrelevant (taking from a few millis to seconds) and cut that out
[21:55:02 CET] <derbie_> the mixing of videos is just a step further than what I'm thinking to do
[21:56:31 CET] <derbie_> was imagining some kind of mass contribution and version control to make continous and the most comprehensive content about a certain topic
[21:57:20 CET] <derbie_> then again i've never edited a video...
[22:00:51 CET] <derbie_> maybe voice recognition + transcripts could make it easier to edit stuff out
[22:01:38 CET] <kepstin> I assume you've already figured out the hard problems of business model (who's paying?) and copyright status, so I'm not gonna discuss those at all.
[22:02:26 CET] <derbie_> open and free
[22:02:51 CET] <kepstin> but for something of the scope you're talking about, i'd basically suggest just hiring a few engineers who already know about video to build the system :/ It's very big for a one-person project.
[22:03:28 CET] <derbie_> i know some java
[22:06:32 CET] <derbie_> at least you said it's possible
[22:07:00 CET] <kepstin> well, the hardest part is complying with the appropriate copyright laws and figuring out how to afford it
[22:07:05 CET] <kepstin> building it is only the hard part ;)
[22:07:58 CET] <kepstin> but if all you really want is to have one person take a few videos on a topic and combine them together into a shorter edited video and repost on youtube or something, the easy way is to just buy a copy of sony vegas or something.
[22:08:18 CET] <kepstin> the slightly harder way is to manually note down times and run a bunch of ffmpeg commands to build the final video
[22:08:42 CET] <derbie_> ^
[22:10:00 CET] <ssdsd> what is the dffrence between -re before -i or -c:v copy ???
[22:11:40 CET] <derbie_> The following could be cut down to "this example is called regression problem" https://youtu.be/UzxYlbK2c7E?t=39m12s to 39:23 don't know the amount would be saved but i feel it would be from 10s to 3s
[22:13:18 CET] <derbie_> Now i'm all excited
[22:17:35 CET] <kepstin> ssdsd: '-re' before '-i' tells ffmpeg to slow down reading the file by sleeping so that it doesn't go faster than realtime.
[22:17:53 CET] <kepstin> ssdsd: '-re' somewhere else in the command... does nothing, i'm suprised it's not an error
[22:18:36 CET] <ssdsd> kepstin: but -re is re-encode the stream/video?
[22:18:46 CET] <kepstin> ssdsd: no.
[22:19:14 CET] <ssdsd> kepstin: how copy can be faster fps than the original video?
[22:19:33 CET] <kepstin> ssdsd: ffmpeg re-encodes the video by default, unless you explicitly tell it to copy
[22:20:14 CET] <ssdsd> kepstin: unless copy or -re , yes?
[22:20:30 CET] <kepstin> no, '-re' doesn't have anything to do with this.
[22:22:31 CET] <kepstin> The only thing the '-re' option does is slow down ffmpeg.
[22:22:35 CET] <ssdsd> kepstin: I not get you , before I ask you if I put -re the ffmpeg re-encode the video and you tell me , no
[22:23:00 CET] <kepstin> ssdsd: the "-re" option does not mean "re-encode". It does not make ffmpeg re-encode the video.
[22:23:12 CET] <kepstin> ssdsd: ffmpeg will re-encode the video unless you use -c copy.
[22:24:15 CET] <ssdsd> so if I dont want that my video re-encode and I dont want to read the video faster than original video fps I need to put ffmpeg -re -c:v copy -i myVideo.avi .....
[22:24:33 CET] <bindi> rtl_fm -g15 -f 98.0M -M wbfm -E deemp | ffmpeg -f s16le -ac 1 -i pipe:0 -acodec libmp3lame -ab 128k -f rtp rtp://192.168.1.123:1234
[22:25:01 CET] <bindi> trying to play rtp://192.168.1.123:1234 on another PC (.123 is the IP of the machine i'm running ffmpeg on), vlc to be specific, yields an error
[22:25:13 CET] <kepstin> ssdsd: Why would you do that? It will just make ffmpeg take a long time to run.
[22:25:31 CET] <kepstin> ssdsd: Are you streaming video?
[22:25:40 CET] <ssdsd> yes i am
[22:25:50 CET] <ssdsd> kepstin: copy or -re , what takes lot of time ?
[22:25:59 CET] <bindi> https://hastebin.com/nejebusaji.tex here's the debug log from vlc
[22:26:29 CET] <kepstin> ssdsd: You didn't explain your original question very well.
[22:27:08 CET] <kepstin> ssdsd: If you have a local file on the hard drive, and you're streaming the output, then you should use the "-re" option (before "-i") to make the video play back in realtime
[22:27:42 CET] <kepstin> ssdsd: You can also use -c copy so that the video doesn't get re-encoded. THis means the command will use less CPU, and the quality will not change.
[22:27:56 CET] <ssdsd> kepstin: greate!
[22:28:55 CET] <ssdsd> kepstin: witch format is better to save mjpeg stream to file on my disk , that takes less cpu and save on quality? avi?
[22:30:38 CET] <kepstin> ssdsd: if you have lots of hard drive space, use "-c copy" and save to whatever container you like, mkv or avi should work.
[22:31:09 CET] <ssdsd> kepstin: have you ever stream video?
[22:31:57 CET] <ssdsd> kepstin: why I must use -re when I takes video from my disk and not when I takes video from live stream? why ffmpeg read video from my disk with larger fps ?
[22:32:27 CET] <kepstin> ssdsd: because your hard drive is fast, so ffmpeg can read the file really fast.
[22:32:56 CET] <kepstin> ssdsd: when you read from a live stream, the video can only be read by ffmpeg as fast as the live stream sends it out.
[22:34:15 CET] <ssdsd> kepstin: can I takes the video file on my disk that I want to stream it and upload to my ram, that will be faster ? on ubuntu ?
[22:35:54 CET] <kepstin> ssdsd: if you're using -re, there's no point...
[22:36:13 CET] <ssdsd> kepstin: last quastion please , do you ever use ffserver?
[22:36:27 CET] <kepstin> ssdsd: nope.
[22:36:40 CET] <ssdsd> kepstin: do you ever stream video?
[22:36:57 CET] <Swervz> That guy in here earlier who was using IRC and driving and said he would be back in 10 minutes never came back...
[22:37:05 CET] <kepstin> i work on software that includes streaming video features, yeah
[22:37:24 CET] <ssdsd> kepstin: witch server do you use to stream video?
[22:37:33 CET] <ssdsd> and witch protocols is support ?
[22:37:59 CET] <kepstin> for non-realtime stuff i just encode mp4 files and put it on http server.
[22:38:28 CET] <kepstin> my realtime stuff is all legacy flash (rtmp) using a customized red5 server, although we're also starting to do some webrtc with kurento iirc.
[22:39:16 CET] <ssdsd> kepstin: "for non-realtime stuff i just encode mp4 files and put it on http server." stream it via mjpeg protocols?
[22:39:20 CET] <kepstin> for most people, i'd probably recommend nginx-rtmp nowadays for live stuff. (it can do hls, dash i think)
[22:39:38 CET] <kepstin> ssdsd: no, just http. No mjpeg anywhere.
[22:39:48 CET] <kepstin> h264+aac in mp4 file
[22:41:51 CET] <kepstin> mjpeg is a terrible streaming format, since it doesn't compress very well.
[22:48:11 CET] <Swervz> Is there anything like the NGU sharp doubling in madVR for ffmpeg?
[22:48:39 CET] <Swervz> It can make some videos look so much better
[22:50:10 CET] <Swervz> Mainly intro videos from old PS1 and PS2 games, the upscaling helps immensely
[22:50:55 CET] <kepstin> Swervz: probably not. I think most madVR stuff is gpu shaders? So someone would have to port it to C for ffmpeg, and it'll be a lot slower
[22:51:06 CET] <kepstin> (or run it in opencl or something, i dunno)
[22:51:35 CET] <Swervz> I was thinking of something you can run offline and have it put out an upscaled video
[22:52:38 CET] <Swervz> The best way I can think of right now is playing it in MPC-HC and then recording it with OBS, the quality loss from re recording it is much lower than the gains you get from the shaders
[22:53:59 CET] <Swervz> I guess you'd be transcoding it anyway with FFMPEG
[23:18:20 CET] <ovidiu> hello
[23:18:38 CET] <ovidiu> I would like to concatenate multiple jpeg files into a video
[23:18:48 CET] <ovidiu> and I used this example
[23:18:49 CET] <ovidiu> http://hamelot.io/visualization/using-ffmpeg-to-convert-a-set-of-images-into-a-video/
[23:19:45 CET] <ovidiu> in my case the command is: ffmpeg -r 16 -f image2 -s 640x480 -i /home/frames/0/%s-video.jpg -vcodec libx264 -crf 25 -pix_fmt yuv420p /home/videos/tl_camera-0.ogv
[23:19:56 CET] <ovidiu> but i've got an error
[23:20:06 CET] <klaxa> i don't think ogv can mux h264
[23:20:09 CET] <klaxa> or can it?
[23:20:14 CET] <klaxa> replace ogv by mkv or mp4
[23:20:18 CET] <ovidiu> : /home/frames/0/%s-video.jpg: Is a directory
[23:20:40 CET] <klaxa> what are your files called?
[23:20:43 CET] <ovidiu> but.. i intended to specify *-video.jpg
[23:21:18 CET] <ovidiu> the following regexp pattern applies: /CAM([0-9]+)__([0-9]{2})_([0-9]{2})_([0-9]{4})_([0-9]{2})_([0-9]{2})_([0-9]{2})-video.jpg/
[23:22:05 CET] <ovidiu> do I have to use %0{n}d instead of ([0-9]{n}) ?
[23:22:18 CET] <klaxa> *something something glob* alternatively: cat /home/frames/0/*-video.jpg | ffmpeg -f image2pipe -r 16 -s 640x480 -i - -c:v libx264 -crf 25 -pix_fmt yuv420p /home/videos/output.mkv
[23:25:20 CET] <ovidiu> cat ?
[23:25:37 CET] <ovidiu> will ffmpeg know to get pictures from stdin?
[23:27:29 CET] <DHE> well you give it a hint by telling it the type is image2pipe
[23:29:08 CET] <klaxa> i think -s 640x480 is also either at the wrong place or unneeded
[23:29:28 CET] <mkdir_> Hi
[23:29:52 CET] <mkdir_> any good places to get .wav files of english words?
[23:31:54 CET] <ovidiu> @DHE thanks a lot
[23:32:00 CET] <ovidiu> it works fine
[23:32:17 CET] <ovidiu> what codec can I use to generate ogv and webm?
[23:40:15 CET] <klaxa> for webm you can use vp8
[23:40:32 CET] <ovidiu> libvpx ?
[23:41:13 CET] <ovidiu> is libtheora available also in ffmpeg?
[23:41:52 CET] <klaxa> yes
[23:42:01 CET] <klaxa> i think that'sthe only codec availble for ogv?
[23:42:10 CET] <klaxa> no idea tbh
[23:42:33 CET] <klaxa> also yes, libvpx-vp8 is the encoder (according to ffmpeg -codecs anyways)
[23:46:39 CET] <TD-Linux> by default ffmpeg will write vp9 into webm (which I recommend)
[23:47:05 CET] <klaxa> ok
[23:47:14 CET] <klaxa> is the encoder "fast" now?
[23:48:28 CET] <sfan5> libvpx is still terribly slow
[23:52:06 CET] <TD-Linux> I would generally recommend choosing a faster encoder speed over vp8, unless you're in a big hurry.
[23:53:03 CET] <utack> at least row-mt should work now, thanks to the new libvpx 1.7 from a few days ago
[00:00:00 CET] --- Tue Jan 30 2018
More information about the Ffmpeg-devel-irc
mailing list