The filter BUFFER_SIZE parameter currently contains a
comment stating that changing its size may cause sudden
crashes due to problems with memory management. This
problem has since been found and solved. Since the buffer
size is no longer a likely source of errors, this comment
should be removed.
Test: Comment only change
Bug: 236847284 introduced this comment, 239741712
covered the real root cause
Change-Id: I9344d136c7220f54d8c66dd4f4da68890b841886
Add lazy tuner service.
Refine code to allow Tuner reference count to be 0 when no one uses it.
Bug: 236002754
Test: atest VtsHalTvTunerTargetTest on both lazy and normal HALs
Test: atest android.media.tv.tuner.cts on both lazy and normal HALs
Change-Id: I0cc69fe8ffd79a66db00cb72d212c222130629b5
This CL allows the vendor to ommit LnbDescrambling from the
configuration file. The VTS will look at the devices configured by the
vendors and automatically configure the dataflows and determine which
tests to run for LnbDescrambling.
Bug: b/240476983
Test: Test: ts-tradefed run vts --module VtsHalTvTunerTargetTest
Change-Id: I003c6405e7fcc4e3494ef976dca83b9f7d6160a6
This CL implements integration tests for LnbDescrambling. The new
testing function ScrambledBroadcastTestWithLnb tests the functionality
of the Lnb and, if the frontend is not software, tests passing a signal
through the tuner and descrambling a broadcast.
Additionally, this CL adds a context variable to the
ScrambledBroadcastTest function to determine which dataflow
(LnbDescrambling or Descrambling) is being tested. It specializes
behavior differently for each datflow to model real world
use cases. Notably, a Descrambler could be tested with no frontend when
playing back a descrambled recording, whereas testing an Lnb broadcast
would require a hardware frontend.
Bug: b/240476983
Test: ts-tradefed run vts --module VtsHalTvTunerTargetTest
Change-Id: Ia35d2d45dca4411b0a15f0585d6ddaecd3f9321a
This CL implements a new dataflow: LnbDescrambling, which aims to test
descrambling a broadcast brought into the tuner with an Lnb attached.
The struct for the configuration and a function to read this dataflow
from the vendor's input file were added. Additionally, the api was
updated to allow the automatic xml parser to read this new dataflow.
Note, no tests were added for this object yet. Those come later in the
chain. The vendor, at this moment, can only harcode this dataflow. It
will be dynamically configurable later in the chain.
Bug: b/240476983
Test: ts-tradefed run vts --module VtsHalTvTunerTargetTest
Change-Id: I545be7d4b2bea0b80a67fd542a80bba7fa38c4ca
This CL allows the VTS to read a vendor's configuration file, determine
if the given devices could support the Live dataflow, and generate
all combinations of units to run them on corresponding integration tests.
Each combination is error checked to ensure they meet the minumum
requirements, and any invalid ones are discared, which may narrow the
combination space immensely.
This CL also adds logic to store IP and PCR filter IDs to include
using them in any configuration combinations. We also pair PCR filters
with audio and video filters if the vendor chooses to provide more than
1, enforcing the invariant that the number of pcr, audio, and video
filters must be equal. If there is only 1 pcr filters, we default to
use that one.
Bug: b/182519645
Test: vts-tradefed run vts --module VtsHalTvTunerTargetTest. Manual
tests with different input configuration files.
Change-Id: Icb2d96b32ed7a14b845c752a79744c44fdaf04e3
This CL allows the VTS to read a vendor's configuration file, determine
if the given devices could support the DVR Record dataflow, and runs the
integration tests with all valid combinations.
2 functions were added to help drive the testing logic.
generateRecordCombinations() generates all valid record dataflow
configurations, and the integration tests call
generateRecordCombinations() to analyze whether to generate these
combinations or use the data flow provided by the vendor (if there is
one).
Additionally, when dynamically configuring DVR_Record, a bug was exposed
in the VTS that came about from recycling the function
recordSingleFilterTest(). When LnbRecord was initialized with a software
frontend, the VTS was looking to the record dataflow's dvr source for
input. If record is not hardcoded by the vendor, the VTS would crash.
To fix this error, an enum class was added as a parameter to
RecordSingleFilterTest() to take into consideration which dataflow
(lnbRecord or record [no Lnb]) was calling the function. New behavior is
defined to take into account both cases. Also, lnbRecord will not be
tested if there are no hardware frontends, as this is not very likely to
be configured by vendors.
Bug: b/182519645
Test: vts-tradefed run vts --module VtsHalTvTunerTargetTest. Manual
tests with different input configuration files.
Change-Id: I76c05ca2e33767e4bdcd2072db5144d495d623b0
This CL allows the VTS to read a vendor's configuration file, determine
if the given devices could support the TimeFilter dataflow, and generate
all combinations of units to run them on corresponding integration tests.
Additionally, the configuration file is checked to see if the vendors
provide the dataflow themselves. If not, the combinations are created.
Bug: b/182519645
Test: vts-tradefed run vts --module VtsHalTvTunerTargetTest. Manual
tests with different input configuration files.
Change-Id: Icdbf8961e9dc06fd979be953027409a0a197cba4
This CL enforces the invariant that vendors provide audio and video
filters in pairs to the Tuner Hal VTS. Thus, the number of each must be
equal. If they do not, the tests are not
ran, and the test suite exits.
Additionally, this CL enforces the assupmtion that vendors will pair
their audio and video filters in the order they are provided, and it
treats the audioFilterIds and videoFilterIds vectors as 2 parallel
structures, where members at the same indicies correspond to a pair.
This is how media filter pairs are chosen when configuring them in the
VTS testing combinations.
Bug: b/182519645
Test: vts-tradefed run vts --module VtsHalTvTunerTargetTest. Manual
tests with different input configuration files.
Change-Id: I74cc059ed610bb08d0929f250f252a16c9f954a8
This CL checks to see if the frontends given in the LnbLive dataflow are
accompanied by a software frontend. If so, these tests are not ran,
because this does not model a real world use case that would be
intentionally configured by a vendor.
Furthermore, the implemented code fixes a bug that would cause the VTS
to crash if the LnbLive tests were ran using a software frontend without
the vendor having configred the Live dataflow. Previously, the
workaround for using a software frontend with an Lnb was to use the dvr
source configured in the live dataflow to simulate input to the frontend.
Now that vendors do not need to provide this in their configuration file
(because it will be automatically generated for them), this access causes
an error that makes the VTS crash. With this new fix, this logic will never be
exectuted, and the VTS will not crash in this case.
Bug: b/240305035
Test: Test: vts-tradefed run vts --module VtsHalTvTunerTargetTest.
Change-Id: I68dc7ff4cfd103a51e3e8d7c6ff787d349a9e241
This CL fixes an issue on the Tuner HAL VTS that lead to a memory leak.
Heap space was allocated to store Lnb Id's for dataflows without being
cleaned using Free(). The fix includes switching to the use of an
integer passed by reference. No heap memory is allocated.
Bug: b/240572001
Test: Test: ts-tradefed run vts --module VtsHalTvTunerTargetTest
Change-Id: I9fcad4c05f548ee4b64cfb34175f34834eec6c56
This CL expands the settings and specs that can be added by vendors to
DVBS frontend types. It also updates the value expectations to model the
format present in the other types.
Bug: b/239968750
Test: vts-tradefed run vts --module VtsHalTvTunerTargetTest
Change-Id: Ifd4a97ce71cfea11e4f5c1293a6342e337cb5699
This CL allows vendors to specify extra filters they would like to
include in the Live dataflow. Note, however, that these filters are not
included in any integration tests yet, as those will come later.
Additionally, this CL cleans up the code originally used to configure
extra filters for DVR playback. It converts the code and API strucutre
to a uniform format consistent with that of other dataflows that allow
extra filters.
Bug: b/239751563
Test: vts-tradefed run vts --module VtsHalTvTunerTargetTest
Change-Id: I662814666873254eff84791b5057da1f44f5e73e
The Dvr::startFilterDispatcher method is intended to
call the startFilterHandler method on every filter by using
pass through methods in the Demux. However, the method
currently returns early with a failure (false return value)
whenever isVirtualFrontend and isRecording are both false.
This causes the thread that the method is called from to
immediately log and exit.
This error occurs when the Dvr::startFilterDispatcher
method is called from the Dvr threadloop, but not when it
is called from the Demux threadloop due to their different
parameters. As noted by current bug 239731089, this means
that this error is only exhibited inconsistently due to
a race condition.
Bug: 237718541
Test: Manually using Cuttlefish, as well as VTS. Previous
inconsistent Dvr filtering errors no longer occur.
Change-Id: I677b66bdc0dacf1a7d57bcbd3085ffd6475547dd
This CL allows the VTS to read a vendor's configuration file, determine
if the given devices could support the Descrambling dataflow, and generate
all combinations of units to run them on corresponding integration tests.
Each combination is error checked to ensure they meet the minumum
requirements, and any invalid ones are discared, which may narrow the
combination space immensely.
Bug: b/182519645
Test: vts-tradefed run vts --module VtsHalTvTunerTargetTest. Manual
tests with different input configuration files.
Change-Id: Ic1b9dae6b43f8f01bc4e490ef9e910a933562bd2
This CL allows the VTS to read a vendor's configuration file, determine
if the given devices could support the LnbRecord dataflow, and generate
all combinations of units (frontend, record filter, dvr, lnb)
to run them on corresponding integration tests.
Bug: b/182519645
Test: vts-tradefed run vts --module VtsHalTvTunerTargetTest. Manual
tests with different input configuration files.
Change-Id: I470d593195d3f6e81cea9758b5758ec47ad3d21c
This CL allows the VTS to read a vendor's configuration file, determine
if the given devices could support the Scan dataflow, and runs the
integration tests with all valid frontends.
Bug: b/182519645
Test: vts-tradefed run vts --module VtsHalTvTunerTargetTest. Manual
tests with different input configuration files.
Change-Id: Ic6756e284090fbd1961a9ed12c1a4b541fb834b8
This CL allows the VTS to read a vendor's configuration file, determine
if the given devices could support the Lnb Live dataflow, and generate
all combinations of units to run them on corresponding integration tests.
Bug: b/182519645
Test: vts-tradefed run vts --module VtsHalTvTunerTargetTest. Manual
tests with different input configuration files.
Change-Id: Iba5262375b3053e0093f91fd3b05a9ebd42ca7d0
This CL allows the VTS to read a vendor's configuration file, determine
if the given devices could support the playback dataflow, and generate
all combinations of units (dvr, audio filter, video filter, section
filters) to run them on corresponding integration tests.
Additionally, began storing section filter id's and eliminated the check
to see if they were stored already by utilizing the TearDown() function
between integration tests.
Bug: b/182519645
Test: vts-tradefed run vts --module VtsHalTvTunerTargetTest. Manual
tests with different input configuration files.
Change-Id: I8e8be258dce9927e755f9c8bdb41441f367a196b
dataflows
This CL allows the VTS to read the contents of vendors'
configuration files and determine which dataflows can be tested
depending on the devices provided. This only implements the logic of
determining which data flows are possible. Currently, the data flow
section of the configuration file is still being read, and
configurations are not being cycled yet. Additionally, TearDown() was
overidden for each testing class.
Bug: b/182519645
Test: vts-tradefed run vts --module VtsHalTvTunerTargetTest
Change-Id: Ib3b3c4de62e6556ef44b42e855a369a5015d66ff
As according to the ISO/IEC 13818-1 specification, media
data in TransportStreams comes in PES packets which are
made up of TS packets. Currently, the MediaFilterHandler
strips out TS Headers, but leaves the PES headers in with
the Media data. This CL has the MediaFilterHandler process
and remove the PES Header from the Media data, while saving
the Presentation Time Stamp if it exists.
Bug: 238889790
Test: Manually using Cuttlefish and SampleTunerTIS to
receive events. Also tested on the VTS.
Change-Id: Idd4fe06f15f5420afd0c473128d8b30f5ca779c6
Previously in CL 19152256 the size variables for Pes and
Section event reading were made unsigned in order to
prevent negative values. However, the conversion from
int8_t directly to uint32_t still produces incorrect values.
To solve this, the values which are read in are first
converted from int8_t to uint8_t before their final
conversion.
Bug: 238797416
Test: Run on Cuttlefish with TS input, and view logging.
Old version should not work with any TS that declares a
size containing any byte with value > 0x80.
Change-Id: I55bb552bc857fd8acf16729f8cfcb9e147e07e9c
Currently, our startMediaFilterHandler returns on the first
time it successfully creates a MediaEvent. This does not
match the intended behavior, which is that all of its
current output is read and turned into events, and then
cleared.
Bug: 238797398
Test: Manually with Cuttlefish and SampleTunerTvInput.
Before change, any input type except ES will only create a
single MediaEvent. After change, full input will be handled
properly.
Change-Id: I856385cdf8ebb3a7d3fb0f864085123ec6c172b9
Currently, the HAL simply sends raw TS data when
SectionEvents are created from a TS file. This CL
will have the HAL process the TS packets and construct
sections to be sent to the SectionFilter. A slight-modified
TS protocol is used that mirrors the current implementation
for PES filters.
This CL is a replication of reverted CL 19121691.
Bug: 237323181
Test: Manually using cuttlefish and the SampleTunerTvInput.
SectionEvents should be received without the 4-byte
TsHeader or any trailing data.
Change-Id: I48de90c9674fb69ecf877359f89f6b4f7f3eaca7
The variable mPesSizeLeft is sometimes being set to a negative value
when it reads from TS data because of conversions from our int8_t vector. This is incorrect, as these sizes are defined to always be positive. Our vectors cannot easily be changed due to our AIDL interfaces, but the SizeLeft variable can be made unsigned to fix the issue.
Bug: 237819905
Test: Manually with cuttlefish and TS input to the DVR with
large values for size bytes. Can also manually test the
result of similar C++ expression to show the behavior.
Change-Id: Iae925cc3c505891b732434fb7c3ffadf7af95411
Currently, the HAL simply sends raw TS data when
SectionEvents are created from a TS file. This CL
will have the HAL process the TS packets and construct
sections to be sent to the SectionFilter. A slight-modified
TS protocol is used that mirrors the current implementation
for PES filters.
Bug: 237323181
Test: Manually using cuttlefish and the SampleTunerTvInput.
SectionEvents should be received without the 4-byte
TsHeader or any trailing data.
Change-Id: Ief6b9beb8f48bda1b83a0bffb83698ca431b7b12
This CL allows vendors to configure the DVR Playback data flow in their
configuration files for the Tuner Hardware. Their connections were
checked to ensure their validity. Additionally, vendors can now give an
extra list of optional filters that can be utilized in the DVR Playback data flow.
Bug: b/182519645
Test: vts-tradefed run vts --module VtsHalTvTunerTargetTest
Change-Id: Ie77337508444672e327ac88a91e73c96bd80fb22
LnbLive configuration
This CL allows vendors to configure Lnb's in their configuration
files. Also, support for the LnbRecord and LnbLive data flows was
implemented. Their connections were checked to ensure their validity.
Additionally, the option to configure extra filters for each was added.
Bug: b/182519645
Test: vts-tradefed run vts --module VtsHalTvTunerTargetTest
Change-Id: I4f733091beb70e7f5658fb5572064f4628bbbfc3
This CL allows vendors to configure the Descrambling data flow in their
configuration files for the Tuner Hardware. Their connections were
checked to ensure their validity. Additionally, vendors can now give an
extra list of optional filters that can be utilized in the data flow.
Bug: b/182519645
Test: vts-tradefed run vts --module VtsHalTvTunerTargetTest
Change-Id: Iaa216876307571afa3ae6baf4624d0da14657439
