SynchroTek Fairchild codec [Archive]

topsykrettz

21st June 2007, 00: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, 06: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, 06: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, 07: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, 10: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, 05: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, 20: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, 21: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, 23: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, 23: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

23rd June 2007, 00: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

23rd June 2007, 00: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, 22: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, 22: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, 22: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, 07: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, 18: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, 03: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, 06: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, 01: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, 12: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, 17: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, 17: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, 20: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, 21: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, 21: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, 21: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, 21: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, 22: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, 22: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, 22: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, 22: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, 23: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, 23: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, 23: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

16th August 2007, 00: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

16th August 2007, 00: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

16th August 2007, 00: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)

Leak

16th August 2007, 00:17

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.
Transcoding from one format to a completely different one (if it easily transcodes to MPEG2, it won't easily transcode to MPEG4 and WMV at the same time), on commodity desktop hardware, with high output quality and in real-time?

That's comedy gold indeed.

No further questions.

np: Yagya - Snowflake 1 (Rhythm Of Snow)

Milvus

16th August 2007, 00:18

Leak

16th August 2007, 00:20

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.
Okay then - how about sending round your tech team then? This site is not a trade show, so what's the marketing department doing here? :rolleyes:

G'night.

np: Gas - Track 5 (Zauberberg)

slavickas

16th August 2007, 00:22

froggy1

16th August 2007, 00:26

I would like to see a comparison of this "wonderful and revolutionary" new "codec" against a wavelet-based codec like Dirac or Snow (even though the last one is still in alpha it can challenge AVC today)

Atak_Snajpera

16th August 2007, 00:54

Okay then - how about sending round your tech team then? This site is not a trade show, so what's the marketing department doing here?

I was going to ask exactly the same question :) Why do we talk to some guy who has no knowledge about video compression at all?!?! I suppose know he will prepare another fake message from "Synchrosomething" and so called technician will explain us how it works.

I start to enjoy this thread :) This guy is good :) We all know that this super syncho codec is a fake but no he is still arguing
What will be next amigo?

Terranigma

16th August 2007, 01:10

What will be next amigo?
Probably a claim for a lossless/lossy coder that compresses higher than YULS's codec in lossless mode, and all AVC coders in it's awesome lossy mode. :scared:

CruNcher

16th August 2007, 01:14

@all
I bet it's a nordic online comedy show and topsykrettz is the host and our responses are shown in that forum for a lough :D

@terranigma
ok nordic coders are good but i doub't better then russian ones, even the asians let research their :P

@topsykrettz
btw how does this work the investors give you money and you transfer it onto the bahamas and then later yourself too :D ?

hmm http://www.xtremesystems.org/forums/member.php?u=48494 <- he is just starting it seems :P
http://www.tomshardware.com/forum/profile-134214.htm
http://www.youtube.com/user/topsykrettz <- you are from germany ?

so you saw Antitrust and thought hey is it so easy to become rich and starting this now ? poor really poor
or is this a viral marketing campaign you doing for your marketing class lol then it failed misserably

topsykrettz

16th August 2007, 01:28

