[issue2607] Creating m4a (aac) does not correctly fill the bitrate file header tag
New submission from Antonio J. de Oliveira ajolive...@ajoliveira.com: There are players not supporting the ~0 tag ffmpeg -ab 256k -i input.flac output.m4a -- messages: 13676 priority: normal status: new substatus: new title: Creating m4a (aac) does not correctly fill the bitrate file header tag type: bug FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2607
[issue2608] bug in libavformat/os_support.c poll function under mingw32
New submission from Max shakhmetov@gmail.com:
$ gdb ffmpeg_g.exe
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show
copying
and show warranty for details.
This GDB was configured as mingw32.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from c:\disk\ffmpeg-0.6.1\ffmpeg/ffmpeg_g.exe...done.
(gdb) run -v 9 -loglevel 99 -i rtsp://194.24.241.164/live.sdp?tcp -
acodec none -y video4.flv
Starting program: c:\disk\ffmpeg-0.6.1\ffmpeg/ffmpeg_g.exe -v 9 -
loglevel 99 -i rtsp://194.24.241.164/live.sdp?tcp -acod
ec none -y video4.flv
[New Thread 20848.0x26dc]
FFmpeg version git-8ed4cc6, Copyright (c) 2000-2011 the FFmpeg
developers
built on Feb 15 2011 18:27:37 with gcc 4.5.0
configuration: --enable-memalign-hack --prefix=/c/disk/ffmpeg-
0.6.1/build --enable-gpl --enable-version3 --enable-nonf
ree
libavutil50. 37. 0 / 50. 37. 0
libavcore 0. 16. 1 / 0. 16. 1
libavcodec 52.113. 1 / 52.113. 1
libavformat 52.100. 1 / 52.100. 1
libavdevice 52. 2. 3 / 52. 2. 3
libavfilter 1. 76. 0 / 1. 76. 0
libswscale0. 12. 0 / 0. 12. 0
[New Thread 20848.0x2b10]
Program received signal SIGSEGV, Segmentation fault.
0x77186395 in select () from C:\Windows\syswow64\ws2_32.dll
(gdb) bt
#0 0x77186395 in select () from C:\Windows\syswow64\ws2_32.dll
#1 0x00435231 in ff_freeaddrinfo (res=0x5b28) at
libavformat/os_support.c:150
#2 0x004be4af in tcp_open (h=0x2bc31c0, uri=0x31dc Address 0x31dc out
of bounds, flags=2) at libavformat/tcp.c:113
#3 0x0fed in ?? ()
#4 0x02bc31c0 in ?? ()
#5 0x0002 in ?? ()
#6 0x0001 in ?? ()
#7 0x in ?? ()
It's occurs cause the select return not greatest fd number, but fd
count.
man: On success, select() and pselect() return the number of file
descriptors contained in the three returned descriptor sets (that is,
the total number of bits that are set in readfds, writefds, exceptfds)
which may be zero if the timeout expires before anything interesting
happens.
in second for loop must be in that form:
for(i = 0; i (nfds_t) numfds; i++) {
...
}
All function:
int poll(struct pollfd *fds, nfds_t numfds, int timeout)
{
fd_set read_set;
fd_set write_set;
fd_set exception_set;
nfds_t i;
int n;
int rc;
#if HAVE_WINSOCK2_H
if (numfds = FD_SETSIZE) {
errno = EINVAL;
return -1;
}
#endif
FD_ZERO(read_set);
FD_ZERO(write_set);
FD_ZERO(exception_set);
n = -1;
for(i = 0; i numfds; i++) {
if (fds[i].fd 0)
continue;
#if !HAVE_WINSOCK2_H
if (fds[i].fd = FD_SETSIZE) {
errno = EINVAL;
return -1;
}
#endif
if (fds[i].events POLLIN) FD_SET(fds[i].fd, read_set);
if (fds[i].events POLLOUT) FD_SET(fds[i].fd, write_set);
if (fds[i].events POLLERR) FD_SET(fds[i].fd, exception_set);
if (fds[i].fd n)
n = fds[i].fd;
};
if (n == -1)
/* Hey!? Nothing to poll, in fact!!! */
return 0;
if (timeout 0)
rc = select(n+1, read_set, write_set, exception_set, NULL);
else {
struct timevaltv;
tv.tv_sec = timeout / 1000;
tv.tv_usec = 1000 * (timeout % 1000);
rc = select(n+1, read_set, write_set, exception_set, tv);
};
if (rc 0)
return rc;
for(i = 0; i (nfds_t) numfds; i++) {
fds[i].revents = 0;
if (FD_ISSET(fds[i].fd, read_set)) fds[i].revents |=
POLLIN;
if (FD_ISSET(fds[i].fd, write_set)) fds[i].revents |=
POLLOUT;
if (FD_ISSET(fds[i].fd, exception_set)) fds[i].revents |=
POLLERR;
};
return rc;
}
--
messages: 13677
priority: normal
status: new
substatus: new
title: bug in libavformat/os_support.c poll function under mingw32
type: bug
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2608
[issue2609] FFMPEG isn't using multiple threads automatically
New submission from Reado d.re...@readesgroupservices.com: FFmpeg version git-8ed4cc6, Copyright (c) 2000-2011 the FFmpeg developers built on Feb 15 2011 15:35:38 with gcc 4.1.2 20080704 (Red Hat 4.1.2-48) configuration: --prefix=/usr --enable-shared --enable-gpl --enable-nonfree --enable-version3 --enable-pthreads --enable-postproc --enable-libx264 --enable-libfaac libavutil50. 37. 0 / 50. 37. 0 libavcore 0. 16. 1 / 0. 16. 1 libavcodec 52.113. 1 / 52.113. 1 libavformat 52.100. 1 / 52.100. 1 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 Command: ffmpeg -i 20110211_092600.MTS -acodec libfaac -ab 128k -ac 2 -ar 44100 -vcodec libx264 -vpre slow -vf yadif=1,scale=854:480 -b 2000k -qmin 22 -qmax 27 -aspect 16:9 -threads 0 -f mp4 -y part1.mp4 Using the command above, FFMPEG doesn't use multiple threads. It used to, but recently it's stopped doing it. I have to change the threads value to something other than 0 to get it to use multiple threads. For example, changing it to 4 or 8 and 300% or more CPU is used. Whereas if it's set to 0, less than 100% CPU is used. My server has 2 CPUs (8 cores) with 4GB RAM and I'm running CentOS 5.5 x64. -- messages: 13678 priority: normal status: new substatus: new title: FFMPEG isn't using multiple threads automatically type: bug FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2609
[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
[issue2598] The mp3 decoder is highly unpredictable
Reimar Döffinger b...@reimardoeffinger.de added the comment: On Mon, Feb 14, 2011 at 01:23:32PM +, Karl Blomster wrote: I'm not qualified to argue about whether the flushing is technically wrong or not, but I'd certainly agree it's suboptimal since with other decoders it generally IS possible to implement decently working random access. Decently working should be possible, but not bit-exact to decoding from the start. You could try fixing it yourself, in libavcodec/mpegaudiodec.c there is a flush function. It memsets synth_buf to 0. Try to find the mimimum number of other things you also have to set to 0 to fix it, the possibly relevant things should be last_buf + last_buf_size synth_buf_offset sb_samples mdct_buf granules FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2598
[issue2610] Complete your registration to FFmpeg issue tracker -- keyitMCCGUtN0Ke8Ar7RtwOwHlvUzNs3J7y
New submission from David Shaw david.s...@s-and-t.com: Dave ST -- messages: 13681 priority: normal status: new substatus: new title: Complete your registration to FFmpeg issue tracker -- keyitMCCGUtN0Ke8Ar7RtwOwHlvUzNs3J7y FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2610
[issue2611] bug in libavcodec/tcp.c
New submission from Max shakhmetov@gmail.com:
1. functions tcp_read and tcp_write is performing analyze of
URLContext::flags is URL_FLAG_NONBLOCK setted or not. But
URL_FLAG_NONBLOCK is never set. Seems that in function tcp_open it must
be set.
2. function tcp_read must have cycle for read all data. Now the function
wait noly 100ms for incoming data. It's wrong. Seems that it must be
like udp_read.
3. function tcp_write must have cycle for read all data. Now the
function wait noly 100ms for incoming data. It's wrong. Seems that it
must be like udp_write.
For example:
static int tcp_read(URLContext *h, uint8_t *buf, int size)
{
TCPContext *s = h-priv_data;
struct pollfd p = {s-fd, POLLIN, 0};
int len = 0;
int ret;
if ( 0 != (h-flags URL_FLAG_NONBLOCK) ) {
for ( ; 0 size ; ) {
if ( url_interrupt_cb() )
return AVERROR(EINTR);
ret = poll(p, 1, 100);
if (ret 0) {
if ( ff_neterrno() == FF_NETERROR(EINTR)
)
continue;
return AVERROR(EIO);
}
if ( !(ret == 1 p.revents POLLIN) )
continue;
ret = recv(s-fd, buf, size, 0);
if (ret 0) {
if (ff_neterrno() != FF_NETERROR(EAGAIN)
ff_neterrno() !=
FF_NETERROR(EINTR))
return AVERROR(EIO);
} else {
size -= ret;
buf += ret;
len += ret;
}
}
} else {
len = recv(s-fd, buf, size, 0);
}
return len;
}
/**/
static int tcp_write(URLContext *h, const uint8_t *buf, int size)
{
TCPContext *s = h-priv_data;
struct pollfd p = {s-fd, POLLOUT, 0};
int len = 0;
int ret;
if ( 0 != (h-flags URL_FLAG_NONBLOCK) ) {
for ( ; 0 size ; ) {
if ( url_interrupt_cb() )
return AVERROR(EINTR);
ret = poll(p, 1, 100);
if (ret 0) {
if ( ff_neterrno() == FF_NETERROR(EINTR)
)
continue;
return AVERROR(EIO);
}
if ( !(ret == 1 p.revents POLLOUT) )
continue;
ret = send(s-fd, buf, size, 0);
if (ret 0) {
if (ff_neterrno() != FF_NETERROR(EAGAIN)
ff_neterrno() !=
FF_NETERROR(EINTR))
return AVERROR(EIO);
} else {
size -= ret;
buf += ret;
len += ret;
}
}
} else {
len = send(s-fd, buf, size, 0);
}
return len;
}
static int tcp_write(URLContext *h, const uint8_t *buf, int size)
{
TCPContext *s = h-priv_data;
struct pollfd p = {s-fd, POLLOUT, 0};
int len = 0;
int ret;
if ( 0 != (h-flags URL_FLAG_NONBLOCK) ) {
for ( ; 0 size ; ) {
if ( url_interrupt_cb() )
return AVERROR(EINTR);
ret = poll(p, 1, 100);
if (ret 0) {
if ( ff_neterrno() == FF_NETERROR(EINTR)
)
continue;
return AVERROR(EIO);
}
if ( !(ret == 1 p.revents POLLOUT) )
continue;
ret = send(s-fd, buf, size, 0);
if (ret 0) {
if (ff_neterrno() != FF_NETERROR(EAGAIN)
ff_neterrno() !=
FF_NETERROR(EINTR))
return AVERROR(EIO);
} else {
size -= ret;
buf += ret;
len += ret;
}
}
} else {
len = send(s-fd, buf, size, 0);
}
return len;
}
--
messages: 13682
priority: normal
status: new
substatus: new
title: bug in libavcodec/tcp.c
type: bug
FFmpeg issue tracker iss...@roundup.ffmpeg.org
[issue2611] bug in libavcodec/tcp.c
Max shakhmetov@gmail.com added the comment:
1. functions tcp_read and tcp_write is performing analyze of
URLContext::flags is URL_FLAG_NONBLOCK setted or not. But
URL_FLAG_NONBLOCK is never set. Seems that in function tcp_open it must
be set.
2. function tcp_read must have cycle for read all data. Now the function
wait only 100ms for incoming data. It's wrong. Seems that it must be
like udp_read.
3. function tcp_write must have cycle for read all data. Now the
function wait only 100ms for send buffer. It's wrong. Seems that it
must be like udp_write.
static int tcp_read(URLContext *h, uint8_t *buf, int size)
{
TCPContext *s = h-priv_data;
struct pollfd p = {s-fd, POLLIN, 0};
int len = 0;
int ret;
if ( 0 != (h-flags URL_FLAG_NONBLOCK) ) {
for ( ; 0 size ; ) {
if ( url_interrupt_cb() )
return AVERROR(EINTR);
ret = poll(p, 1, 100);
if (ret 0) {
if ( ff_neterrno() == FF_NETERROR(EINTR)
)
continue;
return AVERROR(EIO);
}
if ( !(ret == 1 p.revents POLLIN) )
continue;
ret = recv(s-fd, buf, size, 0);
if (ret 0) {
if (ff_neterrno() != FF_NETERROR(EAGAIN)
ff_neterrno() !=
FF_NETERROR(EINTR))
return AVERROR(EIO);
} else {
size -= ret;
buf += ret;
len += ret;
}
}
} else {
len = recv(s-fd, buf, size, 0);
}
return len;
}
static int tcp_write(URLContext *h, const uint8_t *buf, int size)
{
TCPContext *s = h-priv_data;
struct pollfd p = {s-fd, POLLOUT, 0};
int len = 0;
int ret;
if ( 0 != (h-flags URL_FLAG_NONBLOCK) ) {
for ( ; 0 size ; ) {
if ( url_interrupt_cb() )
return AVERROR(EINTR);
ret = poll(p, 1, 100);
if (ret 0) {
if ( ff_neterrno() == FF_NETERROR(EINTR)
)
continue;
return AVERROR(EIO);
}
if ( !(ret == 1 p.revents POLLOUT) )
continue;
ret = send(s-fd, buf, size, 0);
if (ret 0) {
if (ff_neterrno() != FF_NETERROR(EAGAIN)
ff_neterrno() !=
FF_NETERROR(EINTR))
return AVERROR(EIO);
} else {
size -= ret;
buf += ret;
len += ret;
}
}
} else {
len = send(s-fd, buf, size, 0);
}
return len;
}
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2611
[issue2612] bug in libavformat/rtspdec.c in rtsp_read_packet
New submission from Max shakhmetov@gmail.com: rtsp_read_packet try resetup RTSP using tcp, but lower_transport not changed for RTSP_LOWER_TRANSPORT_TCP. Then RTSP stack call ff_rtsp_fetch_packet, analyze lower_transport that equal to RTSP_LOWER_TRANSPORT_UDP, call udp_read_packet and crashes. -- messages: 13684 priority: normal status: new substatus: new title: bug in libavformat/rtspdec.c in rtsp_read_packet type: bug FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2612
[issue2611] bug in libavcodec/tcp.c
Ronald S. Bultje rsbul...@gmail.com added the comment: Please use url_open()/url_read()/url_write(), they take care of the stuff you're trying to do. -- status: new - closed substatus: new - invalid FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2611
[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
[issue2611] bug in libavcodec/tcp.c
Max shakhmetov@gmail.com added the comment: url_open()/url_read()/url_write() - is only wrappers for tcp_open, tcp_read, tcp_write you can try ffmpeg -analyzeduration 0 -v 9 -loglevel 99 -i rtsp://194.24.241.164/live.sdp?tcp -an -y video.flv and you receive inavlid data read but with my functions it's work fine FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue2611
[issue421] Support for WMA lossless
Andrew Pantyukhin infofar...@cenkes.org added the comment: My current employer would find an open-source wma-lossless decoder beneficial. We can provide funding from $1000 and more. I'm bumping priority to important, please bump back if not adequate. -- priority: wish - important FFmpeg issue tracker iss...@roundup.ffmpeg.org https://roundup.ffmpeg.org/issue421
