Skip to main content

TSB doesn't transition to Active state

Please note these java.net forums are being decommissioned and use the new and improved forums at https://community.oracle.com/community/java.
1 reply [Last post]
kpradeep
Offline
Joined: 2011-01-24

In Pipleline.c, when service decoding is initiated decode function is called in which the decode pids in live pipeline are first cleared and then set to the pids that will be decoded. When decoding is stopped decode_stop function is called but the decode pids in live pipeline are not cleared.

In a scenario where service decoding is stopped on a live pipeline and the same live pipeline is used only for buffering (or recording) a different service, the tsb pids in live pipeline are not mapped correctly (i.e in mapAvPIDs function) because the decode pids from the previous tune are not cleared. Due to this incorrect mapping, ifsHandle->ndexSize is always 0 and tsb does not tranitioning to Active state. Is this an issue? But when decode pids are cleared in decode_stop function, TSB transitions to Active state.

Below is an extract from the log

Service Selection
-------------------------------------------------------------------------------------------------------------------------
20110503 10:10:20.726 INFO RI.Stack- 170770 [pool-23] INFO presentation.AbstractDVRServicePresentation - starting broadcast session
20110503 10:10:20.726 INFO RI.Stack- 170772 [pool-23] INFO session.BroadcastSession - present org.cablelabs.impl.service.javatv.navigation.ServiceDetailsImpl@bfc70ae4[uniqueID=ServiceDetailsImpl754308712, locator=ocap://0x5e7, handle=org.cablelabs.impl.manager.service.SIDatabaseImpl$ServiceDetailsHandleImpl@2cf5d668[handle=2cf5d668], sourceID=1511, programNumber=1, appID=0, longName=, deliverySystemType=CABLE, serviceInformationType=SCTE_SI, updateTime=Mon May 02 22:37:29 GMT-06:00 2011, caSystemIDs=[ ], isFree=true, lsData=null], elementary streams: [ org.cablelabs.impl.service.ServiceComponentExt$DavicElementaryStream@b709cc74[service=org.cablelabs.impl.service.ServiceDetailsExt$DavicService@b709cc30[transportStream=org.cablelabs.impl.service.TransportStreamExt$DavicTransportStream@b709cc31 ni=org.cablelabs.impl.davic.net.tuning.NetworkInterfaceImpl@91c4b4f1, frequency=651000000, modulationFormat=16, tsid=15724], serviceId=1], pid=68, associationTag=null] ], BroadcastSession - networkInterface:org.cablelabs.impl.davic.net.tuning.NetworkInterfaceImpl@91c4b4f1, decodehandle: -1 decryptHandle=null, 259cc641, started: false, lock=java.lang.Object@cd596659, details(id)=ServiceDetailsImpl754308712, video=0x25573f80, started=false, blocked=false
20110503 10:10:20.742 INFO RI.Stack- 170781 [pool-23] INFO mpe.MediaAPIImpl - decodeBroadcast(params=MediaDecodeParams[ vd=0x25573f80, tuner=0x1, pcr=68, pids=[ 68 ], types=[ 2 ], block=false])
20110503 10:10:20.742 INFO RI.Stack- mpeos_mediaDecode() - called
20110503 10:10:20.742 INFO RI.Stack- mpeos_mediaDecode() pid cnt: 1
20110503 10:10:20.742 INFO RI.Stack- mpeos_mediaDecode() pid 68 is video pid, asking pipeline to decode
20110503 10:10:20.742 INFO RI.Display.VideoDevice- decode_bin_modify_link -- Attaching video device to pipeline: live pipeline
20110503 10:10:20.742 DEBUG RI.Pipeline- attach_video_device -- video device state read ok
20110503 10:10:20.742 INFO RI.Pipeline- decode() -- video pid 0x0044 (remapped to 1E0)
20110503 10:10:20.742 DEBUG RI.Pipeline- mapAvPIDs -- A/V PID remap values reset.
20110503 10:10:20.742 DEBUG RI.Pipeline- update_preproc -- Setting preprocessor pid list to 0x0044=0x01E0

After initiating a recording
----------------------------------------------------------------------------------------------------------
20110503 10:10:22.179 INFO RI.Pipeline.TSB- tsb_start -- Dump of PIDs:
20110503 10:10:22.179 INFO RI.Pipeline.TSB- 0x0BB8, type is RI_MEDIA_TYPE_VIDEO
20110503 10:10:22.179 INFO RI.Pipeline.TSB- 0x0BB9, type is RI_MEDIA_TYPE_AUDIO
20110503 10:10:22.179 INFO RI.Pipeline.TSB- 0x0BBA, type is RI_MEDIA_TYPE_AUDIO
20110503 10:10:22.179 INFO RI.Pipeline.TSB- 0x0BB8, type is RI_MEDIA_TYPE_PCR
20110503 10:10:22.179 INFO RI.Pipeline.TSB- 0x0065, type is RI_MEDIA_TYPE_PMT
20110503 10:10:22.179 DEBUG RI.Pipeline- mapAvPIDs -- A/V PID remap values reset.
20110503 10:10:22.179 INFO RI.Pipeline- mapAvPIDs -- existing A/V PID map: 0xBB8=0x1E1
20110503 10:10:22.179 INFO RI.Pipeline- mapAvPIDs -- existing A/V PID map: 0xBB8=0x1E1
20110503 10:10:22.179 INFO RI.Pipeline- mapAvPIDs -- existing A/V PID map: 0xBB9=0x2E0
20110503 10:10:22.179 INFO RI.Pipeline- mapAvPIDs -- existing A/V PID map: 0xBBA=0x2E1
20110503 10:10:22.179 INFO RI.Pipeline- mapAvPIDs -- existing A/V PID map: 0xBB8=0x1E1
20110503 10:10:22.179 INFO RI.Pipeline- mapAvPIDs -- existing A/V PID map: 0x65=0xE0
20110503 10:10:22.179 DEBUG RI.Pipeline- update_preproc -- Setting preprocessor pid list to 0x0044=0x01E0 0x0BB8=0x01E1 0x0BB9=0x02E0 0x0BBA=0x02E1 0x0065=0x00E0 0x0000=0x0000
20110503 10:10:22.179 DEBUG RI.Pipeline- update_preproc -- Setting preprocessor Remap info to 0x0002=0x0002 0x0065=0x00E0

Here 0x0BB8 should have been mapped to 0x01E0, but since video pid 0x0044 from previous tune is not cleared, 0x0BB8 is mapped to 0x01E1

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
smaynard
Offline
Joined: 2009-01-27

You are correct - this is an issues and I filed a bug (OCAP_RI-445) on your behalf...