[vlc] Re: help with error deciphering.

[Jean-Paul Saman]

Jean-Paul Saman wrote:
> Kim Schulz wrote:
>> On Mon, 30 Apr 2007 19:26:44 +0200
>> Jean-Paul Saman <jean-paul.saman at planet.nl> wrote:
>>
>>> Kim Schulz wrote:
>>>>
>>>> On Mon, 30 Apr 2007 16:34:48 +0200, Jean-Paul Saman
>>>> <jean-paul.saman at planet.nl> wrote:
>>>>> Kim Schulz wrote:
>>>>>> Hi guys,
>>>>>> What causes an error like this? It seems like it gets triggered by
>>>>> changes to the
>>>>>> timestamp in the RTP header when I stream h263 data.
>>>>>>
>>>>>> main error: picture 00DF07E0 refcount is -1
>>>>>> main error: decoder is leaking pictures, resetting the heap
>>>>>> main error: picture 00DF08F0 refcount is -1
>>>>>> main error: decoder is leaking pictures, resetting the heap
>>>>>> main error: picture 00DF08F0 refcount is -1
>>>>>> main error: decoder is leaking pictures, resetting the heap
>>>>>> main error: picture 00DF08F0 refcount is -1
>>>>>> main error: decoder is leaking pictures, resetting the heap
>>>>>> main error: picture 00DF08F0 refcount is -1
>>>>>> main error: decoder is leaking pictures, resetting the heap
>>>>>> main error: picture 00DF08F0 refcount is -1
>>>>>> main error: decoder is leaking pictures, resetting the heap
>>>>>> main error: picture 00DF08F0 refcount is -1
>>>>>> ffmpeg error: more than 5 seconds of late video -> dropping frame
>>>>> (computer too slow ?)
>>>>> You have a memory leak in your code. The code tries to reference a
>>>>> picture_t that has -1 as reference count. Either it never
>>>>> increased it or decreased it more then once.
>>>>>
>>>>> Is this with unmodified vlc code or did you made changes?? VLC
>>>>> version? OS ?
>>>>>
>>>>> The ffmpeg error basically means there is a major buffer underrun.
>>>>>
>>>>> Gtz,
>>>>> Jean-Paul Saman.
>>>> This is with an unmodified version of VLC 0.8.6b for windows. The
>>>> stream it is receiving is one I create and send myself. 
>>> Are you sure the timestamps are sane?
>>
>>
>> define sane :-) I have tried several different approaches. the one 
>> that seemed to work
>> the best was to simply sum the payload size for each frame. According

The sum of the payload size has nothing to do with timestamps. That is 
more for doing CRC32 on the payload (detecting errors in transmission).

>> to one of the ffmpeg guys, this should be an ok way to do it - as long
>> as the timestamp is increasing for each frame (but is the samme for all
>> packets containing fragments of the same frame).
>>
>>
> That sounds insane ;-)

Actually it sounds like you are sending a malformed stream to VLC. The 
timestamp is meant to increase and is used to time when a frame must be 
sent to decoder and display. VLC uses the timestamps to set and drive 
its internal clock.


Gtz
Jean-Paul Saman.

-- 
This is the vlc mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/support/lists.html