Unexpected x264 header

[GoogleCodeExporter]

This is happening also under Linux when using a new version of x264 (build
greater than 85 apparently).
When trying to use x264enc: 

gst-launch.exe  ksvideosrc ! ffmpegcolorspace ! x264enc! ...

the error is: "Unexpected x264 header"...
I am using GStreamerWinBuild-0.10.6.exe.

Original issue reported on code.google.com by ddrago...@gmail.com on 12 May 2010 at 1:37

[GoogleCodeExporter]

Are you sure this is a GStreamer issue? libx264 don't provide API/ABI 
compatibility 
between build/revisions (I don't know how they call it), so you shouldn't use 
any 
other version that the one recommended for the GStreamer plugin (the same 
happens for 
ffmpeg).

Original comment by ylatuya on 12 May 2010 at 1:46

[GoogleCodeExporter]

I don't know what revision of libx264 was used for 
GStreamerWinBuild-0.10.6.exe. 
I know that I got the same error in Ubunntu 10.04 when I tried to replace 
libx264
build 85 with a newer version. So I suspect there is a similar case here. It is 
just
an assumption. 
Anyway, the error can be easily reproduced in the above mentioned Windows 
version.

Original comment by ddrago...@gmail.com on 12 May 2010 at 2:26

[GoogleCodeExporter]

This pipeline works for me on linux using libx264-85:
gst-launch videotestsrc ! video/x-raw-yuv,width=320,height=240,framerate=30/1 ! 
ffmpegcolorspace ! x264enc! decodebin2 ! ffmpegcolorspace ! fakesink

Original comment by ylatuya on 12 May 2010 at 3:22

[GoogleCodeExporter]

As expected!
But I just looked at the files installed by GStreamerWinBuild-0.10.6.exe and it 
has
libx264-67.dll. Is this the version intended? Or something went wrong with my
installation?

Original comment by ddrago...@gmail.com on 12 May 2010 at 3:56

[GoogleCodeExporter]

From what I understood you are trying to use a version bigger than 85 and this 
case is 
where it fails, isn't it?
I don't have  a windows machine right now and can't test but does the current 
shipped 
version works, which is what really maters?

Original comment by ylatuya on 12 May 2010 at 4:17

[GoogleCodeExporter]

No, this is not what I meant. That was the case only in my Linux test. 
Everything was
fine when I reverted back to libx264-85. Let's not discuss about this Linux 
case.

In Windows I just used GStreamerWinBuild-0.10.6.exe from
http://ossbuild.googlecode.com/files/GStreamer-WinBuilds-GPL-x86.msi. As I 
said, it
comes with libx264-67.dll.
Let's focus only on the WINDOWS error.

Original comment by ddrago...@gmail.com on 12 May 2010 at 6:39

[GoogleCodeExporter]

I can confirm it.
Let see if upgrading libx264 fixes the issue ;)

Original comment by ylatuya on 13 May 2010 at 7:12

• Changed state: Started

[GoogleCodeExporter]

I can confirm, using GStreamer Winbuilds 0.10.6.

A known-good combination of libraries is libx264-85 and 
gst-plugins-ugly-0.10.14. 
This is what Ubuntu Lucid ships.

Original comment by mwcampbe...@gmail.com on 13 May 2010 at 9:45

[GoogleCodeExporter]

The "-67" on the end of the filename is what libx264 emits even though it's 
more up-
to-date than that. It's actually > 85 (I believe it's at 92).

Original comment by david.g.hoyt on 13 May 2010 at 11:31

[GoogleCodeExporter]

Maybe it should be 85 then. 
As I said above, I tried in Linux gst-plugins-ugly-0.10.14 and a version of 
libx264
newer than 85 and I got the same error message. David, could you use build 85? I
assume you used the sources from gst-plugins-ugly-0.10.14...

Original comment by ddrago...@gmail.com on 14 May 2010 at 2:22

[GoogleCodeExporter]

@david We should use build 85. The API changes constantly in libx264 and we 
should 
tight to the recommended, although it's almost impossible to know which one it 
is 
from the GStreamer sources. 
If you look at the code in gstx264enc there is a lot of #ifdef to cover all the 
API 
changes. And a newer change  might not be considered in all those switches. 
It's also 
a bad idea to have a different API in the dll, it's very confusing (yesterday I 
was 
trying to update a to a more recent build, but it was already in the latest 
one, I 
should have read the version in README.txt).

I propose first to get the API version directly from the sources:
API=$(grep '#define X264_BUILD' < x264.h | cut -f 3 -d ' ')
change_key "." "config.mak" "SONAME" "lib${Prefix}x264-$API.dll"

And revert libx264 to tha last commit of build 85:

