CoreAVC + xineliboutput

  Igor skrev:
> 
> @Per
> can you write more detail HOWTO (my English is not so good, sorry)
> 

I have started with a CVS xine-lib. Then applied the vdr-xine patch.

Download and apply the xine.patch from 
http://code.google.com/p/coreavc-for-linux/

There are also some patches here to fix some problems with xine-lib:
http://dvbn.happysat.org/viewtopic.php?p=243997

Walery's patch to demux_mpeg_pes.c is attached. Apply that to.

Per
  

I'm sorry but the latest mail is not about how to get xineliboutput to 
work but xine. Walery has a patch for xineliboutput and I've tried it 
but I haven't been able to get it to work without segfault.

http://allrussian.info/thread.php?threadid=89361&threadview=0&hilight=&hilightuser=0&page=3
  

Hi,
> I'm sorry but the latest mail is not about how to get xineliboutput to
> work but xine. Walery has a patch for xineliboutput and I've tried it
> but I haven't been able to get it to work without segfault.
>
> http://allrussian.info/thread.php?threadid=89361&threadview=0&hilight=&hilightuser=0&page=3
>
 try cvs-version xineliboutput..

Walery
  

Walery Daniloff skrev:
> Hi,
>> I'm sorry but the latest mail is not about how to get xineliboutput to
>> work but xine. Walery has a patch for xineliboutput and I've tried it
>> but I haven't been able to get it to work without segfault.
>>
>> http://allrussian.info/thread.php?threadid=89361&threadview=0&hilight=&hilightuser=0&page=3
>>
>  try cvs-version xineliboutput..

I did that. Don't know if I got the patch correctly applied. I had to 
patch it manually. Will try again later today.

Thanks anyway for your efforts :)
  

Hello,

one more "stupid" question : does it works also for x86_64 ?

I wanted to try it, but if fails at patching :

patching file src/libw32dll/Makefile.am
Hunk #1 FAILED at 13.
Hunk #2 FAILED at 33.
2 out of 2 hunks FAILED -- saving rejects to file
src/libw32dll/Makefile.am.rej

that with coreavc-for-linux/xine/xine.patch against xine-lib-1.2 from
today.

Thank,
  

Gregoire Favre skrev:
> Hello,
> 
> one more "stupid" question : does it works also for x86_64 ?
> 
> I wanted to try it, but if fails at patching :
> 
> patching file src/libw32dll/Makefile.am
> Hunk #1 FAILED at 13.
> Hunk #2 FAILED at 33.
> 2 out of 2 hunks FAILED -- saving rejects to file
> src/libw32dll/Makefile.am.rej
> 
> that with coreavc-for-linux/xine/xine.patch against xine-lib-1.2 from
> today.
> 
> Thank,

Don't know if it works for x86_64.

I checked out xine-lib one minute ago to test and I had no problem.

....
patching file src/libw32dll/Makefile.am
Hunk #1 succeeded at 15 (offset 2 lines).
patching file src/libw32dll/nal_parser.c
....

Where did you get the xine.patch?

svn checkout http://coreavc-for-linux.googlecode.com/svn/trunk/ 
coreavc-for-linux-read-only from yesterday is what I'm using.

Cheers
  

> I wanted to try it, but if fails at patching :
> 
> patching file src/libw32dll/Makefile.am
> Hunk #1 FAILED at 13.
> Hunk #2 FAILED at 33.
> 2 out of 2 hunks FAILED -- saving rejects to file
> src/libw32dll/Makefile.am.rej

please, try with this Makefile version from Walery
http://allrussian.info/thread.php?postid=1226030#post1226030

Igor
  

On Sun, Jan 20, 2008 at 06:38:31PM +0100, Per Mellander wrote:

> Don't know if it works for x86_64.
> 
> I checked out xine-lib one minute ago to test and I had no problem.

Well, that's very strange, I checked revision 32 of the svn, and the svn
(you spoke about a CVS of xine-lib which is abandonned for a long time)
of xine-lib-1.2 :
hg pull -u http://hg.debian.org/hg/xine-lib/xine-lib-1.2/

Are you using xine-lib-1.1 by any chance ?
  

Gregoire Favre skrev:
> On Sun, Jan 20, 2008 at 06:38:31PM +0100, Per Mellander wrote:
> 
>> Don't know if it works for x86_64.
>>
>> I checked out xine-lib one minute ago to test and I had no problem.
> 
> Well, that's very strange, I checked revision 32 of the svn, and the svn
> (you spoke about a CVS of xine-lib which is abandonned for a long time)
> of xine-lib-1.2 :
> hg pull -u http://hg.debian.org/hg/xine-lib/xine-lib-1.2/
> 
> Are you using xine-lib-1.1 by any chance ?

Yes, 1.1.9

It's been very confusing to me. I started of by using the xine-lib that 
can be found on Reinards site http://home.vrweb.de/~rnissl/ Later on I 
figured out that cvs was abandoned so I checked out latest from
hg clone http://hg.debian.org/hg/xine-lib/xine-lib/

I'm running the first one, patched with xine.patch from 
http://coreavc-for-linux.googlecode.com/svn/trunk/ and then handpatched 
with the diff's from happysat and last Walerys patch.

I'm sorry if my input has been not that straight but I didn't realize 
the matter that cvs was abandoned until recently.

I'll try 1.2,

Per
  

> I'll try 1.2,


may be it's the best case :)

@Reinhard

is there any difference between xine-lib 1.2 branch and 1.1 branch for our case ?

Igor
  

I have been using xine-1.2 from the Mercurial distribution, but it
still creates a plugin directory called 1.1.9 and sometimes 1.1.90.

I just can't get it to work!

Here's the steps I have taken: -

