Bug #165
IPTV restream problems - some h264 streams loses VIDEO pid packets
0%
Description
The problem h264 streams are taken from DVB-T and multicasted to network by vlc. Possible cause is that DVB-T provider is using somehow exotic transcoders, maybe that is the cause of all this.
I can watch H264 channel by udp://@ on vlc with no problems. I am appending log from tvheadend.
[[INFO]:subscription: "RTSP" subscribing on "tl", weight: 500, adapter:
"eth1", network: "<N/A>", mux: "239.255.255.51", provider: "<N/A>",
service: "<N/A>", quality: 100
[DEBUG]:Transport: 0.0.0.0/: Status changed to [Hardware input]
[DEBUG]:Transport: 0.0.0.0/: Status changed to [Hardware input] [Input on service]
[DEBUG]:Transport: 0.0.0.0/: Status changed to [Hardware input] [Input on service] [Demuxed packets]
[DEBUG]:Transport: 0.0.0.0/: Status changed to [Hardware input] [Input on service] [Demuxed packets] [Reassembled packets]
[DEBUG]:RTSP: 192.168.1.247:
rtsp://192.168.1.72:9981/channelid/1/streamid=2 -- Stream MPEG2AUDIO
to UDP port 51778
[DEBUG]:RTSP: 192.168.1.247:
rtsp://192.168.1.72:9981/channelid/1/streamid=1 -- Stream MPEG2AUDIO
to UDP port 51780
[INFO]:subscription: "RTSP" unsubscribing from "tl"
Service details of transport in tvheadend ui show h264 video stream
pid, and sometimes log shows lines like:
Mar 13 19:20:21 TS: 0.0.0.0/: H264 #70: Continuity counter error, 1 duplicate log lines suppressed
#68: Continuity counter error
Mar 13 19:20:21 TS: 0.0.0.0/: MPEG2AUDIO
Mar 13 19:20:21 TS: 0.0.0.0/: MPEG2AUDIO @ #69: Continuity counter error
Maybe packets are lost on remuxing...
Attachind stream dump.
History
Updated by Andreas Smas over 14 years ago
- Status changed from New to Fixed
- Found in version set to duplicate
I believe this is a dup of #235