2011-07-31

Compiling Transcode 1.1.6 and 1.2 in OS X

(express post, too much time spent on this but too much work spent to let it slip without benefitting someone else)

1.1.6 is not released, had to be hg-cloned. In fact, the repository looks like the 1.1.6 tag was at some moment added but then deleted?? That branch also has the latest video stabilization, no idea yet if it is also in 1.2

Can be compiled. Get the hg repository via hg itself, not one of the zip/bz/etc packaged from the website since the compilation scripts expect to find the .hg files. Read the README and INSTALL, you'll need to create the configure yourself (easy, just read)

I am using MacPorts, and even installed the included Transcode 1.1.5, so all the requirements are already installed. Most of the expected work was about configuring tne non-macports transcode to use the /opt dirtree.

(Incidentally: 1.1.5 has horribly mismatched documentation, I have had to resort to using strings and source code to understand what some of the utils were supposed to be doing and how. The wiki doesn´t help. Also, not really working some of the combinations of export module/codec blow up without saying anything, no idea if that's because of transcode itself or because of lame, ffmpeg versions, who knows. Also, seems to be accepted that mp4 container files can't be generated directly by Transcode. I am interested on using the video stabilization plugin, but I if I had known that the time invested would be this much, ...)

1.2's generation of configure uses a script named hgversion.sh, which doesn't work right and causes problems: the generated configure fails with
./configure: line 4: .: filename argument required
.: usage: . filename [arguments]
Inspection of the configure source shows that it was badly generated. configure.in uses echo -n blabla trying to output a "blabla" with no line feed. But echo in sh doesn't work like that, so the actual output is "-n blabla\n". (mhm, no, both sh and bash use /bin/echo but it behaves differently, interesting). Anyway: that's nasty, didn't anyone check it? And the errors it causes are insidious, I wasn't sure if those were status messages, warnings or plain errors. The easy fix is change the echo -n $1$HGVER for printf $1$HGVER .

Even after having fixed that, 2 telltale failed output strings remained (something like
configure.in:6: warning: AC_INIT: not a literal: -n 1.2.0-0a9d7c95b961
). But I could not find where they were coming from. No, configure.in:6 was not it, and I could not find any file which had cached the string or parts of it. Before the fix in hgversion.sh there were about 6 of those, after there were 2. Anyway, after some infructuous searching, I decided to try to go on... at least configure now worked and nothing exploded in a seemingly related way.

The ./configure line I used:
./configure --prefix=/opt/local --enable-libavcodec --enable-ffmpeg --enable-experimental --enable-statbuffer --enable-lame   --enable-xvid   --enable-x264   --enable-libquicktime   --enable-faac    --enable-libavformat --with-lame-prefix=/opt/local --with-lame-includes=/opt/local/include --with-xvid-prefix=/opt/local --with-xvid-includes=/opt/local/include --with-xvid-libs=/opt/local/lib --with-faac-prefix=/opt/local/bin --with-faac-includes=/opt/local/include --with-faac-libs=/opt/local/lib --disable-libdvdread --disable-libjpeg 

The xvid support is half-baked. I had to
export CC=I/opt/local/include
so the xvid support finally worked, since sometimes the --with-xvid-includes was left unused by the Makefile.

Incidentally, I think that also helped x264.

Transcode 1.2 has been seemingly abandoned for about 18 months now. The last post in the website says it should be about alpha quality, and that they were desperately looking for new developers...

The make failed because in a number of submakefiles the tcmodule libs  path was not being added to the linker. I fixed it by adding $(LIBTCMODULE_LIBS) whenever the linker failed (with errors like:
Undefined symbols:
  "_tc_module_info_match", referenced from:
      _tc_module_match in tcmp3cut.o
  "_tc_module_info_log", referenced from:
      _tc_module_show_info in tcmp3cut.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[2]: *** [tcmp3cut-1.2] Error 1

)

(note the "_tc_module_info_match": "tc_module_info_match" is a function in the "tcmodule-info" file in the "tcmodule" directory (sometimes Spotlight is useful! ;P). Then, note the "tcmp3cut": that was the part being compiled. Looking for it in the makefile showed that it was not including the $(LIBTCMODULE_LIBS), which was defined in the beginning of the file, but not being used as much as the rest of definitions)

The tools directory had worse problems. The tcstub.c file is used when compiling other files, and 4 definitions conflict with libtc.a. Since libtc  seems to be generic for all of Transcode and the stub seems to be less important, I guessed the stub versions of the definitions had to go. I commented them out (tc_new_video_frame, tc_new_audio_frame, tc_del_video_frame, tc_del_audio_frame).
The errors were like this:
ld: duplicate symbol _tc_new_video_frame in ../libtc/.libs/libtc.a(tcframes.o) and tcmodchain-1.2-tcstub.o

With that, it finally compiled.
Beware, make install is supposed to install in parallel to existing 1.1-line transcodes (the new files should have "-1.2" added to their names), but some files had the same name and got overwriten. Example: avifix.
Which is doubly insidious because the tools directory had those stub file problems, which make all the directory contents suspicious...

When I have a moment to check / compare the 1.1.5, 1.1.6 and 1.2, I'll try to leave a note.

No comments

Post a Comment