RELEASE: GstValidate 1.3.90

[Thibault Saunier]

Hello Thornton

>>    warning : first buffer's running time isn't 062866666 speed: 1.000000 />
>>              Detected on <d3dvideosink0:sink> at 0:00:00.118093949
>>              Details : First buffer running time is not 0, it is: 0:00:00.016683333
>>              Description : the first buffer's received running time is
>> expected to be 0
>
>
>> That issue probably means that there is a timestamping bug somewhere.

> These elements in the pipeline are all from git master. Any hints as to where to look to try to find out why the frame with timestamp=0 isn't being sent down the pipeline would be gratefully received.

I already saw that issue several time but have not taken the time to
investigate it myself, it is not critical but should clearly be fixed.
Looking at the report, the issue is most probably comming from the
demuxer (in that case qtdemux).

>> [snip]
>> Repeats for each frame
>
>> Really you get that message for each frame? I doubt it, the test is (at least should be) executed only for the first frame.
>
> The line which is repeated for each frame is not the warning above. It is the line below.
>
> gstbin.c:4023:gst_bin_query: implement duration caching in GstBin again


Ah, right, it is not reapet for each frame but at each duration query
on the pipeline. In that particular case we have a duration query
happening every 50ms in GstValidate, as I said, that is harmless.

Regards,

Thibault Saunier