Playing recorded video before it has been finalized

[urymf]

Hi,
Let me start by apologizing in advance if this is duplicated or redundant (as I suspect it should be). I searched and searched, but couldn't find the answer.

I'm looking for MKV a/v container alternative, and "HTML5 video containers" came up. Other than the codec support, the one requirement I have that files can be played while they are being "recorded".
Is this supported by mp4 (I'm almost sure it doesn't), ogg and/or webm?

Thanks in advance,
Ury

[ndjamena]

Um, I often open up my X264 encodes with VLC while they're encoding, just to see how they're going. Of course I can't seek because the index hasn't been written yet but I don't think any container will let you do that. Plus, it's quite common for people to go on forums wondering why they can't seek in their MKVs. The answer is usually that whatever encoder they were using hadn't finished and they were playing an incomplete file... What are you asking exactly?

[jagabo]

I can seek with MPCHC while MKV are being encoded with x264 CLI. Only up to the point where the encoding was when MPCHC opened the file.

[ndjamena]

Well, I can seek using VLC too, but I get a garbled screen until it stumbles across an I-frame. It's just using the file size as an indication of length, finding the first readable frame at a byte position and playing from there. I'm pretty sure once you add audio into the mix seeking becomes impossible. Index' are generally written into the end of the file, an encoder has no idea how many I-frames there are going to be so it has no idea how large the index needs to be, or how large the video itself will be, so writing in an index as you go isn't a possibility for any container, period.

[ndjamena]

WOW, I just tried MPC-HC on an MKV while Handbrake was encoding it [shudder] and it's seeking is MUCH better than VLCs, I must remember that. Not only is the I-Frame crap gone but the audio seeks properly too. VLC is useless once you add audio, no matter where on the timeline you press, you're pretty much going to end up at the same place. Now to quit the Handbrake encode and pretend it never happened!

[jagabo]

writing in an index as you go isn't a possibility for any container, period.

I believe Xvid does it by pre-extending the AVI file and writing a temporary index at the end. When the A/V data catches up to the index it extends the file again, writes a new temporary index at the end, then continues on.

And MPEG transport streams are designed for this type of random access. Hence all the overhead.

[ndjamena]

Riiiiight, a temporary index. Well, I just opened the Handbrake encode using MKVInfoGUI and there doesn't seem to be a cue in there, yet MPC-HC still plays it perfectly. Hmm, I wonder if it reads back or just skips to the next I-Frame... That's cheating!

[jagabo]

You can set VLC to "fast seek" too.

[ndjamena]

I set VLC to Fast Seek and restarted. I've played both the current X264 encoding and the unfinished Handbrake encode and nothing has changed, I still get a garbled start when seeking in the X264 file and the Handbrake file still doesn't seek at all. So I disabled Fast Seek in MPC-HC, restarted and again, nothings changed, no garbled frames at all, everything is perfect. MKVInfo still says there's no cue in the file... Apparently the 'Fast Seek' settings are redundant if there's no index to follow.

[urymf]

Thanks, and you're right - I didn't describe the scenario:
I'm developing a DVR-like application, which receives an a/v stream over IP, optionally re-encodes it and saves it to disk. The user should be able to play any portion of the recorded stream (seeking included) while it's still recording (not finalized).
I hope it's clearer now.
Thanks,
Ury

[ndjamena]

Either use the method XViD uses or use an external time-code file. Container is irrelevant.

MPC-HC even has the correct duration, there's nothing in the header that states the length, so I'm assuming MPC-HC simply reads the end of the file and finds the last time code, which is something VLC does better, it will simply play whatever's there, even video wasn't there when it started, then it returns to the beginning.

[ndjamena]

Oh, WHAT PLAYER??? Will you be writing your own playing software or will you be relying on mainstream players?

[urymf]

ndjamena, the player is not the issue here, unless I'm missing something.
What I'm asking is: do any of the mp4, ogg and/or webm video containers support playback from a file while the file is being written (i.e. not finalized) - like in the case of the mkv container.

[jagabo]

Use MPEG transport streams. They're designed for that type of playback. Broadcast video and DVRs with rewind buffers all use transport streams.

[urymf]

Thanks, MPEG-TS might be another option, but I'm asking specifically about "HTML5 video" formats.

[ndjamena]

As far as I can tell 'HTML5 Video' is a mess at the moment, but WebM seems to actually BE Matroska, so if you want something LIKE MKV, that would seem to fit the bill. Other than that... Handbrake is free, have you tried making an MP4 and seeing if it will play before it's finished? And by the way, although MKV CAN play before it's finalised, VLC and MPC-HC will attest that seeking isn't perfect. MPC-HC is limited to the size of the file when it was first opened while VLC is kind of a mess, I haven't tried WMP mid-encode but make sure whatever method you intend to play back with allows for an ever expanding play length or you may be wasting your time.

I'm wondering if MPC-HC or WMP actually index the files before playing, would there be any way of telling?

[jagabo]

I'm wondering if MPC-HC or WMP actually index the files before playing, would there be any way of telling?

A large file would take quite a while to index. I haven't noticed that happening.

[urymf]

Thanks ndjamena. I'll try webm while it's being recorded.