SiChan

Members
  • Content count

    5
  • Joined

  • Last visited

Community Reputation

0 Neutral

About SiChan

  • Rank
    Newbie
  1. @jelockwood As far as I remember, MPEG StreamClip uses resources from Quicktime in order to open video files. This being the case, if you were to use MPEG StreamClip to open the .mpg file inside the EyeTV recording package, it would be video only, it would not be able to play the audio track. Therefore, re-saving the file using MPEG StreamClip would remove the audio. In addition, I'm pretty sure MPEG StreamClip would not be able to play the video file. I might give it a try some time in the future but for now I've re-connected my old standard definition-only EyeTV DTT to my iMac while my EyeTV T2 tuner is languishing in a drawer. At least the EyeTV DTT doesn't heat up to around 80oC while it's pugged in.
  2. Using EyeTV version 3.6.9 (7517) now which is supposed to fix a bunch of problems with the EyeTV-T2 tuner. They have re-added support for the tuner which was not included in the last couple of betas. However, the problem with non-reencoded .mp4 exports of HD channel recordings still remains. They still stutter and will not play on any equipment.
  3. BillyBob, you were right, unfortunately I spoke too soon about being able to fix the recording. The recording I passed through iFFmpeg while re-encoding the audio only plays well in VLC. Using Quicktime, the video plays for about 30 seconds and then gets stuck. The file plays ok for a while on my PS3 but gradually the sound goes out of sync. This is something that Geniatech just need to fix in the EyeTV software like you said. I already had an EyeTV DTT that worked fine for standard definition recordings but bought the EyeTV-T2 so I could record Freeview HD. Now it looks like it's a pretty useless bit of kit as only standard definition recordings work.
  4. Many thanks for your help with this Alfons. After trying out all your options I have found that converting the audio of the .mpg file found in the .eyetv package with ffmpeg is the only thing that works. I used the iFFmpeg GUI though as I find using the command line a bit scary. I first tried your option 1: Exporting the video and audio as separate files in EyeTV and then discarding the video .mp4 as it was now a "bad" file that would not play properly. Accessing the .mpg file inside the .eyetv package by right-click>Show Package Contents, I imported this into Avidemux. However, Avidemux gave an incorrect length for the video (too long). Exporting the .mpg file in Avidemux to an .mp4 (passthrough, no re-encode) results in a file that bizarrely has about half the audio (all the dialogue is in whispers but the music track is still there). Adding this .mp4 file to Subler meant that I could de-select the weird audio track. However, Subler also reported the video to be much longer than it actually was. Adding the .aac audio file exported from EyeTV to Subler in the hopes of mixing it with the video track did not work as the exported audio track, despite playing fine in Quicktime, reports a length of 00:00:00 in Subler. Using VLC to repackage this .aac audio into an .mp4 file without re-encoding resulted in a file that Subler would recognise as having the correct length of the recording. However, since Subler was reporting that the video track was much longer than the audio track it would not allow me to mux them into one file. Option 2: Importing the .mpg file from inside the .eyetv package into iFFmpeg and doing a passthrough of the video while re-encoding the audio to an AAC file with the same bitrate etc. as the original created an .mp4 file that plays fine and is the correct length. Again, before re-packaging into the .mp4 file, iFFmpeg was reporting the .mpg file to be much longer than it actually was. After re-encoding the audio and repackaging into an .mp4 everything is fine. Option 3: This would be the easiest option if it worked but unfortunately, using VLC to repackage the .mpg file from inside the .eyetv package into an .mp4 without re-encoding anything results in a file with a time much shorter than the original file and that only plays in VLC. Opening the resulting file in Quicktime, the video is a black screen and it said it was over 4 hours long! It's great that I now have a way of dealing with these recordings that works so thanks again. I wonder if there is anything I might be able to do with the recordings I've already exported to .mp4 in EyeTV and then deleted the original .eyetv package?
  5. Hi, I have an EyeTV T2 tuner capable of receiving DVB-T2 (Freeview HD) channels in the UK. It is currently connected to a late 2013 iMac. Watching HD channels with EyeTV 3 works fine. Also, if I record a program from one of these channels, the recording plays fine in the EyeTV software, on both the 2013 iMac with NVIDIA GeForce GT 750M graphics card, and on my relatively low powered 2009 MacBook. However, when I export one of these recordings, without re-encoding it, to an .mp4 file, the resulting file does not play very well on either Mac using Quicktime or VLC. The video frame rate is very choppy and the sound stutters. Also, skipping through the exported video is impossible and the video just turns to a grey screen. I have tried to play the exported mp4 files on multiple devices aside from the two Macs including a Samsung Smart TV, a PS3 and a Blu-Ray player and they all have the same problem. I was wondering why the recordings play fine in EyeTV but not when exported? The actual contents of the file, the video codec etc. should not change. Inspecting the exported .mp4 files show that they are 1080p H.264 encoded files with a Mbps of around 4 and with AAC encoded audio. I am sure these files are not too high a bit rate for my equipment to handle. Strangely, if I go to the .eyetv file of the recording and right-click>Show Package Contents, there is a .mpg file inside containing the recording that opens and plays fine in VLC. I was wondering what happens during the export process to inhibit the resulting .mp4 files from playing well? Do these recordings have some kind of digital rights management on them? Another thing I thought it could be is that the exported .mp4 files are somehow lacking a "header"? I remember this used to be a problem with the old .avi container format in that even relatively low bitrate files that should play fine would stutter and play badly if the header was absent. I'd be grateful if anyone could advise me on what I need to do with these files to allow them to play properly, ideally without re-encoding the video as I do not want to lose quality. Many thanks for your help