Phil and Jason: I was talking about a metadata parser for M2TS containers. Right now it seems like it's hit or miss... sometimes it will pick up the data and give me a duration, but most of the time I get a duration of 'None'. I know I said I could look into it... but between being busy and then being unmotivated, I admit I haven't really made progress on that front. If anyone else happens to be looking at adding metadata parsers to kaa.metadata, don't wait for me... -_-
Phil, the HD PVR sounds like a good solution to consider. Having the video show up on /dev/video0 would definitely be less of a headache. Right now I'm using a slightly-hacked copy of dvgrab to grab the stream over firewire and it works, but it fails more often than I'd like. The direct-firewire capture does have a few major features to its advantage. It captures the raw M2TS so any video overlays the cable box might add such as the programming guide or info window don't appear in the recording. The videos are recorded in their broadcast aspect and resolution with no black bars: HD channels are 1920x1080, local TV stations arrive in 1280x720 and the SD channels are 640x480. It also records full A52/AC3 surround audio and it even includes the closed-captioning stream, which I've played back as subtitles through VLC. Jason, I had a few notes to add to the conversation about my experience with MPlayer and M2TS playback. It does it, but it's not perfect. One of the major problems is that seems to assume the internal video timing (time code?) will start at zero, but with video grabbed from a stream, this isn't always the case. This leads to weird time displays like "2:10:05 / 1:00:00". It correctly reports the video is an hour long, but the internal time code started at two hours. This usually doesn't affect playback and is just cosmetic. Also MPlayer occasionally has difficulty finding the proper length of a video, but this doesn't affect playback either. In fact, it may be somehow related to bitrate issues, because everything is proportionally changed. For example, if you have a one hour video that MPlayer somehow decides is only 30 minutes long, it plays back fine and the on-screen timer will be moving at half-speed (i.e., it counts up one second for every two real seconds of video). I first noticed this when hammering on the video thumbnail creator to make it work with M2TS... some videos were detected as the wrong length, but if you set your seek to half that value, you still landed in the middle of the video. Finally, a non-cosmetic problem I've had is the audio sync suddenly going way off track. I have a suspicion of what's happening... that the network video stream has one time code, but when the local cable operator breaks away for local commercials, the inserted video has a different time code. MPlayer sees the time jump and says "!!!" and tries to resync the audio and video. And of course when the channel comes back out of local commercial, the time code jumps again. I have a file with an example of this and about 2/3 of the way through the audio falls out of sync and never really recovers by the end of the show. I tried re-encoding the video (even to a different format/container) and the sync issues persist. They don't appear on the HD concert videos I grabbed from Palladia, but in retrospect, Palladia doesn't have any local advertising that I could see (at least not during those concerts): It was all network video, so there weren't any time code breaks. For the first and last problem, it almost makes me wish there was a command-line option for MPlayer to make it use its own internal free-running timer for its calculations, but still use the video time code for the video output... I know it's needed to figure out frame orders if they arrive out of order. So having said all this, I know there's probably not much we can do, since MPlayer is its own entity, and as discussed previously, we (the Freevo community) aren't keen to hack on MPlayer just for our own purposes. But perhaps this could be something to consider when thinking of what video playback method to use in the future. And of course, as far as recording goes, I think a built-in raw firewire capture would be awesome! But I may be a demographic of one. No worries, that's what makes Freevo good in my book: Need something more? Write it in yourself! Cheers! James Springfield, OR USA ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 _______________________________________________ Freevo-users mailing list Freevo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freevo-users