Transcoding from one format to a completely different one (if it easily transcodes to MPEG2, it won't easily transcode to MPEG4 and WMV at the same time), on commodity desktop hardware, with high output quality and in real-time?

That's comedy gold indeed.

No further questions.

np: Yagya - Snowflake 1 (Rhythm Of Snow)

that is exactly what we are doing for the purpose of making demo's into files.

topsykrettz

16th August 2007, 01:33

its funny how synchrotek "advantage" is shown:
take interlaced source clip,
deinterlace and compress with either their but more probably some other codec and attach some lame marketing and compare it to interlaced source compressed in progressive mode with h264,divx to show how it sucks...

summary: in best case it is some deinterlacer

btw its funny how topsykrettz pretends in the first post that he is not related to synchrotek

+ biggest nonsense I read this year:
Sigh.
at the time i wrote that first comment , i wasnt part of the company, i was later brought on board.

I dont wish to continue this flame show, as you have already decided it is impossible to do what we are claiming. I have seen it first hand, and for those that are interested, i will have the site amended in the next short period of time with the proper codec pack to decode the video without blocking.
We are doing what we say we are doing.
If we showed you exactly how this is done, we would be letting our intellectual property go, which at this point isnt an option.
I mainly wanted to share something that is exciting, as everyone has been moving in the similar direction, this takes a different road.

As for the "do you think we re fools etc" type comments,
Its exactly the opposite. We know some of the best video codec minds in the world read and post on these forums, if we were to detail exactly how we do this, in a way you could understand without a doubt.. you could easily piece together the methods and possibly create something comparable. Unfortunately at this time, we cant publicly disclose our complete methodology, but only the results we are achieving, which is precisely why i m commenting and not our technical side, because i have no chance of inadvertantly giving away some of our patent pending software methods.
And yes you are right, i do want to generate interest, and I agree, being skeptical on the internet is the safest and right way of proceeding, but i really wish you to consider the possibility that we are doing what we say we are. And we will in the future be able to fully demonstrate it, at this time, with interest from companies in the industry, which you would all know, it wouldnt be prudent to release trade secrets that could be reverse engineered.

Sergey A. Sablin

16th August 2007, 01:36

that is exactly what we are doing for the purpose of making demo's into files.

exactly what? transcoding from unknown (existent?) format to another to show what? the power of mpeg-2, mpeg-4, wmv? there is nothing left in final files from source format if it even exists.

CruNcher

16th August 2007, 02:01

exactly you could have used loosless samples for that or screenshots and like everyone else in the industry does PSNR Graphs showing your codecs advantages for all the standard samples that are used in video research, but this way is loughable, you know topsy since all the years their where so many companies that claimed so much stuff and everyone of those had real technical background and explained their stuff very well but they vanished some very mysteriously as they had never existed.
The only Company of those i belived was one that worked for the military on Databases and claimed to have created a Object Based Encoder (something they showed of at a presentation where someone from the DOD was there (researched that on the net) after that they vanished it was basicly the same as Pulsents idea and today many show that off as working
http://www.eetimes.com/story/OEG20020322S0105 - the pulsent story and here some research results of today on that topic from russia
http://www.yuvsoft.com/technologies/semiauto/index.html
http://www.yuvsoft.com/technologies/segmentation/index.html
http://web.archive.org/web/20021210153751/www.pulsent.com/solutions/index.html

but your stuff sounds really strange and i wonder when you'll be contacted by your local millitary, the German Bundeswehr for sure would like to invest, everyone of the other storys in technological achivements is more beliveable then yours face it, because they showed at least some evidence :P

topsykrettz

16th August 2007, 02:09

Still don't understand at all the utility of your process.

You are encoding a file, streaming it thru a 100mbps network, then decoding it, then encoding it a second time ????

I suppose the first encoding take place on a server, be it yours or the server of one of your customers. But the second, on which computer did it take place ? On a server ? Then the first part has no use... On the final playback computer ? Then you need to install software on this device, and it can just play the stream. Why transcoding instead ?

The second encode is just for utilities sake, it isnt necessary, unless we are trying to create a standard file that can be uploaded and shown to people.

We can in the encode process, change it so it builds the stream into any wrapper. We are not trying to make a codec that converts into any decode type as we need our Decoder present to take advantage of the content management and security we have inbuilt.
We are passing the stream off from the decoding computer for simplicity sake as we are set up to demonstrate our codec, not mpeg2/4, wmv. So from the fairchild decoder, we send it to a wrapper type, which captures and builds the stream into a file of that container. This is an extra process used, just to create the files.
We could at the encode stage configure our setup to do that transcode to a different wrapper type and send it through the stream as mpeg2/4, wmv, but for the purposes of what we want to show live, we have it set up to demonstrate our codec. These files are an after thought, and show that we can achieve data rates etc, and put them into different wrappers.

I would like to share how we do this, but at the moment i m not at liberty to disclose exactly how that is done, on home hardware, while reducing cpu usage. The more i read these responses, the more sensational it seems this feat is... I wasnt aware that as someone above said was impossible. again, my lack of knowledge relative to the experts here.:confused:

I apologize if my use of codec is incorrect in this reply.

topsykrettz

16th August 2007, 02:13

exactly you could have used loosless samples for that or screenshots and like everyone else in the industry does PSNR Graphs showing your codecs advantages for all the standard samples that are used in video research, but this way is loughable.

Excellent, so what exactly would you need to see? If you can detail it, i can be sure to see if we can manage to get something up that is. Video isnt our coding background, so we are new to demonstrating how this works, cpu and hardware is our tech team background.

The reason for interlaced source is thats all we have access too. We are creating ntsc broadcast , and our sources appear to be that as well. If you could direct us to exactly what your looking for, and outline it, we will try and meet those, if they dont comprimise exactly how our process works.

Milvus

16th August 2007, 02:24

So your technology is a proprietary audio and video format compression format, with its associated codec software, of course uncompatible with actual players. And you transcoded the results to several standard formats for a demo, which is just a plain stupid error no video specialist would make even extremly tired. Well...

CruNcher detailed everything we need to have an idea of the efficiency of your technology. If your techs need more details, i'm sorry but they are just incompetents...

Video isnt our coding background, so we are new to demonstrating how this works, cpu and hardware is our tech team background.

This statement is a bit scary. If you have only CPU and hardware specialists, how did you manage to conceive a video codec and its format ? If you know nothing about video, even if you are a god of CPU, you just can't do that...

CruNcher

16th August 2007, 02:52

@topsykrettz
Demoscene ?

This statement is a bit scary. If you have only CPU and hardware specialists, how did you manage to conceive a video codec and its format ? If you know nothing about video, even if you are a god of CPU, you just can't do that...
Don't underestimate smart brains, some reading a paper and go on creating great stuff in a time other would need a year they do it in months (even without full background) at least you need to understand the math behind it ;)

Sharktooth

16th August 2007, 03:41

Atak_Snajpera

16th August 2007, 07:55

I'm still waiting for "technician"...:)

Inventive Software

16th August 2007, 11:20

This has a certain air about it from another thread that was comedy gold on a specialist car forum... the guy tried to sell a car that was crashed and then repaired as brand new, and got found out. :D

topsykrettz

16th August 2007, 22:16

Maybe i understood what they're doing.
OK, they just encode some content with fairchild at a certain bitrate (lets say) 1000kbps with a certain quality in realtime, but since there's no publicly available decoder yet, the only way to show us the resulting quality is to transcode to another format (i didnt get if this also happens in realtime... but it doesnt matter) so anyone, including the ones who do not own the decoder, can look at it...
the problem is: how could we verify the fairchild encode was really at 1000kbps?

That is exactly what we have been trying to establish. Thank you :) The transcode happens realtime. We are passing the stream to the container, not much processing taking place in building the file from the stream.
As for verifying the encode, it seems that will be an issue for now, until we can release our decoder, otherwise a live demonstrations seems the only 100% way we can show right now, which is what most would demand any way.
psnr as a method does not seem viable as our codec is streaming, which is where you want the quality from, not from the built file, and from my understanding, most psnr compare raw with file. Screen shots again, not sure how they can be verified as they can be modified. The other reason, is that since our decoder setup is unlike other systems, i m not sure the standard metrics like stream monitors will function correctly as they wont properly see the codec.
So at the moment it seems that you will have to suspend conventional belief, until we can release our decoder.

As for display issues, it seems FF based lib files are causing macro blocking relative to alternatives, on our pc's we are seeing almost nothing in those terms, so please let us know if you are experiencing breakups, what lib file you are using to decode.:thanks:

Sergey A. Sablin

16th August 2007, 22:35

That is exactly what we have been trying to establish. Thank you :) The transcode happens realtime. We are passing the stream to the container, not much processing taking place in building the file from the stream.
that's absolutely not what he said.

