I am having a problem with an encoder that seems to be mixing up frames in a Transport Stream when using an IBP format. I notice this problem because VLC wouldn't stream the stream to another VLC display correctly (it would only show 1-2 frames per second). i recorded a TS using Tsreader and i am using Elecard to analyze the TS and i notice there is two different ways to step through (or watch) the stream, using the Stream order or the Display order. when i use Stream order the frames are not shown in the correct order, and when i use Display order they are shown correctly.
example of problem:
video frame: 1 2 3 4 5 .... 27 28 29 30
frame type: I P B P B ..... P B P I
stream order: 1 2 3 4 5 ..... 27 28 29 30
display order: 1 3 2 5 4 ..... 28 27 29 30
My question is:
What does VLC use do display a stream, the stream order or the display order?
and
Where in the stream do these numbers come from?
(i imagine the stream order is from the IP packets and the display order is from the video frame, but i don't know)
I am still very new at this but i am getting there.
Thanks for the help!
Joe
using VLC to troubleshoot a stand alone encoder
Re: using VLC to troubleshoot a stand alone encoder
ok... so i found out i look a little dumb from my previous post.
after some research into understanding how the TS works i see that there doesn't seem to be a problem with the encoder.
I think that there is a problem when ffmpeg repackets the ts.
The frames coming into VLC per gop are like so. IPBPBPBP.....PI
and the frames coming out are like so. IPBPIPBPI etc.
It seems that there is a loss in the data or the PTS is not being repacketed correctly
this is the most common errors on the second VLC that is recieving the stream (not transcoded)
main warning: PTS is out of range (-37655), dropping buffer
main warning: late picture skipped (164699 > -956)
If i do transcode the video breaks up but more frames per second do get sent.
so question:
Is this a FFmpeg problem?
has anyone experienced this problem ?
does anyone know what could be going wrong?
and how can i resolve this?
should i just get a different streamer?
Thanks!
Joe
ps i am using version 1.0.2 and i am streaming H.264 from one (stand alone) encoder to a VLC (streaming a stream)and then to another VLC (viewing the stream)
after some research into understanding how the TS works i see that there doesn't seem to be a problem with the encoder.
I think that there is a problem when ffmpeg repackets the ts.
The frames coming into VLC per gop are like so. IPBPBPBP.....PI
and the frames coming out are like so. IPBPIPBPI etc.
It seems that there is a loss in the data or the PTS is not being repacketed correctly
this is the most common errors on the second VLC that is recieving the stream (not transcoded)
main warning: PTS is out of range (-37655), dropping buffer
main warning: late picture skipped (164699 > -956)
If i do transcode the video breaks up but more frames per second do get sent.
so question:
Is this a FFmpeg problem?
has anyone experienced this problem ?
does anyone know what could be going wrong?
and how can i resolve this?
should i just get a different streamer?
Thanks!
Joe
ps i am using version 1.0.2 and i am streaming H.264 from one (stand alone) encoder to a VLC (streaming a stream)and then to another VLC (viewing the stream)