There isn't enough information here to help. I can suggest looking at
the following things:
(a) The media timestamps sent by your splitter node -- They should
always be increasing.
(b) Make sure that the marker info masks (pvmi/pvmf/include/
pvmf_media_data.h) are set correctly.
(c) Getting (or sh
Hi RaviY,
Thanks for the fast response. I've one question regarding
timestamps:
1) How they could be always increased in case of I,P,B stream, for
example?
2) What timestamp should i set on the very first sample, after seeking
on the zero position? i would suppose 0, even the last timestamp
be
Here is flags which i set on each sample:
markerInfo |= PVMF_MEDIA_DATA_MARKER_INFO_DURATION_AVAILABLE_BIT;
markerInfo |= PVMF_MEDIA_DATA_MARKER_INFO_M_BIT;
if ( bIsKeyFrame ) {
markerInfo |=
PVMF_MEDIA_DATA_MARKER_INFO_RANDOM_ACCESS_POINT_BIT;
}
Here
i've found where i was wrong, the thread is no more actual.
--
Best regards,
Yuri
On Oct 6, 11:20 am, shadow wrote:
> Here is flags which i set on each sample:
>
> markerInfo |= PVMF_MEDIA_DATA_MARKER_INFO_DURATION_AVAILABLE_BIT;
> markerInfo |= PVMF_MEDIA_DATA_MARKER_INFO_M_B
Hi RaviY,
Can you please clarify how I,P,B ( I frame - has 0 mSec time, P
frame has 66 mSec time, and B frame has 33 mSec time ) streams would
work if time stamps have to be always increased?
--
On Oct 8, 1:58 pm, shadow wrote:
> i've found where i was wrong, the thread is no more actual.
>
H.264 is a special case. So, let me rephrase my statement:
Before: The media timestamps sent by your splitter node -- They should
always be increasing.
Now: The media timestamps sent by the splitter node always need to be
in the "decoding" order. This "decoding" order will most of the times
be an
Hi Ravi,
Thanks a lot for the fast answer...from your words, i see that
existed open core MPEG-4 decoder can't work with B-frames, but H.264
one should works correct. So, the limitation for the increasing time
stamps depends on decoders, right?
~Yuri
On Oct 12, 11:31 am, RaviY wrote:
> H.26
