[mythtv-users] mythcommflag vs mythtranscode for videos

[Peter Bennett (cats22)]

On 01/29/2013 05:24 PM, Michael T. Dean wrote:
> On 01/29/2013 04:31 PM, Peter Bennett (cats22) wrote:
>> I am using mythcommflag and it seems that it actually deletes the seek
>> table, i.e. existing seek table is removed. This actually works quite
>> well, the transcoded file is an X264 mks file and seeking works
>> perfectly with no seek table.
>
> Yes, as a matter of fact, we don't support the bitstream format of
> MKV, so you cannot create a seek table for MKV.  (I'm assuming you
> mean MKV for Matroska Video, as .mks would be Matroska Subtitle (only)).
>
>>   However if I do not run the mythcommflag,
>> the old seek table is still there, and seeking does not work at all,
>> trying to go forward or back stays in the same place and pixellates the
>> screen.
>
> Well, since we don't record to MKV, you must be creating the seek
> table (which should not be there for MKV).  Are you doing that with
> mythtranscode after you transcode to MKV with some other utility?  If
> so, we need to fix mythtranscode to forbid creation of seek tables for
> MKV.
>
>> I am not sure why this is so, but it works for me. I thin perhaps x264
>> mks files do not need a seek table so the mythcommflag is removing it.
>>
>
> Or, really, we need to remove both mythtranscode --buildindex and
> mythcommflag --rebuild and have only one approach for generating seek
> tables (likely in mythutil's command interface).
>
> Mike
> _______________________________________________

Sorry - I do mean MKV, not mks. I am transcoding the MPG files to MKV
X264 (using handbrake), then updating the recorded table with the new
filename ending in MKV. After that I run mythcommflag --rebuild which
deletes the seek table entries. I suppose I could use a SQL command to
delete the seek table entries instead. As I mentioned, keeping the old
seek table entries causes problems with seeking, but deleting them
solves the problem.

Peter