As for verifying the encode, it seems that will be an issue for now, until we can release our decoder, otherwise a live demonstrations seems the only 100% way we can show right now, which is what most would demand any way.
psnr as a method does not seem viable as our codec is streaming, which is where you want the quality from, not from the built file, and from my understanding, most psnr compare raw with file. Screen shots again, not sure how they can be verified as they can be modified. The other reason, is that since our decoder setup is unlike other systems, i m not sure the standard metrics like stream monitors will function correctly as they wont properly see the codec.
So at the moment it seems that you will have to suspend conventional belief, until we can release our decoder.

As for display issues, it seems FF based lib files are causing macro blocking relative to alternatives, on our pc's we are seeing almost nothing in those terms, so please let us know if you are experiencing breakups, what lib file you are using to decode.:thanks:

you're again trying to talk about the things which you're not familiar with. you already said by yourself that you're not technician (and even that yours technicians aren't familiar with video at all) - why you're still trying to describe technical stuffs?
you even dont know how to present/describe your product and don't know what it does - so what's the matter to flame here? everybody already knows that it is fake and nothing more.

it should be really some kind of joke.:confused:

Milvus

16th August 2007, 22:43

Still trying to understand your technology...

The transcode happens realtime. We are passing the stream to the container, not much processing taking place in building the file from the stream.