commit: http://git.videolan.org/gitweb.cgi?
p=x264.git;a=commit;h=7a7fbeab0f1f3b8187d1d8ce56def91f1582d5d7
snapshot: http://git.videolan.org/gitweb.cgi?
p=x264.git;a=snapshot;h=7a7fbeab0f1f3b8187d1d8ce56def91f1582d5d7;sf=tgz

We should also name the x264 version using the API version and the first 6 
digits of 
the commit.
In that particular case, we would use: libx264-0.85~git7a7fbe

Original comment by ylatuya on 14 May 2010 at 8:53

[GoogleCodeExporter]

The proposed naming scheme is only for the scripts, to make it easy to retrieve 
to 
commit used to build libx264, not the dll's name.

Original comment by ylatuya on 14 May 2010 at 2:01

[GoogleCodeExporter]

Another solution is to patch gstx264enc with upstream master.

Original comment by ylatuya on 14 May 2010 at 2:09

[GoogleCodeExporter]

Which solution would be easiest?

Original comment by mwcampbe...@gmail.com on 14 May 2010 at 2:29

[GoogleCodeExporter]

Probably, the easiest one would be patching the sources with master. You don't 
need to 
donwgrade libx264 and you don't need to upgrade it later after the release.
Anyway there are new upstream releases very soon, and we sould update all the 
modules 
as soon they are available.

Original comment by ylatuya on 14 May 2010 at 2:42

[GoogleCodeExporter]

So will you patch the source, or wait for the new upstream release?

Original comment by mwcampbe...@gmail.com on 14 May 2010 at 3:31

[GoogleCodeExporter]

ylatuya - go ahead and make the necessary changes.

Original comment by david.g.hoyt on 14 May 2010 at 5:48

[GoogleCodeExporter]

That's now fixed in trunk.
I'll keep this issue open until I commit the patch for the API version in the 
build
script.

Original comment by ylatuya on 14 May 2010 at 7:06

[GoogleCodeExporter]

Should be fixed in trunk. Please see SVN r758 and r759.

Original comment by david.g.hoyt on 20 Jul 2010 at 12:06

• Changed state: Fixed

[GoogleCodeExporter]

Is there a pre-built version of libgstx264.dll that reflects the changes in 
revs 758 and 759?  I can download the entire trunk at 759 and attempt to build, 
but it would certainly be more convenient to have the ready-made DLL.

Original comment by tomtr...@gmail.com on 30 Jul 2010 at 1:32

[GoogleCodeExporter]

The next release will have those changes. We don't have an exact date slated 
for it, though.

Original comment by david.g.hoyt on 30 Jul 2010 at 5:41

[GoogleCodeExporter]

I will try to get a minimal build set for the DLL; as long as I have the 
requisite lib files, it looks like the project is pretty small.  I am building 
code to interoperate with the Ubuntu version using RTSP, RTP, and h264, so I 
need the fix right away.  Thanks anyway.

Original comment by tomtr...@gmail.com on 30 Jul 2010 at 5:57

[GoogleCodeExporter]

I can provide you with a version of the latest x264 plugin built against the 
trunk if you'd like. Might save you some time...

Original comment by david.g.hoyt on 31 Jul 2010 at 1:25

[GoogleCodeExporter]

That would be great, thanks.

Original comment by tomtr...@gmail.com on 31 Jul 2010 at 1:41

[GoogleCodeExporter]

The build was much easier after I worked around the Windows 7 bug regarding 
indexed content that causes erroneous file errors when checking the project out 
over SVN:

http://serverfault.com/questions/72561/64-bit-tortoisesvn-on-windows-7-says-file
-or-directory-is-corrupted-and-unreadab
http://schleichermann.wordpress.com/2009/12/09/svn-tortoisesvn-cant-move-the-fil
e-or-directory-is-corrupted-and-unreadable-windows-7/

Note that the issue exists for both TortoiseSVN and the SlikSVN command line 
distribution.

After ignoring the wixproj issues (I did not bother to install votive), I was 
able to load the entire solution.  I built just the needed project 
(trunk\Main\GStreamer\Windows\Build\Plugins\Ugly\ext\x264.vcproj); the 
dependencies built perfectly.  After that I copied the resultant DLL and 
libx264-104.dll to the right places and viola'!

Original comment by tomtr...@gmail.com on 8 Aug 2010 at 12:48

[GoogleCodeExporter]

A workaround is to add byte-stream argument to x264enc and set it to true, eg.
"gst-launch -v videotestsrc ! x264enc qp-min=18 byte-stream=1 ! avimux ! 
filesink location=videotestsrc.avi"

Original comment by PaXMaNP...@gmail.com on 22 May 2012 at 4:36