The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Выпуск мультимедиа-пакета FFmpeg 3.2

28.10.2016 19:17

После четырёх месяцев разработки представлен мультимедиа-пакет FFmpeg 3.2, включающий набор приложений и коллекцию библиотек для операций над различными мультимедиа-форматами (запись, преобразование и декодирование звуковых и видеоформатов). Кроме изменений, созданных внутри проекта, в новую версию также включены все последние наработки, развиваемые в ветках ffmpeg-mt (многопоточное декодирование) и libav (форк FFmpeg). Пакет распространяется под лицензиями LGPL и GPL, разработка FFmpeg ведётся смежно с проектом MPlayer.

Из изменений, добавленных в FFmpeg 3.2, можно выделить:

  • Новые фильтры:
    • weave - объединяет полукадры входного видео в один кадр, позволяя удвоить высоту клипа за счёт сокращения кадровой частоты;
    • gblur - применение фильтра Гауссова размытия;
    • avgblur - размытие через усреднение;
    • sobel и prewitt - применение операторов Собеля и Прюитта ко входному видеопотоку;
    • vaguedenoiser - подавитель шумов на основе вейвлетов;
    • nlmeans - подавитель шумов на основе алгоритма Non-Local Means;
    • sidedata и asidedata - удаление/выявления кадров с уточняющими данными для видео и звука;
    • crystalizer audio - простой алгоритм для расширения динамического диапазона звука;
    • acrusher - сокращение звукового разрешения через сокращения числа битов дискретизации;
    • bitplanenoise - показ и измерение уровня шумов в форме Bit plane;
    • maskedclamp - нормализует значение первого битового потока на основании параметров второго и третьего битовых потоков;
    • hysteresis - определяет маску общих компонентов в первом и втором потоках;
    • lut2 - создаёт и применяет таблицу поиска на основании двух входных видео;
    • yuvtestsrc - генерирует тестовый шаблон в формате YUV;
  • Обеспечена возможность использования механизмов аппаратного ускорения чипов MediaCodec для кодирования и декодирования H.264, HEVC, MPEG-4, VP8 и VP9;
  • Реализована поддержка ускорения декодирования H.263, VP8, VP9 и 10-разрядного HEVC (Dithered) через использующий CUDA декодировщик CUVID;
  • Добавлены распаковщики медиа-контейнеров (demuxer) для трекерных форматов, поддерживаемых в библиотеке libopenmpt;
  • Добавлена поддержка протокола tee для разделения вывода на несколько потоков (например, "tee:file://path/to/local/this.avi|file://path/to/local/that.avi");
  • Реализован псевдоупаковщик fifo, который можно использовать для отделения кодирования и упаковки медиаконтейнера через использование FIFO-очереди с асинхронным запуском упаковщика в отдельном потоке. Например, упаковщик fifo можно использовать совместно с упаковщиком tee для отправки потока в несколько обработчиков, принимающих данные с разной скоростью;
  • Добавлен универсальный упаковщик для Ogg Video (.ogv) и обеспечена возможность использования потоков VP8 в медиаконтейнерах Ogg;
  • Добавлена обвязка для декодирования через библиотеку OpenH264;
  • Добавлен упаковщик медиа-контейнеров (muxer) для формата TTA (True Audio);
  • В декодировщике als добавлена поддержка операций с плавающей точкой;
  • Добавлен кодировщик для форматов MLP (Meridian Lossless Packing) и TrueHD;
  • В утилите ffplay реализована поддержка вывода через sdl2. Поддержка вывода через sdl1 прекращена;
  • Поддержка расширенных списков редактирования для формата MOD;
  • Прекращена поддержка кодировщика libfaac;
  • В упаковщике медиа-контейнеров Matroska по умолчанию включена запись контрольных сумм CRC32 для всех элементов первого уровня.


  1. Главная ссылка к новости (http://ffmpeg.org/download.htm...)
  2. OpenNews: Выпуск мультимедиа-пакета FFmpeg 3.1
  3. OpenNews: Выпуск мультимедиа-пакета FFmpeg 3.0
  4. OpenNews: В FFmpeg устранена уязвимость, которая может привести к утечке локальных файлов
  5. OpenNews: Выпуск мультимедиа-пакета FFmpeg 2.8 с обилием новых фильтров
  6. OpenNews: Лидер проекта FFmpeg сложил с себя полномочия
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/45387-ffmpeg
Ключевые слова: ffmpeg
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (40) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 20:39, 28/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    энкодером AAC уже можно пользоваться?
     
     
  • 2.2, Аноним (-), 20:59, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Конечно, покупаешь лицензию и пользуешься.
     
  • 2.3, myc (?), 21:02, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    fdk_aac пользоваться религия не позволяет?
     
     
  • 3.32, Аноимный Аноним. Избранное (?), 19:39, 30/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Это не так. Например nero aac codec позволяет кодировать AAC 525 кбит, а ffmpeg 320 кбит максимум.
     
     
  • 4.33, Аноним (-), 23:27, 30/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Осталось придумать нафига нужны файлы AAC с скоростью 500 кбитов, учитывая что уже на 128 люди их от оригинала отличить напрягаются, а 320 - уже злостный оверкилл с большим запасом. Сделать запас еще больше конечно можно, но при такой щепетильности к качеству можно наверное уже использовать FLAC какой-нибудь. Там вообще все бит в бит, что хорошо для обработки и т.п..

    А так рулит OPUS - его даже на 64 кбитах двуногие почти не могут отличить от оригинала, да еще в вебе играется. Так что смысла плкупать или тем более пиратить у неры их софтину - чуть менее чем нихрена.

     
     
  • 5.41, Аноним (-), 12:18, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Не нужно сравнивать среднестатистические уши и чужие :), не говоря уже о том, что если сравнивать на недопищалке для айфона то разницы и в mp3 на 64 КБит можно не заметить
     
  • 2.5, Хряк (?), 21:07, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С разморозкой!
     

  • 1.4, Аноним (-), 21:05, 28/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >Реализована поддержка ускорения декодирования H.263, VP8, VP9 и 10-разрядного HEVC (Dithered) через использующий CUDA декодировщик CUVID;

    все замечательно, забыт h.264, ссылка на сайт\бложик с последними новостями от 12, видимо по этома автор новости не в курсе, что все cuda из декодера\энкодера в нвидии выкнуты, за некоторыми исключениями и сейчас декодер нвидия именует NVDECODE API (formerly called NVCUVID API)  и да декодер нвидия не умеет 10бит ни в каком формате https://developer.nvidia.com/nvidia-video-codec-sdk

     
     
  • 2.6, Аноним (-), 21:14, 28/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    мда, это в официальном чейнжлоге написал какой-та левый чел, качество ffmpeg новго кода последнее время падает
     
  • 2.9, Stax (ok), 02:32, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > декодер нвидия не умеет 10бит ни в каком формате

    Э мм это ограничение ffmpeg или линуксовой версии nvdecode api? Потому что под оффтопиком нвидия аппаратно декодирует не только 10-разрядный HEVC (который идет на UHD блюриках), но и 12-ти разрядный, популярность которого для рипов нынче стремительно набирает обороты.

     
     
  • 3.12, sergio78 (?), 09:23, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • –3 +/
    какой такой 12 битный внезапнопопулярный? опять это ~0,75% анимешников имеется в виду? ну так больные люди, в то время как на торрентах xvid рипов огромнейшее число, которые и про 10 битное не слышали.
     
     
  • 4.20, Аноним (-), 12:07, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > ~0,75%

    Ну, это ты хватил. Там нужно третий знак после запятой теребить.

     
  • 4.27, Stax (ok), 06:21, 30/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Устраивает xvid - смотрите xvid. Зачем другим советовать?

    Аналогичные аргументы по поводу 10-ти бит на пиксель говорили многие недалекие люди. "Да кому это нужно, мы xvid смотрим и будем смотреть, и вообще за углом продаются по 7 фильмов на диск, по фигу на разрешение и квадраты, зато 7 фильмов по цене одного диска!" И что вышло? Main 10 - рекомендованное представление для HEVC, и на UHD-дисках идет именно HEVC Main 10 (L5.0). В UHD TV тоже в основном будет он, т.к. примерно 5% уменьшение битрейта при том же качестве по сравнению с 8-ми битным. А люди.. люди массово смотрят то, что доступно. Сейчас Main 10 профиль HEVC - то, в чем идет новый 4K контент. Будете смотреть что есть, или перекодировать в 320x288 xvid?

    И я писал не "популярный", а "набирающий популярность". Потому что люди проверили и выяснили, что если делать рипы (этого исходного 10-ти битного потока), то при 12-ти битном кодировании артефактов на том же битрейте меньше. Main 10 HEVC при уменьшении битрейта лучше кодируется Main 12 профилем, только и всего. И вы можете мне не верить, но % 4K-рипов HEVC->HEVC с перекодированием, при котором берут Main 12 профиль будет побольше указанного вами процента. Разумеется, рипы без перекодирования остаются в Main 10. И, разумеется, это не относится к рипам старого контента - там пока нет такого большого резона менять формат, и от Main 12 толку скорее всего будет очень мало.

    А NV, собственно, вполне себе в теме, поэтому последнее поколение карт аппаратно декодирует Main 12 профиль.

     
  • 2.10, soarin (ok), 04:00, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > все замечательно, забыт h.264

    Не забыт, он был добавлен в предыдущих версиях. Это изменения ТЕКУЩЕЙ версии.

     
  • 2.28, iPony (?), 11:38, 30/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > и да декодер нвидия не умеет 10бит ни в каком формате

    И да, в этом ты соврал тоже.

     

  • 1.8, Аноним (-), 00:07, 29/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Debian же давно пообещал вернуться на ffmpeg по дефолту. Так почему даже в Сиде до сих пор VLC и MPV собирают с поддержкой libav?
     
     
  • 2.11, Аноним (-), 05:59, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Норкоман? Libav выкинули ещё в jessie.
    Библиотеки libavcodec, libavformat и др. — части ffmpeg'а.
     
     
  • 3.14, yrii2121 (ok), 11:22, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Норкоман? Libav выкинули ещё в jessie.

    Ты чутка не прав, Libav в jessie не выкидывали. Её выкинули в будущей версии.

    > Библиотеки libavcodec, libavformat и др. — части ffmpeg'а.

    https://packages.debian.org/jessie/libavformat56
    >>This is the library for handling file formats from Libav.

    https://packages.debian.org/jessie/libavcodec56
    >>This is the codec library from Libav (both encoding and decoding).

    Но, FFmpeg есть в jessie-backports.
    И уже:
    https://packages.debian.org/jessie-backports/libavformat57
    >> FFmpeg is the leading multimedia framework, able to decode, encode, transcode, ...

    https://packages.debian.org/jessie-backports/libavcodec57
    >> FFmpeg is the leading multimedia framework, able to decode, encode, transcode, ...

    и т.д.
    Libav форк же, названия оставили такое же.
    А так да, libavcodec, etc является частью пакета FFmpeg.

     
  • 2.15, yrii2121 (ok), 11:29, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Debian же давно пообещал вернуться на ffmpeg по дефолту. Так почему даже
    > в Сиде до сих пор VLC и MPV собирают с поддержкой
    > libav?

    libav (https://tracker.debian.org/pkg/libav) в testing и sid (на данный момент) нету.
    Собирается с ffmpeg.

     
  • 2.34, Аноним (-), 23:31, 30/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Debian же давно пообещал вернуться на ffmpeg по дефолту.

    Так они и вернулись. По поводу чего пара свежих убунт уже вышли с ffmpeg'ом.

     

  • 1.13, Вопрос по видео (?), 11:10, 29/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    Ребят, можно вопрос специалистам? На том же Rutracker'е есть четкие ребята, спецы в своем деле - кодировании видео. Есть целые известные RG (Release Groups), которые "знают как надо". За многие годы они стали настоящими профи и делают шикарные рипы, которые весят очень мало, при этом имея превосходное качество. Я слышал для этого нужно мощное железо, которое позволяет кодировать в несколько проходов (и якобы чем больше, тем лучше) и все такое. Вобщем вопрос в чем - можно ли создавать такие "самые четкие рипы", прям топовые рипы - на Linux. Я ведь правильно понимаю - для этого они на винде используют ПО, которое является надстройкой все того же FFmpeg? Значит весь тюнинг и кодирование рипов можно делать и в Linux, если есть видеокарта nVidia? Или нет?
     
     
  • 2.16, EuPhobos (ok), 11:46, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Пример двух проходного кодирования
    https://trac.ffmpeg.org/wiki/Encode/H.264#twopass
    Что мешает взять кусок видео в 60 секунд и всячески с ним поиграться?
     
     
  • 3.18, Вопрос по видео (?), 11:57, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так то ничего не мешает. Вопрос был чисто теоретический, сам когда-то 100 лет назад занимался кодированием под виндой, естесно через GUIшные проги, и не понимал как оно все работает, ничего не знал о начинке. В Linux не пользовался FFmpeg, ничего не кодировал, но видимо пора попробовать. Просто хотел мнения спецов.
     
     
  • 4.26, EuPhobos (ok), 13:35, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Если в винде тот же ffmpeg как начинка, то всё будет одинаково.
    Единственное что, я пробовал ускорить кодирование через NVENC видеокартой GTX 680, прирост скорости раза в 4-5, но качество получается ужасным, улучшить никак не получилось. Т.е. качество не просто "хуче чем", а совсем плохое, "мыло и квадратики".
     
  • 2.17, yrii2121 (ok), 11:55, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > ...
    > Вобщем вопрос в чем - можно ли создавать
    > такие "самые четкие рипы", прям топовые рипы - на Linux. Я
    > ведь правильно понимаю - для этого они на винде используют ПО,
    > которое является надстройкой все того же FFmpeg? Значит весь тюнинг и
    > кодирование рипов можно делать и в Linux, если есть видеокарта nVidia?
    > Или нет?

    В большинстве случаев, к релизу прикладывают отчет MediaInfo.
    Посмотри какие используются опции кодирования (Encoding settings). И поиграйся по аналогии.

    Если используют "чистый" x264, то для ffmpeg есть аналогичные ключи...
    http://www.videorip.info/x264/81-analogi-kljuchej-kodirovanija-x264-dlja-ffmp

     
     
  • 3.19, Вопрос по видео (?), 12:01, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    1. Mediainfo я так понял OpenSource, значит все хорошо.

    2. Опции Encoding settings - это надо смотреть на Rutracker'е где-то в разделе для кодировщиков?

    3. Она там используют x264/x265, а что насчет открытых кодеков? Они не такие хорошие?Есть ли конкурент x264/x265?

     
     
  • 4.21, yrii2121 (ok), 12:08, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > 1. Mediainfo я так понял OpenSource, значит все хорошо.
    > 2. Опции Encoding settings - это надо смотреть на Rutracker'е где-то в
    > разделе для кодировщиков?
    > 3. Она там используют x264/x265, а что насчет открытых кодеков? Они не
    > такие хорошие?Есть ли конкурент x264/x265?

    1. Да, программа есть под Linux.
    2. Строчка "Encoding settings" есть в отчете Mediainfo. Там написаны опции кодирования конкретного файла.
    По поводу опций и что выбирать (тема обширная, в одном сообщение не расписать; да и в инете на эту тему много есть статей):
    http://www.videorip.info/x264/78-polnoe-opisanie-vseh-kljuchej-kodirovanija-x
    https://rutracker.org/forum/viewtopic.php?t=1037661
    3. Внимательно прочитай, как минимум это:
    https://ru.wikipedia.org/wiki/H.264
    https://ru.wikipedia.org/wiki/X264

     
     
  • 5.22, Вопрос по видео (?), 12:16, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо добрый человек, вижу тема просто хардкор, одним месяцем изучения тут не обойтись. Но надо... надо изучать, ведь хочется делать крутые рипы. Спасибо за ссылки!
     
  • 5.23, Вопрос по видео (?), 12:21, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А можно полюбопытствовать? Возьмем обычный 1.5 часовой фильм (25 GB) на Bluray. Сколько времени займет перекодировать его в 8 гиговый рип максимального качества? Знаю зависит от многого, но чисто теоретически - рип на видеокарте GTX 600 Ti не одного фильма не может занимать больше 1 дня?
     
     
  • 6.24, Вопрос по видео (?), 12:22, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    одного фильма*
     
  • 6.25, yrii2121 (ok), 12:53, 29/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А можно полюбопытствовать? Возьмем обычный 1.5 часовой фильм (25 GB) на Bluray.
    > Сколько времени займет перекодировать его в 8 гиговый рип максимального качества?
    > Знаю зависит от многого, но чисто теоретически - рип на видеокарте
    > GTX 600 Ti не одного фильма не может занимать больше 1
    > дня?

    хз, я не проф. кодировщик. кодирую больше для себя и не часто.
    зависит от разных факторов: хар-ки ЭВМ, содержание видео...

    Я думаю, что если "порыться" по интернету, то какую-нибудь статистику найти можно будет.

     
  • 6.31, Аноним (-), 17:36, 30/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А можно полюбопытствовать? Возьмем обычный 1.5 часовой фильм (25 GB) на Bluray.
    > Сколько времени займет перекодировать его в 8 гиговый рип максимального качества?
    > Знаю зависит от многого, но чисто теоретически - рип на видеокарте
    > GTX 600 Ti не одного фильма не может занимать больше 1
    > дня?

    Видеокарта тут ни при чем - все качественные рипы кодируются только на CPU.

    Из практики, на моем разогнанном i7-2600K x265 на кодировании 1080p с битрейтом порядка 2000 kbit/s выдает порядка 1.5 fps, плюс-минус 0.3 в зависимости от контента. Качество при этом близко к оригиналу (SSIM ~ 0.98-0.99). При более высоком bitrate скорость еще больше падает. А дальше считайте сами. Учтите только, что кодировать надо как минимум два прохода.

     
  • 6.37, Аноним (-), 00:03, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Сколько времени займет перекодировать его в 8 гиговый рип максимального качества?

    А это зависит от того сколько ты готов ждать :). Чем больше ресурсов проца кодек может скушать тем лучше он может компенсировать движение и проч, достигая лучшего качества при меньшем размере или меньшего размера при равном качестве. И сколько это займет больше всего определяется мощностью проца и пределами толерантности.

    Скажем если жать в VP9 - он делает h.264 по битрейт/качество как с куста. Но на самых медленных режимах скорость кодирования может начать измеряться не в fps а в fpm. Frames per minute. И тогда кодирование может занять до-фи-га. В общем перфекционизм штука такая...

     
  • 6.42, Аноним 80_уровня (ok), 16:26, 01/11/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Я бы не использовал видеокарту. Нафик.

    А так — 12-36 часов, в зависимости от степени перфекционизма и свежести процессора (x265, говорят, неплохо оптимизировали для AVX2).

     
  • 4.38, Аноним (-), 00:05, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > 3. Она там используют x264/x265, а что насчет открытых кодеков? Они не
    > такие хорошие?Есть ли конкурент x264/x265?

    Сами эти кодеки открытые. Но патентованные. В exUSSR на это можно и забить. Если забивать не хочется и например хочется в браузере смотреть - посмотри на VP9. Он легко обижает x264 по битрейт/качество и рубается на равных с x265. Но вот кодирует он медленно. То-есть это конечно же настраивается, но на уровнях максимального качества он таки слоупок.

     
  • 2.30, Аноним (-), 17:25, 30/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я в свое время занимался рипами (для собственного пользования и интереса; к профи себя не причисляю), и частенько использовал avisynth. Вроде бы, "профи" тоже в свое время считали его "правильным" инструментом. Так вот, под Linux достойного аналога нет и не предвидится, хотя многое из его арсенала есть и в ffmpeg. Также под Linux нет миллиона GUI, которые упрощают и делают более наглядным кодирование и позволяют визуально оценить результат.

    Но, конечно, главное - это грамотно подобрать кодек и параметры кодирования. Кодеки под Linux есть, и если не боишься командной строки и есть куча свободного времени, то всё возможно.

     
     
  • 3.36, Аноним (-), 23:58, 30/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Но, конечно, главное - это грамотно подобрать кодек и параметры кодирования. Кодеки
    > под Linux есть, и если не боишься командной строки и есть
    > куча свободного времени, то всё возможно.

    В ffmpeg кодеки и есть, их там ДО-ХРЕ-НА. Найти формат который ffmpeg не прожует - еще суметь надо. И никакой маздайной возни с кодекпаками и конфликтами кодеков.

    То что человеку надо - грамотно параметры кодирования выбрать. Все это без проблем, особенно для штучных вещей. Если с ffmpeg не вломак повозиться - он умеет немеряно. Насколько я помню - гугель вроде как именно им транскодирует видео на ютубе, а для них все это - вопрос на миллион и даже не один.

     
     
  • 4.40, Аноним (-), 12:55, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >  ffmpeg кодеки и есть, их там ДО-ХРЕ-НА. Найти формат который ffmpeg не прожует - еще суметь надо. И никакой маздайной возни с кодекпаками и конфликтами кодеков.

    Речь была не о кодеках, а об обработке видео и звука.

     
  • 2.35, Аноним (-), 23:50, 30/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Проходов делается два В первом проходе кодек делает быстрое прикидочное кодиров... большой текст свёрнут, показать
     
  • 2.39, Аноним (-), 00:39, 31/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Значительная часть рипов на рутрекере до сих пор делается кодеком XviD, который ... большой текст свёрнут, показать
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру