[Theora] Stream Test (again)

Tue Apr 25 23:58:17 PDT 2006

I just had another play with it... and i'm seeing similar jumpiness. There 
is a few reasons this can happen... firstly the file is not valid in some 
way... my filters in general don't like invalid files... vlc on the other 
hand seems to play just about anything no matter how bad it is. The other 
reason this often happens is that you don't have enough bandwidth... you 
typically need 1.5-2 times the average bitrate, my filters also don't cope 
very well with buffer starvation. Since it works ok in other players the 
second is not the likely culprit.

I jsut downloaded a 2 megabyte chunk of the stream to check the validity of 
the file... and there are a few things wrong with it. It's not a valid 
stream, i'm suprised oggz-validate didn't pick it up... here's what i 
found...

1) There are data packets in the same pages as header packets. This isn't 
allowed. The second theora header page also has 2 data packets in it and the 
second vorbis page has 18 data packets in it. You need to flush pages after 
the headers. No data can be on the same page as a aheader, and all headers 
in all streams must appear before any data in any stream.
2) Pages consisting only of header packets must have granule pos zero. 
Because there are data packets on them, they have non-zero granule pos.
3) Continuation flags where there are no previously truncated packets
-- The second theora page has 2 header + 2 data packets, the last packet on 
that page is not truncated (or it's last segment would be 255), the next 
theora page has the continuation flag set, and actually does appear so to 
have stray piece of packet at the start. Although not really correct most 
players will just drop that extra little bit of packet as erroneous anyway.

I didn't check the page ordering, since oggz-validate is usually pretty good 
at catching that, so i assume that's ok.

The other issue it looks like it has is the coarse muxing problem. This 
typically happens in cases where the video is very easy to compress (very 
often low motion or all black screens). Basically what happens is too much 
times worth of data gets inside one page, requiring many many packets/pages 
to be buffered.

For example consider this situation... 15fps, and you have a low motion 
chunk of video, such that you manage to fit 75 packets into one theora page. 
This is 5 seconds worth of video. What happens now, is since this page has a 
stream time of 5 seconds, Because of this 5 seconds wroth of vorbis pages 
appear in the stream before the the stream even finds the very first video 
packet.

Since directshow uses a fixed amount of buffers on each segment of the 
stream, when one stream fills all those buffers no more data can be pushed 
through since the renderers are waiting for data on the other stream that 
hasn't arrived yet... so it waits for a while, decides it's not coming, 
drops some packets and then gets back into the same situation again. In 
general i already set this number very high, higher than what a well-muxed 
file should reach. But certain files can still exceed this.

In general the mxuer should avoid this from happening by forcing page 
flushes when some threshold of data is exceed rather than just keep cramming 
data into one page. This also presents problems for low memory devices which 
end up having to buffer up huge amounts of data just to find the next data 
in one of the streams.

libogg does not have any automatic capability to do this, it always trys to 
put ~4096 bytes in a page regardless of how much time that actually 
represents. ffmpeg2theora i believe now does flushing to ensure you don't 
get extremely coarse muxing. And basically you just need to call whatever 
the flush page method is in libogg when you see too much data fitting into 
one page.

This might be something you want to add to your code. In general you 
probably don't want to have any 1 page containing more than about 2-3 
seconds of data or about 50 packets.

Cheers,

PS
> Using Illuminable's DirectShow Filters:

illiminable :)

Zen

----- Original Message ----- 
From: "Neil Morris" <neil at adm1.ph.man.ac.uk>
To: <Theora at xiph.org>
Sent: Tuesday, April 25, 2006 11:31 PM
Subject: Re: [Theora] Stream Test (again)

> Robert Smith wrote:
>
>> Hi All,
>>  I have done some work on the streams at http://www.visonair.tv
>>  The seem a little better (got the page sorting working properly now)
>>  I would appreciate it if people could perform some testing (again) on 
>> the Ogg stream. (visit http://www.visonair.tv/watch.php )  Feel free to 
>> stay connected for long periods of time...
>>
>
> I tried a few quick and none too scientific views of your stream using 
> Windows versions of the following players
>
> RealPlayer10 with the Xiph plugins:
> No problems
> Good Image
>
> VLC 085-cvs  and 084-stable:
> again no problems
> Good Image
>
> Mplayer-Win32:
> again no problems
> Good Image
>
> Windows Media Player
> Using Illuminable's DirectShow Filters:
>
> Mmmm Vorbis audio fine but the Theora video was very stop-start, it
> would run for a second or so, stop then start again. The image itself
> looked fine, as good as the other players but the playback in this state
> would be unwatchable. This result with WMP is a bit odd as WMP will
> playback my own Theora/Vorbis stream in this same configuration
> without this video problem. I am using ffmpeg2theora to encode the
> video and oggzmerge to multiplex the video and audio tracks. I stream
> using PeerCast under the title of Landscape Voyage Video. If you
> install the PeerCast Client (www.peercast.org) you can play the OGG
> stream using the PeerCast Search URL of:
>
> http://127.0.0.1:7144/stream/B615D4B5C24B934C2D3BF1053F1D9854.ogg
>
> (The "localhost" URL is how you communicate with the PeerCast Client.)
>
> With what and how are you encoding your video?, just being nosey<g>.
>
> Neil
>
>
>
> _______________________________________________
> Theora mailing list
> Theora at xiph.org
> http://lists.xiph.org/mailman/listinfo/theora
> 