[x264-devel] Re: H.264 (over MPEG2-TS) over packet-lossy networks

[Michael Niedermayer]

Hi

On Fri, Feb 16, 2007 at 03:27:19PM -0800, Alex Izvorski wrote:
> On Fri, 2007-02-16 at 23:36 +0100, Michael Niedermayer wrote:
> > Hi
> > 
> > On Tue, Feb 13, 2007 at 01:11:05PM -0800, Alex Izvorski wrote:
> > > * you could tweak the decoder you're using to replace a lost slice with
> > > the same image data as in the previous picture (optionally shifted by
> > > the previous picture's motion vectors).
> > 
> > as the author said he uses libavcodec, that isnt needed as lavc already
> > performs more advanced error concealment (if theres any problem with it
> > send us a bugreport ...)
> 
> Could you describe how lavc error concealment works?

i dont remember exactly its long ago when i wrote it, i also dont know if
all the features work with h.264 i didnt test it extensively (users can and
they can send bugreports ...) things where of course tested with mpeg4 asp
when i wrote it ...

anyway heres approximately how it works

first the code will determine which parts of slices are likely intact this
code discards all data after an error and some before within a slice, also
motion vectors, intra dc coefficients, and ac coefficients are handled
seperately in case the bitstream uses data partitioning (only mpeg4 asp
currently, patch for h.264 data partitioning support of course very welcome)

next the code guesses based on the undamaged parts of slices and the
past frame if concealment from the last frame or from spatial neighborhood
would be better based on this it sets the macroblock types which arent
known (they can be known in the partitioned case)

next the code guesses the motion vectors iteratively for all non intra mbs
which have a damaged motion vector, based on the neighboring blocks

last the damaged intra mbs get colored depending on their spatially
neighboring blocks and all damaged parts are passed through a deblock filter
to remove blocking artifacts


> 
> > [...]
> > > * you could calculate checksums in pes packets, and check them on the
> > > receiving end.  pretty sure the ffmpeg's ts packetizer/depacketizer
> > > doesn't handle that now.  one tricky detail is that checksums for each
> > > packet are sent in the header of the next packet with that pid.
> > 
> > i hope you are aware that these checksums are not intended to be used
> > like that (mpeg ts spec: "This CRC is intended for use in network 
> > maintenance such as isolating the source of intermittent errors.") if 
> > you really have bit errors then you should do some real FEC
> > 
> > [...]
> 
> Absolutely, I meant checksums for detecting errors, not for correcting
> them of course.  

its funny but you can correct a bit or 2 with a CRC, not that i am suggesting
that, its just for the geek factor :)


> The reason why I suggest that is that sometimes the pes
> packet has no size in the header field, and so you don't absolutely know
> if you have all of it or if some parts are missing.  The transport
> stream continuity counters are not a reliable way of doing that ;)

the decoder will notice it if a packet is incomplete or damaged, it surely
wont know exactly where the damage is but if you just want to discard
whole PES packets with missmatching CRCs then discarding whole slices
after the decoder should have the same effect if a PES packet == a slice
and if they arent equal then droping damaged slices should be better
then dropping a incomplete PES packet which might evem contain a 
undamaged slice together with a damaged one


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20070217/f614e649/attachment.pgp