Are you saying you created some kind of way to transcode the bitstream from your proprietary format to classical formats without decompressing then recompressing the stream ? Same way some old Divx 3.11 files can be losslessly transcode to MPEG-4 ISO (http://forum.doom9.org/showthread.php?t=85229) ?

Would be quite incredible breakthrough...

Atak_Snajpera

16th August 2007, 22:52

Fairchild losslessly converted to AVC, VC-1 , ASP ...sounds like tale :) That crazy method would be too complicated. DivX 3.11 and ASP are very similar but AVC is a different story!

i will have the site amended in the next short period of time with the proper codec pack to decode the video without blocking.

This guy is clever. He made a big noise about super duper Fairchild codec and about it's wonderful technology which cannot be even properly explained. Later proper codec pack will be available for everybody. Many people will probably download that just to see how it works but what if that's gonna be a new virus and your PCs become a ZombiePCs. Decoding software won't install of course. Let's say due to CRC error. topsykrettz will apologize everybody and he will promise to release new fixed version in couple days.

topsykrettz

16th August 2007, 23:33

Fairchild losslessly converted to AVC, VC-1 , ASP ...sounds like tale :) That crazy method would be too complicated. DivX 3.11 and ASP are very similar but AVC is a different story!

This guy is clever. He made a big noise about super duper Fairchild codec and about it's wonderful technology which cannot be even properly explained. Later proper codec pack will be available for everybody. Many people will probably download that just to see how it works but what if that's gonna be a new virus and your PCs become a ZombiePCs. Decoding software won't install of course. Let's say due to CRC error. topsykrettz will apologize everybody and he will promise to release new fixed version in couple days.

If that were our goal... why would we come to a forum with the best minds in regards to video? ... wouldnt we go post in tomshardware or other places, it would be easier to propagate there.:confused:
I m sorry you don't believe in my sincerity. I dont have realtime access to our coder, who has a family and a day job, just like i do....

Milvus
As for the transcode process, i ve sent your exact quote to him, and will await his answer, if we are doing lossless, from what i understand we are, but i will confirm for you.

Reply:
"All of our processes are realtime as for lossless, well, that remains to be seen, I am really not sure but judging by the output it is near as dammit to lossless.

Personally I think there is a little loss but I don’t have the time to investigate or repair it at this point."

Atak_Snajpera

16th August 2007, 23:33

Small info about registered domain using http://www.networksolutions.com/whois/

Domain Name: synchrotek.com

Created on..............: Wed, Dec 13, 2006
Expires on..............: Thu, Dec 13, 2007
Record last updated on..: Fri, Aug 03, 2007

Administrative Contact:
Domain Discreet
ATTN: synchrotek.com
P.O. Box 278
Yarmouth, NS B5A 4B2
CA
Phone: 1-902-7495331
Email: 54cfe1f10a1e672a00939192647c519e@domaindiscreet.com

If that were our goal... why would we come to a forum with the best minds in regards to video? ... wouldnt we go post in tomshardware or other places, it would be easier to propagate there.

This site is VERY popular. Doom9.org has more than 120,000 users from many countries.

addit

17th August 2007, 01:09

topsykrettz

17th August 2007, 09:48

In response to the Vapourware accusations, what we claim, is what we can and have achieved. We are not boiler room company with a conspiracy to pilfer Trojans or spyware. We , like any paradigm change, fully expected the vast majority of comments to be criticism of what is “impossible” or what “cant be done” And that is fair position to hold given the nature of the internet. We have full confidence in what we have developed and will demonstrate in appropriate conditions. As for what we can publicly release, it has been clearly iterated that one has to trust that we are doing what we say, based on the files we can show freely. Whether you choose to or not, again is completely in your power, and we encourage you to exercise your discretion.

We appreciate the feedback and interest that this forum has generated with regard to our Fairchild media platform. In reading the comments we began to realize that there was a difference in the rendering quality that some of our critics were experiencing, as a result we have been able to identify the reason for the discrepancy. The reason being that some of the decoder formats were not rendering the color depth correctly causing macroblocking and breakups in the visual quality. The following codecs 3ivx 4.5.1 and elecard mpeg 2 seem to give consistent playback quality. This was a surprise to us, as our decoder renders none of these issues, and in test results we didn’t not experience these playback issues with the transcoded files.

Due to recent events further discussion on our technical processes has become inappropriate as we are under NDA agreements. Further comments and discussion must keep this in perspective.

We thank you for you input and interest, and yes, even you Sergey.
:thanks:

CruNcher

17th August 2007, 10:35

