[FFmpeg-devel] Hauppauge HD-PVR Samples/Transport Support

Robert McNamara robert.mcnamara
Thu Feb 28 23:16:39 CET 2008


On Thu, Feb 28, 2008 at 1:10 PM, M?ns Rullg?rd <mans at mansr.com> wrote:

> "Robert McNamara" <robert.mcnamara at gmail.com> writes:
>
> > On Thu, Feb 28, 2008 at 11:59 AM, M?ns Rullg?rd <mans at mansr.com> wrote:
> >
> >> "Robert McNamara" <robert.mcnamara at gmail.com> writes:
> >>
> >> > Hi Folks,
> >> >
> >> > I recently had a chance to take a look at a TS produced by the new
> >> > Hauppauge HD PVR (HD Component Capture device with h.264/AAC Hardware
> >> > Encoding).  A little birdie also told me that several of them had
> been
> >> > uploaded to the incoming samples repository at mplayerhq.hu.  To get
> a
> >> > bit more visibility, one of the samples is also at:
> >> >
> >> > http://www.megaupload.com/?d=4JN6XWCD
> >> >
> >> > It's a 9 Mbit CBR TS of h.264 video and AAC audio.  Ffmpeg is able to
> >> > inspect the container, but not able to do anything useful with it so
> >> > far.  I've managed to dump a few of the first frames with mplayer and
> >> > they look amazing.  Based on the little info I've received, these
> >> > files should be a slightly-nonstandard Mpeg-2 TS container that
> >> > ffmpeg/libavcodec are currently unable to interpret.   I wonder if
> >> > anyone has/will have an opportunity to look at these files?  I know
> >>
> >> Tell me a filename on our ftp, and I'll have a look.
> >
> > I'm not certain that all of the files were uploaded successfully, but
> they
> > were put in a directory named appropriately (Hauppauge_hd_pvr).  The
> file
> > I've got is hcw_hd_pvr_1080i_h264_cap04.ts.  If I had to guess I would
> > imagine cap01, 02, 03, and 05 would be the others.
>
> There is nothing wrong with those files AFAICT (I don't have a strict
> MPEG TS checker at hand), and FFmpeg handles them without a glitch.
>
> > Thanks for looking into this!  I'm definitely not the only one
> > psyched about the potential of this box.
>
> I wasn't very impressed by the quality of those clips, but the source
> could have been bad for all I know.
>
> Oh, and don't top-post.
>
>
Completely right, I realized I had blown it as soon as I hit send.  My
apologies.

My "little birdie" can't tell me much about the files, but the info comes
from inside Hauppauge, and he's telling me, more or less, that they are not
standard TSes.  *If* you are so inclined as to look at  the TS's with an
analyzer, I expect there ought to be some fundamental differences.  I just
SVN up'ed to 12275, and ffmpeg with -acodec and -vcodec copy results in
failure:

*ffmpeg -i ../hcw_hd_pvr_1080i_h264_cap04.ts -acodec copy -vcodec copy
../test.ts
FFmpeg version SVN-r12275, Copyright (c) 2000-2008 Fabrice Bellard, et al.
  configuration: --prefix=/usr --enable-shared --enable-gpl --enable-pp
--enable-swscaler --enable-pthreads --enable-liba52 --enable-liba52bin
--enable-libfaac --enable-libfaad --enable-libfaadbin --enable-libgsm
--enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libx264
--enable-libxvid
  libavutil version: 49.6.0
  libavcodec version: 51.50.1
  libavformat version: 52.7.0
  libavdevice version: 52.0.0
  built on Feb 28 2008 13:38:32, gcc: 4.1.3 20070929 (prerelease) (Ubuntu
4.1.2-16ubuntu2)
Input #0, mpegts, from '../hcw_hd_pvr_1080i_h264_cap04.ts':
  Duration: 00:00:09.8, start: 0.387044, bitrate: 9454 kb/s
  Program 1
    Stream #0.0[0x1011]: Video: h264, yuv420p, 1920x1080 [PAR 1:1 DAR 16:9],
29.97 tb(r)
    Stream #0.1[0x1100]: Audio: mpeg4aac, 48000 Hz, stereo, 130 kb/s
Output #0, mpegts, to '../test.ts':
    Stream #0.0: Video: libx264, yuv420p, 1920x1080 [PAR 0:1 DAR 0:1],
q=2-31, 29.97 tb(c)
    Stream #0.1: Audio: libfaac, 48000 Hz, stereo, 130 kb/s
Stream mapping:
  Stream #0.0 -> #0.0
  Stream #0.1 -> #0.1
Press [q] to stop encoding
error, non monotone timestamps 3003 >= 3003
av_interleaved_write_frame(): Error while opening file
*
I think the reason those of us who are US-bound are excited is because it
allows up to sidestep our draconian cable companies and get a halfway-decent
HD stream where not currently possible.  Also, it appears the h.264 encoder
may be accessible outside of the component ins, i.e, might be possible to
pass a digital stream to the encoder and do quick h.264 encoding in
hardware.  Would be nice!

Thanks again for looking into this.

Robert




More information about the ffmpeg-devel mailing list