Re: Playing MPEG with 1_rc0a-0 badly broken on PPC (all pink video)

On Fri, 8 Aug 2003, I wrote:

> On Fri, 08 Aug 2003, James Courtier-Dutton wrote:
> 
> > Bill Fink wrote:
> > > 
> > > On Fri, 8 Aug 2003, Michael Roitzsch wrote:
> > > 
> > >>>>Considering that this is the first release candidate for 1.0, I was
> > >>>>hoping to get some feedback on why playing MPEG streams on PPC
> > >>>>might suddenly have stopped working.  Oh well, I have gone back to
> > >>>>1_beta12 for now since that works just fine.
> > >>>
> > >>>do you mean any mpeg stream or some in particular?
> > >>>i can't test PPC, but i might try disabling acceleration or something
> > >>>to see if i can reproduce it.
> > > 
> > > It does it on all three sample MPEGs I have, the xine logo, and a
> > > DVD I tried.
> > > 
> > >>You could also try forcing different MPEG-capable demuxer by adding 
> > >>"#demux:<demuxer id>". Currently there are "elem", "mpeg", "mpeg_block" 
> > >>and "mpeg_pes". Some of them might not work at all for your file, some 
> > >>might play video only and some might have endian bugs...
> > > 
> > > mpeg, mpeg_block, and mpeg_pes all have the same broken result, namely
> > > the totally pink video.  elem is different but even worse, with no audio,
> > > extreme blockiness, and tons of error messages like:
> > > 
> > > libmpeg2: stream not demultiplexed ?
> > > 
> > > It would be useful to have datapoints from other PPC users.  I'll
> > > check a different type of PPC system at work to see if that makes
> > > any difference.
> > > 
> > Can you try taking a snapshot of the output and post the url for it here.
> > Is the whole display pink, of is it just a pink tinge to all the video.
> 
> I'm attaching a snapshot of the xine logo (it's only about 20KB).

After much investigation, I traced the problem to the following change
made on July 12:

--------------------------------------------------------------------------------
diff -ur xine-lib-07120306.dist/configure.ac xine-lib-07120312.dist/configure.ac
--- xine-lib-07120306.dist/configure.ac 2003-07-11 12:36:22.000000000 -0400
+++ xine-lib-07120312.dist/configure.ac 2003-07-12 08:31:14.000000000 -0400
@@ -930,6 +930,13 @@
     dnl
     ANSI_FLAGS="-std=gnu89"
     AC_SUBST(ANSI_FLAGS)
+    dnl
+    dnl Multipass compilation
+    dnl
+    AC_TRY_CFLAGS("-fprofile-arcs", PASS1_CFLAGS="$PASS1_CFLAGS 
-fprofile_arcs",)
+    AC_TRY_CFLAGS("-fbranch-probabilities", PASS2_CFLAGS="$PASS2_CFLAGS 
-fbranch-probabilities",)
+    AC_SUBST(PASS1_CFLAGS)
+    AC_SUBST(PASS2_CFLAGS)
 fi
 
 dnl Flags not supported by all *cc* variants
@@ -937,7 +944,7 @@
 
 
 dnl Common cflags for all platforms
-CFLAGS="$CFLAGS $wall -D_REENTRANT -D_FILE_OFFSET_BITS=64 -DXINE_COMPILE"
+CFLAGS="$CFLAGS $wall -D_REENTRANT -D_FILE_OFFSET_BITS=64 -DXINE_COMPILE 
\$(MULTIPASS_CFLAGS)"
 DEBUG_CFLAGS="$DEBUG_CFLAGS $wall -D_REENTRANT -D_FILE_OFFSET_BITS=64 
-DXINE_COMPILE"
 
 enable_w32dll="no"
@@ -960,7 +967,9 @@
 
 
   i?86-*-linux* | i386-*-solaris* | i?86-* | k?-* | athlon-* | pentium*)
-    if test "$GCC" = yes; then
+    if test "$GCC" = yes -o "${CC##*/}x" = "iccx" ; then
+
+      if test "$GCC" = yes ; then
        dnl Check for gcc cpu optimization support
        AC_TRY_CFLAGS("-mcpu=i386", 
                sarchopt="-mcpu",
@@ -1031,7 +1040,15 @@
            fi
            ]
        fi
-
+      else
+       dnl we have the Intel compiler
+       CFLAGS="$CFLAGS -unroll -ipo -ipo_obj -O3"
+       PASS1_CFLAGS="$PASS1_CFLAGS -prof_genx -prof_dir 
\$(PWD)/\$(top_builddir)/"
+       PASS2_CFLAGS="$PASS2_CFLAGS -prof_use -prof_dir 
\$(PWD)/\$(top_builddir)/"
+       AC_SUBST(PASS1_CFLAGS)
+       AC_SUBST(PASS2_CFLAGS)
+      fi
+       
        dnl enable x86 specific parts of the code
        dnl
        dnl all of this stuff needs gcc/gas; it uses gnu c compiler extensions
diff -ur xine-lib-07120306.dist/Makefile.am xine-lib-07120312.dist/Makefile.am
--- xine-lib-07120306.dist/Makefile.am  2003-05-30 09:06:58.000000000 -0400
+++ xine-lib-07120312.dist/Makefile.am  2003-07-12 08:31:14.000000000 -0400
@@ -41,6 +41,13 @@
        @cd doc && $(MAKE) $@
 
 
+pass1:
+       @$(MAKE) MULTIPASS_CFLAGS='$(PASS1_CFLAGS)'
+
+pass2:
+       @$(MAKE) MULTIPASS_CFLAGS='$(PASS2_CFLAGS)'
+
+
 debug:
        @list='$(SUBDIRS)'; for subdir in $$list; do \
          (cd $$subdir && $(MAKE) $@) || exit;\
diff -ur xine-lib-07120306.dist/misc/Makefile.common 
xine-lib-07120312.dist/misc/Makefile.common
--- xine-lib-07120306.dist/misc/Makefile.common 2003-06-27 08:29:17.000000000 
-0400
+++ xine-lib-07120312.dist/misc/Makefile.common 2003-07-12 08:31:14.000000000 
-0400
@@ -13,6 +13,12 @@
          fi \
        fi
 
+pass1:
+       @$(MAKE) MULTIPASS_CFLAGS="$(PASS1_CFLAGS)"
+
+pass2:
+       @$(MAKE) MULTIPASS_CFLAGS="$(PASS2_CFLAGS)"
+
 debug:
        @$(MAKE) CFLAGS="$(DEBUG_CFLAGS)"
 
--------------------------------------------------------------------------------

By reverting this multipass compilation change, I get proper MPEG
video once again.  What is the point of this change anyway, and
should it really be the default behavior?  I am using the gcc 3.2.2-2a
compiler provided by YellowDog Linux 3.0 for PPC.

Further complicating matters was that many changes, including this
one, don't show up in the xine-cvslog web archive.

I don't know enough about the automake stuff to suggest a fix, but
hopefully someone who does can change things so that at least for
PPC it doesn't do the multipass compilation.

                                                -Bill


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01