The reason being that some of the decoder formats were not rendering the color depth correctly causing macroblocking and breakups in the visual quality. The following codecs 3ivx 4.5.1 and elecard mpeg 2 seem to give consistent playback quality. This was a surprise to us, as our decoder renders none of these issues, and in test results we didn’t not experience these playback issues with the transcoded files.

WTF ??? guys that code a revolutionary thing and writing such a (sorry to say) shit and the best of all let this being Market on the whole Internet by a guy who has absolutely no idea of anything in those terms, jesus you'll be gone faster then you came ;)
Yeah right the macroblocking in the Antitrust sample comes from color depth problems sure you could turn brightness full down then no one would see them cool idea indeed, so no one had to see your stuff, but color depth problems ??? *rofl*

MfA

18th August 2007, 04:16

Due to recent events further discussion on our technical processes has become inappropriate as we are under NDA agreements. Further comments and discussion must keep this in perspective.
The compression industry is rich with fraudsters hiding behind NDAs, black boxes and claims of still having to apply for patents ... most of them usually have the common courtesy to use their real names though, so Synchrotek at least stands out in one major way.

aqualung99

18th August 2007, 09:57

From what I understand they are proposing: A revolutionary new codec which can losslessly ramify itself into virtually any video stream be it avc or asp, at realtime framerates. Furthermore the codec itself can achieve higher compression gains than x264 at lower CPU utilisation with non of the associated artifacts...

Well, my only comment would be that if the encoder gave better results than H264 (bit-for-bit) whilst simultaneously utilizing less CPU resources, why on earth would you limit your target market to streaming? It sounds like it's superior in every way!?

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.

And that's not even mentioning the "ramifying" (borrowing addit's term) abilities...sweet J*sus I may never have to transcode anything ever again! :p I can already see the DirectShow graph...

VC1 Source -> Decompressor (faster than Real-time) ->Fairchild Encoder (Real-time) -> Fairchild Decoder (Real-time) -> Fairchild Ramifier (Real-time) -> Any codec I want!!!!! Fairchild FTW!!!

Heck, sign me up! I'm tired of waiting 6-12 hours for my encodes as well! :) When, where, and how much? ;)

Nil Einne

19th August 2007, 16:57

Sigh.
at the time i wrote that first comment , i wasnt part of the company, i was later brought on board.

Really? Let's look at your post history.

You mysteriously were already under NDA in March 9th according to your post on Tom's Hardware http://www.tomshardware.com/forum/234744-45-video-codec-divx and you're even the one who posted the Investor info PDF http://www.esnips.com/doc/e031f180-c089-4baa-bda2-c8205e1e7fcd/SynchroTek_Investor_Information Also on the 10th you were already referring to yourself as "we" http://www.xtremesystems.org/forums/showthread.php?t=136632 and also mentioned this NDA

Despite that, when you came here on 18 March you just happened to discover mention of their codec on NordicHardware http://forum.doom9.org/showthread.php?t=123617 then on 20th March you just happened to notice their website which you visited and had a PDF which was very sparse on information but still interesting for some odd reason "According to the nordichardware forums they have a website at http://www.synchrotek.com Maybe you should ask them edit: just looked at the site and it's a little (read:very) sparse on information. kinda interesting nonetheless though"

Then you came back in June as the Syncrotek "inside-man" with some supposed resulted were you discussed in detail things like "macroblocks", "usual colour shifting" and "horizontal slicing" and mentioning that "it has played on any mobile media device we've tried". Then a few hours later you were back where you admitted you were not an engineer but in finance and also said "showing what they have in the best light. Having seen it on multiple occasions, and having seen the code". You also said "I've forwarded your comments on to my contact at the company who's going to give them to the engineers". As the inside man I'm not really sure why you're suddenly talking about them like you're not part of them again but whatever..... You came back 2 days later and now your saying "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." Mostly back to we again.

Continuoning on... "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. ". You also posted a message from "their" (sic) CTO and you start referring to the company as them again. Funny how you the finance guy aren't involved in the discussions where they present their tech. Funny also how you thnk it's unfortunate for you... You also become under NDA so you can't talk except to let slip that Synchrotek is in discussion with "major corporate entities in the tech sector". Of course, according to your post at Tom's and also what you said to the xtremesystems guy you were already under NDA since March 9th but anyway...

