No offense.
Quote:
Originally Posted by r0lZ
That's right, but I don't want to rewrite BD3D2MK3D again (almost) from scratch just to implement a way to seek in the video.
|
I didn't mean it that way! A person asked for a possibility of cutting source video during encoding. I just wanted to fix your "impossible" answer. This is all. My answer doesn't have meaning "add this solution". I wanted to say that this is impossible with BD3D2MK3D, but you can use other difficult way if you really want to achieve what you want. This is it.
Quote:
Originally Posted by r0lZ
And IIRC SsifSource is much slower than the current solutions.
|
Well, this is
that slow because it's using original sample_decode.exe from Intel SDK. If any all those people who developed their
fast solutions wanted to make it faster, they could develop their own optimized sample_decode.exe version that would still work with ssifSource. Unfortunately, I didn't have time to optimize sample_decode.exe myself. Still, the fact is that all these fast solutions are close-source while mine became open.
Quote:
Originally Posted by r0lZ
I didn't know that its seek is not frame accurate, but it's another reason to not recommend it.
|
It is I-frame accurate. I-frames usually appear every second of the video. 1-second accurate solution is something. And with SequentialToSeekable you can make it to start from the frame you want.
Quote:
Originally Posted by r0lZ
But you're right. I should have written that the MVC decoders currently supported by BD3D2MK3D or based on the Intel MVC decoder are not able to seek.
|
The latter is incorrect though. ssifSource is based on Intel SDK. The truth is that all decoders that work with .h264 files are unable to seek, because .h264 files does not contain an index, meanwhile, for example, .ssif file does. tsMuxeR.exe just ignores the index while extracting .h264 streams from .ssif/.m2ts file.