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

[burek]

[00:01:33 CEST] <dorvan> Peste_Bubonica: fast test... make a directory, mount a ramdisk (mount -t tmpfs tmpfs /DIR), make 2 directories inside SRC, DST, copy src in ramdisk/SRC, and convert it to ramdisk/DST and check the time.
[00:01:58 CEST] <BtbN> no need for that
[00:02:10 CEST] <BtbN> just use yuvtestsrc2 and output to /dev/null
[00:02:14 CEST] <BtbN> if you want to benchmark purely the encoder
[00:02:22 CEST] <dorvan> BtbN: it's not a need, it's a test to bypass hd I/O
[00:02:52 CEST] <dorvan> if you want to benchmark only the encoder...
[00:03:11 CEST] <Peste_Bubonica> dorvan, ok, I will try that
[00:03:28 CEST] <dorvan> mine it's a test to check the really I/O performance of his system, making the work
[00:03:31 CEST] <Cracki> disk I/O will not be the bottleneck
[00:03:52 CEST] <Cracki> only uncompressed video hits the limits of currently available mass storage I/O
[00:03:57 CEST] <BtbN> ffmpeg -f lavfi -i testsrc2 -c:v hevc_nvenc -pix_fmt yuv420p -f null -
[00:04:03 CEST] <Cracki> ^
[00:04:07 CEST] <dorvan> Cracki: you can't say, because you don't no how is using his system
[00:04:19 CEST] <Cracki> ¯\_(Ä)_/¯
[00:04:26 CEST] <BtbN> gives me ~2800fps on my 1050 here.
[00:04:39 CEST] <Peste_Bubonica> beast ram # du -hs /mnt/ram/input.mkv
[00:04:39 CEST] <Peste_Bubonica> 4.7G    /mnt/ram/input.mkv
[00:04:54 CEST] <Cracki> what resolution is testsrc2? 720x5?? ?
[00:05:04 CEST] <BtbN> 320x240 by default
[00:05:08 CEST] <Cracki> ic
[00:05:17 CEST] <BtbN> using 1080p is probably a better test
[00:05:36 CEST] <dorvan> BtbN: I confirm
[00:05:38 CEST] <Cracki> linear scaling would give ~100 fps
[00:05:40 CEST] <Peste_Bubonica> 4600fps
[00:05:44 CEST] <Peste_Bubonica> BtbN, with your test
[00:05:55 CEST] <dorvan> Peste_Bubonica: great!
[00:06:11 CEST] <BtbN> 1920x1080 gives ~220 fps
[00:06:27 CEST] <BtbN> ffmpeg -f lavfi -i testsrc2=size=1920x1080 -c:v hevc_nvenc -pix_fmt yuv420p -f null -
[00:06:28 CEST] <Peste_Bubonica> GPU at 18%
[00:06:38 CEST] <dorvan> :-)
[00:06:46 CEST] <BtbN> you have to look at the video engine load. It's seperate from GPU usage
[00:06:58 CEST] <Peste_Bubonica> ~390fps
[00:06:59 CEST] <BtbN> Not sure if nvidia-smi even shows it.
[00:07:01 CEST] <dorvan> try to change the format
[00:07:11 CEST] <Peste_Bubonica> at 1920x1080
[00:07:18 CEST] <dorvan> and repeat BtbN's test
[00:07:31 CEST] <Peste_Bubonica> now it goes to 400fps and become stable
[00:07:41 CEST] <dorvan> good...
[00:08:01 CEST] <Peste_Bubonica> i can't find it on nvidia-smi
[00:08:20 CEST] <Peste_Bubonica> 57w of TDP, 22% GPU load, 53 celsius
[00:08:33 CEST] <BtbN> you might have to look in nvidia-settings. Not sure if you can even read it on linux
[00:08:40 CEST] <BtbN> GPUz on Windows shows it
[00:09:18 CEST] <Peste_Bubonica> I have an 4k file here, 6.8GB h264
[00:09:19 CEST] <dorvan> BtbN: show only partial data
[00:09:44 CEST] <Peste_Bubonica> this file don't plays well on my TV, I think that I will try to reencode it, to see if it works better
[00:10:02 CEST] <Peste_Bubonica> many h265 files works well on this TV, but this h264 don't
[00:10:07 CEST] <Peste_Bubonica> and it plays nice on my PC
[00:10:24 CEST] <BtbN> hardware players are picky. And usually quite broken
[00:10:31 CEST] <dorvan> Peste_Bubonica: check the encoder speed, but it's like a dragster test in the desert... you have to check the max perf of your system can do "really" in the city :-)
[00:11:44 CEST] <dorvan> this include all the system bus transfers and bottlenecks, ramdisk can help you to remove all removable
[00:11:49 CEST] <Peste_Bubonica> sorry by the noob question, but what is the difference for 10bit and 8bit?
[00:12:08 CEST] <Peste_Bubonica> -pix_fmt yuv420p10
[00:12:22 CEST] <dorvan> BtbN: does not answer 2bits :-)
[00:12:28 CEST] <c_14> Peste_Bubonica: 2 bits
[00:12:39 CEST] <dorvan> c_14: ahahaha
[00:12:44 CEST] <Peste_Bubonica> LOL
[00:12:48 CEST] <c_14> Peste_Bubonica: more bits per pixel
[00:13:06 CEST] <Sgeo__> Does YouTube use ffmpeg or other code to convert incoming videos?
[00:13:31 CEST] <dorvan> Cracki: are you there?
[00:13:56 CEST] <c_14> Peste_Bubonica: 8bit means each color channel has 255 values, 10bit has 1023 values per color channel
[00:14:18 CEST] <c_14> Eh, 256 and 1024 obviously
[00:14:25 CEST] <c_14> the range is 0-255 and 0-1023
[00:14:32 CEST] <JEEB> Sgeo__: they have a custom code base based on FFmpeg libraries
[00:14:33 CEST] <dorvan> c_14: this seems the 10bit it's more lossless then 8bit?
[00:14:39 CEST] <BtbN> Sgeo__, they are supposedly using some heavily modified, _ancient_ version of ffmpeg.
[00:15:00 CEST] <Sgeo__> Oh. So it's not likely to be good at converting videos that ffmpeg chokes on?
[00:15:29 CEST] <c_14> dorvan: depends on how many colors your input chip can detect, but it usually doesn't matter
[00:15:37 CEST] <c_14> It just helps with quantization loss and compression
[00:16:04 CEST] <dorvan> c_14: the first clear and self closing answer of the day: thanks :-)
[00:26:52 CEST] <dorvan> ffserver it's alive in the ffmpeg development?
[00:27:01 CEST] <BtbN> no
[00:27:05 CEST] <BtbN> it's dragged along
[00:27:08 CEST] <BtbN> don't use it
[00:28:03 CEST] <dorvan> BtbN: thanks, I haven't used it.
[00:28:19 CEST] <BtbN> nginx-rtmp is a commonly used alternative
[00:28:39 CEST] <dorvan> I see....
[00:29:34 CEST] <dorvan> but I'm unsure to have another server behind the streamer...
[00:30:29 CEST] <dorvan> same problem: realtime,live streaming.... with nginx-rtmp i can have an api as single source...
[00:31:03 CEST] <dorvan> fragments seems are not a solution...
[00:31:30 CEST] <dorvan> mjpeg can be, I searching for right params...
[00:32:38 CEST] <BtbN> If you want to stream to a browser, there really is no solution for low latency
[00:32:50 CEST] <BtbN> use two second segments HLS/DASH, that's the best you'll get
[00:32:55 CEST] <dorvan> exactly....
[00:34:55 CEST] <dorvan> BtbN: i've already used... i can't make it works correctly, after some time video stop, or show same segments in a loop...
[00:35:23 CEST] <Cracki> I haven't looked into it yet... are ffmpeg libs sufficient to write a program that generates RTP packets?
[00:36:05 CEST] <Peste_Bubonica> dorvan, 70fps in a h264 to h265 yuv420p
[00:36:08 CEST] <Cracki> (so, I'm interested in a custom RTP/RTSP/RTCP server/source)
[00:36:08 CEST] <Peste_Bubonica> 4k
[00:36:35 CEST] <dorvan> Peste_Bubonica: seems good...
[00:36:57 CEST] <dorvan> Peste_Bubonica: calc Mb/s : FPs
[00:37:25 CEST] <dorvan> Cracki: welcome to my problem :-)
[00:37:36 CEST] <Cracki> actually no
[00:37:50 CEST] <dorvan> Cracki: https://trac.ffmpeg.org/wiki/StreamingGuide#Latency    but same start point :-)
[00:38:14 CEST] <dorvan> Cracki: https://trac.ffmpeg.org/wiki/StreamingGuide#StreamingasimpleRTPaudiostreamfromFFmpeg
[00:38:19 CEST] <Cracki> I'm actually interested in sticking to standards and I can control both endpoints, I don't have to mess with what browsers can do or not do
[00:38:38 CEST] <dorvan> Cracki: "FFmpeg can stream a single stream using the RTP protocol. In order to avoid buffering problems ...."
[00:38:40 CEST] <Cracki> but thanks for the links, that tells me ffmpeg is enough
[00:39:22 CEST] <Cracki> "single stream" is bad, I'd want 1+ video and 1+ audio
[00:39:35 CEST] <dorvan> exactly :-) right question, right answer..... (in that wiki there is the options to stream an mp4 :-) )
[00:43:13 CEST] <Fenrirthviti> WriteN, RTMP send error 10054 <-- anyone have a resource handy for those error codes perchance?
[00:43:22 CEST] <Fenrirthviti> I used to have one, but can't for the life of me find it again
[00:45:18 CEST] <Cracki> 10054 is reset by peer, iirc
[00:45:22 CEST] <Cracki> windows error codes
[00:45:47 CEST] <Fenrirthviti> ah, hmm.
[00:52:33 CEST] <dorvan> BtbN: so how to force the refresh of segments sequence?
[01:39:48 CEST] <dorvan> What about on splitting and concatenating the ffmpeg input streams to provide filter elaboration? any tips & tricks?
[01:40:03 CEST] <dorvan> always for realtime/live elaboration
[01:40:29 CEST] <dorvan> always for realtime/live processing*
[02:38:02 CEST] <ZeroWalker> well now i can build ffmpeg with libx264, but not using msvc for some reason, it never detects libx264
[04:43:22 CEST] <Cracki> looking for hardware H.264 _decode_ performance comparisons for current amd and nvidia GPUs. anyone got links? I'm still searching
[09:02:03 CEST] <m4t> hi, i'm using ffmpeg 3.3 to record an rtsp stream. it's pretty simple; -vcodec copy, and -acodec aac, since the rtsp stream is pcm_mulaw. i'm seeing occasionally the output .mp4 files will be sizeable (hundreds of MB), but fail to play (with mpv) with "[ffmpeg/demuxer] mov,mp4,m4a,3gp,3g2,mj2: moov atom not found". i can reproduce the corrupted .mp4 by doing something like 'killall -9 ffmpeg' while it's
[09:02:06 CEST] <m4t> recording the rtsp stream.
[09:02:31 CEST] <m4t> i'm thinking it's because ffmpeg didn't write a valid header to the stream, which the mediainfo command seems to indicate as well.
[09:03:00 CEST] <m4t> is there a way to have ffmpeg periodically write a valid header mid-stream, so that if the stream suddenly dies, the video will still be mostly intact and playable?
[09:04:09 CEST] <furq> use a different muxer
[09:04:51 CEST] <furq> mpegts is specifically designed for this sort of thing
[09:04:54 CEST] <furq> mkv should work as well
[09:05:11 CEST] <m4t> furq: cool, seems simple enough
[09:05:28 CEST] <m4t> currently they're shown (per file) as "ISO Media, MP4 Base Media v1 [IS0 14496-12:2003]"
[09:10:04 CEST] <m4t> just changing the output from .mp4 to .m2ts seems to have done the trick. thanks furq.
[09:26:35 CEST] <Cracki> m4t, incomplete mp4, if the moov atom is missing, is hard/impossible to recover. for mp4, there's a segmented/fragmented muxing mode. that helps
[09:26:47 CEST] <Cracki> (if you must use mp4)
[09:27:12 CEST] <Cracki> I'd go with mpeg transport streams too
[09:43:21 CEST] <m4t> Cracki: thanks. i think i'm going to stick with either mkv or m2ts regardless. i noticed that i can actually get a smaller audio track by using flac instead of aac or raw pcm_mulaw.
[09:43:40 CEST] <m4t> m2ts seems to be OK with flac...not sure if that's proper though
[09:45:34 CEST] <m4t> actually nvm. it pretended to but mediainfo shows no audio track and mpv is silent :|
[09:45:37 CEST] <m4t> mkv it is :-)
[10:04:04 CEST] <Cracki> aac *can* be higher bitrate than flac, but then I'd say that was overkill
[10:13:13 CEST] <m4t> i was turning the 64kbit/s 8000hz mono pcm_mulaw to -acodec aac -b:a 32k. flac seems to be ~26kbit/s
[10:13:46 CEST] <m4t> ¯\_(Ä)_/¯
[10:20:01 CEST] <Cracki> omg that's very compressed
[10:20:23 CEST] <Cracki> I'm not aware of ever having handled pcm_mulaw
[10:24:08 CEST] <furq> it's usually used for speech
[10:24:08 CEST] <Cracki> oh if you're compressing speech, play with opus
[10:24:08 CEST] <furq> you could probably use 8kbps aac or something
[10:24:08 CEST] <furq> but at that bitrate you might as well just use flac
[10:24:14 CEST] <Cracki> aye
[10:24:30 CEST] <m4t> i might play with opus. i'd rather have it lossless tbh though.
[10:24:41 CEST] <m4t> it sounds crappy enough as it is :|
[10:24:42 CEST] <furq> yeah there's not much point going from 26kbps to 6kbps
[10:25:09 CEST] <furq> or however low opus will go for 8khz mono
[10:26:54 CEST] <Cracki> if the source is 8khz 8bit mulaw... ¯\_(Ä)_/¯
[10:26:54 CEST] <m4t> yep
[10:26:54 CEST] <Cracki> more bits for the video
[10:27:06 CEST] <furq> he's copying the video stream anyway
[10:27:44 CEST] <m4t> unrelated, is anyone familiar with a *cheap* way to do h.264 -> h.265 transcoding in real time? i spent many hours looking at the specs of all the raspberry pi like boards, and a bunch of barebones cameras etc. from aliexpress. couldn't come up with anything that seemed suitable.
[10:28:03 CEST] <Cracki> I have this image in my head of an elephant and a mouse being squeezed in a box and they together take the cube shape
[10:28:15 CEST] <furq> there's certainly nothing that'll do it well
[10:28:16 CEST] <Cracki> how cheap?
[10:28:16 CEST] <m4t> some of the chips *did* have h.265 hw encode, but the sdk is under nda and/or unusable
[10:28:31 CEST] <m4t> i dunno. like < $50
[10:28:32 CEST] <Cracki> repacking quantized coefficients maybe
[10:28:40 CEST] <furq> there's definitely nothing that will actually reduce the bitrate and keep the same quality
[10:28:46 CEST] <furq> unless your h264 encoder is really awful
[10:29:15 CEST] <Cracki> why even transcode to 265?
[10:29:23 CEST] <m4t> limited bandwidth
[10:29:30 CEST] <m4t> & disk space
[10:29:42 CEST] <Cracki> that's only gonna save you half the data rate, or give you better quality
[10:29:46 CEST] <furq> x264 will outperform all of the consumer hevc hardware encoders
[10:29:50 CEST] <Cracki> ^
[10:29:58 CEST] <furq> it's much better than nvenc hevc, which is one of the better ones
[10:30:18 CEST] <m4t> x265 you mean?
[10:30:21 CEST] <furq> no i mean x264
[10:30:25 CEST] <m4t> oh
[10:30:47 CEST] <m4t> when you say outperform, you mean quality per bitrate? really?
[10:30:50 CEST] <furq> yeah
[10:30:52 CEST] <m4t> hah
[10:30:53 CEST] <Cracki> recent graphics cards have hevc encode in hw that's supposed to be realtime for 2-4k res
[10:31:05 CEST] <furq> bear in mind this is x264, not any other h264 encoder
[10:31:35 CEST] <furq> but if you're thinking about credit card sized boards, the hw encoding on those is generally awful
[10:31:38 CEST] <m4t> i don't really know enough about the subject, just the marketing of h.265 being same quality in half the bitrate
[10:31:45 CEST] <m4t> which apparently is more hype than truth
[10:31:50 CEST] <m4t> yeah...
[10:31:54 CEST] <furq> well it's somewhat true if you compare the reference encoders
[10:31:56 CEST] <Cracki> it's *possible* with hevc
[10:32:07 CEST] <Cracki> but it requires lots of crunch during encode
[10:32:08 CEST] <m4t> and, there is likely no out of the box transcoding utility that can handle an rtsp stream, like i need to
[10:32:09 CEST] <furq> but the reference encoders are a very long way from the state of the art
[10:32:30 CEST] <furq> and also the gap is necessarily less if you have realtime constraints
[10:33:05 CEST] <Cracki> afaik the raspi has h.264 hw encode, but I'm not aware of 265 ip being in there
[10:33:12 CEST] <furq> at the same encoding speed, x264 is roughly as good as x265
[10:33:28 CEST] <furq> x265 only pulls out in front when it's running slower than x264 -preset veryslow
[10:33:29 CEST] <Cracki> :P 265 is a kind of superset of 264
[10:33:55 CEST] <Cracki> larger allowed blocks and such
[10:34:36 CEST] <Cracki> I wonder when they'll just encode optical flow pyramids rather than blocks of a limited size...
[10:35:29 CEST] <furq> also yeah the pi doesn't do hevc encode
[10:35:38 CEST] <furq> but if it did it would probably be terrible
[10:35:45 CEST] <furq> the avc encoder is barely better than a joke
[10:35:53 CEST] <bencoh> it's better off without it yeah
[10:36:07 CEST] <m4t> a lot of the newer android set top boxes coming out of china have soc's with hevc encode
[10:36:15 CEST] <bencoh> people would start using otherwise :p
[10:36:16 CEST] <m4t> but without an sdk or utility it's worthless to me
[10:36:26 CEST] <Cracki> a bunch of single board computers also gained hevc encode...
[10:36:42 CEST] <Cracki> it's added to a lot of arm cortex A processors
[10:36:44 CEST] <furq> i wouldn't worry too much about it
[10:36:47 CEST] <m4t> hmm do you know of any off the top of your head? it was several months ago when i looked into this
[10:36:56 CEST] <Cracki> all the mobile phone stuff wants it
[10:36:59 CEST] <furq> that kind of thing generally just does the bare minimum to create some kind of hevc compliant bitstream
[10:37:06 CEST] <m4t> yea
[10:37:10 CEST] <Cracki> I was searching the net just now
[10:37:12 CEST] <Cracki> nothing conclusive
[10:37:20 CEST] <furq> it won't come close to what a well-optimised encoder can do
[10:37:41 CEST] <Cracki> decoders are trivial. encoders... silicon is hard.
[10:37:43 CEST] <m4t> i bet the ambarella chips are decent. https://www.ambarella.com/news/105/122/Ambarella-Introduces-H22-a-4K-Ultra-HD-SoC-for-the-Next-Generation-of-Drones-and-Sports-Cameras
[10:37:45 CEST] <bencoh> just like h264 back 5~7 years ago
[10:37:48 CEST] <BtbN> nvenc is probably near the top-end of hardware encoders
[10:37:51 CEST] <BtbN> and it's still bad
[10:37:58 CEST] <m4t> those are what's in the gopro iirc
[10:38:04 CEST] <furq> yeah and nvenc hevc is barely better than nvenc h264
[10:38:09 CEST] <Cracki> hw-accelerated compression is an option
[10:38:14 CEST] <m4t> (well, same brand)
[10:38:19 CEST] <Cracki> hw does the motion estimation, sw uses that
[10:38:36 CEST] <Cracki> a large part of the cpu time is spent on ME
[10:39:31 CEST] <Cracki> companies like mainconcept make codecs for video production and those are gpu (opencl?) accelerated
[10:40:07 CEST] <BtbN> GPUs are generally pretty useless for video encoding
[10:40:52 CEST] <Cracki> well they're massively parallel and can do the ME part
[10:41:14 CEST] <Cracki> not saying to use the fixed function encoders
[10:41:56 CEST] <m4t> what does ME stand for?
[10:42:05 CEST] <furq> motion estimation
[10:42:15 CEST] <BtbN> Isn't that what x264 uses opencl for? It's useless there as well, and sometimes even slower/worse quality.
[10:42:19 CEST] <m4t> oh ok, thx
[10:43:17 CEST] <Cracki> x264 doesn't use opencl at all
[10:43:18 CEST] <Cracki> afaik
[10:43:25 CEST] <bencoh> there was a project
[10:43:32 CEST] <furq> it can use it for lookahead
[10:43:36 CEST] <Cracki> dealing with gpus means dealing with latency during the transfer.
[10:43:41 CEST] <Cracki> gpu programming is no magic bullet.
[10:43:44 CEST] <bencoh> I'm not sure it has been merged (?)
[10:43:50 CEST] <Cracki> it has to be worth it to move data off-ram
[10:43:56 CEST] <furq> opencl lookahead has been upstream for ages
[10:44:00 CEST] <bencoh> ah
[10:44:13 CEST] <furq> there was a gsoc project ages ago for opencl ME
[10:44:20 CEST] <furq> i don't think that ever made it though
[10:44:33 CEST] <Cracki> if you have an integrated GPU, one that shares main memory, it can be lots faster for small operations
[10:44:44 CEST] <Cracki> ME isn't trivial
[10:45:12 CEST] <furq> i'm happy enough just using my gpu for denoising
[10:45:21 CEST] <Cracki> and imho way out of most gsoc's applicants' competence
[10:45:34 CEST] <Cracki> basically optical flow.
[10:45:48 CEST] <Cracki> typical encoders seem to be doing block matching.
[10:46:02 CEST] <Cracki> on a single scale.
[10:47:03 CEST] <Cracki> if you throw state of the art optical flow estimation algorithms at it, you get quite good results and you can use those trivially for video compression
[10:47:19 CEST] <Cracki> even shit algos are good enough for video compression
[10:50:55 CEST] <Cracki> ah so lookahead is supposed to compute a downscaled version of input frames?
[10:53:10 CEST] <m4t> Cracki: btw out of curiousity i just looked into -help muxer=mp4 and tried the original .mp4 but with '-movflags frag_keyframe'. seems to immediately write a header and kill -9'ing it results in a watchable video. but i like mkv+flac better anyways...
[10:53:25 CEST] <Cracki> ^^
[10:53:31 CEST] <furq> afaik lookahead does a low-resolution encode and uses that to determine how many bframes to use
[10:53:39 CEST] <BtbN> fragmented mp4 doesn't have the most widespread support
[10:53:43 CEST] <Cracki> it's just something we use for screencaptures that get killed abruptly
[10:54:05 CEST] <furq> and yeah fmp4 is a hack to allow streaming mp4 to browsers
[10:54:31 CEST] <furq> because it was easier than getting browsers to add one of the many existing formats which does the same thing
[10:54:36 CEST] <furq> because browser vendors are subhuman scum
[10:54:39 CEST] <Cracki> we're stuffing qtrle+aac in a mov container...
[10:55:07 CEST] <Cracki> any better option for lossless rgb888 that compresses synthetic video quite well?
[10:55:16 CEST] <furq> ffv1?
[10:55:37 CEST] <Cracki> how stable and fast is it? qtrle is dumb as heck and thus quite fast
[10:55:49 CEST] <furq> it's very stable
[10:55:57 CEST] <furq> you'll have to find out how fast it is
[10:55:59 CEST] <Cracki> oh also it should be readable by adobe premiere :P
[10:56:02 CEST] <furq> oh
[10:56:07 CEST] <Cracki> *g* yeah
[10:56:13 CEST] <furq> yeah that was worth mentioning up front
[10:56:20 CEST] <furq> there's no dshow or quicktime components for ffv1 afaik
[10:56:26 CEST] <furq> the best thing that does have those is probably ut video
[10:56:41 CEST] <Cracki> it can read qtrle using quicktime codecs, it's supposed to read everything Windows knows in terms of installed codecs... but who knows
[10:57:08 CEST] <furq> "everything windows knows" is dshow
[10:57:23 CEST] <Cracki> i've used lagarith for a while but then I read someone claim the floating point math makes it not quite lossless or unpredictable
[10:57:35 CEST] <Cracki> yes vfw/dshow/media foundation
[10:57:42 CEST] <Cracki> depending on what api premiere knows :P
[10:57:54 CEST] <furq> utvideo should work anyway
[10:57:57 CEST] <furq> and utvideo is very fast
[10:58:05 CEST] <furq> but it's not as good as ffv1 in my experience
[10:58:07 CEST] <Cracki> hmhm gotta try that
[10:58:26 CEST] <Cracki> I'm really looking for lossless non-subsampled non-colorspace-converted if possible
[10:58:48 CEST] <Cracki> ut video, ah good
[10:58:54 CEST] <furq> utvideo and ffv1 both do rgb24
[10:58:54 CEST] <Cracki> says it does what I want
[10:59:03 CEST] <furq> x264 lossless will do it as well
[10:59:09 CEST] <furq> although the compression isn't amazing in rgb iirc
[10:59:28 CEST] <Cracki> h.264 in anything other than yuv420 will choke (older) premiere
[10:59:45 CEST] <Cracki> and my folks cba to pay for monthly/yearly subscriptions
[10:59:56 CEST] <furq> these are all general-purpose codecs, so qtrle might smash them all if you have a source that it does well on
[11:00:07 CEST] <Cracki> something about "owning" software that's obsolete a year after you bought it
[11:00:28 CEST] <Cracki> qtrle explodes if you give it "sensor data"
[11:00:32 CEST] <Cracki> it's just RLE after all
[11:00:50 CEST] <furq> yeah qtrle is generally either amazingly good or unusable
[11:00:51 CEST] <Cracki> so sometimes we knowingly use x264 444 lossless
[11:01:28 CEST] <furq> ffv1 is the best general-purpose lossless codec in my experience, but obviously the compatibility is an issue
[11:01:35 CEST] <furq> someone should really just make qt/dshow components for it
[11:01:36 CEST] <Cracki> is the qtrle codec in ffmpeg optimized much? I was thinking maybe it'd benefit from some love
[11:01:40 CEST] <furq> no idea
[11:01:44 CEST] <Cracki> hm ok
[11:01:56 CEST] <Cracki> maybe I should bother someone to wrap ffv1 into a dshow filter
[11:01:58 CEST] <furq> it doesn't seem like there's a huge amount there to optimise
[11:02:12 CEST] <Cracki> well, you can parallelize encoding of rows
[11:02:53 CEST] <Cracki> since it just does rle and compares to the previous frame, this could even be sent to opencl... but again, latency, likely not worth it
[11:03:15 CEST] <furq> i guess it would benefit from frame threading if it doesn't already have it
[11:03:19 CEST] <Cracki> loop autovectorization or a bunch of arcane intrinsics probably do better
[11:03:33 CEST] <Cracki> afaik it doesn't do frame threading.
[11:03:35 CEST] <furq>     Threading capabilities: none
[11:03:36 CEST] <furq> fun
[11:03:39 CEST] <dorvan> hi all
[11:03:41 CEST] <furq> yeah i guess that's an easy win then
[11:03:51 CEST] <Cracki> heh ok maybe I should look into that then
[11:05:04 CEST] <Cracki> qtrle doesn't have a notion of keyframes, at least not a flag for it. a frame could update all pixels, or none, and you'll only know after at least superficially decoding the frame.
[11:05:12 CEST] <furq> i assume using shotcut or some other NLE that uses ffmpeg's codecs is out of the question
[11:05:20 CEST] <Cracki> mostly
[11:05:45 CEST] <Cracki> it's either premiere or hardcoding all we do in a custom program
[11:06:32 CEST] <Cracki> it's bad enough premiere up to recently had really bad color correction facilities.
[11:06:47 CEST] <Cracki> physically incorrect ones even.
[11:06:53 CEST] <furq> nice
[11:07:04 CEST] <Cracki> the lumetri stuff works correctly.
[11:07:28 CEST] <Cracki> what the old stuff did was work in yuv (ok so far) but added a fixed uv to everything, irrespective of y
[11:07:41 CEST] <Cracki> so black gets turned into *strongly hued* black
[11:08:24 CEST] <Cracki> so the way to avoid that was ignore the color correctors and tweak gains in a levels/curves filter
[11:08:42 CEST] <dorvan> Cracki: when you have time, i need to discuss something with you about concatenate many ffmpeg processes for filtering
[11:09:00 CEST] <Cracki> no, discuss that with the channel.
[11:09:07 CEST] <dorvan> Cracki: if you are available
[11:09:18 CEST] <dorvan> Cracki: thanks :-)
[11:09:19 CEST] <Cracki> I am unavailable.
[11:09:42 CEST] <Cracki> I'm deeply averse to being asked things personally that have nothing to do with me.
[11:09:48 CEST] <dorvan> Cracki: thanks :-)
[11:16:42 CEST] <dorvan> hi all, I need to concatenate many ffmpeg processes for filtering from a realtime/live source (rtmp) (level1), and then output stream to a web streamable format (level2). between level1 and level2 I need to use the stream with opencv or with a neural network software for object detection, face recognition. I'm evaluating the process structure to be more "realtime as possible"
[11:17:04 CEST] <dorvan> thanks for help.
[11:18:01 CEST] <Cracki> ah now I know why I discarded all those other lossless codecs... they have insane bitrates, or I don't know what to tweak...
[11:22:15 CEST] <Cracki> so utvideo (and huvyuv) don't suit me because they encode intra-only. my videos rarely change at all, they're screen caps of powerpoint karaoke. I need either null frames (absolutely no change) or p-frames. qtrle and lagarith can do that, if I tell them to.
[11:25:34 CEST] <furq> yeah ffv1 will do much better on that
[11:25:51 CEST] <furq> but if it's screen captures then qtrle will probably still beat it
[11:26:52 CEST] <Cracki> ugh... if someone's willing to pay me for work on qtrle, I'm game. otherwise I'll maybe get to it eventually maybe... maybe
[11:28:41 CEST] <Cracki> I think I'll have to kick my people to upgrade premiere. they need to using H.264 4:4;4
[11:37:18 CEST] <furq> apparently ffv1 will work in premiere on windows through lav filters
[11:37:41 CEST] <furq> and i found some quicktime component that does the same thing but it seems to be discontinued now
[11:37:48 CEST] <furq> http://perian.org/#download
[11:39:18 CEST] <Cracki> yay
[11:40:40 CEST] <Cracki> lots of what's in the trac wiki might have a better place in the actual docs
[11:40:47 CEST] <Cracki> such as https://trac.ffmpeg.org/wiki/Encode/FFV1
[11:42:11 CEST] <JEEB> furq: perian is discontinued and you should take a look at how the Ut Video guy makes components
[11:42:43 CEST] <JEEB> since he made components for all of the major multimedia frameworks
[11:43:50 CEST] <JEEB> if FFV1 had something similar I could be recommending it to the NLE people. unfortunately currently that's not the case :/
[11:44:06 CEST] <JEEB> also a lot of editors still seem to be utilizing VFW (or moved to MF) so I'm surprised LAV can be used in some cases
[11:45:25 CEST] <ritsuka> quicktime is discontinued too, and the replacement doesn't have a public api for video components yet. But I guess premiere on mac might still use the old quicktime framework
[11:45:46 CEST] <JEEB> yes, everything is atm using the QT stuff
[11:45:50 CEST] <JEEB> on MacOS
[11:46:05 CEST] <ritsuka> mm no, final cut x doesn't for example
[11:46:08 CEST] <bencoh> QT is discontinued? ohmy
[11:46:17 CEST] <JEEB> bencoh: like VFW is discontinued :D
[11:46:25 CEST] <JEEB> ritsuka: so it has completely its own stuff
[11:46:29 CEST] <JEEB> even for export?
[11:46:31 CEST] <bencoh> uhuh
[11:46:40 CEST] <ritsuka> it uses avfoundation/videotoolbox/coremedia and friends
[11:47:03 CEST] <ritsuka> but there isn't a public api for videotoolbox components
[11:50:34 CEST] <Cracki> btw, ffv1 doesn't seem to react to -g... bit rate stays the same with -g 0, 1 or 100, even for static video content...
[11:50:48 CEST] <Cracki> (about 15 Mbps for 1280x960 input)
[12:42:20 CEST] <ZeroWalker> what's zlib used for in ffmpeg?
[12:43:30 CEST] <JEEB> zlib is used for png encoding I think? among some other minor things
[12:43:56 CEST] <JEEB> z.lib (commonly known as zimg) is used for a scaling/colorspace conversion filter
[12:50:18 CEST] <ZeroWalker> wait so does zimg use zlib, why would that be needed for scaling/converting colorspaces?
[12:52:00 CEST] <furq> no
[12:52:04 CEST] <JEEB> the author of zimg is a known troll, the "official name" of the library is z-dot-lib
[12:52:07 CEST] <JEEB> because of course
[12:52:10 CEST] <furq> zimg is actually called "z.lib" because the guy who made it is some kind of ratfucker
[12:52:19 CEST] <furq> but nobody calls it that because of course they don't
[12:52:40 CEST] <furq> the actual zlib is used for png, yeah
[12:52:43 CEST] <JEEB> yup
[12:52:56 CEST] <JEEB> there might have been some other things it was used in, but png encoding is the one I noticed
[12:53:12 CEST] <furq> yeah i've seen a few people with builds that can't encode png because of no zlib
[12:54:35 CEST] <JEEB> well to be honest even the pkg-config file is "zimg" https://github.com/sekrit-twc/zimg/blob/master/zimg.pc.in
[12:54:53 CEST] <JEEB> so it's not that bad, he did understand that if he made his library called "z" it would be a bit too much of a troll :P
[12:54:56 CEST] <furq> yeah i think even he realised calling it z.lib outside of the github readme was a real shit idea
[13:16:34 CEST] <ZeroWalker> how can you link libopus statically
[13:16:51 CEST] <BtbN> build a static version of it and use it
[13:18:01 CEST] <ZeroWalker> i did --enable-static on libopus configure, guess that wasn't the command
[13:21:07 CEST] <BtbN> If the shared libs are still there, they will be prefered.
[13:21:31 CEST] <ZeroWalker> ah
[13:21:31 CEST] <BtbN> You might be able to do some magic with pkg-config, by forcing it to return the static version
[13:21:58 CEST] <ZeroWalker> well never got pkg-config to work so i use extra flags to specify the locations
[13:22:20 CEST] <BtbN> configure requires pkg-config for a lot of things.
[13:22:39 CEST] <ZeroWalker> but i will clear the libopus, that was probably the issue, think i had the same with libx264, it required the dll for some reason, but i think after clearing and remaking it it works
[13:22:54 CEST] <ZeroWalker> well i have it, but i mean, it doesn't auto detect libx264 etc
[13:37:00 CEST] <furq> ZeroWalker: --extra-ldflags="-static"
[13:37:07 CEST] <furq> will tell the linker to prefer static libs
[13:37:47 CEST] <furq> you'll probably need --pkg-config-flags="--static" as well
[13:54:54 CEST] <bencoh> err, -static isn't just a "preference" (?)
[14:44:30 CEST] <dystopia_> how come i loose the subtitles when catting vobs together with -copy ?
[14:44:45 CEST] <dystopia_> ffmpeg.exe -i "concat:VTS_01_1.VOB|VTS_01_2.VOB|VTS_01_3.VOB|VTS_01_4.VOB|VTS_01_5.VOB|VTS_01_6.VOB" -c copy movie.vob
[14:45:03 CEST] <dystopia_> each vob has subs before concat, output does not
[14:46:13 CEST] <JEEB> I think you're putting a bit too much expectations on the workings of the concat features that come before decoding
[14:46:21 CEST] <JEEB> but you can open a bug report on the trac if you want
[14:46:41 CEST] <dystopia_> nah it's not a big deal, i just thought maybe i did somthing wrong
[14:47:12 CEST] <furq> dystopia_: you probably want to use tccat for that
[14:47:43 CEST] <JEEB> I don't remember if MPEG-PS could be just concatenated like MPEG-TS
[14:48:00 CEST] <dystopia_> ok i will give tccat a go
[14:48:09 CEST] <JEEB> (VOBs are MPEG-PS)
[14:48:16 CEST] <dystopia_> hmm
[14:48:36 CEST] <furq> i'm pretty sure it'll work with ffmpeg if you bump analyzeduration/probesize
[14:48:44 CEST] <dystopia_> basically i want to encode the dvd to x264 with subs, maybe i don't need to cat, i can just encode the vobs, then merge them at the end
[14:48:50 CEST] <furq> subtitle streams often don't show up within the first 5MB
[14:48:59 CEST] <furq> but honestly, if you're working with dvds at all then you want to use tccat
[14:49:06 CEST] <furq> and/or tcdemux
[15:27:15 CEST] <nikon> Hello
[15:27:19 CEST] <nikon> anyone can help me?
[15:29:05 CEST] <nikon> i'm trying stream with http to rtmp and i get this error all time
[15:29:06 CEST] <nikon> av_interleaved_write_frame(): Broken pipeB time=00:00:25.44 bitrate=1192.6kbits/s [flv @ 0xc35680] Failed to update header with correct duration. [flv @ 0xc35680] Failed to update header with correct filesize.
[15:29:10 CEST] <nikon> anyone know why?
[15:30:42 CEST] <BtbN> you're writing it somewhere that's not seekable.
[15:31:00 CEST] <BtbN> and "with http to rtmp" makes no sense
[15:32:08 CEST] <nikon> how so?
[15:32:20 CEST] <nikon> i'm trying to restream from http to rtmp using this command
[15:32:46 CEST] <nikon> screen ffmpeg -i "http://serveronline.io:6969/live/user01/Y1pktR5KiP/7051.ts" -async 30 -c:v libx264 -preset veryfast -ab 64k -ar 11025 -ac 2 -c:a aac -strict experimental -s 640x360 -r 30 -vb 1200k -f flv "rtmp://up.widestream.io/wideorigin?token=kqznfic/lafbm6j"
[15:32:56 CEST] <nikon> and they work but after some seconds process close
[15:33:06 CEST] <nikon> and i see this error in ssh
[15:33:12 CEST] <nikon> av_interleaved_write_frame(): Broken pipeB time=00:00:25.44 bitrate=1192.6kbits/s [flv @ 0xc35680] Failed to update header with correct duration. [flv @ 0xc35680] Failed to update header with correct filesize.
[15:33:37 CEST] <furq> you probably want to change your rtmp token
[15:34:40 CEST] <nikon> furq why?
[15:34:52 CEST] <BtbN> Because you just pasted it here.
[15:34:54 CEST] <furq> because you just pasted it in a public irc channel
[15:35:16 CEST] <furq> also if you still need -strict experimental then you're on an old ffmpeg
[15:35:31 CEST] <BtbN> "Broken Pipe" also indicates a network issue
[15:35:44 CEST] <nikon> what type of issue?
[15:35:54 CEST] <nikon> no upstream avaliable?
[15:35:59 CEST] <furq> it usually means the connection was closed
[15:36:20 CEST] <nikon> [14:35] <furq> also if you still need -strict experimental then you're on an old ffmpeg
[15:36:29 CEST] <nikon> yes i have oldest version of ffmpeg
[15:36:35 CEST] <nikon> i don't know how to update
[15:36:51 CEST] <furq> if your distro ffmpeg is old then https://www.johnvansickle.com/ffmpeg/
[15:37:19 CEST] <furq> it's worth upgrading anyway because the builtin aac encoder is massively improved in 3.x
[15:38:02 CEST] <nikon> i'm not a linux expert can you please help me update my ffmpeg?
[15:38:11 CEST] <nikon> [root at ns345064 ~]# ffmpeg ffmpeg version 2.6.8 Copyright (c) 2000-2016 the FFmpeg developers   built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-4)
[15:38:13 CEST] <nikon> this is my version
[15:38:14 CEST] <furq> download that and put the binaries in /usr/local/bin
[15:38:25 CEST] <BtbN> Or just use it from whereever
[15:38:38 CEST] <furq> also stop running as root
[15:39:07 CEST] <nikon> download          x86_64 build: ffmpeg-git-64bit-static.tar.xz - md5 ? for /usr/local/bin folder?
[15:39:42 CEST] <furq> ?
[15:40:23 CEST] <nikon> [14:38] <furq> download that and put the binaries in /usr/local/bin
[15:40:29 CEST] <nikon> i don't understand what i need to do
[15:40:42 CEST] <furq> tar xvf ffmpeg-git-64bit-static.tar.xz
[15:41:04 CEST] <nikon> ok, and now?
[15:41:04 CEST] <furq> will give you a directory with ffmpeg, ffprobe etc binaries
[15:41:21 CEST] <nikon> yes
[15:41:26 CEST] <furq> either call them directly or move them into /usr/local/bin and delete your distro's ffmpeg package
[15:41:27 CEST] <nikon> https://i.gyazo.com/8cac984de818d512f6ed6d4c5b47f968.png
[15:41:58 CEST] <nikon> "delete your distro's ffmpeg package"
[15:42:02 CEST] <nikon> how can i do this?
[15:42:38 CEST] <JEEB> just call your ffmpeg directly
[15:42:38 CEST] <nikon> yum remove ffmpeg ?
[15:42:49 CEST] <furq> probably
[15:42:51 CEST] <nikon> how? like ./ffmpeg ?
[15:42:54 CEST] <furq> i haven't used centos in 10+ years
[15:42:57 CEST] <JEEB> or full path
[15:43:04 CEST] <furq> and yeah you can just call it directly
[15:43:07 CEST] <JEEB> if you're in the same directory then ./ffmpeg will work
[15:43:10 CEST] <furq> or put it in ~/bin or something
[15:43:13 CEST] <nikon> ok
[15:43:16 CEST] <nikon> let me try
[15:43:17 CEST] <furq> idk if that's in the path on centos, especially not if you're logged in as root
[15:48:35 CEST] <nikon> I definitely do not understand any of this, I'm going to have to look for some expert, does anyone here give paid support about it?
[20:33:52 CEST] <cryptodechange> Been playing with the nlmeans feature to reduce grain, where it's reduced the grain and kept the quality, it has kind of made a heat distortion/mirage effect on backgrounds
[20:34:11 CEST] <cryptodechange> I suppose it's the frame shaking but is hidden by the grain itself
[20:48:11 CEST] <cryptodechange> https://imgur.com/a/jCamo
[00:00:00 CEST] --- Mon Aug 14 2017