Re: [Mjpeg-users] Mplex not supporting mp2 audio?
Le 29 janv. 08 à 22:17, Sujeet Akula a écrit : > Hello, > > I recently tried muxing m1v and mp2 video and audio files, > respectively > into VCD-compatible format with mplex, using the following command: > > mplex -f 1 -o talkie.mpg video.m1v audio.mp2 > > It apparently did not complain about the video file, but did complain > about the audio.mp2: > > INFO: [mplex] mplex version 1.8.0 (2.2.4 $Date: 2005/08/28 > 17:50:54 $) > INFO: [mplex] File video.m1v looks like an MPEG Video stream. > **ERROR: [mplex] File audio.mp2 unrecogniseable! > **ERROR: [mplex] Unrecogniseable file(s)... exiting. > > Furthermore, the audio.mp2 and video.m1v files were created using > ffmpeg > and mplayer: > > ffmpeg -i movie.avi -vn -ab 224k -ar 44100 -ac 2 -acodec mp2 -y > audio.mp2 [...] which version of ffmpeg, a recent one? try "file audio.mp2" what's the result? mp3? if mplex is not able to recognize your file it's because the mp2 has a bad tag (and if the file is tagged as mp3, so use a more recent ffmpeg version) bye Hervé - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] frame rate conversion
Le 23 mai 08 à 20:06, Roman Shaposhnik a écrit : > On Fri, 2008-05-23 at 05:15 +0200, Bernhard Praschinger wrote: >> Hallo >> >> Florin Andrei wrote: >>> I'm looking for a way to convert a 60fps video stream to true NTSC >>> frame >>> rate (29.97i). Converting frames to fields to half the frame rate >>> and >>> interlace is easy, but it's the shaving off of the 0.1% of the frame >>> rate that worries me. >>> >>> How about yuvmotionfps? Is it good enough to make a smooth >>> conversion 60 >>> --> 59.94? (PS: you must specify 6:1001 and not 60) bad idea to use yuvmotionfps for this purpose: yuvmotionfps will generate new frames (and keep somes depending on the "frame approximation threshold" you specified) 60 is too much near of 59,94: the tool will re-calculate all the frames (and the new frames will introduce "blur and ghost") >>> Other suggestions? >> The other conversation tool it yuvfps which just droppes or inserts >> frames. Might also work her well because you have only to drop one >> frame >> every 1001 frames. >> Take a look at the note that note on the yuvmotionfps homepage: >> Should I >> use it to do Film (24fps) to PAL (25fps) conversion ? >> >> The obvious thing is that yuvfps will be faster. >> If the encoding does not take too long just try both versions. And >> see >> which version generate the better output. like Bernhard, my advice is to just use yuvfps to drop one frame every 1001 frames (it will preserve contents of frames, no need to re- calculate them) Or keep frames, but modify the lenght of your audio stream to fit with the new duration of frames > On a related note: is there any other motion-estimation based frame > rate conversion implementation available as open source? Or is > yuvmotionfps the only game in town? I think it's the only one but it's still buggy and its author does not answer since... some years: - it does not know to convert framerate > 50fps to less (give it a 60p, and ask it 50p -> resulting frames is 60p) - arg -p (search path radius) is buggy: specify 8 and you'll have 8*2=16 - it crashes on macos 10.5 (no way to use it on this platform) but it's a great tool ;) bye Hervé - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] y4mstabilizer segmentation fault
hello, just some infos/corrections (no solution) Le 3 juin 09 à 06:10, Steven M. Schultz a écrit : > On Wed, 3 Jun 2009, Richard Archer wrote: > >> Here's the setup and the results: >> >> $ ffmpeg -deinterlace -i "test.m2v" -r 25.000 -s 720x576 >> -aspect 4:3 -f yuv4mpegpipe -aspect 4:3 -pix_fmt yuv444p - | >> y4mstabilizer -v -v >/dev/null [...] > The PROBLEM the use of "-pix_fmt yuv444p". -pix_fmt does not scale > or resample the > data!! -pix_fmt simply tells ffmpeg what value to put into the > yuv4mpeg header. > Maybe ffmpeg can do the chroma resampling but I'm fairly sure that - > pix_fmt is not > the way to do it. this is the good arg for ffmpeg to convert planes ;-) it converts / resample data (like y4mscaler) and no only headers (like yuvcorrect) >> Seems stream 0 codec frame rate differs from container frame rate: >> 50.00 (50/1) -> 25.00 (25/1) > ffmpeg is saying your input is 50 frames/sec? Hmmm, interesting. not really, it just says that: pts computed from wrapper can only fit in a timeBase 50 (aka 50 fields, aka interlaced broadcast) but contents is 25fps (ffmpeg output is not so clear ;-)) >> INFO: [y4mstabilizer] frame rate: 25/1 fps (~25.00) >> INFO: [y4mstabilizer]interlace: top-field-first >> INFO: [y4mstabilizer] sample aspect ratio: 16:15 one tip to Richard: if your contents is interlaced, deinterlace (from ffmpeg or another mjpeg tool) if your contents is progressive (and only the wrapper is interlaced), correct headers with yuvcorrect …your stream is still written as interlaced when it reaches y4mstabilizer I had some crashes too with y4mstabilizer (official 190 and previous RC), a file crashed after 7 minutes (was only for tests purposes, but it's a great tool, with a great result :-)) I'm on MacOsX If somebody is interested, I can try to reproduce it (was "old", I must try to remember "how to" :-D) and send crash log bye Hervé -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] y4mstabilizer segmentation fault
f4 ss: 0x001f efl: 0x00010202 eip: 0x17c7 cs: 0x0017 ds: 0x001f es: 0x001f fs: 0x gs: 0x0037 cr2: 0x000fd000 Binary Images: 0x1000 - 0x8fff +y4mstabilizer ??? (???) /Users/herve/_Tools/ _CVS/_MjpegTools/mjpegtools/mjpegtools-1.9.0release_BIN/ intel_Tiger-2009:02:20-25/y4mstabilizer 0x8fe0 - 0x8fe2db43 dyld 97.1 (???) /usr/lib/dyld 0x92032000 - 0x92199ff3 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib 0x9278e000 - 0x92792fff libmathCommon.A.dylib ??? (???) /usr/lib/ system/libmathCommon.A.dylib 0x - 0x1780 libSystem.B.dylib ??? (???) /usr/lib/ libSystem.B.dylib bye PS: result is great, congratulations to its developper :-) Le 3 juin 09 à 03:17, Richard Archer a écrit : > INFO: [y4mstabilizer] global motion xy*2=<0,1> Accumulated > xy=<0,0.5> shift xy=0,-1> > > INFO: [y4mstabilizer] Frame 2 > INFO: [y4mstabilizer] global motion xy*2=<0,0> Accumulated > xy=<0,0.475> shift xy=0,0> > > INFO: [y4mstabilizer] Frame 3 > INFO: [y4mstabilizer] global motion xy*2=<1,-2> Accumulated > xy=<0.5,-0.54875> shift xy=-1,1> > > INFO: [y4mstabilizer] Frame 4 > Segmentation fault (core dumped) > > $ ls > core.6857 > test.m2v > test.ac3 > > $ gdb > GNU gdb Red Hat Linux (6.5-37.el5rh) > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "x86_64-redhat-linux-gnu". > (gdb) file /usr/bin/y4mstabilizer > Reading symbols from /usr/bin/y4mstabilizer...Reading symbols from / > usr/lib/debug/usr/bin/y4mstabilizer.debug...(no debugging symbols > found)...done. > Using host libthread_db library "/lib64/libthread_db.so.1". > (no debugging symbols found)...done. > (gdb) core core.6857 > Reading symbols from /usr/lib64/libmjpegutils-1.9.so.0...Reading > symbols from /usr/lib/debug/usr/lib64/libmjpegutils-1.9.so. > 0.0.0.debug...(no debugging symbols found)...done. > (no debugging symbols found)...done. > Loaded symbols for /usr/lib64/libmjpegutils-1.9.so.0 > Reading symbols from /lib64/libm.so.6...(no debugging symbols > found)...done. > Loaded symbols for /lib64/libm.so.6 > Reading symbols from /lib64/libpthread.so.0...(no debugging symbols > found)...done. > Loaded symbols for /lib64/libpthread.so.0 > Reading symbols from /lib64/libc.so.6... > (no debugging symbols found)...done. > Loaded symbols for /lib64/libc.so.6 > Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging > symbols found)...done. > Loaded symbols for /lib64/ld-linux-x86-64.so.2 > Core was generated by `y4mstabilizer -v -v'. > Program terminated with signal 11, Segmentation fault. > #0 0x004027a4 in calc_SAD_noaccel () > (gdb) bt > #0 0x004027a4 in calc_SAD_noaccel () > #1 0x00402602 in motion () > #2 0x00402378 in gmotion () > #3 0x00401935 in main () > #4 0x00345281d8b4 in __libc_start_main () from /lib64/libc.so.6 > #5 0x00401139 in _start () > (gdb) > > > And there ends my ability to debug this problem :( > > I'm happy to follow instructions to help isolate the bug and > to apply patches and rebuild to test a solution. > > Thank you! > > ...Richard. > > -- > OpenSolaris 2009.06 is a cutting edge operating system for enterprises > looking to deploy the next generation of Solaris that includes the > latest > innovations from Sun and the OpenSource community. Download a copy and > enjoy capabilities such as Networking, Storage and Virtualization. > Go to: http://p.sf.net/sfu/opensolaris-get > ___ > Mjpeg-users mailing list > Mjpeg-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mjpeg-users > Hervé øº°`°ºø,¸¸,øº°`°ºø,¸¸,øº°`°ºø,¸¸,øº°`°ºø,¸¸,øº°`°ºø ALLEZ FAIRE UN TOUR SUR http://herve.flores.online.fr http://movieconverter.online.fr Hervé & Virginie Flores Illustrateurs-graphistes 27, avenue Germaine - 06800 - Cagnes-sur-Mer tel ou fax : 04 92 02 89 36 e-mail : herve.flo...@free.fr øº°`°ºø,¸¸,øº°`°ºø,¸¸,øº°`°ºø,¸¸,øº°`°ºø,¸¸,øº°`°ºø -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] y4mdenoise (was Re: build failure on MacOS 10.5.7)
Le 4 juin 09 à 21:26, Steven Boswell II a écrit : > Whoops! That was an integration error. I just checked in the fix. > Sorry about that! > > For those of you that aren't subscribed to the mjpeg-developer list, > I've been doing heavy development of y4mdenoise lately, I've finally > found a practical implementation of my original idea, and it's > faster than it's ever been. For those of you keeping up with latest > CVS, check it out! could give some tips? I downloaded cvs, I made cd … ./autogen.sh -> configure.ac:276: warning: macro `AM_PATH_SDL' not found in library configure.ac:276: warning: macro `AM_PATH_SDL' not found in library configure.ac:96: error: possibly undefined macro: AC_DEFINE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:276: error: possibly undefined macro: AM_PATH_SDL autoreconf: /usr/bin/autoconf failed with exit status: 1 so, I download and install SDL-1.2.13 (I thought that my current version was maybe too old?!) but I have the same error do you have a "how to" compile from cvs? thanks :-) Hervé -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Top-forward for DV?
Le 25 juin 09 à 12:50, Steven M. Schultz a écrit : >> Rats...my memory of the conversation was that TOP_FORWARD was >> necessary to correct DV of telecined video. > > And for a long time that was the prevailing method - but I ran into > problems back (3 or 4 years). > >> (I searched the >> mailing list archives, by asking Google for "TOP_FORWARD >> site:mail-archive.com", but couldn't find why TOP_FORWARD was >> harmful.) > > I took a quick look and saw bits/pieces of the threads but not parts > I was looking for. Try searching for yuvkineco and yuvcorrect > > I've got to get out the door and don't have time to do much more than > clear out the mailbox. > >> As an experiment, I tried running yuvkineco on video without >> doing TOP_FORWARD, and it was visibly worse.=A0 Maybe that's >> because yuvkineco is top-field-first only?=A0 It didn't seem to >> complain about being given bottom-field-first video. > > Hmmm, I thought yuvkineco would complain about the wrong field order > > >> The reverse-telecined videos I make with yuvkineco TOP_FORWARD >> look great to me...and I thought I was nitpicky about these >> things.=A0 :-) Have I been living a lie?=A0 What should I be doing? > > SHift the video one line up or down within the frame. This is MUCH > better (I think) than shifting the video 1/2 frame. Here's what I > wrote up about 3 years ago: > > #!/bin/sh > > N=rites > > # NOTE: lie and say it's a progressive stream instead of bottom > first. This > # hushes y4mscaler and we will tag the stream as top first > anyhow after > # shifting down 1 line. > # > # Take the first 479 lines of a frame and place them in the last 479 > lines > # of the output frame. This places 1 black line at the top and > converts the > # stream from bottom to top field first: > # y4mscaler -v 0 -I active=704x479+8+0 -O sar=src -O size=704x480 - > O align=BC > # > # OR > # > # If 720x486 input we can skip one top line and take the next 480 > lines: > #y4mscaler -v 0 -I active=704x480+8+1 -O sar=src -O size=704x480 my 2 cents: if I well remember (I didn't verify with the lastest version), TOP_FORWARD only shift luma (chroma was let in state) Same sort of concern here with y4mscaler if your file is 4:2:0 (or 4:1:1), the resulting chroma will be buggy with an odd crop Maybe the idea will be to convert it first to 4:4:4 before any process... (or y4mscaler still have automatisms to handle it?) bye (PS (not related to this thread): thanks to Bernhard Praschinger & Christian Ebert for their tips to compile y4mdenoise from SVN. But I didn't manage. I will wait for an official release to test it) Hervé -- ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] latest change to cpuinfo.sh breaks build on MacOS 10.5.8
Le 2 sept. 09 à 20:19, Bernhard Praschinger a écrit : > Hallo > >> * Steven M. Schultz on Monday, August 31, 2009 at 15:03:33 -0700 >>> On Mon, 31 Aug 2009, Christian Ebert wrote: >>>> $ sw_vers >>>> ProductName: Mac OS X >>>> ProductVersion:10.5.8 >>> Got your 10.6 on order ? :-) I received mine today (10.6) if you want I could make some tries this WE... bye Hervé -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] error
Le 29 janv. 10 à 18:08, steve kaufman a écrit : > Hi, > I cannot download this > > http://mjpeg.sourceforge.net/MacOS/mpeg2enc.intel Do not click on the link but drag this link to the download window of your web client (Safari or Firefox) bye Hervé -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] workaround (PPC) for mpeg2enc's buggyness
Le 16 janv. 08 à 04:40, Steven M. Schultz a écrit : > > On Wed, 16 Jan 2008, Christian Ebert wrote: [...] mjpeg tools too can do the trick ;-) decode DV with ffmpeg | yuvdenoise ... | mpeg2enc or (bad soluce) decode DV with movtoy4m (lose of one field, gamma garbage due QuickTime.framework) | yuvdenoise ... | yuvcorrect for gamma correction | mpeg2enc BitVice is not the only soluce Steven ;-))) PS: for audio "twos" = wav (or aif, I don't remeber if twos is aif and swot is wav or vice-versa) use directly QuickTime Player / mpegstreamclip / FCE / or movtowav to extract audio from DV and encode it to ac3 with ffmpeg, thus mux with mplex. bye Hervé - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] workaround (PPC) for mpeg2enc's buggyness
Le 16 janv. 08 à 14:11, Burkhard Plaum a écrit : > Hi, > > Hervé Flores schrieb: >> Le 16 janv. 08 à 04:40, Steven M. Schultz a écrit : >> >>> On Wed, 16 Jan 2008, Christian Ebert wrote: >> >> >> [...] >> mjpeg tools too can do the trick ;-) >> >> decode DV with ffmpeg | yuvdenoise ... | mpeg2enc >> or (bad soluce) >> decode DV with movtoy4m (lose of one field, gamma garbage due >> QuickTime.framework) | yuvdenoise ... | yuvcorrect for gamma >> correction | mpeg2enc > > Why loose one field? movtoy4m does not decode interlaced streams (only half of the stream = one field, or blend the 2 fields with some parameter) due the great apple's quickTime automatisms. To preserve CPU cunsumption, Apple (=QuickTime) has 3 levels of displays: quarter, half and full image(you can see them selecting the video track in QuickTime player and plays with). The API and documentation fom apple to display interlaced files is buggy, Johan code is OK (theoricaly) but it only manages to blend the 2 fields (complain to Apple ;-)) > Why gamma garbage? QT player displays a darker image than input file (and all quicktime calls from QuickTime.framework do the same) > movtoy4m uses exactly the same code (libavcodec) for DV decoding > as ffmpeg, so the output should be identical. If it's not, there > is something wrong. no, movtoy4m is a tool from Johan Lindstrom, based on QuickTime API for Mac by Apple (different from libavcodec) It has the same defaults as QuickTime Player (displays chroma as progressive instead of interlaced with DV, etc), but it's a very cool tool. (this thread begins to be a Mac-only thread ;-)) sorry for my great level of english... bye Hervé - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] workaround (PPC) for mpeg2enc's buggyness
Le 22 janv. 08 à 22:53, Mark Heath a écrit : > > > On 23/01/2008, at 5:16 AM, Florin Andrei wrote: > >> Mark Heath wrote: >>> >>> Anyway I've been using the mpeg2 encoder in ffmpeg and have been >>> happy with the results. >> >> I asked recently on their mailing list if they solved the rate >> control >> issues and they said no. >> >> Kind of a big issue if the target media is DVD. > > > I use a max rate of 8500 (rather than the DVD specified limit of > 9800) and never had problems during muxing or had the files rejected > by authoring software. Perhaps somebody can explain to me the meaning of mplex verbose, I have sometimes "freezes" on my dvd player (and I suspect too high bitrate) the mpeg2 reports no problem during muxing (with some muxers, dvd authoring softs, etc) but mplex says something like that: mplex -f 8 input.m2v ... -o output.mpg [...] Peak bit-rat: 11814400 This peak is > 10 080 000 kb/s (the maximum "size" of video for DVD) it's just a warning and not an error. I took a look the stream and my other tools/softs didn't detect an "overflow" (resulting stream seems to be ≤ 10 080 000). Somebody understand this warning? mplex is right or does it means anything else? (aka the result is compliant with dvd-specf or not?) ...rate control is always a problem (bigger in ffmpeg but present in mpeg2enc too) bye Hervé - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
