Disclaimer: I work for Opera and do quality assurance for <video>
Opera can’t determine the duration of the ogv video (video.duration is NaN).
I tried reducing your page to
<!doctype html>
<video controls width="320" height="240" class="shadow">
<source src="./uploads/vortrag-horst-allmann-itk-2010.ogv?1" type='video/ogg; codecs="theora, vorbis"' />
<p>dud net</p>
</video>
(I added a query to get around caching)
I checked the TCP traffic in wireshark. Opera sends this as the first request for the video:
GET /uploads/vortrag-horst-allmann-itk-2010.ogv?1 HTTP/1.1
User-Agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.5.8; U; en) Presto/2.8.131 Version/11.11
Host: balkenhantel.de
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: en,en-US;q=0.9,sv;q=0.8,nl;q=0.7,nb;q=0.6,da;q=0.5,de;q=0.4
Accept-Encoding: gzip, deflate
Referer: http://balkenhantel.de/test.html
Connection: Keep-Alive
Range: bytes=0-
The “Range: bytes=0-” header means that this is a Range request. The first request is an unbounded “from zero until the end of the file”, and then for Ogg (if the server supports Range requests) Opera aborts the connection when it has got the video’s first part, does a second Range request at the end to determine the duration (because Ogg doesn’t have metadata about the duration in the start of the file), and finally does a third Range request from where it left off at the beginning to download the rest of the file. (If the server didn’t support Range requests, Opera doesn’t abort the first connection but just continues loading and won’t know the video’s duration until it’s completely loaded.)
WebM has metadata about the duration in the beginning of the file so the seek to the end is not needed for WebM.
Seems according to WireShark that the server doesn’t give any bytes in response to this request, which is weird. Dunno what’s going on there.
Second request seeks to the end as expected (which means that your server does support Range requests):
GET /uploads/vortrag-horst-allmann-itk-2010.ogv?1 HTTP/1.1
User-Agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.5.8; U; en) Presto/2.8.131 Version/11.11
Host: balkenhantel.de
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: en,en-US;q=0.9,sv;q=0.8,nl;q=0.7,nb;q=0.6,da;q=0.5,de;q=0.4
Accept-Encoding: gzip, deflate
Referer: http://balkenhantel.de/test.html
If-Range: Mon, 30 May 2011 19:06:34 GMT
Connection: Keep-Alive
Range: bytes=99004150-99012649
Third request seeks back as expected:
GET /uploads/vortrag-horst-allmann-itk-2010.ogv?1 HTTP/1.1
User-Agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.5.8; U; en) Presto/2.8.131 Version/11.11
Host: balkenhantel.de
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: en,en-US;q=0.9,sv;q=0.8,nl;q=0.7,nb;q=0.6,da;q=0.5,de;q=0.4
Accept-Encoding: gzip, deflate
Referer: http://balkenhantel.de/test.html
If-Range: Mon, 30 May 2011 19:06:34 GMT
Connection: Keep-Alive
Range: bytes=36065-99004149
This third request gives away that the response of the first request gave 36065 bytes before Opera aborted the connection.
I don’t know yet why it doesn’t work as it should. I’ll ask our <video> developer if he can take a look. Please don’t make changes to your server configuration or remove the video file or anything so that we can analyze this properly. 
