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

[burek]

[01:27:18 CEST] <BtbN> Is there any reason not to drop librtmp support?
[01:39:29 CEST] <RiCON> BtbN: as long as rtmpe/s is working fine
[01:59:27 CEST] <BtbN> well, the native code at least claims support, but I wouldn't know how to test
[02:00:49 CEST] <atomnuker> both work, but I don't know the difference either
[02:02:12 CEST] <atomnuker> I wish people would stop using flv over rtmp for streaming like its 2002
[02:03:20 CEST] <BtbN> Well, there's a distinct lack of alternatives
[02:03:54 CEST] <BtbN> The only alternative that has popped up is libftl. Which is essentially webrtc
[02:04:20 CEST] <atomnuker> well there are plenty of alternatives
[02:04:40 CEST] <BtbN> All the popular streaming applications only support rtmp. All the major streaming platforms only take rtmp
[02:05:10 CEST] <BtbN> I'm also not aware of any real alternative which has the same features
[02:05:10 CEST] <atomnuker> I know, that's what's bothering, you can just stream matroska over udp and resend the header on every keyframe
[02:05:25 CEST] <atomnuker> rcombs does this all the time afaik
[02:05:35 CEST] <BtbN> Doing that won't have the same somewhat intelligent frame dropping mechanism
[02:05:41 CEST] <nevcairiel> rtmp is for serving to the streaming website, its rarely only used for clients anymore
[02:05:54 CEST] <atomnuker> what frame dropping mechanism?
[02:06:00 CEST] <rcombs> I do it over HTTP and I don't re-send the header
[02:06:20 CEST] <BtbN> rtmp is intelligent when dropping frames. It drops B frames first, and does its very best to not drop I frames
[02:06:27 CEST] <atomnuker> well if you did it over udp and wanted some resilience you'd resend the header
[02:06:41 CEST] <atomnuker> which side?
[02:06:44 CEST] <rcombs> yeah, I'm not sure if that breaks anything or not
[02:06:54 CEST] <BtbN> and no way to identify the user as well. You'd need one port per user
[02:06:58 CEST] <BtbN> with UDP
[02:06:58 CEST] <rcombs> like, do matroska demuxers handle the header being re-sent? ¯\_(Ä)_/¯
[02:07:12 CEST] <rcombs> also last I checked librtmp supports a few sites that ffrtmp does not
[02:07:12 CEST] <BtbN> atomnuker, the sending side
[02:07:30 CEST] <atomnuker> why does the sending side drop frames? how does it know when to do so?
[02:07:31 CEST] <rcombs> but that was a while back and RTMP's gotten far less common for stream-to-client, yeah
[02:07:57 CEST] <BtbN> When the TCP send command comes back as "buffer full" I guess
[02:08:02 CEST] <BtbN> it reacts to network congestion
[02:08:40 CEST] <atomnuker> tcp shouldn't be used for live streaming at all, by the time a packet is resent its too late
[02:08:49 CEST] <BtbN> that's why it's not resent
[02:09:03 CEST] <BtbN> And TCP does a pretty decent job running pretty much every bigger livestream right now
[02:09:06 CEST] <atomnuker> but the protocol itself handles that for you, doesn't it?
[02:09:24 CEST] <atomnuker> not as good as udp would do with a custom protocol and some FEC
[02:09:32 CEST] <BtbN> I'm actually not sure _how_ rtmp reacts to congestion, but it does
[02:10:12 CEST] <BtbN> with UDP you would get garbled data. With rtmp you get dropped frames
[02:10:26 CEST] <atomnuker> it really shouldn't imo, there's not much it can do, if the network's congested and it drops all but the I-frame there's little chance such a big video frame packet can make it
[02:10:56 CEST] <BtbN> It works pretty nicely actually
[02:11:02 CEST] <atomnuker> with udp you wouldn't get garbled data so much if you had error correction
[02:11:09 CEST] <BtbN> most of the time if the network is just barely overwhelmed you don't even notice the few missing frames
[02:12:16 CEST] <atomnuker> right, well, what if the dropped frame was meant to be used as a reference for the next frames?
[02:12:23 CEST] <atomnuker> you'd notice that pretty quickly
[02:12:35 CEST] <BtbN> That's why it drops B frames first
[02:12:54 CEST] <BtbN> The frames with missing references will/should be skipped by the decoder
[02:13:18 CEST] <atomnuker> it has to drop P frames eventually too, you can't use too many B frames when sending if you want to keep latency low
[02:13:44 CEST] <BtbN> Most live-streams are actually P frame only I guess
[02:14:21 CEST] <BtbN> Ideally, if it starts dropping frames, it would signal the encoder to not use the dropped frame as reference.
[02:14:31 CEST] <BtbN> OBS implements it like that i believe
[02:14:51 CEST] <atomnuker> all of this can still be implemented on top of udp though
[02:15:00 CEST] <atomnuker> to get better latency
[02:15:02 CEST] <BtbN> With UDP you have no idea what frames got dropped
[02:15:21 CEST] <atomnuker> that's why you implement some backward feedback
[02:15:59 CEST] <BtbN> Going that route you'll eventually end up with something similar to rtmp
[02:16:07 CEST] <BtbN> Just without all the flash stuff
[02:16:11 CEST] <atomnuker> yesssss
[02:16:21 CEST] <atomnuker> the flash stuff is what my original complain was about
[02:16:41 CEST] <atomnuker> no hevc, opus, vp9, only mp3 and aac at 44100 khz without any 48khz support
[02:16:45 CEST] <atomnuker> its 2002 vintage
[02:16:53 CEST] <BtbN> 48kHz works just fine via rtmp
[02:17:03 CEST] <atomnuker> nope it doesn't, flv only supports 44100
[02:17:09 CEST] <BtbN> It works anyway
[02:17:18 CEST] <atomnuker> it shouldn't, the muxer errors out
[02:17:36 CEST] <BtbN> I have streamed plenty of streams to Twitch with ffmpeg with 48kHz audio. It definitely works.
[02:17:45 CEST] <atomnuker> well our muxer errors out
[02:18:00 CEST] <atomnuker> try it
[02:18:08 CEST] <BtbN> I did last week. For a week straight.
[02:18:36 CEST] <nevcairiel> actually it allows aac with 48k
[02:20:01 CEST] <atomnuker> are you sure? I'm reading the code, it shouldn't
[02:20:08 CEST] <BtbN> It does
[02:20:18 CEST] <nevcairiel> you must not read very hard =p
[02:20:31 CEST] <atomnuker> I do, read line 132 of flvenc.c
[02:20:35 CEST] <nevcairiel> there is a specific exception for aac right at the beginning to just not do anything
[02:20:39 CEST] <atomnuker> if (par->codec_id == AV_CODEC_ID_AAC) // specs force these parameters
[02:20:41 CEST] <atomnuker>         return FLV_CODECID_AAC | FLV_SAMPLERATE_44100HZ |
[02:20:43 CEST] <atomnuker>                FLV_SAMPLESSIZE_16BIT | FLV_STEREO;
[02:20:51 CEST] <nevcairiel> and those flags just dont do anything
[02:21:39 CEST] <atomnuker> but they do, they're encoded after all: avio_w8(pb, get_audio_flags(s, par));
[02:21:55 CEST] <nevcairiel> and where exactly is it erroring out on those? :)
[02:22:16 CEST] <atomnuker> it used to error out, I swear
[02:22:39 CEST] <BtbN> flv cannot signal 48kHz. but it still works, because aac and mp3 can, and that's what all decoders look at
[02:22:59 CEST] <nevcairiel> here, flv spec:
[02:23:31 CEST] <nevcairiel> wtf is wrong with this pdf, why cant i copypaste from it
[02:23:39 CEST] <atomnuker> ...you two are defending flv just to argue, not for real, r-right?
[02:23:48 CEST] <nevcairiel> cant let someone be wrong
[02:24:13 CEST] <BtbN> thing with flv is, it's still just enough for what the majority of end users can take as a stream
[02:24:34 CEST] <BtbN> as long as that doesn't change, nobody will care enough to migrate
[02:24:46 CEST] <atomnuker> it ought to change sooner or later or we'll get vfw-like hacks for av1 in rtmp
[02:24:57 CEST] <BtbN> If you start sending HEVC or VP9, you will leave behind a lot of users because of their shit PC
[02:25:16 CEST] <atomnuker> you don't reject if a user sends h264
[02:25:19 CEST] <nevcairiel> Anyhow for some reason i cant copy-paste the flv spec, but it basically says that it should always say what those flags there say, but players should ignore it and just read the AAC headers
[02:25:27 CEST] <BtbN> According to twitch stats, almost 30% of users PCs are to shit to handle 1080p60 decoding in real time
[02:25:44 CEST] <atomnuker> they transcode it anyway
[02:25:52 CEST] <atomnuker> this is for client->server
[02:26:03 CEST] <BtbN> Twitch passes the ingestes stream through untouched
[02:26:12 CEST] <BtbN> Only the lower quality levels are transcodes
[02:27:39 CEST] <BtbN> Point is, if 30% of users can't even handle 1080p60 h264, for which hw decoding is _very_ widespread... even VP9 will be a nightmare
[02:27:43 CEST] <BtbN> let alone AV1
[02:28:06 CEST] <atomnuker> its fine, they can watch the transcodes
[02:28:30 CEST] <BtbN> And you'll also somehow need to encode your stream in realtime
[02:28:42 CEST] <nevcairiel> for realtime encoding you probably cant beat h264 anyway, the other formats are just so slow
[02:28:53 CEST] <atomnuker> hardware vp9/hevc encoders exist since kabylakes
[02:29:08 CEST] <BtbN> And are all beat to the ground by x264
[02:29:19 CEST] <nevcairiel> i would go  with ultrafast x264 over hardware anyway
[02:29:30 CEST] <atomnuker> yeah they're not great but they exist
[02:29:52 CEST] <atomnuker> most users use hardware encoding though, because they can't spare 6 cores for superfast x264
[02:29:53 CEST] <nevcairiel> especially with high-core CPUs becoming far more readily  available, which is really good for people that play and stream
[02:30:01 CEST] <BtbN> h264 is just more than good enough. I don't see people switching to anything else in the next decade
[02:30:19 CEST] <atomnuker> yeah, they're a bit slow if they're still using flv, eh
[02:30:29 CEST] <BtbN> The absolute vast majority of people use x264
[02:30:31 CEST] <BtbN> on veryfast
[02:30:40 CEST] <BtbN> Cause that's the default in OBS and XSplit
[02:30:42 CEST] <nevcairiel> noone cares that they are using  flv, its just a transmission format from here to the server
[02:31:02 CEST] <atomnuker> a very restrictive one
[02:31:12 CEST] <atomnuker> also 1/1000 timebase
[15:41:20 CEST] <durandal_1707> j-b: ping
[16:18:22 CEST] <cone-567> ffmpeg 03Michael Niedermayer 07master:6b67d7f05918: avformat/flvenc: Check audio packet size
[16:18:22 CEST] <cone-567> ffmpeg 03Michael Niedermayer 07master:47db5763e21c: avcodec/aacpsdsp_template: Fix integer overflow in ps_stereo_interpolate_c()
[16:18:22 CEST] <cone-567> ffmpeg 03Michael Niedermayer 07master:40c2f870aec9: avcodec/aacdec_template: Check for duplicate elements
[16:18:22 CEST] <cone-567> ffmpeg 03Michael Niedermayer 07master:83dab8183e9f: avcodec/simple_idct_template: Fix several integer overflows
[16:18:22 CEST] <cone-567> ffmpeg 03Michael Niedermayer 07master:1940c27c8272: avcodec/pnm_parser: Avoid reparsing failed data.
[00:00:00 CEST] --- Sun Aug  5 2018