[mythtv-users] Transcoding SD MPEG2 to H.264---recommendations?

[Nick Rout]

On Tue, Nov 30, 2010 at 7:38 PM,  <f-myth-users at media.mit.edu> wrote:
>    > Date: Tue, 30 Nov 2010 13:46:15 +1300
>    > From: Nick Rout <nick.rout at gmail.com>
>
>    > On Tue, Nov 30, 2010 at 7:54 AM,  <f-myth-users at media.mit.edu> wrote:
>    > >    > Date: Mon, 29 Nov 2010 13:19:03 +0000
>    > >    > From: "D. R. Newman" <d.r.newman at e-consultation.org>
>    > >
>    > >    > On 29/11/10 08:52, f-myth-users at media.mit.edu wrote:
>    > >
>    > >    > > However---the result was unusable.  The activity log was crammed full
>    > >    > > of "audio 192 time went backwards 0 ms, dropped 1 frames" and "video
>    > >    > > time didn't advance - dropped 1 frames" lines, and about halfway
>    > >    > > through the transcode, it suddenly went from claiming it had 20
>    > >    > > minutes to go, to done.  (It also said "sync: got 26887 frames, 60691
>    > >    > > expected", which might explain a thing or two.)  And the result, as you
>    > >    > > might expect, was a jumpy mess.
>    > >    > >
>    > >    > > I have no idea why this didn't work.
>    > >
>    > >    > One possibility is that the source file contains lots of errors. I
>    > >
>    > > I considered that, but c'mon.  It was just a normal PVR-250 recording
>    > > from an STB.  It plays just fine.  It seems unlikely that every other
>    > > frame (on average) has an error in it.
>
>    > What are you using to play the file?
>
> mplayer.
>
>    >                                    Are you keeping the exact
>    > filename that you were transcoding and then expecting myth to play it
>    > in place of the recorded programme you started with? That won't work
>    > well because the recordedseek table will be up the wop (TM technical
>    > term).
>
>    > Again if you are giving it a new name and plonking it in mythvideo, it
>    > may need a seektable built.
>
> I'm not playing in Myth at all at the moment, since I'm just testing.
> I took a PVR-250 recording that plays perfectly both in mplayer and
> when sent to a PVR-350 (yes, really, that's how I still watch those
> recordings, though obviously if the transcoding works, I'll switch
> to some VDPAU-supporting card that has an S-video output and send
> the results back to my interlaced CRT) and ran it through Handbrake
> with default options, and with some tweaked options when that failed.
>
> In all cases, I got a file that Handbrake said was missing roughly
> (but not exactly) half its frames, and which played maybe 200-500ms at
> a time and then jumped discontinuously ahead by about the same amount,
> forever.
>
> Either I've got a bad build of Handbrake, or it can't cope with ivtv
> files.  (Or maybe only with ivtv files that also have VBI CC data
> in them.  Or it's something else dumb that I'm not seeing.)  Files
> captured in the same exact way have played without incident for me
> that way for years, and on some Windows box as well using whatever
> Windows defaults to playing mpeg files with.
>
> I haven't (yet) tried either non-Handbrake transcoding, or running
> things through ProjectX first (is it scriptable? last I looked, very
> long ago, it looked like it only had a GUI, but I haven't had time to
> check back during this discussion)---this was just my initial report
> of trying the most-obvious thing and having it blow up for no apparent
> reason.

quick CL usage:
project x is scriptable.

Note: CL doesn't load the GUI components, except with switch [-gui]
<without options>  ...starts the GUI
switches and inputfiles can be in any order

options:
[-ini <path + inifile>] ..use that specified iniFile instead of the standard
[-dvx1] ..create a .d2v ProjectFile on demux
[-dvx2] ..create a .d2v ProjectFile + .ac3.wav (RIFF WAVE Header)
[-dvx3] ..create a .d2v ProjectFile + .mpa.wav (RIFF WAVE Header)
[-dvx4] ..create a .d2v ProjectFile + .ac3.wav + mpa.wav (RIFF WAVE Header)
[-out <path>] ..use that specified directory for output
[-name <filename>] ..use that specified filename for output
[-cut <file>] ..use that text based file as cutpoint list
[-chp <file>] ..use that text based file as chapterpoint list
[-id <tokens>] ..use only these (P)IDs, separated by comma ","
[-gui] ..display the GUI using all given CLI options
[-log] ..write the normal logfile
[-saveini] ..save changes made bei CLI in active .ini
[-split <xxx>] ..split output at xxx MB
[-demux, -tom2p, -topva, -tovdr, -tots, -filter] ..action types


>
> I'm not trying to use VDPAU yet on the mplayer side; in fact, I'm
> calling mplayer with zero args besides the input file (in MKV format)
> to a GeForce 9500 GT (I think---it's either some other nVidia onboard
> video on that machine, or a card I stuck in, but I don't recall and
> haven't checked yet) and it's doing fine---it's not complaining that
> it's too slow to play the result and dropping frames, or anything like
> that.  (It complains it can't open libvdpau, which isn't surprising
> because I've put zero effort into configuring VDPAU on that machine
> yet, and that its using ffmpeg's libavcodec family.)  Of course, it's
> only SD video.  If Handbrake hadn't spewed magabytes of complaints
> about dropped frames and magically finished halfway through its
> estimated time, I'd suspect the player, but at this point I suspect
> the problem is with Handbrake and not playback.