All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH] Too slow libv4l MJPEG decoding with HD cameras
@ 2010-10-26 23:51 Mitar
  2010-10-27  9:08 ` Hans de Goede
  0 siblings, 1 reply; 8+ messages in thread
From: Mitar @ 2010-10-26 23:51 UTC (permalink / raw)
  To: linux-media

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

Hi!

On Sun, Oct 24, 2010 at 6:04 PM, Mitar <mmitar@gmail.com> wrote:
> Has anybody tried to improve MJPEG support in libv4l? With newer
> cameras this becomes important.

I have made a patch which makes libv4l uses ffmpeg's avcodec library
for MJPEG decoding. Performance improvements are unbelievable.

I have been testing with Logitech HD Pro Webcam C910 and
2.6.36-rc6-amd64 and Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz.
Camera supports 2592x1944 at 10 FPS MJPEG stream.

With using original MJPEG code it takes my computer on average 129.614
ms to decode the frame what is 0.0257 us per pixel.

With using ffmpeg MJPEG decoding it takes my computer on average
43.616 ms to decode the frame what is 0.0087 us per pixel.

In comparison with libv4l YUYV decoding which is 27.407 ms to decode
the frame what is 0.0054 us per pixel this is really amazing. So it is
same time range with YUYV decoding! This opens a new question of how
fast would YUYV decoding be if we would use swscale library for that.
(Code for that is already in my patch, I just use it only for MJPEG
decoding to proper output format.)

This makes decoding possible in real-time at 20 FPS on my computer.
This is really great. (When I will have such camera.)


Mitar

[-- Attachment #2: v4l-utils-ffmpeg-mjpeg.patch --]
[-- Type: application/octet-stream, Size: 7992 bytes --]

diff --git a/Make.rules b/Make.rules
index 5799de4..cb60f45 100644
--- a/Make.rules
+++ b/Make.rules
@@ -2,7 +2,7 @@ V4L_UTILS_VERSION=0.8.2-test
 
 # These ones can be overriden from the cmdline
 
-CFLAGS := -g -O1
+CFLAGS := -O3 -ffast-math -frename-registers -fweb -mtune=native
 CFLAGS += -Wall -Wpointer-arith
 CXXFLAGS := $(CFLAGS)
 CFLAGS += -Wstrict-prototypes -Wmissing-prototypes
diff --git a/lib/libv4lconvert/Makefile b/lib/libv4lconvert/Makefile
index 93e5fe8..0e12130 100644
--- a/lib/libv4lconvert/Makefile
+++ b/lib/libv4lconvert/Makefile
@@ -21,6 +21,8 @@ INCLUDES      = ../include/libv4lconvert.h
 
 override CPPFLAGS += -DLIBDIR=\"$(LIBDIR)\" -DLIBSUBDIR=\"$(LIBSUBDIR)\"
 
+override LDFLAGS += -lavcodec -lswscale
+
 all: $(TARGETS)
 
 -include $(CONVERT_OBJS:.o=.d)
diff --git a/lib/libv4lconvert/libv4lconvert-priv.h b/lib/libv4lconvert/libv4lconvert-priv.h
index 61a8c39..604c061 100644
--- a/lib/libv4lconvert/libv4lconvert-priv.h
+++ b/lib/libv4lconvert/libv4lconvert-priv.h
@@ -26,6 +26,14 @@
 #include "processing/libv4lprocessing.h"
 #include "tinyjpeg.h"
 
+#ifdef HAVE_AV_CONFIG_H
+#undef HAVE_AV_CONFIG_H
+#endif
+
+#include <libavcodec/avcodec.h>
+#include <libswscale/swscale.h>
+#include <libavutil/mathematics.h>
+
 #define ARRAY_SIZE(x) ((int)sizeof(x)/(int)sizeof((x)[0]))
 
 #define V4LCONVERT_ERROR_MSG_SIZE 256
@@ -43,6 +51,14 @@
 #define V4LCONVERT_NEEDS_CONVERSION      0x02 /* Apps likely wont know this */
 #define V4LCONVERT_COMPRESSED_AND_NEEDS_CONVERSION 0x03
 
+struct v4lconvert_ffmpeg {
+	AVCodecContext *context;
+	AVCodec *codec;
+	AVFrame *frame;
+	AVPacket packet;
+	struct SwsContext *sws_context;
+};
+
 struct v4lconvert_data {
 	int fd;
 	int flags; /* bitfield */
@@ -51,6 +67,7 @@ struct v4lconvert_data {
 	unsigned int no_formats;
 	char error_msg[V4LCONVERT_ERROR_MSG_SIZE];
 	struct jdec_private *jdec;
+	struct v4lconvert_ffmpeg ffmpeg;
 	struct v4l2_frmsizeenum framesizes[V4LCONVERT_MAX_FRAMESIZES];
 	unsigned int no_framesizes;
 	int convert1_buf_size;
diff --git a/lib/libv4lconvert/libv4lconvert.c b/lib/libv4lconvert/libv4lconvert.c
index f08996a..44d9ae7 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -26,6 +26,14 @@
 #include "libv4lconvert-priv.h"
 #include "libv4lsyscall-priv.h"
 
+#ifdef HAVE_AV_CONFIG_H
+#undef HAVE_AV_CONFIG_H
+#endif
+
+#include <libavcodec/avcodec.h>
+#include <libswscale/swscale.h>
+#include <libavutil/mathematics.h>
+
 #define MIN(a, b) (((a) < (b)) ? (a) : (b))
 
 /* Note for proper functioning of v4lconvert_enum_fmt the first entries in
@@ -168,6 +176,16 @@ void v4lconvert_destroy(struct v4lconvert_data *data)
 		tinyjpeg_set_components(data->jdec, comps, 3);
 		tinyjpeg_free(data->jdec);
 	}
+	if (data->ffmpeg.context) {
+		avcodec_close(data->ffmpeg.context);
+		av_free(data->ffmpeg.context);
+	}
+	if (data->ffmpeg.frame) {
+		av_free(data->ffmpeg.frame);
+	}
+	if (data->ffmpeg.sws_context) {
+		sws_freeContext(data->ffmpeg.sws_context);
+	}
 	v4lconvert_helper_cleanup(data);
 	free(data->convert1_buf);
 	free(data->convert2_buf);
@@ -552,9 +570,6 @@ static int v4lconvert_convert_pixfmt(struct v4lconvert_data *data,
 	switch (src_pix_fmt) {
 	case V4L2_PIX_FMT_PJPG:
 		jpeg_flags |= TINYJPEG_FLAGS_PIXART_JPEG;
-		/* Fall through */
-	case V4L2_PIX_FMT_MJPEG:
-	case V4L2_PIX_FMT_JPEG:
 		if (!data->jdec) {
 			data->jdec = tinyjpeg_init();
 			if (!data->jdec)
@@ -639,6 +654,123 @@ static int v4lconvert_convert_pixfmt(struct v4lconvert_data *data,
 			result = -1;
 		}
 		break;
+		
+	case V4L2_PIX_FMT_MJPEG:
+	case V4L2_PIX_FMT_JPEG:
+		if (!data->ffmpeg.frame) {
+			if (!(data->ffmpeg.frame = avcodec_alloc_frame())) {
+				v4lconvert_oom_error(data);
+			}
+		}
+		if (!data->ffmpeg.context) {
+			if (!(data->ffmpeg.context = avcodec_alloc_context())) {
+				v4lconvert_oom_error(data);
+			}
+		}
+		if (!data->ffmpeg.codec) {
+			avcodec_init();
+			av_log_set_level(AV_LOG_ERROR);
+			avcodec_register_all();
+			if (!(data->ffmpeg.codec = avcodec_find_decoder(CODEC_ID_MJPEG))) {
+				V4LCONVERT_ERR("Codec not found\n");
+				errno = EINVAL;
+				return -1;
+			}
+			
+			data->ffmpeg.context->coded_width = width;
+			data->ffmpeg.context->coded_height = height;
+			
+			if (avcodec_open(data->ffmpeg.context, data->ffmpeg.codec) < 0) {
+				V4LCONVERT_ERR("Could not open codec\n");
+				errno = EINVAL;
+				return -1;
+			}
+			av_init_packet(&data->ffmpeg.packet);
+		}
+		
+		data->ffmpeg.packet.size = src_size;
+		data->ffmpeg.packet.data = src;
+		
+		int got_frame;
+		if (avcodec_decode_video2(data->ffmpeg.context, data->ffmpeg.frame, &got_frame, &data->ffmpeg.packet) < 0) {
+			V4LCONVERT_ERR("Error while decoding frame\n");
+			errno = EPIPE;
+			return -1;
+		}
+
+		if (!got_frame) {
+			V4LCONVERT_ERR("Could not decode frame\n");
+			errno = EPIPE;
+			return -1;
+		}
+
+		if (!data->ffmpeg.sws_context) {
+			switch (dest_pix_fmt) {
+				case V4L2_PIX_FMT_RGB24:
+					data->ffmpeg.sws_context = sws_getContext(data->ffmpeg.context->width, data->ffmpeg.context->height, data->ffmpeg.context->pix_fmt, width, height, PIX_FMT_RGB24, SWS_POINT, NULL, NULL, NULL);
+					break;
+				case V4L2_PIX_FMT_BGR24:
+					data->ffmpeg.sws_context = sws_getContext(data->ffmpeg.context->width, data->ffmpeg.context->height, data->ffmpeg.context->pix_fmt, width, height, PIX_FMT_BGR24, SWS_POINT, NULL, NULL, NULL);
+					break;
+				case V4L2_PIX_FMT_YUV420:
+					data->ffmpeg.sws_context = sws_getContext(data->ffmpeg.context->width, data->ffmpeg.context->height, data->ffmpeg.context->pix_fmt, width, height, PIX_FMT_YUV420P, SWS_POINT, NULL, NULL, NULL);
+					break;
+				case V4L2_PIX_FMT_YVU420:
+					data->ffmpeg.sws_context = sws_getContext(data->ffmpeg.context->width, data->ffmpeg.context->height, data->ffmpeg.context->pix_fmt, width, height, PIX_FMT_YUV420P, SWS_POINT, NULL, NULL, NULL);
+					break;
+			}
+			
+			if (!data->ffmpeg.sws_context) {
+				V4LCONVERT_ERR("Could not get libswscale context\n");
+				errno = EINVAL;
+				return -1;
+			}
+		}
+
+		AVPicture output;
+		switch (dest_pix_fmt) {
+			case V4L2_PIX_FMT_RGB24:
+				if (avpicture_fill(&output, dest, PIX_FMT_RGB24, width, height) > dest_size) {
+					V4LCONVERT_ERR("Destination buffer too small\n");
+					errno = EINVAL;
+					return -1;
+				}
+				break;
+			case V4L2_PIX_FMT_BGR24:
+				if (avpicture_fill(&output, dest, PIX_FMT_BGR24, width, height) > dest_size) {
+					V4LCONVERT_ERR("Destination buffer too small\n");
+					errno = EINVAL;
+					return -1;
+				}
+				break;
+			case V4L2_PIX_FMT_YUV420:
+				if (avpicture_fill(&output, dest, PIX_FMT_YUV420P, width, height) > dest_size) {
+					V4LCONVERT_ERR("Destination buffer too small\n");
+					errno = EINVAL;
+					return -1;
+				}
+				break;
+			case V4L2_PIX_FMT_YVU420:
+				if (avpicture_fill(&output, dest, PIX_FMT_YUV420P, width, height) > dest_size) {
+					V4LCONVERT_ERR("Destination buffer too small\n");
+					errno = EINVAL;
+					return -1;
+				}
+				
+				// U and V planes are swapped
+				uint8_t *temp = output.data[2];
+				output.data[2] = output.data[1];
+				output.data[1] = temp;
+				break;
+		}
+		
+		if (sws_scale(data->ffmpeg.sws_context, (const uint8_t **)data->ffmpeg.frame->data, data->ffmpeg.frame->linesize, 0, data->ffmpeg.context->height, output.data, output.linesize) != height) {
+			V4LCONVERT_ERR("Could not convert with libswscale\n");
+			errno = EINVAL;
+			return -1;				
+		}
+		
+		break;
 
 		/* Custom cam specific YUV formats */
 	case V4L2_PIX_FMT_SPCA501:
diff --git a/lib/libv4lconvert/tinyjpeg-internal.h b/lib/libv4lconvert/tinyjpeg-internal.h
index 702a2a2..fe55228 100644
--- a/lib/libv4lconvert/tinyjpeg-internal.h
+++ b/lib/libv4lconvert/tinyjpeg-internal.h
@@ -47,7 +47,7 @@ struct jdec_private;
 
 #define HUFFMAN_TABLES	   4
 #define COMPONENTS	   3
-#define JPEG_MAX_WIDTH	   2048
+#define JPEG_MAX_WIDTH	   4096
 #define JPEG_MAX_HEIGHT	   2048
 
 struct huffman_table {

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] Too slow libv4l MJPEG decoding with HD cameras
  2010-10-26 23:51 [PATCH] Too slow libv4l MJPEG decoding with HD cameras Mitar
@ 2010-10-27  9:08 ` Hans de Goede
  2010-10-27 10:49   ` Janne Grunau
  0 siblings, 1 reply; 8+ messages in thread
From: Hans de Goede @ 2010-10-27  9:08 UTC (permalink / raw)
  To: Mitar; +Cc: linux-media

Hi,

On 10/27/2010 01:51 AM, Mitar wrote:
> Hi!
>
> On Sun, Oct 24, 2010 at 6:04 PM, Mitar<mmitar@gmail.com>  wrote:
>> Has anybody tried to improve MJPEG support in libv4l? With newer
>> cameras this becomes important.
>
> I have made a patch which makes libv4l uses ffmpeg's avcodec library
> for MJPEG decoding. Performance improvements are unbelievable.
>

Thanks for the patch!

> I have been testing with Logitech HD Pro Webcam C910 and
> 2.6.36-rc6-amd64 and Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz.
> Camera supports 2592x1944 at 10 FPS MJPEG stream.
>
> With using original MJPEG code it takes my computer on average 129.614
> ms to decode the frame what is 0.0257 us per pixel.
>
> With using ffmpeg MJPEG decoding it takes my computer on average
> 43.616 ms to decode the frame what is 0.0087 us per pixel.

That is a great improvement, but using ffmpeg in libv4l is not an option
for multiple reasons:

1) It is GPL licensed not LGPL
2) It has various other legal issues which means it is not available
    in most distro's main repository.

So I'm afraid that using ffmpeg really is out of the question. What
would be interesting is to see how libjpeg performs and then esp. the
turbo-libjpeg version:
http://libjpeg-turbo.virtualgl.org/

I would love to see a patch to use that instead of tiny jpeg, leaving
tinyjpeg usage only for the pixart jpeg variant stuff.

Note that some cameras generate what I call planar jpeg, this means
that they send 3 SOS markers with one component per scan. I don't know
if libjpeg will grok this (I had to patch libv4l's tinyjpeg copy for
this). But first lets see how libjpeg performs, and then we can always
use tinyjpeg to parse the header and depending on the header decide to
use tinyjpeg or libjpeg.

Sorry about nacking your ffmpeg patch, I hope that you are willing to
do a patch to switch to libjpeg, as I'm afraid I currently don't have
time to look into this.

Oh and a hint when using libjpeg for in memory images, please
use the jpeg_mem_src code from here:
http://gphoto.svn.sourceforge.net/viewvc/gphoto/branches/libgphoto2-2_4/libgphoto2/camlibs/ax203/jpeg_memsrcdest.c?revision=13328&view=markup

This code was specifically written to be API compatible with the
one introduced in newer libjpeg versions (8), while providing
memory src support when working with libjpeg versions which
do not ship with a memory src themselves like the version 6b
shipped by most distros (and used as a basis for libjpeg turbo).

So by using this memory src code, the libv4l libjpeg support can
work with libjpeg6-8 and libjpeg-turbo without needing any
ifdef's other then the one in that .c file.

Thanks & Regards,

Hans

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Too slow libv4l MJPEG decoding with HD cameras
  2010-10-27  9:08 ` Hans de Goede
