[issue1688] AVPacket should provide a packet's source address

2010-01-15 Thread Jeremy Morton
Jeremy Morton ffm...@game-point.net added the comment: An addenum of info; the web manpages here: http://www.manpagez.com/man/4/udp/ ... say that UDP sockets are connectionless, and are normally used with the sendto and recvfrom calls, though the connect(2) call may also be used to fix the

[issue1684] QT - Avid 1:1x codec

2010-01-15 Thread Carl Eugen Hoyos
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: The 720p sample works fine now (r21222). _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1684

[issue1688] AVPacket should provide a packet's source address

2010-01-15 Thread Jeremy Morton
Jeremy Morton ffm...@game-point.net added the comment: Adding self. -- nosy: +jez _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1688

[issue1688] AVPacket should provide a packet's source address

2010-01-15 Thread Ronald S. Bultje
Ronald S. Bultje rsbul...@gmail.com added the comment: The man 4 udp stuff I quoted earlier on IRC. There's two questions here that are interesting. 1) UDP is - in ffmpeg - primarily used for RTP, which is point-to-point. It makes no sense to provide the source IP to the client because we know

[issue1688] AVPacket should provide a packet's source address

2010-01-15 Thread Jeremy Morton
Jeremy Morton ffm...@game-point.net added the comment: Actually, having perused the SDP RFC a little more, I think the only line in the SDP that should really have a chance of limiting the traffic by source IP is the c= line. This is supposed to specify the source IP for the data. The fact

[issue1688] AVPacket should provide a packet's source address

2010-01-15 Thread Jeremy Morton
Jeremy Morton ffm...@game-point.net added the comment: (continuation, sorry, submitted too early): I'm not sure whether the c= line in an SDP file is intended to say this is the source IP for data; if it doesn't come from here, you ignore it, or is just meant as a you may want to look here for

[issue1690] QT - Blackmagic 8 bit (2Vuy) codec

2010-01-15 Thread ami_stuff
New submission from ami_stuff ami_st...@o2.pl: Attached patch fixes support for Blackmagic 8 bit (2Vuy) codec. http://samples.mplayerhq.hu/V-codecs/2Vuy2.mov C:\ffmpeg -i 2Vuy2.mov FFmpeg version SVN-r21134, Copyright (c) 2000-2010 Fabrice Bellard, et al. built on Jan 11 2010 06:03:04 with

[issue1689] patch: minor MinGW corrections/changes

2010-01-15 Thread Ramiro Polla
Ramiro Polla ram...@lisha.ufsc.br added the comment: On Fri, Jan 15, 2010 at 3:13 PM, kemuri iss...@roundup.ffmpeg.org wrote: kemuri kemu...@gmail.com added the comment: 2) no, my MinGW x86 3.4.5 and 4.4.2, as well as x86_64 4.4.2 all give warnings with -fPIC: `warning: -fPIC ignored for

[issue1689] patch: minor MinGW corrections/changes

2010-01-15 Thread kemuri
kemuri kemu...@gmail.com added the comment: What configure line are you using to get these? I can't get them with any combination of enabling/disabling shared or static. oh it was occurring when i was compiling for MinGW x86_64... something as simple as ./configure

[issue208] Real Audio Sipr / ACELP.net

2010-01-15 Thread Vitor
Vitor vitor1...@gmail.com added the comment: Last mode implemented in r21234. -- status: open - closed substatus: needs_changes - implemented FFmpeg issue tracker iss...@roundup.ffmpeg.org