Ronald S. Bultje rsbul...@gmail.com added the comment:
Fixed in 0af8a71d66305874bd6f0ebc84ebf99339b6a5d3
--
nosy: -cehoyos, michaelni, xrigou
status: open - closed
substatus: reproduced - fixed
topic: -regression, swscaler
__
Libav issue
Ronald S. Bultje rsbul...@gmail.com added the comment:
Duplicate of 1108 then.
--
status: open - closed
substatus: reproduced - duplicate
superseder: +yuvj420p scaling artefact
topic: -regression, swscaler
__
Libav issue tracker iss
Ronald S. Bultje rsbul...@gmail.com added the comment:
Oops, I mean 675, mixed up the two...
--
superseder: +White artifacts on JPEGs when using libswscale -yuvj420p scaling
artefact
__
Libav issue tracker iss...@roundup.libav.org
https
Ronald S. Bultje rsbul...@gmail.com added the comment:
Please let us confirm that first.
--
status: closed - open
substatus: fixed - reproduced
__
Libav issue tracker iss...@roundup.libav.org
https://roundup.libav.org/issue2558
__
Ronald S. Bultje rsbul...@gmail.com added the comment:
This was fixed a while ago in c76374c6db5f486672f9df223f43e4892bd655c9
--
nosy: -llogan
status: new - closed
substatus: new - fixed
__
Libav issue tracker iss...@roundup.libav.org
https
Ronald S. Bultje rsbul...@gmail.com added the comment:
Fixed in c47d3835021effc04bc1fd2cef6be31e1b186491
--
nosy: -cehoyos, kostya
status: open - closed
substatus: analyzed - fixed
topic: -avcodec
__
Libav issue tracker iss
Ronald S. Bultje rsbul...@gmail.com added the comment:
Fixed in fd085bc08203979c6d0e8a6ab031c7e19b57f7a1.
--
status: new - closed
substatus: new - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2638
Ronald S. Bultje rsbul...@gmail.com added the comment:
41936608 00 00 00 00 00 00 00 00 00 00 00 00 79 69 6c 73
yils
41936624 74 00 00 00 1d a9 6e 61 6d 00 00 00 15 64 61 74t nam
dat
41936640 61 00 00 00 01 00 00 00 00 74 69 74 6c 65 00 00a
title
Ronald S. Bultje rsbul...@gmail.com added the comment:
Signedness problem. Likely this fix is a hack and we should make these
functions take fourccs as their input, that would also actually implement
the API as it was intended. I might do that in a next iteration
Ronald S. Bultje rsbul...@gmail.com added the comment:
Here's a more acceptable version that does the same thing.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2638
Ronald S. Bultje rsbul...@gmail.com added the comment:
Hi,
sorry to have to reply for Diego, but he's been having issues with his
computer. Basically it's broken. Please give hime a little slack in
fixing this. You've been on here since halfway 2008, a few days extra
doesn't matter
Ronald S. Bultje rsbul...@gmail.com added the comment:
Fixed in 4acc94e97a9551d11ead29735e23283d71f1d4c2.
--
status: new - closed
substatus: new - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2563
Ronald S. Bultje rsbul...@gmail.com added the comment:
no, the 1st stream has idnex 0, the second index 1, 100th index 99.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2563
Ronald S. Bultje rsbul...@gmail.com added the comment:
I'll have a look.
(1) as for URL_FLAG_NONBLOCK, it's sn API function, and ffmpeg.c does
not use this API, so it is never set. It not being set, the read loop
should attempt to read forever until data has been read, just like a
blocking
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
Ronald S. Bultje rsbul...@gmail.com added the comment:
Yes.
--
status: open - closed
substatus: open - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue3
Ronald S. Bultje rsbul...@gmail.com added the comment:
http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/122907
If you have no time, I can fix it up.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2587
Ronald S. Bultje rsbul...@gmail.com added the comment:
I agree with Reimar.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2587
Ronald S. Bultje rsbul...@gmail.com added the comment:
==56585== Invalid read of size 4
==56585==at 0x10036F181: vc1_decode_ac_coeff (in ./ffmpeg_g)
==56585==by 0x100373E51: vc1_decode_i_blocks_adv (in
./ffmpeg_g)==56585==by 0x300017: ???
==56585==by 0x1010EA52F: ???
==56585
Ronald S. Bultje rsbul...@gmail.com added the comment:
It fixes some, but not all. wc -l of valgrind ffmpeg goes from ~2000 to
~400, but still more warnings remain:
==61513== Invalid read of size 4
==61513==at 0x10036E8BA: vc1_decode_i_blocks_adv (in ./ffmpeg_g)
==61513
Ronald S. Bultje rsbul...@gmail.com added the comment:
Closing...
--
status: new - closed
substatus: new - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2583
Ronald S. Bultje rsbul...@gmail.com added the comment:
Fixed in 20ac9de3df9b129a4a312d626fed0e2bbb760200
--
status: open - closed
substatus: analyzed - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org
Ronald S. Bultje rsbul...@gmail.com added the comment:
I think so, yes.
--
status: open - closed
substatus: open - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue442
Ronald S. Bultje rsbul...@gmail.com added the comment:
Does make fate succeed in your windows version? It seems like a build
problem to me...
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2576
Ronald S. Bultje rsbul...@gmail.com added the comment:
Hi,
HAVE_AMD3DNOW means it can be assembled, not that the CPU supports it. Use
enable-runtime-cpudetect configure flag to use runtime cpu detection
which should fix this.
FFmpeg issue
Ronald S. Bultje rsbul...@gmail.com added the comment:
Here is a forward from ffmpeg-devel. Please adjust the patch so it has
the correct message and MAX_STREAMS (100, not 99, since they're numbered
from 0 onwards, not 1 onwards), and then it's OK.
2011/1/24 Måns Rullgård m...@mansr.com
Ronald S. Bultje rsbul...@gmail.com added the comment:
can you add a check in write_header() to error out on 100 streams?
Ronald
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2563
Ronald S. Bultje rsbul...@gmail.com added the comment:
The attached patch fixes the crash for me. The problem is that on
resolution change, the decoded NALs are free'ed in free_tables() and
then reused directly after that (after reinit) during decoding of the
actual data, this of course
Ronald S. Bultje rsbul...@gmail.com added the comment:
Applied.
Please open a new issue for the bottom screen corruption if appropriate.
--
status: open - closed
substatus: reproduced - fixed
FFmpeg issue tracker iss
Ronald S. Bultje rsbul...@gmail.com added the comment:
I see the behaviour. The stream is ... dysfunctional at best. It's
probably supported, because there's code in the decoder for handling
this, but lacking a test-case it broke.
Stream #0.0: Video: rawvideo, yuv420p, 960x544, q=2-31
Ronald S. Bultje rsbul...@gmail.com added the comment:
If 25830 does not work but 16420 works fine, and since you have a good
way of seeing if it crashes yes or no, could you figure out for us what
revision exactly broke it? I have a Mac so no valgrind and it doesn't
crash, so hard to debug
Ronald S. Bultje rsbul...@gmail.com added the comment:
The problem is in 8x8 predict functions (16x16 are fine), working on a fix
now...
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2547
Ronald S. Bultje rsbul...@gmail.com added the comment:
I was wrong, it was the 16x16, there was an overflow in one of the
functions. Attached patch fixes it. I've rearranged the calls a little so
that it hopefully doesn't get slower. I haven't benchmarked the change,
but effect should
Ronald S. Bultje rsbul...@gmail.com added the comment:
Fixed in r26381.
--
status: open - closed
substatus: reproduced - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2547
Ronald S. Bultje rsbul...@gmail.com added the comment:
Patch applied. Changing topic to reflect that the stream-continuation
still needs work.
--
title: MMSH shows full metadata, RTSP does not - RTSP/WMS stream does not
support ASF chaining
Ronald S. Bultje rsbul...@gmail.com added the comment:
My idea for MMS is indeed to try RTSP, then HTTP/MMS (and I do prefer a
fallback to mmst, just because some old servers still use that, even
though it's not used a lot). Lack of time is the main reason that we
haven't done it yet
Ronald S. Bultje rsbul...@gmail.com added the comment:
Input #0, rtsp, from 'rtsp://djxmmx.net/Rap-RnB':
Metadata:
genre : Rap
WMFSDKVersion : 11.0.6002.18049
WMFSDKNeeded: 0.0.0.
IsVBR : 0
album : Double Trouble
track
Ronald S. Bultje rsbul...@gmail.com added the comment:
does the metadata update in this radio station in WMP, btw? If so, we
should try supporting that also...
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2478
Ronald S. Bultje rsbul...@gmail.com added the comment:
At the end of each song, the server sends us this:
line='SET_PARAMETER rtsp://djxmmx.net:554/Rap-RnB RTSP/1.0'=0/0
line='Content-Type: application/x-wms-extension-cmd'
line='X-Notice: 2101 End-of-Stream Reached'
line='RTP-Info: url=rtsp
Ronald S. Bultje rsbul...@gmail.com added the comment:
Metadata from the ASF layer isn't forwarded to the RTSP layer, this should
be relatively easy to fix...
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2478
Ronald S. Bultje rsbul...@gmail.com added the comment:
Hi Vitaly,
if your developer or yourself need legal guidance, I can also put you in
touch with our lawyers who commonly assist in these cases. Let me know
if you need such help.
Thanks for your cooperation!
Ronald
Ronald S. Bultje rsbul...@gmail.com added the comment:
Could you upload the other files showing the message at the start
somewhere? Maybe one of them has non-zero bits in the wmapro packet.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https
Ronald S. Bultje rsbul...@gmail.com added the comment:
The interrupt CB is supposed to be handled in applications, why do you
need to do this inside mmst.c?
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2283
Ronald S. Bultje rsbul...@gmail.com added the comment:
Looking at the pro data in the packets, I doubt this issue can be solved
with this file:
[00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00]
[00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00][00]
[00
Ronald S. Bultje rsbul...@gmail.com added the comment:
Attached patch does the initialization of proper contexts for support of
WMAPro-in-WMAVoice. The actual decoding doesn't work yet because the
call to avcodec_decode_audio() is missing. Init fails though:
[wmapro @ 0x101855200] no length
New submission from Ronald S. Bultje rsbul...@gmail.com:
wmaprodec.c:remaining_bits_left() looks like a copy of get_bits_left(), so
we should use get_bits_left() instead of implementing our own version of
it.
--
messages: 13058
priority: normal
status: new
substatus: new
title
Ronald S. Bultje rsbul...@gmail.com added the comment:
I can't find any file containing agile on incoming, and issue1912/ does
not exist...
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue1912
New submission from Ronald S. Bultje rsbul...@gmail.com:
$ gdb ./ffplay_g
(gdb) r rtsp://stream.zune.net:554/a4241/e3/033/984/819/at/audio.wma
Starting program: /Users/ronaldbultje/Projects/ffmpeg-svn/x86-
64/ffplay_g rtsp://stream.zune.net:554/a4241/e3/033/984/819/at/audio.wma
[..]
FFplay
Ronald S. Bultje rsbul...@gmail.com added the comment:
Please don't change the status.
--
status: closed - open
substatus: invalid - reproduced
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue726
Ronald S. Bultje rsbul...@gmail.com added the comment:
The program has been opensourced and license to redistribute has been
restored, so I think the issue is resolved now.
Carl Eugen, is it OK to mark this as resolved?
FFmpeg issue tracker iss
Ronald S. Bultje rsbul...@gmail.com added the comment:
I'm against this change, since it makes it possible to circumvent GPLv2.0
section 2c or GPLv3.0 section 5d. The LGPL has similar requirements (but
more properly worded for library use, see section 7b of LGPLv2.1
Ronald S. Bultje rsbul...@gmail.com added the comment:
I just reconfirmed this with today's download, version 2.0 available
from French iTunes store.
Macintosh-9:LiveRadio.app ronaldbultje$ nm LiveRadio|grep _c
0004f0a0 t -[RFRadioController(Private) _checkInternetConnection]
0004f054 t
Ronald S. Bultje rsbul...@gmail.com added the comment:
Also please run:
yasm -f macho -e -o /tmp/x.s dsputil_yasm.asm
and then attach /tmp/x.s here. Is this latest SVN of FFmpeg or latest
SVN of YASM (or both). If FFmpeg SVN is problem, can you tell us which
revision introduced the compiler
Ronald S. Bultje rsbul...@gmail.com added the comment:
+/* RFC 3550 Section 5.3.1 RTP Header Extension handling */
+if (ext) {
+if (len 4)
+return -1;
+// retrieve header extension length (number of 32-bit words)
+ext = AV_RB16(buf + 2
Ronald S. Bultje rsbul...@gmail.com added the comment:
Fixed in r25349, thanks.
--
status: open - closed
substatus: needs_changes - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2266
Ronald S. Bultje rsbul...@gmail.com added the comment:
read() is called after close(). That is a bug inside aviobuf.c or whatever
part is calling this code, the patch itself is an imo unacceptable)
workaround. The proper fix is to not call read() after close
Ronald S. Bultje rsbul...@gmail.com added the comment:
You need to decode more data before the first image is returned. simply
call avcodec_decode_video2() again with subsequent frame data until
got_picture != 0.
FFmpeg issue tracker iss
Ronald S. Bultje rsbul...@gmail.com added the comment:
Alex told me he's currently working on mono-only and stereo will be buggy
for a while. So the suggestion is to not use the internal AAC encoder for
stereo for a while or bug (pay) Alex or one of his teammates (e.g.
saintdev, forgot his
Ronald S. Bultje rsbul...@gmail.com added the comment:
+} else if (!strcmp(parameter, source)) {
+if (*p == '=') {
(This should be fixed, this is hideous, all over that function, but
that's ok for now.)
-/* XXX: also use address if specified
Ronald S. Bultje rsbul...@gmail.com added the comment:
I think we'd like to use the IPv6 API where-ever possible, including here.
If it's unavailable, os_support should provide a fallback for the IPv4
API. If that's unavailable, it should not be compiled in the first place
because the whole
Ronald S. Bultje rsbul...@gmail.com added the comment:
+#ifndef INET6_ADDRSTRLEN
+# if defined(INET_ADDRSTRLEN)
+#define INET6_ADDRSTRLEN INET_ADDRSTRLEN
+# endif
+#endif
The inner if/endif aren't necessary (I was wrong there earlier).
Otherwise OK
Ronald S. Bultje rsbul...@gmail.com added the comment:
OK from me too.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2212
Ronald S. Bultje rsbul...@gmail.com added the comment:
Applied, thanks.
--
status: new - closed
substatus: new - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2212
Ronald S. Bultje rsbul...@gmail.com added the comment:
Use ./ffplay -autoexit to have it quit at the end of file. By default, it
stays on so you can seek back in the file.
--
status: open - closed
substatus: new - invalid
FFmpeg issue
Ronald S. Bultje rsbul...@gmail.com added the comment:
avs4you.com domain registration info:
egistrant:
Online Media Technologies Ltd.
Suite B, 29 Harley Street
London, W1G9QR
United Kingdom
Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
Domain Name: AVS4YOU.COM
Created on: 23
Ronald S. Bultje rsbul...@gmail.com added the comment:
It was decided that this was an old violation to which this doesn't apply,
so let's leave it closed+fixed.
--
status: open - closed
substatus: open - fixed
FFmpeg issue tracker iss
Ronald S. Bultje rsbul...@gmail.com added the comment:
This is not a free software product, therefore license still needs to be
reinstated. Has this been discussed before?
--
status: closed - open
substatus: fixed - open
FFmpeg issue
Ronald S. Bultje rsbul...@gmail.com added the comment:
Edimax Computer Company
3350 Scott Blvd. Bldg 15
Santa Clara, California 95054
United States
Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
Domain Name: EDIMAX.COM
Created on: 29-Nov-95
Expires on: 28-Nov-10
Last Updated
Ronald S. Bultje rsbul...@gmail.com added the comment:
av_picture_copy(pict, pict_src,
-vp-pix_fmt, vp-width, vp-height);
+vp-pix_fmt, dst_width, dst_height);
#else
sws_flags = av_get_int(sws_opts, sws_flags, NULL
Ronald S. Bultje rsbul...@gmail.com added the comment:
(Actually, in this case it probably means the bug is in Xine, not Amarok,
looking at the backtrace in the original bugreport.)
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https
Ronald S. Bultje rsbul...@gmail.com added the comment:
Can you decode the video using ffplay?
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2142
Ronald S. Bultje rsbul...@gmail.com added the comment:
FWIW, I can reproduce this. Whatever causes the bug should be fixed in
ffplay.c. Please refrain from further bitchfighting and fix the actual
bug.
FFmpeg issue tracker iss
Ronald S. Bultje rsbul...@gmail.com added the comment:
Attached patch screws up rtpdec_asf.c to play this stream. Things to
note:
- this is actually RDT, not RTP ;-)
- each data packet comes with 8 bytes of ?? before the actual ASF data
- each ASF packet is 4 bytes short (according to the ASF
Ronald S. Bultje rsbul...@gmail.com added the comment:
Once you decode the header (and add pn-wmt as mimetype to rtpdec_asf.c),
the header looks like this:
00 00 00 00 02 0c d2 14 30 26 b2 75 8e 66 cf 11
0.u.f..
0010 a6 d9 00 aa 00 62 ce 6c 98 14 00 00 00 00 00 00
Ronald S. Bultje rsbul...@gmail.com added the comment:
This is the FFmpeg bug tracker, not the MPlayer one.
--
status: new - closed
substatus: new - invalid
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org
Ronald S. Bultje rsbul...@gmail.com added the comment:
Hi Dennis,
I've brought this up with your team several times now. I've been
promised several times taht the product will be taken offline next
week. If the product will be discontinued, please take it offline. If
you intend to keep
Ronald S. Bultje rsbul...@gmail.com added the comment:
It crashes (also in the C version) in this piece of code:
__asm__ volatile(
1: \n
CMUL(%0, %%xmm0, %%xmm1)
CMUL(%1, %%xmm4, %%xmm5)
Particularly, the second mulps in CMUL. That's a multiply with variables
in s
Ronald S. Bultje rsbul...@gmail.com added the comment:
I also think wmadec.c never calls ff_imdct_init(), which is probably
related to all this?
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2082
Ronald S. Bultje rsbul...@gmail.com added the comment:
Valgrind suggests something else. First error:
==70074== Invalid write of size 4
==70074==at 0x2F285D: ff_rdft_init (in ./ffplay)
==70074== Address 0x13f6ee28 is 8 bytes after a block of size 80
alloc'd
==70074==at 0xB5042A
Ronald S. Bultje rsbul...@gmail.com added the comment:
A make clean fixed it.
--
status: new - closed
substatus: new - invalid
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2082
New submission from Ronald S. Bultje rsbul...@gmail.com:
http://itunes.apple.com/pl/app/sloochaj/id350353249?
uo%3D2%26mt%3D8%26uo%3D2 is an IPhone app (see incoming/ in a minute)
that uses FFmpeg, without attribution, mention, sources, license, etc:
bash-3.2$ nm ~/Desktop/Sloochaj\!/Payload
Ronald S. Bultje rsbul...@gmail.com added the comment:
Yes.
Please follow http://ffmpeg.org/legal.html if you need practical advice.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue1587
Ronald S. Bultje rsbul...@gmail.com added the comment:
Applied in r23414.
--
status: new - closed
substatus: new - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue1978
Ronald S. Bultje rsbul...@gmail.com added the comment:
(Xuggle isn't interesting because it's opensource. We generally don't
take legal action against them, although we might sometimes ask them to
stop doing it. So I'll change the topic to reflect that most discussion
here will likely
Ronald S. Bultje rsbul...@gmail.com added the comment:
Fix topic.
--
topic: +(L)GPL violation
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue1942
Ronald S. Bultje rsbul...@gmail.com added the comment:
rtsp://wm.microsoft.com/ms/Italy/MSDN/agile1.wmv
is an actual file with WMAPro-in-Voice. I think here it happens because the
stream is truncated and thus the last frame has some zero-bytes. I didn't really
look into it but I'm quite sure
Ronald S. Bultje rsbul...@gmail.com added the comment:
And the EULA forbids RE'ing.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue1242
Ronald S. Bultje rsbul...@gmail.com added the comment:
Can we close this? :-).
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue1758
Ronald S. Bultje rsbul...@gmail.com added the comment:
Not really, it's correct to display that given the content of the packet. This
will get fixed if we get actual WMAPro-in-Voice support, since then it'll
calculate packet size or zero-byte constraints and signal end-of-file. So let's
close
Ronald S. Bultje rsbul...@gmail.com added the comment:
That's no good.
Carl Eugen, since it obviously works for me, could you do the following for me?
- try this under valgrind
- try this using --disable-optimizations
Thanks!
FFmpeg issue
Ronald S. Bultje rsbul...@gmail.com added the comment:
Does this patch fix the problem? Looks like a typo...
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue1758
Index
Ronald S. Bultje rsbul...@gmail.com added the comment:
As you wish.
File 'streaming_CBR-7K.wma.myout.wav' not attached - you can download it from
https://roundup.ffmpeg.org/file885.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https
Ronald S. Bultje rsbul...@gmail.com added the comment:
As for the crash, I might've gotten lost in the valgrind mess from this buffer
overrun. Could you re-run valgrind on the patched version, and also provide a
new gdb output if it changed
Ronald S. Bultje rsbul...@gmail.com added the comment:
Er... *shame* How about this patch?
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue1758
Index: wmavoice.c
Ronald S. Bultje rsbul...@gmail.com added the comment:
provided that you also do one of the following, as per section 3. Assuming
their about dialog/eula/website has a link to the source, that fullfills 3b, so
3a no longer applies.
FFmpeg issue
Ronald S. Bultje rsbul...@gmail.com added the comment:
The GPL is ambiguous about that, but I would obviously prefer if the source link
was available in the About dialog and the EULA as well.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https
Ronald S. Bultje rsbul...@gmail.com added the comment:
Ooh, an American company. I've FW'ed this to SFLC.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue1902
Ronald S. Bultje rsbul...@gmail.com added the comment:
New installer released, license violation resolved, so the issue can be closed
now.
--
status: open - closed
substatus: reproduced - fixed
FFmpeg issue tracker iss
Ronald S. Bultje rsbul...@gmail.com added the comment:
Josh will hopefully implement these two as part of GSoC.
Antique patches (by me) available at:
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-July/073511.html
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-August/073826.html
Ronald S. Bultje rsbul...@gmail.com added the comment:
This software no longer uses FFmpeg, it uses Lame only now. Can we close this or
somehow take it off the list in the issue tracker (I don't care much about the
hall of shame itself, but this is noise in the issue tracker list
1 - 100 of 214 matches
Mail list logo
