SynchroTek Fairchild codec [Archive]

topsykrettz

20th June 2007, 23:21

Fairchild codec comparison

The setup:
Latptop Computer - Pentium M 2.13mhz 2meg l2 cache, 1.5gig ddr2 400mhz ram, 80gb 5400 rpm hd.

Encoder: Fairchild Encoder via virtualdub.

Comparison Codecs: Fairchild(alpha stage), x.264, divx 6.6

The test: 107,164kb Antitrust DVD trailer, SINGLE PASS encode

So what were the results?

Fairchild encoded the 107164kb original at realtime (144 sec). This was a manual limitation we set to emulate encoding in a live environment (fairchild is designed to stream source media live without buffering or significant latency, on top of the obvious VoD/Solid-state uses). Once again, this is a single pass encode for the above reasons.

DivX 6.6 was set to single pass and high speed to reflect the quality difference at the same encode rate, and finished out at 140 seconds total encode time.

X.264 could only achieve a 293 second encode time using the fastest settings, but it's kept in the comparison for the sake of integrity of the test, even as the encode time was roughly double the final quality was only marginally different, a little inferior to fairchild but slightly better than DivX.

Mpg4 format was arbitrarily as fairchild is capable of rendering under any format type.

The encoded files are available below to allow you to verify the results of this test which were thus - Fairchild performs significantly better than the latest versions of both DivX and X.264, using a magnitude less system resources to encode, and a higher visual quality in smaller stream rates. Fairchild has vastly less macroblocks than either X.264 or DivX6.6. making the viewing 'experience' closer to that of a solidstate dvd. Macroblocking has been almost entirely eliminated in the latest development version of Fairchild, but that's not ready for primetime just yet.

X.264 is fairly consistent throughout the entire demo, suffering from the usual colour shifting, and horizontal slicing we've come to expect. This is acceptable in low motion scenes, but becomes an irritation and obscures the picture in the faster paced action sequences.

DivX6.6 starts off OK, but starts to break down half way through, completely falling to pieces and sobbing on the floor by the end of the demo (it's unwatchable).

Fairchild demonstrates superior video quality throught out the entire demo, with the only inconsistencies being a couple of (literally) split second transition scenes (fades) where tiny macroblocks are visible if you're really paying attention.

Things to note, are the CPU usage Fairchild has for rendering vs x.264 and divx, as well as the colordepth, detail level, no blending of hairs, or blotching colors, or the horizontal line blocking of h.264.

Two things to note in playing these videos - Fairchild uses a world-first intrinsic decoding system which allows the file to be played without downloading seperate decoder files. The files you get are the files that play. For the time being, post-processing isn't controlled by Fairchild so you'll need to ensure that this is turned on. Because this is primarily a live streaming format, it works best in VLC.

http://www.mediafire.com/?4fd2uzr0bn1 - Fairchild_Codec_720x480_24fps_144sec_singlepass.mp4

http://www.mediafire.com/?9cvfx4n2nmz - h264_720x480_24fps_fastest_244sec_singlepass.avi (22.06 MB)

http://www.mediafire.com/?5pnlie2tym3 - divx66_720x480_24fps_140sec_singlepass.avi (21.02 MB)

http://www.mediafire.com/?3jd3gmgxnye - divx66_720x480_140sec_singlepass.avi

http://www.mediafire.com/?0x5xgsedxt0 - h264_720x480_fastest_293sec_singlepass.avi

http://www.mediafire.com/?el9ydedamm9 - Fairchild_Codec_phone_176x144_15fps_singlepass.mp4

http://www.mediafire.com/?emgp7d2xf9x - Fairchild_Codec_320x240_24fps_singlepass.mp4

Also a bonus - to date, due to the unique way fairchild operates, it has played on any mobile media device we've tried (mp3-video players, cellphones), without any file modifications or reprocessing, and has done so without stressing the devices system in any way, I guess I don't need to suggest how important that is in the future video.

Remember - Fairchild requires post processing to be turned on, and this is a test of real-time video quality, not your more pedestrian multi-pass lets-wait-3-hours-for-our-video-to-encode quality. ;)

Enjoy.
Synchrotek Inside-man, Topsy Krettz

foxyshadis

21st June 2007, 05:03