@ 2010-10-27 10:49   ` Janne Grunau
  2010-10-27 13:23     ` Hans de Goede
  2010-10-27 14:01     ` Mitar
  0 siblings, 2 replies; 8+ messages in thread
From: Janne Grunau @ 2010-10-27 10:49 UTC (permalink / raw)
  To: Hans de Goede; +Cc: Mitar, linux-media

On Wed, Oct 27, 2010 at 11:08:35AM +0200, Hans de Goede wrote:
> Hi,
> 
> On 10/27/2010 01:51 AM, Mitar wrote:
> > Hi!
> >
> > On Sun, Oct 24, 2010 at 6:04 PM, Mitar<mmitar@gmail.com>  wrote:
> >> Has anybody tried to improve MJPEG support in libv4l? With newer
> >> cameras this becomes important.
> >
> > I have made a patch which makes libv4l uses ffmpeg's avcodec library
> > for MJPEG decoding. Performance improvements are unbelievable.
> >
> 
> Thanks for the patch!
> 
> > I have been testing with Logitech HD Pro Webcam C910 and
> > 2.6.36-rc6-amd64 and Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz.
> > Camera supports 2592x1944 at 10 FPS MJPEG stream.
> >
> > With using original MJPEG code it takes my computer on average 129.614
> > ms to decode the frame what is 0.0257 us per pixel.
> >
> > With using ffmpeg MJPEG decoding it takes my computer on average
> > 43.616 ms to decode the frame what is 0.0087 us per pixel.
> 
> That is a great improvement, but using ffmpeg in libv4l is not an option
> for multiple reasons:
> 
> 1) It is GPL licensed not LGPL

FFmpeg is mostly LGPL licensed, only a few optimizations and interfaces
to GPL libraries. Running FFmpeg's configure without options and
especially without --enable-gpl will only use lgpl or compatible
licensed code.

> 2) It has various other legal issues which means it is not available
>     in most distro's main repository.

FUD, Ubuntu doesn't seem to have a problem with it.

> So I'm afraid that using ffmpeg really is out of the question. What
> would be interesting is to see how libjpeg performs and then esp. the
> turbo-libjpeg version:
> http://libjpeg-turbo.virtualgl.org/
> 
> I would love to see a patch to use that instead of tiny jpeg, leaving
> tinyjpeg usage only for the pixart jpeg variant stuff.
> 
> Note that some cameras generate what I call planar jpeg, this means
> that they send 3 SOS markers with one component per scan. I don't know
> if libjpeg will grok this (I had to patch libv4l's tinyjpeg copy for
> this). But first lets see how libjpeg performs, and then we can always
> use tinyjpeg to parse the header and depending on the header decide to
> use tinyjpeg or libjpeg.
> 
> Sorry about nacking your ffmpeg patch,

While the patch is not the cleanest, there shouldn't be a problem of
making ffmpeg mjpeg decoding optional.

Janne

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Too slow libv4l MJPEG decoding with HD cameras
  2010-10-27 10:49   ` Janne Grunau
