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

[burek]

[00:00:59 CET] <faLUCE> Dodutils: AFAIK vlc has better support for rtsp. why don't you use that?
[00:02:49 CET] <Dodutils> @faLUCE : not sticked to ffmpeg, only know it better than vlc, I can go to vlc if it better support RTSP and can do what I need
[00:03:40 CET] <faLUCE> Dodutils: try vlc for that, command line
[00:05:10 CET] <faLUCE> Dodutils: about the second question:
[00:05:37 CET] <faLUCE> (server "frozen")
[00:06:19 CET] <faLUCE> it depends on which kind of cameras you use
[00:07:13 CET] <Dodutils> an example is that I restart camera every night  and ffmpeg do not detect that and just stop recording but do not reconnect to camera
[00:07:48 CET] <faLUCE> Dodutils: no, you can't proceed in this way
[00:08:32 CET] <faLUCE> ok, the "easy way is this":
[00:08:39 CET] <Dodutils> but what I do not understand is why ffmpeg do not warn/detect/quit or do anything once connection to camera is lost
[00:09:01 CET] <faLUCE> Dodutils: wait, I'll write you the easy and difficult ways to solve that, step by step
[00:09:49 CET] <faLUCE> the easiest way is to relaunch the recorder at each disconnection of the camera
[00:09:58 CET] <faLUCE> (do you use an usb camera?)
[00:10:34 CET] <faLUCE> or do you use an IP camera?
[00:13:18 CET] <Dodutils> I use an IP cam but the example of camera restart was just one case (this one I control and I can restart ffmpeg same time)
[00:13:27 CET] <Dodutils> 8 cams differents models
[00:13:36 CET] <faLUCE> Dodutils: are they all IP ?
[00:13:45 CET] <Dodutils> yep
[00:14:25 CET] <faLUCE> ok, now: would it be enough if you restart recording after a reconnection?
[00:18:29 CET] <Dodutils> that's what I planned checking video file date if 'touch' older than xx second and ffmpeg process still present then houston we have a problem so restart ffmpeg
[00:19:34 CET] <faLUCE> Dodutils: you did  not answer:
[00:19:39 CET] <faLUCE> would it be enough if you restart recording after a reconnection?
[00:20:28 CET] <faLUCE> or you want something more accurate?
[00:21:39 CET] <Dodutils> I want to keep all the files (by default I do 5 mins segmentation) and yes I can restart recording with a loss of a few secs
[00:23:33 CET] <faLUCE> Dodutils: ok, so, first of all, exec   cvlc rtsp://camera-ip   with option that lets vlc exit after a connection failure
[00:23:57 CET] <faLUCE> I don't remember the name of the option, but there's one, wait
[00:25:25 CET] <faLUCE> it should be:    --play-and-exit
[00:25:30 CET] <faLUCE> you can test it
[00:25:55 CET] <faLUCE> so: cvlc  --play-and-exit  rtsp://camera-ip
[00:26:18 CET] <faLUCE> after you tested that, put that into a loop script, and we can proceed with the second part
[00:26:30 CET] <Dodutils> done
[00:26:42 CET] <faLUCE> does it exit after a disconnection ?
[00:29:43 CET] <Dodutils> nope
[00:31:38 CET] <Dodutils> may be there is some timeout parameter ?
[00:31:53 CET] <faLUCE> Dodutils: some years ago play-and-exit worked, wait
[00:35:50 CET] <faLUCE> Dodutils:  --rtsp-timeout
[00:36:14 CET] <faLUCE> try:  clvc --rtsp-timeout=5 ...
[00:37:10 CET] <faLUCE> (it could not work, anyway, it seems more a timeout for the rtsp part, not for the transport part)
[00:37:28 CET] <faLUCE> anyway, try it
[00:37:32 CET] <Dodutils> unknown option or missing mandatory argument `--rtsp-timeout=5'
[00:38:49 CET] <Dodutils> same with space instead of "="
[00:39:20 CET] <Dodutils> and a grep on vlc --help show only 3 timeout parameters with no connection with "streaming"
[00:40:50 CET] <faLUCE> Dodutils: I know, vlc options are a mess. Try that:  --ipv4-timeout=1000*seconds-you-want
[00:41:18 CET] <faLUCE> for example:  --ipv4-timeout=5000  (5 seconds timeout)
[00:44:43 CET] <Dodutils> not stopping either, I guess it is timeout for first connection
[00:48:16 CET] <faLUCE> Dodutils: well, try: vlc --longhelp --advanced | grep timeout
[00:48:26 CET] <faLUCE> there are some other timeouts that you can try
[00:48:38 CET] <faLUCE> for example:  --rtp-timeout
[00:48:56 CET] <faLUCE> also --mms-timeout
[00:49:40 CET] <faLUCE> --notify-timeout seems the "global" one
[00:51:00 CET] <faLUCE> Dodutils: another option is to use a playlist with a "quit" element at the end, but it's more complex. try firstly if some timeout option does work
[00:53:17 CET] <Dodutils> longhelp showed the ipv4 parameter but not the one you tell that are unrecoginzed
[00:53:35 CET] <faLUCE> Dodutils: did you use "--advanced" ?
[00:53:45 CET] <Dodutils> yep
[00:53:51 CET] <faLUCE> which version of vlc ?
[00:53:55 CET] <Dodutils> 3.0.4
[00:54:24 CET] <faLUCE> did you exec "vlc --longhelp --advanced | grep timeout"  ?
[00:54:52 CET] <faLUCE> (I use 3.0.4 as well, and I see that options)
[00:54:55 CET] <Dodutils> sure 1 more parameter showed 4 instead of 3
[00:55:16 CET] <faLUCE> how did you install vlc ?
[00:55:22 CET] <Dodutils> apt-get
[00:55:26 CET] <Dodutils> vlc-bin
[00:56:03 CET] <faLUCE> that's very strange, it's the same version that I use
[00:56:17 CET] <faLUCE> vlc --version
[00:56:18 CET] <faLUCE> VLC media player 3.0.4 Vetinari (revision 3.0.4-0-gf615db6332)
[00:56:26 CET] <Dodutils>  VLC media player 3.0.4 Vetinari (revision 3.0.4-0-gf615db6332)
[00:56:35 CET] <faLUCE> exactly the same
[00:57:19 CET] <faLUCE> Dodutils: ok, open the GUI, advanced options
[00:57:50 CET] <Dodutils> have no GUI
[00:58:11 CET] <faLUCE> ?? then something is broken in your installation of vlc
[00:58:30 CET] <Dodutils> I mena I do not use any Linux GUI
[00:58:33 CET] <Dodutils> mean
[00:58:43 CET] <faLUCE> what distro?
[00:58:52 CET] <Dodutils> WSL
[00:59:03 CET] <faLUCE> I see, then you have some minimal vlc installation
[00:59:38 CET] <faLUCE> then you have to figure how to install a full vlc
[01:00:10 CET] <Dodutils> yep you gave me a lead with those timeout parameters
[01:00:44 CET] <Dodutils> so then I do I wwrite direct-to-disk and also provide server to this stream ?
[01:00:45 CET] <faLUCE> anyway, it's only a matter of a parameter
[01:00:54 CET] <faLUCE> I did that some years ago and it worked
[01:01:06 CET] <Dodutils> will recompile it full
[01:01:22 CET] <faLUCE> after you figure the right param, you have to pipe a sout stream
[01:01:45 CET] <faLUCE> (it will be the proxy" you said)
[01:02:45 CET] <Dodutils> pipe the stream to a file ok but how to make it act as RTSP TCP source ? and ... how do both at same time ?
[01:03:11 CET] <Dodutils> that was my firt issue
[01:03:40 CET] <faLUCE> https://wiki.videolan.org/Documentation:Streaming_HowTo/Command_Line_Examples/  <---- look at "Multiple streaming"
[01:04:06 CET] <faLUCE> it will create a new rtsp source
[01:05:31 CET] <faLUCE> what was the other question Dodutils?
[01:06:01 CET] <Dodutils> I see the examples but they make VLC retsream to other IP
[01:06:34 CET] <faLUCE> Dodutils: just replace with localhost
[01:06:42 CET] <faLUCE> nd it will act as a server
[01:06:45 CET] <Dodutils> is it so simple ? :-)
[01:06:50 CET] <faLUCE> yes, very simple
[01:07:32 CET] <faLUCE> I don't even know why they put a specific address. It's meaningless for non-UDP
[01:08:12 CET] <faLUCE> anyway, I used that tons of times in the past, and it works as server very easily
[01:10:06 CET] <faLUCE>  but which was the other question?
[01:16:08 CET] <Dodutils> other question was about the timeout problem with ffmpeg but I also have another problem with segment naming %03d when I restart ffmpeg it recstart from -000 file
[01:16:27 CET] <faLUCE> Dodutils: note that you have to use rtsp as sout, not rtp
[01:16:43 CET] <Dodutils> I would like it to continue to name-count the file segments of the direct-to-disk streaming
[01:17:05 CET] <faLUCE> [01:16] <Dodutils> other question was about the timeout problem with ffmpeg  <--- for what do you use ffmpeg ?
[01:17:33 CET] <Dodutils> yep rtsp but WSL version of vlc do not recognize --sout ... hell I will start a true Linux VM
[01:18:11 CET] <faLUCE> [01:16] <Dodutils> other question was about the timeout problem with ffmpeg  <--- for what do you use ffmpeg ?
[01:18:16 CET] <Dodutils> for now ffmpeg is used for direct-to-disk record
[01:18:38 CET] <faLUCE> you won't use ffmpeg anymore for that, because you will create two subpipes with vlc
[01:19:12 CET] <faLUCE> the first subpipe will redirect your stream, the second one will write to file
[01:19:22 CET] <Dodutils> yep that is great and will meet my requirements, will have to set good parameters for that to restarm with no re-encodding
[01:19:26 CET] <faLUCE> so, they will depend both on the connection
[01:19:28 CET] <Dodutils> re-encoding
[01:19:45 CET] <faLUCE> it's not necessary to reencode
[01:20:01 CET] <Dodutils> yep exactly if input stop bith output stop too no problem
[01:20:19 CET] <Dodutils> I do not want to reencode as I want it to be low CPU
[01:20:27 CET] <faLUCE> you don't have to
[01:20:32 CET] <Dodutils> that is in fact the main goal of all of this
[01:20:53 CET] <faLUCE> (I did these things since 10 years :-) )
[01:21:11 CET] <faLUCE> I don't understand your last problem
[01:21:26 CET] <faLUCE> "but I also have another problem with segment naming %03d when I restart ffmpeg it recstart from -000 file"
[01:22:30 CET] <Dodutils> yes you can name the files incremental way when you specify ffmpeg to do a segmented every 5 mins direct-to-disk file, by the way I also want to do it with vlc
[01:23:07 CET] <faLUCE> Dodutils: do you want to create a new recording file every 5 mins ?
[01:23:10 CET] <Dodutils> I do not want a huge H.264 file but only small ones, each one containing 5 mins video
[01:23:17 CET] <Dodutils> yep
[01:23:32 CET] <faLUCE> ok, then, you have two ways for doing that
[01:23:37 CET] <Dodutils> with ffmpeg it is easy
[01:25:28 CET] <Dodutils> ffmpeg -rtsp_transport tcp -i 'rtsp://login:password@192.168.1.138:554/ch01.264?ptype=tcp&dev=1' -c copy -map 0 -map -0:1:0 -map -0:1:1 -f segment -segment_time 300 -segment_list slist.txt -segment_format mp4 capture-%03d.mp4
[01:25:38 CET] <faLUCE> Dodutils: there are multiple ways for doing that
[01:26:16 CET] <faLUCE> first of all, ask to vlc people if is there an embedded option for segmenting the output
[01:26:23 CET] <faLUCE> (but I suspect there is not)
[01:27:18 CET] <faLUCE> is there is not, then you could use a rc interface
[01:27:54 CET] <Dodutils> I could kill/restart vlc every 5 mins
[01:27:56 CET] <faLUCE> which means: you will have an instance of vlc , always active, which is controllable by rc commands
[01:28:00 CET] <faLUCE> no, no
[01:28:02 CET] <faLUCE> never kill
[01:28:04 CET] <Dodutils> rc command
[01:28:07 CET] <faLUCE> yes
[01:28:23 CET] <faLUCE> it's an embedded interface that allows you to send commands to vlc
[01:28:32 CET] <faLUCE> like record/stop record
[01:28:53 CET] <faLUCE> so you will create a script that every 5 mins sends this command
[01:29:05 CET] <faLUCE> look at "rc-interface"
[01:29:17 CET] <Dodutils> --rc-host
[01:29:26 CET] <faLUCE> yes, it's a server
[01:29:33 CET] <Dodutils> ok got it, I will RTFM
[01:29:40 CET] <faLUCE> you will set it to localhost with a port
[01:29:51 CET] <faLUCE> and then you will send commands (with nc) to it
[01:29:52 CET] <Dodutils> good lead tnx
[01:30:19 CET] <faLUCE> but ask firstly to vlc people if they added an option for segmenting, meanwhile
[01:30:23 CET] <faLUCE> maybe they did
[01:30:27 CET] <Dodutils> oups ... 1.30am got to go bed
[01:30:42 CET] <Dodutils> thanx for your help
[01:30:47 CET] <Dodutils> and your time
[01:31:02 CET] <faLUCE> yw
[01:31:17 CET] <Dodutils> cya
[01:31:19 CET] <Dodutils> quit
[02:07:58 CET] <FlipFlops2001> Why is the value for "acompressor=threshold=[range 0.00097563-1]" expressed in FRACTIONS as opposed to DECIBELS (dB) like every other hardware and software compressor/limiters in the galaxy? -Asked by Me: Studio & Live Audio Engineer since 1975.
[02:07:58 CET] <ph88> does anyone know a website where i can download a bunch of test videos ?
[02:10:11 CET] <FlipFlops2001> ph88: Try https://www.matrox.com/video/en/products/monarch_hdx/testyourencoder/
[02:11:44 CET] <FlipFlops2001> ph88: Also see: https://www.demo-world.eu/2d-demo-trailers-hd/
[02:14:27 CET] <ph88> I was thinking more some videos specially crafted/selected to test encoders
[02:14:42 CET] <ph88> otherwise i might just take some of my own videos if it's just any other video
[02:21:15 CET] <FlipFlops2001> ph88: Does not the Matrox site fulfill your needs? After all the final folder is labeled "/testyourencoder/". Are you testing for both quality and filesize?
[02:22:42 CET] <ph88> well it's just the same video in different sizes and kb/s right?
[02:28:00 CET] <FlipFlops2001> ph88: Yes, but wouldn't you want to download the largest, most uncompressed file, re-encoded it and make a comparison. Sorry haven't found any "raw" video to download; like one that's Full HD (or better), 4:4:4, 10-bit and at least bt2020. Anybody know if it exists?
[02:28:31 CET] <ph88> no worries, ill figure something out
[02:31:04 CET] <tlacatlc6> ph88, something like this: https://media.xiph.org?
[02:31:28 CET] <ph88> ah that looks great
[02:31:30 CET] <ph88> thanks a lot
[02:31:44 CET] <tlacatlc6> np
[02:33:03 CET] <ph88> tlacatlc6, do you know which file i should download ?  y4m ?
[02:33:50 CET] <tlacatlc6> yeah
[02:33:55 CET] <ph88> can i merge the audio and video into a container first ?
[02:35:14 CET] <tlacatlc6> hmm, honestly i haven't done that as i only encode video. but maybe you can mux it to an mkv?
[02:37:15 CET] <FlipFlops2001> ph88: MKVToolNix/MKVmerge: https://mkvtoolnix.download/windows/continuous/64-bit/
[02:38:01 CET] <FlipFlops2001> Gotta go: Watching some of my reencoded HEVC vids. Bye!
[04:30:57 CET] <damdai> how do i report bugs for ffmpeg
[05:37:00 CET] Last message repeated 1 time(s).
[05:57:49 CET] <pink_mist> go to the ffmpeg.org website
[05:57:55 CET] <pink_mist> click on the link "bug reports"
[05:58:01 CET] <pink_mist> read the page
[12:44:14 CET] <__gh0st> Is it good to preserve the GOP-structure of a video when transcoding it? For example I have a h.264 encoded video file and I want to downscale it and transcode it to h.264 again, if we retain the same GOP-structure of the input video file in the output(transcoded) video file, will we benefit from less quality loss?
[12:44:31 CET] <JEEB> no
[12:44:47 CET] <JEEB> generally you and your transcode have your requirements and features available
[12:47:43 CET] <__gh0st> Can you, please, elaborate why exactly we won't benefit from any quality loss?
[12:49:59 CET] <JEEB> ok, let's put it this way. if the original author had a requirement of having 2 frame GOPs.
[12:50:13 CET] <JEEB> or he used an encoder without tweaking values that output something like that
[12:50:49 CET] <JEEB> also GOPs generally don't mean that's a good (compression wise) place to put a RAP start
[12:51:04 CET] <JEEB> I mean, they could - but you cannot expect that you can re-use the same spots
[12:52:29 CET] <JEEB> and there isn't really anything to gain in general from trying to follow the same RAP/GOP structure
[12:53:00 CET] <__gh0st> What is RAP?
[12:53:39 CET] <JEEB> random access point
[12:57:54 CET] <__gh0st> JEEB: Oh, okay. But what if for some reason we need to do multiple transcoding iterations to the same format(h.264 for example) -- in this case preserving the GOP-structure doesn't give us anything too?
[12:59:00 CET] <JEEB> not really. generally I recommend utilizing lossless intermediates if you are going to iterate
[13:03:10 CET] <BtbN> Every transcode has quality loss, unless encoding lossless. No matter if you match the original parameters or not.
[13:03:22 CET] <DHE> there's only one time I use synchronized keyframes - adaptive bitrate protocols like DASH or HLS. even then it's less about copying the source GOP structure as it is having outputs with consistent GOP structures
[13:05:29 CET] <JEEB> and even there those might be overused since I've only seen stuff like MS's PlayReady SDK for *iOS* (which nobody in their right mind should have to support) utterly fail at that stuff. also 2015 Tizen TVs had something funny but by now I've completely erased them from my memory
[13:06:00 CET] <__gh0st> Huh, I thought if we had a h.264 encoded video with for example a GOP-structure like this: IBBBIBBBI..., and when we transcode it to something like this: IBBBBBBB... We would loss a lot more quality when transcoding than if we would have the GOP-structure the same as input.
[13:06:49 CET] <damdai> Stream #0:0: Audio: dsd_lsbf_planar, 352800 Hz, stereo, fltp, 5644 kb/s   : if ffplay can play this file,   how come VLC cannot?
[13:07:05 CET] <__gh0st> Because if we encode the I-frame as a B frame we would lose a lot more quality than if we would encode it as I-frame(obviously)?
[13:07:10 CET] <DHE> unlike old codecs like mpeg4 (aka divx), h264 doesn't suffer degradation without keyframes. their only true use is so that a player can begin with no reference frames
[13:07:29 CET] <JEEB> a lot of encoders raise the quantizer for non-I pictures, but at that point it's a case if you actually set your rate control right or not. and by using longer GOPs you will probably be able to compress it better :P
[13:07:55 CET] <JEEB> in other words, if you're utilizing constant I frames to keep your bit rate high enough, you've simply not set your rate control right
[13:08:38 CET] <JEEB> not to mention that if you set the same bit rate with bit rate based rate control, the encoder might have to raise the quantizer in those I frames anyways
[13:08:58 CET] <JEEB> generally having shorter GOPs is just for applications being able to seek and scrub quicker :P
[13:09:09 CET] <JEEB> there's no compression wise benefit
[13:09:24 CET] <JEEB> and benefit for compression means that with the average bit rate you get better quality
[13:11:06 CET] <__gh0st> And there is no quality benefit too as I understand..
[13:11:31 CET] <JEEB> *with the same average bit rate
[13:11:32 CET] <DHE> quality and compression are the mutual tradeoff, with "cpu usage" available as a tweak as well
[13:12:54 CET] <__gh0st> Are there cases where preserving the GOP-structure is justfied?
[13:13:23 CET] <JEEB> this is really unrelated to the input, but if your output GOP requirements are exactly the same as the ones for your input
[13:13:31 CET] <JEEB> but really, in that case you are not following the input GOP structure
[13:13:35 CET] <DHE> if you're making multiple bitrates like I described, you'll need to make sure at least SOME keyframes are properly aligned. but a perfect match still isn't needed (depending)
[13:13:36 CET] <JEEB> you are following your requirements
[13:14:16 CET] <JEEB> (they just happen to match)
[13:15:04 CET] <__gh0st> Okay, thank you very much with your answers!
[13:17:01 CET] <damdai> Stream #0:0: Audio: dsd_lsbf_planar, 352800 Hz, stereo, fltp, 5644 kb/s   : if ffplay can play this file,   how come VLC cannot?
[13:31:20 CET] <durandal_1707> damdai: not registered decoder for vlc
[13:31:38 CET] <damdai> durandal_1707 i just tried with nightly and it works
[13:31:51 CET] <damdai> nightly vlc 4.0
[13:32:04 CET] <damdai> somebody told me to do that
[13:36:55 CET] <damdai> there are   dsd_lsbf  and  dsd_msbf    it stands for "least significant bit first"  and "most significant bit first" :  what is better
[13:37:45 CET] <DHE> whatever is supported by the player
[13:38:59 CET] <damdai> ffplays them both
[14:41:09 CET] <pkunk> JEEB: Was it you I discussed with about parallel opening of input streams with ffmpeg cli ?
[14:41:22 CET] <JEEB> probably :)
[14:41:37 CET] <pkunk> I have it working @ https://github.com/chetan-prime/FFmpeg/tree/release/4.1
[14:42:31 CET] <pkunk> If it works fine for a few people then I could create a branch and then send a pull request after making the code safe for non-thread builds
[14:44:43 CET] <JEEB> funky
[14:46:37 CET] <faLUCE> hello all
[14:47:49 CET] <jkhsjdhjs> hey
[14:56:43 CET] <pkunk> JEEB: I have tested it on a 16 stream mosaic. Takes 6-7 seconds vs 3 minutes before
[14:57:05 CET] <JEEB> which is about how long lavf attempts to probe
[14:57:08 CET] <JEEB> by default
[14:57:22 CET] <JEEB> I think 5 seconds is the general default, and MPEG-TS had a custom default of 7?
[14:58:04 CET] <JEEB> I'll probably not be able to poke at it any time soon so I recommend you try and make a proper single change set for it, and prod #ffmpeg-devel with it
[14:58:55 CET] <popara> Is there any way to delay the ffmpeg output? I want to have for example 2 minutes delay, so if i start the stream now, i get 2 minutes earlier of stream data, and continue normal. Save them in a buffer or something and then start streaming.
[15:07:02 CET] <faLUCE> popara: it's not clear what you want
[15:07:30 CET] <faLUCE> why do you want to save data into a buffer and which kind of buffer?
[15:08:11 CET] <faLUCE> memory or file?
[15:17:09 CET] <popara> faLUCE i have a stream ok, and i want to watch this stream but 2 minutes earlier from now
[15:17:30 CET] <popara> and continue as live
[15:17:42 CET] <faLUCE> popara: is the stream a file or  a live stream?
[15:17:47 CET] <popara> live stream
[15:18:07 CET] <faLUCE> popara: then you remux it?
[15:18:50 CET] <popara> yes
[15:19:02 CET] <faLUCE> and do you want to save it into a file befor re-streaming?
[15:19:52 CET] <faLUCE> I mean, what do you have to do with the buffer, other than re-streaming?
[15:21:03 CET] <popara> ah basically if i do HLS streaming setting seg list size and seg time to be 2 minutes, it will work what i want. Anytime that i want to start the stream, i will get 2 minutes earlier
[15:21:33 CET] <popara> it will consume a lot of disk space if i want -5 hours for example
[15:21:33 CET] <popara> but maybe there is no other way
[15:25:54 CET] <faLUCE> popara: you could pipe the output of ffmpeg to a named pipe
[15:26:19 CET] <faLUCE> then you read from this pipe after 2 mins
[15:36:03 CET] <kepstin> that's unlikely to actually work - the pipe buffer will fill up and ffmpeg will stall.
[15:36:11 CET] <kepstin> which will probably break the input
[15:36:47 CET] <faLUCE> kepstin: what if you set a pipe size ?
[15:37:20 CET] <kepstin> then you're buffering based on size not time, and even then i think the max pipe size probably won't be big enough for 2 minutes of video
[15:37:35 CET] <faLUCE>  kepstin it's compressed video I suppose
[15:37:50 CET] <faLUCE> but you use a size which is enough big
[15:42:11 CET] <kepstin> on linux, the default max pipe size is only 1MB. You /can/ increase that with some config under /proc, but even so& For this use case, you'd probably be better off using HLS with the delete old segments config enable on a ramdisk (tmpfs).
[15:42:59 CET] <faLUCE> kepstin: you can flush the pipe when it's full
[15:43:17 CET] <faLUCE> then, read again
[15:43:47 CET] <faLUCE> I don't see big problems
[15:44:05 CET] <kepstin> that doesn't fit the requirement of having a continuous 2 minute buffer
[15:44:58 CET] <kepstin> and needs custom tools besides - with hls you can do it with stock ffmpeg cli
[15:50:16 CET] <faLUCE> kepstin: from what I see you can set the size for a specific pipe
[15:51:07 CET] <faLUCE> kepstin: you have to increase also the max pipe size accordingly, under /proc, as you said
[15:51:31 CET] <kepstin> size != time
[15:51:50 CET] <kepstin> and it still has the issue where it there's no reader, the pipe blocks
[15:51:58 CET] <kepstin> and if you flush the pipe, you lose the buffer
[15:52:00 CET] <kepstin> so...
[15:52:05 CET] <kepstin> doesn't work.
[15:54:40 CET] <faLUCE> kepstin: I remember there are some circular buffers
[15:55:03 CET] <kepstin> ffmpeg's hls output can be configured to operate as a circular buffer.
[15:55:14 CET] <kepstin> (effectively)
[15:55:36 CET] <faLUCE> kepstin: I mean circular buffers for linux
[15:58:11 CET] <faLUCE> I would not reject this solution, otherewise he would be constrained to HLS
[16:10:17 CET] <kepstin> well, if you want to find or write a non-blocking/asynchronous single writer multiple reader circular buffer, and either modify applications to support it or provide some sort of adapter, i'm not gonna stop you.
[16:13:06 CET] <kepstin> in the mean time: hls (in a live streaming mode where old files get deleted) is an implementation of such a buffer that works fine and is already supported by players.
[16:39:12 CET] <deltasquared> kmsgrab is proving to be difficult to get to play ball once again...
[16:40:11 CET] <deltasquared> tried hwdownload on it's own with kmsgrab, complains not linearly mappable. VAAPI context derivation doesn't work any more either, different system (all AMD stuff) and I just get "unknown libva error".
[16:41:23 CET] <jkqxz> Does hwmap work without derivation?  There is still an annoying libva thing where it refuses to work as render on a master device when it doesn't have DRM master.
[16:41:44 CET] <deltasquared> jkqxz: so just plain hwmap? let me try that
[16:42:33 CET] <deltasquared> "A device reference is required to map to a hardware format." (one moment pasting log)
[16:43:05 CET] <jkqxz> You need to provide a destination context.  Something like -f kmsgrab -device /dev/dri/card0 -i - ... -init_hw_device vaapi=v:/dev/dri/renderD128 -filter_hw_device v -vf hwmap,...
[16:43:33 CET] <deltasquared> whoah whoah how is this the first time I have heard about -init_hw_device and -filter_hw_device
[16:43:44 CET] <deltasquared> (like seriously no pointers this is needed in the ffmpeg man pages?)
[16:45:59 CET] <deltasquared> jkqxz: https://a.uguu.se/E8JCo52kI1XX_ffmpeg.log is what I tried previously (note the invocation after "record started")
[16:46:06 CET] <deltasquared> warning, may contain escape codes.
[16:46:17 CET] <JEEB> the hardware stuff is always a kind of a special snowflake :P
[16:46:37 CET] <deltasquared> JEEB: what can I say, I didn't want x11's minor copying overhead at 1440p. :P
[16:46:41 CET] <deltasquared> "minor"
[16:46:57 CET] <deltasquared> also being able to record the console is a nice extra
[16:47:07 CET] <JEEB> that's just kms, no?
[16:47:19 CET] <JEEB> this has nothing to do with kms tbqh, the part where you're using vaapi
[16:47:26 CET] <JEEB> and that's what I was commenting on
[16:47:45 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#kmsgrab
[16:47:45 CET] <deltasquared> JEEB: right... I was going off a bug on the tracker that suggested someone do this when they ran into mapping errors
[16:48:08 CET] <JEEB> kmsgrab even has some example with dervice_device stuff
[16:48:21 CET] <JEEB> deltasquared: so you got completely randomly into the world of hw encoding? wow
[16:48:27 CET] <JEEB> good luck :P
[16:49:04 CET] <deltasquared> JEEB: not even hardware, most hw encoders I've tried so far have been leaving something lacking. I'm just trying to grab frames with the least possible overhead possible given the data rates involved
[16:49:43 CET] <jkqxz> "ffmpeg -y -f kmsgrab -i /dev/dri/card0 -init_hw_device vaapi:/dev/dri/renderD128 -filter_hw_device vaapi0 -vf hwmap,scale_vaapi=format=nv12 -c:v h264_vaapi out.mp4" works for me to do the mapping without DRM master.
[16:50:15 CET] <deltasquared> jkqxz: actually it is being run as sudo there (sorry, my script didn't output that part)
[16:50:29 CET] <deltasquared> I wanted to get it to work first, then see if I could drop privs :P
[16:50:33 CET] <jkqxz> I'm not sure kmsgrab+hwdownload is going to gain much over x11grab.  You still have the same copy, just at a different point.
[16:51:03 CET] <jkqxz> Yeah, that was as root.  The requirement for CAP_SYS_ADMIN (basically root) for kmsgrab is a hard one, it can't work at all without it.
[16:51:37 CET] <deltasquared> hmm. I mean sure if I was using hardware encoding, I'd want to use kmsgrab if only because I could arrange it such that the frames didn't leave the GPU unencoded.
[16:52:00 CET] <deltasquared> but for plain frames perhaps not worth the effort, as has been evidenced thus far >_>
[16:54:43 CET] <deltasquared> honestly never realised you had to explicitly set up and declare hardware devices with a name then pass them to the filter graph like that
[16:57:19 CET] <grosso> hi
[16:57:49 CET] <jkqxz> You generally don't want it if you have a hardware decoder and stay in one API (though it does still work, those names can be passed to -hwaccel_device if you want multiple input streams on the same device), but it's required for filtering-only (i.e. OpenCL) and when you do mapping between APIs.
[16:58:35 CET] <deltasquared> jkqxz: another question then, is it possible to ditch the format filter? my understanding is that ran in software no?
[16:58:53 CET] <deltasquared> (I've had problems with it assuming wonky pixel formats in the past though...)
[16:59:00 CET] <jkqxz> The one after hwdownload?
[16:59:02 CET] <deltasquared> like gray8 or something. what even
[16:59:03 CET] <deltasquared> yes
[16:59:43 CET] <jkqxz> That's needed to hint the libavfilter negotiation into doing the right thing.  It can't currently see into the properties of the hardware frames enough to do it automatically.
[16:59:57 CET] <deltasquared> ah, I had thought it was something like that
[17:00:08 CET] <jkqxz> (It doesn't actually do anything at all at runtime, just a setup hint to get the format right.)
[17:00:16 CET] <deltasquared> ok fair enough
[17:05:29 CET] <grosso> I have a problem when muxing a flv stream. When I call av_interleaved_write frame() and there is no internet connection, it hangs for about 15 minutes and interrupt_callback is never called. This happens only when dealing with rtmps stream (through librtmp I guess); with rtsp there is no problem at all
[17:06:07 CET] <grosso> using ffmpeg v3.3.9
[17:10:11 CET] <grosso> librtmp seems to have a timeout for reading but not for writing
[17:10:45 CET] <grosso> all timeout, rw_timeout, etc. settings have no effect
[17:13:52 CET] <deltasquared> jkqxz: here's what I have thus far... https://a.uguu.se/VPY2r7woBOr1_ffmpeg.log
[17:14:05 CET] <deltasquared> I do have two GPUs though. maybe I need to select the other one.
[17:14:14 CET] <deltasquared> I don't know which way around the render nodes are :/
[17:14:32 CET] <deltasquared> ... nope, exact same error
[17:16:27 CET] <deltasquared> I may just have to try my luck with x11grab at this rate and see what the cycle hit looks like.
[17:16:45 CET] <deltasquared> I wouldn't mind but I have been able to get this to work before, with much swearing
[17:17:10 CET] <deltasquared> on an i3-3100M laptop. iGPU of all things. capture worked flawlessly.
[17:17:26 CET] <deltasquared> (i3-3100M CPU*)
[17:17:47 CET] <deltasquared> apparently there is more swearing involved before I get it to work on this system too :)
[17:22:22 CET] <deltasquared> ok, next daft question then... the ffmpeg-devices man page says you can use -video_size but it defaults to vga. so what video_size expression makes it record the entire screen area by default? (if any)
[17:22:34 CET] <deltasquared> *"cif" doesn't appear to be it.)
[17:23:34 CET] <deltasquared> you'd have thought the default would have been "everything" (but then again... I guess due to how x11 works, if you have multiple monitors that would not be the right thing)
[17:25:37 CET] <deltasquared> ironically gdigrab (the windows one) can do this...
[17:25:50 CET] <deltasquared> idk. maybe it'd require some communication with xrandr or such.
[17:26:24 CET] <deltasquared> but I have no idea how to make it do that programmatically. (xrandr's output is not all that great for shell script use)
[17:43:21 CET] <jkhsjdhjs> hey, i'm capturing an rtsp stream with ffmpeg. the stream has - according to the metadata - 25 fps. but ffmpeg is recording 15fps. is there any way to write 15fps to the metadata of the recorded file without reencoding it?
[17:58:28 CET] <deltasquared> that's interesting. when using x11grab, my GPU fans are spinning up
[17:58:37 CET] <deltasquared> is that the pixel format conversion being done I wonder
[17:59:45 CET] <Foaly> i wouldn't expect the pixel format conversion to happen on the gpu. rather in the driver
[18:00:00 CET] <deltasquared> Foaly: I'm definitely hearing the GPU fans spin up.
[18:00:11 CET] <deltasquared> they're quite distinctive. and loud. >_>
[18:00:40 CET] <deltasquared> I mean I am using the amdgpu ddx, maybe it's being smart and utilising the GPU to do whatever tiled/pixel format conversions
[18:01:02 CET] <deltasquared> which is what I wanted to do with kmsgrab anyway. oh well :D
[18:04:33 CET] <deltasquared> next question, do we have a list of pixel formats anywhere again... I was previously using bgr0 for ffvhuff, but it seems that no longer works and uses gbrp.
[18:05:07 CET] <deltasquared> (as in, I get an incompatible pixel format warning.)
[18:05:11 CET] <BtbN> x11grab is pretty inefficient
[18:05:32 CET] <deltasquared> BtbN: yeah well, kmsgrab is not cooperating
[18:05:44 CET] <deltasquared> we've been through a lto of that earlier
[18:05:47 CET] <deltasquared> *lot
[18:15:34 CET] <deltasquared> BtbN: for your curiosity if it should be the case, the current invocation: fmpeg -f kmsgrab -framerate 30 -i - -init_hw_device vaapi=v:/dev/dri/renderD128 -filter_hw_device v -vf hwmap,hwdownload,format=bgr0 -vcodec ffvhuff -pix_fmt bgr0 /fs/local/framegrab/huff.mkv
[18:15:55 CET] <deltasquared> > [AVHWDeviceContext @ 0x55d7c9ad7f80] Failed to initialise VAAPI connection: -1 (unknown libva error).
[18:16:11 CET] <deltasquared> if there's one thing that annoys me, it's "unknown errors" that aren't logged.
[18:16:50 CET] <deltasquared> (at least in managed langs with exceptions you generally had no excuse for not providing semi-meaningful error messages.)
[18:17:24 CET] <BtbN> Have you tried putting the hw_device options before -i?
[18:17:40 CET] <deltasquared> no actually, I had not spotted that
[18:18:11 CET] <deltasquared> ... alas same error
[18:19:27 CET] <BtbN> You are using an Intel card though?
[18:20:09 CET] <deltasquared> BtbN: negative. it's just that a certain bug report I came across when getting an error about not being able to map the DRM object suggested trying to use vaapi on AMD cards. let me see if I can find it again.
[18:20:41 CET] <BtbN> Yeah, the whole VAAPI stuff is primarily tested on Intel, and only parts of it work on AMD.
[18:20:45 CET] <deltasquared> https://trac.ffmpeg.org/ticket/7375 then someone on here suggested ditching the derive_device part.
[18:20:55 CET] <deltasquared> if you know a way to make it work by vdpau, by all means...
[18:21:05 CET] <deltasquared> (preferably without needing an x11 connection)
[18:21:17 CET] <BtbN> vdpau has no meanf of doing anything like that
[18:21:19 CET] <BtbN> *s
[18:21:24 CET] <BtbN> It's a pure video decode API
[18:21:30 CET] <BtbN> And it's half-dead
[18:21:34 CET] <deltasquared> well shoot. how else am I supposed to get around the mapping issue then
[18:21:49 CET] <deltasquared> if I just use a straight hwdownload, I get... one moment
[18:21:56 CET] <BtbN> The AMD driver plain might not support doing that
[18:23:03 CET] <deltasquared> :/
[18:23:08 CET] <jkqxz> You might be able ot diagnose "unknown libva error" by running it in strace and seeing what it tries to load.
[18:23:19 CET] <jkqxz> Or building a debug libva and stepping through it in gdb.
[18:23:40 CET] <deltasquared> oof, I'm getting fairly invested in this aren't I :)
[18:23:43 CET] <deltasquared> [AVHWFramesContext @ 0x558a8fef3e40] Failed to map DRM object 4 to memory: 22.
[18:23:43 CET] <deltasquared> [hwdownload @ 0x558a8ff03080] Failed to download frame: -22.
[18:23:43 CET] <deltasquared> Error while filtering: Invalid argument
[18:23:53 CET] <BtbN> Are you sure /dev/dri/renderD128 is correct?
[18:24:00 CET] <deltasquared> BtbN: I have no idea to be quite honest
[18:24:03 CET] <deltasquared> neither seem to work
[18:24:08 CET] <deltasquared> (I have two render nodes)
[18:24:25 CET] <deltasquared> this motherboard doesn't seem capable of disabling the integrated graphics >_>
[18:25:33 CET] <deltasquared> however, I do think that card0 is correct, as the screen resolution is being detected.
[18:27:45 CET] <deltasquared> BtbN: here's the log when I try to use hwdownload,format=bgr0: https://a.uguu.se/LDCDGZcXVKLA_stdin
[18:27:58 CET] <deltasquared> ... err, that does not appear to have worked well
[18:28:02 CET] <deltasquared> stupid mime types
[18:29:25 CET] <jkqxz> That's inability to map the display memory on a discrete card to the CPU, I think.
[18:29:37 CET] <deltasquared> jkqxz: I kinda guessed
[18:29:57 CET] <deltasquared> the question seems to be, what can have it transferred to main memory without involving the CPU to copy data
[18:30:16 CET] <deltasquared> I would have thought "download" implied it could do so, but apparently not.
[18:30:26 CET] <deltasquared> then again how would it... you'd need DMA set up.
[18:31:34 CET] <jkqxz> hwdownload for some APIs (like VDPAU or VAAPI) invokes a special copy to get the stuff into CPU memory.  The KMS/DRM stuff is too generic to know anything about the hardware, so all it can do is try to memory map and copy.
[18:32:47 CET] <deltasquared> so, linux doesn't have a means to do this in all cases?
[18:33:09 CET] <deltasquared> if vaapi isn't universal (or maybe it's an ffmpeg issue? idek anymore)
[18:34:29 CET] <deltasquared> I have tried other solutions before now like simplescreenrecorder. that does not appear to support all codecs that ffmpeg can. e.g. ffvhuff in my case.
[18:34:51 CET] <deltasquared> it'd be neat if that did work; to my understanding the way that's implemented is fairly efficient, involving hooks into opengl rendering.
[18:51:36 CET] <deltasquared> BtbN: actually, doing some experiments, x11grab isn't too bad
[18:51:45 CET] <deltasquared> not much time spend in xorg for instance. 5% cpu at most.
[18:52:47 CET] <deltasquared> if I save rawvideo for instance the workload becomes mostly kernel I/O overhead.
[18:53:16 CET] <deltasquared> (side note, does ffmpeg have a more efficient way of writing loadsadata? mmap or O_DIRECT perhaps?)
[21:45:59 CET] <jkhsjdhjs> hey, just reposting my question: i'm capturing an rtsp stream with ffmpeg. the stream has - according to the metadata - 25 fps. but ffmpeg is recording 15fps. is there any way to write 15fps to the metadata of the recorded file without reencoding it?
[21:46:36 CET] <tmm1> what metadata?
[21:48:43 CET] <jkhsjdhjs> sorry, i don't know that much of rtsp and videos in general. i can show you what ffmpeg says when it begins capturing
[21:51:41 CET] <jkhsjdhjs> https://hastebin.com/uricefabic
[21:53:06 CET] <jkhsjdhjs> in line 8 it says 25fps. but ffmpeg captures 15fps and writes 25fps in the metadata of the mp4 file
[21:56:45 CET] <grosso> all timeout, rw_timeout, etc. settings make no effect
[21:56:58 CET] <grosso> I have a problem when muxing a flv stream. When I call av_interleaved_write frame() and there is no internet connection, it hangs for about 15 minutes and interrupt_callback is never called. This happens only when dealing with rtmps stream (through librtmp I guess); with rtsp there is no problem at all
[21:57:19 CET] <grosso> using ffmpeg v3.3.9
[21:57:28 CET] <grosso> librtmp seems to have a timeout for reading but not for writing
[22:20:32 CET] <jkhsjdhjs> i think i just had to add -r 15 before -i
[22:20:53 CET] <jkhsjdhjs> i'll see 40 minutes if it worked or not
[22:33:39 CET] <ohnx> hi, i'm having some issues using the stop_silence option with the silenceremove filter on ffmpeg 4.0.2-2
[22:34:07 CET] <ohnx> I see the option on the documentation website here: https://ffmpeg.org/ffmpeg-filters.html#silencedetect but when I try to use it on my computer, I am told that "Option 'stop_silence' not found"
[22:42:12 CET] <ohnx> ah never mind, I see now that the latest version of ffmpeg is 4.1.2
[22:49:45 CET] <faLUCE> jkhsjdhjs: something is wrong with your command. you should not add framerate
[22:49:55 CET] <faLUCE> jkhsjdhjs: paste the ffmpeg command
[23:36:09 CET] <remlap> Hi I am trying to build from the github and I get this error: make: *** [ffbuild/common.mak:60: libavfilter/af_sofalizer.o] Error 1
[23:37:25 CET] <faLUCE> remlap: paste a more detailed output int pastebin
[23:37:31 CET] <remlap> ok
[23:37:47 CET] <remlap> https://pastebin.com/sfuCnmAw
[23:39:22 CET] <faLUCE> remlap: OS?
[23:39:26 CET] <faLUCE> remlap: configure?
[23:44:06 CET] <remlap> ubuntu 18.10 https://pastebin.com/9FF8YccK
[23:46:30 CET] <faLUCE> remlap: sudo apt-get install libysofa-dev
[23:46:35 CET] <faLUCE> remlap: sudo apt-get install libmysofa-dev
[23:47:11 CET] <remlap> already got mate
[23:47:18 CET] <furq> it would fail in configure if that was missing
[23:47:34 CET] <faLUCE> furq: yes, but given it's git...
[23:49:36 CET] <remlap> the error seems to date back to 8b53d13 which is ages ago but last time I was able to build successfully
[23:50:18 CET] <remlap> I remember noticing all the changes to sofalizer and reverted back, but its been months and still seeing it when I went to build today
[23:51:03 CET] <furq> oh
[23:51:08 CET] <furq> apparently you need a newer libmysofa
[23:51:10 CET] <faLUCE> remlap: I would check if  mysofa_neighborhood_init_withstepdefine is inside the last release of sofa
[23:51:13 CET] <faLUCE> exactly
[23:51:41 CET] <furq> https://github.com/hoene/libmysofa/commit/ae6dbe79661ca698c7bf5a32506aa90616137ee0
[23:52:17 CET] <remlap> so the repositories version is causing the error?
[23:52:29 CET] <faLUCE> there's not a check for the version of sofa
[23:52:31 CET] <furq> if it's older than august 2018 then it doesn't have that function
[23:52:45 CET] <furq> but yeah it might be worth filing a bug because configure should check that
[23:52:45 CET] <faLUCE> but you can install the new version
[23:53:15 CET] <remlap> okay ill build and see
[23:58:30 CET] <remlap> think its gone through it and still building :)
[23:58:38 CET] <remlap> thanes faLUCE furq
[23:58:43 CET] <remlap> thanks
[00:00:00 CET] --- Mon Mar 25 2019