Валентин

Если у провайдера спрашивать не хотите, то или в настройках ее ковыряться, или wireshark поставить посмотреть куда приставка обращается.

Смотря, какие у вас возможности)
Если вы обычный пользователь IPTV, то можете воспользоваться ping/iperf для получения качественных параметров канала связи, wireshark для проверки работы IGMP, сетевыми мониторами для выявления текущей нагрузки на входящем порту, системными мониторами для получения информации о загрузке CPU и памяти.
Если вы оператор, то мы подробно обсуждали этот вопрос здесь.
Если вы поставщик контента, то для вас есть специальные приборы, в крайнем случае можно воспользоваться TS Reader.
Если вы не понимаете, какие возможности у вас есть, лучше пойти через фриланс)

Так выходит, у тебя уже не мультикаст, а http трафик. А обычный http браузером нормально отрабатывается? И пробовал ли совсем отключать iptables?

Я могу навскидку предложить несколько решений, но они потребуют наличия как минимум одного L3 свича. Он нужен как минимум для смешивания трафика (маршрутов) с разных вланов
1) самый правильный - все вланы с мультикастом проходят через L3 свич, на нем вы запрещаете (acl, igmp filter) определенные группы с нужного влана
2) самый масштабируемый - на L3-свиче заходят все вланы и поднимается PIM, явно указываются маршруты для групп (ip mroute static)
3) самый сказочный - клиенты используют igmp v3 с явным указанием источника
4) самый дебильный, но не требующий никакого другого оборудования - все каналы в одном влане, а на клиентских портах висят acl на нужные src-dst адреса. Впрочем, такие же acl можно повесить на порты, к которым подключены источники мультикаста

Все предложенные варианты примерно одинаковы. IGMP-proxy конечно лучше включать на железке, близкой к потребителю контента, если это возможно.
Но гнать мультикаст через туннели не очень хорошая идея. Я бы лучше сделал так: превратил мультикастовый трафик в HTTP с помощью udpxy и смотрел бы уже видео в режиме http. Это еще более актуально, если Вы будете смотреть IPTV с ноутбука через Wi-Fi. Для обработки событий падающего туннеля можно использовать средства SLA.
К сожалению, я не знаю, как включить udpxy конкретно на MikroTik.

Понятно, что если много абонентов, лучше сделать CAS. Сейчас есть приставки, в которых достаточно ввести pin-код или пароль, не испоьзуя внешних карточек. это является фичей прошивки и обычно интегрируется либо в ваш биллинг/middleware, либо в облачные решения.
Если ваш биллинг самописный и есть возможность напрямую подавать команды/acl на абонентский порт, достаточно просто настроить этот порт (отключить mvr, блокировать snooping, как захотите).
Далее, если у вас технология Option82 используется, на цисках наверняка можно указать нужную av-pair для блокировки multicastа.

Дальше нужно исходить из того, что у вас уже умеет делать биллинг, исмотреть, что проще.

PIM на свичах доступа обычно не ставят, так как не известно, вдруг где-нибудь придется втыкать более тупое устройство, чем циска.

Смотря как биллинг организован, какая технология для авторизации и как внутри сети все раскидано. Но на оборудовании надежней. Впрочем, если влан на порт, нормально заблокировать на брасе

Похоже у меня потери на сети. При более тщательном тестировании выявил участо с потерями 0.015% на UDP, 20MB. Походу влияет на качество.

А для того, чтоб не летел мультикаст, поставьте на крайняк ACL на ненужный порт.