@ 2010-10-27 13:23     ` Hans de Goede
  2010-10-27 13:59       ` Mitar
  2010-10-27 14:01     ` Mitar
  1 sibling, 1 reply; 8+ messages in thread
From: Hans de Goede @ 2010-10-27 13:23 UTC (permalink / raw)
  To: Janne Grunau; +Cc: Mitar, linux-media

Hi,

On 10/27/2010 12:49 PM, Janne Grunau wrote:

<snip>

>>> With using ffmpeg MJPEG decoding it takes my computer on average
>>> 43.616 ms to decode the frame what is 0.0087 us per pixel.
>>
>> That is a great improvement, but using ffmpeg in libv4l is not an option
>> for multiple reasons:
>>
>> 1) It is GPL licensed not LGPL
>
> FFmpeg is mostly LGPL licensed, only a few optimizations and interfaces
> to GPL libraries. Running FFmpeg's configure without options and
> especially without --enable-gpl will only use lgpl or compatible
> licensed code.
>

Ok, that is good to know.

>> 2) It has various other legal issues which means it is not available
>>      in most distro's main repository.
>
> FUD, Ubuntu doesn't seem to have a problem with it.

Not a really helpful response I'm afraid, there are a number of highprofile
distributions which do not include ffmpeg, so depending on ffmpeg is not
really an option.

>> So I'm afraid that using ffmpeg really is out of the question. What
>> would be interesting is to see how libjpeg performs and then esp. the
>> turbo-libjpeg version:
>> http://libjpeg-turbo.virtualgl.org/
>>
>> I would love to see a patch to use that instead of tiny jpeg, leaving
>> tinyjpeg usage only for the pixart jpeg variant stuff.
>>
>> Note that some cameras generate what I call planar jpeg, this means
>> that they send 3 SOS markers with one component per scan. I don't know
>> if libjpeg will grok this (I had to patch libv4l's tinyjpeg copy for
>> this). But first lets see how libjpeg performs, and then we can always
>> use tinyjpeg to parse the header and depending on the header decide to
>> use tinyjpeg or libjpeg.
>>
>> Sorry about nacking your ffmpeg patch,
>
> While the patch is not the cleanest, there shouldn't be a problem of
> making ffmpeg mjpeg decoding optional.

If and only if libjpeg-turbo turns out to be much slower this is something
to consider. But the first thing to do here is see if we can solve this
in a way which is acceptable to all downstream users of libv4l, and thus
can be added in a non optional way (so make libv4l require libjpeg).

I'm not a big fan of optional features / compile time options as they
do not make support any easier.

Regards,

Hans

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Too slow libv4l MJPEG decoding with HD cameras
  2010-10-27 13:23     ` Hans de Goede
