DivXDecH264 for linux

[GoogleCodeExporter]

Apologies if this is OT but I can't find elsewhere to post this query.

Would it be a good idea to extend dshowserver to also support the DivX7 
H264 decoder DivXDecH264.ax? This decoder is almost as good as CoreAVC.

Original issue reported on code.google.com by stuart_morris@talk21.com on 2 Jul 2009 at 1:35

[GoogleCodeExporter]

Have you tried it?
There isn't anything CoreAVC specific in dshowserver.  you just need to know 
the guid
and you should be able to try it

Original comment by alannis...@gmail.com on 9 Jan 2010 at 3:06

• Changed state: WaitingForResponse

[GoogleCodeExporter]

Tried it.
It loads, but there is no video (out frames: 0)

output from mplayer:

Forced video codec: divxdech264
Opening video decoder: [dshowserver] DirectShowServer video codecs
dshowserver --codec DivXDecH264.ax --size 640x512 --guid 6f513d27-97c3-453c-
87feb24ae50b1601 --fourc 0x31637661 --bits 16 --outfmt 0x32595559 --pid 10597 
--id 
b775f950 --numpages 10 --port 36844 &
Opening device (port is 36844)
len: 984
ProductVersion: 1.1
Decoder supports the following YUV formats: YUY2 IYUV UYVY YV12 YVYU I420 YVU9 
Decoder is capable of YUV output (flags 0x7f)
Setting fmt
Starting
Initialization is complete
Using socket based mutex
VDec: vo config request - 640 x 512 (preferred colorspace: Packed YUY2)
[PP] Using codec's postprocessing, max q = 4.
Trying filter chain: vo
VDec: using Planar YV12 as output csp (no 3)
Movie-Aspect is 1.81:1 - prescaling to correct movie aspect.
VO Config (640x512->928x512,flags=0,'MPlayer',0x32315659)
VO: [gl] 640x512 => 928x512 Planar YV12 
VO: Description: X11 (OpenGL)
VO: Author: Arpad Gereoffy <arpi@esp-team.scene.hu>
EINPROGRESS in connect() - selecting
Dshowserver Connected to host
[gl] GLX chose visual with ID 0x2f
[gl] Settings after autodetection: ati-hack = 0, force-pbo = 1, rectangle = 0
[gl] Creating 1024x512 texture...
[gl] Resize: 928x512
Found DirectShow filterSelected video codec: [divxdech264] vfm: dshowserver 
(Divx 
DShow H264 decoder)
==========================================================================
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
dec_audio: Allocating 192000 + 65536 = 257536 bytes for output buffer.
FFmpeg's libavcodec audio codec
INFO: libavcodec "vorbis" init OK!
AUDIO: 44100 Hz, 2 ch, s16le, 0.0 kbit/0.00% (ratio: 0->176400)
Selected audio codec: [ffvorbis] afm: ffmpeg (FFmpeg Vorbis)
==========================================================================
Building audio filter chain for 44100Hz/2ch/s16le -> 0Hz/0ch/??...
[libaf] Adding filter dummy 
[dummy] Was reinitialized: 44100Hz/2ch/s16le
[dummy] Was reinitialized: 44100Hz/2ch/s16le
Trying preferred audio driver 'oss', options '[none]'
ao2: 44100 Hz  2 chans  s16le
audio_setup: using '/dev/dsp' dsp device
audio_setup: using '/dev/mixer' mixer device
audio_setup: using 'pcm' mixer device
audio_setup: sample format: s16le (requested: s16le)
audio_setup: using 2 channels (requested: 2)
audio_setup: using 44100 Hz samplerate (requested: 44100)
audio_setup: frags:  32/32  (1884 bytes/frag)  free:  59392
AO: [oss] 44100Hz 2ch s16le (2 bytes per sample)
AO: Description: OSS/ioctl audio output
AO: Author: A'rpi
Building audio filter chain for 44100Hz/2ch/s16le -> 44100Hz/2ch/s16le...
[dummy] Was reinitialized: 44100Hz/2ch/s16le
[dummy] Was reinitialized: 44100Hz/2ch/s16le
Starting playback...
Increasing filtered audio buffer size from 0 to 62336
Seek now
Seek now
Seek now
Seek now
Seek now
Seek now
Seek now
Uninit audio filters...
[libaf] Removing filter dummy 
Uninit audio: ffmpeg
Uninit video: dshowserver
************
in-frames: 72 out-frames: 0
************
Destroying filtervo: uninit ...

