Re: [Mjpeg-users] Mjpeg-users Digest, Vol 1, Issue 1994
On Tue, Jun 20, 2006 at 10:39:17PM -0700, David Strozzi wrote: My beefs with gmplayer: I can't step frame by frame through a movie. Again, think you're giving a talk at a scientific meeting, showing data at successive timesteps, and someone in the audience says wait wait, go back a few frames. You want a keystroke that will go back one frame. If you're really just dealing with a sequence of still frames, then you might try an image browser such as gthumb instead. You can make it full-screen and it has simple keystrokes and buttons to advance forward/backward in the image set. I've used it to view captured video (after unpacking it to one frame per file) and from what I remember if I held down the forward/backward button it played them at around 30fps. -Dave Dodge ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] jpeg flipbook
On Tue, Jun 20, 2006 at 10:07:10AM -0700, David Strozzi wrote: So my more basic question is, of the 'standard' movie file formats, which I guess are AVI, MOV, and MPEG, can any of them function as 'containers' for jpegs or pngs or bitmaps? There is a png codec that can be used to store lossless frames in quicktime. I think it's really intended for production/editing use, but I've run into it once in the wild: http://www.veer.com/download/moveyourfeet.mov That's a music video done in the style of low-res videogame graphics, where solid colors and hard pixels are desired. The downside is that while the Apple quicktime player (on MacOS and Windows) can display it, I have yet to find any Linux video player that recognizes the codec, even with the win32 binary dlls loaded. -Dave Dodge ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] DC30+ miscapture: 2nd field sometimes shifted by one line
On Fri, Mar 31, 2006 at 10:26:01AM +0200, [EMAIL PROTECTED] wrote: OK, SVHS probably isn't the thing I need because my VCR is only VHS and a cable won't make it better ;-( I'm nearly at the point to try to write a deinterlacer which fits the 2nd field into the 1st one by x/y-shifting it. Needs motion search. But this would be a workaroud, not a fix. I would really prefer to solve the problem, but I don't know what causes it. Could it simply be a very slight timing difference beween the VCR and the proper frame/fieldrate for PAL? Several months ago I tried doing some NTSC capturing (using a cx88 device and mencoder) from a fairly high-end consumer VHS deck and outboard comb filter. There were problems. In addition to the occasional dropped frame, if I looked very closely at a captured frame with matching fields I could see that the scanlines were slightly misaligned. The misalignment was by different amounts in different parts of the frame, and I'm pretty sure it changed every time I recaptured the same sequence. I upgraded to a professional VCR with S-Video output and an internal time-base corrector, and the timing problems seem to have disappeared. Unfortunately this might be an expensive solution and there's still no guarantee it'll solve your particular problem. -Dave Dodge --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Yuvtools
On Thu, Mar 02, 2006 at 09:26:26AM -0800, Steven M. Schultz wrote: On Wed, 1 Mar 2006, Jerome Cornet wrote: Unfortunately in Canada they still sell NTSC-only DVD players, and there's no way you can play PAL-DVDs on those. Hmmm - are the same model(s) of DVD players available in Canada as in the US? Both are region 1 and NTSC so they might be the same. I was (pleasantly) surprised to put a PAL DVD (sent from Austria) in and it just worked. Some players in the US and I assume Canada are internally multi-format, even if they're not advertised as such. It might require entering a secret code into the remote to unlock the capability, the same way that some can unlock multi-region support. Some can even transcode, playing back PAL DVDs as NTSC or vice versa, though the resulting image might be a little choppy. Ironically it can be the cheaper brands and models which have more of this functionality, probably so that they only have to design one device and then be able to sell it world-wide. Occasionally the DVD makers throw a fit and force a firmware change to disable the capabilties, so if you go shopping for a known-hackable model, don't be too shocked if a brand-new one doesn't respond to all of the old hacks. For example check your model here: http://www.videohelp.com/dvdhacks -Dave Dodge --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] B ... [WAS: y4mscaler: Upsampling to widescreen]
On Tue, Dec 20, 2005 at 11:15:43AM +1100, Mark Heath wrote: I'm not sure how this came about but I thought about training a Backpropagation neural net with sample images so that it may learn what the missing pixels looked like from the surrounding pixels. Just FYI, you might be interested in this work on Video Epitomes: http://www.psi.toronto.edu/~vincent/videoepitome.html -Dave Dodge --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] yuvdenoise -S and -b
On Tue, Oct 04, 2005 at 01:30:03PM -0700, Steven M. Schultz wrote: Is this from a VHS tape deck? Maybe a signal stabilizer would help, something like: http://www.kramerelectronics.com/indexes/item.asp?desc=98 or a TBC but that's probably more money than you want to spend ;) One option for NTSC might be the JVC SR-V101US. This is an S-VHS deck from their pro line, has Y/C output and a built-in TBC. It can be found online for under $300 in the US. I don't know if they have a PAL equivalent, though. -Dave Dodge --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Converting from jpg/png to dv
On Mon, Aug 08, 2005 at 12:02:50PM +0200, Dik Takken wrote: ffmpeg2raw.c:228: let op: implicit declaration of function `please_use_av_log' FYI: I think this message means that something is trying to use printf or fprintf within ffmpeg. ffmpeg intentionally tries to prevent that. -Dave Dodge --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Pro quality dvd streams for animation
On Thu, May 19, 2005 at 07:41:14AM +, Matt wrote: I've seen the Blender book on the shelf at Borders - maybe I'll pick it up and give it a try. For nothing, it is awesome software. Can't be beaten. Agreed, it's by far the most functional free tool out there. And if you don't mind getting a little dirty, you can throw together a farm in short order. Additionally, you really don't need the book. However, if you're _already_ familiar with some other big 3D modeling and animation package, you might really want a book on hand. I did some work several years ago with PowerAnimator (the precursor to Maya), and the Blender interface is so radically different that I was pretty much in a constant state of confusion every time I tried to use it. If you're coming in with no preconceived notions of how these tools are supposed to work, it may be a lot easier to get comfortable. -Dave Dodge --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Re: Compiling Mjpegtools under Cygwin
On Sun, May 01, 2005 at 09:41:51AM -0700, Steven M. Schultz wrote: On Sun, 1 May 2005 [EMAIL PROTECTED] wrote: A pleasant side effect is that you should have an easier time of building with Cygwin. Most appear to be type conversions which are not cast ie long to uint32_t. The correct thing, I believe, is not to just add casts (although that might be correct in many cases) but to change the the 'long' to 'uint32_t' (or int32_t). On 64bit platforms 'long' is 8 bytes (64bits). This may not matter here, but I believe on X86-64 Windows long remains 32 bits, in order to avoid breaking data structure layout in the Windows ABI. I don't know how this might impact Cygwin or other code. -Dave Dodge --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Re: Mjpeg-users digest, Vol 1 #1702 - 6 msgs
On Mon, May 02, 2005 at 09:19:51PM -0700, Steven M. Schultz wrote: My concern is that there may be (if not today, then tomorrow) systems for which 'unsigned int' is 64bits. Data points: I've seen an old Cray Unix system where all types except char were 64 bits. And I believe there's current DSP compilers where all types, including char, are 64 bits. For regular desktops and servers, a 64-bit int would be very unusual. Linux normally uses 32-bit int on 64-bit hardware, and I believe most other Unix-like systems are doing the same. The code seems to be going to a great deal of effort to determine ande use the machine's natural (fastest) word/int length and changing that to be 32 might not be optimal (or correct) for some systems. C99 has int_fast32_t and uint_fast32_t types in stdint.h, which are supposed to be set to the fastest integer types of at least 32 bits. Of course if you're shoving the code through a C++ compiler, or using some older C compiler, these might not be defined. -Dave Dodge --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Opteron + mjpegtools
On Sat, Feb 12, 2005 at 07:16:12PM +0100, Roine Gustafsson wrote: However, I'll wager the cluster of 32bit beige boxes would be more bang for the buck than a honkin' 64 bit Bigiron UltraPower. Atleast for rendering. An off the shelf Opteron or G5 will be a lot cheaper than the same amount of Itanium2/Power5 CPU speed, but available configurations cap out at about 4 CPUs and 64G of RAM per machine right now. Companies like SGI and HP can build Itanium2-based single machines with pretty much as many CPUs and as much shared RAM as you care to pay for. SGI is now even offering to build clusters of such machines with multiple 10Gbit/sec interfaces between them. If your job requires huge amounts of shared data, you don't have a lot of alternatives. -Dave Dodge --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Opteron + mjpegtools
On Sat, Feb 12, 2005 at 11:36:27AM -0800, Steven M. Schultz wrote:
On Sat, 12 Feb 2005, Roine Gustafsson wrote:
It's an urban myth that 64bit is faster than 32bit, like people assume
a 2GHz computer is twice as fast as a 1GHz computer.
It's also an urban myth that 64bit is slower than 32bit :)
Not automatically, but on MacOS you can easily run into trouble.
Anecdote: I took a benchmark of my own (mostly loops of integer math
and bitwise logical operations) and put it on a G5 XServe. This code
made use of some 64-bit integers. I compiled it with gcc generically
and it ran quite nicely. As I started adding flags to enable the use
of the G5's 64-bit instructions, it got slower. The more optimization
flags I added, the worse it got.
Here's why; consider this trivial bit of code to add two 64-bit
integers:
#include stdint.h
uint64_t foo(uint64_t const x,uint64_t const y) { return x + y; }
First a generic 32-bit compilation and the resulting assembly:
gcc -O3
_foo:
addc r4,r4,r6
adde r3,r3,r5
blr
Now let's turn on all of the options for G5 support and see what
happens:
gcc -O3 -mcpu=970 -mtune=970 -mpowerpc64 -mpowerpc-gpopt -force_cpusubtype_ALL
_foo:
stw r3,-32(r1)
stw r4,-28(r1)
stw r5,-24(r1)
stw r6,-20(r1)
ld r4,-32(r1)
ld r3,-24(r1)
add r2,r4,r3
mr r4,r2
srdi r3,r2,32
blr
GAH! The function's arguments are already in registers, but this code
writes them to RAM and then reads them back before using them. I
don't know enough about the G5's pipelining and cache performance to
say how bad this will be, but it's certainly going to be noticably
slower than the non-G5 version.
My guess is that since the current MacOS has no 64-bit support in the
ABI, all function arguments get broken into 32-bit values before being
passed. gcc wants to get the values into 64-bit registers so that it
can do a single add instruction, but for whatever reason it believes
the best approach to doing this is to use 32-bit stores and 64-bit
loads.
So a combination of the limits in the Apple ABI, and gcc's crazy
implementation, lead to the resulting code being much worse when
the 64-bit optimizations are turned on.
This is with Apple's supplied/modified gcc 3.3. I also tried a
vanilla gcc 3.4.1, but it generates even more instructions for the
64-bit case and additionally seemed to have some incompatibilities
with Apple's gcc wrt structure field layout. Perhaps the commercial
compilers will do better.
Hopefully the next MacOS with a 64-bit userland will fix all this.
-Dave Dodge
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] more telecine stuff
On Wed, Jan 26, 2005 at 09:41:07PM +, John Gay wrote: [...] We had several Super 8 home movies when I was a kid. Our local library also carried Super 8 movies before the advent of video tape. For example I have the home version of Star Wars on Super8. It's only one reel (16 or 17 minutes, I think), so it's actually just a couple of climactic scenes. Mono sound, and it's cropped to fit the 4:3 aspect ratio. Going back even further, there used to be a home market for 16mm. My father has a silent projector from his childhood that uses an ordinary light bulb. The belts are made from long metal springs and to change the projector to rewind mode you actually re-thread them onto different pulleys by hand. Films included cartoons, short Westerns, etc. Castle Films was a major supplier of this stuff for decades. -Dave Dodge --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplexing DTS streams, nearly
On Wed, Jan 19, 2005 at 07:31:45PM -0800, Trent Piepho wrote: On Wed, 19 Jan 2005, Steven M. Schultz wrote: [...] Have you tried upgrading autoconf on an old system? It's nearly impossible. Well, yes and no. Installing updated vesions of the autotools is pretty straightforward if you're used to installing things from source. A quick primer for those who haven't done it: download and unpack tarfiles http://ftp.gnu.org/pub/gnu/automake/automake-1.9.4.tar.bz2 http://ftp.gnu.org/pub/gnu/autoconf/autoconf-2.59.tar.bz2 http://ftp.gnu.org/pub/gnu/libtool/libtool-1.5.10.tar.gz prefix=/where/you/want/it/installed export PATH=$prefix/bin:$PATH export LD_LIBRARY_PATH=$prefix/lib:$LD_LIBRARY_PATH export CPPFLAGS=-I$prefix/include export LDFLAGS=-L$prefix/lib cd autoconf-2.59 ./configure --prefix=$prefix make make install cd automake-1.9.4 ./configure --prefix=$prefix make make install cd libtool-1.5.10 ./configure --prefix=$prefix make make install That will leave you with a clean, new autotools in your path. You can run autogen.sh and it should just ignore whatever versions happen to be installed by the system packages. That's the good news. Now for the bad news... If the CVS package you're dealing with (such as mjpeg_play) has external dependencies, then the configure script generation may require some macros that aren't bundled with autotools. These would be defined by m4 files that the dependencies themselves drop into the share/aclocal directory when you install them. In the case of mjpeg_play, it wants m4 files from (and I'm just listing the most recent stable versions): - pkgconfig 0.15.0 - gtk 1.2.10 - SDL 1.2.8 Otherwise you get complaints about things like AM_PATH_GTK, and the resulting configure script is broken. So you now have a couple options: - if you have those dependencies installed in your system directories, you can copy the relevant m4 files from the system share/aclocal to $prefix/share/aclocal and it might work. - you can install those packages with the same prefix as autotools. For example download the SDL source and use --prefix=$prefix when configuring it. It will then drop its m4 file into $prefix/share/aclocal and your new autotools will see it. - there might also be some way to set a search path for the aclocal files, but I don't know it off-hand. Note that this all implies that you might sometimes need to install several of a package's _optional_ dependencies in order to get configure script generation to work. The configure script may need macros from those optional packages even if you don't intend to enable them when you do the build. The minimum versions must be very bleeding edge, when redhat 9 and slackware No, not really. But their also not years old either (RH9 went end of life a some time back - they're up to fedora 3 or whatever now). To see what the fuss is about I just tried doing CVS mjpeg_play and indeed it was a bit painful. I was doing this on a server system that had very little desktop stuff installed; for example no GTK+ or pkgconfig in the system directories. I did all of the above to install a local copy of the latest autotools, as well as SDL and pkgconfig under the same prefix. Then I hit GTK+. I actually have a copy of GTK+-2 already installed for gimp (in a different non-standard prefix), but its aclocal file was too new. The mjpeg_play configure needs specifically GTK+-1, which is of course several years old now. I tried installing it but apparently glib-1.2.10 makes use of some gcc extensions that were deprecated in the meantime and are no longer supported at all in gcc 3.4.2. Luckily I still have an older gcc 3.3.3 lying around and that was able to get glib compiled (albeit with many warnings): cd glib-1.2.10 env CC=/path/to/old/gcc ./configure --prefix=$prefix \ make make install After all that, I was finally able to run autogen.sh successfully in mjpeg_play. I proceeded to configure, make, and make install without any overt breakage. mplex and its libraries seem to have been installed along with everything else. -Dave Dodge --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplexing DTS streams, nearly
On Thu, Jan 20, 2005 at 04:43:49AM -0800, Trent Piepho wrote: On Thu, 20 Jan 2005, Michael Hanke wrote: Am Donnerstag 20 Januar 2005 11.09 schrieb Dave Dodge: Well, yes and no. Installing updated vesions of the autotools is pretty straightforward if you're used to installing things from source. [snip] Back when I first installed Linux, we didn't even have these new-fangled package managers! Installing from source and building your own kernel was the ONLY way. You want binaries? We got your SunOS and OSF/1 and Ultrix right here, WTF is Linux? Now days I think rpm, apt, etc. are a god-send to keeping a system organized and working. I've flirted with package managers many times and even contributed some packages to GoboLinux, but on my home systems I always seem to end up going back to pure source builds after a while. Exactly what I was going to say. Once you install autohell from source, you've just broken rpm or whatever package management system you're using. Yes, I can see this being a problem if you're also using a package manager. Especially if you do something like install directly from source into the managed directories (that's just asking for trouble). Now personally when I do these from-source builds I _never_ install them into places like /bin and /lib. I keep a strict distinction between my stuff and the system's stuff. This habit probably comes from many years of building things for my own use on Solaris without any admin privileges. You'll probably have two versions installed on top of each other using each other's files in random and broken ways. And good luck upgrading your packages or using something like up2date. I tend to go to the other extreme: if I'm installing Foo, and it requires Bar and Baz, then I'll set up a dedicated install prefix for Foo and put private copies of Bar and Baz in there with it. Example: in my /opt/gimp-2.0.1 directory I have compiled for use solely by gimp: pkgconfig zlib autoconf libtool automake jpeg glib tiff libpng freetype expat render xrender fontconfig xft atk pango gtk+ libart libexif gimp-print lcms libmng libxml2 popt librsvg libwmf aalib libgtkhtml gimp gimp-help Yes, this means that they all consume tons of disk space, and that they require extra RAM (because e.g. gimp won't be able to share the same in-core instance of libgtk as any other applications). On the other hand, I can copy that /opt/gimp-2.0.1 directory to another system, or put it on CD, and know that it will pretty much just work without worrying about what versions of those packages are installed on the target system already. Note: I have a single Makefile that builds all of that, with awareness of how the packages depend on each other. So if I decide to swap in a new version of some single piece I can usually just tweak a few lines in the Makefile and start a rebuild from scratch. I'm not saying that I really _like_ doing things this way, but that's how it usually ends up for some reason. Which is why doing things like installing a fresh set of autotools, and SDL, and pkgconfig, and GTK, just to bootstrap mjpegtools probably seems a lot less extreme to me than it would to most people :-) -Dave Dodge --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Use patched mpeg2dec for hdtv?
On Wed, Jan 05, 2005 at 11:41:13PM -0800, Steven M. Schultz wrote: On Thu, 6 Jan 2005, Dave Dodge wrote: [...] DV is not used for HD (and yes, the ADVC line is SD only). I've seen several mentions of the term HDV (including at the Canopus site) which appears to be some high-definition variant of DV. But it sounds like it's still relatively new and expensive. Considering you have to agree to a disclaimer just to download the form to apply for access to the specification, details don't seem to be very free-flowing :-) so it's possible from my Powerbook to send the MPEG-TS files over the IEEE1394 bus to the ATSC receiver and that box will drive the TV. I believe a friend has also done this with his Mitsubishi TV which contains an integrated tuner and 1394 port. - a video card with drivers supporting XvMC. Some NVIDIA cards do this if you use NVIDIA's drivers. I don't know about ATI. If you want to stay with open source drivers, then I don't know if there's any solution; perhaps a _REALLY_REALLY_REALLY_ fast machine could do it. Even a ~2.8GHz IA32 system can't play back HD content reliably without XvMC. At least that's been my experience. A dual G5 can do a fairly good job of it though ;) I've tried it on an Athlon XP2400+ _with_ XvMC and I wasn't completely happy with the results, though it may have been fill rate issues in the video card since it was a relatively low-end NVIDIA FX5200. This was also about a year ago so the drivers and software may have improved. - you need to select the proper PIDs, demux the stream, and so on, to get the MPEG program that you want. With over-the-air ATSC If you're talking about demuxing, scaling, recoding HD content down to SD size you really need that FAST system :) And it won't be a real time process (not even close). I was assuming the extraction of an SD program from the transport stream. Trying to demux and decompress HD, scale it, and then compress it into DV I would expect to be infeasible on any normal home system. Even if you use the video card to accelerate the MPEG and scaling stages, you might still have issues getting the data back to the CPU fast enough to do the remainder of the work. Perhaps newer machines and cards using PCI Express will make this sort of thing practical. Very true. Some stations put up 4 or 5 ~4Mb/s SD programs. Others, such as the PBS (KCET) put 2 programs up - one ~14Mb/s HD and one 5Mb/s SD (the 2nd program is a digital version of their analog program). The local PBS station has up to five programs going at once, with the bandwidth allocation changing depending on the time of day. I'm thinking of getting the pchdtv card but after reading (on pchdtv's forums) about all the woes folks have had getting the drivers to work it sounds like a rough ride. My only experience is with the original pchdtv 2000 card, which did require at least being acquainted with kernel building and patching to get it working. Once set up, it worked fine and was easily controlled from the command line. I even managed to throw together a few quick programs of my own, based on the example code, to do the exact processing and tuning that I wanted. I don't know about the new 3000 card. I think one of the Eye500 units would be a lot simpler :-) If it weren't for that Mac only aspect of it I'd probably consider one in place of a pchdtv card, since it might move more of the custom code into userspace instead of requiring a special driver in the kernel. If the control protocol hasn't been intentionally obfuscated someone might bother to reverse-engineer it eventually. -Dave Dodge --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] y4mdenoise (in CVS) now does 2 processors!
On Tue, Jan 04, 2005 at 10:13:28PM -0800, Steven Boswell II wrote: I'm testing it on a dual-processor Athlon MP 2800+ machine. Just FYI, HP has a collection of mid-sized test systems available via the Internet, running various operating systems and CPU types. I see this includes 4-way Itanium2 and Xeon (which shows up as 8-way from userspace) systems running Linux. Various compilers including gcc and Intel's icc are provided. Access is free -- even if you're not planning on buying one yourself -- since these are partly intended for developers whose end-users might have this sort of hardware. System list and more information here: http://www.testdrive.hp.com/current.shtml You wouldn't normally have 100% of the machine to yourself (they have a more restricted testing program for that situation). If you start running long test jobs that eat 100% CPU time, they might take issue with it. But for short tests to make sure things are at least working properly and quickly, on hardware you might not otherwise have available, you might take a look. Note that they only provide unencrypted telnet and ftp for connections. No support for ssh, rsync, X11 display-back, etc. -Dave Dodge --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Use patched mpeg2dec for hdtv?
On Tue, Jan 04, 2005 at 10:36:01PM -0500, sean wrote: I'm trying to run an atsc ( over-the-air hdtv ) signal out the ieee1394 port. I have the pchdtv card which gives me the mpeg.ts stream. i have a avdc300 which will take dv input and give me component output for an ntsc panasonic hdtv. Bear in mind that some of this is just guesswork and I might be wrong... Are you intending to display high definition content? Skimming the spec of that Canopus device reveals no mention of HDV, so it's probably limited to regular standard definition DV. Also, I think MPEG-TS over IEEE1394 and DV over IEEE1394 are both special, different protocols. You probably need something more than simply redirecting the data to /dev/raw1394 to get it to work. For MPEG-TS, I think the protocol is called AV/C and is what things like D-VHS decks and set-top boxes use to communicate. If you have a TV with 1394 input, you could probably use that to pipe the data from the pchdtv card to the TV. You might have to filter the the stream to adjust the PIDs or insert null packets (I think some receiving devices are picky about the bitrate). Since this shouldn't involve any actual MPEG decompression on the PC, it would probably not be very CPU-intensive. There's: http://sourceforge.net/projects/libavc1394 which claims to support the AV/C protocol in Linux, though I don't know anything about the state of tools using that library to actually move data around. Just FYI the best-known application for processing AV/C this way is probably VirtualDVHS, which I think is only for MacOS X. Assuming you do _not_ have 1394 input on your TV, then you do have to somehow get the data into analog format first. If you want HD video, your best bet may be something like this: - a _REALLY_ fast machine. - a video card with drivers supporting XvMC. Some NVIDIA cards do this if you use NVIDIA's drivers. I don't know about ATI. If you want to stay with open source drivers, then I don't know if there's any solution; perhaps a _REALLY_REALLY_REALLY_ fast machine could do it. - mplayer, xine, or some equivalent, with XvMC support, to decode and display the MPEG-TS full-screen. If you have RGBHV (VGA) input on your TV, then just attach the TV to the computer and work out the video timings on the card until they seem to be right. If your TV does not have RGBHV, then you can try setting the video card to use ATSC timings and use an external RGBHV-to-YPrPb signal adapter. An alternative might be something like the Roku HD1000, which can in theory accept MPEG-TS over TCP/IP (using various protocols including NFS, SMB, and some streaming stuff) decode it, scale it, and output analog video. From a hardware standpoint this definitely works and the Roku has no problem chewing through even high bitrate HD content; however the software might still be very rough and might not do exactly what you need even if it exists. Roku has some forums where you might be able to find out the current state of the software: http://www.rokulabs.com/forums/ If your goal is just SD video, then your original idea might work if you can get all of the pieces in place. There are a couple of things that come to mind, though: - you need to select the proper PIDs, demux the stream, and so on, to get the MPEG program that you want. With over-the-air ATSC there's frequently more than one program in the raw transport stream; even if the broadcaster isn't sending out HD they might have a second SD program with a weather map or some such thing. - you will need to decompress the MPEG stream and then (I assume) recompress into DV. This may require a pretty fast machine. I don't know what tools are available to do this on Linux. Something like ffmpeg might be able to accomplish it with the right command-line arguments. - you need to get the DV out on the wire in a format that your Canopus device understands. I'm guessing that it uses the same protocol as a DV camera. Most of the software I found in a quick search is more concerned with getting DV _in_ to the computer than sending it _out_. The Kino sourcecode seems to mention a video1394Writer class which probably does the correct protocol, but I don't know if there's any tool included that actually uses it: http://kino.schirmacher.de/ Anyway, that's just some random thoughts on the subject. I've worked a bit with a pchdtv card, and tried some of the above techniques myself with mixed results, but have never done anything with DV. -Dave Dodge --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Mjpeg-users mailing list Mjpeg
[Mjpeg-users] generating HDTV
I want to _generate_ HD output; ideally an ATSC-compliant TS but a 720p30 video ES would be a good start. I have my animation/rendering program configured to produce 1280x720 PPM frames at 30 frames per second. Here's what I currently use, based on some wild guesses. Does anyone see any glaring problems with these settings? I've kept all of the source frames in case I need to re-encode them. cat *.ppm \ | ppmtoy4m -n 150 -F 30:1 -A 1:1 -I p -S 420_mpeg2 \ | mpeg2enc \ --no-constraints \ --format 3 \ --b-per-refframe 0 \ --video-bitrate 19000 \ --video-buffer 500 \ --no-dummy-svcd-SOF \ --min-gop-size 15 \ --max-gop-size 15 \ --closed-gop \ --keep-hf \ --intra_dc_prec 11 \ --output outputfile.mpg With the above settings I found that mjpegtools-1.6.2 initially complained about the bitrate and/or dc precision being out of range. Is there any way to select the high level and high profile settings on the command line? I couldn't find any and ended up patching the defaults in the code in order to fix it: profile = 1; level = 4; I suspect the bitrate might be too high if I want to stay within the bounds of broadcast ATSC, since packetization will add overhead. But the data will probably be delivered over Ethernet from a file server instead of actually sent over the air, so I'm not too concerned about it. There's not intended to be any audio associated with the video, so I don't think I need to leave any room for it. FYI the intended application is a screensaver-like program for an HDTV set-top box. The files as generated above do play with things like mplayer, but I haven't had a chance to get them turned into transport streams and try them with the intended hardware (the API there insists on a TS). There seem to be several free programs to tear transport streams apart but very few for constructing them. -Dave Dodge --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] generating HDTV
On Thu, Dec 23, 2004 at 02:59:30PM -0800, Steven M. Schultz wrote: On Thu, 23 Dec 2004, Dave Dodge wrote: [...] 30fps is a valid ATSC rate (as is 3/1001) Yeah, I at least checked on that before proceeding. I agree that I don't think I've ever seen 30fps content in the wild but since it's allowed I'm hoping the decoder will take it. What you're going to run into when trying to work with HD output is that 'mpeg2enc' is a [EMAIL PROTECTED] (Main Profile @ Main Level) encoder and not a HL (High Level) encoder. Right, that's basically what caused the problems initially, since those settings were hardcoded. I noticed that the tables in the sourcecode had entries for the other profiles/levels and it _seems_ to work if I just change the hardcoded settings to point to them; but I don't know enough to be sure if it's really generating correct output. The software decoders I've been testing with are probably more lenient than the hardware decoder I'm intending this for. Upgrade to the cvs version if you're going to try and do anything with HD content. Thanks, I'll give that a shot. Most of the HD stations I watch are the [EMAIL PROTECTED]/1001 format. Same here, and the decoder I'm using has no problem handling it. I did try a couple of test frames at that resolution but for the rendering software I'm using (electricsheep.org), higher resolution means huge amounts of additional RAM and a lot more time -- and 1280x720 is already pretty much at the limit for my rendering machine. To continue on... ;) The stations broadcast a SD and an HD program at the same time I think the local CBS broadcaster is strictly HD, but course they might change that if/when they lose their analog station. On the other hand, the local PBS station has five programs with multiple audio PIDs per program and they change the bandwidth allocation depending on the time of day. Some old test data here: http://www.dododge.net/roku/ts-samples.html 19Mb/s should be ok but you might want to back down just a little to leave room for the overhead. The VBV size I've seen used is 488 (which is close to the 500 you've specified) The buffers are probably my main concern. It's known from test cases that this decoder can handle bitrates up into the 30Mb/sec range, provided you can get the data into it at that speed. But I don't want it to have to drop frames or lose sync while decoding because some internal buffer overflows. Silent movie era in High Definition :) Pretty much. I believe the hardware can play a separate stream (such as an MP3 file) as background music to whatever TS you give it, so I don't need to provide my own audio within the TS. Of course a problem with that is that some muxers might require an audio ES in order to work at all. To generate the TS stream you may want to give ProjectX a try I have that one on my TODO list as the most likely candidate to work. I've made some brief attempts with other muxers without success. -Dave Dodge --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mplex files 2GB
yves, on 11/12/04 13:03 you wrote: I'm unable to use mplex with files greater than 2GB without splitting Just a guess: Files over 2GB would probably require the program to be compiled with large file support, so that it uses the 64-bit file API. I think configure is supposed to enable this automatically; check that the config.h it generates has _FILE_OFFSET_BITS set to 64. If large files are enabled and it's still not working, then somewhere in the code there may be a 32-bit signed integer being used to handle file accesses. Such a value would overflow at 2GB. -Dave Dodge --- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
