V.Zhukoff wrote: А почему тогда такая избирательная любовь к WASAPI рендереру? Ничего подобного с другими ресурсами не происходит.

Издержки так сказать эксклюзивного режима. Не только другие программы не могут в это время на устройство выводить, но и разные копии одной.

В последнее время я перестал пользоваться Прог демуксом. Да, при использовании ПрогАР Прог демукс не даёт рассинхрона, но наблюдается другой недочёт, который меня совершенно не устраивает и который отсутствует у Арксофт демукса.
Если записать передачу со звуком в AC3, а потом перекодировать звук в mp3 и снова наложить ( используются программы TSDoctor для демуксирования, Daniusoft Audio Converter для конвертирования и TSMuxer для муксирования), то при использовании Арксофт демукса не будет рассинхрона изображения и звука, а при использовании Прог демукса звук будет опережать изображение. В чём тут дело, не мне судить, а вам, Акад. Но для меня рассинхрон при конвертировании критичен.

kostan wrote:В последнее время я перестал пользоваться Прог демуксом. Да, при использовании ПрогАР Прог демукс не даёт рассинхрона, но наблюдается другой недочёт, который меня совершенно не устраивает и который отсутствует у Арксофт демукса.
Если записать передачу со звуком в AC3, а потом перекодировать звук в mp3 и снова наложить ( используются программы TSDoctor для демуксирования, Daniusoft Audio Converter для конвертирования и TSMuxer для муксирования), то при использовании Арксофт демукса не будет рассинхрона изображения и звука, а при использовании Прог демукса звук будет опережать изображение. В чём тут дело, не мне судить, а вам, Акад. Но для меня рассинхрон при конвертировании критичен.

Да, плохие файлы пишет ProgDVB. Еще хуже воспроизводит.
А зачем записывать звук АС3 если можно сразу писать в mp?
Вообще, такое количество программ последовательно могут и сами дать рассинхрон. Лучше бы пользоваться одной программой, мах двумя.

kostan wrote:В последнее время я перестал пользоваться Прог демуксом. Да, при использовании ПрогАР Прог демукс не даёт рассинхрона, но наблюдается другой недочёт, который меня совершенно не устраивает и который отсутствует у Арксофт демукса.
Если записать передачу со звуком в AC3, а потом перекодировать звук в mp3 и снова наложить ( используются программы TSDoctor для демуксирования, Daniusoft Audio Converter для конвертирования и TSMuxer для муксирования), то при использовании Арксофт демукса не будет рассинхрона изображения и звука, а при использовании Прог демукса звук будет опережать изображение. В чём тут дело, не мне судить, а вам, Акад. Но для меня рассинхрон при конвертировании критичен.

В TS поток пишется как есть с канала. Если какие то проблемы то либо софт конвертации кривой либо поток с канала. Обычно второе. Demux на это не влияет ни в TS ни в mpeg.

kostan wrote: Если записать передачу со звуком в AC3, а потом перекодировать звук в mp3 и снова наложить ( используются программы TSDoctor для демуксирования, Daniusoft Audio Converter для конвертирования и TSMuxer для муксирования), то при использовании Арксофт демукса не будет рассинхрона изображения и звука, а при использовании Прог демукса звук будет опережать изображение.

А не могли бы Вы выложить куда-нибудь кусок файла, на котором присутствует этот рассинхрон с prog demux?

Prog wrote:Если какие то проблемы то либо софт конвертации кривой либо поток с канала.

Не надо все пожалуйста сваливать на сторону.
Записывал по 10 мин мультики. Обычно они 55мб получаются. Так из 15 -6 штук кривых файлов ts размером 1,4 гиг. Где в хаосе в произвольной последовательности нарезан контент. Испорченые короче. При этом при передаче на экран все выводилось спокойно и аккуратно.

Такая концовка лога - нормальна или нет?

