aloha standalone player compatibility

[torsius]

Since the aloha release thread has become so... monolithic, I thought I'd make a new one, to focus on the standalone compatibility, since it was mentioned a few times in the release thread.

First off, I hope the devs haven't had too big of a heartattack with some people saying the aloha streams won't playback on standalones (since they claim divx compatibility or whatever), because it works fine on my unit (liteon lvd-2001).

In fact, I have been regularly testing out the devapi4 builds on my player, and they have all worked flawlessly (when I was actually able to encode with the build I was using).

Here's the features/settings I regularly use, and love:

b-frames (1,1.5,0)
trellis-quant
MPEG matrix (just recently, since I use trellis)
adaptive quantization
MSP 6
chroma motion
VHQ 4

I haven't messed with cartoon mode, and I don't use qpel or gmc as my standalone doesn't support them anyways.

All the standalone junkies should post their settings/players/results here, to help the devs figure out what currently ails aloha :)

[Doom9]

what kind of bitrates have you tested?

[torsius]

With the devapi builds before aloha, I have used many avg bitrates ranging from 500 kbps to 1500 kbps.

I have only done a few tests with aloha itself though, all those being right around 1000 kbps avg.

My player seems to be very mature with it's xvid support, I have yet to see a single xvid stream skip or stutter with it. It only has problems with certain divx 3.11 (sbc) content.

Also, I only use mod16 resolutions at 640x[whatever] or less, so I'm not sure how well it handles high resolution content.

[sysKin]

Hi,
Before one of you posts some bigger standalone-compatibility raport, I'd like to inform you that a bug in mpeg-4 header was fixed today by Michael. Please don't post standalone-problems until beta2 (or unless you compile by yourself).

:)
Radek

[torsius]

I guess other standalones out there must be more picky about ISO compliance and all that stuff.

Is koepi planning on releasing other intermediate updates to xvid short of beta2? I only ask this for other standalone users who are having issues with beta1.

[seewen]

I made a test with "Godfather 3" on my KISS DP-450.

I used beta 1 version.

608x336
2-pass (avg 1100kbps).
2 B frames (default values).
Chroma ME.
Chroma OPT.
VHQ 4.
I HAD TO use H.263 matrix. Beccause the only way to limit the bitrate @4'000kbps is to use "DXN HT" profile, and with it you cannot use an other matrix.
(All other options set to default).


The result if perfect. Plays perfect, time-search perfect, stream change perfect (it was a BivX. AC3 - MP3).

I will do more tests, but I guess it will work perfectly if the bitrate is under 4'000 and consecutive B-frames are under 5, exactly like previous build.

[amango]

