[MPlayer-dev-eng] [BUG] [PATCH] Ogg/Theora frametime broken on 0-length packets

[David Kuehling]

>>>>> "Reimar" == Reimar Döffinger <Reimar.Doeffinger at gmx.de> writes:

> On Sat, Apr 30, 2011 at 02:34:20PM +0200, David Kuehling wrote:
>> I noticed that a/v sync drifts in theora files that contain 0-length
>> video demux packets (i.e. frames where the image doesn't change at
>> all), when played back with -demuxer ogg.  The libavformat demuxer
>> seems to work correctly.  However it uses so much memory (a leak),
>> that it won't work on the target platform (NanoNote: 32MB RAM, no
>> swap).

> Please provide a better bug report so we can fix this, -demuxer ogg is
> unlikely to work forever.

Sorry I don't understand that sentence.  You mean demuxer ogg is
deprecated?  WRT 'better bug report': what else (apart from a test-case
video) do you need?

>> Looking closer, I found that ds_get_next_pts() returns the *current*
>> pts when the packet read last has zero length.  This is due to the
>> check for 'ds->buffer_pos' to see whether data have already been read
>> from the *current* packet.  Of course, ds->buffer_pos will stay when
>> a zero-length packet was read, so that fails.

> There are multiple possible solutions, the most correct _probably_ to
> stop the Ogg demuxer from outputting 0-size packets.  

This would only work if we would then increase the frametime of the
previous video frame accordingly.  I.e. before we enqueue a new video
packet we'd first have to go on reading any consecutive 0-size packets
(which are AFAIK 5 byte when counting the headers), to determine
frametime.  Sure that adding this kind of complexity to the ogg demuxer
is the right solution?

> Though this also might be an issue of the decoder behaving
> incorrectly.  Are you sure it is not related to that you end up using
> libtheora when using -demuxer ogg while using fftheora with -demuxer
> lavf?  

I guess the decoder does not play a role, because vd_theora.c just
returns NULL (i.e. skip frame) when receiving a 0-sized packet.

> But a sample file to test and verify multiple approaches would be most
> useful.  

Trying to encode one.  Unfortunately I have no license for my sample
file, so can't upload it publicly.

cheers,

David
-- 
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110430/6896e309/attachment.asc>