Martin Storsjö mar...@martin.st added the comment:
This should hopefully work in the latest version in git, as long as
everything is served over normal http, not https. If it doesn't, please
reopen the issue.
--
nosy: +mstorsjo
status: new - closed
substatus: new - implemented
Martin Storsjö mar...@martin.st added the comment:
This has been implemented in git://git.libav.org/libav now.
--
status: new - closed
substatus: new - implemented
__
Libav issue tracker iss...@roundup.libav.org
https://roundup.libav.org
Martin Storsjö mar...@martin.st added the comment:
Fixed in git.ffmpeg.org/ffmpeg.git now
--
status: new - closed
substatus: new - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2614
Martin Storsjö mar...@martin.st added the comment:
Yes, but in this case, the resetup failed, since the server didn't agree to do
the
resetup for TCP.
Does it still crash? It doesn't in my tests at least. That's the important
issue.
To actually make the UDP-TCP fallback work perfectly (so
Martin Storsjö mar...@martin.st added the comment:
The issue as I can see, is that resetup_tcp() undoes the UDP setup, and then
fails to set
up TCP, leaving some data structures wiped after the ff_rtsp_undo_setup. This
call to
av_read_frame() returns with a failure code, as it should
Martin Storsjö mar...@martin.st added the comment:
Thanks, I'm able to reproduce the issue with the url given in the
backtrace!
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2612
Martin Storsjö mar...@martin.st added the comment:
This patch fixes the issue for me at least, the patch is also sent to the
mailing list.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2612
Martin Storsjö mar...@martin.st added the comment:
Also, I'm not sure what version of tcp.c you have, that one does seem
incorrect to me. The latest one in both git://git.ffmpeg.org/ffmpeg.git
and git://git.videolan.org/ffmpeg.git looks right to me, while what you
quited clearly is wrong
Martin Storsjö mar...@martin.st added the comment:
Where did you get that version of tcp.c? Did you write it yourself? Then why
do you ask about it here? The latest version in git.ffmpeg.org looks like
this: http://git.ffmpeg.org/?
p=ffmpeg.git;a=blob;f=libavformat/tcp.c;h
Martin Storsjö mar...@martin.st added the comment:
I misunderstood what you meant - apparently you meant that the version you
provided should be the new, correct one. But it isn't. The current tcp_read()
only waits for 100 ms, but if nothing was returned in that time, url_read
Martin Storsjö mar...@martin.st added the comment:
Fixed in git.ffmpeg.org/ffmpeg.git.
--
status: new - closed
substatus: new - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2612
New submission from Martin Storsjö mar...@martin.st:
Currently, libavformat doesn't seem to support seeking in .amr files.
This can be reproduced e.g. with http://samples.mplayerhq.hu/A-
codecs/amr/sample.amr.
ffmpeg -i sample.amr -ss 2 out.wav
works as intended, since the seeking is done
Martin Storsjö mar...@martin.st added the comment:
Quite close, but not exactly. The code tried to open
/apple/nrj/nrjlive-1/nrjurbanhi/Seg_012111_024157_518/nrjurbanhi_012111_024157_103658.ts
as
a local file name instead of keeping the server name but stripping the rest of
the URL.
The
Martin Storsjö mar...@martin.st added the comment:
Applied in git://git.ffmpeg.org/ffmpeg.git now.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2583
Martin Storsjö mar...@martin.st added the comment:
One potential solution to this is available since SVN rev 26246.
For RTP/UDP urls, specify ?connect=1, in order to call connect() on the UDP
socket, which makes the OS filter out packets from other sources. For RTSP
urls, specify ?filter_src
New submission from Martin Storsjö mar...@martin.st:
To reproduce, run this command line:
ffmpeg -fdebug ts -loglevel debug -dump -y -i
rtsp://albin.abo.fi:8554/sample_100kbit.mp4?
tcp -acodec copy -vcodec copy out.mp4
This errors out with this message almost immediately:
[mp4 @ 0x10180f600]
Martin Storsjö mar...@martin.st added the comment:
If the non monotone check originally is meant to skip the check for all
packets with a timestamp identical to the first timestap of the stream,
the attached patch would solve this particular issue, although I'm not
sure if that is a correct
New submission from Martin Storsjö mar...@martin.st:
As mentioned in issue 2452, the timestamp adjustment can affect the outcome of
remuxing.
This command line works properly initially:
./ffmpeg -fdebug ts -loglevel debug -dump -y -i
rtsp://albin.abo.fi:8554/sample_h264_100kbit.mp4?
tcp
Martin Storsjö mar...@martin.st added the comment:
Fixed in SVN rev 26107.
--
status: new - closed
substatus: new - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2448
Martin Storsjö mar...@martin.st added the comment:
I ran into the same issue recently. It turned out to be that the machine lacked
yasm but used nasm instead. (After upgrading the latest yasm, I forgot to rerun
configure, since I thought I actually had it installed already, and it took me
Martin Storsjö mar...@martin.st added the comment:
Here's the output of nasm -f macho -e -o /tmp/x.s
libavcodec/x86/dsputil_yasm.asm -Ilibavcodec/x86/
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2306
Martin Storsjö mar...@martin.st added the comment:
The patch looks correct to me. Michael, ok to apply?
--
nosy: +michaelni, mstorsjo
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2302
Martin Storsjö mar...@martin.st added the comment:
Applied in libswscale rev 32562.
--
status: open - closed
substatus: approved - applied
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2302
Martin Storsjö mar...@martin.st added the comment:
FWIW, a demuxer that handles receiving raw rtp:// URLs without having a
local SDP description was committed in SVN rev 25527.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https
Martin Storsjö mar...@martin.st added the comment:
FWIW, a demuxer that handles receiving raw rtp:// URLs without having a
local SDP description was committed in SVN rev 25527.
--
substatus: wont_implement - implemented
FFmpeg issue
Martin Storsjö mar...@martin.st added the comment:
Hi,
Thanks for locating the bug, I'll have a look at it shortly.
As for this issue, there is no duplication between rtpproto and rtpdec, both
of them are used in the full setup, at different levels.
rtpproto is the main handler of rtp
Martin Storsjö mar...@martin.st added the comment:
Thanks for finding this bug, I applied the patch (with some
modifications), fixed in rev 25402.
This kinds of bugs easily appear since none of the maintainers have access
to mpegts/RTP data to test with. It would be very helpful if you'd
Martin Storsjö mar...@martin.st added the comment:
Added myself to the nosy list
--
nosy: +mstorsjo
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2280
Martin Storsjö mar...@martin.st added the comment:
Thanks, this is very valuable for maintaining support for this format!
How do you play the capture back in VLC? For testing this with ffplay, I
extracted the packets via wireshark into a rtpdump file format, which I play
back with rtpplay
Martin Storsjö mar...@martin.st added the comment:
It may work for some RTP urls, but not for all. It would not, for example, work
in a case where the
SDP actually would contain parameters necessary for receiving the streams.
Given the way demuxers and protocol handlers are handled
Martin Storsjö mar...@martin.st added the comment:
I looked at the packet dump, and the patch looks quite ok to me. I touched
it up a little, here's another version of it. I'll apply it in a few days
if nobody objects.
--
nosy: +mstorsjo
Martin Storsjö mar...@martin.st added the comment:
Applied in SVN rev 25372.
--
status: open - closed
substatus: needs_changes - implemented
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2270
Martin Storsjö mar...@martin.st added the comment:
Fixed in SVN rev 25154.
--
status: open - closed
substatus: needs_more_info - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2237
Martin Storsjö mar...@martin.st added the comment:
Looks good to me. Luca, Ronald, ok with applying it?
--
nosy: +lu_zero, mstorsjo, rbultje
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2212
Martin Storsjö mar...@martin.st added the comment:
-/* XXX: also use address if specified */
-ff_url_join(url, sizeof(url), rtp, NULL, host,
-reply-transports[0].server_port_min, NULL);
+/* Use source address if specified
Martin Storsjö mar...@martin.st added the comment:
Fixed in SVN rev 25036.
--
status: new - closed
substatus: new - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2159
Martin Storsjö mar...@martin.st added the comment:
Please post the patch (made with svn diff or diff -u), or even the fixed
version of the file, so that we can review it.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org
Martin Storsjö mar...@martin.st added the comment:
Fixed this crash in rev 24059, the stream as such isn't yet supported
though.
--
status: open - closed
substatus: reproduced - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https
New submission from Martin Storsjö mar...@martin.st:
Since rev 23750, compilation is broken if only fixed-point mpegaudio decoders
are enabled, when
compiling with MMX.
The relevant parts of rev 23750:
Modified: trunk/libavcodec/mpegaudiodec.c
Martin Storsjö mar...@martin.st added the comment:
Ok, sorry for nagging about it - just wanted to make sure the issue wasn't
forgotten. :-)
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2054
Martin Storsjö mar...@martin.st added the comment:
Fixed in rev 23949.
--
status: new - closed
substatus: new - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2054
Martin Storsjö mar...@martin.st added the comment:
Applied the latest patch, fixing this issue.
I don't totally understand the reason for dropping these 1-byte packets at
end of stream either, but I'm leaving that part to someone that
understands the original reason for this code
Martin Storsjö mar...@martin.st added the comment:
David Conrad was ok with the patch, but suggested me to use op.e_o_s instead
of context-eof. Still waiting for an explicit ok on this version.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
Martin Storsjö mar...@martin.st added the comment:
What a coincidence - I was just about to report the exactly same issue.
The problem lies at these lines in libvorbis.c:
/* i'd love to say the following line is a hack, but sadly it's
* not, apparently the end of
Martin Storsjö mar...@martin.st added the comment:
Fixed in svn rev 23181.
--
status: open - closed
substatus: open - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue1948
Martin Storsjö mar...@martin.st added the comment:
Faac doesn't support encoding in 8 kHz mode, which it says clearly in the
output:
[libfaac @ 0x643750]libfaac doesn't support this output format!
And what does this have to do with libopencore_amrnb
Martin Storsjö mar...@martin.st added the comment:
The sample is available at
http://samples.mplayerhq.hu/A-codecs/amr/amrnb-dtx-nodata/ now.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue1888
New submission from Martin Storsjö mar...@martin.st:
The lavc native AMR-NB decoder doesn't support AMR-NB DTX/SID frames (frame
type 8)
and no data frames (15).
A sample has been uploaded to upload.ffmpeg.org under
/MPlayer/incoming/amrnb-dtx-
nodata, and is also available at
http
Martin Storsjö mar...@martin.st added the comment:
Good that the issue in XBMC is fixed.
There's no issue with rtsp.c, you've misunderstood the problem. The problem is
not
using url_fdopen, the problem is that calls to url_open_protocol must be
matched
with url_close. In rtsp.c, we first
Martin Storsjö mar...@martin.st added the comment:
Hmm, ok, I see. That's certainly a problem.
Basically, if you open an URLContext without calling url_open (or
url_open_protocol),
you're sidestepping the reference counted network initialization that's done in
url_open_protocol and url_close
Martin Storsjö mar...@martin.st added the comment:
On Mon, 12 Apr 2010, Ronald S. Bultje wrote:
So what's the problem with using url_open_protocol() with a custom-made
protocol
(xmbc://, if you want)? That'll fix all of this, right?
That should work, yes, and is a very proper solution IMO
Martin Storsjö mar...@martin.st added the comment:
Yes, that particular sample seems to work just fine with this patch,
thanks!
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue1785
Martin Storsjö mar...@martin.st added the comment:
Does this patch fix the issue for you?
--
nosy: +mstorsjo
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue1790
Martin Storsjö mar...@martin.st added the comment:
Applied in rev 22209
--
status: new - closed
substatus: new - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue1790
New submission from Martin Storsjö mar...@martin.st:
The AAC decoder can't decode concatenated packets, which libfaad handles just
fine.
aac_decode_frame simply returns the total number of input bytes, instead of the
number of bytes actually used.
One case where this can be noticed
Martin Storsjö mar...@martin.st added the comment:
Yes, the rtp packets contain enough information for splitting the AAC frames
properly, but that requires quite a bit of restructuring. (We had the same
discussion
recently regarding the AMR depacketizer, where I initially suggested splitting
Martin Storsjö mar...@martin.st added the comment:
Good catch. Uploaded a copy of a wav file of this content at
http://albin.abo.fi/~mstorsjo/sample.wav, to avoid any potential AMR
decoder differences.
So, the same bug is reproducable with this command line:
./ffmpeg -i http://albin.abo.fi
New submission from Martin Storsjö mar...@martin.st:
When transcoding into AAC using AMR packets as input, the encoder seems
to hang
very soon after starting.
Steps to reproduce:
ffmpeg -i http://samples.mplayerhq.hu/A-codecs/amr/sample.amr out.mp4
If running the code in gdb and breaking
58 matches
Mail list logo