@ 2010-10-27 13:59       ` Mitar
  2010-10-27 17:43         ` Hans de Goede
  0 siblings, 1 reply; 8+ messages in thread
From: Mitar @ 2010-10-27 13:59 UTC (permalink / raw)
  To: Hans de Goede; +Cc: Janne Grunau, linux-media

Hi!

On Wed, Oct 27, 2010 at 3:23 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> If and only if libjpeg-turbo turns out to be much slower this is something
> to consider. But the first thing to do here is see if we can solve this
> in a way which is acceptable to all downstream users of libv4l, and thus
> can be added in a non optional way (so make libv4l require libjpeg).

I opted for avcodec as I have been told it is the fastest
implementation around. But I have not really tested that claim. So for
sure this should be tested. I tested just original tinyjpeg vs.
avcodec implementation.

I am sorry but I do not have time to do more work on this. Especially
because libjpeg-turbo also seems to have problems with restart
markers:

http://libjpeg-turbo.virtualgl.org/About/Performance (at the end)

which is the problem I am currently try to deal with also with ffmpeg:

https://roundup.ffmpeg.org/issue2325

Restart markers are used by Logitech HD Pro Webcam C910 to allow
decoding of MJPEG in parallel for example on GPU for even faster
decoding.

So implementing libjpeg-turbo does not seem that it would give me a
working solution and improvement over libavcodec. (And for ffmpeg
there is at least patch for that.)

