I apologize if this has been covered before, or if it really isn't a part of the plan for MediaFork, or if I oversimplify, but here's my scenario.
I make EyeTV recordings, which are made as "MPEG1/MPEG2" (elgato's description). EyeTV has a lot of options for exporting (transcoding) its own recordings, presumably by using the Quicktime engine?
Anyway, given that MediaFork/Handbrake has always been about dealing with a DVD or VIDEO_TS source (MPEG-2), why not also have it recognize a MPEG-2 source that's not in a stream (i.e., one that was previously saved as an .mpg, as EyeTV does ... make sense? Or is a .mpg also a stream ... ?
The goal here for me is to be able to not have to use Apple's H.264 encoding if MediaGrid can do it better.
MPG > MP4
Forum rules
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.
*******************************
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.
*******************************
Re: MPG > MP4
Makes sense. Getting more mpeg-2 sources into the app is one of my longer-term goals, but it's not going to be easy, as right now we have a very specialized input system titer hand-coded just for reading DVD data.deckeda wrote:Anyway, given that MediaFork/Handbrake has always been about dealing with a DVD or VIDEO_TS source (MPEG-2), why not also have it recognize a MPEG-2 source that's not in a stream (i.e., one that was previously saved as an .mpg, as EyeTV does ... make sense?
For now, I suggest using the x264 QuickTime component.
have you tried isquint? its pretty bare bones on options but it works well enough, and should be able to read your mpeg 2 files. the ipod/tv toggle switches resolution i believe (320x240/640x480), and maybe some other switches. size and bitrate (and a few other) options can be overridden in the advanced settings.
ah -- Visual Hub. I'd forgotten, thanks. I just now glanced an saw an EyeTV thread there ... I have much to read on that site too.
Anyone happen to know what (read: how "good") their implementation of H.264 is like, compared to x.264 used here?
Maybe I just answered my own question, if H.264 is H..264 is H.264 but I admit not understanding the disadvantages of using Quicktime's H.264 encoder, if that's what this is about ...
Anyone happen to know what (read: how "good") their implementation of H.264 is like, compared to x.264 used here?
Maybe I just answered my own question, if H.264 is H..264 is H.264 but I admit not understanding the disadvantages of using Quicktime's H.264 encoder, if that's what this is about ...
VisualHub utilizes an ffmpeg binary for everything, but ffmpeg is using x264 as well. I know that can be confusing because in HandBrake "ffmpeg" just means regular old MPEG-4, but the ffmpeg project folds in any number of codecs, including x264. So VisualHub uses the same h.264 encoder. It's just that we use x264 directly, whereas they use it indirectly.deckeda wrote:ah -- Visual Hub. I'd forgotten, thanks. I just now glanced an saw an EyeTV thread there ... I have much to read on that site too.
Anyone happen to know what (read: how "good") their implementation of H.264 is like, compared to x.264 used here?
Maybe I just answered my own question, if H.264 is H..264 is H.264 but I admit not understanding the disadvantages of using Quicktime's H.264 encoder, if that's what this is about ...
Now I'll confuse you more. Right now HandBrake 0.7.1 uses a much older copy of x264 than VisualHub uses. But MediaFork 0.8.0b1 uses a relatively current one, which I think is newer than the one in the copy of ffmpeg VisualHub uses. And by HandBrake 0.8.0b2 we'll be using whatever the latest and greatest x264 is, and try to stay current. At least, that's my intention for the future, if prigaux's cool with it (he's the one who actually compiles the universal binaries of the libraries).
There are a number of reasons why QuickTime's h.264 encoder sucks. The first reason is that it doesn't do high profile. Neither does HandBrake (quite yet), but the extra bells and whistles high profile h.264 entails can raise picture quality drastically. The other big reason is it's pretty slow slow compared to x264. And a minor quibble is that it tends to not do well in quality shoot-outs. The reference spec is the same for all the encoders, but there can be lots of variation in how they're applied.