Re: Fixing mpeg2enc
Steven Boswell II <[email protected]> Tue, 31 Aug 2010 16:45:37 -0700 (PDT)
| Newsgroups | gmane.comp.video.mjpeg.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============0475547978713731374== Content-Type: multipart/alternative; boundary="0-1365363177-1283298337=:75901" --0-1365363177-1283298337=:75901 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --- On Tue, 8/31/10, Andrew Stevens <[email protected]> wrote: >>>>[3] The most-recent bitrate estimation code seriously undershoots >>>>the target. >>> >>>I'm tempted to write this off (restore mpeg2encs single-pass >>>rate-control release) >> >>I'd be happy with that solution too.=A0 The old bitrate estimation did >>a fantastic job of maintaining a steady rate, both in terms of size >>and in terms of perceptible video quality. > >Sounds like differently tuned formula for bit-allocation based on >predicted/actual complexity.=A0 It *should* be possible to use ffmpeg's >facility for user-defined rate-control Formulae to achieve something >pretty close. I prefer your facility.=A0 ffmpeg's doesn't work for me. >Thinking about it ...=A0 I'm not sure what you mean with 'undershoot'. >There's currently no mechanism for specifying a target mean rate As in, I ask for 4000 kbps video, and the final result is closer to 2000 kb= ps.=A0 I like to pick a bitrate that fills all the space I want the video t= o occupy on a DVD, so undershooting doesn't help me at all. >>>>[4] The most-recent mplex code seems to have serious trouble with >>>>A/V sync. > >Thats really *weird* .=A0 mplex-internally its hard to see how audio >could first drift and then stop drifting. I don't know either, but it was really pronounced.=A0 Once you're done with= a round of bug-fixing, I'll redo that project (which will take a week or s= o...I didn't save the denoised video from that one, sadly) and see if it's = still off.=A0 If so, I'll have to figure out how to get the ISO to you.=A0 = I don't know if KTorrent can act as its own tracker, but if so, maybe I can= make a private torrent for you.=A0 Otherwise, snail-mail! >>There's one more artifact I thought of, one that might be related to >>the above bugs.=A0 On my computer screen, video looks perfect, but >>when I view it with a DVD player on a TV, whether a CRT-style TV or >>an LCD-style TV, it kind of looks like the video has been run >>through a "plaid" filter.=A0 Even my highest-resolution video looks >>like it's melting on a very small scale, especially in >>not-so-brightly-lit areas.=A0 I don't know how else to describe this >>one. > >This sounds like decoder mismatch...=A0 (MPEG-2 isn't bit-accurately >specified, unlike MPEG-4) you can get subtle block artefacts if the >encoders idea of the decoded image and the actual decode are slightly >different.=A0 Is this also a recent issue?=A0 If you can upload an .iso >someplace I'll take a peek... I think this has been going on ever since I started doing video with Linux,= but I'll check through some of my oldest recordings to see if it looks lik= e it's happening there.=A0 (Though it'll be hard to evaluate my pre-y4mdeno= ise recordings for artifacts...they're all artifacted :-) Steven Boswell =0A=0A=0A --0-1365363177-1283298337=:75901 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <table cellspacing=3D"0" cellpadding=3D"0" border=3D"0" ><tr><td valign=3D"= top" style=3D"font: inherit;">--- On Tue, 8/31/10, Andrew Stevens <wacks= [email protected]> wrote:<br>>>>>[3] The most-recent bitrat= e estimation code seriously undershoots<br>>>>>the target.<br>&= gt;>><br>>>>I'm tempted to write this off (restore mpeg2encs= single-pass<br>>>>rate-control release)<br>>><br>>>I'= d be happy with that solution too. The old bitrate estimation did<br>= >>a fantastic job of maintaining a steady rate, both in terms of size= <br>>>and in terms of perceptible video quality.<br>><br>>Sound= s like differently tuned formula for bit-allocation based on<br>>predict= ed/actual complexity. It *should* be possible to use ffmpeg's<br>>= facility for user-defined rate-control Formulae to achieve something<br>>= ;pretty close.<br><br>I prefer your facility. ffmpeg's doesn't work f= or me.<br><br>>Thinking about it ... I'm not sure what you mean with= 'undershoot'.<br>>There's currently no mechanism for specifying a targe= t mean rate<br><br>As in, I ask for 4000 kbps video, and the final result i= s closer to 2000 kbps. I like to pick a bitrate that fills all the sp= ace I want the video to occupy on a DVD, so undershooting doesn't help me a= t all.<br><br>>>>>[4] The most-recent mplex code seems to have = serious trouble with<br>>>>>A/V sync.<br>><br>>Thats real= ly *weird* . mplex-internally its hard to see how audio<br>>could = first drift and then stop drifting.<br><br>I don't know either, but it was = really pronounced. Once you're done with a round of bug-fixing, I'll = redo that project (which will take a week or so...I didn't save the denoise= d video from that one, sadly) and see if it's still off. If so, I'll = have to figure out how to get the ISO to you. I don't know if KTorrent can act as its own tracker, but if so, maybe I can make a private= torrent for you. Otherwise, snail-mail!<br><br>>>There's one m= ore artifact I thought of, one that might be related to<br>>>the abov= e bugs. On my computer screen, video looks perfect, but<br>>>wh= en I view it with a DVD player on a TV, whether a CRT-style TV or<br>>&g= t;an LCD-style TV, it kind of looks like the video has been run<br>>>= through a "plaid" filter. Even my highest-resolution video looks<br>&= gt;>like it's melting on a very small scale, especially in<br>>>no= t-so-brightly-lit areas. I don't know how else to describe this<br>&g= t;>one.<br>><br>>This sounds like decoder mismatch... (MPEG-= 2 isn't bit-accurately<br>>specified, unlike MPEG-4) you can get subtle = block artefacts if the<br>>encoders idea of the decoded image and the ac= tual decode are slightly<br>>different. Is this also a recent issue? If you can upload an .iso<br>>someplace I'll take a= peek...<br><br>I think this has been going on ever since I started doing v= ideo with Linux, but I'll check through some of my oldest recordings to see= if it looks like it's happening there. (Though it'll be hard to eval= uate my pre-y4mdenoise recordings for artifacts...they're all artifacted :-= )<br><br>Steven Boswell<br><br></td></tr></table><br>=0A=0A --0-1365363177-1283298337=:75901-- --===============0475547978713731374== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd --===============0475547978713731374== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mjpeg-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mjpeg-developer --===============0475547978713731374==--