Maybe we should make libv4l plugable in this respect? So that
different underlying libraries could be easily swapped and tested and
used? Or just use different compilation switches and let distribution
maintainers decide which one they want to use?


Mitar

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Too slow libv4l MJPEG decoding with HD cameras
  2010-10-27 10:49   ` Janne Grunau
  2010-10-27 13:23     ` Hans de Goede
@ 2010-10-27 14:01     ` Mitar
  1 sibling, 0 replies; 8+ messages in thread
From: Mitar @ 2010-10-27 14:01 UTC (permalink / raw)
  To: Janne Grunau; +Cc: Hans de Goede, linux-media

Hi!

On Wed, Oct 27, 2010 at 12:49 PM, Janne Grunau <j@jannau.net> wrote:
> While the patch is not the cleanest, there shouldn't be a problem of
> making ffmpeg mjpeg decoding optional.

In which way not the cleanest? I am always searching for ways to
improve my further work. So please elaborate.


Mitar

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Too slow libv4l MJPEG decoding with HD cameras
  2010-10-27 13:59       ` Mitar
@ 2010-10-27 17:43         ` Hans de Goede
  2010-10-28 20:35           ` Mitar
  0 siblings, 1 reply; 8+ messages in thread
From: Hans de Goede @ 2010-10-27 17:43 UTC (permalink / raw)
  To: Mitar; +Cc: Janne Grunau, linux-media

