Successfully built HB with MinGW/MSYS (need help!)

Archive of historical development discussions
Discussions / Development has moved to GitHub
Forum rules
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.

*******************************
Post Reply
MichaelChou
Posts: 1
Joined: Mon Feb 18, 2013 4:03 am

Successfully built HB with MinGW/MSYS (need help!)

Post by MichaelChou » Mon Feb 18, 2013 6:48 am

I'm planning to add Intel QuickSync supoort to HandBrake. Intel Media SDK is currently available for Windows only. So it'll be nice to be able to compile HandBrake using MinGW/MSYS under Windows.
I did some hacks, and built it successfully. I am not too familiar with the configuration and building scripts, so I don't know how to properly modify the source code of HB and generate a patch. I'll describe the dirty hacks below, hoping someone can help with it.

1. I only built 64-bit version. But I think 32-bit version might work as well.

2. I use msys(w/ git,svn,wget) from here: http://sourceforge.net/projects/mingwbu ... -packages/
mingw-w64: http://sourceforge.net/projects/mingw-w ... z/download
Note: I'm builing 64-bit HB under 64-bit Windows. But MSYS is 32-bit only thus the config.guess script will detect the host as i686-pc-mingw32. There might be other workarounds, but I use a simple one here: just use a 32-bit mingw which support cross-compiling to win64 target.

3. make/configure.py need some changes due to the MinGW/MSYS environment:
line 387: Should remove conftest.exe instead of conftest under Windows.
line 411: Change '%s/config.guess' to 'sh %s/config.guess' since the script isn't an executable and can't be invoked by python directly.
line 1356~1377: The script won't find ar, cp, gcc, etc. under Windows, it must look for ar.exe, cp.exe, gcc.exe, etc. instead. So we must add *.exe to the names argument. For example, change ToolProbe( 'AR.exe', 'ar' ) to ToolProbe( 'AR.exe', 'ar', 'ar.exe' ).
After the above changes, you can successfully configure HB.

4. build/GNUmakefile need to change due to the backslash(\) in paths:
Just replace all backslashes(\) in this file with slashes(/).
Cause: Python os module will generate \ instead of / in paths under Windows because it's a Windows convention. Backslash in makefiles will not be a problem itself, but in this one there're variables like SRC/, BUILD/, etc. of which the define lines will end with backslashes. Backslash will be treated as a line-continuation character in this case, thus mess up these varibale value. In fact, Windows has no problem recognizing slashes(/) in paths, and even support mix use of / and \. So simply changing all backslashes or only the ones which is the last character of a line, to slashes, will do the trick.
A more elegant solution is modifying configure.py so that it will use slash instead of backslash in paths even under Windows.
Now, cd to build/ and type make to build HB.

5. 'cc not found' when compiling yasm
I examed build/contrib/yasm/yasm-1.2.0/Makefile and found that CC is properly set to (in my case) C:/dev/msys/mingw/bin/x86_64-w64-mingw32-GCC.exe -std=gnu99, but CCLD_FOR_BUILD and CC_FOR_BUILD is set to cc, which is obviously incorrect, especially considering I was cross-compiling.
I don't know why these two variables are not set correctly, I just change Makefile to get compiling continue.
Type make to continue building.

6. 'more than one -exported-symbols argument is not allowed' when linking fribidi
Edit build/contrib/fribidi/fribidi-0.19.2/lib/Makefile.am: remove -export-symbols-regex "^fribidi_.*" from libfribidi_la_LDFLAGS
Type make to continue building.

7. 'libmp4v2.a(mp4.o): undefined reference' when linking hb.dll and HandBrakeCLI.exe
These references are all in libstdc++. Becuase libmp4v2 is written in c++, and the building script use gcc wrapper to link hd.dll and HandBrakeCLI.exe, the option -lstdc++ is not implied. So we must explicitly add -lstdc++ or change to g++ wrapper.
These are what I did:
libhb/module.defs, insert before line 99: LIBHB.GCC.l += stdc++
test/module.defs, insert before line 36: TEST.GCC.l += stdc++
You can make these changes before building. Type make to continue building.

