<div>I am new to this group and I need to know how half pixel interpolarion is done at the boundaries.....Can any one plz help me regarding this.....</div>
<div> </div>
<div> </div>
<div>Thanks & regards,</div>
<div>Mahesh<br><br> </div>
<div><span class="gmail_quote">On 1/17/07, <b class="gmail_sendername">Guillaume Poirier</b> <<a href="mailto:gpoirier@mplayerhq.hu">gpoirier@mplayerhq.hu</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi Måns,<br><br>Måns Rullgård wrote:<br>> Guillaume Poirier <<a href="mailto:gpoirier@mplayerhq.hu">
gpoirier@mplayerhq.hu</a>> writes:<br>><br>><br>>>Hi,<br>>><br>>>List, Peter wrote:<br>>><br>>>>Hello everyone,<br>>>><br>>>><br>>>><br>>>>I am new to this group although experienced with
H.264. I tried to use<br>>>>the x264 encoder to prepare sequences for an error-resilience test.<br>>>><br>>>>I was very surprised, when I discovered, that x264 CAN NOT produce<br>>>>slices! Slices are the basic tool to cope with packet-losses over
<br>>>>IP-based networks (without retransmission), and in fact can make a huge<br>>>>difference for subjective quality, in particular at high loss-rates.<br>>><br>>>Very basic indeed. _I_ think it's better to add more advanced parity
<br>>>(which allow the errors to be recovered) infos somewhere in the<br>>>transport layer stream than using slices.<br>><br>><br>> Using error correcting coding at the transmission layer substantially
<br>> increases the bitrate. With slices a transmission error will ruin the<br>> rest of the slice, while other slices still decode properly.<br>> Sometimes a little damage here and there is acceptable if it means you
<br>> can keep the bitrate down. Besides, you don't always have control<br>> over the transmission encoding.<br>><br>> Put another way, slices limit the scope of the damage caused by<br>> whatever transmission errors make it through your error correction
<br>> layers.<br>><br>> Anyone who has watched digital TV should appreciate the usefulness of<br>> slices.<br><br>Mmmm. I guess I did not understand what "error concealment" meant. My<br>dictionary translates it to "dissimulation des erreurs" which more or
<br>less translates back in English as "error hiding", which by my book<br>means that if an error occurs, it doesn't show, up to a certain amount<br>of errors you can't recover.<br><br>As far as I understand, slices don't allow that, that's why I thought
<br>that better error correction blocks was the solution.<br><br>But now that I understand what "error concealment" means, and I see<br>that slices seem like the right tool for that job.<br><br>Sorry for the trouble. I'm learning smth new every day :-)
<br><br><br>>>>Did I miss something here, or is it true that x264 can only produce 1<br>>>>slice per frame???<br>>><br>>>It used until r609 to but it was replaced by a much better and faster<br>
>>multi-threaded encoding mode.<br>><br>><br>> Multithreaded encoding and slices are really distinct features.<br>> Slices may be desired, as the OP says, with or without multithreading.<br><br>Loren, Out of curiosity, did you remove sliced encoding support
<br>because it was too deeply "interleaved" with multi-threaded support,<br>so your new multi-threaded encoding mode had to make sliced encoding<br>go away? Or are there other reasons?<br><br>Guillaume<br><br>--
<br>This is the x264-devel mailing-list<br>To unsubscribe, go to: <a href="http://developers.videolan.org/lists.html">http://developers.videolan.org/lists.html</a><br><br></blockquote></div><br>