Bug #235
UDP H264 stream corruption
0%
Description
Thx for ticket 233, it works fine now.
There are still a few streams that don't play well in tvheadend/showtime or tvheadend/xbmc combination
I've attached again the wireshark trace, TS (from the wireshark trace) and the recorded mkv (which was taken at another time)
Files
History
Updated by Steven VS - over 14 years ago
Updated by No matter what H264 stream (720p, 1080i, 1080p, AC3 audio, MPEG2 audio) I take, I have always artifacts. I stream here at home with VLC (server side). VLC at client side plays all the streams fine.
I have also tried to stream with RTP, but that's the same.
Updated by Steven VS - over 14 years ago
I found a part of the problem, PES header length has as maximum 0xFFFF. For big resolutions this is not sufficient. VLC makes a new PES header with hlen = 0 and fills it up with the rest of the frame. In tvheadend, if the startcode is 0x000001E0 and the next startcode is 0x000001E0, the information is dropped (because there are no H264 startcodes in between)
I tried to solve it with a dirty fix, when PES header length is > 0xFF00 (VLC never goes to 0xFFFF), consider the frame as incomplete and wait for more information.
However, for some reason, IP won't fragment these frames (I already tried TCP_MAXSEG and IP_PMTU_DISCOVER) and a lot are dropped. I still have to check this issue.
Updated by Steven VS - over 14 years ago
I finally solved the issue. Attached is a patch for the H264 - VLC server problem.
Also a small extra fix for ticket 233 is included. The problem is that you can have the following situation:
000001 000001e0 [pes header] 10
TVheadend thinks the SC is 00000100 and doesn't parse the PES header.
My TCP problems were driver related, if someone encounters it, you can play with ethtool and set tso off.
Updated by