Transcoded material de-interlaced but shouldn't be

[mrvanes@…]

Transcoded material (mpeg4 and rtjpeg) is shown with deinterlace. This results in broken playback for xvmc/bob deinterlace method.

[spin667@…]

How can you tell it's shown with de-interlacing (I'm sure it probably is as I don't think the frontend tries to detect if the material is interlaced or not)?

Also, just because something is transcoded doesn't mean de-interlacing was done. That's an option.

I play de-interlaced mpeg4/nuv recordings with mythtv all the time also using xvmc/bob and haven't noticed a problem. How is playback "broken" for you?

[danielk]

No indication that myth is behaving incorrectly in description

[mrvanes@…]

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... ---

[cpinkham]

Unable to reproduce with SVN trunk here. Either this is fixed or was an issue with the reporters system.