[issue2685] Input file names with colons aren't seen by ffmpeg
Luca Barbato lu_z...@gentoo.org added the comment: It a non so apparent normal behaviour, ffmpeg accepts uris, assuming the default protocol being file:// so a:b.mp3 got parsed as protocol a resource b.mp3 I'm afraid. __ Libav issue tracker iss...@roundup.libav.org https://roundup.libav.org/issue2685 __
[issue2246] 'too many video packets in the buffer' with mp4 (mplayer lavf demuxer)
Luca Barbato lu_z...@gentoo.org added the comment: gwirth I'm about to format your patch, I'd use the name and email provide to roundup to give credit. Is that ok for you? ___ Libav issue tracker iss...@roundup.ffmpeg.org https://roundup.libav.org/issue2246 ___
[issue2040] strange interaction of avfilter with ffmpeg multiple output stream ad different widths
Luca Barbato lu_z...@gentoo.org added the comment: Sister issue being having partial transcoding of a multi video stream file impossible Input #0, nut, from 'out.nut': Metadata: encoder : Lavf52.102.0 Duration: 00:13:15.00, start: 0.00, bitrate: 63 kb/s Stream #0.0: Video: mpeg4, yuv420p, 352x288, 25 tbr, 25 tbn, 25 tbc Stream #0.1: Audio: mp2, 44100 Hz, 2 channels, s16, 64 kb/s Stream #0.2: Video: flv, yuv420p, 35x28, 25 tbr, 25 tbn, 25 tbc this breaks encoding: ffmpeg -re -i out.nut out.flv -newvideo -vcodec copy FFmpeg version git-6a7e074, Copyright (c) 2000-2011 the FFmpeg developers built on Mar 8 2011 16:38:43 with gcc 4.5.2 configuration: --prefix=/usr --libdir=/usr/lib64 --shlibdir=/usr/lib64 --mandir=/usr/share/man --enable-shared --cc=x86_64-pc-linux-gnu-gcc --enable-gpl --enable-version3 --enable-postproc --enable-avfilter --disable-stripping --disable-debug --disable-doc --disable-vaapi --disable-static --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libfaac --enable-nonfree --enable-libdc1394 --disable-indev=oss --enable-x11grab --disable-outdev=oss --enable-pthreads --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libvpx --enable-libopenjpeg --disable-altivec --disable-amd3dnow --disable-amd3dnowext --cpu=core2 --enable-hardcoded-tables libavutil50. 39. 0 / 50. 39. 0 libavcodec 52.113. 2 / 52.113. 2 libavformat 52.102. 0 / 52.102. 0 libavdevice 52. 2. 3 / 52. 2. 3 libavfilter 1. 76. 0 / 1. 76. 0 libswscale0. 12. 0 / 0. 12. 0 libpostproc 51. 2. 0 / 51. 2. 0 [nut @ 0x10765b0] no index at the end [nut @ 0x10765b0] Estimating duration from bitrate, this may be inaccurate Input #0, nut, from 'out.nut': Metadata: encoder : Lavf52.102.0 Duration: 00:13:15.00, start: 0.00, bitrate: 63 kb/s Stream #0.0: Video: mpeg4, yuv420p, 352x288, 25 tbr, 25 tbn, 25 tbc Stream #0.1: Audio: mp2, 44100 Hz, stereo, s16, 64 kb/s Stream #0.2: Video: flv, yuv420p, 35x28, 25 tbr, 25 tbn, 25 tbc File 'out.flv' already exists. Overwrite ? [y/N] y [buffer @ 0x109f410] w:352 h:288 pixfmt:yuv420p [scale @ 0x109f7f0] w:352 h:288 fmt:yuv420p - w:35 h:28 fmt:yuv420p flags:0xa004 [buffer @ 0x10a28f0] w:35 h:28 pixfmt:yuv420p Output #0, flv, to 'out.flv': Metadata: encoder : Lavf52.102.0 Stream #0.0: Video: flv, yuv420p, 35x28, q=2-31, 200 kb/s, 1k tbn, 25 tbc Stream #0.1: Audio: libmp3lame, 44100 Hz, stereo, s16, 64 kb/s Stream #0.2: Video: flv, yuv420p, 35x28, q=2-31, 200 kb/s, 1k tbn, 25 tbc Stream mapping: Stream #0.0 - #0.0 Stream #0.1 - #0.1 Stream #0.2 - #0.2 FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2040
[issue2040] strange interaction of avfilter with ffmpeg multiple output stream ad different widths
Luca Barbato lu_z...@gentoo.org added the comment: As I said nothing, I debugged it and it's pretty much unrelated. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2040
[issue2625] ffplay crashes on TS file with bogus data
Luca Barbato lu_z...@gentoo.org added the comment: The file results missing, could you please re-upload it? FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2625
[issue2608] bug in libavformat/os_support.c poll function under mingw32
Luca Barbato lu_z...@gentoo.org added the comment: You are right, I'll send a patch to the ml now, I'm using the roundup data for the attribution. -- status: new - open substatus: new - approved FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2608
[issue2612] bug in libavformat/rtspdec.c in rtsp_read_packet
Luca Barbato lu_z...@gentoo.org added the comment: Could you please provide a backtrace and/or a test feed? FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2612
[issue2606] invalid timestamp in .ts file
Luca Barbato lu_z...@gentoo.org added the comment: Beside spewing this number of warning and having some concealment on stream start it plays fine on ffplay FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2606
[issue2606] invalid timestamp in .ts file
Luca Barbato lu_z...@gentoo.org added the comment: vlc seems to have a severe problem with the audio track btw FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2606
[issue394] RTP MP2T payload_type doesn't parse pat for discovering streams
Luca Barbato lu_z...@gentoo.org added the comment: Looks like that patch does the bare minimum to fix it and I'd apply it for now. The more generic solution is to chain the full mpegts demuxer like we do for rtp_asf. Could you please attach the wireshark dump (or the text from the rtsp session)? FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue394
[issue394] RTP MP2T payload_type doesn't parse pat for discovering streams
Luca Barbato lu_z...@gentoo.org added the comment: here an example of the traditional sdp. RTSP/1.0 200 OK Cseq: 2 Server: fbxrtspd/1.2 Freebox RTSP server Public: DESCRIBE, OPTIONS, SETUP, TEARDOWN, PLAY Content-Length: 218 Content-Type: application/sdp Content-Language: fr v=0 o=leCDN 1295382234 1295382234 IN IP4 kapoueh.proxad.net s=unknown i=unknown c=IN IP4 0.0.0.0 t=0 0 m=video 0 RTP/AVP 33 a=control:rtsp://mafreebox.freebox.fr:554/fbxtv_pub/stream?namespace=1service=201flavour=ld FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue394
[issue2318] FFserver bug
Luca Barbato lu_z...@gentoo.org added the comment: Fixed -- status: open - closed substatus: open - fixed FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2318
[issue2318] FFserver bug
Luca Barbato lu_z...@gentoo.org added the comment:
That's because the whole machinery got broken by the fact the codec defaults and
the stream defaults now are different (one is 0/0 the other 0/1). I have a
stupid patch to fix that by overwriting the value.
Still we should either rethink this monster.
diff --git a/ffserver.c b/ffserver.c
index fcc3359..d16b82a 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -3782,6 +3782,8 @@ static void build_feed_streams(void)
AVStream *st;
st = feed-streams[i];
s-streams[i] = st;
+//XXX: workaround
+st-sample_aspect_ratio = st-codec-sample_aspect_ratio;
}
av_set_parameters(s, NULL);
if (av_write_header(s) 0) {
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2318
[issue2318] FFserver bug
Luca Barbato lu_z...@gentoo.org added the comment: Update topic -- topic: +ffserver FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2318
[issue2435] FFserver desync while streaming mpegts
New submission from Luca Barbato lu_z...@gentoo.org: Not sure if it is a regression but I'm having my share of issues trying to make something apparently simple: - prepare a streamcopy feed ffmpeg -i source -vbsf foo -vcodec copy -acodec copy http://host/feed.ffm - serve it as mpegts Enjoy the full video desync. -- messages: 12998 priority: normal status: new substatus: new title: FFserver desync while streaming mpegts topic: ffserver type: bug FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2435
[issue2436] ffm http output doesn't support bitstream filters
New submission from Luca Barbato lu_z...@gentoo.org: Due how it is written, if you want to do streamcopy and reformat as in ffmpeg -i source -vbfs foo -abfs bar -vcodec copy -acodec copy http://host/feed.ffm You end up with a completely corrupted feed. Glaring example: h264+aac source. In that case you additionally have also a problem with AAC extradata not being properly forwarded. The best solution could be having an explicit flag to trigger remote configuration or not. Using the normal code seems to have an issue or ffserver is even more broken than should. -- messages: 12999 priority: normal status: new substatus: new title: ffm http output doesn't support bitstream filters topic: ffmpeg, ffserver type: bug FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2436
[issue127] instructions for reporting bugs ON NEW BUG PAGE
Luca Barbato lu_z...@gentoo.org added the comment: ping FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue127
[issue46] backup
Luca Barbato lu_z...@gentoo.org added the comment: The new host is fully backed up. -- status: open - closed substatus: open - implemented FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue46
[issue849] Roundup migration
Luca Barbato lu_z...@gentoo.org added the comment: Help testing the new migration needed again, please try it FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue849
[issue849] Roundup migration
Luca Barbato lu_z...@gentoo.org added the comment: The web interface seems working correctly, now the mail interface seems not behaving FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue849
[issue2304] Test mailgw
New submission from Luca Barbato lu_z...@gentoo.org: Is the mailgw working now? -- messages: 12284 priority: normal status: new substatus: new title: Test mailgw type: bug FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2304
[issue2304] Test mailgw
Luca Barbato lu_z...@gentoo.org added the comment: Assigning to me -- assignedto: - lu_zero nosy: +lu_zero FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2304
[issue2304] Test mailgw
Luca Barbato lu_z...@gentoo.org added the comment: On 10/15/2010 08:17 PM, compn wrote: compnte...@twmi.rr.com added the comment: testtestest I can read them... is everything fine? -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2304
[issue2304] Test mailgw
Luca Barbato lu_z...@gentoo.org added the comment: On 10/15/2010 08:17 PM, compn wrote: compnte...@twmi.rr.com added the comment: testtestest I can read them... is everything fine? -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2304
[issue2304] Test mailgw
Luca Barbato lu_z...@gentoo.org added the comment: Ok the mail gw seems working as well (postfix conf updated) -- status: new - closed substatus: new - works_for_me FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2304
[issue2270] RTP parser fails on RFC 3550 header extensions
Luca Barbato lu_z...@gentoo.org added the comment: hi, the patch looks more or less ok (just a }; that should be } as Martin noted on irc), do you have test samples for it? what's the producer? FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2270
[issue2212] rtsp punch packets sent to wrong IP
Luca Barbato lu_z...@gentoo.org added the comment: On 09/03/2010 02:29 PM, Martin Storsjö wrote: In his defense, he asked about this, and I suggested this solution, since it is independent of both v4 and v6, not littering general code with references to whichever address family has the largest addresses at the moment. But if you prefer that we use INET6_ADDRSTRLEN straight away, I'm ok with that too. I have no strong opinion regarding the macro value, INET6_ADDRSTRLEN seems fine if is always defined. The rest of the patch looks ok lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2212
[issue2212] rtsp punch packets sent to wrong IP
Luca Barbato lu_z...@gentoo.org added the comment: On 09/03/2010 08:52 PM, John Wimer wrote: John Wimer j...@god.vtic.net added the comment: new version of 0001 patch, where it doesn't bother checking for INET_ADDRSTRLEN. Looks ok -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2212
[issue2039] strange interaction of avfilter with ffmpeg multiple output stream ad different widths
New submission from Luca Barbato lu_z...@gentoo.org: somehow the width and height are wrongly updated resulting in strangely looking videos ./ffmpeg -y -t 1 -i in -s 480x360 -vcodec mpeg2video -acodec mp2 out1.mpeg -s 320x240 -vcodec mpeg2video -acodec mp2 out2.mpeg ./ffmpeg -y -t 1 -i in -s 480x360 -vcodec mpeg2video -acodec mp2 out3.mpeg ./ffmpeg -y -t 1 -i in -s 320x240 -vcodec mpeg2video -acodec mp2 out4.mpeg out1.mpeg out3.mpeg -- assignedto: lu_zero messages: 10954 nosy: lu_zero, stefano_sa priority: normal status: new substatus: open title: strange interaction of avfilter with ffmpeg multiple output stream ad different widths topic: avfilter type: bug FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2039
[issue2040] strange interaction of avfilter with ffmpeg multiple output stream ad different widths
New submission from Luca Barbato lu_z...@gentoo.org: somehow the width and height are wrongly updated resulting in strangely looking videos ./ffmpeg -y -t 1 -i in -s 480x360 -vcodec mpeg2video -acodec mp2 out1.mpeg -s 320x240 -vcodec mpeg2video -acodec mp2 out2.mpeg ./ffmpeg -y -t 1 -i in -s 480x360 -vcodec mpeg2video -acodec mp2 out3.mpeg ./ffmpeg -y -t 1 -i in -s 320x240 -vcodec mpeg2video -acodec mp2 out4.mpeg out1.mpeg out3.mpeg -- assignedto: lu_zero messages: 10955 nosy: lu_zero, stefano_sa priority: normal status: new substatus: open title: strange interaction of avfilter with ffmpeg multiple output stream ad different widths topic: avfilter type: bug FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2040
[issue2040] strange interaction of avfilter with ffmpeg multiple output stream ad different widths
Luca Barbato lu_z...@gentoo.org added the comment: Reassign -- assignedto: lu_zero - stefano_sa FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2040
[issue1899] rtp doesn't demux audio/X-QDM and video/X-SV3V-ES
Luca Barbato lu_z...@gentoo.org added the comment: Worth mentioning that an rtsp url gives you as container either -standard rtsp/rtp -real rtsp dialect -other and points an abstract resource, the name can be as misleading as possible. -- title: rtsp mov could not find codec parameters - rtp doesn't demux audio/X-QDM and video/X-SV3V-ES topic: +avformat, rtsp FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1899
[issue1825] ffmpeg and google rtsp
Luca Barbato lu_z...@gentoo.org added the comment: Martin fixed it for me ^^ -- status: new - closed substatus: new - fixed FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1825
[issue1881] Strange msrtsp server
New submission from Luca Barbato lu_z...@gentoo.org: rtsp://193.126.232.33:554/PGrande/video results in an assertion triggered it looks an msrtsp server and streams some wmv3 in asf in rtp that gets mangled somehow. -- assignedto: rbultje messages: 10133 nosy: rbultje priority: normal status: open substatus: open title: Strange msrtsp server topic: avformat type: bug FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1881
[issue1789] FFmpeg issue tracking system does not show register link.
Luca Barbato lu_z...@gentoo.org added the comment: Fixed. -- assignedto: - lu_zero nosy: +lu_zero status: open - closed substatus: reproduced - fixed FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1789
[issue1653] Roundup: Do not allow non-admins to delete others messages
Luca Barbato lu_z...@gentoo.org added the comment: I added a check in the schema, it should be tested. -- assignedto: - lu_zero nosy: +lu_zero FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1653
[issue1261] [ROUNDUP] Setting timezone incorrectly leaves you unable to view details or bugs
Luca Barbato lu_z...@gentoo.org added the comment: The current classic view doesn't seem to provide that feature... could you please point me to a patch providing it? Otherwise I'll do myself but would take more since I'm not that proficient with TAL FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1261
[issue1777] Test
Luca Barbato lu_z...@gentoo.org added the comment: On 02/25/2010 02:24 PM, Luca Barbato wrote: -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue1777
[issue1777] Test
New submission from Luca Barbato lu_z...@gentoo.org: abcd -- messages: 9543 priority: normal status: closed substatus: reject title: Test type: bug FFmpeg issue tracker iss...@roundup.ffmpeg.org http://roundup.ffmpeg.org/issue1777
[issue1777] Test
Luca Barbato lu_z...@gentoo.org added the comment: test FFmpeg issue tracker iss...@roundup.ffmpeg.org http://roundup.ffmpeg.org/issue1777
[issue1777] Test
Luca Barbato lu_z...@gentoo.org added the comment: test FFmpeg issue tracker iss...@roundup.ffmpeg.org http://roundup.ffmpeg.org/issue1777 prova
[issue1777] Test
Luca Barbato lu_z...@gentoo.org added the comment: test update FFmpeg issue tracker iss...@roundup.ffmpeg.org http://roundup.ffmpeg.org/issue1777
[issue1777] Test
Luca Barbato lu_z...@gentoo.org added the comment: last test FFmpeg issue tracker iss...@roundup.ffmpeg.org http://roundup.ffmpeg.org/issue1777 prova
[issue1774] roundup emails lost?
New submission from Luca Barbato lu_z...@gentoo.org: Got a report about this, the email is to actually test the issue. -- assignedto: lu_zero messages: 9526 nosy: lu_zero priority: normal status: new substatus: new title: roundup emails lost? topic: roundup type: bug _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1774 _
[issue1774] roundup emails lost?
Luca Barbato lu_z...@gentoo.org added the comment: .. -- assignedto: lu_zero - nosy: -lu_zero _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1774 _
[issue1688] ffmpeg should allow a registered callback to accept or reject network packets
Luca Barbato lu_z...@gentoo.org added the comment: On 02/01/2010 04:04 PM, Michael Niedermayer wrote: Michael Niedermayer michae...@gmx.at added the comment: inOn Mon, Feb 01, 2010 at 01:47:17PM +, Jeremy Morton wrote: Jeremy Morton ffm...@game-point.net added the comment: ffmpeg is no firewall I don't think this is really firewall functionality. no? which other application has a callback to let the user analize low level packets to then reject them. also, there is your OS firewall, 3rd party firewalls, LD_RRELOAD over the network code, ... also your patch would require changes to every single user application to have any effect. No it wouldn't, existing apps would be unaffected, because as you say below this would be an API change. Whatsmore, it could be implemented as optional by enabling it using a build switch. It requires every user application to add a callback, and add functionality to detect bad RTP packets. this is not reasonable, rejecting incorrect packets belongs in rtp/udp/rtsp not the user application If you want an extension of libavformats API this is possible but only after someone proofed the need for such change, that is someone MUST read the RFCs about RTPRTSPSDP and then explain exactly * why the *SRC SEQ numbers are not sufficient. If i'm opening an SDP file or just directly opening an rtp:// URL (I'm opening an SDP file) in order to wait for an RTP stream to be sent to me, there is nowhere I can specify those numbers. Even if I could, there is no formal mechanism for my program to get those numbers from the sender, so I wouldn't know which one was the one to throw away and which to keep. you can specify the IP address of the sender in the rtp URL i would assume Also, lazy firmware implementers can just set the SSRC to 0 (and do, I've seen it), so multiple streams could have the SSRC 0, becoming indistinguishable. 8.2 Collision Resolution and Loop Detection Although the probability of SSRC identifier collision is low, all RTP implementations must be prepared to detect collisions and take the appropriate actions to resolve them. so there is no indistinguishable SSRC in RTP. * what exact attack scenario is possible due to this Multiple streams being sent in to a transcoding server that receives RTP streams and outputs them to eg. a Flash client using RTMP. There's only 65535 port numbers to choose from, malicious attackers can likely send valid camera data to port(s) being used for receiving streams. How does your callback detect an attacker? * how this can be fixed I've posted a sample diff in this issue which fixes this (proof-of-concept), by allowing the calling code to register a callback function which can check the source network address to make sure it's the address (ie. the address of the sender; a network camera in this case) it expected to receive the packet from. It can return zero or nonzero to reject or accept the packet. 9.2 Authentication and Message Integrity Authentication and message integrity are not defined in the current specification of RTP since these services would not be directly feasible without a key management infrastructure. It is expected that authentication and integrity services will be provided by lower layer protocols in the future. i think this should be a sufficient final awnser to your problem if you want to be 100% sure you can use srtp (and/or have rtsp do its work...) -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero _ 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 _
[issue1688] AVPacket should provide a packet's source address
Luca Barbato lu_z...@gentoo.org added the comment: Adding myself -- nosy: +lu_zero _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1688 _
[issue1697] MSRTSP doesn't work with some Akamai streams
Luca Barbato lu_z...@gentoo.org added the comment: On 01/20/2010 02:57 AM, Alan Steremberg wrote: Alan Steremberg al...@wunderground.com added the comment: This part of the patch is a mistake, it should be taken out. I am not able to test without it in my copy, but I forgot to remove it before creating the patch. there is also some 2space indentation that could be removed. In short your patch is about parsing correctly the control line in sdp (if I read correctly). So it isn't just about msrtsp I think. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1697 _
[issue1697] MSRTSP doesn't work with some Akamai streams
Luca Barbato lu_z...@gentoo.org added the comment: The style could be cleaned up I think. _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1697 _
[issue1190] Fix build failure on NetBSD in bktr driver
Luca Barbato lu_z...@gentoo.org added the comment: Please do not force us to remove your account. I mark it as wont_implement. You may feed the configure with additional -D_NETBSD_SOURCE=1 and that should make it build I think. -- status: open - closed substatus: reproduced - wont_implement _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1190 _
[issue1021] Something is wrong here
Luca Barbato lu_z...@gentoo.org added the comment: as in you can edit and delete yours I think, the issue log should report it in the history anyway, isn't it? _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1021 _
[issue127] instructions for reporting bugs ON NEW BUG PAGE
Luca Barbato lu_z...@gentoo.org added the comment: Could we come up with some better wording? I'll try to update the web ui so the guidelines will come up as discussed. FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue127
[issue1003] roundup 1.4.8 mailgw is broken
Luca Barbato lu_z...@gentoo.org added the comment: 1.6.8 seems doing the right thing, I'm tweaking a bit apache configuration to avoid using acl to have it write in the same dir postfix does. -- assignedto: - lu_zero nosy: +lu_zero title: roundup 1.4.6 wins! - roundup 1.4.8 mailgw is broken type: - bug _ FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue1003 _
[issue913] test roundup 1.4.8 mailgw
Luca Barbato lu_z...@gentoo.org added the comment: compn wrote: compn te...@twmi.rr.com added the comment: i am unable to get a password or any type of email from this mailman interface. http://lscube.org/mailman/listinfo/ffmpeg-issues Try to have your mail server more permissive, the DNS is still managed by aruba... -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue913
[issue913] test roundup 1.4.8 mailgw
New submission from Luca Barbato lu_z...@gentoo.org: ... -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- messages: 4607 priority: normal status: new substatus: new title: test roundup 1.4.8 mailgw FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue913
[issue913] test roundup 1.4.8 mailgw
Luca Barbato lu_z...@gentoo.org added the comment: Apparently everything works so far... -- assignedto: - lu_zero nosy: +lu_zero priority: normal - important status: new - closed substatus: new - works_for_me type: - bug FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue913
[issue406] Attachments are not passed to the ML anymore
Luca Barbato lu_z...@gentoo.org added the comment: Should be fixed now -- assignedto: - lu_zero nosy: +lu_zero FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/roundup/ffmpeg/issue406
