MPEG-TS with H.263 video stream

[hetoan2]

I am attempting to play back a live MPEG-TS stream over UDP (yes I know it has been stated before that this is not a supported feature) using the UdpDataSource. The MPEG-TS container has sample frames in h264 format.

I went about following the suggestions here: #90

The method I tried was to create a TsChunkSource/TsSampleSource modified from the HlsChunkSource/HlsSampleSource varieties in attempt to get playback to work. So far I have been unable to play the stream, despite the UdpDataSource receiving the packets. This leaves the player in a continuous "preparing" state.

My question is, do I need to implement my own renderer to play this type of stream?

I am unsure as to why my implementation is not sufficient, I am supplying the TsChunk/Sample Sources with the udp URI, which is using the HlsExtractorWrapper (which I am pretty sure is a mistake). The result is that the SampleSourceTrackRenderer is constantly stuck calling doPrepare(). This is because of HlsExtractorWrapper (and the resulting extractor) failing on it's own prepare() because the TsExtractor has never called output.endTracks() to signal the tracks built in the Extractor wrapper.

Should I be using a different extractor? Should I make my own extractor? I am unsure of the best way to go about solving this problem. Will there ever be support for this kind of use-case, where there is a single track without end? I know there are some major revisions going on in 2.x, but as of now on the dev branch, this issue still exists.

If I have omitted any important data, please let me know.

[amoussawi]

hey...if it's a simple mpeg-ts udp streaming, then you don't have to complicate it that much. just make sure that you are receiving full TS packets or you will run into problems. because you know, udp doesn't handle packet loss. make your udp packet size a multiple of TS packet size and this will be enough.

[hetoan2]

I am getting full TS packets, but the renderer never gets out of preparing. I have to look back at this when I implement a custom extractor. Unless there is a different way of instantiating the player.

[AquilesCanta]

I don't have enough information to give you a definitive answer, but I can tell that you are not trying to play an HLS stream, so you should just use an ExtractorSampleSource(no HlsExtractorWrapper or TsChunk involved, chunks are related to adaptive streaming, such as HLS). If you just pass along the default extractors, the correct extractor should be selected automatically.

[duanyao]

I also tried to play mpeg-ts over udp recently, these are what I learnt:

• Check the colorspace of h.264. ExoPlayer don't support yuv444p on some (or all?) android devices , try yuv420p instead (ffmpeg option is -pix_fmt yuv420p).
• Don't use intra-refresh feature of h.264, or ExoPlayer can't parse it, see Unable to play h.264 intra-refresh video from the middle of a live stream #1654. However, without intra-refresh the playback quality is very bad over WIFI due to packet losses.
• Make sure the udp packet size is multiple times of 188 (size of mpet-ts packet), or ExoPlayer can't parse ts stream when there are packet losses.

If the problem persist, I suggest recording the ts stream to a file, and try to play it with ExoPlayer.

[hetoan2]

@AquilesCanta I am trying to use the ExtractorSampleSource, but am unable to do so because the extractor is not reading the input correctly. I have looked into the issue further.

When using the comprehensive list of extractors the program becomes stuck on the Webm extractor. I have reduced the list of extractors to just TsExtractor, since I know this to be the format.

What appears to be happening is that the TsExtractor (which I have forced as the only extractor) is unable to load the correct payload reader for the PMT once it is available. I am getting the PAT fine (pid = 0), which then loads the PMT into the list of payload readers specified by the pid of the associated program in the table. The PAT reports this pid as being 256, however when the following packets are read, they are with pid = 257. Thus, the payload readers list returns null, leaving it in the continue state where it then attempts to read more packets.

Is my stream malformed? I am able to play it with VLC on android just fine, although I know sometimes they support things differently, even if it is incorrect.

[hetoan2]

I should also mention that I attempted to simply force the PIDs in order to get the PmtReader to consume the other packets. I was unable to enter the section where the streamType was interpreted by the switch statement. I am unsure why this could be happening, since the list of streamTypes already encountered should be empty, and nothing else should be exiting the while loop.

[AquilesCanta]

If what you said is right (about the pat referencing pid 256, and the pmt for that program having pid 257), then you are not going to be able to play it with Exoplayer's TS extractor (as you said, this is not spec compliant). It is not something we are going to add a workaround for, either. If there are no extra discrepancies, you could try replacing the pid for every 257 pid pmt to 256.

[hetoan2]

Upon further examination, I was able to determine that the pid 256 was pointing to the PMT, then the PMT pointed to pid 257 for the PES. The problem was that no pesPayloadReader was detected because the table reported H.263 (0x10) as the stream type, which is not a type supported in the stream switch case statement.

Am I wrong in assuming that the H.264 decoder should be able to parse the H.263 stream? I have heard the H.263 format was the precursor to H.264 and is quite similar, but do not know that much about it in depth.

[AquilesCanta]

Unfortunately we don't have a H.263 reader and I don't think the 264 one would work. But of course you can try it out with some small hardcoding. We could write one but it is not a priority right now considering the upcoming v2 release (feel free to contribute with one if you think it is similar to the h264 one).

I updated the title to avoid misleading people. I will use this issue to track H263 support in transport stream.