run time feature detection on ARM? Or was it reasoned
that run time feature detection isn't as useful for a primarily embedded
platform (where software will be more static)?
Thanks,
--
-Mike Melanson
___
libav-devel mailing list
libav-devel
On 10/22/2012 11:31 PM, Reinhard Tartler wrote:
grammar fixes
[...]
-The following bug in our Bugzilla has been fixed:
+The following bug in our Bugzilla have been fixed:
Disagree.
--
-Mike Melanson
___
libav-devel mailing list
libav-devel
will care about your proper documents and information).
Thanks,
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 3/30/2012 9:02 PM, Mashiat Sarker Shakkhar wrote:
On 3/31/2012 3:07 AM, Mike Melanson wrote:
[...]
I'm reading for a Bachelor's Degree in Computer Science. I'm interested
in taking part in this year's Google Summer of Code and your project has
especially caught my attention (specifically
On 3/19/2012 11:05 PM, Mike Melanson wrote:
On 3/19/2012 3:23 PM, Derek Buitenhuis wrote:
Reference generated by the Win32 VFW decoder.
The related sample is here:
http://japland.org/i/sample-zeco.avi
Staged as a sample:
http://samples.libav.org/V-codecs/ZECO/
But it's 4.5 MB large. I
, then the first 2.
Both had problems.
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Of course. No index - no keyframe indication - all frames are decoded as
interframes. Try remuxing file instead (we have nice -vframes option).
You mean this codec's frames don't have a bit to indicate frame type? The
information has to go into the index? Unusual.
--
-Mike Melanson
).
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Just updated and rebuilt on PPC:
TESTacodec-wmav1
reference file '/home/melanson/libav/tests/ref/acodec/wmav1' not found
make: *** [fate-acodec-wmav1] Error 1
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https
On 3/17/2012 9:09 AM, Mike Melanson wrote:
On 3/17/2012 9:06 AM, Justin Ruggles wrote:
Module: libav
Branch: master
Commit: 85cf49fab7d4451dd68e5748862c319ee221df6f
Author: Justin Rugglesjustin.rugg...@gmail.com
Committer: Justin Rugglesjustin.rugg...@gmail.com
Date: Sat Mar 17 11:35:18 2012
On 3/17/2012 9:15 AM, Måns Rullgård wrote:
Mike Melansonm...@multimedia.cx writes:
On 3/17/2012 9:09 AM, Mike Melanson wrote:
On 3/17/2012 9:06 AM, Justin Ruggles wrote:
Module: libav
Branch: master
Commit: 85cf49fab7d4451dd68e5748862c319ee221df6f
Author: Justin Rugglesjustin.rugg
WMA lossless supports up to 8 channels and our new decoder apparently has
support. Do we have any multichannel samples (going up to 6 and 8
channels) that we can test against the decoder?
Thanks,
--
-Mike Melanson
___
libav-devel mailing list
libav
On 3/8/2012 12:54 AM, Mike Melanson wrote:
WMA lossless supports up to 8 channels and our new decoder apparently
has
support. Do we have any multichannel samples (going up to 6 and 8
channels) that we can test against the decoder?
I don't think the decoder supports more than 2 channels
: Target `fate' not remade because of errors.
This is due to dct-test failing to build.
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
the problem on my PPC machine.
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
since I haven't figured out how to fix commit messages in git.
line1: short description
line2: empty
lineX: more details
I figured this out through trial and error. That really should be
written down somewhere.
--
-Mike Melanson
___
libav-devel
that
contributors add FATE tests for their work when it's not especially
obvious how to do so.
I have enough practice now with the new system that I want to write it
down before I forget.
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
to output BMP files from
x86_32 and PPC and then compare them for off-by-1?
Thanks,
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
/288460800
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
this as git's way of punishing me for my ignorance and
format 2 separate bundles (I have figured out 'git format-patch
range_start..range_end')?
Thanks,
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org
figured out 'git format-patch
range_start..range_end')?
git rebase -i origin/master
rearrange the commits so that your patches are at the end
profit
git pull --rebase can fix the issue as well.
Thanks. 'git rebase -i' followed by 'git format-patch HEAD~6' gave me
what I want.
--
-Mike
my stuff about 5 times before I
send it.
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 1/7/2012 11:20 AM, Ronald S. Bultje wrote:
Why is the -pix_fmt gray needed? What I'm afraid of is that you'll be
Not sure what I was thinking with that (gray on the mind?). I'll submit
another test with my next batch that corrects this.
--
-Mike Melanson
/bsf_h264_mp4toannexb
Looks good, but shouldn't it be in tests/fate/h264.mak?
That sounds reasonable. I was just happy to figure out how to add this test.
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org
this by claiming it would be the gateway to including
every bit of computing knowledge imaginable.
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
fine, leading to much confusion and frustration.
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
into this.
Thanks,
--
-Mike Melanson
From d48418214ea04c66ccd74f70e57f730a36f01bd1 Mon Sep 17 00:00:00 2001
From: Mike Melanson m...@multimedia.cx
Date: Fri, 30 Dec 2011 20:26:01 -0800
Subject: [PATCH] Experimental ghost: protocol
---
libavformat/Makefile |1 +
libavformat/allformats.c |1
On 12/30/2011 9:30 PM, Luca Barbato wrote:
On 31/12/11 05:37, Mike Melanson wrote:
Attached is a patch that implements a protocol identified as 'ghost:'.
This protocol behaves as a file, except that all writes occur to a
phantom file in memory. Upon closing the file, the protocol runs MD5
over
for
this codec.
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
these samples yourself? If so, which encoder did
you use? avconv?
CRI ADX doesn't strike me as a codec with lots of features and modes that
need to be exercised.
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https
file. I suspect things got this way because we had the
audio decoder before the video decoder.
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
on
my own learning process which mainly involves grep'ing until I figure out
how to add a new test.
Maybe the correct solution is to have documentation on how to add new tests.
Just a little frustrated because I've been trying to figure out how to add
a new FATE test. :-)
--
-Mike Melanson
is that the md5: target is non-seekable as this
same test repeated with MPEG system target outputs matching MD5 hashes.
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
from 'md5:' does match the MD5 of what gets laid
down on disk as out.mpg (no seeking involved in the write, I guess). But I
don't think we should be afraid of writing files via FATE tests.
Alternatively, we create an internal output target that simulates a file
entirely in memory.
--
-Mike
+- SMJPEG demuxer
Thank you. I've been meaning to do this for 8 years or so. The SMJPEG IMA
ADPCM decoder isn't much use without it. :-)
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo
. So some of these fixes are based
on that documentation, while others are just clean-ups.
Excellent. Also, per my code coverage work, FATE does not even begin to
exercise ADX. This seems like an appropriate use of the
adxenc(raw_wav); adxdec(adx_wav) test pattern.
--
-Mike Melanson
in my adventures with
GStreamer. :-)
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
it on your behalf. :)
Patch looks good. It would probably be useful to store the result of
AV_RB32(scratch[8]) into a fourcc var rather than evaluating it
multiple times. But that might fall under cosmetic reorg.
--
-Mike Melanson
___
libav-devel
size size also cannot be a multiple of the encoded size
one size to much?
Nice catch. And now I get to figure out how to patch a patch, another
topic that git-howto.txt neglects to mention. I guess this is a simple
enough case to learn on.
--
-Mike Melanson
-- while the current description is technically
accurate, it could be worded more clearly.
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
.
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
I can't help thinking VBLE = Variable Bit-Length Encoding. Generic,
but
accurate.
Variable-length bits? That's a new concept.
Makes perfect sense to me: Total number of bits per element is variable
vs. fixed.
--
-Mike Melanson
___
libav
On 11/8/2011 2:08 AM, Felipe Contreras wrote:
This is really very basic stuff covered in countless online tutorials,
including git's official one:
There's nothing basic about git. But now that our tutorial (the one that
matters) has been updated, is it accurate?
--
-Mike Melanson
On Mon, 07 Nov 2011 23:09:47 -0800
Mike Melanson m...@multimedia.cx wrote:
Yeah, 'git show' does work. Now to see what 'git send-email' does with
that patch. How does a command line tool interact with SMTP anyway?
As they have been always doing: assuming that a unix host is
running
. Nothing new appears in the directory.
11. Sending patches for review
git send-email commit list|directory
$ git send-email
git: 'send-email' is not a git command. See 'git --help'.
What am I missing?
--
-Mike Melanson
___
libav-devel mailing list
, but 'git format-patch hash' doesn't appear to do anything. And
'git send-email' doesn't exist (?).
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
package.
Okay, that helped. Probably should be in the doc. I would submit a
change if I could figure out how. Still hung up on the format-patch thing.
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman
until I did 'apt-get install git-email'. Apparently, I'm the
only dev lame enough to be using Ubuntu.
git show hash shows anything?
Yeah, 'git show' does work. Now to see what 'git send-email' does with
that patch. How does a command line tool interact with SMTP anyway?
--
-Mike Melanson
it was used in 2 games (Discworld II and III). Can you send me some
samples for the archive?
Thanks,
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
-an in this case in order to keep the
output smaller since we really don't care about exercising the PCM
system in this case. Perhaps just a personal preference.
2) This isn't a very useful sample since all of the frames are
apparently the same (0xfcfd0349).
--
-Mike Melanson
On 9/22/2011 11:09 PM, Mike Melanson wrote:
A few things:
[...]
Oops, looks like Mans already covered my complaints. Carry on.
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav
it?
2) There's a usable Cinepak encoder patch out there. It's chatty but it
does the job. I don't know about the overall quality but given the vintage
of the codec, the encoder is probably doing a good job. Should we push it
in?
Thanks,
--
-Mike Melanson
. Tomas H.:
Can you comment about whether you think your Cinepak is suitable for
inclusion?
Thanks,
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 7/9/2011 6:27 PM, Ronald S. Bultje wrote:
Fate-suite admins, should I add md5sum files for each? I didn't see
them in h264/, but did see it in h264-conformance/ and film/.
The md5sums are an artifact of Attila's mphq-- there was some script
that automatically generated them all over the
FATE test.
--
-Mike Melanson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Hi guys,
I didn't get a response earlier, so let's try this:
How do I access incoming nowadays? I have roundup samples on incoming
that I need access to.
I can rule out my samples repository
(samples.multimedia.cx/samples.mplayerhq.hu). I didn't mirror the incoming
directory.
--
-Mike
56 matches
Mail list logo
