On 29.06.2025 15:18, Jack Lau wrote:
On Jun 29, 2025, at 19:47, Timo Rothenpieler <t...@rothenpieler.org> wrote:
On 29.06.2025 05:14, Jack Lau wrote:
On Jun 29, 2025, at 11:11, Jack Lau <jacklau122...@gmail.com> wrote:
Hi Timo,
On Jun 29, 2025, at 06:49, Timo Rothenpieler <t...@rothenpieler.org> wrote:
I've actually cleaned this up a bit while trying to implement DTLS via
schannel, and effectively removed the whole section:
https://github.com/BtbN/FFmpeg/commit/b6794f1373fb07b791cfacd2189c7efc4d6bdbcc
There's also a bunch of other necessary UDP related fixes in tls.c.
Don't try to use an http proxy for UDP. It doesn't work:
https://github.com/BtbN/FFmpeg/commit/709ce9e5c48e3a27a400cf5af35038d3f0602c8a
I totally agree with the above two patches, it’s very reasonable
Properly forward the various hosts and ports to udp.c so it actually works when
using a non-external UDP connection:
https://github.com/BtbN/FFmpeg/commit/46375adf7d9cc61f709ab14dd2ea017995f735db
But I think this patch need a bit modify, I think the c->listen stands for
FFmpeg if is server. When it is true, FFmpeg as server.
So maybe:
if (c->listen) {
av_dict_set_int(options, "localport", port, 0);
av_dict_set(options, "localaddr", c->underlying_host, 0);Add
commentMore actions
} else {
av_dict_set_int(options, "connect", 1, 0);
}
Sry for forgetting modify this code, the right code I want to express is that:
if (c->listen) {
av_dict_set_int(options, "connect", 1, 0);
} else {
av_dict_set_int(options, "localport", port, 0);
av_dict_set(options, "localaddr", c->underlying_host, 0);
}
It goes together with
https://github.com/BtbN/FFmpeg/commit/6fc902eb75554e6ad91a2ddf4ce1d131feee6f55
Without setting the localport to 0 in client-mode in combination with above
patch, it'll try to bind to the port passed in the URL, which when tryong to
connect to a server on localhost will result in a bind failure, cause it tried
to bind to the same port.
I also found this issue, I’m not sure modify the udp code if is suitable, but I
can provide a workaround:
The udp.c code clearly is lacking for this, so fixing it seems the right
course of action to me.
We shouldn't be working around our own code.
@@ -127,23 +127,22 @@ int ff_tls_open_underlying(TLSShared *c, URLContext
*parent, const char *uri, AV
- ret = ffurl_open_whitelist(c->is_dtls ? &c->udp : &c->tcp, buf,
AVIO_FLAG_READ_WRITE,
+ ret = ffurl_open_whitelist(c->is_dtls ? &c->udp : &c->tcp, buf,
+ c->is_dtls ? (c->listen ? AVIO_FLAG_READ :
AVIO_FLAG_WRITE) : AVIO_FLAG_READ_WRITE,
That does seem like a crude hack-around to me at best.
Since a DTLS UDP socket will always be AVIO_FLAG_READ_WRITE, since the
communications is unavoidably two-way.
It seems much better to me to adjust udp.c to properly support two-way
communication.
There's also other issues, like the fifo it sets up for the packet
processing thread will happily be used by both the udp_read and write
functions if it's there, causing absolute chaos.
https://github.com/FFmpeg/FFmpeg/commit/8d3096f7ac7c2a9193dac901a5f6b9d604a68882
In theory it could also launch both rx and tx queue now, but I focused
on fixing the interference first.
There's other places where it clearly assumes to only ever be used for
reading or writing, never both. DTLS might be the first instance of that
no longer holding true.
You can see the full set of patches here:
https://github.com/FFmpeg/FFmpeg/compare/master...BtbN:FFmpeg:schannel_dtls
There's a bunch more udp.c related enhancements and fixes.
Like, actually being able to find out who just sent a packet (schannel
demands the clients sockaddr to do anything when in server mode).
The schannel dtls code works in client mode already (i.e. I can stream
to an openssl s_server -dtls with it).
But for server mode _something_ is going wrong with loading the servers
certificate, and I haven't figured out what it is yet.
&parent->interrupt_callback, options,
parent->protocol_whitelist,
parent->protocol_blacklist, parent);
diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
index 2a3905891d..9cc5acd3e1 100644
--- a/libavformat/tls_openssl.c
+++ b/libavformat/tls_openssl.c
@@ -985,6 +985,9 @@ static int dtls_start(URLContext *h, const char *url, int
flags, AVDictionary **
av_log(p, AV_LOG_ERROR, "Failed to connect %s\n", url);
return ret;
}
+ /* Make the socket non-blocking, set to READ and WRITE mode after
connected */
+ ff_socket_nonblock(ffurl_get_file_handle(p->tls_shared.udp), 1);
+ p->tls_shared.udp->flags |= AVIO_FLAG_READ | AVIO_FLAG_WRITE |
AVIO_FLAG_NONBLOCK;
}
And "connect" in listen mode makes no sense to me?
There is no remote address, where would it "connect" the socket to?
Oops! I got it mixed up.
You’re right.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org>
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org <mailto:ffmpeg-devel-requ...@ffmpeg.org> with subject
"unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".