Why did you IVTC the fairchild but not the AVC or Divx encodes? Didn't you or your engineers realize when you saw the interlacing that you needed to deinterlace or ivtc? (They appear to have been improperly force film'd, some clean frames missing while other interlaced frames passed through. Probably made by gordian knot by someone following a guide online for their first time?) You also coded the fairchild squeezed down to 720x314 active area, but the divx and h.264 are 720x372. Even still, the h.264 managed to look quite a bit more detailed, for people who like to watch things fullscreen (the youtube crowd doubtless wouldn't care).

This is the equivalent x264 commandline used (since this was made in vdub), for interested parties:
x264 --ref 1 --filter 0:0 --analyse all --me hex --subme 1 --trellis 1 --8x8dct --threads 1 --bframes 2 --direct auto --weightb --bitrate 1024
Which is not really the fastest (for total raw speed an ASP codec like yours makes a little more sense anyway) and of course doesn't include --interlaced on an obviously interlaced source. Was any kind of filtering performed during the encode that wasn't performed for fairchild, also? (The defaults of gordian knot include certain filters that slow the encoding down, which may explain why you had to crank the normally very fast divx down to fastest; I'll admit it looks pretty horrible there.)

I welcome quality comparisons, but if you're going to sell a forum full of gearheads on something that sounds suspiciously like vaporware, you need to tighten up your methods and provide totally reproduceable steps instead of cheating, by ignorance or malice. Especially to imply that h.264 created the "horizontal slicing we've come to expect" shows a shocking lack of knowledge about video fundamentals that will get you laughed out of any studio you try to sell to, even if some smaller operators might be bamboozled.

The most important step would be to provide a sample of the source, then it's easy to determine how much is lost in each encode. If that's not important, you can get the h.264 filesize much lower and still have minimally accceptible quality than you can mpeg-4 sp.

By the way, why do you say things like "due to the unique way fairchild operates" and "world-first intrinsic decoding system"? It's simple profile MPEG-4, many variations of it have been around for a long time, via divx and itunes especially, and there's nothing revolutionary about it at all.

CruNcher

21st June 2007, 05:24

@topsykrettz
Wich investor do you think you can spoof with that slides :P
and look @ those samples jesus it's plain Mpeg-4 that you compare with VPX and the others, are you crazy :D
No one is gonna belive you stay with the truth, you makeing complete idiots out of yourselves lol the IPTV market is dominated by WMV9 and H.264 currently and you come with this Mp4 encodes that say absolutely nothing, that's realy crazy and funny @ the same time :D.
I think your some marketing Students who try a Viral Marketing campaign to see how much success you gonna have with this nonsense but hey just to inform you, that's out and this is Doom9 makeing such nonsense official here to be spreaded arround is plain dumb ;)

topsykrettz

21st June 2007, 06:42

The videos were made by me in the hour I had access to the encoder laptop. I am by no means an engineer (actually I'm in finance, of all things), but I do like to play with video tech on the side occasionally. I basically just loaded up virtualdub, and knocked out the few comparison's to go with the Fairchild one. I have been semi-permitted to drop these fairchild files out into the public to see the public reaction, and so far it seems to be that of disbelief, or that it's a standard mpeg-4 codec. So they don't really quite know this thread exists.

I'm obviously interested in showing what they have in the best light. Having seen it on multiple occasions, and having seen the code, I can assure you that it's not just another simple profile mpeg4 codec. This thing was made (literally) in a garage in just over a year. You can verify this by doing some deeper analysis of the files provided.

That being the case, I've forwarded your comments on to my contact at the company who's going to give them to the engineers. If anyone would like to give me the _optimal_ virtualdub settings for h264 and divx, i'll gladly re-encoded them for you using the 100 meg .vob source. Likewise, I can acquire the Fairchild version in any preferred container.

I understand that all new things under the sun are met with the same disbelief and criticism, so I'm going to ignore the vapourware comments and instead provide you with whatever it is you require, in order to prove the validity of the codec as at the very least an equal contender to h264 (at which point it will no doubt succeed it). Also bare in mind, this is an Alpha-Beta codec - how many years have h264 and divx been in development?

So let me know what you need, and I'll do my best to provide it, or pass it on.

foxyshadis

21st June 2007, 09:48

In my opinion, the best way to quickly test both x264 and xvid (as a stand-in for divx here) with a minimum of time and learning investment is Handbrake (http://handbrake.m0k.org/). Load & encode, basically, no special ripping or settings needed usually. It might need deinterlace checked if that isn't auto-detected and comes out jagged, but it normally just works.

With the default settings, xvid and x264 will probably run close to how they did in your test, roughly realtime and roughly half realtime. Without b-frames, it'll be even more fair compared to your sample. To speed the x264 up even further, these options can go in the h.264 tab:
1.5x faster:
partitions=none:subq=1:me=dia:nr=500
1.8x fastest:
partitions=none:subq=1:me=dia:nodeblock:nocabac:nochroma_me:nr=500

Of course, by stripping out almost everything that made x264 useful in the first place, the last line makes almost a glorified mpeg-4 sp encoder and looks it. It's not seriously intended, just to show how fast the codec can go. (You also have, for instance, the ATI converter, which makes up for a lack of quality with insane speed.)

I do see that your codec incorporates some interesting adaptive quantization measures, though I can't pry too deeply into the bitstream. I do look forward to seeing what other areas it innovates in.

Apologies for being a bit harsh earlier.

Sergey A. Sablin

22nd June 2007, 04:17

I understand that all new things under the sun are met with the same disbelief and criticism, so I'm going to ignore the vapourware comments and instead provide you with whatever it is you require, in order to prove the validity of the codec as at the very least an equal contender to h264 (at which point it will no doubt succeed it). Also bare in mind, this is an Alpha-Beta codec - how many years have h264 and divx been in development?

you'd better spend your energy amongst silly investors, explaining them that MPEG-4 sp is somehow contender for MPEG-4 AVC. If you'd learn a bit about history of video compression you'll easily find our that mpeg-4 sp which is implemented in this codec was developed at the same previous century where divx was.
You'll be lucky if you'll manage to argue what could be that new in MPEG-4 SP comparing MPEG-4 AVC, baring in mind that MPEG-4 SP is prepredecessor of MPEG-4 AVC. And MPEG-4 SP is about 10 years older than AVC.

topsykrettz

22nd June 2007, 19:13

you'd better spend your energy amongst silly investors, explaining them that MPEG-4 sp is somehow contender for MPEG-4 AVC. If you'd learn a bit about history of video compression you'll easily find our that mpeg-4 sp which is implemented in this codec was developed at the same previous century where divx was.
You'll be lucky if you'll manage to argue what could be that new in MPEG-4 SP comparing MPEG-4 AVC, baring in mind that MPEG-4 SP is prepredecessor of MPEG-4 AVC. And MPEG-4 SP is about 10 years older than AVC.

Sergey, I would agree with you wholeheartedly if the codec was just a simple mpeg-4 sp codec revised. Fortunately as I've mentioned above - it's not an mpeg-4 codec - period.

What you are seeing is simply the surface of the stream and the container; mpeg-4 was picked in this case because just about everyone has an mpeg-4 compatible player. The codec can be made to render on any existing decoders, if desired (a feature, if you will). It could clone AVC, or WMV, or even (hilariously) Mpeg-1 which was used in the very first trial runs. Since the container for Fairchild is completely arbitrary, you could feasibly take advantage of the various postprocessing and filters that exist for any codec.

I think the point of this demonstration may have been miscommunicated (it's been a really long week! roll on weekend...). As I mentioned above, the codec is being worked on out of a literal garage, after hours, after families have gone to bed.

That being the case, we can't afford to host a live streaming demo site where we can show that the codec can render 480p streams with almost negligible loss, from a live video source (hd camera, dvd, etc), with significantly minimal resource usage.

The purpose of thie demo was to show that even stripped down, current mpeg4-avc technology is too much of a resource beast to even come close to encoding realtime (it's forte lies in high end ripping, after all) let alone encode and stream realtime on your average computer.

What this translates to is not a codec for the consumer market, rather for the IPTV telco's who would stand to save millions on infrastructure through not having to pay a handsome sum of 1mil a piece for a TandbergTV encoder machine just to achieve a similar quality (as an off-the-cuff example).

Once I acquire an HD source from the company I will demonstrate that the cpu usage for rendering 480,720,1080 and up persists at a very linear scale, and will happily render a 720 stream with resources to spare on much less spec than a ghz box.

Unless you have some money or resources to lend us, we're stuck with using the small resources at hand, and that only allows us to create demonstrations like this.

That being given, what would it take, what kind of encode structure would you need to feel this is valid. A live streaming container?

Lay it out on the table and we'll do our best to create what the upper crust of the world's codec connoisseurs need to see.

Sergey A. Sablin

22nd June 2007, 20:33

Sergey, I would agree with you wholeheartedly if the codec was just a simple mpeg-4 sp codec revised. Fortunately as I've mentioned above - it's not an mpeg-4 codec - period.
yes, it is. if it wouldn't it won't be decoded by mpeg-4 sp decoders.

What you are seeing is simply the surface of the stream and the container; mpeg-4 was picked in this case because just about everyone has an mpeg-4 compatible player. The codec can be made to render on any existing decoders, if desired (a feature, if you will). It could clone AVC, or WMV, or even (hilariously) Mpeg-1 which was used in the very first trial runs. Since the container for Fairchild is completely arbitrary, you could feasibly take advantage of the various postprocessing and filters that exist for any codec.
that's make me think you don't understand that codec means COder+DECoder. If you're talking about any existent decoder, than what you're talking about is just some kind of postprocessing, not a codec - feel difference? And that's said it doesn't improve performance of encoder in any way and has nothing to do with a word codec.

That being given, what would it take, what kind of encode structure would you need to feel this is valid. A live streaming container?

Lay it out on the table and we'll do our best to create what the upper crust of the world's codec connoisseurs need to see.

even cheating with pulldown encoding doesn't help you - improperly encoded AVC stream noticeably better than yours anyway. And that's how it should be - because AVC was designed to outperform any previous standard. And there is no way to show that mpeg-4 sp better in quality than mpeg-4 asp or H263++ or AVC, or even VC-1. Just no way. And there is nothing to talk about until you understand this pretty simple logic.

Wilbert

22nd June 2007, 22:09

And that's how it should be - because AVC was designed to outperform any previous standard. And there is no way to show that mpeg-4 sp better in quality than mpeg-4 asp or H263++ or AVC, or even VC-1. Just no way. And there is nothing to talk about until you understand this pretty simple logic.
Then I take it that you have evidence that AVC is better than ASP or MPEG-2 for medium and high bitrates. Where is it?

Sergey A. Sablin

22nd June 2007, 22:58

Then I take it that you have evidence that AVC is better than ASP or MPEG-2 for medium and high bitrates. Where is it?

for medium ones it is for sure. for high bitrates one need some tricks, as AVC includes all tools which exist in MPEG-2 and ASP I personally see no reason why AVC should be worse than these too.

Theoretically all codecs will saturate at very high bitrates, that's obvious, entropy of the signal will be the limit. But there is no situation where AVC could be worse there as it may use exactly same tools as previous specs - 8x8 DCT, no loop-filtering, half-pel motion estimation. Using CABAC and context adaptation plus better motion vector prediction and intra prediction will save couple of bits anyway.

BTW - here is a talk about sub medium btrates as far as I see from sample streams ;)

Wilbert

22nd June 2007, 23:18

for medium ones it is for sure. for high bitrates one need some tricks, as AVC includes all tools which exist in MPEG-2 and ASP I personally see no reason why AVC should be worse than these too.
Once again, i'd like to see some evidence for both assertions.

Sergey A. Sablin

22nd June 2007, 23:36

Once again, i'd like to see some evidence for both assertions.

any kind of samples wouldn't have any prove, cause anyone may argue that this is just a sample which doesn't prove anything.
The only thing which can prove efficiency of AVC is that it is an superset of previous standards plus several new more efficient tools. And I can't understand your point, why using same tools + more effective entropy coding and prediction can make AVC anyhow worse than previous standards? What needs to be proven here?

Manao

24th June 2007, 21:05

Though I strongly with Sergey, you can't make an ASP-equivalent encoder out of an AVC one. Half pel, intra prediction, DCT & quantization are different.

And the biggest problem when it comes to high bitrate comparisons is that everybody is using mpeg2 sources, which completely bias such comparisons.

I still think a high bitrate ASP encoding will look closer to a mpeg2 source just because it will exhibit the same type of artifacts.

But there's imho no question as to the superiority of AVC on an unprocessed source, whatever the bitrate.

Of course, the problem is that almost nobody has access to such sources. DV is roughly equivalent to mpeg2 intra only, so it bias towards mpeg2/ASP. All DVDs are mpeg2, and HDDVDs/blurays encoded in AVC will doubtless bias toward AVC...

Blue_MiSfit

24th June 2007, 21:57

Those are some good points Manao.

I think this codec could be interesting, mainly due to its supposed simplicity and lightweight nature. Of course, I believe nothing until I have either a CLI encoder or a VFW codec that I can sink my teeth into and really compare with my existing workflows.

If it can encode and decode 1080p24 (at less than 10mbit) in real-time on a slower Pentium 4 or Athlon XP, and look good, I will be very impressed. There aren't many easy on the CPU, streamable, high quality video codecs out there.

This brings up a very big question. How does your customer play a video? If he has to install a plugin, anything beyond QuickTime, RealPlayer, or Flash, you're probably asking too much. Are you going to create your own decoder? It sounds like this codec is based on MPEG-4 SP, but that it has a lot of its own specific extensions, like VC-1.

~MiSfit

Hellworm

28th June 2007, 21:49

What you are seeing is simply the surface of the stream and the container; mpeg-4 was picked in this case because just about everyone has an mpeg-4 compatible player. The codec can be made to render on any existing decoders, if desired (a feature, if you will). It could clone AVC, or WMV, or even (hilariously) Mpeg-1 which was used in the very first trial runs. Since the container for Fairchild is completely arbitrary, you could feasibly take advantage of the various postprocessing and filters that exist for any codec.

So you mean the real feature is that it can produce an output for different standards and decoders. So my question is can you provide us fairchild samples of the same input as asp,avc and mpeg1? And does it need to transcode again for the different output formats, because that would make it simply a flexible core width still fixed output (like libav) or does it "translate" the multiple formats from the "real" fairchild stream?

And - still assuming that it does the latter - it can still be only as good as the selected format, and from the samples you provided it isn't that good. Rate control seems to be borked, after a scene change there are very low quality frames and later it becomes better, looks like pure cbr on frame basis or something like that.
And doing some tests with the samples you provided, not only seems the avc sample to be of better quality, but also does libav (through mencoder) provide similar quality with asp, though much more consistent, but also does it 3x realtime on my pc. And that's utilizing only one core.

*.mp4 guy

30th June 2007, 06:13

The rate control looked like it was doing (a fairly respectable job) staying within streaming vbv requirements, which is why I-frames were heavily compressed, if they were compressed less it would cause lag/stutter in a streaming environment, which is aparently what this compressor is optimized for.

Hellworm

1st July 2007, 17:21

Looking at it this way it really does a good job, thought still not impressing.
But I still like to know what should be so special about this encoder. Seems like topsykrettz has gone away.

topsykrettz

12th July 2007, 02:20

Hey all

Sorry for the delay in replying. I had been trying to get ahold of the head guys at Synchrotek to find out more information and run your comments past them. Unfortunately (for me, not them obviously.. haha) they've been occupied presenting technology demo's, so obviously very busy.

I did find out a few interesting tidbits of information which I will outline below as I'm sure you're all very busy people...

Firstly, I didn't stress the setup of the system i was using. Due to my lack of knowledge of the exact mechanics regarding how codecs fit together (as I mentioned previously, i focus on the money side of things - ie. what the net effect advantages yield, not how they work..) and my rudimentary knowledge in this arena was for certain not enough. The command-line encoder he had put on the laptop and set to task to encode; I was under the impression that it was encoding a VOB from my hdd, that he had put on there with the usb key so I could reproduce the tests with other codecs. This, it seems, couldn't be further from the truth. What I failed to be aware of was that it was encoding the source file via a stream set up from another computer, to my laptop. In other words, _Real-time encoding the stream_ to a file, mpeg4 by my request, to my hdd.

It's now been explained to me that this is much different than the comparables I was setting up. Based on the thread comments I showed him, he explained that what the forum members here were talking about was a bit different - creating solid state files from pre-existing raw files using compression and filters, without the time and resource constraints of live delivery. What he had the CLI encoder set to do was a _worst case scenario_, that is, the quality yielded in the worst possible conditions - a realtime stream of the codec, no deblocking or filters applied, just a straight pass-through encode. The reason for this is because "in the real world" investors and partners are less interested in the 10% of the time best case scenario, and more interested in what the low end of their customer base would see (by this you can judge the high end with little difficulty) - a more realistic method of evaluating worth. So again.. my lack of knowledge (sorry guys!) i didnt realise, that even when i turned off as many settings as i could, Gordian Knot and even Handbrake have filters on by default that enhance image quality, and turning this off via CLI is way above and beyond my level...

In any event, I did manage to get a word from their CTO, who had some things to say on the topic, which I'll post here;

Dear Sergey,

I have read your commentary on our technology and felt obligated to respond in kind. A few things that I should point out, while you obviously have a handle on the entire technology surrounding video processing and we did spend a reasonable amount of time analyzing your diatribe, I must refer you to the one thing that I think you missed regarding what we are doing, namely streaming video over the internet. While your comments I think are valid for studio production of DVDs and high end video, they don't really apply to our technology to the same degree. Our objective was to push live streaming video over the web at the highest possible rate, with the best compression possible and the highest quality possible for the compression used, all the while reducing the infrastructure costs to do the streaming. Yes of course we can ramp up quality by sacrificing speed and get into the same realm you speak of, but that is not our mandate.

Another aspect of our codec is the business model it will be used under. Primarily it is intended for ISPs and video carriers who wish to push IPTV. While they would love to use only the highest quality possible, thereby providing the best for their customers, there is a tradeoff of quality for performance and as such the balance must allow for them to reduce their infrastructure costs while maintaining reasonable video and audio quality for IPTV. The customers by and large are not likely to have as critical an eye as you do, and will likely never notice the quality as being anything but most acceptable from their perspective.

One last item I should mention is that of a business model. While everyone is adamant about quality, there comes a point where it is simply not profitable to provide the quality when it will never be noticed other than by the latency for this medium. It’s a little like putting a large block V-8 engine into a VW bug, it tends to be overkill and you can never take advantage of it. So with that in mind, we determined that providing acceptable quality for streaming at very high speeds with compression that would allow for the stream to be serviced by an infrastructure far leaner than what is currently being used and providing content management as well as a form or DRM that would allow the ISP to manage illegal copying would be the best way to service this industry.

We appreciate your input and look forward to hearing from you in the future. Perhaps when we launch this you will be able to gain a complete understanding of what we have to offer. Until then we are obligated to not release our codec or other proprietary information with regard to our processes. I am sure you can appreciate this aspect as well.

Sincerely,

BG
CTO Syncrotek Labs

I have been informed today that improved demo's have been created and I will post them once I get my hands on them (and the OK from synchrotek, hehe). The synchrotek site has also been updated, and there's a much clearer outline of the company's technology and goals here; http://synchrotek.com/index.php?synchro=technology

Since they're now in talks with a handful of companies (I'm not allowed to mention any names, but I guess I can slip that they're major corporate entities in the tech sector) I'm now under an NDA ;) This means that I won't be able to freely give out inside information anymore, so most things will have to be run back to them before I can reply.

CruNcher

12th July 2007, 05:50

Now this makes alot more sense, so they develop ways for Video Codecs to improve CBR quality (Streaming) ?
From that point the Antitrust Sample is not bad but the bad I frames are a Problem the guys behind this must have not thought about, when takeing bits from a scene cut it is very heavily percieved HVS wise, try to save some bandwith by takeing bits before the GOP ends, but not @ the scenecut it's to heavy as HVS optimization if you don't do it partition wise, but like this for the whole frame and so extreme, anyway i think that H.264 is allready very good for Streaming (with some fine tweaking of tools and balanceing in Encoding/Decoding Speeds and Quality) and SVC will be even better in terms of scaleability to the infrastructure, wish you good luck with your optimization work for this area and your complete platform idea behind it.

topsykrettz

15th August 2007, 00:58

http://www.synchrotek.com/index.php?synchro=demos So I dont need to play messenger anymore :) They have some demo's up, 2 to demonstrate compression, 2 to demonstrate cpu usage, the HD, which is pretty impressive, played it on my laptop no problem with Mplayer and changed the cpu multi so i was clocked at 800mhz. Not many codecs can say that. The source even uses more cpu. http://www.w6rz.net/ed24p_03.zip ( http://www.w6rz.net/ed24p_03.zip)

take a look.

And encode times for perspective, with the hardware we have available.
Realtime on an Amd 4200 , and an intel allendale.
Comparitively mainconcept is 6.5 to 1 realtime
http://www.synchrotek.com/_tmp/mainconceptcpu.png

CruNcher

15th August 2007, 11:58

Cool that the Fairchild guys use Antitrust for testing (used it to for EDP testing tweaking hehe), but hey comeon you compare Mpeg-2 with H.264 here now ? H.264 can be lowered in complexity too with some tweaks, even the demos on their side prove nothing from a scientific point :P and to use Mpeg-2 or ASP on a low bandwith network seems odd to me (without pp at least) and your Antitrus sample as said is HVS wise wrong it hurts my eyes badly @ every cut so why did you use a "trailer" here for showing this off ?)
If i had a boss in a Mediacompany for example IPTV broadcaster i would tell him send this guys home from where they come their are better solutions these days with better quality ;)

I do 720p tweaking @ 800 mhz (x86) with H.264 (x.264) CoreAVC/Libavcodec/Hardware PV1 as base @ the moment and i can say it works perfectly no problems here (it's about how much knowledge you have and are into the matter and also expirience with it and a key factor is time/patience you need alot of this) but i never thought a minute about selling this as a new technology or product that sounds moral wise not right especialy seeing all the devs of the core technology behind that working on the real chalenges (Codec tweaking and testing is a chalenge too tough).

Somehow i still don't understand what they write on their website faq how does all this fit together ?

Is fairchild based on any pre-existing codec technology, such as AVC / ASP / VC1?
No - it is a totally new way of looking at the video delivery process. Fairchild uses a dual-part system, with an intelligent receiving end. The processes involved in the delivery of fairchild video is nothing like the standard methods currently implemented by conventional codecs, which merely decrypt / uncompress video data. SynchroTek recognised the issues of conventional video codecs, and chose to re-invent the video delivery process altogether.

How does Fairchild differ from other codecs currently on the market?

- Error protection therefore less prone to artifacting at high and low data rates.
- Low back end server requirements.
- Low latency and low cpu requirements conducive to VOD and Fast channel switching.
- Complete software based encode and decode therefore transferable to any DSP with updatable capability.
- Unlike any current codec system, and therefore ownable in full, without having to share patent rights with competitors.
- Highly resistant management prevents stream ripping, letting content providers rest assured.
- Comprehensive content management, allowing targetted advertisements, marketing and demographics information.

What devices will Fairchild render on? Could Fairchild Encoder be implemented into cellphones and mobile devices?
Cellphones, PVRs, Desktop computers, laptops, PDAs, STBs - Fairchild will render on pretty much any device capable of display video. Due to Fairchild's unique ability to mask as other codecs, implementation can be seamless and swift, without the need to push new firmware. SynchroTek has tested a variety of cellphones and mp3 players to date, all of which have rendered the fairchild video flawlessly.

First you read it's a "new technology" then it's a "network improvement" an in the last it seems to be somekind of "algorithm for improving current codecs that can even transform (mask) itself into other bitstreams, how odd that sounds" so the hell on wich layer is this based on the Network Layer ? Bitstream ? (compatible with all of the shown codecs (website) on the decoding side would seem strange for bitstream ok not if you somehow shrink the bitstream and recompress it on the reciver side but this would't lower the complexity the other way would be the case)

So in the end my conclusion would be Network Layer somekind of a new Protocol that alters video bitstreams somehow and makes them less complex "nahhh that sounds strange"

slavickas

15th August 2007, 16:26

in short very cheaply made scam, from people who don't understand anything about video compression to people who don't understand it too. any doom9 member with 100+ posts should see that

Atak_Snajpera

15th August 2007, 16:43

http://www.synchrotek.com/index.php?synchro=demos So I dont need to play messenger anymore

All clips were encoded using existing codecs (Windows Media Video , MPEG2 , MPEG-4) so everything is a BS!!!!!! I would ban this guy imediatelly. ADMIN!!!!

topsykrettz

15th August 2007, 19:40

All clips were encoded using existing codecs (Windows Media Video , MPEG2 , MPEG-4) so everything is a BS!!!!!! I would ban this guy imediatelly. ADMIN!!!!

The clips are not existing codecs.. they are using existing containers to decode.
Look inside the stream you ll see its not mpeg 2 or mpeg 4 or wmv, it merely uses those containers to decode the video inside, hence the interoperability of any device. A fairchild decoder is in the works and will improve quality, as we are limited by the container atm, but that includes security and content management which isnt being released at this time.

As for the antitrust clip, it was meant to show the envelope of a single pass on a home computer. The codec scales, with a tandberg box the bit rate would shrink, and quality would improve and stay realtime, but this is the limit of the hardware, and we are showing it as such. This is for iptv live content, stream integrity, mobile devices, and WEb Conferencing. As well as h.264 doesnt have inbuilt content management or security, at the cost less than 1% bandwidth overhead..

As for the cpu usage on decode, if tweaking h.264 for 800mhz, 1080i or 720p is that easy, its a surprise none of the online content , ie 1080 trailers can render on those boxes, i think its possible, but that still doesnt circumvent encode time. This is targeted at LIVE STREAMING, not high quality multipass encodes. In the works is a system to do just that, for pre-encoded content.

I would like to see, on a equally spec'd computer, a h.264 encode realtime, that stays together image wise, and will render on a pentium 3 without a problem.

topsykrettz

15th August 2007, 20:15

Cool that the Fairchild guys use Antitrust for testing (used it to for EDP testing tweaking hehe), but hey comeon you compare Mpeg-2 with H.264 here now ? H.264 can be lowered in complexity too with some tweaks, even the demos on their side prove nothing from a scientific point :P and to use Mpeg-2 or ASP on a low bandwith network seems odd to me (without pp at least) and your Antitrus sample as said is HVS wise wrong it hurts my eyes badly @ every cut so why did you use a "trailer" here for showing this off ?)
If i had a boss in a Mediacompany for example IPTV broadcaster i would tell him send this guys home from where they come their are better solutions these days with better quality ;)

Again, if you look deep into the bitstream you will see its not mpeg2 its merely the container we used to demonstrate our codec in. This is not a conventional codec, and it is not assembled in a conventional way, which is why unless under close analysis it is difficult to see.

Again for the 1mbps, this was to show the compression limit on (intel box used for non hd) our hardware. It will scale, an octacore clovertown for example would improve us immensely, however we dont have access to hardware of that kind yet, so using this set up "The demonstration videos below were created by streaming DVD data across a 100Mbps ethernet network, encoding real-time at the receiver box*." this is what we could achieve. The bitrate could have been increased to 1.3-.1.4 and have had 0 artifacts, but this was meant to show 1mbit is achievable on this hardware.

I do 720p tweaking @ 800 mhz (x86) with H.264 (x.264) CoreAVC/Libavcodec/Hardware PV1 as base @ the moment and i can say it works perfectly no problems here (it's about how much knowledge you have and are into the matter and also expirience with it and a key factor is time/patience you need alot of this) but i never thought a minute about selling this as a new technology or product that sounds moral wise not right especialy seeing all the devs of the core technology behind that working on the real chalenges (Codec tweaking and testing is a chalenge too tough).

I can appreciate the challenge of that, since i havent been able to find any online hd content (in the form of trailers) that will render on my 800mhz. All the 1080i content i ve come accross crashes out, when i try to run it. Now when you say patience, that requires tweaking for every video? Industry wants a solution that just renders, regardless of the video, and this does it realtime. This is not for finesse encoding, which i agree, is definately an art. This is designed to fill the security gap, content management gap, and live encoding gap that exists in iptv, and other online content sources. As for preencoded streamed content, h.264 does have a high degree of quality, but at the decode end, has a high degree of hardware demands as well, same with wmv, just look at microsofts old iptv boxes that melt basically, which is why they are now all SOC, and even still they are having delivery issues with AT&T's uverse.
The idea here is... we are just out of alpha development, there are 5 people in the company at the moment, and we are working out of our homes.. in the garage so to speak, we havent had 10 corporations best minds take 5 years to develop..h.264 for example... but what are the possibilities when they do get a chance to improve it. Think of divx, or wmv9 or h.264 in its infancy, and look how much they progressed. This is not a finished or fully developed codec, this is a just into beta stage media platform.

Somehow i still don't understand what they write on their website faq how does all this fit together ?

First you read it's a "new technology" then it's a "network improvement" an in the last it seems to be somekind of "algorithm for improving current codecs that can even transform (mask) itself into other bitstreams, how odd that sounds" so the hell on wich layer is this based on the Network Layer ? Bitstream ? (compatible with all of the shown codecs (website) on the decoding side would seem strange for bitstream ok not if you somehow shrink the bitstream and recompress it on the reciver side but this would't lower the complexity the other way would be the case)

So in the end my conclusion would be Network Layer somekind of a new Protocol that alters video bitstreams somehow and makes them less complex "nahhh that sounds strange"
Strange can be true. This isnt conventional, and its not just a codec, we have security and rights managment built in, to this, that will be active when we release our decoder, atm we are just demonstrating the video aspect of our offering, in conventional containers so it can be viewed. Again, because we put our data into a container, does not necessarily mean it is mpeg2 per say, we have data in the stream that translates data to render on whatever the containers prefered decoder is. a double handshake if you will.

Again to re-iterate, this is a beta stage codec, that is meant for realtime applications, not multi pass encodes as of yet. Please compare it as such. And we welcome any suggested improvements:thanks:

Atak_Snajpera

15th August 2007, 20:21

Look inside the stream you ll see its not mpeg 2 or mpeg 4 or wmv,

I don't have to look inside the stream to tell that two clips have MPG2 FourCC , third has WMV2 (Windows Media Video 8) and the last one has MP4V (MPEG-4 ASP).
In my case MPEG2 clips are decoded by libmpeg2 , WMV by libavcodec wmv2 , libavcodec mpeg4. You won't fool nobody here. We are not group of idiots...

we have data in the stream that translates data to render on whatever the containers prefered decoder is
Hahahahaah!!! I have to admit you have wonderfull imagination.

topsykrettz

15th August 2007, 20:42

I don't have to look inside the stream to tell that two clips have MPG2 FourCC , third has WMV2 (Windows Media Video 8) and the last one has MP4V (MPEG-4 ASP).
In my case MPEG2 clips are decoded by libmpeg2 , WMV by libavcodec wmv2 , libavcodec mpeg4. You won't fool nobody here. We are not group of idiots...

Hahahahaah!!! I have to admit you have wonderfull imagination.

We are not trying to fool anyone here, if you read above in the thread, we ve already discussed this issue before, just because it uses those decoders, does not mean it is that codec, its not imagination, that is what we are doing. I m not understanding the hostility to be honest.:confused:

Sergey A. Sablin

15th August 2007, 20:43

Again, if you look deep into the bitstream you will see its not mpeg2 its merely the container we used to demonstrate our codec in. This is not a conventional codec, and it is not assembled in a conventional way, which is why unless under close analysis it is difficult to see.

once again - it is standard mpeg-2 video, standard wmv video, standard mpeg-4 sp video. muxed into standard mpeg-2 program stream, standard MP4 file format and standard WMV. nothing else.
nothing new, nothing special, nothing at all.

edit: in case somebody fools you that it is something new - just open it in http://elecard.com/products/products-pc/professional/streameye-tools/ to look inside very deep of the stream.

Atak_Snajpera

15th August 2007, 21:18

I m not understanding the hostility to be honest.
You are trying to sell something what doesn't exist! It exists only in your imagination. That's all! Listen We were not born yesterday to believe in everything what is on Internet,TV... You have chosen wrong forum...

topsykrettz

15th August 2007, 21:55

once again - it is standard mpeg-2 video, standard wmv video, standard mpeg-4 sp video. muxed into standard mpeg-2 program stream, standard MP4 file format and standard WMV. nothing else.
nothing new, nothing special, nothing at all.

edit: in case somebody fools you that it is something new - just open it in http://elecard.com/products/products-pc/professional/streameye-tools/ to look inside very deep of the stream.

Like we discussed before, unless i m missing something, this is showing the breakdown of quantization, yuv etc based on the decoder it is using. if you look into the bit stream you will see our compression and pixels do not move in a square shape.. it appears this analyzer assesses the decoder and wrapper, then overlays the appropriate breakdown based on those factors.

again, it is not just an mpeg2/mpeg4/wmv. we could easily show this with source code, and live demonstration, unfortunately sergey, we can afford to do neither for you.

topsykrettz

15th August 2007, 21:57

You are trying to sell something what doesn't exist! It exists only in your imagination. That's all! Listen We were not born yesterday to believe in everything what is on Internet,TV... You have chosen wrong forum...

Again, we are not trying to fool anyone, this endeavour would be a waste of our time if we were just rehashing old codecs, and we are not trying to insult anyones intelligence or expertise. I can only go by what we are doing, not by what others have done.

Again we are using our own codec, with wrappers that exist so it renders.

Leak

15th August 2007, 21:59

I m not understanding the hostility to be honest.:confused:
Yeah, I think you'll find that this happens to a lot of snake oil salesmen... :rolleyes:

we have data in the stream that translates data to render on whatever the containers prefered decoder is.
And there I was, not knowing that MPEG2, MPEG4 and WMV data streams were actually all Turing-complete, which they'd have to be to facilitate such a miracle. So did you go fetch your Nobel prize for that discovery yet?

Granted, I don't know who your usual customers are, but some people here happen to have a bit of experience in computer science, coding and handling video...

np: Fennesz - Chateau Rouge (Venice)

topsykrettz

15th August 2007, 22:19

Yeah, I think you'll find that this happens to a lot of snake oil salesmen... :rolleyes:

Thanks for the vote of confidence, Leak. You may wish to ask yourself why I am spending so much time trying to elaborate and clarify my position, when it's obvious that nobody on Doom9 is here to buy things. I came to show everyone something that I, and everyone else who's seen this, finds very interesting, but it seems a lot of people here would rather nothing but shout me down without even considering that what I'm saying may be true.

And there I was, not knowing that MPEG2, MPEG4 and WMV data streams were actually all Turing-complete, which they'd have to be to facilitate such a miracle. So did you go fetch your Nobel prize for that discovery yet?

I'm not sure why you're trying to propagate further misinformation, but I've never said anything even remotely close to this. Generally speaking, Codecs are contained in a wrapper yes? I'm not sure why it appears to be so difficult to comprehend that it may infact be possible to put different codecs inside different wrappers, by reconfiguring parts of the encode process. There are only so many parts of a wrapper/container that designate it's type. As I said before, we're choosing the wrapper - it's not some magical automatic process. Otherwise they wouldn't be in specified filetypes, no?

Granted, I don't know who your usual customers are, but some people here happen to have a bit of experience in computer science, coding and handling video...

I agree. I was hoping that some of them would be intrigued enough to actually look deeper into this than simply running things like gspot, avicodec, and sergey's elecard application which simply detect wrappers in the same way players do, which solves nothing.

IF someone was kind enough to outline the concise and exact reasons why they don't believe this, as opposed to naysaying, I would be obliged to do my best to answer. :rolleyes:

Milvus

15th August 2007, 22:41

Generally speaking, Codecs are contained in a wrapper yes?

Nope, codecs are software (or hardware) devices enabling creation or playback of an compressed audio or video stream. Do not confuse codecs and compression formats.

And since the samples you provided can be played by regular software decoders (VLC, MPlayer, FFMPEG...), it means every part of the file is standard-compliant : the container, the audio stream and the video stream. Otherwise, you would need to provide special playback software so we can test them.

It seems you want to promote special encoders who can output standard files, designed with new ideas for CBR optimization. If that the case, it certainly will be very interesting for many people here. But if you keep confusing everyone with strange technobabble, you'll lose all credibility.

we have data in the stream that translates data to render on whatever the containers prefered decoder is

if you look into the bit stream you will see our compression and pixels do not move in a square shape.

gspot, avicodec, and sergey's elecard application which simply detect wrappers in the same way players do, which solves nothing.

When i'm reading this, i have only one thought : "what the **** is he trying to tell us ???

Sergey A. Sablin

15th August 2007, 22:49

I was hoping that some of them would be intrigued enough to actually look deeper into this than simply running things like gspot, avicodec, and sergey's elecard application which simply detect wrappers in the same way players do, which solves nothing.

there is nothing deeper, then analyzing bitstream.
first of all you're trying to mix everything you ever know about video. Container is a wrapper - MPEG-2 PS, TS, MP4, WMV, AVI etc - you may place almost everything into them. The tools detect not only containers, but also inner bitstreams - video and audio.
In case of the streams on this site (for example mpeg2 stream) - container is recognized as mpeg-2 PS, this means it is follows all the rules of packing bitstream - this is only possible if muxer follows all the rules of mpeg-2 PS, which means that this is mpeg-2 PS muxer. Same for video - every bit was correctly recognized, ie syntax of the bitstream fully compliant with mpeg-2 video spec (and not any other, mpeg-4 or avc for example), which means it is was produced with mpeg-2 compliant encoder and not some magic encoder (whatever it's name). That's quite simple - there is nothing more deeper.

So what you are calling wrappers here? MPEG-2/4/WMV specifications?
At most what I can see here is that synchotek maybe made an implementation of mpeg-2/4sp/wmv codecs, but I have strange feeling seeing a lot of companies around with no information about their location, management etc on their own web sites, which take use of very known LGPL implementations...

topsykrettz

15th August 2007, 23:06

The process:

RAW video(file / stream) --> Fairchild Encoder (encodes the data into fairchild codec(compresses the data))-100mbps network-->Fairchild Decoder (decodes the data) -->passes stream off to a wrapper of choice.. be it mpeg2,4 or wmv etc --> wrapper builds a file ---> the file is what you see, which is why it comes up as a mpeg2,4 or wmv under analysis.

This was never meant to build files, it was meant to stream, this is a workaround so you can view our files.
Now I have experienced visual qualitydegradation with the lib's that are being used to decode by ffdshow, so i am going to find out what exact decoder we are using, and post that up on the site, so the 1mbps comes through at the near raw file visual quality we are seeing, please stay tuned for that, should have it by tonite.

topsykrettz

15th August 2007, 23:13

It seems you want to promote special encoders who can output standard files, designed with new ideas for CBR optimization. If that the case, it certainly will be very interesting for many people here. But if you keep confusing everyone with strange technobabble, you'll lose all credibility.

I appreciate this constructive comment, as this is probably where the confusion lies. I am not as technically literate as most of you here when it comes to video, and thus the terms i use i may be using double meanings for, because i am re-iterating what our tech team says into terms that i can understand.

We do have a codec, but we pass that stream off to a wrapper which builds the file so we can show our compression, although it seems with the multiplicity of decoders for the same wrapper we are running into problems regardless as there should be no macroblocking upon rendering, which i am now seeing with the ffdshow codec i just pulled down. So we will work to have the exact codec pack we used to build the files up on our site to eliminate that problem.

At this time, we can not release our decoder, as it has the content management and security part inbuilt to it, as well we dont have a server to stream from as of yet, which is why we are building standard files.

I can see now, that there is no way to verify because of this process as you only see what the wrapper built.

Leak

15th August 2007, 23:14

I came to show everyone something that I, and everyone else who's seen this, finds very interesting, but it seems a lot of people here would rather nothing but shout me down without even considering that what I'm saying may be true.
Well, you seem to be a group of one as far as being "interested in this" is concerned. I'm mainly reading this for the humour value...

I'm not sure why you're trying to propagate further misinformation, but I've never said anything even remotely close to this.
You call it "misinformation", I call it "damage control"...

Generally speaking, Codecs are contained in a wrapper yes?
As you already heard - no. Why you'd mix up the soft- or hardware that actually creates and/or decodes compressed video- and audio streams with the data itself is a bit baffling, to be honest.

It helps to get the basics right before trying to get to the important part, especially around here...

I'm not sure why it appears to be so difficult to comprehend that it may infact be possible to put different codecs inside different wrappers, by reconfiguring parts of the encode process.
Sure it's possible if the container supports it, as several existing ones (like QuickTime/MP4 and I believe Matroska) do. I just don't see an improvement when you stick MPEG2, MPEG4 and WMV along with several different audio formats into a single container (i.e. a single media file) unless you're trying to deliberately bloat the resulting file. And then there's still enough player devices that won't be able to handle more than one video stream in a file.

Also, if you think serving video/audio in several different formats depending on the client is new - it's not. Especially not for streaming - but that's not even what those demos you linked to were about...

There are only so many parts of a wrapper/container that designate it's type.
Yeah, what else is new?

As I said before, we're choosing the wrapper - it's not some magical automatic process. Otherwise they wouldn't be in specified filetypes, no?
"We?" I thought you were merely interested in this product, and now you're suddenly part of the team? Is this some part of a viral marketing campain that got out of control?

I agree. I was hoping that some of them would be intrigued enough to actually look deeper into this than simply running things like gspot, avicodec, and sergey's elecard application which simply detect wrappers in the same way players do, which solves nothing.
Oookay. So exactly how is your "revolutionary" new way of opening files going to work on all kinds of devices (as you wrote) that can't or won't be upgraded? Especially without the end user installing DirectShow filters for that purpose as far as Windows machines are concerned?

IF someone was kind enough to outline the concise and exact reasons why they don't believe this, as opposed to naysaying, I would be obliged to do my best to answer. :rolleyes:
Well, showing actual demos of said "technology" instead of linking to a few files in different standardized (and separate) containers would help, for a start.

If would also help if you'd actually state what problem your solution is supposed to solve... I'm not seeing an existing problem in the first place.

If that product of yours is an on-the-fly encoder you might want to stop talking about containers and start talking encoders.

Also - the following part of your FAQ:

Is fairchild based on any pre-existing codec technology, such as AVC / ASP / VC1?

No - it is a totally new way of looking at the video delivery process. Fairchild uses a dual-part system, with an intelligent receiving end. The processes involved in the delivery of fairchild video is nothing like the standard methods currently implemented by conventional codecs, which merely decrypt / uncompress video data. SynchroTek recognised the issues of conventional video codecs, and chose to re-invent the video delivery process altogether.

is obviously total bovine digestion product when you look at the demos...

That said, if you can actually supply a demo of the software instead of some videos that could have been produced by anything people might start believing you have the product you advertise...

np: Secede - Hospital Requiem (Tryshasla)