Re: [Mjpeg-users] Mpeg2enc quality?
Now, the result generated by mpeg2enc has a few quality issues when compared to the result obtained with a commercial DVD authoring packet, but I really would like to switch to mpeg2enc and dvdauthor instead of that commercial program. The following two links demonstrate the issue: http://www.nuonsoft.com/temp/flower_mpeg2enc.jpg http://www.nuonsoft.com/temp/flower2.jpg (The above are captures of the resulting M2V file. These captures were saved as jpg with the lowest possible compression rate to prevent jpeg artifacts.) The first link is the result generated with mpeg2enc with the above command line. The second link is the result with the commercial encoder. You clearly see a lot more noise around the flower in the center. Also the green leaves on the left and bottom of the picture aren't as crips with mpeg2enc as with the commercial encoder. They are a bit more blocky with mpeg2enc. In some of my slides there is an even greater difference between the two encoders. I have tried many many many encoders and even on Your screenshots I can see better colors in picture created by mpeg2enc. It is really the best encoder nowadays. It is my opinion. I haven't seen as pretty good quality as eith mpeg2enc. --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 24 Aug 2004 04:16, Selva Nair wrote: Hi Anne, Hi, Selva At last I managed to reproduce your stuttering audio on another machine with the latest xine (xine-lib-1-rc5, xine-ui-0.99.2). The older version of xine plays it fine, though. Interesting. After some experimentation this is what I have concluded. The audio stutters when the average bitrate is much below the dvd rate (see below) but is mplexed at the dvd rate (with -f 8). This could be something peculiar about this version of xine, may be not. xine-0.9.20, mplayer and vlc play the clip fine. I suggest you to do a few more tests before burning to a dvd. Although you made this video with -b 4500, the average rate is kess than 2000 kbps, possibly because this is made from still images. So remake it with -f 8 and low value of quantization, say -q 4 or even lower. The idea is to get a decent bitrate of 5000 kbps or so which amounts to a total size of 70 MB for your 116 second stream instead of the current 24 MB or so. If you have to lower the q value to get to that size, do it. Lower the q better is your quality as long as the average rate does not not get too close to the peak rate (a 20% room is recommended). Although for normal full size video such low values of q are not recommended, in this special case of still images you can go pretty low. By the way, the default peak bitrate for mpeg2enc -f 8 is 7500kbps; aim for an average of 5000 or so - it may be hard to get more than that with stills. You can make a quick estimate of the average bitrate from the file size as average video bit rate = m2v size in bytes * 8 / duration in seconds Multiplex as dvd and test it with xine again. $ lav2yuv coda.eli | mpeg2enc -f 8 -q 4 -4 2 -2 1 -o coda.m2v (add scaler if the source is not 720x576) $ lav2wav coda.eli | mp2enc -r 48000 -o coda.mp2 $ mplex -f 8 coda.mp2 coda.m2v -o coda.mpg Let's see how this goes. I've left the whole quoted, because it will be useful in the archives, I think. This is definitely the right track. Encoding at -q 4 brought fewer stutters, -q 3 didn't seem much better - the file size was not much bigger, and there were still quite a few stutters. At -q the file size shot up to around 56 MB, and the only stutters were one at the beginning, where there was a fault in the input file, so unavoidable, and in the last 2-3 seconds. Although it's not perfect I could live with that. disk performance is usually a non-issue for dvd rate mpeg2 playback. OK - fine. Tutorial time again, though ;-) First, what do these parameters mean (it's not obvious from the man page)? - -4 2 -2 1 Then, the problems I've had appear to be caused by the way I have created the avi. This was done by grabbing a series of single frames, creating 25fps avis from them, creating transition avis, then writing an eli that could bring them together into one. Is there any way I could have lessened the chances of the problems I've had? Could they, for instance, be made interlaced in some way? And would it have helped? Or is it maybe that I didn't get a good quality sound grab in the first place? If so, again, recommendations would help. Finally, the main recording is in the form of a series of avis (filename02%.avi), interlaced. The coda is formed from a series of non-interlaced avis. I know I can't create a transition between the, but will I encounter problems when I try to stitch them together into one long production? I guess it's time to start reading up on dvdAuthor, too. Anne - -- Registered Linux User No.293302 Have you visited http://twiki.mdklinuxfaq.org yet? -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBK0HZkFAvMr/nNX8RAqpAAJ9+x36yKKetLdVhmAfXwlvNWP/9SgCfYg80 Tq7KSxsHhPBioNVCzmCRFxU= =SCUg -END PGP SIGNATURE- --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 23 Aug 2004 21:56, Selva Nair wrote: [*] The last time I used yuvscaler it did not support -O DVD, It seems to work OK now - I used it to change 768 to 720 but I haven't touched it after y4mscaler appeared. Make sure I don't have y4mscaler. In fact I've seen mention of several tools that I don't appear to have. Are they from cvs? Anne - -- Registered Linux User No.293302 Have you visited http://twiki.mdklinuxfaq.org yet? -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBK0iCkFAvMr/nNX8RAv/xAKCS19ip0BvBk/PQVjIchISOew7kRACfcrmP dZOM85ikOEEEf1qPlUu6tcM= =7IuG -END PGP SIGNATURE- --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 23 Aug 2004 21:31, Selva Nair wrote: Have you tried playing any dvd-rate mpeg2 file from disk? You can copy, say, a short chapter from a dvd and try. If you have ogle, mplayer or vlc, try those too. I tried that, and it played fine in xine, so you were right. It's not a disk access timing problem. Or author it on a dvd-rw and see whether your standalone dvd-player can play it! Be sure to author it using, say, dvdauthor, not simply copy the mpg to the disk. Instead of going down this road I followed your other suggestions, which revealed quite a bit about the problem, I think. Now I'm going to read up on dvdauthor. Anne - -- Registered Linux User No.293302 Have you visited http://twiki.mdklinuxfaq.org yet? -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBK1ExkFAvMr/nNX8RAg0QAJ93ixC/m+GmTDH9+n4P+Pv5AWLx/wCgjOMK NgaTfCWefNTRHoIbBKWstgI= =n98a -END PGP SIGNATURE- --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
On Tue, 24 Aug 2004, Anne Wilson wrote: I don't have y4mscaler. In fact I've seen mention of several tools that I don't appear to have. Are they from cvs? The other tools you've seen mentioned are indeed from the cvs version of mjpegtools. y4mscaler is not, at this time, integrated into mjpegtools. Get y4mscaler from: http://www.mir.com/DMG/ For mjpegtools-1.6.x you want y4mscaler-0.6.2, for the cvs version of mjpegtools you need y4mscaler-0.7.1. Just do a make and then cp/mv the y4mscaler executable into a directory in $PATH Cheers, Steven Schultz --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
On Tue, 24 Aug 2004, Anne Wilson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 24 Aug 2004 04:16, Selva Nair wrote: Hi Anne, Hi, Selva At last I managed to reproduce your stuttering audio on another machine with the latest xine (xine-lib-1-rc5, xine-ui-0.99.2). The older version of xine plays it fine, though. Interesting. After some experimentation this is what I have concluded. The audio stutters when the average bitrate is much below the dvd rate (see below) but is mplexed at the dvd rate (with -f 8). This could be something peculiar about this version of xine, may be not. xine-0.9.20, mplayer and vlc play the clip fine. I do not understand why multiplex rate should affect playback, that's why I left it for your experimentaion instead of spamming the list with my half-baked conclusions ;) By the way, later ( 1.6.1 release?) versions of mplex can be forced to use a lower bitrate than the default of 10.08Mbps with -f 8. That may be another way to multiplex low bit-rate streams. I really do not know whether its important to keep the mplex rate not too much higher than the actual video+audio rate. Also is there a practical lower limit for dvd bitrate? I've left the whole quoted, because it will be useful in the archives, I think. This is definitely the right track. Encoding at -q 4 brought fewer stutters, -q 3 didn't seem much better - the file size was not much bigger, and there were still quite a few stutters. At -q the file size shot up to around 56 MB, and the only stutters were one at the beginning, where there was a fault in the input file, so unavoidable, and in the last 2-3 seconds. Although it's not perfect I could live with that. Even if the issue was with the mplex rate, that much fine tuning should not be required. I never had any audio problem with mpeg2enc/mplex although I haven't used used extreme values of bit rates. Possibly something is wrong with xine too: if you run xine with --verbose you may get some messages on audio drifts, if any. Selva --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
On Tue, 24 Aug 2004, Selva Nair wrote: I do not understand why multiplex rate should affect playback, that's why I left it for your experimentaion instead of spamming the list with my half-baked conclusions ;) It doesn't - at least I've never had it. Lowering the bitrate of the video will produce something that will make your eyes hurt but won't cause audio stuttering. By the way, later ( 1.6.1 release?) versions of mplex can be forced to use a lower bitrate than the default of 10.08Mbps with -f 8. That may be another way to multiplex low bit-rate streams. I really do not know whether its important to keep the mplex rate not too much higher than the actual video+audio rate. Doesn't make any difference. All you need to be is over the point at which mplex gives underrun errors. 1 bit/sec over is all that's needed ;) As long as the final total bitrate's less than 10.08 (and this includes any peaks/spikes - not just the Average!) you could put anything in the MPEG header. I've seen DVDs flagged as 9800kbit/sec for the video but on closer examination were closer to 6500 - the multiplexing just stuffed in the largest permitted DVD value. Also is there a practical lower limit for dvd bitrate? That's between you and your eyeballs ;) Much depends on the source and the amount of filtering done of course. Since DVDs are allowed to use the 352x480 (or 352x576) resolution you can give up some spatial resolution but then use a higher bitrate to avoid blockiness. For fullframe size with good material clean material and a modest amount of filtering you can get by with ~5000 kbits/s at a reasonable quality. At the 1/2 D1 resolution a bitreate closer to 4000 or less will produce quite a long playing time at a very acceptable quality. Even if the issue was with the mplex rate, that much fine tuning should not be required. I never had any audio problem with mpeg2enc/mplex Nor have I. I have had audio playback issues with mplayer due to broken/miscompiled audio decoders but that wasn't mplex/mp2enc/mpeg2enc related. although I haven't used used extreme values of bit rates. Possibly something is wrong with xine too: if you run xine with --verbose you may get some messages on audio drifts, if any. That's a good idea. If xine is having to stop/start the audio in an attempt to maintain a/v sync that would could cause the audio problems. Cheers, Steven Schultz --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
Hi, Tutorial time again, though ;-) First, what do these parameters mean (it's not obvious from the man page)? - -4 2 -2 1 I dont know much about mpeg2 encoding to comment on that; I can only say that -4 and -2 takes an argument in the range 1 to 4, smaller numbers lead to a more thorough motion estimation search which means better quality at the expense of speed. From my own experience and from what I have learned from this list -4 2 -2 1 runs much faster than -4 1 -2 1 and still produces almost as good an output as the latter. Hopefully you will get more expert explanations from others. Then, the problems I've had appear to be caused by the way I have created the avi. This was done by grabbing a series of single frames, creating 25fps avis from them, creating transition avis, then writing an eli that could bring them together into one. Is there any way I could have lessened the chances of the problems I've had? Could they, for instance, be made interlaced in some way? And would it have helped? Not that it would have helped, but in general its not a good idea to de-interlace unless absolutely necessary. Was there any special reason to deinterlace the input? I would have kept it all interlaced if the source is interlaced. You lose quality when you de-interlace. Or is it maybe that I didn't get a good quality sound grab in the first place? I am not sure I understand. You mean audio quality? If so, again, recommendations would help. Finally, the main recording is in the form of a series of avis (filename02%.avi), interlaced. The coda is formed from a series of non-interlaced avis. I know I can't create a transition between the, but will I encounter problems when I try to stitch them together into one long production? lav2yuv will complain if you try to mix interlaced and progressive sources. One can think of some ways of handling this without re-encoding but it may be easier to re-encode coda as interlaced with the same field order, frame size, aspect ratio and fps as the rest of the video. Selva --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 24 Aug 2004 19:56, Selva Nair wrote: Then, the problems I've had appear to be caused by the way I have created the avi. This was done by grabbing a series of single frames, creating 25fps avis from them, creating transition avis, then writing an eli that could bring them together into one. Is there any way I could have lessened the chances of the problems I've had? Could they, for instance, be made interlaced in some way? And would it have helped? Not that it would have helped, but in general its not a good idea to de-interlace unless absolutely necessary. Was there any special reason to deinterlace the input? I would have kept it all interlaced if the source is interlaced. You lose quality when you de-interlace. It isn't that I de-interlaced. I wanted a series of 5-second-ish stills pulled from the main video - a sort of summary to pull things together instead of the abrupt ending. I started each of these from a single frame pulled from the main recording. Since this project is very much a learning experience I'm quite prepared to do the whole lot again. Would that be a matter of adding -I t -L 1 to jpeg2yuv? Or is it maybe that I didn't get a good quality sound grab in the first place? I am not sure I understand. You mean audio quality? Yes - I was wondering whether I could have got a faster sampling rate or something, to make it less of a gap. If so, again, recommendations would help. Finally, the main recording is in the form of a series of avis (filename02%.avi), interlaced. The coda is formed from a series of non-interlaced avis. I know I can't create a transition between the, but will I encounter problems when I try to stitch them together into one long production? If I re-create all the avis in an interlaced mode, will the blends automatically be interlaced? lav2yuv will complain if you try to mix interlaced and progressive sources. One can think of some ways of handling this without re-encoding but it may be easier to re-encode coda as interlaced with the same field order, frame size, aspect ratio and fps as the rest of the video. Now there's another question. The main avis are in 768x576, whereas I want 720x576. I was expecting to use yuvscaler just prior to encoding. Of course I had used yuvscaler on the coda, so that I could check that it was working. I guess that it would be better to take it on trust and then convert them all at the same time when encoding? Sorry for so many questions, but I am trying to get the concepts clear. And thanks to both you and Steven for clarifying so many things. Anne - -- Registered Linux User No.293302 Have you visited http://twiki.mdklinuxfaq.org yet? -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBK5UVkFAvMr/nNX8RApfWAJ4mJ6XWtv3hKL5P2PNvk93wapJrFACeLXM8 /sL7SAu995IETR/xOauYxK4= =S70G -END PGP SIGNATURE- --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
On Tue, 24 Aug 2004, Anne Wilson wrote: OK - I prepared a coda_q4.mpg and launched xine from a console. I saw exactly what you have both been suggesting: xine: found demuxer plugin: MPEG program stream demux plugin av_offset=0 pts spu_offset=0 pts fixing sound card drift by -1453 pts video_out: throwing away image with pts 2962135 because it's too old (diff : 3703). 200 frames delivered, 0 frames skipped, 1 frames discarded fixing sound card drift by 3365 pts fixing sound card drift by 2534 pts fixing sound card drift by 1899 pts fixing sound card drift by 1423 pts #lots more of these Occasional drifts are okay, but this is far too many.. Although these messages suggest problem with the sound card driver or unusual clock drifts, it could well be something wrong with this version of xine. Tuning some of the xine configuration parameters such as audio.av_sync_method and others in the .xine/config file may help, but I would first check with the xine mailing list. Selva --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
On Tue, 24 Aug 2004, Anne Wilson wrote: It isn't that I de-interlaced. I wanted a series of 5-second-ish stills pulled from the main video - a sort of summary to pull things together If the main video was interlaced then the stills need to be treated as interlaced. the whole lot again. Would that be a matter of adding -I t -L 1 to jpeg2yuv? Yes, I think that would be a good idea - otherwise you'll end up with progressive frames. I am not sure I understand. You mean audio quality? Yes - I was wondering whether I could have got a faster sampling rate or something, to make it less of a gap. One question just hit me... Did you create the audio track in little pieces (individual .mp2 files) that were catenated together or did you do one long audio capture and encoding? I'm wondering if the playback problems you're having are due to discontinuities in the audio stream at the splice/join points. If I re-create all the avis in an interlaced mode, will the blends automatically be interlaced? Unless you place a 'yuvdeinterlace' command in the pipeline the interlacing will be preserved. Now there's another question. The main avis are in 768x576, whereas I want 720x576. I was expecting to use yuvscaler just prior to encoding. Of course If the main files are 768x576 then scaling back to the DVD frame size is not just a good idea - it's required ;) Cheers, Steven Schultz --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
On Tue, 24 Aug 2004, Anne Wilson wrote: I did try it in totem, but that yielded no info at all. The result was at least as bad as with xine, possibly worse. totem is just another front-end to xine that uses the same xine-library for playback, isn't it? Selva --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 24 Aug 2004 21:27, Selva Nair wrote: On Tue, 24 Aug 2004, Anne Wilson wrote: I did try it in totem, but that yielded no info at all. The result was at least as bad as with xine, possibly worse. totem is just another front-end to xine that uses the same xine-library for playback, isn't it? In that case it will tell us nothing. I did wonder if it had something in common. Amme - -- Registered Linux User No.293302 Have you visited http://twiki.mdklinuxfaq.org yet? -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBK7J7kFAvMr/nNX8RAuThAKCQ/TJfPsWxsCVOkua55GY+WkkgxgCgisMf anL9bs7w6y+YDCOfRf0tRbo= =n0Ey -END PGP SIGNATURE- --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 24 Aug 2004 21:13, Steven M. Schultz wrote: On Tue, 24 Aug 2004, Anne Wilson wrote: It isn't that I de-interlaced. I wanted a series of 5-second-ish stills pulled from the main video - a sort of summary to pull things together If the main video was interlaced then the stills need to be treated as interlaced. OK - I'll se to that. the whole lot again. Would that be a matter of adding -I t -L 1 to jpeg2yuv? Yes, I think that would be a good idea - otherwise you'll end up with progressive frames. OK I am not sure I understand. You mean audio quality? Yes - I was wondering whether I could have got a faster sampling rate or something, to make it less of a gap. One question just hit me... Did you create the audio track in little pieces (individual .mp2 files) that were catenated together or did you do one long audio capture and encoding? I'm wondering if the playback problems you're having are due to discontinuities in the audio stream at the splice/join points. No, it was taken from an avi in one piece - except that there was an edit of 2-3 frames of the avi, IIRC, near the beginning to correct a wobble - which explains the hiccough that I said was unavoidable. Apart from that it is one untouched stream. If I re-create all the avis in an interlaced mode, will the blends automatically be interlaced? Unless you place a 'yuvdeinterlace' command in the pipeline the interlacing will be preserved. Good Now there's another question. The main avis are in 768x576, whereas I want 720x576. I was expecting to use yuvscaler just prior to encoding. Of course If the main files are 768x576 then scaling back to the DVD frame size is not just a good idea - it's required ;) Yes, I realise that, but I was just unsure as to the right stage in which to do it. Anne - -- Registered Linux User No.293302 Have you visited http://twiki.mdklinuxfaq.org yet? -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBK7O2kFAvMr/nNX8RAsTvAJ9iSP5qgosnDGhAyIgDFhTpFp7YIACfaS2r 7UVlA6fDO5ZTTdgnpfwVpfo= =5eBS -END PGP SIGNATURE- --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 24 Aug 2004 21:23, Selva Nair wrote: On Tue, 24 Aug 2004, Anne Wilson wrote: It isn't that I de-interlaced. I wanted a series of 5-second-ish stills pulled from the main video - a sort of summary to pull things together instead of the abrupt ending. I started each of these from a single frame pulled from the main recording. Since this project is very much a learning experience I'm quite prepared to do the whole lot again. Would that be a matter of adding -I t -L 1 to jpeg2yuv? Yes -I t if the rest of the video is top-field-first (check with lavinfo), and -L 1 if the jpeg is an interleaved frame, not one field after the other. I seldom use jpeg2yuv, so I am copying from the manpage. (ppmtoy4m is the way to go, but I digress :) Yes - I'll remember to check. Or is it maybe that I didn't get a good quality sound grab in the first place? I am not sure I understand. You mean audio quality? Yes - I was wondering whether I could have got a faster sampling rate or something, to make it less of a gap. Sorry, I am missing here something. Which gap ? No, you're not missing something. It's probably my lack of understanding. I thought the problem was a performance gap between the audio and the video? If I re-create all the avis in an interlaced mode, will the blends automatically be interlaced? Generally blending is a pixel-wise operation so interlacing should not be affected. In particular, if you are using transit.flt to generate the transition, then yes interlacing will be preserved. Good Now there's another question. The main avis are in 768x576, whereas I want 720x576. I was expecting to use yuvscaler just prior to encoding. Of course Out of curiosity, how did you end up with a 768x576 interlaced PAL avi? My capture card is a DC10+ under v4l - that's the resolution it captures at full size. On my previous small project I used -d 2, but I think on this one I used -d 1 in lavrec. I had used yuvscaler on the coda, so that I could check that it was working. I guess that it would be better to take it on trust and then convert them all at the same time when encoding? I think so. OK Anne - -- Registered Linux User No.293302 Have you visited http://twiki.mdklinuxfaq.org yet? -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBK7RqkFAvMr/nNX8RAo7CAJ4nm0od0udYpdkT9KTnBcxZL5I68QCdE44V 9pyfWMgA3PZQa7W1Jgcr6tA= =4q/C -END PGP SIGNATURE- --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
On Tue, 24 Aug 2004, Anne Wilson wrote: On Tuesday 24 Aug 2004 21:23, Selva Nair wrote: On Tue, 24 Aug 2004, Anne Wilson wrote: Out of curiosity, how did you end up with a 768x576 interlaced PAL avi? That's the square pixel PAL full frame size of course ;) 768/576 = 4/3 My capture card is a DC10+ under v4l - that's the resolution it captures at full size. On my previous small project I used -d 2, but I think on this one I used -d 1 in lavrec. Yep - and DC10+ cards generate square pixels (or, if they can provide Rec.601 pixels then the drivers/software aren't requesting that format). Thus the need to resample/scale to the DVD frame size. This: http://www.mir.com/DMG/aspect.html and the paragraph with: An image with a standard display aspect ratio of 4:3 (i.e. TV) with 576 lines (i.e. PAL) would thus have: * 768 square pixels per line, or * 702+54/59 non-square 59:54 pixels per line So, a DVD frame of 720x576 is really (and we'll round up a pixel or so) a 704x576 area inside a 720x576 frame! You'll have 8 pixels of black on each side in a correctly resampled 768x576 to 720x576 frame. Don't worry about seeing the black borders though - they'll be hidden by the thief (TV overscanning) ;) If you have y4mscaler this is what should do the job for you: ... | y4mscaler -I sar=1:1 -O sar=PAL -O preset=DVD -O option=sinc:4 | ... Of course you could just go with the 704x576 frame size - just change the -O preset=DVD to be -O size=704x576, I think that should do the trick. Good Luck! Steven Schultz --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
On Tue, 24 Aug 2004, Steven M. Schultz wrote: Out of curiosity, how did you end up with a 768x576 interlaced PAL avi? That's the square pixel PAL full frame size of course ;) 768/576 = 4/3 I know, but I avoid capture cards that generate square pixels from non-square pixel sources. As you know PAL or for that matter NTSC frames are not exactly 4:3. I hope the card is padding the frame correctly before scaling. My capture card is a DC10+ under v4l - that's the resolution it captures at full size. On my previous small project I used -d 2, but I think on this one I used -d 1 in lavrec. Yep - and DC10+ cards generate square pixels (or, if they can provide Rec.601 pixels then the drivers/software aren't requesting that format). Thus the need to resample/scale to the DVD frame size. Funny that it cant be convinced to deliver 704x576 or padded 720x576 frames. Selva --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
On Tue, 24 Aug 2004, Selva Nair wrote: I know, but I avoid capture cards that generate square pixels from non-square pixel sources. As you know PAL or for that matter NTSC frames It's not generating square from non-square. It's sampling the analog waveform at a frequency which gives 768 square pixels per line. A card is free to sample the analog at any frequency it wants. The DC10+ just happens to be sampling at the rate which gives 768 active samples per line. are not exactly 4:3. I hope the card is padding the frame correctly before scaling. If it's sampling at 14.75MHz then no padding is required - the card is delivering a 4/3 aspect picture at 768 pixels per line. Funny that it cant be convinced to deliver 704x576 or padded 720x576 frames. Ah, but 704x576 and 720 are 59:54 pixels, not 1:1. If the card were sampling at 13.5MHz and generating 704 or 720x576 frames then we wouldn't be having this discussion :-) See: http://www.uwasa.fi/~f76998/video/conversion/ Chapter 3 has a nice table with a lot of useful information. You can see that 768x576 1:1 size uses a ~14.75MHz sampling rate while the 720x576 and 704x576 59:54 (well, he uses 128/117 but that's close enough ;)) are using a 13.5MHz sampling rate. Even though I switched to the DV capture method quite some time ago I still use y4mscaler a lot when converting HDTV to widescreen DVD (the scaling's actually more cpu intense than the mpeg2 encoding as it turns out) and thus need to convert from square pixels to 40:33 for 16/9 DVD. Steven Schultz --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
On Tue, 24 Aug 2004, Steven M. Schultz wrote: On Tue, 24 Aug 2004, Selva Nair wrote: I know, but I avoid capture cards that generate square pixels from non-square pixel sources. As you know PAL or for that matter NTSC frames It's not generating square from non-square. It's sampling the analog waveform at a frequency which gives 768 square pixels per line. A card is free to sample the analog at any frequency it wants. The DC10+ just happens to be sampling at the rate which gives 768 active samples per line. are not exactly 4:3. I hope the card is padding the frame correctly before scaling. If it's sampling at 14.75MHz then no padding is required - the card is delivering a 4/3 aspect picture at 768 pixels per line. Agreed, if its sampling at 14.75Mhz no scaling is needed, only a 1 pixel padding. Even though I switched to the DV capture method quite some time ago I still use y4mscaler a lot when converting HDTV to widescreen DVD (the scaling's actually more cpu intense than the mpeg2 encoding as it turns out) and thus need to convert from square pixels to 40:33 for 16/9 DVD. Oh, HDTV.. well, so its getting harder and harder to avoid scaling, eh? Thanks for the info. Selva --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
On Tue, 24 Aug 2004, Selva Nair wrote: Agreed, if its sampling at 14.75Mhz no scaling is needed, only a 1 pixel padding. Oops - slight misunderstanding there. For PAL if it was sampling at 13.5MHz there would be no need for scaling because the card would be giving 704 samples/line. At 14.5MHz it is giving 768. In analog to digital conversion fractional and odd sample counts get rounded up to an easier to implement (in hardware) multiple of 8 - thus the 702.xxx gets bumped up to 704. Perhaps a little arithmetic will clear things up (and besides, I feel like improving my typing skills ;)). PAL --- Square pixel sampling freq: 14.75 MHz Rectangular (Rec.601) sampling freq: 13.5 MHz NTSC Square pixel sampling freq: 12 + 3/11 MHz Rectangular (Rec.601) sampling freq: 13.5 MHz Notice anything interesting? The rectangular rates are the same. You can look those numbers up in any broadcast TV reference. From those numbers the ratio of the rectangular/square pixels is derived. I'll omit the reduction of common factors - I assume we've all have basic math skills :-) Thus, for PAL square / rect = (14 + 3/4) / (13 + 1/2 ) = 59/54 EXACTLY And for NTSC square / rect = (12 + 3/11) / (13 + 1/2) = 10/11 EXACTLY Q.E.D. So, to convert from square to rectangular sampling you use y4mscaler with -O sar=PAL or -O sar=NTSC which mean -O sar=59:54 and -O sar=10:11 respectively. All more clear now? ;) Even though I switched to the DV capture method quite some time ago I still use y4mscaler a lot when converting HDTV to widescreen DVD Oh, HDTV.. well, so its getting harder and harder to avoid scaling, eh? Yep - 1920x1080i over the air. I use a Samsung T-165 receiver which has a couple IEEE1394 ports on it. Attach it to my Powerbook and run a Virtual D-VHS program available (free) from Apple and capture the transport streams. Takes a minimum of a 2GHz G5 to play back a ~14Mb/s stream so I usually grind the data thru a decode|scale|encode cycle. Oh, in the US (not sure about Canada and other neighboring NTSC countries) there's the 'broadcast flag' that the FCC is imposing (greed/pressure from the MPAA and so on). After July 5 2005 you won't be able to buy HDTV receivers without copy protection !$*(@# stuff. Existing equipment's being 'grandfathered in' so hardware you buy today that doesn't honor the broadcast flag will still work. Thus if you're ever going to be interested in HDTV reception on a computer running other than windoze you may want to get the equipment now while the getting is good. http://www.pchdtv.com is a PCI card (that I'm thinking of getting before it's too late). Linux Journal has mentioned that in 2005 they'll be covering projects that require pre-ban cards... Cheers, Steven Schultz --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Too late?
On Tue, 24 Aug 2004, Steven M. Schultz wrote: On Tue, 24 Aug 2004, Selva Nair wrote: Agreed, if its sampling at 14.75Mhz no scaling is needed, only a 1 pixel padding. Oops - slight misunderstanding there. For PAL if it was sampling at 13.5MHz there would be no need for scaling because the card would be Oh no, in this context I was not referring to scaling required to burn dvds, but to scaling (and padding) during capture -- I thought we were debating on my statement that I do not like cards that _scale_ from non-square to square pixels to which you pointed out that DC10 or its driver does not _scale_ but simply sample at 14.75MHz to generate square pixels. In the first place I should have written that as I prefer cards that sample at 13.5MHz as my destination is almost always dvds and that would have avoided all this confusion. Of course, the 14.75MHz sampled square-pixel PAL sources have to be appropriately scaled (with padding/clipping as necessary) to a valid dvd frame size before encoding to dvds. Selva --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
