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

[burek]

[00:00:04 CET] <TanaPanda> i'm currently using: ffmpeg -stream_loop -1 -i input.mp4 -map 0:v -vcodec copy -f mpegts udp://192.168.6.2:20
[00:00:17 CET] <TanaPanda> hmmm
[00:00:19 CET] <TanaPanda> I had a thought
[00:01:51 CET] <BtbN> Why are you transcoding the audio to whatever (probably horrible) default mpeg-ts has?
[00:02:00 CET] <BtbN> Or does it just not have audio?
[00:03:00 CET] <TanaPanda> it has audio but I am taking this one step at a time
[00:03:07 CET] <TanaPanda> I would like to get the video to stream properly
[00:08:38 CET] <TanaPanda> nvm my thought was no good
[00:30:24 CET] <wodim> how do I make it so the animation frames here in the overlay loop forever? ffmpeg -i cat.mp4 -i animation/%02d.png -filter_complex overlay -y output.mp4
[00:30:31 CET] <wodim> I know stream_loop, but "1" makes it repeat once
[00:30:40 CET] <wodim> and a high number makes the overlay keep moving when the video has already ended
[00:43:17 CET] <wodim> solution: add eof_action=endall to overlay
[08:30:39 CET] <familiyaF> Hi, I am writing a mac application, where I want to integrate VideoToolbox, is there any guideline available for hardware filter support integration. Any direction would be much appreciated.
[11:43:09 CET] <Radioactive> hello, I was wondering if anyone can guide me on FFmpeg and thread safety, as in which functions are definitely not thread safe for audio decoding in particular, and if i have multiple instances of say format contexts and codec contexts on different threads, if they're still referencing shared memory making operations on them not thread safe?
[11:44:04 CET] <Radioactive> also does avformat_open_input allocate a new instance each time or could it return an existing instance if one has been made already?
[11:45:59 CET] <Radioactive> cc JEEB
[11:46:02 CET] <JEEB> lavf/lavc contexts should be separate, but if there's some underlying library utilized for TLS or whatever, those might be not-threadsafe
[11:46:08 CET] <Radioactive> that was fast :D
[11:46:25 CET] <JEEB> so if you are handling different inputs from different threads, that should be OK as long as you don't cross the beams
[11:47:10 CET] <Radioactive> what do you mean by cross beams exactly JEEB?
[11:48:25 CET] <Radioactive> an issue i'm having is that different streams from a file are being decoded with different format context/codec context objects on different threads, but i'm still getting crashes indicating a race condition of some kind
[11:48:45 CET] <JEEB> oppen debug time
[11:48:49 CET] <JEEB> *oppan
[11:50:00 CET] <Radioactive> it's difficult to parse the crash, it happens deep within an ffmpeg callstack, but usually happens inside of av_read_frame or avcodec_decode_audio4 (yes I know it's deprecated but also happens if i switch to using send_packet/receive_frame) while they're both being called from different threads
[11:50:52 CET] <JEEB> and the lavf/lavc contexts are all handling just their own thing?
[11:51:02 CET] <JEEB> anyways, $dayjob - no real time :P
[11:52:21 CET] <Radioactive> as far as i know, unless things like avcodec_find_decoder avcodec_open2 avformat_open_input etc.. return shared stuff
[12:26:21 CET] <docwhite> Hello! I was trying to do something I'm struggling to be able to search on Google. I basically have some .ts fragments that have audio and video. I would like to set the audio to a stream with 0 channels. Is it possible?
[12:28:12 CET] <docwhite> The reason being to simulate a case that breaks a GStreamer command we use (ges-laungh-1.0)... It panics and hangs when it's processing an HLS where one fragment all of a sudden has an audio stream with 0 channels (whereas before it had > 1). Just trying to reproduce it, that's why I was asking.
[13:05:46 CET] <wodim> can't I apply the fps filter to an input?
[13:33:09 CET] <tth> hello
[13:34:38 CET] <tth> I'm trying to encode 16bits pnm files to .mp4, with no luck -- source: http://la.buvette.org/vrac/00042.pnm -- result: http://la.buvette.org/vrac/foo.mp4 -- any hint to do that ?
[13:35:01 CET] <furq> tth: pastebin the command line and full output
[13:43:34 CET] <tth> furq: http://la.buvette.org/vrac/encoding.txt
[13:44:25 CET] <kepstin> looks like an issue in ffmpeg's pnm decoder, even just playing that file in ffplay looks wrong, while loading it in an image viewer is fine
[13:44:54 CET] <BtbN> What even is pnm? Animated png?
[13:45:17 CET] <pink_mist> I thought that was apng
[13:46:25 CET] <furq> BtbN: one of the netpbm formats
[13:46:37 CET] <furq> or uh
[13:46:41 CET] <furq> the collective name for all of them i guess
[13:46:56 CET] <BtbN> Never heard of that before
[13:47:09 CET] <kepstin> classic unix image format
[13:47:22 CET] <kepstin> many of the variants are text based
[13:50:49 CET] <furq> ppm is a neat intermediate file format for piping
[14:40:36 CET] <Zusor> I'm adding text to a video and copying the audio over isn't working. This is generated using ffmpeg-python. Here's the command and output. https://pastebin.com/fPwF1Gbx
[14:42:00 CET] <DHE> you're using -map, so you'll have to explicitly request the audio be pulled in as well. add -map 0:a
[14:42:38 CET] <DHE> wait...
[14:43:37 CET] <DHE> you want 0:v for the video description in the filter_complex path as well...
[14:45:38 CET] <Zusor> Do you have any idea on how to do that in ffmpeg-python. Here's the code I'm using to generate the command https://pastebin.com/EqkJ4Urc
[14:49:09 CET] <DHE> no. but from the CLI it is calling a filter with [0] as an input. that should be [0:v]
[14:49:59 CET] <DHE> or if you need a black screen, there's a "filter" that takes no inputs and produces a black rectangle of video as an output that would be better suited
[14:55:23 CET] <faLUCE> hello. Why if I do:   ffmpeg -i file.flac -acodec copy out.flac the bitrate changes from 1553kb/s to 124kb/s ?
[14:55:35 CET] <faLUCE> I thought flac was lossless
[15:05:17 CET] <kepstin> faLUCE: you're doing copy, so it's not even changing. either the original file had a bunch of junk in it that didn't get copied (e.g. large png cover art?) but was included in the bitrate calculation, or the source bitrate calculation was just wrong
[15:05:49 CET] <kepstin> 1553kbps is higher than i've seen a normal flac - iirc that's actually higher than uncompressed cd audio?
[15:06:34 CET] <furq> yeah it is but you can have 24-bit flac
[15:06:37 CET] <faLUCE> kepstin: it's 5.1 dolby. anyway, doesn't matter. the relevant thing is to be sure that ffmpeg doesn't recompress
[15:06:40 CET] <furq> or that
[15:07:02 CET] <furq> what's reporting that bitrate
[15:07:21 CET] <kepstin> faLUCE: are you using any other options or is that *exactly* the ffmpeg command line you ran?
[15:07:43 CET] <kepstin> if you use -c copy when trimming a flac, the duration is not updated correctly, which means the bitrate will be reported wrong on the output file.
[15:37:23 CET] <void09> what can i use to cut comercials from a .ts capture, while keeping dvbsubs synced ?
[15:38:09 CET] <JEEB> in theory dropping TS packets while rewriting timestamps and discontinuity counters would be the thing
[15:38:21 CET] <JEEB> I used to use murdoccutter for some stuff
[15:38:28 CET] <void09> i tried mkvtoolnix, splitting the file into parts by timestamps, then joining them back. i find the last/4th segment has the subs late by 5 frames
[15:38:38 CET] <JEEB> kind of wish there was an OSS thing like that which did minimal touching
[16:13:17 CET] <void09> avidemux is pretty good, but it did not implement subs for some reason
[16:13:59 CET] <void09> well, not perfect I guess. I am getting continuity errors with ffmpeg when scanning a certain avidemux cut job
[16:14:26 CET] <void09> The ones where I have to cut just from the beginning and end are fine, but the ones with commercials inbetween, not so perfect.
[16:21:52 CET] <JEEB> void09: avidemux etc still do a full demux/remux
[16:22:06 CET] <void09> hm ?
[16:22:10 CET] <void09> oh
[16:22:22 CET] <JEEB> if youjust want to cutmpeg-ts you don't need that
[16:22:22 CET] <void09> well you have to do it if you want to cut stuff out
[16:22:25 CET] <JEEB> no
[16:22:28 CET] <void09> no ?
[16:22:35 CET] <JEEB> only if ypu n3ed to cut within gops
[16:23:05 CET] <JEEB> but broadcast gops are short and commercials usually end up with rap in beginning
[16:23:45 CET] <void09> yep, the last movie i cut had commercials always beginning and ending within a gop
[16:23:49 CET] <void09> i mean, with a gop
[16:24:15 CET] <void09> probably some not dumb encoder (mpeg2). There is this tv station that does not do this though, always fixed gop
[16:24:21 CET] <void09> fixed duration
[16:24:51 CET] <JEEB> so what you need is something to at least cut packetsput. extra points for fixing discont counters and timestamps & pcr
[16:25:18 CET] <JEEB> the less ypu touch the less you have a chance to fuck up
[16:25:44 CET] <void09> I like perfect jobs.. and it bothers me I cannot do a perfect job :(
[16:26:07 CET] <void09> do you know of tutorials for cutting .ts ?
[16:26:58 CET] <JEEB> 188 byte packets, 0x47 start code
[16:27:12 CET] <JEEB> if you mena an app, look at something like murdoc cutter
[16:27:43 CET] <JEEB> although as i said, i'd love a kiss mpeg-ts cutter open source
[16:27:51 CET] <BtbN> If in doubt, head and tail will work.
[16:27:54 CET] <JEEB> but e-no-time
[16:28:39 CET] <JEEB> BtbN: yea if your capture strats at start code just bs=188 that
[16:32:40 CET] <void09> JEEB: got any english link to it? it's all japanese websites
[16:33:03 CET] <JEEB> it's ajapanese app but I just don't know anything else similar :p
[16:33:25 CET] <void09> no english translation in the app?
[16:33:51 CET] <JEEB> nope, although i think main buttons werw just generic english words
[16:34:57 CET] <void09> ok, where can I download it ? :)
[16:35:34 CET] <JEEB> also last time it was checked the download php script added php at the beginning or end of the zip :D
[16:35:48 CET] <JEEB> like the script got barf'd into the buffer
[16:36:26 CET] <JEEB> the official site is that it's a direct
[16:36:28 CET] <JEEB> thing
[16:43:11 CET] <celebrate> Hi, what is the recommended format to encode videos using ffmpeg for whatsapp/facebook?
[16:43:45 CET] <celebrate> When using the following, initial video output is fine however once it is compressed by facebook/whatsapp there is a audio/video sync issue :(
[16:43:46 CET] <celebrate> let command = ffmpeg()        .input(tempFilePath)        .videoBitrate(2500)        .videoCodec('libx264')        .format('mp4')        .output(targetTempFilePath)
[16:46:03 CET] <void09> facebook encodes the video itself, no?
[16:46:08 CET] <celebrate> it does as well yes
[16:46:20 CET] <celebrate> but there seems to be a problem with the way i'm encoding it first
[16:46:29 CET] <void09> so why encode it one more time ? the web is full of crappy quality stuff encoded 100 times :P
[16:46:39 CET] <celebrate> Because i'm displaying videos on my platform first
[16:47:00 CET] <celebrate> imagine an app where users can upload videos - i initially compress them so that theyre way smaller to download
[16:47:18 CET] <celebrate> then a user has an option to download this video himself, and later they can share it to any platform they want - this is where the issue happens
[16:47:30 CET] <durandal_1707> crappy quality
[16:48:01 CET] <celebrate> i imagine theres a standard/recommended format for compressing videos that intend to be shared on facebook/whatsapp no?
[16:49:51 CET] <celebrate> praying to the ffmpeg gods that someone will help 🙏🏻
[16:52:43 CET] <void09> I still don't get it : P
[16:52:50 CET] <void09> let facebook compress it, and then download it back ? :D
[16:58:57 CET] <celebrate> its about sharing my content
[16:59:00 CET] <celebrate> from my platform to another
[16:59:21 CET] <celebrate> and this is all scalable.. uploading to facebook then downloading it back isn't scalable
[16:59:47 CET] <celebrate> make sense?
[17:29:54 CET] <kepstin> celebrate: you should always upload the original video to services like that where possible
[17:30:11 CET] <kepstin> since they transcode it anyways, so you want as few lossy transcode steps as possible
[17:38:33 CET] <celebrate> that makes sense
[17:38:37 CET] <celebrate> but some of these files are really big
[17:38:42 CET] <celebrate> 50-> 100 MB on phone
[17:38:48 CET] <celebrate> which is why i also do the transcoding
[17:41:03 CET] <celebrate> regardless..what is the optimized format (+ audio/video encoding) for such sharable videos, via whatsapp/fb?
[17:41:11 CET] <celebrate> i can try that out and see
[17:42:42 CET] <kepstin> there's no such thing, all these services re-encode every video format no matter what you provide
[17:44:48 CET] <kepstin> if the source files are bigger than you want to keep around, i suppose a reasonable option would be to do a re-encode with x264 to a high quality (use crf mode with a value that doesn't cause any noticable quality loss)
[17:45:48 CET] <celebrate> so this is what im doing now
[17:45:49 CET] <celebrate> let command = ffmpeg()        .input(tempFilePath)        .videoBitrate(2500)        .videoCodec('libx264')        .format('mp4')        .output(targetTempFilePath)
[17:45:55 CET] <celebrate> you can see i'm using x264
[17:46:35 CET] <DHE> 2500 kbit seems kinda low unless you're at 720p or lower resolution
[17:46:36 CET] <kepstin> yeah, the problem is you're setting a bitrate, don't do that, you want to use crf mode instead
[17:46:47 CET] <kepstin> for archiving, anyways
[17:47:13 CET] <celebrate> ok so you recommend using crf instead of bitrate
[17:47:19 CET] <celebrate> or at least trying
[17:48:39 CET] <kepstin> also you should consider just writing the ffmpeg command lines yourself instead of whatever library you're using, it's possible the library is hiding some stuff from you and we can't really help you when things go wrong unless you share the real command line anyways
[17:49:35 CET] <kepstin> ['ffmpeg', '-i', tempFilePath, '-crf', '18', '-c:v', 'libx264', '-f', 'mp4', targetTempFilePath]
[17:49:44 CET] <kepstin> or something like that :)
[17:50:05 CET] <kepstin> (you also have to deal with audio, of course, maybe throw a -c:a copy in there.
[17:50:06 CET] <kepstin> )
[17:51:27 CET] <celebrate> i'm using fluent-ffmpeg
[17:51:41 CET] <celebrate> https://github.com/fluent-ffmpeg/node-fluent-ffmpeg/
[17:51:55 CET] <celebrate> but yes probably writing down the whole command is not a bad idea
[17:52:06 CET] <celebrate> appreciate it!
[17:52:29 CET] <celebrate> what's the 18 for?
[17:52:34 CET] <celebrate> after the -crf
[17:53:06 CET] <kepstin> it's an arbitrarily-scaled number that corresponds to a quality setting.
[17:53:22 CET] <kepstin> lower numbers are higher quality, higher numbers are smaller files.
[17:53:44 CET] <kepstin> 18 is a good starting point for a video that you want to archive with minimal quality loss
[17:54:28 CET] <kepstin> with that "fluent" interface you're gonna have to use the .outputOptions() method to set all these options manually anyways, so it doesn't really give you anything :)
[17:56:18 CET] <celebrate> yeah haha was just looking at that
[17:56:41 CET] <celebrate> but going off of what you wrote
[17:57:46 CET] <celebrate> something along the lines of this?
[17:57:50 CET] <celebrate> .outputOptions('-i tempFilePath -crf 18 -c:v libx264 -f mp4 targetTempFilePath');
[17:59:31 CET] <kepstin> no, what i gave was a complete command line
[18:00:13 CET] <celebrate> but i have to use the fluent library
[18:00:22 CET] <kepstin> why?
[18:00:22 CET] <celebrate> i modified yours a bit
[18:00:31 CET] <kepstin> but anyways, assuming you use the fluent interface to set everything you have, and you remove the bitrate, then i think it would be .outputOptions(['-crf', '18'])
[18:00:33 CET] <celebrate> because its hooked up to some serverless function provider
[18:00:52 CET] <celebrate> This method allows passing any output-related option to ffmpeg. You can call it with a single argument to pass a single option, optionally with a space-separated parameter:
[18:00:58 CET] <celebrate> it mentiosn "space-seperated"
[18:01:12 CET] <kepstin> use the array format.
[18:01:17 CET] <celebrate> oh nvm
[18:01:19 CET] <celebrate> youre right
[18:01:20 CET] <celebrate> :)
[18:01:21 CET] <celebrate> yep
[18:01:31 CET] <celebrate> ok cool will give it a try, thanks!
[18:21:50 CET] <wodim> can I use scale to upscale or downscale a video as necessary, making sure neither of the two dimensions is bigger than x?
[18:22:29 CET] <wodim> in other words, make it fit in a square of 500x500 but upscaling if necessary
[18:22:34 CET] <wodim> preserving AR
[18:26:24 CET] <asterismo_l> hi, i need some help compiling ffmpeg without SSE3 and SSE4 instruction set
[18:26:58 CET] <asterismo_l> i'm getting this error when converting a gif to a mp4: ffmpeg: common/cpu.c:251: x264_cpu_detect: Assertion `!(cpu&(X264_CPU_SSSE3|X264_CPU_SSE4))' failed
[18:28:05 CET] <asterismo_l> so i tried to compile ffmpeg with --disable-sse --disable-sse2 --disable-sse3 --disable-ssse3 --disable-sse4 --disable-sse42 but the error i think it is thrown by x264 library
[18:28:11 CET] <JEEB> well yea
[18:28:18 CET] <wodim> then you have to compile the x264 library?
[18:28:36 CET] <asterismo_l> so i compiled x264 with --disable-asm and replaced those libs and the error still
[18:30:02 CET] <asterismo_l> wait, i still libx264-148 in my system
[18:30:49 CET] <JEEB> also that assert isn't on current master nor the previous one I had cloned
[18:31:19 CET] <JEEB> x86: Remove some legacy CPU detection hacks
[18:31:21 CET] <JEEB> in 2017
[18:31:27 CET] <JEEB> 344699fd386890ac1cf80a70a68a3ae16767ed62
[18:31:50 CET] <JEEB> > Some misconfigured virtualized systems could sometimes also  trigger this code path and cause assertions
[18:35:43 CET] <asterismo_l> this is the library files in debian: https://packages.debian.org/stretch/amd64/libx264-dev/filelist
[18:36:47 CET] <asterismo_l> compiling x264 does not create libx264.so
[18:38:46 CET] <asterismo_l> do i need it?
[18:39:45 CET] <wodim> docs in ffmpeg.org are from the current stable version or git?
[18:39:52 CET] <JEEB> git master
[18:39:59 CET] <JEEB> there are some doxygen generated docs that are per branch
[18:40:11 CET] <wodim> scale=force_divisible_by is not in 4.2.1 ?
[18:40:37 CET] <wodim> docs would be much more useful if they said in which version filters/options/etc were added :/
[18:41:20 CET] <JEEB> yea, the specific option is in master only
[18:41:28 CET] <JEEB> before that there was a hack to use negative numbers
[18:41:42 CET] <JEEB> like w=1280:h=-2
[18:41:56 CET] <JEEB> would set it to matching value according to aspect ratio, and make sure it was divisible by 2
[18:41:58 CET] <wodim> I have "scale=w='max(600,iw)':h=max'(600,ih)':force_original_aspect_ratio=decrease", could I shove a negative number into that?
[18:42:06 CET] <wodim> yeah x264 is complaining about divisilibity
[18:42:08 CET] <JEEB> (or you could do math)
[18:42:27 CET] <JEEB> I think when I last did that myself I used math, because it was before the negative number hacks
[18:44:37 CET] <JEEB> wodim: since you're already knee-deep into the math stuff (max etc) you might as well go with that -- and there's the example @ https://ffmpeg.org/ffmpeg-filters.html#scale
[18:44:45 CET] <JEEB> > Increase the size, making the size a multiple of the chroma subsample values:
[18:45:00 CET] <JEEB> because that's what you need, multiple of chroma subsampling
[18:45:24 CET] <wodim> hmmm okay thanks
[18:46:15 CET] <JEEB> the last one is specifically mod2, but generally speaking the chroma subsampling is why "some codecs" require specific sizes :P
[18:55:02 CET] <celebrate> hey, so the crf thing worked but also kind of didn't
[18:55:21 CET] <celebrate> i the crf value was low (18) it worked, but as i started moving it up that seemed to be causing the issues
[18:55:31 CET] <celebrate> however the whole idea is to be able to compress the video files
[18:55:40 CET] <celebrate> so perhaps i need to play around w/ the audio as well?
[19:00:05 CET] <wodim> JEEB, yeah, but I guess it doesn't really matter whatever I do with w or h when later force_original_aspect_ratio=decrease will change either and possibly end with an odd number
[19:00:19 CET] <wodim> unless I'm misundersatnding something
[19:01:27 CET] <wodim> I'll end up building from git, seems like less trouble
[19:12:09 CET] <tjader> Hello, I'm trying to use ffmpeg to convertt a bunch of png files to a webm slideshow, but my output is coming out short
[19:12:29 CET] <tjader> I'm using ffmpeg -framerate 1 -pattern_type glob -i '*.png' -lossless 1 Fazenda.webm
[19:12:58 CET] <tjader> I have 60 png files, and ffmpeg identifies the output as being a minute long, but the output webm is only 38 seconds long
[19:14:39 CET] <tjader> https://pastebin.com/wX5EAeK8 here's the full output
[19:18:53 CET] <kepstin> celebrate: if you want to have a high quality video that can be uploaded to other services, then it needs to be high quality and therefore fairly big
[19:19:11 CET] <kepstin> if you want a streamable low quality file, that's a different encode
[19:19:54 CET] <cehoyos> tth: Patch sent: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/254310.html
[19:21:48 CET] <cehoyos> void09: FFmpeg is not the right tool if you don't want to re-encode, ProjectX is old software that does exactly what you want.
[19:28:31 CET] <celebrate> my main issue is just the fact that some of the files lose audio/video sync when they are processed by facebook/whatsapp
[19:28:51 CET] <celebrate> i guess the solution would be as you mentioned..if they export the video they'll get the original oe
[19:28:55 CET] <celebrate> one*
[19:29:19 CET] <celebrate> whereas if they are viewing it on my platform, they'll see the compressed version i created
[19:29:22 CET] <celebrate> makes sense i guess
[19:29:32 CET] <celebrate> ideally would have just one file that would work universally
[20:15:47 CET] <Filarius> Sigh, i'm trying to write Python stript to use 2 ffmpeg to x264 compress frames sequence and get lossy raw images storing frames just in memory without saving h264 to file
[20:16:06 CET] <Filarius> just saving to file and read raw frames from compressed files works okay
[20:16:45 CET] <Filarius> but I can't make ffmpeg to read from stdin and write to stdout at same time
[20:17:41 CET] <Filarius> with this i'm trying to just get compressed stream
[20:17:43 CET] <Filarius> ffmpeg -y -report -f rawvideo -pix_fmt gray -s:v 1920x1080 -r 60 -i - -c:v libx264 -preset fast -crf 28 -f mpegts -
[20:19:16 CET] <Filarius> here Python script just not able to get pipes
[20:19:27 CET] <Filarius> its in Windows OS btw
[20:21:41 CET] <kepstin> you'll need to close the pipe going to ffmpeg's stdin so ffmpeg sees the eof and flushes its output.
[20:22:10 CET] <kepstin> dunno if that's exactly the issue you're hitting, but it's one common reason for an ffmpeg pipe to hang.
[20:22:37 CET] <Filarius> i want to stream many frames without closing pipe
[20:23:23 CET] <Filarius> gray -> h264 -> gray  frames in realtime
[20:24:04 CET] <kepstin> well, if you keep pushing frames in, then eventually frames will come out the other end.
[20:24:19 CET] <kepstin> but x264 has large internal buffers, so it'll take a while.
[20:24:56 CET] <kepstin> alternately you could run it in zerolatency mode, but then it has significant reduction in encoding efficiency
[20:24:56 CET] <Filarius> also debugging in Python show me "-1" instead of stdin and stdout buffers
[20:25:11 CET] <Filarius> like they are not exist
[20:26:05 CET] <kepstin> what's the actual reason you're doing this, anyways?
[20:26:27 CET] <Filarius> I will try to make another example where I had error from ffmpeg about its can't find proper output formant while stdin stdout in Python debugger there was exists
[20:26:59 CET] <Filarius> well
[20:27:20 CET] <kepstin> also you're not providing a frame size (resolution) on the input
[20:27:39 CET] <kepstin> the default probably is wrong, which might be part of your issue.
[20:27:48 CET] <Filarius> there -s:v 1920x1080
[20:28:01 CET] <Filarius> its works okay if I saving to file
[20:28:04 CET] <kepstin> that's an output option that scales the video
[20:28:15 CET] <Filarius> no
[20:28:29 CET] <kepstin> oh, wait, i got mixed up, yeah it's before the -i
[20:28:31 CET] <kepstin> never mind
[20:28:43 CET] <Filarius> okay :)
[20:28:52 CET] <kepstin> right, as an input option, -s acts like an alias of the -video_size demuxer option
[20:29:43 CET] <Filarius> well, i'm playing with neural networks building, and I need relatively fast option to compress raw image with x264 and decompress it to get lossy image to push to neural network
[20:30:06 CET] <kepstin> so, do you care about mix of frame types - I, P, B?
[20:30:18 CET] <kepstin> gop size? motion estimation?
[20:30:45 CET] <kepstin> video codecs when compressing video of motion do different things on different frames within a group of frames
[20:30:56 CET] <Filarius> i just care about good/bad image differnce, not care about what type of frame it is
[20:31:08 CET] <kepstin> x264 tracks motion between frames and reduces detail on stuff that's moving fast for example, because people can't see detail there
[20:31:33 CET] <kepstin> are you encoding completely independent images, or an actual continuous video?
[20:31:37 CET] <Filarius> bad better to have all kinds of frames to compare, not only key-frames
[20:31:50 CET] <kepstin> and do you need it to be representative of how actual video encoding works?
[20:32:07 CET] <Filarius> i need to work with continuous
[20:33:02 CET] <kepstin> if you're dealing with continuous video, and you want it to be representative, i'd recommend just pre-encoding the video, rather than doing it realtime. Then you just feed the original video, and the result of decoding the other video, as two inputs to your thing.
[20:33:24 CET] <kepstin> less fuss, and probably faster too
[20:33:39 CET] <TanaPanda> how do I send a video that is already the format i want into ffmpeg and out to an IP address?
[20:34:00 CET] <kepstin> TanaPanda: it depends on what network protocol you want to use.
[20:34:43 CET] <Filarius> right now I just saving 1 single frame to file and read it, but ffmpeg start/stop is taking long time, and i need it really many times to do
[20:34:47 CET] <TanaPanda> UDP\
[20:34:51 CET] <kepstin> (which mostly means "what network protocol does the thing you're sending to accept?")
[20:35:07 CET] <TanaPanda> I want to send the video to UDP://192.168.6.2:20
[20:35:18 CET] <TanaPanda> and yes I know 20 is way below 1024 but its what I have to use
[20:35:20 CET] <kepstin> Filarius: you really want to encode the whole video all at once to a single file
[20:35:38 CET] <kepstin> TanaPanda: sending to arbitrary ports is fine, that doesn't need special priviledges or anything
[20:36:01 CET] <TanaPanda> I have made it seem to work before however when I try to open the stream via VLC i get nothing
[20:36:14 CET] <kepstin> Filarius: once you do that, then you can read the original source and the re-encoded video in parallel and do stuff a frame at a time quickly and easily.
[20:36:25 CET] <TanaPanda> I dont want to change anything about the file
[20:36:33 CET] <TanaPanda> other than to stream it
[20:37:26 CET] <kepstin> TanaPanda: well, that's mostly a question of setting up the receiving end, not an ffmpeg question. and if you don't want to touch the file, you don't even need ffmpeg, even netcat can read a file and send over udp
[20:37:58 CET] <kepstin> (although that would run faster than realtime, you'd probably need pacing)
[20:37:58 CET] <Filarius> kepstin, every new frame will be made new based on knowladge of previous frames, i can't just make only one video
[20:38:29 CET] <Filarius> i mean based on knowladge of how x264 make losses on previouse frames
[20:38:33 CET] <kepstin> Filarius: I have no idea what you're getting at then. because when doing video encoding with modern techniques, the video encoder references future frames.
[20:38:44 CET] <kepstin> so this literally causes a time paradox ;)
[20:39:21 CET] <kepstin> that's (one of the reasons) why the encoder buffers a lot of frames, btw, so it can see into the future
[20:40:07 CET] <kepstin> you *can* turn this off, that's what -tune zerolatency does - but at a significant cost to encoding efficiency, so it's not really representative of general video encoding.
[20:41:35 CET] <kepstin> TanaPanda: if you use ffmpeg as the source for this, note that it can't do a direct file copy, at a minimum it will remux, so you need to specify the output container (even if you want the same as the input)
[20:41:36 CET] <tth> cehoyos: many thanks !
[20:41:53 CET] <TanaPanda> hmmm
[20:42:09 CET] <TanaPanda> This is the first time I have attempted to use ffmpeg so dumb it down please and thank you
[20:42:27 CET] <kepstin> TanaPanda: the ffmpeg command will look something like "ffmpeg -re -i input.file -c copy -f mpegts udp://192.168.6.2:20"
[20:42:46 CET] <Filarius> look, I generate frame and send to encoder, take lossy frame, by knowning how lossy one looks like I making another good frame and send to encoder again, and etc many-many times until i get some signal whats things going good
[20:42:58 CET] <kepstin> where the "mpegts" has to be replaced with the actual container format you want to use for stream. But mpegts is an ok choice commonly used with udp.
[20:43:34 CET] <kepstin> Filarius: meanwhile, the encoder can't encode the current frame until it gets the next frame, because it looks into the future. so you get stuck with nothing making progress.
[20:43:52 CET] <Filarius> its not problem if there will be several frames buffered inside of ffmpeg, i will just will keep send "blank" frames to wait my good frame will go out to me
[20:44:11 CET] <kepstin> Filarius: if you're encoding the *same* frame over and over again, then you need to *re-initialize the encoder* each time so it's starting in the same state
[20:44:31 CET] <TanaPanda> so using that command I am able to start the stream and open the strema in VLC but no picture
[20:44:31 CET] <kepstin> otherwise it'll be referencing the previous encoded frame when making the new one, which kinda makes your results invalide
[20:45:10 CET] <kepstin> Filarius: i still have no idea about the *why* you're trying to do this, which might help me suggest something that would actually work.
[20:45:29 CET] <TanaPanda> and using wireshark I can see the packets moving
[20:46:28 CET] <kepstin> TanaPanda: if that ffmpeg command ran without error, then it's successfully sending the video, and you're either running into network issues or the player isn't set up correctly :/
[20:47:02 CET] <TanaPanda> if I do the same thing but through VLC wire shark shows the packets as mpeg ts instead of UDP and i get picture
[20:47:04 CET] <Filarius> lets speak about.. sheeps. I paining sheeps and keep sending to ffmpeg, and then I will see how sheeps looks like on output i will change how I paining sheeps, and will wait until another-pained sheeps appears from ffmpeg, and etc until i will find i like my sheeps :)
[20:47:08 CET] <TanaPanda> which is confusing me
[20:47:58 CET] <Filarius> painting
[20:48:12 CET] <kepstin> Filarius: meanwhile, x264 is going "ok, got a picture, lets wait until i get another one, maybe i'll be able to copy/paste the same sheep in both and save some bits"
[20:48:21 CET] <Filarius> sorry, English not my best language
[20:48:55 CET] <kepstin> Filarius: so *why* are you doing this?
[20:50:40 CET] <kepstin> Filarius: normally, you paint a bunch of pictures of sheep, and then send them all to the encoder and say "please make my sheep look as good as you can but make it no bigger than x bits" and later it comes back with a group of bits that when decoded turn into all of your sheep paintings again, but when you look close you realize that some of the sheep look the same between pictures.
[20:52:45 CET] <Filarius> i want to speedup process of making new frames, whatever how many I will make frames to be encoded, I will need only small piece of one frame to process, and i will need to start next iteration
[20:53:38 CET] <kepstin> Filarius: why?
[20:53:45 CET] <kepstin> what's going on?
[20:54:06 CET] <kepstin> give me the one sentence summary at the top of the scientific paper you're writing saying what you hope to accomplish :)
[20:54:36 CET] <kepstin> right now, what you're doing seems to have no bearing with how real video codecs actually work, so i don't know why a video codec is involved at all
[20:54:43 CET] <TanaPanda> excelleration of photon at 10x the speed of light to travel in time
[20:56:03 CET] <Filarius> neural network need lossy frames to learn on. And also its used to generate frames. Every time its learns - it will make another frame. 1 step of learning needs only part of one frame. If I will make it learn on several frames without makeing fresh ones - this learning will do nothing good, or even make it worser
[20:56:12 CET] <kepstin> Filarius: a real video encoder doesn't operate on invidual frames, instead it operates on entire groups of frames at a time.
[20:56:26 CET] <kepstin> Filarius: so you need to design your stuff to work with that.
[20:57:00 CET] <kepstin> Filarius: you've explained "how", but i asked "why"
[20:57:01 CET] <Filarius> i mean, after network changes inside - its also will start making another frames than was before
[20:57:33 CET] <Filarius> why I need it ?
[20:57:35 CET] <kepstin> why does this neural net exist? what are the frames it generates used for?
[20:57:46 CET] <kepstin> why does it need to see the lossy frames?
[20:57:58 CET] <TanaPanda> sounds like he is making/designing something
[20:58:24 CET] <Filarius> well, steganography, as example
[20:59:23 CET] <kepstin> ok, so if your goal is "i want to put a pattern into this video that doesn't get taken away when using this encoder when encoding with these settings"
[20:59:35 CET] <kepstin> then you need to operate on a group of frames at a time, not at a single frame at a time
[20:59:45 CET] <kepstin> because otherwise the results are meaningless :/
[21:00:16 CET] <kepstin> since the video encoder has its own internal context and memory between frames that you are interacting with
[21:00:21 CET] <Filarius> just I want NN to learn behaviour of H264 encoder, not what rocket science guys do in related publications - they mostly use normal (gauss) noise instead
[21:01:05 CET] <Filarius> but its looks like hard way - takes more time
[21:01:26 CET] <Filarius> to make "fresh lossy image"
[21:01:30 CET] <kepstin> if you want the nn to learn how a read h264 video encoder operates, then you have to have it look at entire groups of pictures at a time, since the video encoder operates on entire groups of pictures at a time.
[21:02:09 CET] <kepstin> if you want to make a "cool glitch effect that degrades the image", then don't bother with a nn at all, just run the video through an h264 encoder with settings that make it look bad.
[21:03:03 CET] <kepstin> (note also that by default x264 doesn't even have fixed groups of frames, it dynamically decides when to start a new group based on image analysis)
[21:03:15 CET] <Filarius> I tryed that, while NN is "stupid" - it can learn on groups, but to make it really "smart", I think, every small step of learning must be made on freshy generated pictures
[21:03:41 CET] <kepstin> if you want it to learn on individual pictures, then you might as well just use a still image encoder
[21:03:49 CET] <kepstin> like jpeg or something.
[21:04:03 CET] <kepstin> x264 can run as a still image encoder, but you have to re-initialize it each image
[21:04:18 CET] <kepstin> (which isn't very slow if you use it as a library instead of starting up ffmpeg cli)
[21:04:36 CET] <kepstin> but the result of that won't be representative of *video*
[21:04:39 CET] <kepstin> since it's still images
[21:04:40 CET] <Filarius> like i said before, 1 frame of video provide many steps to learn
[21:04:53 CET] <Filarius> while i need only 1 step
[21:06:20 CET] <kepstin> there's a fundamental mismatch between what you're doing and how video encoders work. your thing works fine with still images, but video encoders work on multiple frames together, so you need to *generate* multiple frames together.
[21:06:24 CET] <Filarius> well, I can encode several frames, and take only one from middle, or choose random, then it will learn "video frames"
[21:06:41 CET] <kepstin> since a change in a previous or future frame of x264 input can effect what it'll output for the current frame
[21:07:06 CET] <kepstin> affect*
[21:07:06 CET] <Filarius> I can just make NN to look at previous frame too
[21:07:33 CET] <kepstin> you should make your nn treat a unit of work as "an entire series of frames"
[21:08:00 CET] <Filarius> I will, but right now I just trying to make something what works
[21:08:00 CET] <kepstin> you could start with something like 8 or 16 frames or whatnot, and use the options to the video encoder to switch it to fixed gop size that matches
[21:09:04 CET] <kepstin> that's only kinda representative, since real video for many applications doesn't used fixed gop (although much streaming and broadcast does have fixed gop)
[21:09:35 CET] <Filarius> while I right now i just can't make ffmpeg to give me lossy images without using saving to file as inbetween so I will not need to restart ffmpeg each time
[21:09:43 CET] <kepstin> in the mean time, if you want to treat x264 as a still frame encoder, and you are using ffmpeg cli, then you need to restart ffmpeg each time.
[21:10:28 CET] <kepstin> you could do it much faster using the library interface, btw., but i suppose if you're writing python that could be tricky.
[21:11:12 CET] <kepstin> hmm. I suppose the other workaround to get it to act as a still image encoder on continuous input is to set the gop size to 1 frame
[21:11:15 CET] <kepstin> and disable lookahead
[21:11:31 CET] <Filarius> but if people make livestreams - then video stream appears without need to restart ffmpeg
[21:11:44 CET] <kepstin> right, because they're generating a continuous video.
[21:12:01 CET] <kepstin> not a "generate one frame, wait for it to encode, then send the next frame"
[21:12:18 CET] <kepstin> instead they're pushing frames into the encoder continuously and not caring about what happens after.
[21:12:52 CET] <Filarius> yes, and I also can make continuous video, filling buffer with frames what I will not use for processing
[21:13:16 CET] <Filarius> like street traffic where I count only red cars
[21:13:23 CET] <kepstin> the contents of those filler frames will affect how x264 encodes the frames you care about
[21:13:42 CET] <kepstin> since ffmpeg will use them as part of the group of pictures that it's encoding
[21:13:45 CET] <Filarius> they will be kind of what i need, no problems
[21:14:27 CET] <kepstin> remember, changing any single frame within a group of pictures can affect how the video encoder encodes past and future frames
[21:15:02 CET] <kepstin> so as an optimization problem it's pretty hard, you can't just say "oh, this frame is good" and go on, because the changes you make to the next frame will result in x264 doing somehting different on the previous frame
[21:15:12 CET] <Filarius> so, can we be more close "how to do it" and more far from "why i (do not) need this"
[21:16:38 CET] <Filarius> yep, I know in h264  previous frames is affects on next up to key-frame
[21:17:50 CET] <Filarius> I will work on this after I will be able to make that "streaming"
[21:18:57 CET] <kepstin> My internet dropped there, oops. Switched to my phone so typing slow now
[21:20:06 CET] <kepstin> alright. so if you want to make your application "work", but produce results that aren't representative of real video, then use the "-tune zerolatency" option on the encoder
[21:20:28 CET] <kepstin> that will cause the encoder to only use the past rather than also looking into the future when optimizing frames
[21:21:29 CET] <kepstin> there might still be other sources of latency in that pipeline, but in theory that should get you to "one frame in, wait a bit, one frame out"
[21:21:50 CET] <Filarius> well, first i need to make that "streaming" at all, and only after it will be available - make tweeks and design what use idea of different kind of x264 frames
[21:22:22 CET] <Filarius> but thanks for reminding about zerolatency
[21:22:26 CET] <kepstin> since you seem to still be working on still frames at this point, you should also set "-g 1" so a "group of pictures" is only one frame long
[21:22:38 CET] <kepstin> that way the encoder won't keep (as much) context from frame to frame
[21:23:09 CET] <kepstin> that way you're basically optimizing against (almost, but not quite) a still image encoder
[21:23:12 CET] <kepstin> only I frames
[21:23:19 CET] <kepstin> again, not representative of real video
[21:24:50 CET] <kepstin> many streaming services do actually use a fixed gop of around 2-5 seconds, assuming 30fps is reasonable you should eventually be targeting working on around 60-150 frames at a time instead of one frame at a time
[21:25:14 CET] <kepstin> encoding fixed gop with x264 might need special options if you're not reinitializing the encoder between runs, feel free to ask for help about that
[21:26:01 CET] <kepstin> but even getting up to around 10-30 frames would likely start to give reasonable results
[21:26:15 CET] <kepstin> iirc bluray specs use really short gop size that might be close to that? have to check.
[21:27:18 CET] <Filarius> but first I need make it possible to write good frames and get lossy frames without saving to file (as I expect this must take less time to get freshy lossy frame), right now I can't make it works
[21:27:25 CET] <kepstin> and also note that you're optimizing against a *specific implementation* of an encoder using *specific options* so the result won't really be generalizable.
[21:28:08 CET] <Filarius> not only "implementation" but also "specific encoding options", yep i know it
[21:28:36 CET] <kepstin> running an ffmpeg encoder piped into an ffmpeg decoder works fine for that, read your programming standard library documentation about how to hook up pipes between processes.
[21:29:20 CET] <kepstin> normally you'd start one process, then start the next process and pass the stdout pipe from the first to the stdin of the next
[21:30:59 CET] <Filarius> i said, I made Python script what was able to write to pipe, and to read to pipe, but in Windows i see what when I use both annon pipes at same time - module what allow to make easy communication with cli application just do not see stdin/stdout available, i found it while debugging.
[21:31:40 CET] <kepstin> you wouldn't be using both pipes from any single ffmpeg?
[21:31:57 CET] <kepstin> you send raw frames to stdin on one ffmpeg, then read raw frames from stdout on the second ffmpeg
[21:32:20 CET] <Filarius> both pipes at same time from same instance of cli application - not before this time
[21:34:14 CET] <kepstin> i'm not sure what you're talking about. you have two cli applications, and each has only one pipe connected to your program.
[21:34:44 CET] <kepstin> your program ’ ffmpeg encoder ’ ffmpeg decoder ’ your program, right?
[21:34:54 CET] <Filarius> yep
[21:35:22 CET] <Filarius> i will start separate "minimal example script" to do right now
[21:35:37 CET] <kepstin> so you make sure you use the "-tune zerolatency" (since otherwise the encoder won't do anything until you close the first pipe), then write a frame to the first ffmpeg, then read from the second ffmpeg.
[21:36:46 CET] <Filarius> right now I just trying to make 1 ffmpeg, what will read raw frames and return me h264 stream, its just not works at all
[21:37:23 CET] <kepstin> first, get it working where you close the stdin pipe
[21:38:08 CET] <kepstin> if that doesn't work, nothing will. after that it's configuring the encoder correctly to not buffer frames internally.
[21:39:16 CET] <Filarius> closing stdin - works
[21:39:35 CET] <Filarius> at last i got some data from stdout after it
[21:40:19 CET] <kepstin> make sure when you're doing this that the ffmpeg cli log output is going somewhere (a terminal?) that you can read it
[21:40:39 CET] <Filarius> -report
[21:41:05 CET] <kepstin> so, check it and make sure it says it encoded one frame without any errors :)
[21:41:31 CET] <Filarius> "cur_dts is invalid" on each frame
[21:42:13 CET] <kepstin> hmm, that might be because you didn't use the -framerate input option. doesn't really matter for this use case since presumably you don't care much about accurate frame timestamps.
[21:42:32 CET] <Filarius> aaaand i do not see any erros on log related to output
[21:43:53 CET] <kepstin> right, so the next step is to make sure that your program is flushing any buffers it has after each frame. there's usually a flush method or something on the stream object.
[21:53:04 CET] <Filarius> hm, good idea but seems here flush is defined but not implemented, will goodle related topix
[21:53:36 CET] <Filarius> calling flush() do nothing
[22:07:31 CET] <Filarius> no effect whatever i flush stdout or stdin, only after closing stdin was closed - ffmpeg return result
[22:13:05 CET] <Filarius> if you have some ideas - throw me, I will check it tomorrow, its time to sleep in here
[22:57:54 CET] <kepstin> did you actually set the -tune zerolatency option?
[22:58:08 CET] <kepstin> but yeah, other than that, i dunno what else it could be.
[23:00:55 CET] <jemius> Compression is fascinating. My 18.7 MB video is 15.1 MB large when converted to grayscale
[23:03:11 CET] <kepstin> yeah, the way the YUV colourspace works, most of the hard-to-encode detail is in the "Y" channel, which represents lightness. The U/V channels, which determine the colour, take up much less space.
[23:06:15 CET] <kepstin> (the simplest way to convert a YUV video to greyscale is to simply drop the U/V channels completely and use the Y channel as the greyscale value)
[23:07:19 CET] <Filarius> also i had some research - losses on UV is much less than in Y
[23:11:16 CET] <kepstin> the most common video pixel format, yuv with 4:2:0 sampling, actually encodes the U and V channels at ¼ the resolution (half width, half height) of the Y channel.
[23:11:35 CET] <TanaPanda> Hello again
[23:11:57 CET] <TanaPanda> I finally got my stream to work in ffmpeg
[23:13:08 CET] <TanaPanda> but how do I make it loop?
[23:14:09 CET] <kepstin> the "-stream_loop -1" option (when placed before an input) will cause ffmpeg to read that input in a loop.
[23:14:26 CET] <kepstin> -1 means infinite, otherwise it's a count of times to loop
[23:14:33 CET] <TanaPanda> ok thanks
[23:14:38 CET] <TanaPanda> the command i got to work is
[23:14:39 CET] <TanaPanda> ffmpeg -loglevel debug -max_interleave_delta 15000000 -rtbufsize 128000k -threads 0 -re -i /home/pi/Desktop/ActiveChannel/Property_LCI.mp4 -codec copy -s 720x576 -q10 -shortest -f mpegts udp://192.168.6.2:20?pkt_size=1316?buffer_size=65536
[23:14:45 CET] <TanaPanda> incase anyone else cares to know
[23:15:37 CET] <kepstin> TanaPanda: the "-s 720x576" and "-q10" output options on that doesn't do anything, you can't resize video or change quality when using -codec copy
[23:15:54 CET] <TanaPanda> ok. i'll try dropping those and see if it still works
[23:15:57 CET] <TanaPanda> thank you
[23:16:21 CET] <TanaPanda> and it does still play
[23:16:23 CET] <TanaPanda> awesome
[23:16:30 CET] <jemius> Filarius, what is UV?
[23:18:36 CET] <Filarius> okay, will go sleep and will return to digging solution somewhere tomorrow. I see its can be a proble with flushing stdout/in in Python for ffmpeg
[23:18:43 CET] <kepstin> jemius: U and V are two arbitrary axis in a color plane. U is (roughly) blue-green, and V is (roughly) red-green. https://en.wikipedia.org/wiki/YUV has some diagrams and examples
[23:18:53 CET] <Filarius> UV in YUV420P
[23:19:04 CET] <TanaPanda> so would I add -stream_loop -1 after -re?
[23:19:20 CET] <kepstin> TanaPanda: or before the -re, the only thing that matters is that it's before the -i
[23:19:29 CET] <Filarius> and -tune zerolatency with 500+ frames still not working
[23:19:48 CET] <kepstin> Filarius: probably some buffering issue then. I have no idea how pipes work on windows
[23:19:54 CET] <kepstin> you might consider using linux? :/
[23:20:22 CET] <Filarius> i consider make it cross-platform, but starting from Windows :)
[23:22:28 CET] <TanaPanda> now I can cut VLC out of my process I love it
[23:23:34 CET] <TanaPanda> think that bit rate and buffer rate will work on just about any mp4 file?
[00:00:00 CET] --- Sat Dec 14 2019