[issue2685] Input file names with colons aren't seen by ffmpeg
Luca Barbato 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 <https://roundup.libav.org/issue2685> __
[issue2671] test roundup ui
New submission from Luca Barbato : I hate it -- messages: 13900 priority: normal status: open substatus: new title: test roundup ui topic: regression, roundup type: bug __ Libav issue tracker <https://roundup.libav.org/issue2671> __
[issue2246] 'too many video packets in the buffer' with mp4 (mplayer lavf demuxer)
Luca Barbato 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 <https://roundup.libav.org/issue2246> ___
[issue2040] strange interaction of avfilter with ffmpeg multiple output stream ad different widths
Luca Barbato added the comment: As I said nothing, I debugged it and it's pretty much unrelated. FFmpeg issue tracker <https://roundup.ffmpeg.org/issue2040>
[issue2040] strange interaction of avfilter with ffmpeg multiple output stream ad different widths
Luca Barbato 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 <https://roundup.ffmpeg.org/issue2040>
[issue2625] ffplay crashes on TS file with bogus data
Luca Barbato added the comment: The file results missing, could you please re-upload it? FFmpeg issue tracker <https://roundup.ffmpeg.org/issue2625>
[issue2612] bug in libavformat/rtspdec.c in rtsp_read_packet
Luca Barbato added the comment: Could you please provide a backtrace and/or a test feed? FFmpeg issue tracker <https://roundup.ffmpeg.org/issue2612>
[issue2608] bug in libavformat/os_support.c poll function under mingw32
Luca Barbato 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 <https://roundup.ffmpeg.org/issue2608>
[issue2606] invalid timestamp in .ts file
Luca Barbato added the comment: vlc seems to have a severe problem with the audio track btw FFmpeg issue tracker <https://roundup.ffmpeg.org/issue2606>
[issue2606] invalid timestamp in .ts file
Luca Barbato added the comment: Beside spewing this number of warning and having some concealment on stream start it plays fine on ffplay FFmpeg issue tracker <https://roundup.ffmpeg.org/issue2606>
[issue2318] FFserver bug
Luca Barbato added the comment: Fixed -- status: open -> closed substatus: open -> fixed FFmpeg issue tracker <https://roundup.ffmpeg.org/issue2318>
[issue394] RTP MP2T payload_type doesn't parse pat for discovering streams
Luca Barbato 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=1&service=201&flavour=ld FFmpeg issue tracker <https://roundup.ffmpeg.org/issue394>
[issue394] RTP MP2T payload_type doesn't parse pat for discovering streams
Luca Barbato 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 <https://roundup.ffmpeg.org/issue394>
[issue2436] ffm http output doesn't support bitstream filters
New submission from Luca Barbato : 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 <https://roundup.ffmpeg.org/issue2436>
[issue2435] FFserver desync while streaming mpegts
New submission from Luca Barbato : 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 <https://roundup.ffmpeg.org/issue2435>
[issue2318] FFserver bug
Luca Barbato added the comment: Update topic -- topic: +ffserver FFmpeg issue tracker <https://roundup.ffmpeg.org/issue2318>
[issue2318] FFserver bug
Luca Barbato 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
<https://roundup.ffmpeg.org/issue2318>
[issue2025] Make things assignable to me
Luca Barbato added the comment: grrr... I did long ago I think and I'll try to get startssl to give us a certificate soon... aconverse account updated meanwhile. FFmpeg issue tracker <https://roundup.ffmpeg.org/issue2025>
[issue127] instructions for reporting bugs ON NEW BUG PAGE
Luca Barbato added the comment: ping FFmpeg issue tracker <https://roundup.ffmpeg.org/issue127>
[issue2304] Test mailgw
Luca Barbato added the comment: On 10/15/2010 08:17 PM, compn wrote: > > compn added the comment: > > testtestest I can read them... is everything fine? -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero FFmpeg issue tracker <https://roundup.ffmpeg.org/issue2304>
[issue2304] Test mailgw
Luca Barbato added the comment: On 10/15/2010 08:17 PM, compn wrote: > > compn added the comment: > > testtestest I can read them... is everything fine? -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero FFmpeg issue tracker <https://roundup.ffmpeg.org/issue2304>
[issue2304] Test mailgw
Luca Barbato 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 <https://roundup.ffmpeg.org/issue2304>
[issue849] Roundup migration
Luca Barbato added the comment: The web interface seems working correctly, now the mail interface seems not behaving FFmpeg issue tracker <https://roundup.ffmpeg.org/issue849>
[issue2304] Test mailgw
New submission from Luca Barbato : Is the mailgw working now? -- messages: 12284 priority: normal status: new substatus: new title: Test mailgw type: bug FFmpeg issue tracker <https://roundup.ffmpeg.org/issue2304>
[issue2304] Test mailgw
Luca Barbato added the comment: Assigning to me -- assignedto: -> lu_zero nosy: +lu_zero FFmpeg issue tracker <https://roundup.ffmpeg.org/issue2304>
[issue849] Roundup migration
Luca Barbato added the comment: Help testing the new migration needed again, please try it FFmpeg issue tracker <https://roundup.ffmpeg.org/issue849>
[issue46] backup
Luca Barbato added the comment: The new host is fully backed up. -- status: open -> closed substatus: open -> implemented FFmpeg issue tracker <https://roundup.ffmpeg.org/issue46>
[issue2270] RTP parser fails on RFC 3550 header extensions
Luca Barbato 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 <https://roundup.ffmpeg.org/issue2270>
[issue2212] rtsp punch packets sent to wrong IP
Luca Barbato added the comment: On 09/03/2010 08:52 PM, John Wimer wrote: > > John Wimer 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 <https://roundup.ffmpeg.org/issue2212>
[issue2212] rtsp punch packets sent to wrong IP
Luca Barbato 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 <https://roundup.ffmpeg.org/issue2212>
[issue2040] strange interaction of avfilter with ffmpeg multiple output stream ad different widths
Luca Barbato added the comment: Reassign -- assignedto: lu_zero -> stefano_sa FFmpeg issue tracker <https://roundup.ffmpeg.org/issue2040>
[issue2040] strange interaction of avfilter with ffmpeg multiple output stream ad different widths
New submission from Luca Barbato : 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 <https://roundup.ffmpeg.org/issue2040>
[issue2039] strange interaction of avfilter with ffmpeg multiple output stream ad different widths
New submission from Luca Barbato : 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 <https://roundup.ffmpeg.org/issue2039>
[issue1899] rtp doesn't demux audio/X-QDM and video/X-SV3V-ES
Luca Barbato 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 <https://roundup.ffmpeg.org/issue1899>
[issue1881] Strange msrtsp server
New submission from Luca Barbato : 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 <https://roundup.ffmpeg.org/issue1881>
[issue1825] ffmpeg and google rtsp
Luca Barbato added the comment: Martin fixed it for me ^^ -- status: new -> closed substatus: new -> fixed FFmpeg issue tracker <https://roundup.ffmpeg.org/issue1825>
[issue1826] rtsp should always check for cseq
New submission from Luca Barbato : At least the 302 response isn't fully checked for validity. [yet another pro-memoria] -- assignedto: lu_zero messages: 9885 nosy: lu_zero priority: normal status: new substatus: new title: rtsp should always check for cseq FFmpeg issue tracker <https://roundup.ffmpeg.org/issue1826>
[issue1825] ffmpeg and google rtsp
New submission from Luca Barbato : ffmpeg doesn't seem to handle correctly google rtsp server. Check http://gdatatips.blogspot.com/2008/10/getting-rtsp-streams-from-youtube-api.html to get some valid uris, I used that to check and fix 302 support in ffmpeg. [this issue is a pro-memoria for me mostly] -- assignedto: lu_zero messages: 9884 nosy: lu_zero priority: normal status: new substatus: new title: ffmpeg and google rtsp type: bug FFmpeg issue tracker <https://roundup.ffmpeg.org/issue1825>
[issue1261] [ROUNDUP] Setting timezone incorrectly leaves you unable to view details or bugs
Luca Barbato 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 <https://roundup.ffmpeg.org/issue1261>
[issue1653] Roundup: Do not allow non-admins to delete others messages
Luca Barbato added the comment: I added a check in the schema, it should be tested. -- assignedto: -> lu_zero nosy: +lu_zero FFmpeg issue tracker <https://roundup.ffmpeg.org/issue1653>
[issue1789] FFmpeg issue tracking system does not show register link.
Luca Barbato added the comment: Fixed. -- assignedto: -> lu_zero nosy: +lu_zero status: open -> closed substatus: reproduced -> fixed FFmpeg issue tracker <https://roundup.ffmpeg.org/issue1789>
[issue1777] Test
Luca Barbato 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 <https://roundup.ffmpeg.org/issue1777>
[issue1777] Test
Luca Barbato added the comment: last test FFmpeg issue tracker <http://roundup.ffmpeg.org/issue1777> prova
[issue1777] Test
Luca Barbato added the comment: test update FFmpeg issue tracker <http://roundup.ffmpeg.org/issue1777>
[issue1777] Test
Luca Barbato added the comment: test FFmpeg issue tracker <http://roundup.ffmpeg.org/issue1777> prova
[issue1777] Test
Luca Barbato added the comment: test FFmpeg issue tracker <http://roundup.ffmpeg.org/issue1777>
[issue1777] Test
New submission from Luca Barbato : abcd -- messages: 9543 priority: normal status: closed substatus: reject title: Test type: bug FFmpeg issue tracker <http://roundup.ffmpeg.org/issue1777>
[issue1774] roundup emails lost?
Luca Barbato added the comment: Seems working to a point _ FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue1774> _
[issue1774] roundup emails lost?
Luca Barbato added the comment: .. -- assignedto: lu_zero -> nosy: -lu_zero _ FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue1774> _
[issue1774] roundup emails lost?
New submission from Luca Barbato : 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 <https://roundup.ffmpeg.org/roundup/ffmpeg/issue1774> _
[issue1688] ffmpeg should allow a registered callback to accept or reject network packets
Luca Barbato added the comment: On 02/01/2010 04:04 PM, Michael Niedermayer wrote: > > Michael Niedermayer added the comment: > > inOn Mon, Feb 01, 2010 at 01:47:17PM +, Jeremy Morton wrote: >> >> Jeremy Morton 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 RTP&RTSP&SDP 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 <https://roundup.ffmpeg.org/roundup/ffmpeg/issue1688> _
[issue1713] rtsp.c demuxer fails to check filehandle being invalid
Luca Barbato added the comment: On 01/26/2010 04:41 PM, Luca Abeni wrote: > > Luca Abeni added the comment: > > Patch is ok, IMHO Patch looks ok, but I wonder how that crash happens. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero _ FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue1713> _
[issue1688] AVPacket should provide a packet's source address
Luca Barbato added the comment: On 01/24/2010 02:21 PM, Jeremy Morton wrote: > > Jeremy Morton 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 <https://roundup.ffmpeg.org/roundup/ffmpeg/issue1688> _
[issue1688] AVPacket should provide a packet's source address
Luca Barbato added the comment: Adding myself -- nosy: +lu_zero _ FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue1688> _
[issue1697] MSRTSP doesn't work with some Akamai streams
Luca Barbato added the comment: On 01/20/2010 02:57 AM, Alan Steremberg wrote: > > Alan Steremberg 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 <https://roundup.ffmpeg.org/roundup/ffmpeg/issue1697> _
[issue1697] MSRTSP doesn't work with some Akamai streams
Luca Barbato added the comment: The style could be cleaned up I think. _ FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue1697> _
[issue1190] Fix build failure on NetBSD in bktr driver
Luca Barbato 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 <https://roundup.ffmpeg.org/roundup/ffmpeg/issue1190> _
[issue1021] Something is wrong here
Luca Barbato 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 <https://roundup.ffmpeg.org/roundup/ffmpeg/issue1021> _
Re: [issue1003] roundup 1.4.8 mailgw is broken
Luca Barbato wrote: Luca Barbato 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. Trying every msg features (including removal), 1.4.6 seems working fine so far, 1.4.8 seems to be still broken. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
[issue1003] roundup 1.4.8 mailgw is broken
Luca Barbato 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 <https://roundup.ffmpeg.org/roundup/ffmpeg/issue1003> _
[issue1003] roundup 1.4.6 wins!
New submission from Luca Barbato : 1.4.8 is broken. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- messages: 5079 priority: normal status: new substatus: new title: roundup 1.4.6 wins! _ FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue1003> _
[issue127] instructions for reporting bugs ON NEW BUG PAGE
Luca Barbato 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 <https://roundup.ffmpeg.org/roundup/ffmpeg/issue127>
[issue406] Attachments are not passed to the ML anymore
Luca Barbato added the comment: It should work, please reopen if isn't -- status: open -> closed substatus: open -> fixed FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue406>
[issue913] test roundup 1.4.8 mailgw
Luca Barbato added the comment: compn wrote: > compn 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 <https://roundup.ffmpeg.org/roundup/ffmpeg/issue913>
[issue913] test roundup 1.4.8 mailgw
Luca Barbato 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 <https://roundup.ffmpeg.org/roundup/ffmpeg/issue913>
[issue913] test roundup 1.4.8 mailgw
Luca Barbato added the comment: Luca Barbato wrote: > New submission from Luca Barbato : Reply + utf8 is working? 用 -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue913>
[issue913] test roundup 1.4.8 mailgw
New submission from Luca Barbato : ... -- 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 <https://roundup.ffmpeg.org/roundup/ffmpeg/issue913>
[issue882] ffplay + rtsp source seek failure
New submission from Luca Barbato : While I'm trying to discover what's wrong in live555 and seeking, I checked also ffplay and got a strange result: - seek by percentage works as should - seek by offset is broken, the current pts isn't updated as should so the seek always tries to seek by 10s or -10s basic way to reproduce : - setup a rtsp server (e.g. feng) - ffplay rtsp://path/to/resource - check the play requests when seeking by percentage and seeking by offset (use mouse seeking or seeking by keyboard) - notice how seek by percentage leads to correct requests - notice how seek by offset always seek to second 10 or seek to second -10 -- assignedto: lu_zero messages: 4441 nosy: lu_zero priority: normal status: new substatus: new title: ffplay + rtsp source seek failure topic: avformat, ffplay type: bug FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue882>
[issue849] Roundup migration
Luca Barbato added the comment: compn wrote: > compn added the comment: > > the list info page gives an incorrect mail address. > now i can send/recieve mails! > > how to get mails for every bug tho? there is a mailing list you could subscribe on lscube.org/mailman/listinfo =) lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue849>
[issue406] Attachments are not passed to the ML anymore
Luca Barbato added the comment: Should be fixed now -- assignedto: -> lu_zero nosy: +lu_zero FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue406>
[issue849] Roundup migration
Luca Barbato added the comment: Francesco Cosoleto wrote: > Francesco Cosoleto added the comment: > > Email notification isn't working anymore? I haven't got an email when issue > 806 > was closed and my "Your issues" list is empty. They are working for me. I just received your update through email. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue849>
[issue849] Roundup migration
Luca Barbato added the comment: Michael Niedermayer wrote: > Michael Niedermayer added the comment: > > On Thu, Feb 19, 2009 at 07:37:41PM +, Vitor wrote: >> Vitor added the comment: >> >> I'm not subscribed to the mailing list, but no message has arrived at the >> gmane >> archive since the migration and >> http://live.polito.it/pipermail/ffmpeg-issues/ >> is offline. Is the ML supposed to be working? > > The ML is there, though iam not sure if its free of problems yet > ML: http://lscube.org/mailman/listinfo/ffmpeg-issues I guess we have to notify lars about the change, looks like I missed it. > issues there where, where that replies didnt work (we ll see if that one > does) and that the content filter ate 4 bugreports, i think ive fixed the > filter and hope luca did fix the reply issue the reply issue got fixed and I asked upstream to take a look on the root problem so nobody won't have to hack with capabilities and/or hand write transports specific... > Also its great to see file attachments work again, i hope it stays that > way. Luckily that got solved by upstream and will remain this way. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue849>
[issue854] Roundup should try to write files using the same group
Luca Barbato added the comment: Hacking a bit postfix made it work... -- status: new -> closed substatus: new -> fixed FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue854>
[issue854] Roundup should try to write files using the same group
Luca Barbato added the comment: Luca Barbato wrote: > New submission from Luca Barbato : > > One of the annoying issues about roundup is that there isn't a configuration > option to make every agent use the same user/group for the file. > > (Using this to test some local workarounds, once upstream fixes their > mailserver > I'll try to get the issue there as well) Meanwhile I managed to have at least apache save as apache:roundup, so the issue is half solved. FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue854>
[issue854] Roundup should try to write files using the same group
Luca Barbato added the comment: ... -- assignedto: -> lu_zero nosy: +lu_zero FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue854>
[issue854] Roundup should try to write files using the same group
New submission from Luca Barbato : One of the annoying issues about roundup is that there isn't a configuration option to make every agent use the same user/group for the file. (Using this to test some local workarounds, once upstream fixes their mailserver I'll try to get the issue there as well) -- messages: 4272 priority: normal status: new substatus: new title: Roundup should try to write files using the same group topic: roundup type: bug FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue854>
[issue91] dont pass large attachments to the ML
Luca Barbato added the comment: Now roundup will just provide a link to the website if the file is too big to be attached. -- status: open -> closed substatus: open -> implemented ___ FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue91> ___
[issue91] dont pass large attachments to the ML
Luca Barbato added the comment: The new version of roundup apparently solves the issue by itself. ___ FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue91> ___
[issue849] Roundup migration
New submission from Luca Barbato : trying migration success. -- assignedto: lu_zero messages: 4257 nosy: lu_zero priority: normal status: new substatus: new title: Roundup migration topic: roundup type: feature_request FFmpeg issue tracker <https://roundup.ffmpeg.org/roundup/ffmpeg/issue849>
