[mythtv-commits] Ticket #1364: Transcoded material de-interlaced but shouldn't be

MythTV mythtv at cvs.mythtv.org
Mon Mar 27 09:28:02 UTC 2006

#1364: Transcoded material de-interlaced but shouldn't be
 Reporter:  mrvanes at gmail.com  |        Owner:  ijr     
     Type:  defect             |       Status:  reopened
 Priority:  minor              |    Milestone:  unknown 
Component:  mythtv             |      Version:  0.19    
 Severity:  medium             |   Resolution:          
Changes (by mrvanes at gmail.com):

  * resolution:  invalid =>
  * status:  closed => reopened


 I'm sorry. I really thought I elaborated on this issue, but my answers
 seem to have missed this trac entry and went into the dev mailinglist
 instead... My answer to this question was this:

 Sorry this wasn't clear, I thought that deinterlaced progressive video
 looked the same everywhere. What I see is 2 frames above eachother
 (both taking up half of the frame height) and one superimposed on top
 of that (and a lot of flicker). That's why I thought it was
 deinterlaced cause it looks like it sends 2 frames in the time of 1
 and then 1 whole, sort of what happens with double frame rate bob I
 thought? Plus, it disappears when I disable deinterlace. I haven't
 experimented with other deinterlace types though.

 Maybe it's of use to tell that I use via XvMC and I suspect my
 deinterlacing is done in HW and that causes the problem?

 And later in the discussion:
 On a sidenote: The transcoding thing was a test to see if I would want
 that on all my recordings, but since my 600MHz via Epia is not capable
 of decoding the transcoded mpeg4 stream smoothly I will stick to the
 native mpeg2 anyway.
 Is there a good reason why this via Epia can't decode the
 forementioned mpeg4 stream fast enough and has no problem whatsoever
 decoding divx movies played by mplayer?
 CPU usage goes to 100% while playing transcoded material (86 for
 mythfrontend, 14 for X), it stays at a cool 38% while playing divx in
 mplayer (30 for mplayer, 8 for X).

 And (in discussion with Aran Cox):
 > If you reduce the
 > verticle resolution by half or more what you've got is poor man's
 > deinterlacing.  Essentially the file will be progressive and mythtv
 > will detect it as progressive and not apply a deinterlace filter.

 Not so. I scaled to 384x288 (using deinterlace filters as well) but
 playback problem (with bob deint) is still there.

 > I don't see why you'd have a problem if you keep the native resolution
 > as long as you have the interlacing related options enabled on the
 > transcoding profile. It's a mystery to me why you'd see that.

 Maybe this is a bug after all? :)

 > mythtv is usually slower than mplayer... you can try transcoding to
 > 384x288 and see if you find it acceptable.

 I did. It's not acceptable (playback is smooth but resolution is too
 low) but above all it doesn't solve the problem...

Ticket URL: <http://svn.mythtv.org/trac/ticket/1364>
MythTV <http://www.mythtv.org/>

More information about the mythtv-commits mailing list