Exiting... (Quit)

Property page works:

wine dshowserver.exe -c DivXDecH264.ax  --config
No id specified, assuming test mode
Using default width  for DivXDecH264.ax: 1280
Using default height for DivXDecH264.ax: 720
Using default fourcc for DivXDecH264.ax: 0x34363248
Using default outfmt for DivXDecH264.ax: 0x30323449
Using default outbit for DivXDecH264.ax: 12
Using default GUID   for DivXDecH264.ax: 6f513d27-97c3-453c-87feb24ae50b1601
Opening device (port is 0)
len: 984
ProductVersion: 1.1
Decoder supports the following YUV formats: YUY2 IYUV UYVY YV12 YVYU I420 YVU9 
Decoder is capable of YUV output (flags 0x7f)
Setting fmt
Starting
Initialization is complete
Filter does provide ISpecifyPropertyPages

Original comment by kjchmiel...@gmail.com on 10 Jan 2010 at 9:54

Attachments:

• defaults.diff

[GoogleCodeExporter]

Confirmed I see the same issue.  I'll look into it.

Original comment by alannis...@gmail.com on 10 Jan 2010 at 2:25

• Changed state: Started

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I not sure if it's correct solution but works here with DivXDecH264.ax, coreavc 
2.0 
and xvid.

Original comment by kjchmiel...@gmail.com on 20 Jan 2010 at 12:21

Attachments:

• discontinuity.diff

[GoogleCodeExporter]

Thanks, I will take a look.  I spent many hours banging my head against the wall
comparing a working test-app with the broken one in the code without much luck.

Now that we only support Wine, I am actually considering trashing the current
implementation entirely and just writing proper windows dshow filters to send 
and
receive data, and hooking them together with a graph.  that is basically what 
the
code does now, but it is really kludgy, and hard to debug.  We'll see if I get 
the time.

Original comment by alannis...@gmail.com on 26 Jan 2010 at 3:13

[GoogleCodeExporter]

Yes, it looks like current implementation is missing something. I did more 
tests and 
divx decoder only works with -nocorecct-pts, with correct-pts there are still 
strange 
issues (video freezes and decoder continues output frames after seek or 
decoding is 
very slow). On the other hand coreavc works better then ever, with -correct-pts 
enabled i get performance boost.
I can't help much with dshow but i can still help with testing.

Original comment by kjchmiel...@gmail.com on 26 Jan 2010 at 3:50

[GoogleCodeExporter]

Well, either the DivxH264 has anti-benchmarking code, or there is a race 
condition
somewhere.
when I turn on -benchmark, it dies every time within a couple of frames.  When I
added a sleep in DS_VideoDecoder_DecodeInternal() it started working fine.

I will try a few more things to see if I can nail it down.

Original comment by alannis...@gmail.com on 1 Feb 2010 at 4:26

[GoogleCodeExporter]

I don't understand how DS_VideoDecoder works as a whole, in particular what 
SetPts, 
GetPts and FreeFrame does but maybe it is related somehow to what described 
here:

http://msdn.microsoft.com/en-us/library/dd373500(VS.85).aspx
http://msdn.microsoft.com/en-us/library/dd377506(VS.85).aspx

Original comment by kjchmiel...@gmail.com on 1 Feb 2010 at 9:43

[GoogleCodeExporter]

