On Thu, Feb 09, 2017 at 01:20:09PM +0100, Michael Niedermayer wrote:
[...]
> > int ff_mjpeg_encode_stuffing(MpegEncContext *s)
> > {
> > int i;
> > PutBitContext *pbc = &s->pb;
> > int mb_y = s->mb_y - !s->mb_x;
> >+int ret;
> >+MJpegContext *m;
> >+
> >+m = s->mjpeg_ctx;
>
On Thu, Feb 09, 2017 at 03:44:59AM +0100, Michael Niedermayer wrote:
> On Wed, Feb 01, 2017 at 11:23:04PM -0800, Jerry Jiang wrote:
[...]
> i sadly dont have time to do a more complete review ATM (need sleep)
> but this patch doesnt look like it was ready for being pushed
more reviewing related to
On Thu, Feb 09, 2017 at 04:30:02AM +0100, Michael Niedermayer wrote:
> On Thu, Feb 09, 2017 at 03:17:23AM +, Rostislav Pehlivanov wrote:
> > On 9 February 2017 at 02:44, Michael Niedermayer
> [...]
> > > i sadly dont have time to do a more complete review ATM (need sleep)
> > > but this patch
On Thu, Feb 09, 2017 at 03:17:23AM +, Rostislav Pehlivanov wrote:
> On 9 February 2017 at 02:44, Michael Niedermayer
[...]
> > i sadly dont have time to do a more complete review ATM (need sleep)
> > but this patch doesnt look like it was ready for being pushed
> >
>
> Perhaps I was too hasty
On 9 February 2017 at 02:44, Michael Niedermayer
wrote:
>
> > +
> > +int ff_mjpeg_encode_mb(MpegEncContext *s, int16_t block[12][64])
> > +{
> > +int i, is_chroma_420;
> > +
> > +// Number of bits used depends on future data.
> > +// So, nothing that relies on encoding many times and
On Wed, Feb 01, 2017 at 11:23:04PM -0800, Jerry Jiang wrote:
> > seems to break
> > make fate-vsynth1-mjpeg-444
>
> Fixed.
>
Missing commit message
[...]
> -void ff_mjpeg_encode_mb(MpegEncContext *s, int16_t block[12][64])
> +// Possibly reallocate the huffman code buffer, assuming blocks_per_
On Wed, Feb 01, 2017 at 11:23:04PM -0800, Jerry Jiang wrote:
> > seems to break
> > make fate-vsynth1-mjpeg-444
>
> Fixed.
>
> ---
> Changelog| 1 +
> doc/encoders.texi| 21 ++
> libavcodec/Makefile
On 8 February 2017 at 07:09, Jerry Jiang wrote:
> Hey is there an update on the status of the patch? Any other requested
> changes?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Hi, sorr
Hey is there an update on the status of the patch? Any other requested
changes?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> seems to break
> make fate-vsynth1-mjpeg-444
Fixed.
---
Changelog| 1 +
doc/encoders.texi| 21 ++
libavcodec/Makefile | 8 +-
libavcodec/mjpegenc.c| 243 +++
On Tue, Jan 31, 2017 at 11:31:23PM -0800, Jerry Jiang wrote:
> Fixed patch issue.
>
> > It seems that "mjpeg-trell-qprd-huffman" is missing here.
>
> Removed the test instead since it's supposed to error.
seems to break
make fate-vsynth1-mjpeg-444
Internal error, put_bits buffer too small
Asser
Fixed patch issue.
> It seems that "mjpeg-trell-qprd-huffman" is missing here.
Removed the test instead since it's supposed to error.
---
Changelog| 1 +
doc/encoders.texi| 21 ++
libavcodec/Makefile
On 30.01.2017 04:54, Jerry Jiang wrote:
[...]
diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak
index a51f16c..a325da9 100644
--- a/tests/fate/vcodec.mak
+++ b/tests/fate/vcodec.mak
@@ -213,11 +213,15 @@ fate-vsynth%-jpeg2000-97: DECINOPTS = -vcodec
jpeg2000
FATE_VCODEC-$(c
On 30 January 2017 at 03:54, Jerry Jiang wrote:
>Hey everyone,
>
>Sorry for the long wait, here's a new patch addressing the feedback. In
>addition, we discovered that this current implementation of optimal huffman
>encoding is not compatible with QP RD, so we chose to disable QP RD for
>mjpeg or
On Sun, Jan 29, 2017 at 07:54:19PM -0800, Jerry Jiang wrote:
> Hey everyone,
>
> Sorry for the long wait, here's a new patch addressing the feedback. In
> addition, we discovered that this current implementation of optimal huffman
> encoding is not compatible with QP RD, so we chose to disable QP
Hey everyone,
Sorry for the long wait, here's a new patch addressing the feedback. In
addition, we discovered that this current implementation of optimal huffman
encoding is not compatible with QP RD, so we chose to disable QP RD for
mjpeg or amv encoding. (Wondering if that's acceptable, since it
On Wed, 28 Dec 2016 08:13:52 +
Rostislav Pehlivanov wrote:
> The only problem I have with the code is that it uses a linked list
> and calls malloc during runtime. Couldn't the linked list be replaced
> with an array allocated during init (it should be okay, I don't think
> resolution is allo
On Wed, Dec 28, 2016 at 01:22:14AM -0500, Jerry Jiang wrote:
> Hey everyone,
>
> I made a completely new patch to both fix the newline corruption (hopefully),
> and to address comments. Also, I found that one of the tests wasn't being
> checked, so I fixed that too.
>
> > your patch is missing do
On Wed, Dec 28, 2016 at 01:22:14AM -0500, Jerry Jiang wrote:
> Changelog| 1 +
> doc/encoders.texi| 21 +++
> libavcodec/Makefile | 8 +-
> libavcodec/mjpegenc.c| 265
> ++
On 28 December 2016 at 06:22, Jerry Jiang wrote:
> -
> +{ "huffman", "Huffman table strategy", OFFSET(huffman), AV_OPT_TYPE_INT,
> { .i64 = HUFFMAN_TABLE_DEFAULT }, 1, 2, VE, "huffman" },
> +{ "default", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> HUFFMAN_TABLE_DEFAULT }, INT_MIN, INT_MAX, VE, "hu
Hey everyone,
I made a completely new patch to both fix the newline corruption (hopefully),
and to address comments. Also, I found that one of the tests wasn't being
checked, so I fixed that too.
> your patch is missing docs (document -huffman optimal by creating mjpeg
> encoder section in doc/en
On Tue, Dec 27, 2016 at 07:37:09 +, Jerry Jiang wrote:
> This is my first patch submitted to FFmpeg, so I'm sure that I missed
> something. Please bear with me. :P This patch implements the solution
> outlined here: https://guru.multimedia.cx/small-tasks-for-ffmpeg/
Apart from the newline-corr
On Tue, 27 Dec 2016 07:37:09 +
Jerry Jiang wrote:
> Hey everyone,
>
> This is my first patch submitted to FFmpeg, so I'm sure that I missed
> something. Please bear with me. :P This patch implements the solution
> outlined here: https://guru.multimedia.cx/small-tasks-for-ffmpeg/
hi! it is i
On Tue, Dec 27, 2016 at 07:37:09AM +, Jerry Jiang wrote:
> Hey everyone,
>
> This is my first patch submitted to FFmpeg, so I'm sure that I missed
> something. Please bear with me. :P This patch implements the solution
> outlined here: https://guru.multimedia.cx/small-tasks-for-ffmpeg/
>
> Ac
Thanks for looking at our patch!
> What's the performance impact like when you enable it? Any reason why it
> shouldn't be made the default?
From local testing on converting a random video using the mjpeg codec, we
were able to encode at a speed of 207 fps with the -huffman optimal flag, a
speed
On 27 December 2016 at 07:37, Jerry Jiang wrote:
> Hey everyone,
>
> This is my first patch submitted to FFmpeg, so I'm sure that I missed
> something. Please bear with me. :P This patch implements the solution
> outlined here: https://guru.multimedia.cx/small-tasks-for-ffmpeg/
>
>
Hi, thanks for
Hey everyone,
This is my first patch submitted to FFmpeg, so I'm sure that I missed
something. Please bear with me. :P This patch implements the solution
outlined here: https://guru.multimedia.cx/small-tasks-for-ffmpeg/
Activated by passing the flag "-huffman optimal" to the mjpeg encoder,
otherw
27 matches
Mail list logo