ESS-chipset based standalone players does have problems with beta 1 (can't play).

[LigH]

@ amango:

With which settings used? Probably not in general - I bet you can tweak XviD until a video runs fine, although you may have to leave some quality optimizing options away.

As far as I read in the german doom9/Gleitz forum, the ELTA 8883 player might be the most complete MPEG4 player so far - the only thing we still doubt about is the use of XviD GMC with 4 warp points.

For older players, also QPel might be a problem. Some even may check the FourCC (which is easy to patch, anyway). And custom matrices may not be supported by all players. But as far as I remember, those are the only "risky" options.

[torsius]

amango,

as syskin said, there was a problem in the headers produced by the aloha version, which has since been corrected (in the cvs). this may have been the cause of the incompatibility in certain standalones.

someone with an ess-based player should grab the newest available source from the cvs and test it out to see if that fixes the problem.

[RadicalEd]

Mm.. defaulting to the highest level setting for whatever profile is used seems more like a hack than a fix :|
But I'm just whining cause I want levels and am too lame to code them myself :P

[olnima]

@ torsius:

I tried the beta2 (with default settings) with an ESS-based DVD player (yamada 6100) but still it doesn't work.

Olnima

[raz0r]

yes, both beta1 and 2 dont work on ESS based players, pretty sad.
settings: MSP6 VHQ4 no qpel no gmc no bframes. no chance to get it working, but if sigma players can handle it the problem is perhaps based on the chip/firmware (since ess designs all firmwares for all players, iirc)

[gotaserena]

Both betas worked flawlessly in my xcard.

B-frames ON, Trellis ON, GMC OFF, Qpel OFF. H.263/MPEG/Andreas 78er/HVS, Carton Mode ON&OFF.

[amango]

A firmware update for the ESS-players might help. But this will take some weeks, before it will be supported. ESS-players still have problems with XVID, as they don't correctly display B-Frames even with the old dev-api3 builts.

[najt]

Also doesn't work on the Philips DVD737. I'm not sure if this is a ESS based player.

[amango]

The Phillips DVD 737 does have an ESS-chipset, too.

[olnima]

Dear Developer, don't know what You did but You did it perfect! :-)

The newest build fron http://xvid.gamrdev.com/ is working perfect on my ESS-chip-based player yamada 6100. Only with a first test, next days I'll do some more.

THANK YOU !!!

(Happy) Olnima

[amango]

You are right. The built from 14.12.2003 acutally works with ESS-chipset based standalone players without problems.

[Koepi]

There was a problem with setting the pixel aspect ratio field to a wrong value - it's fixed now - just wait for beta3, we have some more nice things to come :)

Regards
Koepi

[sysKin]

Hehehe, so much for mpeg-4 compatibility with this ESS chipset...

The older XviD was setting pixels to be rectangles 1:1 big, the newer versions sets them to square. It's obvoiusly the same, even if written differently - so this chipset isn't too smart, after all.

Radek

[Heini011]

Hi Koepi,

will we see the beta 3 within the next days ? i would like to take this not only for testing purpose but for backups now...

it seems to be very solid already...

greetings, heini011.

[amango]

Originally posted by Koepi
There was a problem with setting the pixel aspect ratio field to a wrong value - it's fixed now - just wait for beta3, we have some more nice things to come :)

Regards
Koepi

I have encoded some anime episodes with beta 2. I don't want to encode them again. Is there a way I can "patch" this files to be compatible to play them with the ESS-standalone player? (Patching those files with the correct data with the pixel ratio field)

[sysKin]

Originally posted by amango
I have encoded some anime episodes with beta 2. I don't want to encode them again. Is there a way I can "patch" this files to be compatible to play them with the ESS-standalone player? (Patching those files with the correct data with the pixel ratio field) In theory this is easy, in practice there isn't any mpeg-4 reader/writer that could do that. There isn't even any program that could be patched to do that :(

Unfortunaltely new headers are 2 bytes shorter now, so you can't even try editing files directly :(

*Perhaps* only replacing first keyframe would do. What you can try is:
encode first scene alone, from the beginning to second keyframe in your movie (with constant quant to make it easier, just try keeping similar size if you need to) and use virtualdub to replace everything between first and second keyframe with new stream. It should work.

Radek

[amango]

I just tried it. I encoded the first scene and appended the new video with the old one.

It does not work. The first scene plays well on the standalone, but if the player reaches the appended part of the AVI that was encoded with the Beta2-release, it stops playing. :(

[symonjfox]

Originally posted by sysKin
In theory this is easy, in practice there isn't any mpeg-4 reader/writer that could do that. There isn't even any program that could be patched to do that :(

Unfortunaltely new headers are 2 bytes shorter now, so you can't even try editing files directly :(

But, is it possible (if someone write this kind of program) or is it a big hack, or an heavy work?

I'm a little interessed since my first encodes are AR wrong (I kept full D1 res without resizing to 1:1 AR) so I have to resize maually while playing. While if there's a such program, I just demux video, change header (adding the 16:9 AR flag in the stream) and remux with its audio).

[sysKin]

Originally posted by symonjfox
But, is it possible (if someone write this kind of program) or is it a big hack, or an heavy work?If you would have any program that reads mpeg-4 data (but not mindlessly, actually decodes the bitstream) and then writes it back again, it would be easy to patch it.

The AR is only written in VOL header - this is the header that describes whole video stream, not any particular frame. If there was a way to re-write VOL headers only, and copy actual frames as they are (without decoding), it would be enough.

[symonjfox]

Thanks ...

[amango]

Maybe someone can write a patch-program - to make older xvid encodings compatible with standalone players? If this means you did not have to re-encode again, this would be great.