You continue a few more posts where you become we again. You mention also "there are 5 people in the company at the moment, and we are working out of our homes.. in the garage so to speak". 5 people you say? Does this include you? The CTO? So when you said the top guys at Synchrotek, you were referring to 4 other people? You seem to have settle with 'we' from that point on although you seem to talk about them like they're a fairly big team rather then this 4 people+you scenario.

I don't think I'm the only one who finds this love-hate relationship you seem to have with your company where you can't decide whether to say "we" or "them" is bizzare.

It seems quite clear you're basically complete BS. Whether you're seriously trying to rip people off or just have a bit of fun I don't know. However I would suggest next time you try to do something like this, get your story straight. Your story is more inconsistent then Star Trek, and that's saying something. Just because you call yourself 'top secrets' doesn't mean anyone is actually going to believe your part of a topsecret team when you can't even decide if your actually part of the team. Also claiming to be part of the finance team doesn't mean people are going to let you get away with using a bunch of technobabble and then pretending you don't actually know how to explain the 'truth'. And saying you're under NDA isn't going to mean people won't tell you to put up or shut up.

Edit: Actually I'm pretty sure I know what's going on... I know that you're on "holiday" because of Typhoon Sepat but do you really have nothing better to do then to continue with this BS? Don't forget your mid-term exams are coming up very soon!

Sharktooth

19th August 2007, 17:10

definatly a hoax

Atak_Snajpera

19th August 2007, 21:15

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

This line is still a masterpiece :)

Sagittaire

19th August 2007, 22:29

IMO it's a joke ... :rolleyes:

CruNcher

19th August 2007, 23:38

topsykrettz

20th August 2007, 04:55

i hope or he trys to fool everybody to get money so he would commit a crime with this hope nobody falls for that and really invests there then, if he really should try to get onto the money of investors.
More internet crime happens everyday and now it could have reached Doom9 as a marketplace lol, but definatly that was the dumbest task he did, if it should be really a try of fraud :P

As mentioned previously, this technology is for real, and we will be more than happy to demonstrate this in person to those who would benefit.

I don't mind the claims that this is a hoax, as that is understandable given the nature of what is being suggested here. However, please kindly refrain from making very unfounded suggestions that we are criminals, based on nothing but uninformed speculation. :rolleyes:

All the best,

:thanks:

Dark Shikari

20th August 2007, 05:21

As mentioned previously, this technology is for real, and we will be more than happy to demonstrate this in person to those who would benefit.

I don't mind the claims that this is a hoax, as that is understandable given the nature of what is being suggested here. However, please kindly refrain from making very unfounded suggestions that we are criminals, based on nothing but uninformed speculation. :rolleyes:I think you have quite successfully informed us enough for us to make such statements :p

Gabriel_Bouvigne

20th August 2007, 19:20

I really hope it's just a hoax, as the other obvious option would be yet another libavcodec rip-off.

Of course, there is still the option that it could be a so revolutionary break-through that NO ONE is understanding anything about it...

squid_80

20th August 2007, 20:18

Of course, there is still the option that it could be a so revolutionary break-through that NO ONE is understanding anything about it...
Because that always happens... (http://www.timecube.com/)

Synchrotek

20th August 2007, 21:18

Dear Doom9 community,

Firstly, I would like to thank certain members of this community who contacted and alerted us at SynchroTek to the regrettable misrepresentation and misinformation that has occurred within this forum. Without such assistance who knows how long or what damage may unknowingly have been done to our company.

Until yesterday, "Topsy Krettz" was a contracted employee at SynchroTek who appears to have been over-zealous in promoting our technology. Whilst we appreciate the sentiment, we don't appreciate the manner by which he has gone about this, and in doing so contravened his NDA and Terms of Employment with SynchroTek. Accordingly, "Topsy" is no longer with the company and the appropriate actions are being taken to ensure the security of SynchroTek's intellectual property.

We feel that it is unfortunate that "Topsy" chose to make so many claims only loosely based on partial conversations and email correspondences. We are currently in discussion with a couple of corporations in the telecoms and video provision industry, and as such we are not at leisure to deny nor confirm the statements that have been made thusfar, as this would undermine our own integrity and agreements.

However, should you feel that you have further interest in what we are doing at SynchroTek, we encourage you to contact us through the appropriate official channels listed on http://www.synchrotek.com .

Once again, a large thank you to the astute members of this community for stopping a potentially devastating PR disaster. We are thankful that "Topsy" does not know enough about our technology, and the video delivery industry in general, to have been a more serious issue.

Many thanks, and best regards,

Clayton Strauts, Marketing Director
SynchroTek Labs Inc, Canada