HeavyMetalTelevision.com mit IPTV

iptv.DisabledFilters = 1 2 6
iptv.ExtProtocolBasePort = 4321
iptv.SectionFiltering = 1
iptv.TsBufferPrefill = 0
iptv.TsBufferSize = 1

HeavyMTV;IPTV:10:S=0|P=0|F=EXT|U=hmtv.sh|A=0:I:0:256=27:257=@3:0:0:1:0:0:0

#!/bin/sh

# HeavyMTV;IPTV:10:S=0|P=0|F=EXT|U=hmtv.sh|A=0:I:0:256:257:0:0:1:0:0:0

#LOG=/var/log/vdr-iptv
LOG=/dev/null

if [ $# -ne 2 ]; then
    logger "$0: error: Invalid parameter count '$#' $*"
    exit 1
fi

PARAMETER=${1}
PORT=${2}
HLS="http://70.166.98.130:1935/hmtv/myStream/playlist.m3u8"
RTSP="rtsp://70.166.98.130:1935/hmtv/myStream"
RTMP="rtmp://70.166.98.130:1935/hmtv/myStream"

#Mostly working for weeks with some h.264 video artefacts until wowza server runs wild again with invalid P/DTS "Experiencing Technical Issues".  
ffmpeg -nostats -v debug -analyzeduration 10M -stimeout 10M -rtsp_transport udp -max_delay 100K -i "${RTSP}" -f mpegts -c:v copy -c:a mp2 -b:a 192k -ar 44100 -af volume=-10dB "udp://127.0.0.1:${PORT}?pkt_size=16356" > ${LOG} 2>&1

#Not better than rtmp.
#ffmpeg -nostats -v debug -analyzeduration 10M -stimeout 10M -rtsp_transport tcp -max_delay 100K -i "${RTSP}" -f mpegts -c:v copy -c:a mp2 -b:a 192k -ar 44100 -af volume=-10dB "udp://127.0.0.1:${PORT}?pkt_size=16356" > ${LOG} 2>&1

#NOTE: mp2 transcoding is a quirk needed for keeping VDR (and/or xineliboutput-sxfe) A/V demuxer/decoders in lipsync. 
#If the delivered MP4A format is a joint stereo format the used decoder versions cannot detect it and decode mono only,  
#be aware that surround information is destroyed by some joint stereo formats, so I assume the joint information in mono decoding mode, too.
#xine vdr-demux reports using faad, vlc too and reports stereo, but sounds mono, if You want to be sure use the ffmpeg audio vectorscope on an audio stream dump like this: 
# ffmpeg -v debug -i hmtvdump.aac -filter_complex "[0:a]avectorscope=s=1280x720,format=yuv420p[vid]" -map "[vid]" -map 0:a -codec:v mpeg4 -q:v 10 -codec:a mp2 output.mp4

#Audio only, in times of high latency / packet loss or hmtv wowza server runs wild again.
#ffmpeg -nostats -v debug -analyzeduration 10M -rtsp_transport udp -max_delay 100K -i "${RTSP}" -f mpegts -vn -c:a mp2 -b:a 192k -ar 44100 -af #volume=-10dB "udp://127.0.0.1:${PORT}?pkt_size=16356" > ${LOG} 2>&1

#Only working without nasty audio dropouts in spare low overseas latency times, otherwise triggering VDR TS-Packet Error intermittently.
#ffmpeg -nostats -v verbose -analyzeduration 10M -i "${RTMP}" -bsf:v h264_mp4toannexb -f mpegts -c:v copy -c:a mp2 -b:a 192k -ar 44100 -af volume=-10dB "udp://127.0.0.1:${PORT}?pkt_size=16356" > ${LOG} 2>&1

#Not working, chunk download always too slow, breaks with big underrun, server is too far away or too slow for non RT- protocols, west of U.S.
#ffmpeg -nostats -v debug -analyzeduration 10M -i "${HLS}" -f mpegts -c:v copy -c:a mp2 -b:a 192k -ar 44100 -af volume=-10dB "udp://127.0.0.1:${PORT}?pkt_size=16356" > ${LOG} 2>&1

#vlc 2.0.6, 2.2.1 not better than ffmpeg, maybe missing advanced adaption parameters.
#vlc -vv "${RTSP}" --sout "#standard{access=udp,mux=ts{pid-video=256,pid-audio=257},dst=127.0.0.1:$PORT}" --intf dummy > ${LOG} 2>&1
#vlc -vv "${RTMP}" --sout "#standard{access=udp,mux=ts{pid-video=256,pid-audio=257},dst=127.0.0.1:$PORT}" --intf dummy > ${LOG} 2>&1
#vlc -vv "${HLS}" --sout "#standard{access=udp,mux=ts{pid-video=256,pid-audio=257},dst=127.0.0.1:$PORT}" --intf dummy > ${LOG} 2>&1