08:09:44.405 - >>> CMPEG2Splitter::Pause
08:09:44.515 - >>> CMPEG2Splitter::Stop...
08:09:44.516 - Flushing buffer is video 1
08:09:44.519 - Flushing buffer is video 0
08:09:44.523 - Flushing buffer is video 2
08:09:44.531 - Flushing buffer is video 3
08:09:44.538 - Zero FinishProcess
08:09:45.481 - Flushing buffer is video 1
08:09:45.484 - Flushing buffer is video 0
08:09:45.489 - Flushing buffer is video 2
08:09:45.494 - Flushing buffer is video 3
08:09:45.498 - Streams count 2
08:09:45.619 - >>> CMPEG2Splitter::Pause
08:09:45.620 - >>> CMPEG2Splitter::Run
08:09:45.620 - New speed 1.00
08:09:45.621 - New speed 1.00
08:09:45.649 - !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!DoesPTSJump
08:09:45.649 - Caching data. Sleep - 136
08:09:45.786 - New sub 69377.72 next 69378.07 gr tm: 0.15 start tm 345.63
08:10:03.348 - >>> CMPEG2Splitter::Pause
08:10:03.836 - >>> CMPEG2Splitter::Stop...
08:10:03.837 - Flushing buffer is video 1
08:10:03.840 - Flushing buffer is video 0
08:10:03.844 - Flushing buffer is video 2
08:10:03.849 - Zero FinishProcess
08:10:08.443 - Flushing buffer is video 1
08:10:08.446 - Flushing buffer is video 0
08:10:08.450 - Flushing buffer is video 2
08:10:08.455 - Streams count 1
08:10:08.509 - >>> CMPEG2Splitter::Pause
08:10:08.511 - >>> CMPEG2Splitter::Run
08:10:08.511 - New speed 1.00
08:10:08.522 - !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!DoesPTSJump
08:10:08.522 - Caching data. Sleep - 40
08:10:08.562 - New sub 69457.68 next 69457.91 gr tm: 0.04 start tm 363.82
08:10:11.275 - >>> CMPEG2Splitter::Pause
08:10:11.295 - >>> CMPEG2Splitter::Stop...
08:10:11.297 - Flushing buffer is video 1
08:10:11.300 - Flushing buffer is video 0
08:10:11.304 - Flushing buffer is video 2
08:10:11.309 - Zero FinishProcess
08:10:14.598 - Flushing buffer is video 1
08:10:14.601 - Flushing buffer is video 0
08:10:14.605 - Flushing buffer is video 2
08:10:14.610 - Streams count 2
08:10:14.611 - Flushing buffer is video 0
08:10:14.712 - >>> CMPEG2Splitter::Pause
08:10:14.716 - >>> CMPEG2Splitter::Run
08:10:14.716 - New speed 1.00
08:10:14.717 - New speed 1.00
08:10:14.730 - !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!DoesPTSJump
08:10:14.730 - Caching data. Sleep - 200
08:10:14.931 - New sub 70708.72 next 70709.13 gr tm: 0.21 start tm 366.63
08:10:14.982 - Out OSD № 1, siz = 3128, tim 0.00, gr tim, delta buf/pes start 9
08:10:14.982 - Out OSD № 1, siz = 2944, tim 0.00, gr tim, delta buf/pes start 9
08:10:14.983 - Out OSD № 1, siz = 2760, tim 0.00, gr tim, delta buf/pes start 9
08:10:15.133 - Out OSD № 1, siz = 4048, tim 0.00, gr tim, delta buf/pes start 9
08:10:15.384 - Out OSD № 1, siz = 6256, tim 0.00, gr tim, delta buf/pes start 9
08:10:16.284 - Do graph pause: traffic is over.
08:10:16.284 - >>> CMPEG2Splitter::Pause
08:10:16.696 - Buf pos has resized. Isvideo = 3
08:10:18.839 - Buf pos has resized. Isvideo = 3
08:10:22.707 - Buf pos has resized. Isvideo = 3
08:10:57.201 - >>> CMPEG2Splitter::Stop...
08:10:57.394 - Flushing buffer is video 1
08:10:57.426 - Flushing buffer is video 0
08:10:57.430 - Flushing buffer is video 2
08:10:57.435 - Flushing buffer is video 3
08:10:57.439 - Zero FinishProcess
08:10:58.162 - >>> CMPEG2Splitter::Pause
08:10:58.164 - >>> CMPEG2Splitter::Run
08:10:58.164 - New speed 1.00
08:10:58.164 - New speed 1.00
08:11:17.242 - Flushing buffer is video 1
08:11:17.245 - Flushing buffer is video 0
08:11:17.249 - Flushing buffer is video 2
08:11:17.254 - Flushing buffer is video 3
08:11:17.259 - Streams count 2
08:11:17.359 - !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!DoesPTSJump
08:11:17.359 - Caching data. Sleep - 127
08:11:17.486 - New sub 95072.49 next 95072.93 gr tm: 0.24 start tm 368.50
08:11:25.183 - Do graph pause: traffic is over.
08:12:01.703 - RecreateAndResizeBuffer
08:12:01.703 - Main buffer has resizing isvideo 1
08:12:28.652 - RecreateAndResizeBuffer
08:12:28.652 - Main buffer has resizing isvideo 1
08:13:47.690 - RecreateAndResizeBuffer
08:13:47.691 - Main buffer has resizing isvideo 1
08:18:59.019 - RecreateAndResizeBuffer
08:18:59.020 - Main buffer has resizing isvideo 1

