After we previously implemented a sketch of each single software component that we need for our TV prototype on the Raspberry, the next step was to create an actual proof-of-concept prototype. As noted before, we use the gnutv application from the Debian package dvb-apps because it already provides generic DVB functions which means that we can focus on the data decoding with OpenMAX. The idea is to provide a hardware specific output mode which allows users to watch TV like that:
gnutv -buffer 1048576 -out omx $CHANNEL
Because the MPEG-TS streams may contain several video streams as well as audio streams, we first need to select the PIDs that should be used for playback. More precisely, one PID for audio and one for video. To keep the prototype as simple as possible, we automatically select the first video stream and the first audio stream. These parameters are required to decode the MPEG-TS data into MPEG-ES.
Then we define a callback function for each type of data which passes the elementary data to the corresponding module (omx_video, omx_audio). At last we need to adjust the gnutv code to provide the new omx output mode, but that is straightforward and not an OpenMax issue.
Again we were surprised that even such a simple prototype performed so well. In short, the video decoding worked flawlessly and except for some noise in the decoded audio data, we could already watch TV. However, there are some open issues. It is probably a good idea to provide a dedicated cache for the MPEG-TS data to cope with jitter and similar problems. Furthermore, the audio module also needs some cleanup to get rid of the noise. But what is most important is to synchronize the audio and video data. During our tests, the video stream was always ahead of the audio stream. A solution for the problem should not be too hard since the MPEG data provides meta data and it is straightforward to enhance the prototype with threads and events for data synchronization.