Re: Timestamp, flags, YUV, play VOB files

Sat Oct 01 2005, Mikhail Ramendik wrote:

> > The time stamps are measured in a 90kHz clock (stored in an uint64_t).
> 
> OK, this will be in the API. 
> 
> It will probably be a new struct type, codein_frame_t, including a 
> yuv_image_t, the timestamp, and the flags.
> 
ok

[... field coded pictures, 60 fields/s decoder output ...]
> No need. This would only speed things up if we do deinterlacing by expanding 
> one field and discarding the other; but this method is handled by the 
> fast-deinterlacer (based on your patch; I will soon send you a version of 
> that with all the fixes discussed later).
Ok, then maybe just a flag that tells that the stream was coded this
way in case it is needed for the color information (see below).

> A PAL interlaced display is 25 frames/sec and this process (known in other 
> sources as telecine) is not needed.
Yes, in that case normally the movie frame rate is set to 25 fps
but the original is really 24fps, so the movie plays a little bit
faster than the NTSC/24/30fps version


> I know this double framerate trick. I don't really want to do that; I suspect 
> it won't make things any better compared to the fast-deinterlace. The 
> noticeable part is the level of detail, not the smoothness of movement (30fps 
> is enough for movement anyway).And the level of detail is not increased.

Actually I don't think 30fps is enough for smoothness of movement if it
is a real interlaced source. In this case I think the output from
the decoder should be 60 frames per second (deinterlaced with
some suitable algorithm). But this should be an option/user mode I think,
because it will use more CPU. 
Just to make things clear, I'm not talking about some simple double 
framerate trick, but doing real deinterlacing for every field/outputting
new frames at the input field rate (double input frame rate). 



> But the output of the decoder is always frame coded, right?

Yes, as it is implemented at the moment.

> 
> If I can not rely on the sizes of a pixel in U and V, then I can only 
> deinterlace Y... which might be enough for most cases anyway.

They size of a pixel in U and V is constant. It's just that
which Y value belong to a specific U and V value is different
(I think) if the picture is frame or field coded, so the output frame
from the decoder could be somewhat 'wrong' if you handle the uv values
the same. I have to check the mpeg spec to make sure I remember this right.

It is something like this I think
In a frame coded picture you get values <type>.<x>.<y> (y is the line)
Y.0.0 Y.0.1 Y.0.2 Y.0.3  field 0
Y.1.0 Y.1.1 Y.1.2 Y.1.3  field 1
Y.2.0 Y.2.1 Y.2.2 Y.2.3  field 0
Y.3.0 Y.3.1 Y.3.2 Y.3.3  field 1

UV.0.0 UV.0.1            
UV.1.0 UV.1.1            
for every 2 Y values in x direction you get 1 UV
and for every 2 Y lines you get one line with UV.

So UV.0.0 is positionend at the same pixel as Y.0.0
UV.0.1 is positioned at Y.0.2
UV.1.0 -> Y.2.0
UV.1.1 -> Y.2.2
to get the UV at the other Y pos you have to interpolate.
And you can see that all UV information is in field 0, but is used
interpolated in field 1. (Actually now that I think of it, it might
be that the UV information should really be placed in the middle
between two Y lines).

But when the picture is field coded. You get

Y.0.0 Y.0.1 Y.0.2 Y.0.3  field 0
Y.1.0 Y.1.1 Y.1.2 Y.1.3  field 0
UV.0.0 UV.0.1            

y.0.0 y.0.1 y.0.2 y.0.3  field 1
y.1.0 y.1.1 y.1.2 y.1.3  field 1
uv.0.0 uv.0.1

Here the color information UV is present in both fields so interpolation
is only done within a field.

When the decoder combines these into a frame it will be
Y.0.0 Y.0.1 Y.0.2 Y.0.3  field 0
y.0.0 y.0.1 y.0.2 y.0.3  field 1
Y.1.0 Y.1.1 Y.1.2 Y.1.3  field 0
y.1.0 y.1.1 y.1.2 y.1.3  field 1
UV.0.0 UV.0.1            
uv.0.0 uv.0.1

Now if we treat this 'decoded' picture the same way as a frame coded picture,
The color information will be a bit wrong because UV.0.0 will
be used to interpolate UV for y.0.0,
and uv.0.0 will be used for Y.1.0.
This destroys the binding of the color information to the separate fields.

So if you want to make a 'correct' deinterlacer this has to be handled.

Anyway as I said I'm not 100% sure of this. I have to check the mpeg spec.



> > It might be possible to make a call when ogle detects a still
> > picture so you can output it directly in that case.
> 
> Doesn't ogle know if a picture is still, by the time it should call the 
> deinterlacer? If it does, I suggest not calling - even though I will support 
> this case.

No, ogle doesn't know in all cases, because a 'still picture' in mpeg
is just that there are no more pictures coming after it.
If you have a stream of decoded pictures, and there are no more pictures
for a while in the mpeg stream, then the last decoded/displayed picture
should be shown until the next one is available in the stream.
There is some more info on a DVD that can help you to know if a picture
has a gap to the next one or not, but generally you don't know
(until it's too late).

Depending on your API this maybe isn't a problem.
If I can just keep getting deinterlaced pictures until your
internal buffer is empty, without having to input new pictures
everything should be ok.

/Bj|rn