ProgDVB видимо упал в этой точке. А падения видны (или нет) в ProgDVBEngine.log.

Просто странно,что две строчки повторяются три раза. Даже четыре. Интересно, почему?
И о каком буфере идёт речь?

kostan wrote:Просто странно,что две строчки повторяются три раза. Даже четыре. Интересно, почему?
И о каком буфере идёт речь?

Это увеличение кэша демукса до максимума. Так как трафик поступает, но не используется.
P.S. Так что с файлами, которые плохо играются на ProgDemux и хорошо на других? Выложите кусочик? Интересно было бы найти в чём дело и поправить.

Akad wrote:

kostan wrote:Просто странно,что две строчки повторяются три раза. Даже четыре. Интересно, почему?
И о каком буфере идёт речь?

Это увеличение кэша демукса до максимума. Так как трафик поступает, но не используется.
P.S. Так что с файлами, которые плохо играются на ProgDemux и хорошо на других? Выложите кусочик? Интересно было бы найти в чём дело и поправить.

Очень трудно выложить всё наглядно, но я попытаюсь.

Akad wrote:Так что с файлами, которые плохо играются на ProgDemux и хорошо на других?

Лично у меня нет проблем с Prog демуксом. Проблемы с дефолтным MS. И не с тем, что плохо играются. А с тем что иногда плохо пишутся. Раз. А второе,
что проигрывание файлов на MS демуксе + DDSD дает большую нагрузку, сыпет картинку и тормозит звук. Совсем нет таких проблем на WASAPI
Короче именно к ProgDemux у меня претензий нет.

Akad wrote:

kostan wrote:Просто странно,что две строчки повторяются три раза. Даже четыре. Интересно, почему?
И о каком буфере идёт речь?

Это увеличение кэша демукса до максимума. Так как трафик поступает, но не используется.
P.S. Так что с файлами, которые плохо играются на ProgDemux и хорошо на других? Выложите кусочик? Интересно было бы найти в чём дело и поправить.

Файлы не плохо играются. Просто, если они записаны при включённом ПрогДемуксе, то их аудио при конвертации накладывается так, что, хотя Adobe Audition косвенно показывает, что и звук, и изображение синхронны, но при наложении звука звук опережает изображение. А при записи файлов при включённом Арксофт демуксе при наложении синхронизированного по показаниям Adobe Audition звука на изображение и звук и изображение синхронны. И вот мне интересно, почему. Легче всего сказать, что это просто глюк программы Adobe Audition. Но даже если это и так, она же не просто так ошибается. Мне кажется, дело в записи. При использовании разных мультиплексоров запись происходит по-разному. Хотя вполне может быть, что я не прав.

На всякий случай напомню, что демукс в зависи не участвует. Он даже не нужен для неё в async. mode.

Prog wrote:На всякий случай напомню, что демукс в зависи не участвует. Он даже не нужен для неё в async. mode.

Просто впечатление такое, что при записи при использовании Прог демукса сначала начинает записываться видео и только через 0.700 секунды аудио. При этом в записи получается 0.700 секунды тишины, которая рядом программ, а возможно и всеми, просто не воспринимается. А при использовании Арксофт демукса и звук и изображение начинают записываться в одно и то же время.