the GetPts and SetPts should generally be used to pass information from the 
demuxer
to the display, and the decoder should just forward them along with the proper 
frame
usually.  Also, We don't support the IMediaSample2 interface which you poted, 
but
this is the relevant section of MSDN:
http://msdn.microsoft.com/en-us/library/dd407001%28VS.85%29.aspx

The Time and MediaTime functions may be more likely to be used by the decoder.  
I
have a log of functions that are called and will need to look it over.

There is also the possibility that we need to paymore attention to the reference
counts on the sample.

I should have more info in a day or 2.

Original comment by alannis...@gmail.com on 1 Feb 2010 at 11:06

[GoogleCodeExporter]

-benchmark works partially here, although is considerably slower then coreavc.
Decoder dies as You described if i disable "Low latency" option on property 
page.

Original comment by kjchmiel...@gmail.com on 2 Feb 2010 at 1:43

[GoogleCodeExporter]

I committed a fix for the discontinuity that should be correct.  However, there 
is
still definitely a race condition somewhere, as I can only reliably use the 
filter
about 50% of the time.
One think I noticed is that the filter seems to depend on the timestamp
(GetTime/SetTime), but the problem is that the lavf filter which we used to 
use, and
provides good timestamp info no longer works reliably, and the mov demuxer, 
which
decodes well, doesn't provide accurate timestamps.

This patch may have helped a little, but not all that much:
Index: libmpcodecs/vd_dshowserver.c
===================================================================
--- libmpcodecs/vd_dshowserver.c.orig   2010-02-02 21:53:31.000000000 -0800
+++ libmpcodecs/vd_dshowserver.c    2010-02-02 21:37:57.000000000 -0800
@@ -242,7 +242,7 @@
    if(len<=0) return NULL; // skipped frame

    ds_mpi->vd->cmd = VD_DECODE; //'2' is cmd for decoding