After all these hacks, you can successfully built HB. You'll find HandBrakeCLI.exe under build/ and hb.dll under build/libhb/.

Open win/CS/HandBrake10.sln using Visual Studio, change the configuration to Release|x64 (in my case), and build solution. Copy build/HandBrakeCLI.exe and build/libhb/hb.dll to win/CS/HandBrakeWPF/bin/ and all work is done.

The thing is I don't know how to get all the workarounds above into HandBrake source tree so that it won't need manual hacking everytime you compile and won't break compiling under other platforms. So anyone can help with this?

User avatar
Rodeo
HandBrake Team
Posts: 12209
Joined: Tue Mar 03, 2009 8:55 pm

Re: Successfully built HB with MinGW/MSYS (need help!)

Post by Rodeo » Mon Feb 18, 2013 3:49 pm

MichaelChou wrote:I'm planning to add Intel QuickSync supoort to HandBrake.
Stop right there. There is already someone from Intel working on this.

https://reviews.handbrake.fr/r/436/

Montago

Re: Successfully built HB with MinGW/MSYS (need help!)

Post by Montago » Tue Mar 19, 2013 6:01 pm

so... whats the status of QuickSync in Handbrake ?

User avatar
Rodeo
HandBrake Team
Posts: 12209
Joined: Tue Mar 03, 2009 8:55 pm

Re: Successfully built HB with MinGW/MSYS (need help!)

Post by Rodeo » Tue Mar 19, 2013 6:04 pm

It's being worked on. There will be a Windows-only nightly build at some point in the not too distant future.

Montago

Re: Successfully built HB with MinGW/MSYS (need help!)

Post by Montago » Tue Mar 19, 2013 6:06 pm

thanks man !

looking forward to see what kind of quality you can squeeze out of QS !

User avatar
s55
HandBrake Team
Posts: 9545
Joined: Sun Dec 24, 2006 1:05 pm

Re: Successfully built HB with MinGW/MSYS (need help!)

Post by s55 » Tue Mar 19, 2013 6:30 pm

There is very little you can tweak in terms of quality since there are only a handful of actual options you can pass to the encoder, most of which don't affect quality.

In other words, it's not going to be any better or worse than any other app that uses quicksync.

Montago

Re: Successfully built HB with MinGW/MSYS (need help!)

Post by Montago » Tue Mar 19, 2013 6:35 pm

According to this article: http://www.extremetech.com/computing/12 ... nscoding/5
The best possible quality from QS is done in Arcsoft Media Converter - while Cyberlink Media Espresso does a terrible job.

AMC seems to be acceptable ?

at least QS is super fast, so some benefits exist

I guess time will tell

User avatar
s55
HandBrake Team
Posts: 9545
Joined: Sun Dec 24, 2006 1:05 pm

Re: Successfully built HB with MinGW/MSYS (need help!)

Post by s55 » Tue Mar 19, 2013 6:44 pm

Might be using a low bit-rate or low resolution encode, but ultimately, they are all using the same SDK, so can get the same results if you use the same settings.

There isn't really much you can tweak at all. It's not like x264, it doesn't even have a quarter of the features.

gmb
Bright Spark User
Posts: 332
Joined: Thu Mar 28, 2013 12:49 pm

Re: Successfully built HB with MinGW/MSYS (need help!)

Post by gmb » Thu Mar 28, 2013 12:55 pm

s55 wrote:There is very little you can tweak in terms of quality since there are only a handful of actual options you can pass to the encoder, most of which don't affect quality.

In other words, it's not going to be any better or worse than any other app that uses quicksync.

