[iptv-users] Open Source x264 Encoder

[Alex Moen]

Another extremely important point is that the STBs don't have  
powerhouse processors.  The more that we squeeze down video, the more  
the processor has to work in order to recreate the video frame.  Also,  
VBR is known to be more processor intensive than CBR, hence most IPTV  
providers are using CBR.  So, sacrificing some bandwidth to give the  
STB processor more data to use to recreate frames will equal a much  
better picture.  Depending on the STB, 300k could make the difference  
between a good picture and microblocking.

I am all for open source, and I am going to look into X264 for my own  
knowledge and do some testing on it.  However, with some of the gear  
on the market today (for instance, VSI (www.vsicam.com), where an HD  
H264 encoder is actually affordable, and S/A's DCM), it's going to be  
pretty hard to think that I am going to be able to be more compact,  
efficient, and reliable by rolling my own...

Thanks for the heads up about X264... I'm gonna take a look at it.

Alex Moen
NDTC



> -----Original Message-----
> From: iptv-users-bounces at puck.nether.net [mailto:iptv-users-bounces at puck.nether.net 
> ] On Behalf Of João Serra
> Sent: Thursday, January 21, 2010 8:35 PM
> To: iptv-users at puck.nether.net
> Subject: [iptv-users] Open Source x264 Encoder
>
> I noticed that almost all of you are working at some IPTV provider,
> I'm just an IPTV application Developer and i don't deal with encoders
> at all, so i have a question for all of you:
>
> Have you tried the open-source X264 H.264 encoder? According to the
> things i read on the net, x264 can out perform every hardware encoder
> on the market, even in real-time, both in quality and speed... In the
> last version it can even encoder in real time without latency, making
> it suitable for video-conferencing applications...
> I suggest you to read this post in one of the x264 developers blog -
> http://x264dev.multimedia.cx/?p=249&cpage=1#comment-2427 According to
> him, there are no h264 encoders in the market(both software and
> hardware) that can achieve that level of low-latency... (I know IPTV
> doesn't care much about latency, I'm just trying to illustrate the
> power of x264)
>
> My IPTV provider, for instance, uses 2 MB/s(in average, they use VBR)
> h264 streams for SD content(they're using Harmonic's Divicom Electra
> 8000) and it really looks awful when compared to a couple of x264
> files i have encoded with x264 at 500kb/s(average - VBR encoded) Yes,
> i know i can't compare off-line encoding with real-time encoding, so i
> did another test: I encoded a video in real-time on a Core 2 Duo with
> the same average bitrate of 2mb/s and again, my provider hardware
> encoder looses again in quality... I tried Sports, Movies, News, etc
> and looking to my Samsung LCD, o difference is very visible, x264
> wins!
>
> So, my question to you is: why do you use those very very expensive
> hardware encoders that produce mediocre results, if Software encoders
> can easily outperform them? And they are much more cheaper(they are a
> just standard servers, you can even add SDI/ASI PCI cards if you
> want)...
>
> I know x264 can be a pain in the ass to configure, given the bazillion
> features and options it supports, however, i think it's a fair
> trade-off, if you consider it's price...
> I only think i cannot test is it's stability, have any of you tested
> it? For instance, letting a Red Hat Enterprise Linux box real time
> encoding a stream for a couple of months without interruption?
> _______________________________________________
> iptv-users mailing list
> iptv-users at puck.nether.net
> https://puck.nether.net/mailman/listinfo/iptv-users
> _______________________________________________
> iptv-users mailing list
> iptv-users at puck.nether.net
> https://puck.nether.net/mailman/listinfo/iptv-users