I made it into two patches, the first one only moves
udp_set_multicast_ttl and second one does the fix.
On Fri, Aug 5, 2016 at 3:19 AM, Michael Niedermayer
wrote:
> On Fri, Aug 05, 2016 at 01:20:12AM +0430, Omid Ghaffarinia wrote:
>> Thanks for your comment, actually
On Fri, Aug 05, 2016 at 01:20:12AM +0430, Omid Ghaffarinia wrote:
> Thanks for your comment, actually 'code move' is necessary to make the
> code compile because it is needed to use udp_set_url in
> udp_set_multicast_ttl and the code is moved to make it possible.
> I can make it in two separate
Thanks for your comment, actually 'code move' is necessary to make the
code compile because it is needed to use udp_set_url in
udp_set_multicast_ttl and the code is moved to make it possible.
I can make it in two separate patches if needed, first to move
udp_set_multicast_ttl without any further
On Wed, Aug 03, 2016 at 12:29:17PM +0430, Omid Ghaffarinia wrote:
> Does it still fail?
no failure
i would prefer if the code move would be in a seperate
patch though. Its harder to review for developers as is
thx
[...]
--
Michael GnuPG fingerprint:
Does it still fail?
Thanks in advance.
On Sat, Jul 23, 2016 at 10:36 AM, Omid Ghaffarinia
wrote:
> I'm sorry for that, it failed because it was prepared for release/2.8,
> this one should work on master.
>
>
> On Thu, Jul 21, 2016 at 3:48 AM, Michael Niedermayer
>
I'm sorry for that, it failed because it was prepared for release/2.8,
this one should work on master.
On Thu, Jul 21, 2016 at 3:48 AM, Michael Niedermayer
wrote:
> On Wed, Jul 20, 2016 at 05:38:10PM +0430, Omid Ghaffarinia wrote:
>> Thanks for testing in mingw
>> New
On Wed, Jul 20, 2016 at 05:38:10PM +0430, Omid Ghaffarinia wrote:
> Thanks for testing in mingw
> New patch attached, which should work now.
still fails, even on ubuntu:
libavformat/udp.c: In function ‘udp_set_multicast_ttl’:
libavformat/udp.c:367:13: warning: passing argument 1 of ‘udp_set_url’
Thanks for testing in mingw
New patch attached, which should work now.
On Wed, Jul 20, 2016 at 1:25 PM, Michael Niedermayer
wrote:
> On Wed, Jul 13, 2016 at 03:09:28PM +0430, Omid Ghaffarinia wrote:
>> I attached the patch.
>>
>> The actual bug is, when creating a local
On Wed, Jul 13, 2016 at 03:09:28PM +0430, Omid Ghaffarinia wrote:
> I attached the patch.
>
> The actual bug is, when creating a local multicast stream (i.e. giving
> "rtp://224.1.1.1:1?ttl=0" to avio_open), then you can see the
> packets on the network and not just on local machine (despite
Is the patch approved or does it need more explanation?
On Wed, Jul 13, 2016 at 3:09 PM, Omid Ghaffarinia
wrote:
> I attached the patch.
>
> The actual bug is, when creating a local multicast stream (i.e. giving
> "rtp://224.1.1.1:1?ttl=0" to avio_open), then you
I attached the patch.
The actual bug is, when creating a local multicast stream (i.e. giving
"rtp://224.1.1.1:1?ttl=0" to avio_open), then you can see the
packets on the network and not just on local machine (despite setting
multicast ttl to 0) which was a security bug in my purpose of usage
On Tue, Jul 12, 2016 at 18:31:36 +0430, Omid Ghaffarinia wrote:
Your mailer has broken the patch by inserting line breaks. You should
try attaching the patch as a file, or directly using "git send-email".
> Bug is due to kernel handling multicast ttl 0 differently (as noted in
> kernel code
When using ffmpeg to start a local-only server (i.e. setting ttl=0)
using multicast ip (i.e. 224.1.1.1) you can see packets going to
network.
Bug is due to kernel handling multicast ttl 0 differently (as noted in
kernel code net/ipv4/route.c:2191 see:
13 matches
Mail list logo