So what.? The "Audio Channels" submenu was greyed out for non-stereo audio tracks in VLC 2.0 and earlier, just like the "Stereo Mode" menu is greyed out now in VLC 2.1. When files aren't being transcoded, the situation is completely different, because the file is available on disk and the size is known, so jumping to any specific position in the source file is easy.See that last pic above that says stero ? I have the same issue its like a dull grey I cant change it or anything and I don't understand that paste bin like or what ever it is sorry The data that has already been transcoded isn't stored either, so UMS doesn't even know where it is byte-wise at any given time. There's simply no way to translate a byte-offset into a specific position when the data is being generated on-the-fly. But, those that only support byte-based positioning regardless of if UMS had done all it should correctly, ultimately cannot seek when transcoding. UMS doesn't handle all of these details properly, so there are probably some renderers where it could work had UMS done it correctly where it's not available. That said, it's not quite that simple, as there are multiple details I left out, that can impact what the renderer supports and not. This means that renderers that use time-based positioning does support seeking while transcoding, but those that only accepts byte-based positioning doesn't. The duration in time is known since it is the same as the duration of the source file. When transcoding, the duration in bytes in undefined, there's no way to know that until you have transcoded the whole file (aka played through it). The fundamental problem is that some use byte-based positioning (by number x from the start of the file) and some use time-based positioning. In short, seeking while transcoding works on some renderers but not on others. That said, the duration (in bytes, not seconds) would still be unknown so I don't quite see how it would solve anything.
0 kommentar(er)
