[vlc-devel] [PATCH] Fix 0-byte Ogg packet handling
Timothy B. Terriberry
tterribe at xiph.org
Mon Sep 3 01:15:35 CEST 2012
Here is a stab at fixing https://trac.videolan.org/vlc/ticket/3416
It should also fix https://trac.videolan.org/vlc/ticket/3550
Right now this decodes every 0-byte packet as if it were a new frame,
returning the previous buffer to be displayed again. This should work
"okay" for things like the 120 fps stockholm-vfr.ogg, but is still going
to have problems for 1000 fps things like dupes.ogv (which is no longer
available for me to test with... I will bug Greg about that).
I'm not sure the best approach to handle the 1000 fps case, e.g., what
the ramifications are of dropping duplicate frames after decoding (as
opposed to after demuxing) on time display updates, file length display,
etc. However, 0-byte frames are not the only way to encode "duplicate"
frames, and people have been using alternate approaches, which work out
to about 9 bytes for a dropped frame, to avoid 0-byte packet demuxer
bugs like this one.
So whatever approach we take, it should be based on checking for the
TH_DUPFRAME return value of th_decode_packetin(), not the size of the
packet. That return value is used whenever a frame copies over the
previous reference frame without coding any blocks. Therefore the 1000
fps case is not strictly related to 0-byte packets, and should be
addressed in a separate patch.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4526 bytes
Desc: not available
More information about the vlc-devel