[Mlt-devel] Fwd: Bug#660183: kdenlive: rendered video haslost red when taken some sources
Hi Dan,
this sounds like another libav issue, or not?
Original-Nachricht
hiya
downloaded the 7.8 from sid and isntalled them but still no red in the
videos
On 17 February 2012 08:12, Patrick Matthäi pmatth...@debian.org
mailto:pmatth...@debian.org wrote:
Am 17.02.2012 09:05, schrieb Dick William Thomas:
Package: kdenlive
Version: 0.8.2.1-1
Severity: important
Dear Maintainer,
* I've been using kdenlive or months with out issue and
today reinstalled
wheezy with out debian multimedia repo as I wanted a more pure
debian also
ffmpeg now support x264
I've found video's rendered from a source that has a windowed
screen capture
are green
* What exactly did you do (or not do) that was effective (or
ineffective)?
I recorded two videos using ffmpeg then rendered them
one after the
other in a single video 1/2 the video has normal colour but the
windows part is
lost it's red.
I think the problem is melt as I also tried it with openshot and
it had the
same outcome
and when kdenlive is run from the command line the out put says
it's sending it
to melt
I recoreded the videos using
#FULL SCREEN
ffmpeg -f alsa -ac 2 -i pulse -f x11grab -r 30 -s $(xwininfo
-root | grep
'geometry' | awk '{print $2;}') -i :0.0+0,0 -acodec libvorbis
-ab 128k -ac 2
-vcodec libx264 -crf 0 -threads 0 -baseName-fullscreen.avi
#WINDOWED
INFO=$(xwininfo -frame)
WIN_GEO=$(echo $INFO | grep -oEe 'geometry [0-9]+x[0-9]+' | grep
-oEe
'[0-9]+x[0-9]+')
WIN_XY=$(echo $INFO | grep -oEe 'Corners:\s+\+[0-9]+\+[0-9]+' |
grep -oEe
'[0-9]+\+[0-9]+' | sed -e 's/\+/,/' )
ffmpeg -f alsa -ac 2 -i pulse -f x11grab -r 30 -s $WIN_GEO -i
:0.0+$WIN_XY
-acodec libvorbis -ab 128k -ac 2 -vcodec libx264 -vf
scale=720:432 -threads 0
-y baseName-windowed.avi
the output is in this download along with the rendered finish
product
http://dl.dropbox.com/u/__302701/kdenlive-bug.tar.gz
http://dl.dropbox.com/u/302701/kdenlive-bug.tar.gz
Could you try out mlt 0.7.8?
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
Re: [Mlt-devel] no alpha channel for video with PIX_FMT_YUVA420P pixel format
16.02.12 18:56, Dan Dennedy написав(ла):
2012/2/16 Maksym Veremeyenkove...@m1stereo.tv:
02.02.12 19:03, Maksym Veremeyenko написав(ла):
Hi,
i am trying to decrease cpu usage, so i would like to use
PIX_FMT_YUVA420P animation instead of PIX_FMT_BGRA (or other rgb with
alpha channel) but has no luck..
video with such pixel format in *nut* container has detected by ffmpeg
properly, but mlt did not use it alpha channel.
i can provide a sample if required...
alpha been ignored for PIX_FMT_YUVA420P and PIX_FMT_YUVA444P pixel format.
moreover current implementation of libswscale drop alpha channel if
destination format has no alpha and not planar (even if buffer specified)
attached patch extract alpha plane during image decoding. it works almost
fine except moments when image fetched from cache (even if *noimagecache*
specified). another problem is artifact that appear if last frame in movie
is not transparent but producer specifies *out* out of animation.
another attempt to fix this was to fix mlt_frame_clone (patch attached) but
it has no luck too...
OK, thank you for the start of this effort. I will look at it this weekend.
attached updated version that works with cache.
second patch is optional but could be usefull if frame with alpha been
cloned.
--
Maksym Veremeyenko
From d13a842181a9bc55c40b84af9c385ddbd0965987 Mon Sep 17 00:00:00 2001
From: Maksym Veremeyenko ve...@m1stereo.tv
Date: Fri, 17 Feb 2012 12:01:40 +0200
Subject: [PATCH] alpha extracting from planar formats
---
src/modules/avformat/producer_avformat.c | 59 ++
1 files changed, 51 insertions(+), 8 deletions(-)
diff --git a/src/modules/avformat/producer_avformat.c b/src/modules/avformat/producer_avformat.c
index 87b87af..f58e287 100644
--- a/src/modules/avformat/producer_avformat.c
+++ b/src/modules/avformat/producer_avformat.c
@@ -115,6 +115,7 @@ struct producer_avformat_s
unsigned int invalid_pts_counter;
double resample_factor;
mlt_cache image_cache;
+ mlt_cache alpha_cache;
int colorspace;
pthread_mutex_t video_mutex;
pthread_mutex_t audio_mutex;
@@ -1243,7 +1244,7 @@ static mlt_image_format pick_format( enum PixelFormat pix_fmt )
}
static void convert_image( AVFrame *frame, uint8_t *buffer, int pix_fmt,
- mlt_image_format *format, int width, int height, int colorspace )
+ mlt_image_format *format, int width, int height, int colorspace, uint8_t **alpha )
{
#ifdef SWSCALE
int full_range = -1;
@@ -1256,6 +1257,21 @@ static void convert_image( AVFrame *frame, uint8_t *buffer, int pix_fmt,
flags |= SWS_CPU_CAPS_MMX2;
#endif
+ /* extract alpha from planar formats */
+ if ( ( pix_fmt == PIX_FMT_YUVA420P || pix_fmt == PIX_FMT_YUVA444P )
+ *format != mlt_image_rgb24a *format != mlt_image_opengl
+ frame-data[3] frame-linesize[3] )
+ {
+ int i;
+ uint8_t *src, *dst;
+
+ dst = *alpha = mlt_pool_alloc( width * height );
+ src = frame-data[3];
+
+ for(i = 0; i height; dst += width, src += frame-linesize[3], i++)
+ memcpy(dst, src, FFMIN(width, frame-linesize[3]));
+ }
+
if ( *format == mlt_image_yuv420p )
{
struct SwsContext *context = sws_getContext( width, height, pix_fmt,
@@ -1388,9 +1404,14 @@ static int producer_get_image( mlt_frame frame, uint8_t **buffer, mlt_image_form
// Get codec context
AVCodecContext *codec_context = stream-codec;
+ uint8_t *alpha = NULL;
+
// Get the image cache
if ( ! self-image_cache ! mlt_properties_get_int( properties, noimagecache ) )
+ {
self-image_cache = mlt_cache_init();
+ self-alpha_cache = mlt_cache_init();
+ }
if ( self-image_cache )
{
mlt_cache_item item = mlt_cache_get( self-image_cache, (void*) position );
@@ -1422,6 +1443,16 @@ static int producer_get_image( mlt_frame frame, uint8_t **buffer, mlt_image_form
}
self-got_picture = 1;
+ /* check for alpha */
+ item = mlt_cache_get( self-alpha_cache, (void*) position );
+ original = mlt_cache_item_data( item, size );
+ if( original )
+ {
+alpha = mlt_pool_alloc( size );
+memcpy( alpha, original, size );
+mlt_cache_item_close( item );
+ }
+
goto exit_get_image;
}
}
@@ -1464,7 +1495,6 @@ static int producer_get_image( mlt_frame frame, uint8_t **buffer, mlt_image_form
context = self-video_format;
stream = context-streams[ self-video_index ];
codec_context = stream-codec;
-
if ( *format == mlt_image_none ||
codec_context-pix_fmt == PIX_FMT_ARGB ||
codec_context-pix_fmt == PIX_FMT_RGBA ||
@@ -1495,12 +1525,12 @@ static int producer_get_image( mlt_frame frame, uint8_t **buffer, mlt_image_form
picture.linesize[1] = codec_context-width / 2;
picture.linesize[2] = codec_context-width / 2;
convert_image( (AVFrame*) picture, *buffer,
- PIX_FMT_YUV420P, format, *width, *height, self-colorspace );
+ PIX_FMT_YUV420P, format, *width, *height, self-colorspace, alpha );
}
else
#endif
convert_image( self-av_frame, *buffer,
Re: [Mlt-devel] [PATCH] save converted image for next use
15.02.12 20:49, Dan Dennedy написав(ла):
[...]
In the pixbuf patch, you should not call the convert_image virtual
function directly; use mlt_frame_get_image().
use mlt_frame_get_image for converting image did not work - call to that
function return blank frame...
i updated patch and added the same functionality to pango producer, but
calling convert_image virtual function directly left till i find another
way to convert it...
--
Maksym Veremeyenko
From 061535dd2d7675cbb7596f3be0ff4a7c1fc272ac Mon Sep 17 00:00:00 2001
From: Maksym Veremeyenko ve...@m1stereo.tv
Date: Fri, 17 Feb 2012 16:17:32 +0200
Subject: [PATCH 1/2] save converted frame of pixbuf producer
---
src/modules/gtk2/producer_pixbuf.c | 74 +++-
1 files changed, 64 insertions(+), 10 deletions(-)
diff --git a/src/modules/gtk2/producer_pixbuf.c b/src/modules/gtk2/producer_pixbuf.c
index b7da50b..3adce16 100644
--- a/src/modules/gtk2/producer_pixbuf.c
+++ b/src/modules/gtk2/producer_pixbuf.c
@@ -59,8 +59,24 @@ struct producer_pixbuf_s
uint8_t *image;
mlt_cache_item image_cache;
pthread_mutex_t mutex;
+ struct
+ {
+ uint8_t *image, *alpha;
+ int image_size, alpha_size;
+ mlt_image_format format;
+ } clone;
};
+static void clean_clone( producer_pixbuf self )
+{
+ if ( self-clone.image )
+ mlt_pool_release( self-clone.image );
+ self-clone.image = NULL;
+ if ( self-clone.alpha )
+ mlt_pool_release( self-clone.alpha );
+ self-clone.alpha = NULL;
+}
+
static void load_filenames( producer_pixbuf self, mlt_properties producer_properties );
static void refresh_image( producer_pixbuf self, mlt_frame frame, int width, int height );
static int producer_get_frame( mlt_producer parent, mlt_frame_ptr frame, int index );
@@ -391,6 +407,7 @@ static void refresh_image( producer_pixbuf self, mlt_frame frame, int width, int
int dst_stride = self-width * ( self-alpha ? 4 : 3 );
int image_size = dst_stride * ( height + 1 );
self-image = mlt_pool_alloc( image_size );
+ clean_clone( self );
if ( src_stride != dst_stride )
{
@@ -454,7 +471,8 @@ static void refresh_image( producer_pixbuf self, mlt_frame frame, int width, int
static int producer_get_image( mlt_frame frame, uint8_t **buffer, mlt_image_format *format, int *width, int *height, int writable )
{
int error = 0;
-
+ mlt_image_format format_origin;
+
// Obtain properties of frame
mlt_properties properties = MLT_FRAME_PROPERTIES( frame );
@@ -472,20 +490,55 @@ static int producer_get_image( mlt_frame frame, uint8_t **buffer, mlt_image_form
// Get width and height (may have changed during the refresh)
*width = self-width;
*height = self-height;
- *format = self-alpha ? mlt_image_rgb24a : mlt_image_rgb24;
+ format_origin = self-alpha ? mlt_image_rgb24a : mlt_image_rgb24;
+ if ( mlt_image_none == *format)
+ *format = format_origin;
// NB: Cloning is necessary with this producer (due to processing of images ahead of use)
// The fault is not in the design of mlt, but in the implementation of the pixbuf producer...
if ( self-image )
{
- // Clone the image
- int image_size = self-width * self-height * ( self-alpha ? 4 :3 );
- uint8_t *image_copy = mlt_pool_alloc( image_size );
- memcpy( image_copy, self-image, image_size );
- // Now update properties so we free the copy after
- mlt_frame_set_image( frame, image_copy, image_size, mlt_pool_release );
- // We're going to pass the copy on
- *buffer = image_copy;
+ int size;
+ uint8_t* image;
+
+ if ( self-clone.image self-clone.format == *format)
+ {
+ image = mlt_pool_alloc( self-clone.image_size );
+ memcpy( image, self-clone.image, self-clone.image_size );
+ mlt_frame_set_image( frame, image, self-clone.image_size, mlt_pool_release );
+ *buffer = image;
+ if ( self-clone.alpha )
+ {
+image = mlt_pool_alloc( self-clone.alpha_size );
+memcpy( image, self-clone.alpha, self-clone.alpha_size );
+mlt_frame_set_alpha( frame, image, self-clone.alpha_size, mlt_pool_release );
+ };
+ }
+ else
+ {
+ clean_clone( self );
+ size = self-width * self-height * ( self-alpha ? 4 :3 );
+ image = mlt_pool_alloc( size );
+ memcpy( image, self-image, size );
+ if(frame-convert_image format_origin != *format)
+ {
+frame-convert_image( frame, image, format_origin, *format );
+*format = format_origin;
+ }
+ mlt_frame_set_image( frame, image, size, mlt_pool_release );
+ *buffer = image;
+ self-clone.format = *format;
+ self-clone.image_size = mlt_image_format_size( *format, *width, *height, NULL );
+ self-clone.image = mlt_pool_alloc( self-clone.image_size );
+ memcpy(self-clone.image, image, self-clone.image_size);
+ image = mlt_frame_get_alpha_mask(frame);
+ if ( image )
+ {
+self-clone.alpha_size = (*width) * (*height);
+self-clone.alpha = mlt_pool_alloc( self-clone.alpha_size );
+memcpy(self-clone.alpha, image, self-clone.alpha_size);
+ };
+ }
Re: [Mlt-devel] Fwd: Bug#660183: kdenlive: rendered video haslost red when taken some sources
On Fri, Feb 17, 2012 at 12:32 AM, Patrick Matthäi pmatth...@debian.org wrote:
Hi Dan,
this sounds like another libav issue, or not?
My libav bugzilla ticket was marked as fixed, but I have not confirmed
it. I could not completely fix the problem in MLT, I could only try to
prevent it. There might be some compositions that trigger the problem
still, but for just playing/transcoding a single video or playlist, I
do not reproduce the problem with my MLT change.
Original-Nachricht
hiya
downloaded the 7.8 from sid and isntalled them but still no red in the
videos
On 17 February 2012 08:12, Patrick Matthäi pmatth...@debian.org
mailto:pmatth...@debian.org wrote:
Am 17.02.2012 09:05, schrieb Dick William Thomas:
Package: kdenlive
Version: 0.8.2.1-1
Severity: important
Dear Maintainer,
* I've been using kdenlive or months with out issue and
today reinstalled
wheezy with out debian multimedia repo as I wanted a more pure
debian also
ffmpeg now support x264
I've found video's rendered from a source that has a windowed
screen capture
are green
* What exactly did you do (or not do) that was effective (or
ineffective)?
I recorded two videos using ffmpeg then rendered them
one after the
other in a single video 1/2 the video has normal colour but the
windows part is
lost it's red.
I think the problem is melt as I also tried it with openshot and
it had the
same outcome
and when kdenlive is run from the command line the out put says
it's sending it
to melt
I recoreded the videos using
#FULL SCREEN
ffmpeg -f alsa -ac 2 -i pulse -f x11grab -r 30 -s $(xwininfo
-root | grep
'geometry' | awk '{print $2;}') -i :0.0+0,0 -acodec libvorbis
-ab 128k -ac 2
-vcodec libx264 -crf 0 -threads 0 -baseName-fullscreen.avi
#WINDOWED
INFO=$(xwininfo -frame)
WIN_GEO=$(echo $INFO | grep -oEe 'geometry [0-9]+x[0-9]+' | grep
-oEe
'[0-9]+x[0-9]+')
WIN_XY=$(echo $INFO | grep -oEe 'Corners:\s+\+[0-9]+\+[0-9]+' |
grep -oEe
'[0-9]+\+[0-9]+' | sed -e 's/\+/,/' )
ffmpeg -f alsa -ac 2 -i pulse -f x11grab -r 30 -s $WIN_GEO -i
:0.0+$WIN_XY
-acodec libvorbis -ab 128k -ac 2 -vcodec libx264 -vf
scale=720:432 -threads 0
-y baseName-windowed.avi
the output is in this download along with the rendered finish
product
http://dl.dropbox.com/u/__302701/kdenlive-bug.tar.gz
http://dl.dropbox.com/u/302701/kdenlive-bug.tar.gz
Could you try out mlt 0.7.8?
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Mlt-devel mailing list
Mlt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlt-devel
