[issue1688] AVPacket should provide a packet's source address
Michael Niedermayer michae...@gmx.at added the comment: On Sun, Jan 24, 2010 at 10:52:08AM +, Jeremy Morton wrote: Jeremy Morton ffm...@game-point.net added the comment: But I still have to understand what the requirements are, and why providing the packet's source address in AVPacket would help (I suspect it would be kind of useless for RTP...). Luca, The requirement is for the calling code to be able to somehow tell ffmpeg which UDP packets to accept, and which to reject. In my case it needs to be based on source IP (perhaps port would be worth including too). Because UDP is connectionless, the code may want to reject packets from invalid source IPs to stop a DoS-style attack (eg. A is streaming video data to port 6789 so that when B streams its video data, you get a mixed up mess of 2 streams instead of one unless you reject A's packets). RTP has ssrc and seq numbers to get them right he will probably need access to your network and if he does have access to it the IP will not help you So i still dont see what kind of attack this would protect against about UDP if you only want packets from a specific IP the correct way is to specify this IP during open somehow not to accept all packets and after wasting resources to a DOS attack reject packets. [...] _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1688 _
[issue1709] ac3_decode_frame does not return err on error
New submission from gnif ge...@spacevs.com: The function ac3_decode_frame does not return the value of err when an error has occurred, instead it returns s-frame_size. To reproduce, just supply an incomplete ac3 frame and note the output of ac3_decode_frame -- messages: 9010 priority: normal status: new substatus: new title: ac3_decode_frame does not return err on error topic: avcodec type: bug _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1709 _
[issue1688] AVPacket should provide a packet's source address
Jeremy Morton ffm...@game-point.net added the comment: RTP has ssrc and seq numbers to get them right he will probably need access to your network and if he does have access to it the IP will not help you But ffmpeg is receiving 2 valid video streams; both have valid ssrc and seq numbers. It doesn't know which is the right one, as is evidenced by the current behaviour where is spews out errors and occasionally shows frames from each of the video streams. about UDP if you only want packets from a specific IP the correct way is to specify this IP during open somehow not to accept all packets and after wasting resources to a DOS attack reject packets. 'somehow'? How, exactly, do you do that with incoming UDP packets? It's a connectionless protocol. Windows boxes do not have iptables, and trying to dynamically configure some other firewall to get this behaviour to happen is a major nightmare. It's far better IMHO to do it inside ffmpeg. Maybe not by bloating AVPacket, but perhaps by some callback function that lets your code tell ffmpeg whether or not to accept+process the packet. _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1688 _
[issue1688] AVPacket should provide a packet's source address
Luca Barbato lu_z...@gentoo.org added the comment: On 01/24/2010 02:21 PM, Jeremy Morton wrote: Jeremy Morton ffm...@game-point.net added the comment: RTP has ssrc and seq numbers to get them right he will probably need access to your network and if he does have access to it the IP will not help you But ffmpeg is receiving 2 valid video streams; both have valid ssrc and seq numbers. It doesn't know which is the right one, as is evidenced by the current behaviour where is spews out errors and occasionally shows frames from each of the video streams. so the ssrcs are the same for both of the streams? otherwise we got a but that should be fixed in the rtp demuxer ^^; about UDP if you only want packets from a specific IP the correct way is to specify this IP during open somehow not to accept all packets and after wasting resources to a DOS attack reject packets. 'somehow'? How, exactly, do you do that with incoming UDP packets? if the ssrc is different then is easy otherwise... we have to think a bit more ^^; lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1688 _
[issue1641] mpegts initial decoding issue
Michael Niedermayer michae...@gmx.at added the comment: On Thu, Dec 24, 2009 at 03:34:03AM +, Mark Spieth wrote: [...] utils.c |3 +++ 1 file changed, 3 insertions(+) f0e2f94fcafd17f6ed36c272f698318a21faaf2a ffmpeg-estimate-cleanup.patch cleanup packetbuffer after duration estimation for mpeg if the bug is confirmed and its confirmed that the patch fixes it then iam ok with the patch [...] _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1641 _
[issue1641] mpegts initial decoding issue
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: @mspieth: Please provide a command line to reproduce this issue. If not every mpeg2video (+mp2/ac3 audio) in mpegts sample can be used to reproduce the issue, please provide a sample as well. -- status: new - open substatus: new - needs_more_info _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1641 _
[issue1633] Recent patch to libavcodec/h264.c breaks playback of legit files
Christos Gourdoupis xg...@tellas.gr added the comment: that might round down more than needed 30 bits (9 decimal digits) of significance is a huge level of precision that you don't meet everyday in real life. But I guess you can go to (131 - 1 = 0x7FFF ). Above that a possible multiplication by 2 will overflow. _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1633 _
[issue1709] ac3_decode_frame does not return err on error
Justin Ruggles justin.rugg...@gmail.com added the comment: This is intended behavior. The only time it actually returns an error is when there is a frame sync loss. Partial or invalid frames will trigger error concealment, which repeats the last known good block until the next valid frame is decoded. -- status: new - closed substatus: new - invalid _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1709 _
[issue1709] ac3_decode_frame does not return err on error
Reimar Döffinger b...@reimardoeffinger.de added the comment: On Sun, Jan 24, 2010 at 09:43:14PM +, Justin Ruggles wrote: Justin Ruggles justin.rugg...@gmail.com added the comment: This is intended behavior. The only time it actually returns an error is when there is a frame sync loss. Partial or invalid frames will trigger error concealment, which repeats the last known good block until the next valid frame is decoded. I think a patch to extend avctx-error_concealment to allow enabling/disabling different aspects of this behaviour would be welcome. _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1709 _
[issue1687] QT - YV12 - wrong colors
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: Fixed (including -vcodec copy -f avi) in r21436. -- status: open - closed substatus: reproduced - fixed _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1687 _
[issue1709] ac3_decode_frame does not return err on error
Justin Ruggles justin.rugg...@gmail.com added the comment: Yes, it would be welcome. Reopening as a feature request. -- priority: normal - minor status: closed - open substatus: invalid - open type: bug - feature_request _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1709 _
[issue1687] QT - YV12 - wrong colors
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: Upload codec's readme. _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1687 _ Readme.rtf Description: RTF file
[issue1258] TrueHD Audio in EVO container refuses to play
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment: Sample moved to samples/evob. _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1258 _
[issue1705] Return 'lib' prefix to windows shared libraries
LRN lrn1...@gmail.com added the comment: I had problems building gst-ffmpeg on Windows with MSys. gst-ffmpeg looks for lib*.dll files and freaks out when it is unable to find them (at the moment i can't tell you exactly what it does - i don't remember; i can find out, if that's important). This is fixable, of course, but i wanted to know just how attached you are to lib-less names before trying to make a patch that fixes this in gst-ffmpeg permanently. -- priority: normal - wish _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1705 _
[issue1705] Return 'lib' prefix to windows shared libraries
Mans Rullgard m...@mansr.com added the comment: LRN iss...@roundup.ffmpeg.org writes: LRN lrn1...@gmail.com added the comment: I had problems building gst-ffmpeg on Windows with MSys. gst-ffmpeg looks for lib*.dll files and freaks out when it is unable to find them (at the moment i can't tell you exactly what it does - i don't remember; i can find out, if that's important). So gscreamer is busted. Fix it. This is fixable, of course, but i wanted to know just how attached you are to lib-less names before trying to make a patch that fixes this in gst-ffmpeg permanently. Changing the names would break things for everybody, and contrary to popular belief, that is something we avoid doing without good reason. _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1705 _
