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

[burek]

[00:05:36 CEST] <nine_milli> blb
[02:32:00 CEST] Last message repeated 1 time(s).
[03:39:17 CEST] <TikityTik> how do you preserve transparency with making gifs?
[04:29:28 CEST] <nine_milli> blb
[11:20:40 CEST] <Guillaume412> Hello
[11:20:55 CEST] <Guillaume412> I'm currently encountering countless problems using ffmpeg to stream RTP video. Can you help me please ?
[12:10:32 CEST] <DHE> not if you don't at least mention what problems you're encountering
[16:17:23 CEST] <nine_milli> blb
[17:30:53 CEST] <dooteo> Hi all, which are parameters to screencast with mpeg-2 video codec, and which would be sdp file parameters to be played by ffplay?
[17:37:34 CEST] <kepstin> dooteo: lol, why would you want to use mpeg 2 video?
[19:06:02 CEST] <fpihl> `ffprobe -show_frames file.ivf` have many empty fields for AV1, especially `pict_type=?`. Using libaom. How can i fix this?
[19:11:45 CEST] <kepstin> fpihl: you could become an ffmpeg developer and work on it, i suppose? other than that, av1 stuff is still in active development and is changing all the time :/
[19:13:12 CEST] <kepstin> make sure you're using the latest ffmpeg git master, too
[19:17:19 CEST] <fpihl> kepstin: did a git pull last week so I'm not on latest. Do you now where to start digging?
[19:20:12 CEST] <kepstin> hmm. -show_frames is looking at decoder output, so you'd be looking at the libaom api (you might have to do development there if it doesn't expose the informamtion) and ffmpeg's libavcodec/libaomdec.c wrapper
[19:20:38 CEST] <kepstin> fpihl: also consider building your ffmpeg with libdav1d support, it looks like the dav1d decoder wrapper sets more of these fields already
[19:24:42 CEST] <fpihl> kepstin: thanks, I'll try dav1d instead. Everything is available in Dav1dFrameHeader, the questions is just if/how it's exported...
[22:01:11 CEST] <Guillaume412> Hello. Is there a solution to stream to some browser with low latency (using ffmpeg of course) ?
[22:03:19 CEST] <nine_milli> blb
[22:08:05 CEST] <klaxa> sounds easy, in reality: not so easy
[22:09:22 CEST] <kepstin> to get really low latency you basically need to use webrtc, which ffmpeg isn't able to do on its own.
[22:09:47 CEST] <kepstin> can probably get down to a few seconds with carefully tuned segmented streaming
[22:10:29 CEST] <Guillaume412> haha
[22:10:47 CEST] <Guillaume412> oh I see
[22:11:46 CEST] <Guillaume412> I can get down to 200ms with rtp over internet, would like to keep this latency through websocket... Is there a way to attach ffmpeg rtp output to some websocket system ?
[22:12:21 CEST] <BtbN> If you write one yourself, yes. Not out of the box, no.
[22:12:46 CEST] <Guillaume412> Okay, Thanks
[22:13:10 CEST] <kepstin> note that rtp might not be the best option there, but it would work. In order to feed the browser the data you'll have to use MSE in javascript, which pretty much means remuxing it there.
[22:13:34 CEST] <Guillaume412> Also, do you know a good way to transmit low latency video from one pc to another ?
[22:13:56 CEST] <Guillaume412> ok
[22:13:59 CEST] <kepstin> for two pcs on a lan, just use ordinary rtp (over udp)
[22:14:36 CEST] <Guillaume412> Just what I'm doing now - sending with ffmpeg and receiving with mplayer
[22:15:58 CEST] <kepstin> if you're getting high latency with rtp, there's a few things to look at - encoder settings (maybe the encoder is in a high delay mode, x264 is high delay by default) and player buffering.
[22:17:52 CEST] <BtbN> There is no real protocol for the kind of low latency you are talking
[22:18:04 CEST] <BtbN> every solution that exists, like Steam In-Home, is proprietary
[22:18:15 CEST] <Guillaume412> oh, I understand why
[22:18:27 CEST] <BtbN> And has custom software throughout the whole stack, including the de/encoders
[22:18:52 CEST] <Guillaume412> like Stadia
[22:19:28 CEST] <BtbN> The WiiU Gamepad even use a custom variant of h264
[22:19:37 CEST] <Guillaume412> oh
[22:19:45 CEST] <Guillaume412> interesting
[22:22:00 CEST] <BtbN> They disabled all parts that took to long, or something like that
[22:25:54 CEST] <kepstin> x264 with tune "fastdecode,zerolatency" is probably pretty close tho that, tho.
[22:31:12 CEST] <kepstin> together those disable bframes, mbtree, lookahead, frame threading, in-loop deblocker, weighted prediction, cabac :)
[22:34:02 CEST] <Guillaume412> ok, thanks
[23:40:37 CEST] <ossifrage> I see about 300-500ms of end-to-end latency with RTSP/RTP with mpv --profile=low-latency
[00:00:00 CEST] --- Thu Jul 25 2019