-   ds_mpi->vd->pts = (uint64_t)(sh->buffered_pts[0]*1E9);
+   ds_mpi->vd->pts = (uint64_t)(1E9* (sh->num_buffered_pts ? 
sh->buffered_pts[0] :
sh->pts));
    memcpy(ds_mpi->data, data, len);
    if (0) {
       static int count = 0;

Original comment by alannis...@gmail.com on 3 Feb 2010 at 5:57

[GoogleCodeExporter]

We shouldn't keep pts and media time in the same variable because these are 
different 
numbers.

Original comment by kjchmiel...@gmail.com on 6 Feb 2010 at 8:56

Attachments:

• media_time.diff

[GoogleCodeExporter]

Thanks.  I committed this, but it didn't help any with the reliability problems 
I
have with this codec.  I'm convinced there is a race somewhere.

I did find a lead, in that the output Output sample from the codec to our 
display is
being set to size '0'.  Specifically, the result of GetActualDataLength() is 0 
on the
decoded sample.  When running a standard windows Graph, I never see this 
happen.  The
weird thing is I see this both in the cases it hangs and the cases it runs.  
Still it
indicates something is likely wrong, though it may be a red-herring.

Original comment by alannis...@gmail.com on 7 Feb 2010 at 12:58

[GoogleCodeExporter]

I believe I finally nailed it down.  This should now be fixed in R110
The problem was in DS_Filter_CopySample()
Somehow the iterator was created incorrectly such that it wasn't incrementing.  
Thus
if a second output packet arrives before the 1st is consumed, it would hang 
forever.
Please verify that it is working well for you now.

Original comment by alannis...@gmail.com on 7 Feb 2010 at 3:06

• Changed state: WaitingForResponse

[GoogleCodeExporter]

FYI, here are some benchmarks, running on an Intel Core-2 Quad on x86_64

NASA video (720p) AVC1
DivxH264:
BENCHMARKs: VC:  12.946s VO:   0.003s A:   0.000s Sys:   0.220s =   13.169s
BENCHMARK%: VC: 98.3067% VO:  0.0212% A:  0.0000% Sys:  1.6721% = 100.0000%

FFh264 (from SVN):
BENCHMARKs: VC:  12.553s VO:   0.001s A:   0.000s Sys:   0.110s =   12.664s
BENCHMARK%: VC: 99.1252% VO:  0.0098% A:  0.0000% Sys:  0.8650% = 100.0000%

CoreAVC 2.0:
BENCHMARKs: VC:   8.171s VO:   0.001s A:   0.000s Sys:   0.792s =    8.965s
BENCHMARK%: VC: 91.1506% VO:  0.0135% A:  0.0000% Sys:  8.8358% = 100.0000%

A DVD 480p rip
DivxH264:
BENCHMARKs: VC:  24.265s VO:   0.006s A:   0.000s Sys:   0.316s =   24.586s
BENCHMARK%: VC: 98.6933% VO:  0.0226% A:  0.0000% Sys:  1.2841% = 100.0000%

FFH264:
BENCHMARKs: VC:  20.788s VO:   0.003s A:   0.000s Sys:   0.205s =   20.995s
BENCHMARK%: VC: 99.0112% VO:  0.0137% A:  0.0000% Sys:  0.9751% = 100.0000%

CoreAVC 2.0:
BENCHMARKs: VC:  18.948s VO:   0.004s A:   0.000s Sys:   0.244s =   19.196s
BENCHMARK%: VC: 98.7088% VO:  0.0189% A:  0.0000% Sys:  1.2724% = 100.0000%

So at least on my system, there is no reason to use DivxH264 for the videos I 
can
play in mplayer.  ffh264 is at least as good if not better, and for at least 
some
streams CoreAVC is significantly faster.

Unfortunately, I can't use mplayer with the streams I actually care about, as 
they
need the lavc demuxer, which I can't use with Dshowserver currently.  But 
mostly I
use this for MythTV.  Of course these days (now that I have a reasonably quick 
CPU),
the reason I use dshowserver is because it can flag commercials significantly 
faster
than ffh264 can in MythTV

Original comment by alannis...@gmail.com on 7 Feb 2010 at 3:25

[GoogleCodeExporter]

I can confirm the problem has gone. Divx decoder is slower here too.

Original comment by kjchmiel...@gmail.com on 7 Feb 2010 at 12:51

[GoogleCodeExporter]

Original comment by alannis...@gmail.com on 7 Feb 2010 at 1:43

• Changed state: Fixed

[GoogleCodeExporter]

Hi, I maintain the Coreavc-for-Ubuntu ppa that packages mplayer+dshowserver. Is 
it 
safe to patch dshowserver with the defaults patch so that users can use 
divx+dshowserver if they want?
Or are you going to release dshowserver with the updated defaults soon?

Original comment by Ripps...@gmail.com on 15 Feb 2010 at 7:28

[GoogleCodeExporter]

I would like to use mencoder with dshowserver and divxh264 decoder because 
ffh264 has problems with BBC-HD material, blocking, where CoreAVC and DivXH264 
don't suffer from this. I tried this under Windows with Sherpya's 
mplayer/mencoder builds and his dsn implementation. There is side effect 
though, these encoders are meant to provide RGB output for screen and libx264 
expects YUV as input, at least that is what I'm thinking, and the result is 
that skin-colour is blueish. My question is, how to get YUV activated, above I 
saw "Decoder is capable of YUV output (flags 0x7f)", but how/where should I 
activate this flag ?
Further, if I patch mplayer, copy the precompiled dshowserver stuff to 
/usr/local/bin and DivXDecH264.ax to /usr/lib/win32, and modify codecs.conf 
with the gui-info
6f513d27-97c3-453c-87feb24ae50b1601 should I be well then ? wine needed ???

Original comment by belca...@zonnet.nl on 10 Aug 2010 at 11:25

[GoogleCodeExporter]

I know I wine to run dshowserver, I meant does CoreAVCDecoder/DivXDecH264 have 
to be registered somehow ? If yes how, the installer of DivX gives me troubles, 
also with winetricks.

Regards

Original comment by belca...@zonnet.nl on 11 Aug 2010 at 7:47