Hi,

On 10/27/2010 03:59 PM, Mitar wrote:
> Hi!
>
> On Wed, Oct 27, 2010 at 3:23 PM, Hans de Goede<hdegoede@redhat.com>  wrote:
>> If and only if libjpeg-turbo turns out to be much slower this is something
>> to consider. But the first thing to do here is see if we can solve this
>> in a way which is acceptable to all downstream users of libv4l, and thus
>> can be added in a non optional way (so make libv4l require libjpeg).
>
> I opted for avcodec as I have been told it is the fastest
> implementation around. But I have not really tested that claim. So for
> sure this should be tested. I tested just original tinyjpeg vs.
> avcodec implementation.
>
> I am sorry but I do not have time to do more work on this. Especially
> because libjpeg-turbo also seems to have problems with restart
> markers:
>
> http://libjpeg-turbo.virtualgl.org/About/Performance (at the end)
>
> which is the problem I am currently try to deal with also with ffmpeg:
>
> https://roundup.ffmpeg.org/issue2325
>

Well the problem is not entirely the same. libjpeg-turbo will degrade
a bit in performance when encountering these markers, where as if I
understand your ffmpeg bugreport properly ffmpeg does not properly
decode these images. This seems actually like an argument in favor of
giving libjpeg a try.

Are you sure you cannot make some time for this?

Regards,

Hans

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Too slow libv4l MJPEG decoding with HD cameras
  2010-10-27 17:43         ` Hans de Goede
@ 2010-10-28 20:35           ` Mitar
  0 siblings, 0 replies; 8+ messages in thread
From: Mitar @ 2010-10-28 20:35 UTC (permalink / raw)
  To: Hans de Goede; +Cc: Janne Grunau, linux-media

Hi!

On Wed, Oct 27, 2010 at 7:43 PM, Hans de Goede <hdegoede@redhat.com> wrote:
> Are you sure you cannot make some time for this?

Sorry, probably not. At least not in the near future.


Mitar

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2010-10-28 20:35 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-26 23:51 [PATCH] Too slow libv4l MJPEG decoding with HD cameras Mitar
2010-10-27  9:08 ` Hans de Goede
2010-10-27 10:49   ` Janne Grunau
2010-10-27 13:23     ` Hans de Goede
2010-10-27 13:59       ` Mitar
2010-10-27 17:43         ` Hans de Goede
2010-10-28 20:35           ` Mitar
2010-10-27 14:01     ` Mitar

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.