weird problem, video decodes fine in DXVA, awful in software

[deets]

hmm so i have an odd problem. I have a video file that plays back fine using DXVA, but if i switch to a software decoder, the picture looks really bad quality or is very jerky.

Its a 1080i 25fps football capture that i convert to 1080p 50fps....

In DXVA mode there is little blocking or pixelation, in softwae i get lots of blocking and smearing, although it does sometimes blip to the high quality.

tried feeding the file via neuron2's NV decoding tools and also a straight conversion in ripbot, same problem :confused:

any ideas how to get it playing back the same in software (ie ffdshow as well as DXVA decoding?

a 50mb encoded clip is here to see if the issue can be replicated and commented on....

bitrate is about 10mbs

http://www.mediafire.com/file/vzwinammmkk/09-09_20-59-41_10510_World Cup Qualifier England v Croatia_fixedchip-001.mkv

[nm]

hmm so i have an odd problem. I have a video file that plays back fine using DXVA, but if i switch to a software decoder, the picture looks really bad quality or is very jerky.

Its a 1080i 25fps football capture that i convert to 1080p 50fps....
Your sample clip plays fine here with MPlayer, except that my CPU is not fast enough to decode it in real time. Even MPlayer & ffmpeg-mt is a bit too slow on this 1.9 Ghz Turion X2. VLC displays a slideshow of the video, and after seeking it gives the blocking and smearing effect that you described. So the origin of your problems is probably the same as mine: the software decoder that you are using is not fully multithreaded or it's otherwise slow, or your CPU is not fast enough.

Have you already tried setting the H.264 decoder used by ffdshow-tryouts to "ffmpeg-mt"? Alternatively, you could also use DivX 7, which is even faster. Or encode the video with x264 parameter "--slices 4" so that standard libavcodec has a better chance of decoding it in real time.

[kieranrk]

You can't do slice-based multithreaded decoding with x264's slicing implementation.

[ajp_anton]

VLC is glitchy for a second after seeking, but there are no problems whatsoever with MPC's internal decoder or when not seeking.

[nm]

You can't do slice-based multithreaded decoding with x264's slicing implementation.
Generally you can, but slice-parallel decoding in libavcodec is implemented so that it doesn't support the type of deblocking that may cross slice boundaries. This could be worked around by deblocking after a full frame has been decoded, for example, but that's not supported in libavcodec. Instead, you can ignore the problem by setting libavcodec parameter "fast" (mplayer -lavdopts threads=4:fast). This may cause some corruption, but it's not usually visible in normal playback.

Anyway, it's better to use ffmpeg-mt or some other frame-parallel decoder.

[Blue_MiSfit]

... or CoreAVC or DivX H.264 :)

Plemty of options!

~MiSfit

[deets]

something someone said to me, the level is wrong, it should be 4.2. would that make a huge difference? I guess my centrino laptop just doenst have the power for this one, even with ffdshow mt :)

[Astrophizz]

Yes, I don't believe that would be fast enough for 1080p at 50 fps.

[nm]

something someone said to me, the level is wrong, it should be 4.2. would that make a huge difference?
None for these software decoders. Generally, if you flag it L4.2, some commercial DXVA/software codecs may refuse to play it back altogether.

I guess my centrino laptop just doenst have the power for this one, even with ffdshow mt :)
If it's Core 2 Duo, try the DivX 7 decoder to be sure. It's freeware.