Running on Ubuntu 7.10 x86_64.
Downloaded xine-lib-1.2 from hg
Patched with xine.patch from google code site
Fixed the Makefile.am problem
Patched with additional patch posted from Per in this mailing list
Patched with all additional patches that are in the Genpix thread on DVBN
Ran configure (./configure --disable-dxr3) && make && make install
Downloaded the CoreAVC unpacked file from rapidshare
(coreavcdecoder_unpacked.ax)
Put it in /usr/lib/win32 as (CoreAVCDecoder.ax)
Remove /usr/local/lib/plugins/1.1.9/xineplug_decode_ff.so [THERE IS NO
/usr/local/lib//1.1.9/xineplug_decode_qt.so]
Remove /usr/local/lib/plugins/1.1.90/xineplug_decode_ff.so [THERE IS
NO /usr/local/lib//1.1.90/xineplug_decode_qt.so]
Patched xinelibout (this doesn't work and causes a segfault on VDR startup)
Tried vdr-xine - this shows a black screen with audio but no video -
message says it can't find a plugin to handle the video.

So it seems that it just doesn't load the DLL. Am I missing any other
dependencies, do you need wine or anything else?

Thanks for your help and hopefully the above can lead to a howto, and
perhaps someone can upload somewhere a patched and working xine-lib as
well as a patched and working xinelibout?

Thanks in advance for all your help.


2008/1/21 Igor <goga777@bk.ru>:
> > I'll try 1.2,
>
>
> may be it's the best case :)
>
> @Reinhard
>
> is there any difference between xine-lib 1.2 branch and 1.1 branch for our case ?
>
> Igor
>
>
>
>
>
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
  

Hi,

> Tried vdr-xine - this shows a black screen with audio but no video -
> message says it can't find a plugin to handle the video.

show verbose-log  - xine --verbose=2
  

Morfsta skrev:
> I have been using xine-1.2 from the Mercurial distribution, but it
> still creates a plugin directory called 1.1.9 and sometimes 1.1.90.
> 

Evereything except that you use Mercurial looks like my setup. I started of with 
the xine-lib I had on my machine, which was originally taken from Reinhards 
xine-site. ( http://home.vrweb.de/~rnissl )

> 
> So it seems that it just doesn't load the DLL. Am I missing any other
> dependencies, do you need wine or anything else?

You don't need wine. The thing I did to see if the .ax is loaded is

[root@mm plugins]# lsof | grep Core
xine       4548      root  mem       REG        8,2  1031168    1999941 
/usr/lib/win32/CoreAVCDecoder.ax

I can see it gets opened whenever I switch to a H.264 channel.

> 
> Thanks for your help and hopefully the above can lead to a howto, and
> perhaps someone can upload somewhere a patched and working xine-lib as
> well as a patched and working xinelibout?

My xine-lib:

http://www.mellander.org/per/projects/linux/VDR-CoreAVC/xine-lib-with-coreavc-dvbn-walery.tar.gz

This is in Swedish but please have a look at 
http://www.vdr.nu/forum/viewtopic.php?t=431

Per
  

See attached xine.log

On Jan 21, 2008 7:30 AM, Walery Daniloff <walery@protect.donpac.ru> wrote:
> Hi,
>
> > Tried vdr-xine - this shows a black screen with audio but no video -
> > message says it can't find a plugin to handle the video.
>
> show verbose-log  - xine --verbose=2
>
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
  

> See attached xine.log
>

>load_plugins: plugin mpeg2 will be used for video streamtype 00.

try delete /usr/local/lib libxine* and /usr/local/lib/xine dir and make 
install xine again

Walery
  

Same problem. I'm not sure that the w32 codec support is being built
in xine. If I look in src/libw32dll I see: -

:~/dshow/xine-lib-1.2/src/libw32dll# ls
common.c    Makefile          Makefile.in   qtx              wine
DirectShow  Makefile.am       nal_parser.c  w32codec.c
dmo         Makefile.am.orig  nal_parser.h  w32codec.c.orig
libwin32.h  Makefile.am.rej   qt_decoder.c  w32codec.h

there doesn't seem to be any .lo or .o files - do you have them?

Also, if I do a make clean && make in that directory it doesn't do anything: -

# make
make[1]: Entering directory `/root/dshow/xine-lib-1.2/src/libw32dll'
make[1]: Nothing to be done for `all-am'.
make[1]: Leaving directory `/root/dshow/xine-lib-1.2/src/libw32dll'

Could this be the problem?

Thanks


On Jan 21, 2008 11:05 AM, Walery Daniloff <walery@protect.donpac.ru> wrote:
>
> > See attached xine.log
> >
>
> >load_plugins: plugin mpeg2 will be used for video streamtype 00.
>
> try delete /usr/local/lib libxine* and /usr/local/lib/xine dir and make
> install xine again
>
> Walery
>
>
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
  

linux 64bit? Most likely in it a problem.

> Also, if I do a make clean && make in that directory it doesn't do 
> anything: -
>
> # make
> make[1]: Entering directory `/root/dshow/xine-lib-1.2/src/libw32dll'
> make[1]: Nothing to be done for `all-am'.
> make[1]: Leaving directory `/root/dshow/xine-lib-1.2/src/libw32dll'
>
> Could this be the problem?
  

On Sun, Jan 20, 2008 at 10:20:40PM +0300, Igor wrote:

> please, try with this Makefile version from Walery
> http://allrussian.info/thread.php?postid=1226030#post1226030

Thank.

I'll be lazy and wait for a current patch against xine-lib-1.2 :-)

All the channels I have access to seems to works with ffmpeg and
xine-lib-1.2 sofar...
  

At least Hoochster says in his HowTo (for myth this time) that "..CoreAVC will only run in 32bit mode. So if you are running 64bit Linux, then you will need to setup a 32bit Chroot to compile Mplayer with the patches. This Howto does not cover that, but if you reference the Wiki site at the top, there is a pre-compiled dshowserver binary for 64bit that will help. You will still need the 32bit setup for mplayer though.."http://www.hoochvdr.info/viewtopic.php?f=29&t=546 I didn't try this, just thought this info might help someone..> From: walery@protect.donpac.ru> To: vdr@linuxtv.org> Date: Mon, 21 Jan 2008 14:40:01 +0300> Subject: Re: [vdr] VDR - xine - CoreAVC> > linux 64bit? Most likely in it a problem.> > > Also, if I do a make clean && make in that directory it doesn't do > > anything: -> >> > # make> > make[1]: Entering directory `/root/dshow/xine-lib-1.2/src/libw32dll'> > make[1]: Nothing to be done for `all-am'.> > make[1]: Leaving directory `/root/dshow/xine-lib-1.2/src/libw32dll'> >> > Could this be the problem?
  

I demand that Morfsta may or may not have written...

> I have been using xine-1.2 from the Mercurial distribution, but it
> still creates a plugin directory called 1.1.9 and sometimes 1.1.90.

Wrong. 1.1.90 only. Any 1.1.9 which you see is from xine-lib 1.1.9.

[snip]
> Running on Ubuntu 7.10 x86_64.

libw32dll is built only in i386; I see nothing in the patch which causes it
to be built on amd64.

[snip]
  

I demand that Per Mellander may or may not have written...

> Morfsta skrev:
>> I have been using xine-1.2 from the Mercurial distribution, but it still
>> creates a plugin directory called 1.1.9 and sometimes 1.1.90.

> Evereything except that you use Mercurial looks like my setup. I started of
> with the xine-lib I had on my machine, which was originally taken from
> Reinhards xine-site. ( http://home.vrweb.de/~rnissl )

If you use Real streams with xine-lib, DO NOT USE THOSE SNAPSHOTS (until
they're updated); instead, download and use xine-lib 1.1.9.1 or current hg.
(Ref. CVE-2008-0225.)

(My Debian repository has 1.1.9.1.)

[snip]
  

I demand that Gregoire Favre may or may not have written...

> On Sun, Jan 20, 2008 at 10:20:40PM +0300, Igor wrote:
>> please, try with this Makefile version from Walery
>> http://allrussian.info/thread.php?postid=1226030#post1226030

> Thank.

> I'll be lazy and wait for a current patch against xine-lib-1.2 :-)

For these changes to have any chance of being accepted, they must be:

  * based on current 1.2
  * split up into a series of incremental patches
    - a functional xine-lib after each patch is considered useful :-)

and they must have:

  * the necessary changes to get libw32dll built on amd64
    - unless it won't work on amd64, of course...
  * copyright/licence headers in each new file
  * suitable descriptions for each patch, with summary lines
    - this will make for easy import and useful output from "hg log"

ffmpeg remains the preferred option, though.

[snip]
  

OK, you are right. I am building it in a 32bit chroot environment and
now it tried to build in lib32dll!

However, I get this error message: -

w32codec.c:581: error: 'BUF_VIDEO_WVC1' undeclared (first use in this function)

I can't find anywhere in the code where this is declared but the
coreavc patch adds it..

Any ideas?

On Jan 21, 2008 2:42 PM, Darren Salt <linux@youmustbejoking.demon.co.uk> wrote:
> I demand that Morfsta may or may not have written...
>
> > I have been using xine-1.2 from the Mercurial distribution, but it
> > still creates a plugin directory called 1.1.9 and sometimes 1.1.90.
>
> Wrong. 1.1.90 only. Any 1.1.9 which you see is from xine-lib 1.1.9.
>
> [snip]
> > Running on Ubuntu 7.10 x86_64.
>
> libw32dll is built only in i386; I see nothing in the patch which causes it
> to be built on amd64.
>
> [snip]
> --
> | Darren Salt    | linux or ds at              | nr. Ashington, | Toon
> | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
> |   Kill all extremists!
>
> b Wrong file type, 0:1
>
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
  

I demand that Morfsta may or may not have written...

[snip]
> However, I get this error message: -

> w32codec.c:581: error: 'BUF_VIDEO_WVC1' undeclared (first use in this function)

> I can't find anywhere in the code where this is declared but the
> coreavc patch adds it..

> Any ideas?

Incomplete patch?

Anyway, I'm guessing that it's for the same codec as BUF_VIDEO_VC1, which I
added for 1.1.9 (since it's one which ffmpeg implements).

[snip]
  

Seems that there is a difference in versions somewhere. BUF_VIDEO_WVC1
is defined in xine-engine.h. I added it to an include and its
compiling-ish.... I'm actually cross compiling 32bit in my 64 bit
environment which is fun with having to provide so many 32-bit libs.
Still I don't fancy trashing my 64bit VDR box just to play around with
CoreAVC - it runs quite a few other bits and pieces.

On Jan 21, 2008 3:16 PM, Darren Salt <linux@youmustbejoking.demon.co.uk> wrote:
> I demand that Morfsta may or may not have written...
>
> [snip]
> > However, I get this error message: -
>
> > w32codec.c:581: error: 'BUF_VIDEO_WVC1' undeclared (first use in this function)
>
> > I can't find anywhere in the code where this is declared but the
> > coreavc patch adds it..
>
> > Any ideas?
>
> Incomplete patch?
>
> Anyway, I'm guessing that it's for the same codec as BUF_VIDEO_VC1, which I
> added for 1.1.9 (since it's one which ffmpeg implements).
>
> [snip]
> --
> | Darren Salt    | linux or ds at              | nr. Ashington, | Toon
> | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
> | + Burn less waste. Use less packaging. Waste less.     USE FEWER RESOURCES.
>
> Don't use a big word where a diminutive one will suffice.
>
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
  

I demand that Morfsta may or may not have written...

> Seems that there is a difference in versions somewhere. BUF_VIDEO_WVC1
> is defined in xine-engine.h.

I don't know where your xine-engine.h came from, but it's not xine-lib.

[snip; don't top-post]
  

It was in the tar file that Per posted earlier of his xine-lib!

On Jan 21, 2008 4:06 PM, Darren Salt <linux@youmustbejoking.demon.co.uk> wrote:
> I demand that Morfsta may or may not have written...
>
> > Seems that there is a difference in versions somewhere. BUF_VIDEO_WVC1
> > is defined in xine-engine.h.
>
> I don't know where your xine-engine.h came from, but it's not xine-lib.
>
> [snip; don't top-post]
> --
> | Darren Salt    | linux or ds at              | nr. Ashington, | Toon
> | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
> | + Buy local produce. Try to walk or cycle. TRANSPORT CAUSES GLOBAL WARMING.
>
> Avoid run-on sentences they are hard to read.
>
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
  

Hi,

Igor schrieb:

> is there any difference between xine-lib 1.2 branch and 1.1 branch for our case ?

The 1.2 branch contains my VDR plugins while the 1.1 branch needs
a patch, which vdr-xine-0.8.1 provides. Don't think that this is
relevant for our goals.

The patch for the 1.1 branch is mainly meant for distributions
which want to ship a xine-lib-1.1 with support for my VDR plugin.
As 1.2 is still in development, API version numbers are likely to
change and therefore most xine-lib-1.1 based software needs some
(often minor) patches to get it going with xine-lib-1.2.

Bye.
  

I demand that Morfsta may or may not have top-posted AGAIN...

> On Jan 21, 2008 4:06 PM, Darren Salt <linux@youmustbejoking.demon.co.uk>
> wrote:
>> I demand that Morfsta may or may not have written...
>>> Seems that there is a difference in versions somewhere. BUF_VIDEO_WVC1
>>> is defined in xine-engine.h.
>> I don't know where your xine-engine.h came from, but it's not xine-lib.

> It was in the tar file that Per posted earlier of his xine-lib!

I've not looked in that tarball, but I can say for certain that there is no
header of that name in any xine-lib tarball which I've generated.

[snip quoted .sigs]
  

Darren Salt skrev:
> I demand that Morfsta may or may not have top-posted AGAIN...
> 
>> On Jan 21, 2008 4:06 PM, Darren Salt <linux@youmustbejoking.demon.co.uk>
>> wrote:
>>> I demand that Morfsta may or may not have written...
>>>> Seems that there is a difference in versions somewhere. BUF_VIDEO_WVC1
>>>> is defined in xine-engine.h.
>>> I don't know where your xine-engine.h came from, but it's not xine-lib.
> 
>> It was in the tar file that Per posted earlier of his xine-lib!
> 
> I've not looked in that tarball, but I can say for certain that there is no
> header of that name in any xine-lib tarball which I've generated.
> 
> [snip quoted .sigs]

That tar-ball included all the patches from coreavc, dvbn and walery. IIRC the 
difference is in the dvbn-patch.

Per
  

Hey, it works ... Sort of. Anyone else having the "green bar" problem?
I get a large green bar across the bottom of the screen and four fuzzy
representations of the picture above it on: -

BBC HD
DigitalAlb HD-1
DigitalAlb HD-2
SVT HD

However, Channel 4 HD and a number of other HD channels work fine.
Anyone else managed to see BBC HD okay? I know it is supported with
the CoreAVC codec...

It's swings and roundabouts - some spatial mode channels now are fine!
  

Problem in incorrect patch.. The size of a picture 1920?1080 is sewn rigidly 
up, and for BBS HD it is necessary 1440?1080

> Hey, it works ... Sort of. Anyone else having the "green bar" problem?
> I get a large green bar across the bottom of the screen and four fuzzy
> representations of the picture above it on: -
>
> BBC HD
> DigitalAlb HD-1
> DigitalAlb HD-2
> SVT HD
  

hmmm, I've been looking into the demux_mpeg_pes function in xine,
isn't the height and width stored in the transport stream within the
pes? I tried to adapt the code that shows the resolution in femon to
work on the stream in demux_mpeg_pes but not had much success so far..
:-(

Do you have to parse through the payload itself?

On Jan 23, 2008 3:10 AM, Walery Daniloff <walery@protect.donpac.ru> wrote:
> Problem in incorrect patch.. The size of a picture 1920?1080 is sewn rigidly
> up, and for BBS HD it is necessary 1440?1080
>
> > Hey, it works ... Sort of. Anyone else having the "green bar" problem?
> > I get a large green bar across the bottom of the screen and four fuzzy
> > representations of the picture above it on: -
> >
> > BBC HD
> > DigitalAlb HD-1
> > DigitalAlb HD-2
> > SVT HD
>
>
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
  

OK, I have added the following code into src/demuxers/demux_mpeg_pes.c

static int32_t GetVideoSize(const uint8_t *buf, int length, int
*width, int *height)
{
  int i = 0;         // the minimum length of the video packet header
  //i += buf[i] + 1;   // possible additional header bytes
  for (; i < length-6; i++) {
    if (buf[i] == 0 && buf[i + 1] == 0 && buf[i + 2] == 1) {
      if(buf[i + 3] == 0xb3) {
        int d = (buf[i+4] << 16) | (buf[i+5] << 8) | buf[i+6];
        *width = (d >> 12);
        *height = (d & 0xfff);
        return 1;
      }
    }
  }
  return 0;
}

and then put the following code in parse_video_stream: -

  int Width, Height;
  if (GetVideoSize(p, payload_size, &Width, &Height)) {
   printf("Detected video size %dx%d\n", Width, Height);
  }
  else {
   printf("Failed to detect video size\n");
  }

before:   /* H.264 broadcasts via DVB-S use standard video PES packets,

This detects the video size for MPEG2 broadcasts (Detected video size 704x576
), but not for H264, I'm guessing the payload is in a different
format. Can anyone point me in the direction of a GetVideoSize type of
function for H264 (I looked in libavcodec and the code looks a bit
more complex!), or spot what I am doing wrong here?

TIA


On Jan 23, 2008 11:50 AM, Morfsta <morfsta@gmail.com> wrote:
> hmmm, I've been looking into the demux_mpeg_pes function in xine,
> isn't the height and width stored in the transport stream within the
> pes? I tried to adapt the code that shows the resolution in femon to
> work on the stream in demux_mpeg_pes but not had much success so far..
> :-(
>
> Do you have to parse through the payload itself?
>
>
> On Jan 23, 2008 3:10 AM, Walery Daniloff <walery@protect.donpac.ru> wrote:
> > Problem in incorrect patch.. The size of a picture 1920?1080 is sewn rigidly
> > up, and for BBS HD it is necessary 1440?1080
> >
> > > Hey, it works ... Sort of. Anyone else having the "green bar" problem?
> > > I get a large green bar across the bottom of the screen and four fuzzy
> > > representations of the picture above it on: -
> > >
> > > BBC HD
> > > DigitalAlb HD-1
> > > DigitalAlb HD-2
> > > SVT HD
> >
> >
> >
> > _______________________________________________
> > vdr mailing list
> > vdr@linuxtv.org
> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> >
>
  

Hi,

Morfsta schrieb:

> OK, I have added the following code into src/demuxers/demux_mpeg_pes.c
> 
> static int32_t GetVideoSize(const uint8_t *buf, int length, int
> *width, int *height)
> {
>   int i = 0;         // the minimum length of the video packet header
>   //i += buf[i] + 1;   // possible additional header bytes
>   for (; i < length-6; i++) {
>     if (buf[i] == 0 && buf[i + 1] == 0 && buf[i + 2] == 1) {
>       if(buf[i + 3] == 0xb3) {
>         int d = (buf[i+4] << 16) | (buf[i+5] << 8) | buf[i+6];
>         *width = (d >> 12);
>         *height = (d & 0xfff);
>         return 1;
>       }
>     }
>   }
>   return 0;
> }
> 
> and then put the following code in parse_video_stream: -
> 
>   int Width, Height;
>   if (GetVideoSize(p, payload_size, &Width, &Height)) {
>    printf("Detected video size %dx%d\n", Width, Height);
>   }
>   else {
>    printf("Failed to detect video size\n");
>   }
> 
> before:   /* H.264 broadcasts via DVB-S use standard video PES packets,
> 
> This detects the video size for MPEG2 broadcasts (Detected video size 704x576
> ), but not for H264, I'm guessing the payload is in a different
> format. Can anyone point me in the direction of a GetVideoSize type of
> function for H264 (I looked in libavcodec and the code looks a bit
> more complex!), or spot what I am doing wrong here?

In H.264, this information in coded far more complex. Have a look
into VDR's h264parser.c. Look for pic_width_in_mbs_minus1,
pic_height_in_map_units_minus1 and frame_crop_*_offset.

You can get the standard from here for free:
http://www.itu.int/rec/T-REC-H.264-200503-I/en

Bye.
  

Yes, I started looking at that. I also downloaded some H264 reference
utilities that someone at Dolby put together.

 It seems that you must start scanning the mpeg stream for a Sequence
Parameter Set with a NAL Access Code of 7. At first glance this
doesn't appear too bad, as the code is already in
src/demuxers/demux_mpeg_pes.c to scan for a NAL code of 9 (Access Unit
Delimiter), which it uses to detect the presence of H264 stream.

I thought it would be quite straightforward to find the NAL code of 7
and then parse the SPS and in turn find the height and width
parameters. However, trying to get this to work in sequence is not
that easy as the parse_video_stream seems to want to identify MPEG1/2
or H264 and then just init the decoders. This is where the
initialisation of CoreAVCDecoder.ax is made, currently with the
hardcoded video size of 1920x1080.  What I want it to do is identify
the H264 stream and then keep scanning for an SPS to identify the size
prior to initting the decoder.

It seems that once it's found the AUD it doesn't really want to keep
looking for a SPS. I tried modifying the code to look for a SPS to
init the H264 sequence, however haven't had much success with that
either.

It might be the case that the whole initialisation of the CoreAVC
decoder would be better suited somewhere else in the code.... :-\

Still, I knew nothing about MPEG2 and MPEG4 formats this morning and
now I know a tiny bit! Unfortunately, I'm not sure if I have the
coding skills to be able to finish the job.. :-(

On Jan 24, 2008 7:31 PM, Reinhard Nissl <rnissl@gmx.de> wrote:
> Hi,
>
> Morfsta schrieb:
>
>
> > OK, I have added the following code into src/demuxers/demux_mpeg_pes.c
> >
> > static int32_t GetVideoSize(const uint8_t *buf, int length, int
> > *width, int *height)
> > {
> >   int i = 0;         // the minimum length of the video packet header
> >   //i += buf[i] + 1;   // possible additional header bytes
> >   for (; i < length-6; i++) {
> >     if (buf[i] == 0 && buf[i + 1] == 0 && buf[i + 2] == 1) {
> >       if(buf[i + 3] == 0xb3) {
> >         int d = (buf[i+4] << 16) | (buf[i+5] << 8) | buf[i+6];
> >         *width = (d >> 12);
> >         *height = (d & 0xfff);
> >         return 1;
> >       }
> >     }
> >   }
> >   return 0;
> > }
> >
> > and then put the following code in parse_video_stream: -
> >
> >   int Width, Height;
> >   if (GetVideoSize(p, payload_size, &Width, &Height)) {
> >    printf("Detected video size %dx%d\n", Width, Height);
> >   }
> >   else {
> >    printf("Failed to detect video size\n");
> >   }
> >
> > before:   /* H.264 broadcasts via DVB-S use standard video PES packets,
> >
> > This detects the video size for MPEG2 broadcasts (Detected video size 704x576
> > ), but not for H264, I'm guessing the payload is in a different
> > format. Can anyone point me in the direction of a GetVideoSize type of
> > function for H264 (I looked in libavcodec and the code looks a bit
> > more complex!), or spot what I am doing wrong here?
>
> In H.264, this information in coded far more complex. Have a look
> into VDR's h264parser.c. Look for pic_width_in_mbs_minus1,
> pic_height_in_map_units_minus1 and frame_crop_*_offset.
>
> You can get the standard from here for free:
> http://www.itu.int/rec/T-REC-H.264-200503-I/en
>
> Bye.
> --
> Dipl.-Inform. (FH) Reinhard Nissl
> mailto:rnissl@gmx.de
>
> _______________________________________________
>
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
  

Hi,

Morfsta schrieb:

>  It seems that you must start scanning the mpeg stream for a Sequence
> Parameter Set with a NAL Access Code of 7. At first glance this
> doesn't appear too bad, as the code is already in
> src/demuxers/demux_mpeg_pes.c to scan for a NAL code of 9 (Access Unit
> Delimiter), which it uses to detect the presence of H264 stream.

Correct.

> I thought it would be quite straightforward to find the NAL code of 7
> and then parse the SPS and in turn find the height and width
> parameters. However, trying to get this to work in sequence is not
> that easy as the parse_video_stream seems to want to identify MPEG1/2
> or H264 and then just init the decoders. This is where the
> initialisation of CoreAVCDecoder.ax is made, currently with the
> hardcoded video size of 1920x1080.  What I want it to do is identify
> the H264 stream and then keep scanning for an SPS to identify the size
> prior to initting the decoder.
> 
> It seems that once it's found the AUD it doesn't really want to keep
> looking for a SPS. I tried modifying the code to look for a SPS to
> init the H264 sequence, however haven't had much success with that
> either.

Typically, a SPS is found in the same memory block which starts
with an AUD for an "I frame". From VDR's remux.c,
cRemux::ScanVideoPacket():

              if (!p[-2] && !p[-1]) { // found 0x000001
                 if (h264) {
                    int nal_unit_type = p[1] & 0x1F;
                    switch (nal_unit_type) {
                      case 9: { // access unit delimiter
                           int primary_pic_type = p[2] >> 5;
                           switch (primary_pic_type) {
                             case 0: // I
                             case 3: // SI
                             case 5: // I, SI
                                  PictureType = I_FRAME;
                                  break;

> It might be the case that the whole initialisation of the CoreAVC
> decoder would be better suited somewhere else in the code.... :-\

Doesn't the decoder support a callback function where it tells
you, the detected frame size? It'll really be a mess to do H.264
"decoding" in the demuxer.

Bye.
  

On Jan 24, 2008 9:54 PM, Reinhard Nissl <rnissl@gmx.de> wrote:
> Typically, a SPS is found in the same memory block which starts
> with an AUD for an "I frame". From VDR's remux.c,
> cRemux::ScanVideoPacket():
>
>              if (!p[-2] && !p[-1]) { // found 0x000001
>                 if (h264) {
>                    int nal_unit_type = p[1] & 0x1F;
>                    switch (nal_unit_type) {
>                      case 9: { // access unit delimiter
>                           int primary_pic_type = p[2] >> 5;
>                           switch (primary_pic_type) {
>                             case 0: // I
>                             case 3: // SI
>                             case 5: // I, SI
>                                  PictureType = I_FRAME;
>                                  break;
>
> > It might be the case that the whole initialisation of the CoreAVC
> > decoder would be better suited somewhere else in the code.... :-\
>
> Doesn't the decoder support a callback function where it tells
> you, the detected frame size? It'll really be a mess to do H.264
> "decoding" in the demuxer.
>

I'm not sure about that. So, if the function identifies an AUD at the
start of the payload then it could go on and scan the rest of the
payload for an SPS? In other words we must scan after the AUD for

Data[0] = 0x00
Data[1] = 0x00
Data[2] = 0x01
Data[3] & 0x1F = 0x07

and start parsing from Data[4]?

How can we be sure that combination of bytes doesn't exist by chance
in the picture payload anyway?

Cheers
  

Hi,

Morfsta schrieb:

> I'm not sure about that. So, if the function identifies an AUD at the
> start of the payload then it could go on and scan the rest of the
> payload for an SPS? In other words we must scan after the AUD for
> 
> Data[0] = 0x00
> Data[1] = 0x00
> Data[2] = 0x01
> Data[3] & 0x1F = 0x07
> 
> and start parsing from Data[4]?
> 
> How can we be sure that combination of bytes doesn't exist by chance
> in the picture payload anyway?

cVideoRepacker takes care that each field / frame is preceded by
an AUD. A SPS appears before slice start codes and is typically
found only in I frames.

The special coding (see annex B if I recall correctly) takes care
that video data doesn't emulate NAL start codes.

Bye.
  

OK, I spent a bit of time looking at this today as there doesn't seem
to be much movement on FFMPEG and H264 at the moment.

I have managed to get xine to now detect the H264 video size prior to
starting up the CoreAVC decoder and set the size within the
initialisation function: -

      memset(&bih, 0x00, sizeof(bih));
      bih.biWidth = sps.width;
      bih.biHeight = sps.height;
      bih.biPlanes = 1;
      bih.biBitCount = 24;
      bih.biCompression = 0x34363248; //31435641; //AVC1
      bih.biSizeImage = 0;
      bih.biXPelsPerMeter=10000;
      bih.biYPelsPerMeter=10000;
      bih.biClrUsed=0;
      bih.biClrImportant=0;
      bih.biSize = sizeof(bih);
      buf->content = malloc(sizeof(bih));

It detects BBC HD as the right video size, i.e. 1440 x 1080 - however
this now results in a squased image on the display with black bars
down the left and right sides. Any idea how you tell CoreAVC what the
video size is and to scale it to the size that xine is using? It
detects other video sizes such as 1920x1088 and displays them all
correctly on the screen so I know that we are now very close!

Once I get this bit right, I'll release a patch to xine's
demux_mpeg_pes.c that will properly detect the source video size prior
to starting CoreAVC.

Thanks for any help.
  

Hi,

Morfsta schrieb:

> I have managed to get xine to now detect the H264 video size prior to
> starting up the CoreAVC decoder and set the size within the
> initialisation function: -
> 
>       memset(&bih, 0x00, sizeof(bih));
>       bih.biWidth = sps.width;
>       bih.biHeight = sps.height;
>       bih.biPlanes = 1;
>       bih.biBitCount = 24;
>       bih.biCompression = 0x34363248; //31435641; //AVC1
>       bih.biSizeImage = 0;
>       bih.biXPelsPerMeter=10000;
>       bih.biYPelsPerMeter=10000;
>       bih.biClrUsed=0;
>       bih.biClrImportant=0;
>       bih.biSize = sizeof(bih);
>       buf->content = malloc(sizeof(bih));
> 
> It detects BBC HD as the right video size, i.e. 1440 x 1080 - however
> this now results in a squased image on the display with black bars
> down the left and right sides. Any idea how you tell CoreAVC what the
> video size is and to scale it to the size that xine is using? It
> detects other video sizes such as 1920x1088 and displays them all
> correctly on the screen so I know that we are now very close!

Looks like you/CoreAVC miss setting the aspect ratio of the
frame. If you replay a BBC HD recording with xine (using FFmpeg)
and open a VDR menu, you should see messages like that which tell
you the frame aspect ratio after the @:

vdr_video: osd: (0, 0)-(1440, 1080)@1,81818
ratio: 18182

Just a guess: maybe the above bih.biXPelsPerMeter and
bih.biYPelsPerMeter can be used to set the pixel aspect ratio
which will then in turn yield the frame aspect ratio when applied
to the coded frame size. So pixel aspect for the above sample
should yield:

	pa = 1.81818 * 1080 / 1440 = 1.363635

and most likely:

	bih.biXPelsPerMeter=13636

BTW: the above ratio of 1.81818 is different from 16:9 which is
1.77778. I've no idea why BBC uses this "strange" ratio. And
1920x1088 doesn't yield 16:9 either, but 1.76471.

Bye.
  

On Feb 11, 2008 6:31 PM, Reinhard Nissl <rnissl@gmx.de> wrote:

> Just a guess: maybe the above bih.biXPelsPerMeter and
> bih.biYPelsPerMeter can be used to set the pixel aspect ratio
> which will then in turn yield the frame aspect ratio when applied
> to the coded frame size. So pixel aspect for the above sample
> should yield:
>
>        pa = 1.81818 * 1080 / 1440 = 1.363635
>
> and most likely:
>
>        bih.biXPelsPerMeter=13636
>

I tried that, what would the bih.biYPelsPerMeter be in this instance?
10000?  Even then it doesn't seem to make any difference.

There is a reference to that structure here: -

http://www.herdsoft.com/ti/davincie/davp3xo2.htm

I think I'm quite close to getting this sorted but just can't seem to
get this final output right.. :-(
  

Hi,

Morfsta schrieb:

>> Just a guess: maybe the above bih.biXPelsPerMeter and
>> bih.biYPelsPerMeter can be used to set the pixel aspect ratio
>> which will then in turn yield the frame aspect ratio when applied
>> to the coded frame size. So pixel aspect for the above sample
>> should yield:
>>
>>        pa = 1.81818 * 1080 / 1440 = 1.363635
>>
>> and most likely:
>>
>>        bih.biXPelsPerMeter=13636
> 
> I tried that, what would the bih.biYPelsPerMeter be in this instance?
> 10000?  Even then it doesn't seem to make any difference.

That's why I wrote "guess".

Anyway, does the decoder tell you the aspect ratio anywhere?

The aspect ratio must be passed to get_frame(). When the frame
has the correct aspect ratio set, xine-lib will take care to
setup the video scaler to stretch for example the image to 136 %
horizontally.

Bye.
  

On Feb 11, 2008 8:09 PM, Reinhard Nissl <rnissl@gmx.de> wrote:

> Anyway, does the decoder tell you the aspect ratio anywhere?
>
> The aspect ratio must be passed to get_frame(). When the frame
> has the correct aspect ratio set, xine-lib will take care to
> setup the video scaler to stretch for example the image to 136 %
> horizontally.

The coreavc patch for xine has this code in it: -

+        if(!img) {
+        img = this->stream->video_out->get_frame (this->stream->video_out,
+              this->bih->biWidth,
+              this->bih->biHeight,
+              this->ratio,
+              IMGFMT_YUY2,
+              field);
+        }

with      this->ratio = (double)this->bih->biWidth/(double)this->bih->biHeight;

This is all within xine's src/libw32dll/w32codec.c which is a
different area to which I was modifying before
(src/demuxers/demux_mpeg_pes.c) where the codec is initialised.
  

Hi,

Morfsta schrieb:

> The coreavc patch for xine has this code in it: -
> 
> +        if(!img) {
> +        img = this->stream->video_out->get_frame (this->stream->video_out,
> +              this->bih->biWidth,
> +              this->bih->biHeight,
> +              this->ratio,
> +              IMGFMT_YUY2,
> +              field);
> +        }
> 
> with      this->ratio = (double)this->bih->biWidth/(double)this->bih->biHeight;

Looks not bad, but ratio is wrong. For your sample 1440 x 1080 it
will yield 1.3333 and not 1.8181 (or 1.7778). Therefore you get
those black bars left and right to the image.

In case the decoder doesn't provide the image aspect ratio (and
it looks like that as you had to provide the image size too),
you'll have to extract it from the H.264 data yourself (as you
did already for the image size).

Bye.
  

On Feb 11, 2008 9:09 PM, Reinhard Nissl <rnissl@gmx.de> wrote:
> In case the decoder doesn't provide the image aspect ratio (and
> it looks like that as you had to provide the image size too),
> you'll have to extract it from the H.264 data yourself (as you
> did already for the image size).
>

OK - thanks for your help and patience Reinhard.

We are on the right track here. If I hardcode the this->ratio to be
1.8181 all looks good for my channels. However it is a hack and I have
come this far, so I might as well get the rest correct!

I used xinelibout for my H264 parser but Petri Hintukainen skips
parsing of the VUI! I am looking in your h264parser.c in VDR and you
also seem to comment this stuff out!

So, here is my code: -

       if (br_get_bit(&br)) { /* VUI parameters */
          if (br_get_bit(&br)) { /* Aspect Info */
             uint32_t aspect_ratio_idc = br_get_u8(&br);
             printf("H.264 SPS: -> Aspect Ratio IDC %d\n", aspect_ratio_idc);
             const uint32_t Extended_SAR = 255;
             if (aspect_ratio_idc == Extended_SAR) {
                  uint32_t sar_width = br_get_u16(&br);
                  uint32_t sar_height = br_get_u16(&br);
                  printf("H.264 SPS: -> SAR_Size = %dx%d\n",
sar_width, sar_height);
             }
          }
       }

I am getting an Aspect Ratio IDC of 11 so the sar width and height
calcs are not called. What do I need to do here to get the aspect
(~1.818181)?

Thanks again!




>
> Bye.
> --
> Dipl.-Inform. (FH) Reinhard Nissl
> mailto:rnissl@gmx.de
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
  

Hi,

Morfsta schrieb:

> I used xinelibout for my H264 parser but Petri Hintukainen skips
> parsing of the VUI! I am looking in your h264parser.c in VDR and you
> also seem to comment this stuff out!

Well, I have no use for this kind of information, but I have to
read over it as there is no other way to get to relevant
information behind it :-(

> So, here is my code: -
> 
>        if (br_get_bit(&br)) { /* VUI parameters */
>           if (br_get_bit(&br)) { /* Aspect Info */
>              uint32_t aspect_ratio_idc = br_get_u8(&br);
>              printf("H.264 SPS: -> Aspect Ratio IDC %d\n", aspect_ratio_idc);
>              const uint32_t Extended_SAR = 255;
>              if (aspect_ratio_idc == Extended_SAR) {
>                   uint32_t sar_width = br_get_u16(&br);
>                   uint32_t sar_height = br_get_u16(&br);
>                   printf("H.264 SPS: -> SAR_Size = %dx%d\n",
> sar_width, sar_height);
>              }
>           }
>        }
> 
> I am getting an Aspect Ratio IDC of 11 so the sar width and height
> calcs are not called. What do I need to do here to get the aspect
> (~1.818181)?

Well, the spec tells you that aspect_ratio_idc 11 means a sample
(pixel) aspect ratio 15:11 (1.3636). And you have 1440 x 1080
pixels so the frame aspect ratio yields:

	far = 1.3636 * 1440 / 1080 = 1.8181

Bye.
  

> Well, the spec tells you that aspect_ratio_idc 11 means a sample
> (pixel) aspect ratio 15:11 (1.3636). And you have 1440 x 1080
> pixels so the frame aspect ratio yields:
>
>        far = 1.3636 * 1440 / 1080 = 1.8181
>

Could you give me a link to where you found that please?

Also, I just discovered another problem with this method. I was
wondering why the performance on HD was so poor and it turns out that
the picture was being de-interlaced twice, once by CoreAVC for the
h264 picture and then by xine post plugin (tvtime). When I remove the
post deinterlacing plugin the performance is much better and now seems
to decode all the h264 channels I have access to pretty well with ~40%
idle. However, when I go back to a MPEG2 channel of course the
deinterlacing is now disabled and it looks terrible!

Do you know if its possible to enable de-interlacing for only a
certain picture type(s), or am I looking at this the wrong way?
  

On 12 Feb 2008, at 08:27, Morfsta wrote:

> now seems to decode all the h264 channels I have access to pretty  
> well with ~40% idle.


Which CPU are you using?
  

Hi,

Morfsta schrieb:

>> Well, the spec tells you that aspect_ratio_idc 11 means a sample
>> (pixel) aspect ratio 15:11 (1.3636). And you have 1440 x 1080
>> pixels so the frame aspect ratio yields:
>>
>>        far = 1.3636 * 1440 / 1080 = 1.8181
> 
> Could you give me a link to where you found that please?

I've posted the URL to the spec some weeks ago already. In that
issue, have a look into Annex E.2.1, Table E-1, Page 313.

> Also, I just discovered another problem with this method. I was
> wondering why the performance on HD was so poor and it turns out that
> the picture was being de-interlaced twice, once by CoreAVC for the
> h264 picture and then by xine post plugin (tvtime). When I remove the
> post deinterlacing plugin the performance is much better and now seems
> to decode all the h264 channels I have access to pretty well with ~40%
> idle. However, when I go back to a MPEG2 channel of course the
> deinterlacing is now disabled and it looks terrible!
> 
> Do you know if its possible to enable de-interlacing for only a
> certain picture type(s), or am I looking at this the wrong way?

Simply set the progressive_frame flag.

But use_progressive_frame_flag=0 overrides this information and
will still deinterlace.

To disable it completely for your decoder even in this case, do
not set VO_INTERLACED_FLAG when getting the frame.

Have a look into ff_video_decoder.c.

Bye.
  

On Feb 11, 2008 11:00 PM, Torgeir Veimo <torgeir@pobox.com> wrote:

> Which CPU are you using?
>

AMD BE-2350 overclocked to 2.6Ghz. Now running H264 channels like a
charm with CoreAVC.

Almost there....
  

On Feb 11, 2008 11:03 PM, Reinhard Nissl <rnissl@gmx.de> wrote:

> I've posted the URL to the spec some weeks ago already. In that
> issue, have a look into Annex E.2.1, Table E-1, Page 313.
>

Sorry. I'll see what I can dig out to set that up properly. For now
hardcoding works well as most H264 channels are 16:9.

> Simply set the progressive_frame flag.
>
> To disable it completely for your decoder even in this case, do
> not set VO_INTERLACED_FLAG when getting the frame.
>

Yup, it was set right there and no need for it. Now CoreAVC runs with
much better performance with xine. No more dropped frames... :-)