But there are bigger quality differences between some QS encoders. The curent QS quality reference is Cyberlink Mediespresso with m2ts extension. (mp4 doesn't encode in high profile). Arcsoft Mediaconverter doesn't support high profile for QS and some others too. No other encoder can match Mediaespresso with m2ts encoding. Also some converters don't allow a very high bitrate.

gmb
Bright Spark User
Posts: 332
Joined: Thu Mar 28, 2013 12:49 pm

Re: Successfully built HB with MinGW/MSYS (need help!)

Post by gmb » Thu Mar 28, 2013 12:59 pm

Montago wrote:According to this article: http://www.extremetech.com/computing/12 ... nscoding/5
The best possible quality from QS is done in Arcsoft Media Converter - while Cyberlink Media Espresso does a terrible job.

AMC seems to be acceptable ?

at least QS is super fast, so some benefits exist

I guess time will tell

They surely encoded in mp4 with Cyberlink, it is much worse. Arcsoft has a terrible QS image quality but it's the fastest.

User avatar
s55
HandBrake Team
Posts: 9545
Joined: Sun Dec 24, 2006 1:05 pm

Re: Successfully built HB with MinGW/MSYS (need help!)

Post by s55 » Thu Mar 28, 2013 1:15 pm

These are just GUI's. If they all pass down the same settings, they should all get the same quality / speed unless they are doing something else outside quicksync.

gmb
Bright Spark User
Posts: 332
Joined: Thu Mar 28, 2013 12:49 pm

Re: Successfully built HB with MinGW/MSYS (need help!)

Post by gmb » Thu Mar 28, 2013 2:05 pm

s55 wrote:These are just GUI's. If they all pass down the same settings, they should all get the same quality / speed unless they are doing something else outside quicksync.

I know, but in the end there are bigger differences between QS encoders for me as user for whatever reason. I also tried MediaCoder which has tons of settings and whatever I tried it never was able to match the quality and speed of MediaEspresso with m2ts output. (I forgot to mention that the quality option in MediaEspresso did also make a difference in quality)

And there are also huge speed differences. I tested ~10 QS encoders not long ago with my Ivy Bridge HD4000 iGPU. What I didn't like from most GUI encoders like Mediaespresso were the limited bit rate or profile settings. MediaEspresso is limited to max 13 Mbps and I can't choose the profile. If I choose mp4 output it converts the video in normal profile. So I have to choose m2t output for high profile which is nonsense. Same for Arcsoft Mediakonverter, I can't change the profile there.

Montago

Re: Successfully built HB with MinGW/MSYS (need help!)

Post by Montago » Thu Mar 28, 2013 11:20 pm

Media Espresso is pure garbage... its like using any software from Apple: limitations, limitations !

Read the article i linked, it tells that Arcsoft Media Converter does the best job using QS - i dont know why !

gmb
Bright Spark User
Posts: 332
Joined: Thu Mar 28, 2013 12:49 pm

Re: Successfully built HB with MinGW/MSYS (need help!)

Post by gmb » Thu Mar 28, 2013 11:28 pm

Montago wrote:Media Espresso is pure garbage... its like using any software from Apple: limitations, limitations !

Read the article i linked, it tells that Arcsoft Media Converter does the best job using QS - i dont know why !

As I said Arcsoft is much worse than MediEspresso with high profile and quality option. The problem is that MediaEspresso with mp4 output converts with baseline profile and this looks much worse and probably that's why you see different results in other tests. Arcsoft is the fastest by far but has a very bad image quality. Arcsoft and MediaEespresso are both limited, I don't see a difference here. In fact MediaEspresso offers slightly more options.

edit: http://www.extremetech.com/wp-content/u ... .30-PM.png

So I was correct, mp4. No wonder they got a bad quality.

I would like to know if Handbrake will support the flexible knobs on Ivy Bridge or only on Haswell. I mean this: http://s14.directupload.net/images/130329/8spmsngz.png

User avatar
Rodeo
HandBrake Team
Posts: 12209
Joined: Tue Mar 03, 2009 8:55 pm

Re: Successfully built HB with MinGW/MSYS (need help!)

Post by Rodeo » Sat Mar 30, 2013 1:55 pm

1) we do intend to support High profile H.264 output out of QuickSync, regardless of hardware.
-> I haven't heard of anything that would prevent us from doing this yet (it would really suck if there is).

2) we're going to try and support as many features as possible, but also remain compatible with older hardware.
-> if all goes well, we'll just detect what features are available and enable/disable stuff accordingly.

3) the priority is to get the basics right… i.e. something which works.
-> after that, tweaks to make sure we get as much quality as possible out of QuickSync are definitely on my TO-DO list.

Post Reply