The window "rc" member actually contains one less than the real row
count (See CTA-708E Sec 8.10.5.2 definition of "rc" member). Hence
we need to take that into account when determining whether to do
a scroll or just increase the row location. Without this change we
will trample an existing row, for example if CEA708_Window_RowCount()
is 2 and i_row_count = 3.
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
In the 708 specification, the origin for references to window location
is always the top left corner regardless of the anchor type (see
CTA-708E Sec 8.2). However VLC's internal representation for
subpictures with SUBPICTURE_ALIGN_BOTTOM expect the origin to be
relative to bottom left corner of the screen. Hence we need to do
a bit of math to handle this conversion or else windows which are
supposed to be at the bottom according to the spec are rendered
at the top.
In other words, a Y-value of 99% for a window of type
CEA708_ANCHOR_BOTTOM_LEFT should be rendered at the bottom of
the screen, not at the top of the screen.
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
When doing roll-up captions, the decision on whether to scroll
should not be based on the number of lines in the window, but
rather whether we were on the last line when we received the CR
command.
This problem manifests as the same line being overwritten
continuously rather than scrolling when we receive a sequence
such as the following:
DefineWindow with rc=1 (i.e. two lines)
SetPenLocation Row 1 (i.e. the second row)
Write caption
CarriageReturn
SetPenLocation Row 1
Write caption
CarriageReturn
In the above example, because CEA708_Window_RowCount() would
return 1, the row number would be bumped and a scroll would
not be performed. Hence the subsequent SetPenLocation would
proceed to overwrite the current line.
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
The existing logic was making the decision on which lines to
render based exclusively on the i_firstrow/i_lastrow attributes,
which may be larger than the rowcount specified when the window
is created. This can result in more lines being rendered than
requested by the sender.
Take into account the window rowcount property to render the
correct number of lines, and in cases where that number is less
than the delta between first/last, make sure to render the
correct subset of lines (i.e. the last N lines in the case of
TB).
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
The decision when to truncate was being made based on the first
row in the array, but for TB scrolling we need to be checking
the last row. Presumably this is a cut/paste error from the
above code block for BT scrolling.
Also, the for loop for the copy needs to include the first
entry, since i_firstrow gets incremented implicitly by the
truncate operation.
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
In the existing code, p_region would always be equal to
p_spu_sys->region, since that is what it is initalized to and
nothing ever changes it. Hence as the loop iterates, all the
windows will be update the first subpicture region (i.e.
corrupting that region such that it's properties are exclusively
that of the last window in the loop). The result is only
the last window is ever rendered on-screen.
Add a variable to determine whether to use the original region
or whether to create a new region (so we end up with a different
subpicture region for each window).
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
Devin Heitmueller
Francois Cartegnie
Steve Lhomme