Re: Fixing mpeg2enc
Steven Boswell II <[email protected]> Mon, 30 Aug 2010 17:58:24 -0700 (PDT)
| Newsgroups | gmane.comp.video.mjpeg.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============8174166758758789022== Content-Type: multipart/alternative; boundary="0-1841066409-1283216304=:73301" --0-1841066409-1283216304=:73301 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >--- On Mon, 8/30/10, Andrew Stevens <[email protected]> wrote: >>[1] MPEG-1 encoding is really broken. > >MPEG-*1* is still in use?=A0 Cripes! Hey, VideoCDs forever! :-)=A0 VCD-grade video is one of my torture tests fo= r y4mdenoise -- I see how low I can push the bitrate before the picture sta= rts to break down.=A0 I can easily squeeze a 2 hour 15 minute movie onto a = VCD with good resolution.=A0 Also, I can put about 8 hours of VCD-grade vid= eo on a DVD, which is really handy. Also, someone wrote in a long time ago, asking about MPEG-1 streaming and t= he same mpeg2enc artifact I'm talking about, so there are at least two peop= le left in the world that would appreciate this. >Can you put a sample where it happens online someplace? I've e-mailed the first clip to you.=A0 Luckily, bzip2 works great on .yuv = streams that have been run through y4mdenoise, so 2.66MB of raw video compr= essed down to 118KB in this case. >>[2] MPEG-2 encoding still has that overflow issue with "-q 1". > >Does the problem also occur if you disable SIMD (MMX support) for >quantization and inverse quantization? How do I do that?=A0 I'd be happy to run a full DVD-sized test with SIMD su= pport turned off if you tell me how to do this.=A0 FYI, both of my computer= s are Athlon-based. >If it fails can you put .iso of failing snippet online someplace? Since the pattern repeats every GOP, and mostly on scenes where very little= is changing, I should be able to produce a clip that easily fits into your= mailbox.=A0 That's my next priority. >The problem with-only-on-embedded-HW bugs is they're monstrously hard >to pin down without access to a HW development environment / >bit-accurate simulation model.=A0 Its not like you can nail down the >offending macro-block easily :-( I'd be very tempted to close this >bug (not fix it) my simply flooring q for DVD profiles at 2. Please don't "fix" it that way -- then I'll just be back to having very blo= cky output.=A0 "-q 1" works great when it's not artifacting. >>[3] The most-recent bitrate estimation code seriously undershoots >>the target.=A0 The previous code (which, it looks like, I grabbed from >>CVS around March 15, 2005) does a much better job. > >I know I know.=A0 It simply is not working properly yet.=A0 In all >honesty I'm tempted to write this off (restore mpeg2encs single-pass >rate-control release) and put effort into ffmpeg. I'd be happy with that solution too.=A0 The old bitrate estimation did a fa= ntastic job of maintaining a steady rate, both in terms of size and in term= s of perceptible video quality.=A0 I once tried to use ffmpeg to encode Vid= eoCD-grade video -- the moving scenes looked horrible, and a following stil= l-scene looked intensely high-resolution.=A0 The transition was jarring.=A0= I don't get those sorts of jarring transitions with mpeg2enc.=A0 I vastly = prefer whatever it is you're doing differently. >>[4] The most-recent mplex code seems to have serious trouble with >>A/V sync.=A0 It looks perfect when viewed on my computer, but gets out >>of sync when played on an actual DVD player. > >This is kind of weird.=A0 mplex's basic muxing strategy hasn't changed >in years (decades?)=A0 unless someone else has fiddled with it.=A0 What >kind of out-sync?=A0 A fixed offset or a steady 'drift'...=A0 is there >any remux-ing going on elsewhere in the toolchain -> DVD? No, there's no remuxing -- I wouldn't put up with such distortion in my out= put chain. :-)=A0 It seems like it's in sync at the beginning, then quickly= gets a good half-second or more out of sync and stays there. I don't think I can reproduce that one with a short clip -- I may just have= to mail you a DVD. ----- There's one more artifact I thought of, one that might be related to the ab= ove 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 k= ind 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 descri= be this one. Steven Boswell =0A=0A=0A --0-1841066409-1283216304=:73301 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 Mon, 8/30/10, Andrew Stevens <w= [email protected]> wrote:<br>>>[1] MPEG-1 encoding is really = broken.<br>><br>>MPEG-*1* is still in use? Cripes!<br><br>Hey, = VideoCDs forever! :-) VCD-grade video is one of my torture tests for = y4mdenoise -- I see how low I can push the bitrate before the picture start= s to break down. I can easily squeeze a 2 hour 15 minute movie onto a= VCD with good resolution. Also, I can put about 8 hours of VCD-grade= video on a DVD, which is really handy.<br><br>Also, someone wrote in a lon= g time ago, asking about MPEG-1 streaming and the same mpeg2enc artifact I'= m talking about, so there are at least two people left in the world that wo= uld appreciate this.<br><br>>Can you put a sample where it happens onlin= e someplace?<br><br>I've e-mailed the first clip to you. Luckily, bzi= p2 works great on .yuv streams that have been run through y4mdenoise, so 2.66= MB of raw video compressed down to 118KB in this case.<br><br>>>[2] M= PEG-2 encoding still has that overflow issue with "-q 1".<br>><br>>Do= es the problem also occur if you disable SIMD (MMX support) for<br>>quan= tization and inverse quantization?<br><br>How do I do that? I'd be ha= ppy to run a full DVD-sized test with SIMD support turned off if you tell m= e how to do this. FYI, both of my computers are Athlon-based.<br><br>= >If it fails can you put .iso of failing snippet online someplace?<br><b= r>Since the pattern repeats every GOP, and mostly on scenes where very litt= le is changing, I should be able to produce a clip that easily fits into yo= ur mailbox. That's my next priority.<br><br>>The problem with-only= -on-embedded-HW bugs is they're monstrously hard<br>>to pin down without= access to a HW development environment /<br>>bit-accurate simulation model. Its not like you can nail down the<br>>offendin= g macro-block easily :-( I'd be very tempted to close this<br>>bug (not = fix it) my simply flooring q for DVD profiles at 2.<br><br>Please don't "fi= x" it that way -- then I'll just be back to having very blocky output. = ; "-q 1" works great when it's not artifacting.<br><br>>>[3] The most= -recent bitrate estimation code seriously undershoots<br>>>the target= . The previous code (which, it looks like, I grabbed from<br>>>= CVS around March 15, 2005) does a much better job.<br>><br>>I know I = know. It simply is not working properly yet. In all<br>>hone= sty I'm tempted to write this off (restore mpeg2encs single-pass<br>>rat= e-control release) and put effort into ffmpeg.<br><br>I'd be happy with tha= t solution too. The old bitrate estimation did a fantastic job of mai= ntaining a steady rate, both in terms of size and in terms of perceptible video quality. I once tried to use ffmpeg to encode Vide= oCD-grade video -- the moving scenes looked horrible, and a following still= -scene looked intensely high-resolution. The transition was jarring.&= nbsp; I don't get those sorts of jarring transitions with mpeg2enc. I= vastly prefer whatever it is you're doing differently.<br><br>>>[4] = The most-recent mplex code seems to have serious trouble with<br>>>A/= V sync. It looks perfect when viewed on my computer, but gets out<br>= >>of sync when played on an actual DVD player.<br>><br>>This is= kind of weird. mplex's basic muxing strategy hasn't changed<br>>i= n years (decades?) unless someone else has fiddled with it. Wha= t<br>>kind of out-sync? A fixed offset or a steady 'drift'... = ; is there<br>>any remux-ing going on elsewhere in the toolchain -> D= VD?<br><br>No, there's no remuxing -- I wouldn't put up with such distortion in my output chain. :-) It seems like it's in sync at the= beginning, then quickly gets a good half-second or more out of sync and st= ays there.<br><br>I don't think I can reproduce that one with a short clip = -- I may just have to mail you a DVD.<br><br>-----<br><br>There's one more = artifact I thought of, one that might be related to the above bugs. O= n my computer screen, video looks perfect, but when I view it with a DVD pl= ayer on a TV, whether a CRT-style TV or an LCD-style TV, it kind of looks l= ike the video has been run through a "plaid" filter. Even my highest-= resolution video looks like it's melting on a very small scale, especially = in not-so-brightly-lit areas. I don't know how else to describe this = one.<br><br>Steven Boswell<br><br></td></tr></table><br>=0A=0A=0A=0A=0A=0A= =0A=0A --0-1841066409-1283216304=:73301-- --===============8174166758758789022== 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 --===============8174166758758789022== 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 --===============8174166758758789022==--