[vlc-devel] decoding behavior of VLC when splicing streams. (corrected version)
hornsby
adrian_hornsby at yahoo.co.uk
Wed Nov 16 13:21:07 CET 2005
Resend because of some mistakes :
Hi,
I would like to work on the decoder behaviour of VLC to enable it to handle
well splicing of streams.
I developed a software that enable to splice of MPEG2 ts streams in real
time. The challenge here was to be able in real time to virtually
reconstruct the display order out of the sending order without buffering.
I came up with different conclusion on decoder behaviour.
1 - in case the stream structure is made of I and P frames things are very
easy as the I frames are sent before P frames. So display order is the same
as the sending order.
2- in case the stream consist of I, P and also B frames things get more
complicated.
Consider the following stream (M=3, N=12):
<--- P0 B1 B2 I3 B4 B5 P6 B7 B7 P9 B10 B11 P12 B13 B14 I15<---
|-------------------------display order--------------|
0 I3 B1 B2 P6 B4 B5 P9 B7 B8 P12 B10 B11 I15 B13 B24
|--Encoding Order(GOP=picture 1 to 12)----|
the GOP contains pictures 1 to 12.
B-pictures 1 and 2 are encoded after I-picture 3, using P-picture 0 and
I-picture 3 as reference. Note that B-pictures 13 and 14 are part of the next
GOP because they are encoded after I-picture 15.
In case of a big time gap (or full GOP missing) VLC restart decoding at the
first next I-picture (which is correct) but VLC seems to want to display the
2 B-pictures (in the example, B1 and B2) based on the last P-pictures stored
in VLC memory. The resulting display is a mix of pictures and squares
appearing. VLC should indeed restart decoding at the first next I-picture but
it also should drop the next B-pictures following the first I-picture (only
if Time_reference of the B-pictures < Time_reference of I-picture)
Problems also appears in case of fields pictures.
You can easily recreate the behaviour without splicing tool, only with 2
VLCs. Setup one VLC as a server and another as Client.
From the server send a MPEG2 ts stream in multicast to the client. Then stop
the server, wait a while and restart it. The client sometimes display huge
artifacts and sometimes doesn't even restart.
I developed that behaviour handling in my splicing tool(dropping B-pictures
after first next I-picture) and now VLC reacts perfectly without any
artifacts.Now I would like to implement this on the decoder side because it
would be easier. where could I look at ??
Thanks very much if you read that far.
Adrian
--
##################################
http://thisisallaround.freezee.org
##################################
___________________________________________________________
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with
voicemail http://uk.messenger.yahoo.com
--
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
-------------------------------------------------------
--
##################################
http://thisisallaround.freezee.org
##################################
___________________________________________________________
Yahoo! Model Search 2005 - Find the next catwalk superstars - http://uk.news.yahoo.com/hot/model-search/
--
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
More information about the vlc-devel
mailing list