PDA

View Full Version : envivio vssh, h264 and mp4...help me :)


seishin
15th January 2004, 22:47
hi, i've read many sites about h264 to get an impression of the acutal status, and to get a working software combination for encoding and playback on my 1,3athlon (..i've nothin else to do ^^;;):

vanguard (http://www.vsofts.com/codec/h264_download.html) devolped a h264 vfw-codec with their own fourcc 'vssh'
- i've tested the VSSH264Codec10beta.exe because the vssh264preview61.zip isn`t working at my pc
- it's a very fine codec which need 24h to encode for a complete dvd on a 1,3athlon but the playback, in reference to their documentation, work only at 2ghz => i cannot watch the video without stuttering on my system *eg*, the fourcc is 'vssh'

openhdot264 (http://hdot264.sourceforge.net/), or the hdot264-vfw-implementation (http://rarewares.hydrogenaudio.org/mp4.html) is very experimental...it crashes all players by loading a test-avi which i created by this (maybe the yuv-to-hdd-thing is only experimental), the fourcc: 'h264'. and it's incompatible with vssh - codec( i don't know if vanguard produce only a 'like'-h264-codec)

jm74.zip (http://bs.hhi.de/~suehring/tml/download/) ..reference for all above: only creates .h264-files...fine because i cannot play them anywhere

i also found DSPR_264-Filter_10.exe (http://www.dspr.com/www/support/download/video_download.htm) on the net, this is the soft-decoder for the actual h264-hardware encoders but their .264-files(i don't own such a card, and i do not find a demo.264 on the net) cannot be the same like the .h264 files created by the reference-encoders

envivio seems to be the only company with a realtime-working-software-resolution and i tested EnvivioTV-H264-2-1-181.exe (http://www.vtc.com.vn/downloads/EnvivioTV-H264-2-1-181.exe|2781184|abdbafa1b1b0211d03b80785decf85f8|/), regarding to their website and some articles it could be that this player can show me my h264-videos BUT this player likes only h.264 from within mp4.i've mailed to envivio and get this answer:

<<Note that EnvivioTV is only a MPEG-4 player on which you
can decode H263 or H264 that are encapsulated in a mp4 files.
.avi or .h264 is not a MPEG-4 file.>>


so my question: which tool can put h264 into mp4...i tested all tools from bond's faq (http://forum.doom9.org/showthread.php?s=&threadid=62723) but they don't know how to use h264.

btw: the picture-quality is amazing compared to xvid&co

Sirber
15th January 2004, 23:28
any shots?

seishin
16th January 2004, 02:31
sorry...but i don't have the vssh-files anymore, cause they aren't compatible to 'real' h264 imho...i'll make screenschots until someone will give me a method for h264->mp4 ... eventually will mainconcepts release, planned for january, produce some stuff i need :)

bond
16th January 2004, 08:54
good to see that there is more and more interest coming up for h.264 as its really a great thing, especially when it comes to have an open standard to fight closed HD solutions, like wmv9

yep, as h.264 is part of the mpeg-4 standard the MP4 container is the native container designed for h.264
i wonder what hacks are once again necessary to put h.264 in AVI (i am sure even more than with "old" mpeg-4v2), but lets hope the idea of putting it into avi dies a fast death before it comes up too much (4cc troubles we already know could also be avoided aso)...

when it comes to muxing h.264 into .mp4 i am not that sure if there already exist working solutions (which are freely available) cause as you mentioned the available implementations are still experimental it seems
but you can also try the 3ivx muxer, mp4box, avgen from ibm... checkout my signature (mp4 faq) for a bigger list of tools

btw thanks for this list of h.264 implementations!

gino25
16th January 2004, 15:53
where i can download the last version of envivio?

Doom9
16th January 2004, 19:47
@bond: I have some h.264 content in AVI.. seems to work like a charm from what I can tell. Except for b-frames, MPEG-4 in AVI is no problem afaik and the b-frame issue has long since been worked out.

bond
16th January 2004, 20:06
well b-frames are not the only problem avi causes, like i said also aac is not possible without a hack in it and different fourccs will also cause a mess like we have atm with mpeg-4v2
avi is the evil reason when it comes to why different mpeg-4 implementations have interoperability issues

all-in-all i would prefer any smart container like matroska to be used with h.264 than avi being used again widely for mpeg-4 content


btw from what i found out the first already available really stable h.264 implementation (with stable creation tools aso) from envivio is also using mp4 only

lexor
17th January 2004, 03:32
so is there a fully functional encoder? maybe not a full commercial solution, but some tech-demo that can be used for evaluation? I'm not overly concerned with performance of it, as I only gonna test it on about 15-30 sec clips. audio is also not required. all I want is to see for myself what the hype is all about.

seishin
17th January 2004, 10:32
wow...such a fast and great response :cool:

i have updated the threadintro with some more or less direct links...hope that will help...

envivios player is turned into a comercial-interest-thing...not mor avaible for offical dl

@bond: i don't know if inoperability between different h264-codecs is only a prob of the wrappin-h264-in-avi stuff, i think they all cook their own soup like nero with the private-stuff in mp4 for the subtitle-shit...

bond
17th January 2004, 10:53
Originally posted by lexor
so is there a fully functional encoder? maybe not a full commercial solution, but some tech-demo that can be used for evaluation? I'm not overly concerned with performance of it, as I only gonna test it on about 15-30 sec clips. audio is also not required. all I want is to see for myself what the hype is all about.well read the first post for available encoders ;)
but i think its also necessary to note that these encoders are surely not tuned very much (maybe the encoder from envivio is better as they already offer it for sale)

Originally posted by seishin
i have updated the threadintro with some more or less direct links...hope that will help...cool! makes it easier for ppl who are too lazy to use google ;)

i don't know if inoperability between different h264-codecs is only a prob of the wrappin-h264-in-avi stuff, i think they all cook their own soupwell the specs are clear
you can only be compliant to them or not, so i think the main problems will be caused by avi in the future (and i guess atm the encoders, except envivio, are still very experimental to be able to start some compatiblity tests or so)

like nero with the private-stuff in mp4 for the subtitle-shit...well you also have to say that putting non compliant streams into mp4 is perfectly allowed in the specs, when using so called private IDs (thats what nero does)
you will never have any problems with neros mp4 files, the only thing that can happen is that the subs get ignored (btw from what i heard 3ivx also thinks about supporting the playback of these vobsubstreams in mp4)

lexor
17th January 2004, 14:17
well according to the first post all the encoders produce .h264 files that cannot be played anywehre. that's why I was asking, becouse he did say something about picture quality so he must have gotten them to encode in playable format. which one did you use seishin?

and that hdot264-vfw-implementation link to rarewares is an ICL compile (Intel Cmpiler), thus it won't work on AMD CPU.

alexnoe
17th January 2004, 16:34
Lexor: You claim that the compiler has, with a lot of work and only bad intentions, be designed to create locally self rewriting code, or that the code requires a Pentium 4.
Do you have any proof?

lexor
17th January 2004, 16:44
I claim what? sorry I don't understand. But what I said was that is says right there on that page that its "ICL7" which means that it has been compiled on a Pentium CPU using Intel Compiler version 7 using Pentium only Assembler instructions. In general that means the program won't execute on a non-Pentium CPU. I have AMD that means it won't work.

What are you saying about self rewriting code? I never heard of that.

alexnoe
17th January 2004, 16:48
Lexor: I have described the only 2 possibilities to create code running on a Intel CPU, but not on any AMD. Especially does any newer AMD have every instruction which an Intel Pentium has. Actually, the Pentium has, compared to an 80486DX4, only one new general use (i.e. can be used by normal apps) instruction, which is CMPXCHG8B.
What are you saying about self rewriting code? I never heard of that.It means that the code, after loading it into the memory, is changing itself. This does sometimes not work properly on AMDs if this happens very shortly before the code is executed.

lexor
17th January 2004, 16:57
ok I'll download and test it out, but at University programs that I create for my Scientific Computation course (in C++) that are compiled using ICL7, don't even run let alone run correctly on my Athlon at home. From what my professor is telling me that is because it utilises some instructions that are handled in microcode (you knwo L1 Code, L1 Data, L1 Trace chaches? it's the instruction in Trace one) basically AMD doesn't have those. I'm not talking about SSE/MMX etc. instructions.

anyway I'll try.

alexnoe
17th January 2004, 17:02
Either the Intel's have undocumented instructions, or the developers of the compiler have added additional checks to make the program fail on AMD CPUs.

A processor should never allow to access microcode by any app!

Kurosu
17th January 2004, 17:58
Originally posted by lexor ok I'll download and test it out, but at University programs that I create for my Scientific Computation course (in C++) that are compiled using ICL7, don't even run let alone run correctly on my Athlon at home. From what my professor is telling me that is because it utilises some instructions that are handled in microcode (you knwo L1 Code, L1 Data, L1 Trace chaches? it's the instruction in Trace one) basically AMD doesn't have those. I'm not talking about SSE/MMX etc. instructions.huh?
For calculus, what you can use and what you can not is essentially clear:
P3 has full SSE instruction-set. So does Athlon XP and further.
P4 has SSE2 and maybe some additions, which it only shares with Athlon64. Older Athlon only have iSSE, no floatingpoint SSE. I don't know for the cache management/scheduling but prefechnta, prefetcht0/1/2 and probably sfence/mfence are included as part of iSSE, and I don't see many more. However, I highly suspect a SSE2 instruction executed on an Athlon XP or older, or float-SSE on old Athlon.

But people not reading the docs and firing the compiler will end up generating specific P4 code. I perfectly recall options like Qa<somethink> or /G<something> doing perfectly the job of not generating uncompatable code, or producing the correct code able to branch to the correct CPU path.

There are a bunch of programs around there compiled by ICL7 and working on Athlons, Koepi's XviD for a starter.
Sorry for polluting this thread.

lexor
17th January 2004, 19:13
ok perhaps this post should be split, but I think it fits with the idea of presenting additional h264 implementations.

this seems to be something along the line of JM from the first post but older, however it requires to be compiled (has no precompiled .exe files in /bin directory) so I would like to add this and as well ask for link to compile instruction: or maybe someone with experience can do it? so I don't screw up :) I have a history of that...

TML8 (http://kbs.cs.tu-berlin.de/~stewe/vceg/archive.htm#TML8)


TMNPLAY: a player for YUV concatenated Files which encoder produces:

tmnplay (http://kbs.cs.tu-berlin.de/~stewe/vceg/tools.htm)

this players does seem to play back the .yuv files that JM produced, but it all comes out as gebberish on the screen.

Tommy Carrot
17th January 2004, 20:10
If this thread is about h.264 related projects, we should mention x264 (http://lyra.via.ecp.fr/) too. Perhaps something useful can become from it.

bond
17th January 2004, 20:39
and not to forget: skal is also working on a h.264 encoder:
http://skal.planet-d.net/coding/mpeg4codec.html tough he didnt release any code till now it seems

unmei
17th January 2004, 20:42
From the h.264 implementations that i tested over time, the Vanguard is the one that is closest to 'usable' with its vfw inteface and (i think) DS decoder ..BUT this implementation cannot give you an idea of the power of h.264. IIRC the vanguard is a low profile only encoder, which means it doesn't use or drastically limits the most powerful algos. In my test's i were tempted to say it's quality is sort of a Xvid/RVX mixture which is already respectable (but dead slow). I expect h.264 encoders in a few years (1,2,3?) to be anorder of magnitude more efficient, a comparision to Xvid could then look like a comparision of DivX SBC to Xvid today. Well i fear h.264 will look more like RVX than Xvid as its once again a 'push the bitrate down' not a 'increase quali at same bitrate' codec. I expect the future choice to be MPEG-2 for hi bitrates (>2mbit/s), Xvid for medium (0.7-2mbit/s) and h.264 to take over the field currently ruled by RVX (<0.7mbit/s). Wild speculation tho :P

for the Intel compiler, i'm not well informed about it, but every binary i downloaded so far that was labeled ICL7 worked on my Thunderbird (Athlon-non-XP). Of course there are program that do not work because of if SSE but this has nothing to do with ICL.

Tommy Carrot
17th January 2004, 20:49
Originally posted by unmei
Well i fear h.264 will look more like RVX than Xvid as its once again a 'push the bitrate down' not a 'increase quali at same bitrate' codec. I expect the future choice to be MPEG-2 for hi bitrates (>2mbit/s), Xvid for medium (0.7-2mbit/s) and h.264 to take over the field currently ruled by RVX (<0.7mbit/s

H.264 should be better than mpeg4 ASP (xvid) at all bitrates.

lexor
18th January 2004, 00:25
1,2,3 years? but I want it now! plus this guys (http://www.lsilogic.com/news/product_news/2003_09_08.html) say they have it working now.

/edit:
oh yeah I completely forgot XBMP (http://www.xboxmediaplayer.de/info_project.htm) supports "AVC - Advanced Video Coding (H.264)" playback. which means XBox's CPU can handle it.(that's only 733Mhz)

bobololo
18th January 2004, 04:07
FYI

http://www.chiariglione.org/MPEG/working_documents/mpeg-04/avc/avc_vt.zip

This document gives interesting results on how H.264/AVC performs compared to mpeg-2/4. It also shows the very scientific methods MPEG used to make the tests. This could gives some idea to people looking for ways to compare different codecs.

seishin
18th January 2004, 05:06
i have read ffmpeg could play h264...but can anyone please explain me how to get a .[h]264-file playin on windows with this?

also i've looked at the "password only"-soft on the site of dspr, but the listed encoder and server are only frontends for their own hardware :(

Stux
18th January 2004, 06:27
Originally posted by lexor
1,2,3 years? but I want it now! plus this guys (http://www.lsilogic.com/news/product_news/2003_09_08.html) say they have it working now.

/edit:
oh yeah I completely forgot XBMP (http://www.xboxmediaplayer.de/info_project.htm) supports "AVC - Advanced Video Coding (H.264)" playback. which means XBox's CPU can handle it.(that's only 733Mhz)

Actually, that just means that the XBMP purports to decode it. It makes no reference to how well it decodes it, or at what resolution. Perhaps it only handles 320x240 ;)

bond
1st February 2004, 14:01
lo guys

bobololo gave me hint that .yuv files outputted by the reference decoder can be played with the following yuv decoder filter (http://www.ee.columbia.edu/~ywang/Research/YUVGenius.html) in dshow

check it out, i only get a green screen tough :(

bond
19th February 2004, 22:10
Originally posted by seishin
jm74.zip (http://bs.hhi.de/~suehring/tml/download/) ..reference for all above: only creates .h264-files...fine because i cannot play them anywherejust for completeness: the decoder from moonlight seems to play them as i reported here (http://forum.doom9.org/showthread.php?s=&threadid=71208)