Thread: [Mlt-devel] melt / kdenlive just crashes after startup on PPC [solved] [hackfixed]
Brought to you by:
ddennedy,
lilo_booter
From: Christoph <cr...@u-...> - 2009-08-28 16:30:45
|
Hi! I tried to make kdenlive running on my debian - PPC machine. It just crashes after the setup wizzard. I saw a lot of user posts in the net about that .... This happens on my machine running melt, latest version from git (0.4.5 + x), latest ffmpeg (see below) gdb melt some_movie.avi .... [producer avformat] /home/chris/brain/b4.avi pkt.dts 1 req_pos 0 cur_pos -1 pkt_pos 1 got_pic 208 key 0 [filter gtkrescale] 576x432 -> 720x576 (yuv422) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x4931a4d0 (LWP 25272)] 0x0ff88768 in pthread_mutex_lock () from /lib/libpthread.so.0 (gdb) bt #0 0x0ff88768 in pthread_mutex_lock () from /lib/libpthread.so.0 #1 0x0ffd8114 in pool_return (ptr=0x493d5028) at mlt_pool.c:187 #2 0x0ffd857c in mlt_pool_release (release=0x493d5028) at mlt_pool.c:381 #3 0x0ffc7378 in mlt_property_set_data (this=0x1015e950, value=0x49456028, length=830880, destructor=0xffd8564 <mlt_pool_release>, serialiser=0) at mlt_property.c:107 #4 0x0ffc9120 in mlt_properties_set_data (this=0x1015b640, name=0xe9ff678 "image", value=0x49456028, length=830880, destroy=0xffd8564 <mlt_pool_release>, serialise=0) at mlt_properties.c:915 #5 0x0e9fc818 in filter_scale (this=0x1015b640, image=0x49319d04, format=<value optimized out>, iwidth=576, iheight=432, owidth=720, oheight=576) at filter_rescale.c:65 #6 0x0caaeb64 in filter_get_image (this=0x1015b640, image=0x49319d04, format=0x10072b64, width=0x49319b58, height=0x49319b5c, writable=0) at filter_rescale.c:228 #7 0x0ffc44bc in mlt_frame_get_image (this=0x1015b640, buffer=0x49319d04, format=0x10072b64, width=0x49319b58, height=0x49319b5c, writable=0) at mlt_frame.c:276 #8 0x0caaee00 in filter_get_image (this=0x1015b640, image=0x49319d04, format=0x10072b64, width=0x49319ce8, height=0x49319cec, writable=0) at filter_resize.c:260 #9 0x0ffc44bc in mlt_frame_get_image (this=0x1015b640, buffer=0x49319d04, format=0x10072b64, width=0x49319ce8, height=0x49319cec, writable=0) at mlt_frame.c:276 #10 0x0ffd6950 in producer_get_image (this=0x1015aa98, buffer=0x49319d04, format=0x10072b64, width=0x49319ce8, height=0x49319cec, writable=0) at mlt_tractor.c:274 #11 0x0ffc44bc in mlt_frame_get_image (this=0x1015aa98, buffer=0x49319d04, format=0x10072b64, width=0x49319ce8, height=0x49319cec, writable=0) at mlt_frame.c:276 #12 0x0ffd408c in consumer_read_ahead_thread (arg=<value optimized out>) at mlt_consumer.c:628 #13 0x0ff86e34 in start_thread () from /lib/libpthread.so.0 #14 0x0fee2ab0 in clone () from /lib/libc.so.6 Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) up #1 0x0ffd8114 in pool_return (ptr=0x493d5028) at mlt_pool.c:187 (gdb) l 173 168 * 169 * \private \memberof mlt_pool_s 170 * \param ptr an opaque pointer 171 */ 172 173 static void pool_return( void *ptr ) 174 { 175 // Sanity checks 176 if ( ptr != NULL ) 177 { (gdb) 178 // Get the release pointer 179 mlt_release that = ( void * )(( char * )ptr - sizeof( struct mlt_release_s )); 180 181 // Get the pool 182 mlt_pool this = that->pool; 183 184 if ( this != NULL ) 185 { 186 // Lock the pool 187 pthread_mutex_lock( &this->lock ); (gdb) p *this Cannot access memory at address 0x24842d80 (gdb) p this $1 = (mlt_pool) 0x24842d80 (gdb) p *that $2 = {pool = 0x24842d80, references = 897856640} (gdb) p that $3 = (mlt_release) 0x493d5020 (gdb) x/16x that-4 0x493d5000: 0x00000000 0x00081002 0x00000000 0x00000000 0x493d5010: 0x00000000 0x00000000 0x00000018 0x00080fea 0x493d5020: 0x24842d80 0x35843480 0x2e852a80 0x2a862b80 0x493d5030: 0x2c872b80 0x2b872a80 0x2a872b80 0x2b872c80 (gdb) This looks like overwritten!!! What happened? I installed ffmpeg via 'apt-get source' version 4:0.5+svn20090609-2 The debian packages of libav* now ships in two flavours: /usr/lib/libavcodec.so.52.20.0 /usr/lib/altivec/libavcodec.so.52.20.0 So, now I compile latest libmlt which uses the altivec optimized libs: melt and kdenlive just crash. Note about using altivec: <b> Data must be aligned in memory on 16 byte boundaries. </b> This is also true for other cpu features like mmx and sse !!! So we crash on the fancy pointer arithmetic in mlt_pool.c feeding altivec/libavcodec.so.52.20.0 with memory from: mlt_release release = memalign( 16, this->size ); ptr = ( char * )release + sizeof( struct mlt_release_s ); I attached a quick and dirty hack which padds the struct mlt_release_s to 16 bytes. That works for me. U must add these compiler flags: -mcpu=7450 -mpowerpc-gfxopt -maltivec -mabi=altivec cu on kdenlive ML ;P |
From: Christoph R. <ch...@u-...> - 2009-08-29 15:11:43
|
mh ... and there is another bug: src/framework/mlt_pool.c @@ -266,7 +278,7 @@ void *mlt_pool_alloc( int size ) int index = 8; // Minimum size pooled is 256 bytes - size = size + sizeof( mlt_release ); + size = size + sizeof( struct mlt_release_s ); while ( ( 1 << index ) < size ) index ++; chris |
From: Dan D. <da...@de...> - 2009-08-29 20:18:52
|
On Sat, Aug 29, 2009 at 8:11 AM, Christoph Rudorff<ch...@u-...> wrote: > mh ... and there is another bug: > > src/framework/mlt_pool.c > > @@ -266,7 +278,7 @@ void *mlt_pool_alloc( int size ) > int index = 8; > > // Minimum size pooled is 256 bytes > - size = size + sizeof( mlt_release ); > + size = size + sizeof( struct mlt_release_s ); > while ( ( 1 << index ) < size ) > index ++; > very good catch. your patches are applied. -- +-DRD-+ |
From: Christoph R. <ch...@u-...> - 2009-08-29 22:52:43
|
Hi Dan! I do assembly but I don't x86. So I read about SSE (wikipedia) it seems that it needs alignment, too. So I would remove the #ifdef and make it default. And I remembered the correct gcc macro: // align to 16 byte in case we toss buffers to external assembly // optimized libraries (sse/altivec) // // I don't start a flame war about pointer arithmetics here. typedef struct __attribute__ ((aligned (16))) mlt_release_s { mlt_pool pool; int references; } *mlt_release; So u are also into kdenlive? So far it's running stable here ;) but there are some "little" endian issues: false colors in the gui. Are there any handcoded color conversations yuv->rgb in mlt or kdenlive or are they _all_ done by other libraries? greets from Amsterdam chris Dan Dennedy schrieb: > On Sat, Aug 29, 2009 at 8:11 AM, Christoph Rudorff<ch...@u-...> wrote: >> mh ... and there is another bug: >> >> src/framework/mlt_pool.c >> >> @@ -266,7 +278,7 @@ void *mlt_pool_alloc( int size ) >> int index = 8; >> >> // Minimum size pooled is 256 bytes >> - size = size + sizeof( mlt_release ); >> + size = size + sizeof( struct mlt_release_s ); >> while ( ( 1 << index ) < size ) >> index ++; >> > > very good catch. your patches are applied. > |
From: Dan D. <da...@de...> - 2009-08-29 23:40:05
|
On Sat, Aug 29, 2009 at 3:52 PM, Christoph Rudorff<ch...@u-...> wrote: > Hi Dan! > > I do assembly but I don't x86. So I read about SSE (wikipedia) it seems > that it needs alignment, too. So I would remove the #ifdef and make it Agreed. It will not hurt. > default. And I remembered the correct gcc macro: > > > // align to 16 byte in case we toss buffers to external assembly > // optimized libraries (sse/altivec) > // > // I don't start a flame war about pointer arithmetics here. > > typedef struct __attribute__ ((aligned (16))) mlt_release_s { > mlt_pool pool; > int references; > } > *mlt_release; > > > So u are also into kdenlive? So far it's running stable here ;) but there Yes > are some "little" endian issues: false colors in the gui. If you can explain more, I can help direct you more to the problem area. If you say, "GUI" then to me it means not in the rendered/shown video - like perhaps misinterpretation of a color value. > Are there any handcoded color conversations yuv->rgb in mlt or kdenlive or > are they _all_ done by other libraries? Mostly in MLT. see src/modules/core/filter_imageconvert.c. Most operations are done byte-wise, so should be safe. MLT defines mlt_image_rgb24 to be literally R8 G8 B8, and mlt_image_rgb24a as R8 G8 B8 A8. When interfacing with some libs, it is not always clear what you are working with. Such libs include libavcodec, gtk2, qt, and frei0r. In src/framework/mlt_property.c:mlt_property_atoi() there is a conversion from color string value to an int that might be used in various places. > greets from Amsterdam > > chris > Thank you for your help. > > Dan Dennedy schrieb: >> On Sat, Aug 29, 2009 at 8:11 AM, Christoph Rudorff<ch...@u-...> wrote: >>> mh ... and there is another bug: >>> >>> src/framework/mlt_pool.c >>> >>> @@ -266,7 +278,7 @@ void *mlt_pool_alloc( int size ) >>> int index = 8; >>> >>> // Minimum size pooled is 256 bytes >>> - size = size + sizeof( mlt_release ); >>> + size = size + sizeof( struct mlt_release_s ); >>> while ( ( 1 << index ) < size ) >>> index ++; >>> >> >> very good catch. your patches are applied. >> > -- +-DRD-+ |
From: Christoph R. <ch...@u-...> - 2009-08-30 01:13:39
|
Dan Dennedy schrieb: > please double-check my latest commit well, with the align attribute the __padding is no more necessary. One hack ought be enough ;) I should mention, that the __attribute__ is a gcc extension. If someone wants to compile that with M$VC or so ... About false colors in kdenlive ... a complete bug report would be off topic on this ML. I haven't tested everything yet. - Project Tree: all thumbs false colors - time line: thumbs of videos/images ok, color clips false - clip/project monitor: all colors ok, except color clips - render result: colors ok but the color clips are all false Hunting these bugs is not easy. Most annoying is the 100%CPU usage when kdenlive is idle and it's main window got focus: http://www.kdenlive.org/mantis/view.php?id=605 Smells like an endless signal/slot loop in qt/kde and it seems not every version is affected. chris > On Sat, Aug 29, 2009 at 3:52 PM, Christoph Rudorff<ch...@u-...> wrote: >> Hi Dan! >> >> I do assembly but I don't x86. So I read about SSE (wikipedia) it seems >> that it needs alignment, too. So I would remove the #ifdef and make it > > Agreed. It will not hurt. > >> default. And I remembered the correct gcc macro: >> >> >> // align to 16 byte in case we toss buffers to external assembly >> // optimized libraries (sse/altivec) >> // >> // I don't start a flame war about pointer arithmetics here. >> >> typedef struct __attribute__ ((aligned (16))) mlt_release_s { >> mlt_pool pool; >> int references; >> } >> *mlt_release; >> >> >> So u are also into kdenlive? So far it's running stable here ;) but there > > Yes > >> are some "little" endian issues: false colors in the gui. > > If you can explain more, I can help direct you more to the problem > area. If you say, "GUI" then to me it means not in the rendered/shown > video - like perhaps misinterpretation of a color value. > >> Are there any handcoded color conversations yuv->rgb in mlt or kdenlive or >> are they _all_ done by other libraries? > > Mostly in MLT. see src/modules/core/filter_imageconvert.c. Most > operations are done byte-wise, so should be safe. MLT defines > mlt_image_rgb24 to be literally R8 G8 B8, and mlt_image_rgb24a as R8 > G8 B8 A8. When interfacing with some libs, it is not always clear what > you are working with. Such libs include libavcodec, gtk2, qt, and > frei0r. In src/framework/mlt_property.c:mlt_property_atoi() there is a > conversion from color string value to an int that might be used in > various places. > >> greets from Amsterdam >> >> chris >> > > Thank you for your help. > >> Dan Dennedy schrieb: >>> On Sat, Aug 29, 2009 at 8:11 AM, Christoph Rudorff<ch...@u-...> wrote: >>>> mh ... and there is another bug: >>>> >>>> src/framework/mlt_pool.c >>>> >>>> @@ -266,7 +278,7 @@ void *mlt_pool_alloc( int size ) >>>> int index = 8; >>>> >>>> // Minimum size pooled is 256 bytes >>>> - size = size + sizeof( mlt_release ); >>>> + size = size + sizeof( struct mlt_release_s ); >>>> while ( ( 1 << index ) < size ) >>>> index ++; >>>> >>> very good catch. your patches are applied. >>> > > > |
From: jb <j-...@us...> - 2009-08-30 08:28:02
|
On Sunday 30 August 2009 03.13:25 Christoph Rudorff wrote: > - Project Tree: all thumbs false colors > - time line: thumbs of videos/images ok, color clips false > - clip/project monitor: all colors ok, except color clips > - render result: colors ok but the color clips are all false Hi! Which version of Kdenlive are you using? I just checked and it seems to me that the code for project tree and timeline thumbs is the same in current svn... About the color clips, you can check if the issue is in MLT by doing: melt colour resource=0xff0000ff (should play a red clip, 0x00ff00ff should be green and 0x0000ffff blue) If that works, than this is a bug in the way Kdenlive creates the color code. > Hunting these bugs is not easy. > Most annoying is the 100%CPU usage when kdenlive is idle and it's main > window got focus: > http://www.kdenlive.org/mantis/view.php?id=605 If I remember correctly, some of these high CPU usages were also related to older Qt / KDE versions. I really encourage you to use something like Qt 4.5.x and KDE 4.3 and Kdenlive 0.7.5 regards jb |
From: Christoph R. <ch...@u-...> - 2009-08-30 14:02:53
|
Hi! "melt color" displays correct colors! However, while running it in gdb I noticed internally it runs in yuv mode ... how to set up the consumer to run in rgb? (just to be sure that the color wasn't converted twice the false way) I compiled kdenlive from svn/trunk. My machine runs debian/lenny, libqt4 4.4.3-1 kdebase-runtime 4:4.1.0-2 Actually I need some more time to look into kdenlive ... chris ps: the RGB2YUV() in mlt looks correct. I used to debug kaffeine some time ago. This is how I had to fix it: unsigned int KXineWidget::rgb2yuv( unsigned int R, unsigned int G, unsigned int B ) { #if Q_BYTE_ORDER == Q_LITTLE_ENDIAN return ((((((66*R+129*G+25*B+128)>>8)+16)<<8)|(((112*R-94*G-18*B+128)>>8)+128))<<8|(((-38*R-74*G+112*B+128)>>8)+128)); #else return ((((((-38*R-74*G+112*B+128)>>8)+128)<<8)|(((112*R-94*G-18*B+128)>>8)+128))<<8|(((66*R+129*G+25*B+128)>>8)+16))<<8; #endif } jb schrieb: > On Sunday 30 August 2009 03.13:25 Christoph Rudorff wrote: > >> - Project Tree: all thumbs false colors >> - time line: thumbs of videos/images ok, color clips false >> - clip/project monitor: all colors ok, except color clips >> - render result: colors ok but the color clips are all false > > Hi! > > Which version of Kdenlive are you using? > I just checked and it seems to me that the code for project tree and timeline thumbs is the same in current svn... > About the color clips, you can check if the issue is in MLT by doing: > melt colour resource=0xff0000ff (should play a red clip, 0x00ff00ff should be green and 0x0000ffff blue) > > If that works, than this is a bug in the way Kdenlive creates the color code. > > > Hunting these bugs is not easy. >> Most annoying is the 100%CPU usage when kdenlive is idle and it's main >> window got focus: >> http://www.kdenlive.org/mantis/view.php?id=605 > > If I remember correctly, some of these high CPU usages were also related to older Qt / KDE versions. I really encourage you to use something like Qt 4.5.x and KDE 4.3 and Kdenlive 0.7.5 > > > regards > jb > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Mlt-devel mailing list > Mlt...@li... > https://lists.sourceforge.net/lists/listinfo/mlt-devel |
From: Dan D. <da...@de...> - 2009-08-30 18:31:08
|
On Sun, Aug 30, 2009 at 7:02 AM, Christoph Rudorff<ch...@u-...> wrote: > Hi! > > "melt color" displays correct colors! However, while running it in gdb I > noticed internally it runs in yuv mode ... how to set up the consumer to > run in rgb? (just to be sure that the color wasn't converted twice the > false way) > melt color:#ff0000 -consumer sdl_still uses RGB output. In MLT trunk, it will also cause the color producer to generate as RGB. If you add the -debug option to melt, then it will report information about color conversions. If you want to make color generate as yuv, but force a rgb conversion, then use: melt color:#ff0000 -filter gamma -consumer sdl_still The gamma filter only works in yuv space, so it will ask the color producer for yuv, but since the sdl_still asked for rgb, the framework converts it to rgb. Another handy test is to use the frei0r R, G, and B filters. 'melt color:red -filter frei0r.R' 'melt color:green -filter frei0r.G' 'melt color:blue -filter frei0r.B' should all cause white output -- +-DRD-+ |
From: Dan D. <da...@de...> - 2009-09-06 19:37:18
|
On Sun, Sep 6, 2009 at 7:51 AM, Christoph<cr...@u-...> wrote: > Dan Dennedy schrieb: >> I asked to please disregard frei0r, but you ran a bunch of tests with >> it and ask questions. I will not provide feedback on anything related >> to ppc and frei0r at this time. Please run the basic color test using >> the rgb sdl consumer as I suggested. > > I did. Maybe u missed this mail: > > http://sourceforge.net/mailarchive/message.php?msg_name=4AA2FD98.3020301%40u-club.de > > I did not underline the important, sry: > > The Question was if the color parser in mlt works on ppc. > Answer: yes. Ah, yes. I did not see if you had ever tried to use the sdl_still consumer, and it has been difficult to follow all of your mails especially when they involve frei0r and Kdenlive. I just want to help you in a more methodically bottom-up fashion because it is easy to get confused and miscommunicate. >> Which of the following works? >> >> melt color:red -consumer sdl_still >> melt color:#ff0000 -consumer sdl_still >> melt color:0xff0000ff -consumer sdl_still > > red > red > red I was thinking after I sent this that red is a poor choice because it is not really sensitve to byte order. When handled incorrectly, the alpha component as 0xff will be interpreted as red and the red component also 0xff as alpha, fully opaque. Just to be 100% sure, test blue: melt color:blue -consumer sdl_still melt color:#0000FF -consumer sdl_still melt color:0x0000FFFF -consumer sdl_still > I also tested the other sdl_* consumer, with default and with a blank > loader.ini : all ok great. I was going to ask testing with plain 'sdl' consumer next to introduce rgb24 -> yuv422 conversion. > So far I haven't found any color bugs in mlt, yet. OK, good, but I am confident "burningtv" effect is broken on big endian. I would like you to test image producers next using consumers sdl_still first, followed by sdl. melt pixbuf:some.png (or other image format, most supported) melt qimage:some.png melt avformat:some.png After that, please test the boxblur filter; it is suspicious: melt somevideo -fitler boxblur It should just be blurred with no color distortion. > Some color bugs in kdenlive disappeared when starting with a fresh project > file. The 'old' project file of the screenshot was opened, edited and > saved many times. Some color values lost the rightmost octet. Actually I > can't reproduce it. I made a 'git init' to track the changes of the > project files. > > melt color:0xff00ffff > magenta > > melt color:0xff00fff > green. (ppc/i386 !) > not pure green but it's green: 0xff00fff = 0x0ff00fff > > now look again at the screenshot .... that makes sense. yep! > If I cut off last octet I get the same false colors! > > So this is a kdenlive xml problem, > and there is a kdenlive <=> qt/kde problem with the thumbs. I will look around. > are u in #kdenlive channel? No. I quickly lose productivity with interruption. -- +-DRD-+ |
From: Christoph R. <ch...@u-...> - 2009-09-05 16:02:59
Attachments:
screenshot-rgb-ppc.png
|
Hi! Hunting color bugs is funny and confusing. I gave that mail a new topic. Some color problems have nothing to do to with endianess and this is not a bug report ... yet. ;) Meanwhile I returned home and now I can compare the stuff: i386 desktop vs powerbook G4 The last hours I played around with kdenlive, mlt, frei0r freej, frei0r all more or less fresh from git or svn. 1. frei0r.R,G,B are obviously broken. I checked the code. melt color:red -filter frei0r.R (and G,B): * ok on i386 (but why?) * but all broken on ppc in freej the frei0r,R,G,B works just like they are bugged: R and B effects are swapped (ppc and i386). Mh, do we care about the frei0r's color_model flag of F0R_COLOR_MODEL_BGRA8888 or F0R_COLOR_MODEL_RGBA8888 ? freej doesn't ... yet ;) 2. melt I am confused about filters. I can attach filters but there are some filters auto attached? How to stop xine.deinterlace? That makes a yuv transformation and that confuses me debugging. melt color:green -debug -silent [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 output: ppc/green, i386/green melt color:green -filter frei0r.G -silent -debug [filter frei0r.G] frei0r 720x576 [filter deinterlace] xine.deinterlace 0 prog 1 format rgb24a [filter imageconvert] rgb24a -> yuv422 [filter frei0r.G] frei0r 720x576 ... output: i386/white ppc/black melt color:green -filter gamma -silent -debug [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 where's the gamma filter? 3. kdenlive Mh, I hope I can attach a screenshot to the mail list ... let's see, here it becomes very confusing. It shows kdenlive from svn on ppc: 1. kb.avi is a b/w movie. It's 'selected' in the timeline. 2. color clip magenta, 2,3 are all defined as 0xff00ffff in the project file but they don't behave the same bugged or right way: * the magenta clip shown in project monitor appears green. * the magenta2 clip on the right in the timeline is magenta in the project monitor. So question is: is there somewhere a thumbnail cache? Any other cache I should delete? I'm going to open that file on i386 .... so long, chris Dan Dennedy schrieb: > On Sun, Aug 30, 2009 at 7:02 AM, Christoph Rudorff<ch...@u-...> wrote: >> Hi! >> >> "melt color" displays correct colors! However, while running it in gdb I >> noticed internally it runs in yuv mode ... how to set up the consumer to >> run in rgb? (just to be sure that the color wasn't converted twice the >> false way) >> > > melt color:#ff0000 -consumer sdl_still > > uses RGB output. In MLT trunk, it will also cause the color producer > to generate as RGB. > If you add the -debug option to melt, then it will report information > about color conversions. If you want to make color generate as yuv, > but force a rgb conversion, then use: > > melt color:#ff0000 -filter gamma -consumer sdl_still > > The gamma filter only works in yuv space, so it will ask the color > producer for yuv, but since the sdl_still asked for rgb, the framework > converts it to rgb. > > Another handy test is to use the frei0r R, G, and B filters. > > 'melt color:red -filter frei0r.R' > 'melt color:green -filter frei0r.G' > 'melt color:blue -filter frei0r.B' > should all cause white output > |
From: Dan D. <da...@de...> - 2009-09-05 21:04:01
|
On Sat, Sep 5, 2009 at 9:02 AM, Christoph Rudorff<ch...@u-...> wrote: > Hi! > > Hunting color bugs is funny and confusing. I gave that mail a new topic. > Some color problems have nothing to do to with endianess and this is not a > bug report ... yet. ;) > > Meanwhile I returned home and now I can compare the stuff: > i386 desktop vs powerbook G4 > > The last hours I played around with > > kdenlive, mlt, frei0r > freej, frei0r > > all more or less fresh from git or svn. > > 1. frei0r.R,G,B are obviously broken. I checked the code. > > melt color:red -filter frei0r.R (and G,B): > * ok on i386 (but why?) > * but all broken on ppc > > in freej the frei0r,R,G,B works just like they are bugged: R and B effects > are swapped (ppc and i386). > > Mh, do we care about the frei0r's color_model flag of > F0R_COLOR_MODEL_BGRA8888 or F0R_COLOR_MODEL_RGBA8888 ? freej > doesn't ...yet ;) That is a very good question. I see that while most frei0r filters use RGBA, some use BGRA, and for the ones using PACKED, it does not matter. However, I see the MLT frei0r filter does not do anything special. I did not make it, did not know about this frei0r field, and have overlooked it thus far in my dealings with it. I will investigate some more. > > 2. melt > > I am confused about filters. I can attach filters but there are some > filters auto attached? Typically, yes. The default producer is the 'loader' producer that uses file extension mapping to look for a suggested producer, failing over to avformat. It also attaches a set of "normalizing" filters as specified in loader.ini. This conforms all sources of video to the settings in the MLT profile. > How to stop xine.deinterlace? That makes a yuv The below messages show it is in a passive mode, but if you really want to exclude it comment out the appropriate line in loader.ini. > transformation and that confuses me debugging. > > melt color:green -debug -silent > > [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 >From xine/filter_deinterlace.c: if ( deinterlace && !progressive ) *format = mlt_image_yuv422; mlt_log_debug( MLT_FILTER_SERVICE( filter ), "xine.deinterlace %d prog %d format %s\n", deinterlace, progressive, mlt_image_format_name( *format ) ); ... if ( deinterlace && *format == mlt_image_yuv422 && *image && !progressive ) --- This means, it only actually deinterlaces and coerces the format to yuv422 when the debug message reads "deinterlace 1 prog 0." This means something else has requested yuv422. The default consumer is 'sdl' which is yuv422 only and the one asking for yuv422. As I already stated in two previous emails, you must use -consumer sdl_still to request rgb24. Alternatively, you can use -consumer sdl_preview which is a wrapper over 'sdl' and 'sdl_still' and will let you test yuv422 consumer requests while playing and rgb24 consumer requests while pausing and stepping frame-by-frame. > [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 > [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 > output: ppc/green, i386/green Good! > melt color:green -filter frei0r.G -silent -debug > [filter frei0r.G] frei0r 720x576 > [filter deinterlace] xine.deinterlace 0 prog 1 format rgb24a > [filter imageconvert] rgb24a -> yuv422 > [filter frei0r.G] frei0r 720x576 > ... > output: i386/white ppc/black I am going to take a closer look at all the info here and the code, do more analysis, and come back to this. > melt color:green -filter gamma -silent -debug > [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 > [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 > [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 > where's the gamma filter? Not all filters include logging messages. If you want to verify the gamma filter is really included and not silently excluded for some reason, then: melt ... -consumer xml. And make sure the XML shows it. > 3. kdenlive > > Mh, I hope I can attach a screenshot to the mail list ... let's see, here > it becomes very confusing. It shows kdenlive from svn on ppc: > > 1. kb.avi is a b/w movie. It's 'selected' in the timeline. Are you claiming there is a problem here? OK, it looks a little purplish on the timeline. Is that due to something in kdenlive "design?" And it looks tinted red in the Project Tree. Hmm, that does seem strange. > 2. color clip magenta, 2,3 are all defined as 0xff00ffff in the project > file but they don't behave the same bugged or right way: > * the magenta clip shown in project monitor appears green. Strange indeed. Furthermore, it appears correct in the timeline and appears yellow in the Project Tree! > * the magenta2 clip on the right in the timeline is magenta in the > project monitor. but appears cyan in the Project Tree?! > So question is: is there somewhere a thumbnail cache? Any other cache I > should delete? Yes there is for Kdenlive, but I do not know anything about it really other than it exists. JBM can help you. You definitely need to be able to delete the cache to debug further in kdenlive. It would also be nice if you can make a trivial code change and turn off caching. > I'm going to open that file on i386 .... > > so long, > > chris > > > > Dan Dennedy schrieb: >> On Sun, Aug 30, 2009 at 7:02 AM, Christoph Rudorff<ch...@u-...> wrote: >>> Hi! >>> >>> "melt color" displays correct colors! However, while running it in gdb I >>> noticed internally it runs in yuv mode ... how to set up the consumer to >>> run in rgb? (just to be sure that the color wasn't converted twice the >>> false way) >>> >> >> melt color:#ff0000 -consumer sdl_still >> >> uses RGB output. In MLT trunk, it will also cause the color producer >> to generate as RGB. >> If you add the -debug option to melt, then it will report information >> about color conversions. If you want to make color generate as yuv, >> but force a rgb conversion, then use: >> >> melt color:#ff0000 -filter gamma -consumer sdl_still >> >> The gamma filter only works in yuv space, so it will ask the color >> producer for yuv, but since the sdl_still asked for rgb, the framework >> converts it to rgb. >> >> Another handy test is to use the frei0r R, G, and B filters. >> >> 'melt color:red -filter frei0r.R' >> 'melt color:green -filter frei0r.G' >> 'melt color:blue -filter frei0r.B' >> should all cause white output >> > -- +-DRD-+ |
From: Christoph <cr...@u-...> - 2009-09-06 03:19:15
|
Hi Dan! Thanks for all the pointers. They will help debugging. So I continue from last mail. I opened the kdenlive project file made on ppc on i386: some things are ok, others are not. I don't send u a screenshot ... that will be too confusing unless u can click around in that mess :P ... it's just ... funny. Were there some fixes in the xml part lately? While playing on kdenlive-ppc, after making that screenshot I noticed yellow was set to 0xfffb00 (my me, accidently) I fixed that, diffing the saved files showed this: <producer in="0" out="124" id="5" > <property name="mlt_type" >producer</property> <property name="aspect_ratio" >0.000000</property> <property name="length" >15000</property> <property name="eof" >pause</property> - <property name="resource" >0xfffb00f</property> + <property name="resource" >0xffff00ff</property> <property name="mlt_service" >colour</property> + <property name="colour" >0xffff00ff</property> </producer> - <kdenlive_producer audio_max="0" channels="0" duration="125" default_audio="0" video_max="0" frame_size="352x288" frequency="0" in="0" aspect_ratio="0.000000" mlt_service="colour" out="124" type="4" colour="0xfffb00ff" id="5" name="yellow" default_video="0" /> + <kdenlive_producer audio_max="0" channels="0" duration="125" default_audio="0" video_max="0" frame_size="352x288" frequency="0" in="0" aspect_ratio="0.000000" mlt_service="colour" out="124" type="4" colour="0xffff00ff" id="5" name="yellow" default_video="0" /> Who ate the 'f'? And it does not explain the color shift. Can we still solve this with logic? So now I have problems reproducing the bugs ... something mixed up the project file while playing around. Let's start over. PPC: I found and deleted some cache trash in /var/tmp/..../kpc or so. I did not reinstall or recompiled not anything, no nothing!!1 I started with a fresh project on ppc. Surprise: color clips all work! ProjectTree: All thumbs are wrong (avi,png,color) clip/project monitors: all ok timeline: * the b/w avi is tinted in red or blue. Don't see any logic, yet. * png thumb wrong rendered file: ok :) i386: Then I opened that file on i386: ProjectTree: some thumbs of the color clip previews are broken. Funny: C,M,Y: ok R,G,B: false. They show up in white,white,black No other color bugs. "Reload clip" fixes the thumb. close kdenlive, opened it, load the _same_ _unmodified_ file from ppc again: all ok. So there is a caching problem. TODO: test title clips MLT: I ran some more color test. I feel like I have to sort all the mlt options to be sure not to see errors by mistake. So far I can say, the color value parser (#rrggbb 0xrrggbba etc.) of the color generator on ppc works. That was one of our main questions. I just played a bit now with frei0r plugins .... fancy buggy output. On both, i386 and ppc. Need a break now 8) too many colors chris Dan Dennedy schrieb: > On Sat, Sep 5, 2009 at 9:02 AM, Christoph Rudorff<ch...@u-...> wrote: >> Hi! >> >> Hunting color bugs is funny and confusing. I gave that mail a new topic. >> Some color problems have nothing to do to with endianess and this is not a >> bug report ... yet. ;) >> >> Meanwhile I returned home and now I can compare the stuff: >> i386 desktop vs powerbook G4 >> >> The last hours I played around with >> >> kdenlive, mlt, frei0r >> freej, frei0r >> >> all more or less fresh from git or svn. >> >> 1. frei0r.R,G,B are obviously broken. I checked the code. >> >> melt color:red -filter frei0r.R (and G,B): >> * ok on i386 (but why?) >> * but all broken on ppc >> >> in freej the frei0r,R,G,B works just like they are bugged: R and B effects >> are swapped (ppc and i386). >> >> Mh, do we care about the frei0r's color_model flag of >> F0R_COLOR_MODEL_BGRA8888 or F0R_COLOR_MODEL_RGBA8888 ? freej >> doesn't ...yet ;) > > That is a very good question. I see that while most frei0r filters use > RGBA, some use BGRA, and for the ones using PACKED, it does not > matter. However, I see the MLT frei0r filter does not do anything > special. I did not make it, did not know about this frei0r field, and > have overlooked it thus far in my dealings with it. I will investigate > some more. > >> 2. melt >> >> I am confused about filters. I can attach filters but there are some >> filters auto attached? > > Typically, yes. The default producer is the 'loader' producer that > uses file extension mapping to look for a suggested producer, failing > over to avformat. It also attaches a set of "normalizing" filters as > specified in loader.ini. This conforms all sources of video to the > settings in the MLT profile. > >> How to stop xine.deinterlace? That makes a yuv > > The below messages show it is in a passive mode, but if you really > want to exclude it comment out the appropriate line in loader.ini. > >> transformation and that confuses me debugging. >> >> melt color:green -debug -silent >> >> [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 > > From xine/filter_deinterlace.c: > > if ( deinterlace && !progressive ) > *format = mlt_image_yuv422; > mlt_log_debug( MLT_FILTER_SERVICE( filter ), "xine.deinterlace %d > prog %d format %s\n", > deinterlace, progressive, mlt_image_format_name( *format ) ); > ... > if ( deinterlace && *format == mlt_image_yuv422 && *image && !progressive ) > > --- > > This means, it only actually deinterlaces and coerces the format to > yuv422 when the debug message reads "deinterlace 1 prog 0." This means > something else has requested yuv422. The default consumer is 'sdl' > which is yuv422 only and the one asking for yuv422. As I already > stated in two previous emails, you must use -consumer sdl_still to > request rgb24. Alternatively, you can use -consumer sdl_preview which > is a wrapper over 'sdl' and 'sdl_still' and will let you test yuv422 > consumer requests while playing and rgb24 consumer requests while > pausing and stepping frame-by-frame. > >> [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 >> [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 >> output: ppc/green, i386/green > > Good! > >> melt color:green -filter frei0r.G -silent -debug >> [filter frei0r.G] frei0r 720x576 >> [filter deinterlace] xine.deinterlace 0 prog 1 format rgb24a >> [filter imageconvert] rgb24a -> yuv422 >> [filter frei0r.G] frei0r 720x576 >> ... >> output: i386/white ppc/black > > I am going to take a closer look at all the info here and the code, do > more analysis, and come back to this. > >> melt color:green -filter gamma -silent -debug >> [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 >> [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 >> [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 >> where's the gamma filter? > > Not all filters include logging messages. If you want to verify the > gamma filter is really included and not silently excluded for some > reason, then: melt ... -consumer xml. And make sure the XML shows it. > >> 3. kdenlive >> >> Mh, I hope I can attach a screenshot to the mail list ... let's see, here >> it becomes very confusing. It shows kdenlive from svn on ppc: >> >> 1. kb.avi is a b/w movie. It's 'selected' in the timeline. > > Are you claiming there is a problem here? OK, it looks a little > purplish on the timeline. Is that due to something in kdenlive > "design?" And it looks tinted red in the Project Tree. Hmm, that does > seem strange. > >> 2. color clip magenta, 2,3 are all defined as 0xff00ffff in the project >> file but they don't behave the same bugged or right way: >> * the magenta clip shown in project monitor appears green. > > Strange indeed. Furthermore, it appears correct in the timeline and > appears yellow in the Project Tree! > >> * the magenta2 clip on the right in the timeline is magenta in the >> project monitor. > > but appears cyan in the Project Tree?! > >> So question is: is there somewhere a thumbnail cache? Any other cache I >> should delete? > > Yes there is for Kdenlive, but I do not know anything about it really > other than it exists. JBM can help you. You definitely need to be able > to delete the cache to debug further in kdenlive. It would also be > nice if you can make a trivial code change and turn off caching. > >> I'm going to open that file on i386 .... >> >> so long, >> >> chris >> >> >> >> Dan Dennedy schrieb: >>> On Sun, Aug 30, 2009 at 7:02 AM, Christoph Rudorff<ch...@u-...> wrote: >>>> Hi! >>>> >>>> "melt color" displays correct colors! However, while running it in gdb I >>>> noticed internally it runs in yuv mode ... how to set up the consumer to >>>> run in rgb? (just to be sure that the color wasn't converted twice the >>>> false way) >>>> >>> melt color:#ff0000 -consumer sdl_still >>> >>> uses RGB output. In MLT trunk, it will also cause the color producer >>> to generate as RGB. >>> If you add the -debug option to melt, then it will report information >>> about color conversions. If you want to make color generate as yuv, >>> but force a rgb conversion, then use: >>> >>> melt color:#ff0000 -filter gamma -consumer sdl_still >>> >>> The gamma filter only works in yuv space, so it will ask the color >>> producer for yuv, but since the sdl_still asked for rgb, the framework >>> converts it to rgb. >>> >>> Another handy test is to use the frei0r R, G, and B filters. >>> >>> 'melt color:red -filter frei0r.R' >>> 'melt color:green -filter frei0r.G' >>> 'melt color:blue -filter frei0r.B' >>> should all cause white output >>> > > > |
From: jb <j-...@us...> - 2009-09-06 14:04:20
|
On Saturday 05 September 2009 22.03:47 you wrote: > On Sat, Sep 5, 2009 at 9:02 AM, Christoph Rudorff<ch...@u-...> wrote: > > So question is: is there somewhere a thumbnail cache? Any other cache I > > should delete? > > Yes there is for Kdenlive, but I do not know anything about it really > other than it exists. JBM can help you. You definitely need to be able > to delete the cache to debug further in kdenlive. It would also be > nice if you can make a trivial code change and turn off caching. Kdenlive caches project tree thumbnails in the project's folder, under a "thumbs" folder. If I remember correctly, I fixed a bug in thumbnails not so long ago that caused all color clips to use the same file for caching, resulting in random thumbs, so if you can, please use latest svn. By default, the project folder is $HOME/kdenlive, so the thumbnails are probably cached in: $HOME/kdenlive/thumbs. If you want to disable thumbs caching, you can simply comment out these lines, around line 527 of projectlist.cpp, in void ProjectList::slotAddClip(DocClipBase *clip, bool getProperties) if (QFile::exists(cachedPixmap)) { item->setIcon(0, QPixmap(cachedPixmap)); } regards jb |
From: Dan D. <da...@de...> - 2009-09-05 23:20:29
|
On Sat, Sep 5, 2009 at 2:03 PM, Dan Dennedy<da...@de...> wrote: > On Sat, Sep 5, 2009 at 9:02 AM, Christoph Rudorff<ch...@u-...> wrote: >> melt color:green -debug -silent >> [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 >> [filter deinterlace] xine.deinterlace 0 prog 1 format yuv422 >> output: ppc/green, i386/green > > Good! This means rgb24 -> yuv422 conversion is ok. Run this test using -consumer sdl_still to verify the color generator is correct. >> melt color:green -filter frei0r.G -silent -debug >> [filter frei0r.G] frei0r 720x576 >> [filter deinterlace] xine.deinterlace 0 prog 1 format rgb24a >> [filter imageconvert] rgb24a -> yuv422 >> [filter frei0r.G] frei0r 720x576 >> ... >> output: i386/white ppc/black > > I am going to take a closer look at all the info here and the code, do > more analysis, and come back to this. Run this test using -consumer sdl_still to eliminate rgb24a -> yuv422 as a potential source of error. -- +-DRD-+ |
From: Dan D. <da...@de...> - 2009-09-06 02:20:14
|
On Sat, Sep 5, 2009 at 4:20 PM, Dan Dennedy<da...@de...> wrote: > On Sat, Sep 5, 2009 at 2:03 PM, Dan Dennedy<da...@de...> wrote: >> On Sat, Sep 5, 2009 at 9:02 AM, Christoph Rudorff<ch...@u-...> wrote: >>> >>> melt color:green -filter frei0r.G -silent -debug >>> >>> [filter frei0r.G] frei0r 720x576 >>> [filter deinterlace] xine.deinterlace 0 prog 1 format rgb24a >>> [filter imageconvert] rgb24a -> yuv422 >>> [filter frei0r.G] frei0r 720x576 >>> ... >>> output: i386/white ppc/black >> >> I am going to take a closer look at all the info here and the code, do >> more analysis, and come back to this. > > Run this test using -consumer sdl_still to eliminate rgb24a -> yuv422 > as a potential source of error. Disregard this test. Upon reviewing the B, G, and R frei0r filters, I see they are not endian-safe because they access the memory as uint32_t and use a bitmask to access individual color components without anything to address byte order. Regarding the different frei0r color models, nearly all use F0R_COLOR_MODEL_RGBA8888, which the header clearly states: ...the first byte value represents the red, the second the green, and the third the blue color component of the pixel. The last value represents the alpha value. This is exactly the same as MLT's rgba. Yet, when you look at something like saturat0r.c, which is RGBA, it is clearly wrong: const unsigned char* src = (unsigned char*)inframe; b = *src++; g = *src++; r = *src++; ... *dst++ = *src++; // copy alpha Then, you look at cluster.c, which says it is BGRA. It uses unsigned char pointer access as well, but then treats the first byte as R, second as G, and third as B. Next, looking at colordistance.c, which is RGBA, and also uses unsigned char pointer access, but correctly treats first as R, second as G, third as B, and fourth as alpha. Many of them seem to work fine because they really ought to indicate PACKED32 and do not care. Surely, there are some that do not care about individual color components, but the potential danger is which component they treat as alpha when not using byte pointer. In summary, Christoph, to make the debugging easier for now, please do not use the frei0r filters because many of them are not endian-safe. I need to review all of them as a separate project. -- +-DRD-+ |
From: Christoph <cr...@u-...> - 2009-09-06 02:50:33
|
Dan Dennedy schrieb: > On Sat, Sep 5, 2009 at 4:20 PM, Dan Dennedy<da...@de...> wrote: >> On Sat, Sep 5, 2009 at 2:03 PM, Dan Dennedy<da...@de...> wrote: >>> On Sat, Sep 5, 2009 at 9:02 AM, Christoph Rudorff<ch...@u-...> wrote: >>>> melt color:green -filter frei0r.G -silent -debug >>>> >>>> [filter frei0r.G] frei0r 720x576 >>>> [filter deinterlace] xine.deinterlace 0 prog 1 format rgb24a >>>> [filter imageconvert] rgb24a -> yuv422 >>>> [filter frei0r.G] frei0r 720x576 >>>> ... >>>> output: i386/white ppc/black >>> I am going to take a closer look at all the info here and the code, do >>> more analysis, and come back to this. >> Run this test using -consumer sdl_still to eliminate rgb24a -> yuv422 >> as a potential source of error. > > Disregard this test. Upon reviewing the B, G, and R frei0r filters, I > see they are not endian-safe because they access the memory as > uint32_t and use a bitmask to access individual color components > without anything to address byte order. > > Regarding the different frei0r color models, nearly all use > F0R_COLOR_MODEL_RGBA8888, which the header clearly states: > > ...the first byte value represents the red, the second the green, and the > third the blue color component of the pixel. The last value represents > the alpha value. > > This is exactly the same as MLT's rgba. Yet, when you look at > something like saturat0r.c, which is RGBA, it is clearly wrong: > > const unsigned char* src = (unsigned char*)inframe; > b = *src++; > g = *src++; > r = *src++; > ... > *dst++ = *src++; // copy alpha > > Then, you look at cluster.c, which says it is BGRA. It uses unsigned > char pointer access as well, but then treats the first byte as R, > second as G, and third as B. > > Next, looking at colordistance.c, which is RGBA, and also uses > unsigned char pointer access, but correctly treats first as R, second > as G, third as B, and fourth as alpha. > > Many of them seem to work fine because they really ought to indicate > PACKED32 and do not care. Surely, there are some that do not care > about individual color components, but the potential danger is which > component they treat as alpha when not using byte pointer. > > In summary, Christoph, to make the debugging easier for now, please do > not use the frei0r filters because many of them are not endian-safe. I > need to review all of them as a separate project. 100% ack on that. All frei0rs needs a review. As I said im my last mail, I have to become more familar with mlt options to exclude other sources of errors. However, the sobel and the colordistance filter in freej on ppc look much more fancy then on i386: b/w movies get fancy colors :P In freej color bugs show up as expected. But on ppc "melt -filter frei0r.sobel some.avi" works correct *) ! Same output as on i386. melt b0.avi -filter frei0r.colordistance just crashes on ppc :( chris *) running 'out of the box' w/o loader.ini hacks ... melt b0.avi -filter frei0r.sobel -silent -debug [producer avformat] b0.avi pkt.dts 27 req_pos 27 cur_pos 22 pkt_pos 27 got_pic 208 key 0 [filter imageconvert] yuv422 -> rgb24a [filter gtkrescale] 576x432 -> 720x576 (rgb24a) [filter imageconvert] rgb24a -> yuv422 [filter frei0r.sobel] frei0r 720x576 [filter deinterlace] xine.deinterlace 1 prog 0 format yuv422 [producer avformat] b0.avi did it fed sobel with yuv?! |