alex22
29th January 2005, 19:57
Hello,
I'm happily using AGK 1.88b with transport streams. Thanks again for the awesome work: AGK literally divided by 3 the time I spend in DivXing a satellite program, that's not a minor feat !
There's just a minor bug, with a workaround, that I would like to report.
The bug: if the stream has two audio streams and a PMT which erroneously mentions only a single audio, then there's no way for the .tstream (generated through the Ctrl-F9 GUI) to be taken into account (even following the Readme advice, and selecting the same value twice). In this case only the front panel audio stream selection is followed, and this one is constrained to the single PID.
Hence I suspect that having a PMT overrides the .tstream in some way.
The workaround: remove the PMT with a PID filter. In this case, AutoGK behaves differently: it launches DGTable, then allows all audio PIDs to be selected from the front panel, thus the .tstream is not even needed in this case.
Hope this helps,
-Alex
I'm happily using AGK 1.88b with transport streams. Thanks again for the awesome work: AGK literally divided by 3 the time I spend in DivXing a satellite program, that's not a minor feat !
There's just a minor bug, with a workaround, that I would like to report.
The bug: if the stream has two audio streams and a PMT which erroneously mentions only a single audio, then there's no way for the .tstream (generated through the Ctrl-F9 GUI) to be taken into account (even following the Readme advice, and selecting the same value twice). In this case only the front panel audio stream selection is followed, and this one is constrained to the single PID.
Hence I suspect that having a PMT overrides the .tstream in some way.
The workaround: remove the PMT with a PID filter. In this case, AutoGK behaves differently: it launches DGTable, then allows all audio PIDs to be selected from the front panel, thus the .tstream is not even needed in this case.
Hope this helps,
-Alex