I have done all the patching to xine-lib, ( patch from coreavc-for-linux-read-only + additional from happysat ). Then I've put CoreAVCDecoder.ax in /usr/lib/win32.
I'm running VDR with xineliboutput.
-P "xineliboutput --fullscreen --local=sxfe --audio=alsa --remote=none"
What more do I have to do, ( extra arguments etc. ) to use CoreAVC? When I start VDR now I can't see any difference from using ffmpeg.
.... load_plugins: plugin /usr/local/lib/xine/plugins/1.1.9/xineplug_dmx_nsv.so found load_plugins: plugin /usr/local/lib/xine/plugins/1.1.9/xineplug_decode_a52.so found video_out_xv: using Xv port 275 from adaptor NV17 Video Texture for hardware colour space conversion and scaling. video_out_xv: this adaptor supports the yuy2 format. video_out_xv: this adaptor supports the yv12 format. audio_alsa_out : supported modes are 8bit 16bit 24bit 32bit mono stereo (4-channel not enabled in xine config) (4.1-channel not enabled in xine config) (5-channel not enabled in xine config) (5.1-channel not enabled in xine config) (a/52 and DTS pass-through not enabled in xine config) xine: found input plugin : VDR (Video Disk Recorder) input plugin input cache plugin disabled xine: found demuxer plugin: DVD/VOB demux plugin video_out_xv: VO_PROP_INTERLACED(1) av_offset=0 pts video_out_xv: VO_PROP_ZOOM_X = 100 prebuffer=14400 pts prebuffer=14400 pts prebuffer=14400 pts prebuffer=14400 pts prebuffer=14400 pts video: synced early prebuffer=14400 pts prebuffer=14400 pts video: synced early prebuffer=14400 pts prebuffer=14400 pts video: synced early [h264 @ 0x11c43f0]non existing PPS referenced [h264 @ 0x11c43f0]decode_slice_header error [h264 @ 0x11c43f0]non existing PPS referenced [h264 @ 0x11c43f0]decode_slice_header error ....
I'm having the same problem. I've put the .ax file in /usr/lib/win32, registed the key in ~/.mplayer/registry32 and then done: - # dshowserver -c CoreAVCDecoder.ax -s 1280x720 -g 09571a4b-f1fe-4c60-9760de6d310c7c31 -b 12 -f 0x34363248 -o 0x30323449 shm:/dshow_shm.(null) sem1:/dshow_sem1.(null) sem2:/dshow_sem2.(null) Opening device Called unk_IsDebuggerPresent len: 948 ProductVersion: 1.3.0.0 Decoder supports the following YUV formats: YUY2 IYUV YV12 I420 Decoder is capable of YUV output (flags 0x27) Setting fmt Starting Initialization is complete shm_open failed: No such file or directory
Is dshowserver supposed to run in the background - using strace it says it's detached but I can't see it?
I looked through the diff and can't find any options to enable CoreAVC in xine-lib... Must be missing something?
Igor, can you point us to or translate a HOWTO?
Thanks
On Jan 19, 2008 4:38 PM, Per Mellander per@mellander.org wrote:
I have done all the patching to xine-lib, ( patch from coreavc-for-linux-read-only + additional from happysat ). Then I've put CoreAVCDecoder.ax in /usr/lib/win32.
I'm running VDR with xineliboutput.
-P "xineliboutput --fullscreen --local=sxfe --audio=alsa --remote=none"
What more do I have to do, ( extra arguments etc. ) to use CoreAVC? When I start VDR now I can't see any difference from using ffmpeg.
.... load_plugins: plugin /usr/local/lib/xine/plugins/1.1.9/xineplug_dmx_nsv.so found load_plugins: plugin /usr/local/lib/xine/plugins/1.1.9/xineplug_decode_a52.so found video_out_xv: using Xv port 275 from adaptor NV17 Video Texture for hardware colour space conversion and scaling. video_out_xv: this adaptor supports the yuy2 format. video_out_xv: this adaptor supports the yv12 format. audio_alsa_out : supported modes are 8bit 16bit 24bit 32bit mono stereo (4-channel not enabled in xine config) (4.1-channel not enabled in xine config) (5-channel not enabled in xine config) (5.1-channel not enabled in xine config) (a/52 and DTS pass-through not enabled in xine config) xine: found input plugin : VDR (Video Disk Recorder) input plugin input cache plugin disabled xine: found demuxer plugin: DVD/VOB demux plugin video_out_xv: VO_PROP_INTERLACED(1) av_offset=0 pts video_out_xv: VO_PROP_ZOOM_X = 100 prebuffer=14400 pts prebuffer=14400 pts prebuffer=14400 pts prebuffer=14400 pts prebuffer=14400 pts video: synced early prebuffer=14400 pts prebuffer=14400 pts video: synced early prebuffer=14400 pts prebuffer=14400 pts video: synced early [h264 @ 0x11c43f0]non existing PPS referenced [h264 @ 0x11c43f0]decode_slice_header error [h264 @ 0x11c43f0]non existing PPS referenced [h264 @ 0x11c43f0]decode_slice_header error ....
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Morfsta skrev:
I'm having the same problem. I've put the .ax file in /usr/lib/win32, registed the key in ~/.mplayer/registry32 and then done: -
You don't have to register.
I patched xine-lib with coreavc for Linux xine.patch @ http://coreavc-for-linux.googlecode.com/svn/trunk/xine/xine.patch
Then you have to add additional code to demux_mpeg_pes.c ( see attached patch )
You have to delete xineplug_decode_ff.so and xineplug_decode_qt.so in /usr/local/lib/xine/plugins/1.1.9/
I tried xineliboutput first but that give me black screen with epg + sound. With vdr-xine-0.8.1.tgz it all seems to work :)
root@mm plugins]# lsof | grep Core xine 4548 root mem REG 8,2 1031168 1999941 /usr/lib/win32/CoreAVCDecoder.ax
Many thanks to Igor who has been a great help!
--- demux_mpeg_pes.c.org 2008-01-19 22:09:58.000000000 +0100 +++ demux_mpeg_pes.c 2008-01-19 22:10:02.000000000 +0100 @@ -1092,6 +1092,7 @@ static int32_t parse_private_stream_1(de return this->packet_len + result; }
+int sent_header = 0; /* Added by Mel */ static int32_t parse_video_stream(demux_mpeg_pes_t *this, uint8_t *p, buf_element_t *buf) { int32_t result; uint32_t todo_length=0; @@ -1136,6 +1137,7 @@ static int32_t parse_video_stream(demux_ an AUD has been found at the beginning of the payload. */ if (this->mpeg12_h264_detected < 2) { + sent_header = 0; /* Added by Mel */ uint8_t *pp = p + 2, *pp_limit = p + payload_size - 1; while (0 < pp && pp < pp_limit) { if (pp[0] == 0x01 && pp[-1] == 0x00 && pp[-2] == 0x00) { @@ -1156,9 +1158,44 @@ static int32_t parse_video_stream(demux_ pp++; pp = memchr(pp, 0x01, pp_limit - pp); } + usleep(100); /* Added by Mel */ lprintf("%s%c\n", (this->mpeg12_h264_detected & 1) ? "H.264" : "MPEG1/2", (this->mpeg12_h264_detected & 2) ? '!' : '?'); + +// Mel START + + if (this->mpeg12_h264_detected == 3){ + if (sent_header == 0) { + printf("INIT H264\n"); + xine_bmiheader bih; + buf_element_t *buf = this->video_fifo->buffer_pool_alloc (this->video_fifo); + buf->decoder_flags = BUF_FLAG_STDHEADER; + + memset(&bih, 0x00, sizeof(bih)); + bih.biWidth = 1920; + bih.biHeight = 1080; + 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)); + memcpy(buf->content, &bih, sizeof(bih)); + //memcpy(buf->content, &bih, sizeof(bih)); + buf->size = sizeof(bih); + buf->type = BUF_VIDEO_H264; + buf->decoder_flags |= BUF_FLAG_FRAME_END; + this->video_fifo->put (this->video_fifo, buf); + sent_header = 1; + buf = NULL; + } } +}
+// Mel END /* when an H.264 AUD is seen, we first need to tell the decoder that the previous frame was complete. */
I'm having the same problem. I've put the .ax file in /usr/lib/win32, registed the key in ~/.mplayer/registry32 and then done: -
You don't have to register.
yes, for xine no need any coreavc-registration.
I patched xine-lib with coreavc for Linux xine.patch @ http://coreavc-for-linux.googlecode.com/svn/trunk/xine/xine.patch
no any rejects ? with which xine-lib version did you work ?
Then you have to add additional code to demux_mpeg_pes.c ( see attached patch )
did you install the additional patches from hXXp://dvbn.happysat.org ?
You have to delete xineplug_decode_ff.so and xineplug_decode_qt.so in /usr/local/lib/xine/plugins/1.1.9/
yes, may be the option --disable-ffmpeg during xine-lib compilaton will help, too
I tried xineliboutput first but that give me black screen with epg + sound.
for xineliboutput you have to try the patch from http://allrussian.info/thread.php?postid=1226448#post1226448 (very many thanks to Walery)
With vdr-xine-0.8.1.tgz it all seems to work :)
fine !!! and what about your impressions ?
Many thanks to Igor who has been a great help!
ah, not to me ! To Walery from our forum - he helped to me and to you yesterday evening.
@ALL can somebody to make cumulative coreavc-patch for xine and xineliboutput with "xine.patch + patches from dvbn.happysat + patches" from allrussian ?
@Per can you write more detail HOWTO (my English is not so good, sorry)
Igor
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
--- demux_mpeg_pes.c.org 2008-01-19 22:09:58.000000000 +0100 +++ demux_mpeg_pes.c 2008-01-19 22:10:02.000000000 +0100 @@ -1092,6 +1092,7 @@ static int32_t parse_private_stream_1(de return this->packet_len + result; }
+int sent_header = 0; static int32_t parse_video_stream(demux_mpeg_pes_t *this, uint8_t *p, buf_element_t *buf) { int32_t result; uint32_t todo_length=0; @@ -1136,6 +1137,7 @@ static int32_t parse_video_stream(demux_ an AUD has been found at the beginning of the payload. */ if (this->mpeg12_h264_detected < 2) { + sent_header = 0; /* Added by Mel */ uint8_t *pp = p + 2, *pp_limit = p + payload_size - 1; while (0 < pp && pp < pp_limit) { if (pp[0] == 0x01 && pp[-1] == 0x00 && pp[-2] == 0x00) { @@ -1156,9 +1158,44 @@ static int32_t parse_video_stream(demux_ pp++; pp = memchr(pp, 0x01, pp_limit - pp); } + usleep(100); lprintf("%s%c\n", (this->mpeg12_h264_detected & 1) ? "H.264" : "MPEG1/2", (this->mpeg12_h264_detected & 2) ? '!' : '?'); + + + + if (this->mpeg12_h264_detected == 3){ + if (sent_header == 0) { + printf("INIT H264\n"); + xine_bmiheader bih; + buf_element_t *buf = this->video_fifo->buffer_pool_alloc (this->video_fifo); + buf->decoder_flags = BUF_FLAG_STDHEADER; + + memset(&bih, 0x00, sizeof(bih)); + bih.biWidth = 1920; + bih.biHeight = 1080; + 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)); + memcpy(buf->content, &bih, sizeof(bih)); + //memcpy(buf->content, &bih, sizeof(bih)); + buf->size = sizeof(bih); + buf->type = BUF_VIDEO_H264; + buf->decoder_flags |= BUF_FLAG_FRAME_END; + this->video_fifo->put (this->video_fifo, buf); + sent_header = 1; + buf = NULL; + } } +}
+ /* when an H.264 AUD is seen, we first need to tell the decoder that the previous frame was complete. */
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&hiligh...
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&hiligh...
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&hiligh...
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
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 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
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
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?
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? _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
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-coreav...
This is in Swedish but please have a look at http://www.vdr.nu/forum/viewtopic.php?t=431
Per
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 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]
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
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.363635and 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.363635and most likely:
bih.biXPelsPerMeter=13636I 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 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....
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.8181Could 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: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... :-)
On Jan 21, 2008 7:01 AM, Morfsta morfsta@gmail.com wrote:
However, I get this error message: -
w32codec.c:581: error: 'BUF_VIDEO_WVC1' undeclared (first use in this function)
Try:
--- xine-lib/src/xine-engine/buffer.h.orig 2007-11-05 18:33:03.000000000 -0500 +++ xine-lib/src/xine-engine/buffer.h 2007-11-05 18:33:38.000000000 -0500 @@ -192,6 +192,8 @@ #define BUF_VIDEO_CAVS 0x02620000 #define BUF_VIDEO_VP6F 0x02630000 #define BUF_VIDEO_THEORA_RAW 0x02640000 +#define BUF_VIDEO_VC1 0x02650000 +#define BUF_VIDEO_WVC1 0x02650000
/* audio buffer types: (please keep in sync with buffer_types.c) */
That got it!
I've got it working now in the 32-bit chroot environment, I can see it loading the CoreAVC codec when switching to BBC HD.
Sadly, I'm doing this remotely so can't see how the results actually look on the TV until tomorrow! I'm keen on seeing a channel that uses spatial direct mode.
Has anyone managed to get the xinelibout patch working so that VDR doesn't coredump on startup?
On Jan 21, 2008 5:45 PM, VDR User user.vdr@gmail.com wrote:
On Jan 21, 2008 7:01 AM, Morfsta morfsta@gmail.com wrote:
However, I get this error message: -
w32codec.c:581: error: 'BUF_VIDEO_WVC1' undeclared (first use in this function)
Try:
--- xine-lib/src/xine-engine/buffer.h.orig 2007-11-05 18:33:03.000000000 -0500 +++ xine-lib/src/xine-engine/buffer.h 2007-11-05 18:33:38.000000000 -0500 @@ -192,6 +192,8 @@ #define BUF_VIDEO_CAVS 0x02620000 #define BUF_VIDEO_VP6F 0x02630000 #define BUF_VIDEO_THEORA_RAW 0x02640000 +#define BUF_VIDEO_VC1 0x02650000 +#define BUF_VIDEO_WVC1 0x02650000
/* audio buffer types: (please keep in sync with buffer_types.c) */
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 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 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...
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]
-
Darren Salt -
Dex -
Gregoire Favre -
Igor -
Morfsta -
Per Mellander -
Reinhard Nissl -
Torgeir Veimo -
VDR User -
Walery Daniloff