Skip to main content

Trick mode for XDK

3 replies [Last post]
mowknow
Offline
Joined: 2007-10-18
Points: 0

Hi, I'm looking at how to get trick mode working for the XDK simulator using the OCAP-RI (seek and FF at various speeds for now). I'm aware that you guys are working on DVR simulation. Presumably you have to implement some or all trick mode features as part of DVR simulation. Am I right in my thinking here, and if so is there any code/design-discussion/example that I could look at? Anyone I could discuss this with? Thanks.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
sglennon
Offline
Joined: 2008-12-17
Points: 0

Regarding the incompatibility of the plug-ins, I'm not really sure. Without debugging the situation directly to find out what the GObject issues are, there is nothing obvious, aside from the version mismatch. The GStreamer base code does move on significantly over time, so a 0.10.22 to 0.10.23 compatibility issue would not surprise me. As an example, during our development we made a transition between minor versions of GStreamer to pick up support for GstBitBuffer and GstByteBuffer.

The ETV muxing sounds intriguing. I can see how this would be useful, and might be a handy addition to the GStreamer plug-in stable. Let me if you would like to discuss this further - maybe we can help and/or offer advice.

For the frame drop we would not be "re-encoding" - we would need to do inspection within the TS payloads and decide where the boundaries are so we can drop the appropriate TS packets. There is a slight wrinkle in that a PES packet may contain partial and/or more than one frame. To make the most robust implementation we would have to dissect and re-encapsulate. At least we would not have to do the hard parts of video encoding.

Steve

sglennon
Offline
Joined: 2008-12-17
Points: 0

The current (ongoing) DVR platform work makes use of some standard GStreamer plugins for storing the file and playing it back (filesink and filesrc respectively). The current plan is to implement two new elements (indexingfilesink and trickfilesrc or similar names) which specifically support MPEG2 transport streams, and create/store both the mpeg transport stream and an index file.

This will allow us to create the most flexible approach for DVR trick modes, supporting frame/packet accurate seeking, (very) fast forward and reverse etc.

The expectation we have for our implementation is that we will likely support only I-frame trick modes in the near-ish term. More complex modes like I+P or I+P+B "nearest frame" modes could be supported, but it is not clear that they are really necessary, given that this is more of a simulator/emulator than a consumer appliance.

In the short term we don't have this in place - so we are left with using standard GStreamer elements and methods to do "client side" trick mode.

To get to full server-side trick mode as required by the Home Networking extension, we will have to get the indexer/trick aware source implemented.

A couple of other thing I should mention in this area - for recording we are taking a short-term easy way out. Though the platform "supports" conversion of a time shift buffer to a permanent recording (we report all the right clipping/progress/status), we don't actually copy the TSB file to a permanent recording. Whenever you play back ANY recording, you will get the same canned file. This is because we really need to get the indexing in place before we create the library that copies parts of a TSB file to a permanent recording - that copy library needs to be index aware.

Second, we don't currently implement a "circular buffer" style of time shift buffer file in the platform. If you start a time shift session, the TSB file will grow indefinitely, though the stack/seek behavior enforces the expected constraints of only being able to seek back 90 minutes (or whatever is specified). We fully support dynamic changes in the duration of the TSB from a reporting/conversion/status point of view, we just don't trim the front end of the file, so on the physical disk if just grows indefinitely until the TSB session is terminated.

Steve

mowknow
Offline
Joined: 2007-10-18
Points: 0

Thanks for the informative response

Sounds like you will need to decode the video ES to drop the P+B frames, then re-encode the video ES before streaming to the client. We could have shared functionality in the decode-and-drop frames part, although for our environment we do not need to re-encode; Our server and client run on the same box. For this reason, we may be able to use the existing videorate plugin to drop frames, although this raises some performance issues since it drops them after they have become video/x-raw-yuv.

It's possible that we would have shared functionality in the filesink/filesrc part as well, although this would require us to change our current architecture so that our ETV muxer module becomes a gstreamer element. Currently we mux the ETV stream into the A/V and send the TS packets via udp to the gstreamer pipline receiving packets with udpsrc.

On a more pragmatic level, do you know why gstreamer plugins downloaded from http://www.gstreamer-winbuild.ylatuya.es/doku.php?id=download do not work with the ocap-ri version of gstreamer? When I run

/gst-inspect-0.10.exe --gst-plugin-load=libgstvideorate.dll

I get this error.

(gst-inspect-0.10.exe:5660): GLib-GObject-WARNING **: cannot register existing type `GstObject'

(gst-inspect-0.10.exe:5660): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

(gst-inspect-0.10.exe:5660): GLib-GObject-CRITICAL **: g_type_register_static: assertion `parent_type > 0' failed

(gst-inspect-0.10.exe:5660): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

(gst-inspect-0.10.exe:5660): GLib-GObject-CRITICAL **: g_type_register_static: assertion `parent_type > 0' failed

(gst-inspect-0.10.exe:5660): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

Possibly it is because OCAP-RI is running gstreamer v 0.10.22, gstreamer-winbuild is at 0.10.23?

(libgstvideorate.dll is not part of the OCAP_RI.)