Re: [libav-devel] [PATCH] Announce Libav 0.7.1
On Fri, Jul 22, 2011 at 11:25:12AM +0700, Le Hong Dang wrote: Hi, On 7/21/2011 2:25 PM, Reinhard Tartler wrote: diff --git a/src/index b/src/index index 53c67c7..6fa2238 100644 --- a/src/index +++ b/src/index @@ -35,6 +35,37 @@ with the latest developments by subscribing to both the h1News/h1 +a name=release_0.7.1/ah3*_Juli_* 21 2011/h3 + Should this be July instead of Juli? :) Thanks for making the release available! There is a small typo in the text. A detailed list of changes can be seen in the git log: ohttp://git.libav.org/?p=libav.git;a=shortlog;h=refs/heads/release/0.7; the o before http in the text. but the link is correct not the text. I dont see the error in the patch. only at the webpage. -- Johan Andersson ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] H.264: Add optimizations to predict x86 assembly.
On Fri, Jul 22, 2011 at 03:09:18AM +, Loren Merritt wrote: On Thu, 21 Jul 2011, Daniel Kang wrote: libavcodec/x86/h264_intrapred.asm |5 +- libavcodec/x86/h264_intrapred_10bit.asm | 1117 --- libavcodec/x86/h264_intrapred_init.c| 29 +- 3 files changed, 437 insertions(+), 714 deletions(-) This patch has passed my review. Then push it :) Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Announce Libav 0.7.1
On Fri, Jul 22, 2011 at 08:42:34 (CEST), Johan Andersson wrote: On Fri, Jul 22, 2011 at 11:25:12AM +0700, Le Hong Dang wrote: Hi, On 7/21/2011 2:25 PM, Reinhard Tartler wrote: diff --git a/src/index b/src/index index 53c67c7..6fa2238 100644 --- a/src/index +++ b/src/index @@ -35,6 +35,37 @@ with the latest developments by subscribing to both the h1News/h1 +a name=release_0.7.1/ah3*_Juli_* 21 2011/h3 + Should this be July instead of Juli? :) Thanks for making the release available! There is a small typo in the text. A detailed list of changes can be seen in the git log: ohttp://git.libav.org/?p=libav.git;a=shortlog;h=refs/heads/release/0.7; the o before http in the text. but the link is correct not the text. I dont see the error in the patch. only at the webpage. My bad, both already fixed. Thanks! -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] vorbisenc: simplify floor_classes[] table
On Sun, Jul 17, 2011 at 04:21:43PM +0100, Mans Rullgard wrote: This avoids an indirection in the table. Data size is slightly smaller on 64-bit systems, 8 bytes larger on 32-bit. OK Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] vorbisenc: simplify floor_classes[] table
Mans Rullgard m...@mansr.com writes:
This avoids an indirection in the table. Data size is slightly
smaller on 64-bit systems, 8 bytes larger on 32-bit.
Signed-off-by: Mans Rullgard m...@mansr.com
---
libavcodec/vorbis_enc_data.h | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vorbis_enc_data.h b/libavcodec/vorbis_enc_data.h
index a1e743e..37a4e1e 100644
--- a/libavcodec/vorbis_enc_data.h
+++ b/libavcodec/vorbis_enc_data.h
@@ -492,13 +492,13 @@ static const struct {
int dim;
int subclass;
int masterbook;
-const int *nbooks;
+const int nbooks[4];
} floor_classes[] = {
-{ 3, 0, 0, (const int[]){ 4 } },
-{ 4, 1, 0, (const int[]){ 5, 6 } },
-{ 3, 1, 1, (const int[]){ 7, 8 } },
-{ 4, 2, 2, (const int[]){ -1, 9, 10, 11 } },
-{ 3, 2, 3, (const int[]){ -1, 12, 13, 14 } },
+{ 3, 0, 0, { 4 } },
+{ 4, 1, 0, { 5, 6 } },
+{ 3, 1, 1, { 7, 8 } },
+{ 4, 2, 2, { -1, 9, 10, 11 } },
+{ 3, 2, 3, { -1, 12, 13, 14 } },
};
Come to think of it, those arrays could be int8_t. In fact, everything
in that struct could.
--
Måns Rullgård
m...@mansr.com
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] 10-bit DNxHD support v7
Joseph Artsimovich jos...@mirriad.com writes: On 18/07/2011 22:56, Måns Rullgård wrote: Joseph Artsimovichjos...@mirriad.com writes: On 18/07/2011 15:45, Måns Rullgård wrote: Maximmax_p...@gmx.de writes: Am 18.07.2011 16:09, schrieb Måns Rullgård: [...] An integer implementation is surely much faster than floating-point one but it's still insufficient for realtime applications The point? You'll be able to obtain reasonable performance benefits only by using SIMD-optimized code. That's the point. I fail to see how that justifies using the even slower floating-point non-simd code. I used that as a starting point, thinking it's the only option I had. Today I tried making various integer-based (I)DCT implementations work with 10-bit samples. I had success with ff_jpeg_fdct_islow() by setting BITS_IN_JSAMPLE to 10 and turning my unsigned samples into signed ones. The latter was required because: [0 .. 1023] samples - [0 - 8191] DCT coeffs - [0 - 65528] after post-scaling by 8, which is outside of DCTELEM (16 bit signed) range. With signed samples, I get: [-512 .. 511] samples - [-4096 .. 4095] DCT coefs - [-32768 .. 32760] after post-scaling by 8, which barely fits in. I still had no success with fdct_ifast() or j_rev_dct() though. I just sent a patch for 10-bit simple_idct. The attached version of your DNxHD patch uses it and decodes about 60% faster than the original version. That's helpful, thanks. For DCT, as I had success with ff_jpeg_fdct_islow(), I am going to turn jfdctint.c into a template. Is that the way to go? In case you missed it, this has all been done and the 10-bit support pushed. Thank you for your contribution. -- Måns Rullgård m...@mansr.com ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] riff: Add mpgv MPEG-2 fourcc
Supported by mplayer and seen in the wild.
---
libavformat/riff.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/libavformat/riff.c b/libavformat/riff.c
index 27f45b9..c426ae5 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -131,6 +131,7 @@ const AVCodecTag ff_codec_bmp_tags[] = {
{ CODEC_ID_MPEG2VIDEO, MKTAG('s', 'l', 'i', 'f') },
{ CODEC_ID_MPEG2VIDEO, MKTAG('E', 'M', '2', 'V') },
{ CODEC_ID_MPEG2VIDEO, MKTAG('M', '7', '0', '1') }, /* Matrox MPEG2
intra-only */
+{ CODEC_ID_MPEG2VIDEO, MKTAG('m', 'p', 'g', 'v') },
{ CODEC_ID_MJPEG,MKTAG('M', 'J', 'P', 'G') },
{ CODEC_ID_MJPEG,MKTAG('L', 'J', 'P', 'G') },
{ CODEC_ID_MJPEG,MKTAG('d', 'm', 'b', '1') },
--
1.7.3.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] riff: Add mpgv MPEG-2 fourcc
On Fri, Jul 22, 2011 at 10:14:35AM -0700, Alex Converse wrote:
Supported by mplayer and seen in the wild.
---
libavformat/riff.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/libavformat/riff.c b/libavformat/riff.c
index 27f45b9..c426ae5 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -131,6 +131,7 @@ const AVCodecTag ff_codec_bmp_tags[] = {
{ CODEC_ID_MPEG2VIDEO, MKTAG('s', 'l', 'i', 'f') },
{ CODEC_ID_MPEG2VIDEO, MKTAG('E', 'M', '2', 'V') },
{ CODEC_ID_MPEG2VIDEO, MKTAG('M', '7', '0', '1') }, /* Matrox MPEG2
intra-only */
+{ CODEC_ID_MPEG2VIDEO, MKTAG('m', 'p', 'g', 'v') },
{ CODEC_ID_MJPEG,MKTAG('M', 'J', 'P', 'G') },
{ CODEC_ID_MJPEG,MKTAG('L', 'J', 'P', 'G') },
{ CODEC_ID_MJPEG,MKTAG('d', 'm', 'b', '1') },
--
looks trivial and so OK
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] mjpeg: actually handle RSTn marker
I noticed this bugreport: http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/133631 This patch fixes playback of the referenced file: http://dren.dk/dl/mjpg-broken.avi ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] jpegdec: actually search for and parse RSTn
From: Michael Niedermayer michae...@gmx.at
Fixes http://ffmpeg.org/trac/ffmpeg/ticket/267
Signed-off-by: Michael Niedermayer michae...@gmx.at
(cherry picked from commit 7b8ed831eb8432d202dad16dedc1758b018bb1fa)
---
libavcodec/mjpegdec.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index b28fdf8..a1588df 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -879,9 +879,12 @@ static int mjpeg_decode_scan(MJpegDecodeContext *s, int
nb_components, int Ah, i
}
}
-if (s-restart_interval !--s-restart_count) {
+if (s-restart_interval show_bits(s-gb, 8) == 0xFF){/* skip
RSTn */
+--s-restart_count;
align_get_bits(s-gb);
-skip_bits(s-gb, 16); /* skip RSTn */
+while(show_bits(s-gb, 8) == 0xFF)
+skip_bits(s-gb, 8);
+skip_bits(s-gb, 8);
for (i=0; inb_components; i++) /* reset dc */
s-last_dc[i] = 1024;
}
--
1.7.4.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] jpegdec: actually search for and parse RSTn
On Fri, Jul 22, 2011 at 07:53:44PM +0200, Reinhard Tartler wrote: From: Michael Niedermayer michae...@gmx.at Fixes http://ffmpeg.org/trac/ffmpeg/ticket/267 Signed-off-by: Michael Niedermayer michae...@gmx.at (cherry picked from commit 7b8ed831eb8432d202dad16dedc1758b018bb1fa) --- libavcodec/mjpegdec.c |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) It needs extensive testing on all known JPEG variants to make sure it doesn't screw anything, it looks slightly suspicious to me. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] dnxhddec: avoid a branch in 10-bit decode_dct_block()
The minimum weight value is 32 so this test can be skipped for the 10-bit case. Overall speedup 3-4%. Signed-off-by: Mans Rullgard m...@mansr.com --- libavcodec/dnxhddec.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c index 426be2e..63ccd08 100644 --- a/libavcodec/dnxhddec.c +++ b/libavcodec/dnxhddec.c @@ -239,7 +239,7 @@ static av_always_inline void dnxhd_decode_dct_block(DNXHDContext *ctx, //av_log(ctx-avctx, AV_LOG_DEBUG, j %d\n, j); //av_log(ctx-avctx, AV_LOG_DEBUG, level %d, weight %d\n, level, weight_matrix[i]); level = (2*level+1) * qscale * weight_matrix[i]; -if (weight_matrix[i] != level_bias) +if (level_bias 32 || weight_matrix[i] != level_bias) level += level_bias; level = level_shift; -- 1.7.6 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] dnxhddec: avoid a branch in 10-bit decode_dct_block()
Hi, On Fri, Jul 22, 2011 at 3:37 PM, Mans Rullgard m...@mansr.com wrote: The minimum weight value is 32 so this test can be skipped for the 10-bit case. Overall speedup 3-4%. Signed-off-by: Mans Rullgard m...@mansr.com --- libavcodec/dnxhddec.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) OK. Ronald ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] Minimum Quality Standards For (Marginal) Encoders
What's the minimum level of quality an encoder should meet in order to be included in the codebase? 2 items: 1) I wrote an Apple Graphics/SMC video encoder that operates on a lossless principle rather than attempting to make any R/D decisions during vector quantization. Should I bother submitting 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 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] Minimum Quality Standards For (Marginal) Encoders
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? I just figured out that the author of this patch is on the list. 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
