x264 "very slow" profile problem

[deets]

so i have plenty of time on my hands and want to encode using "very slow". problem is, all the videos just stop after a second of *playback*.

Im encoding TV caps from a few sources, be it MPEG2 or H.264 its the same output. If i switch to the quicker presets, the files encode fine.

used lord Mulders prog which has 1373 and the new megui which has 1376. also tried cli 32bit as i normally use 64bit versions

any ideas?

[nakTT]

Hi there,

Most of the time I encode using "Very Slow" preset. So far I have no issue whatsoever. IMHO it is not the issue is with MeGUI or x264 itself as I have no issue with them.

[LoRd_MuldeR]

Post your exact commandline and the shortest possible sample file (unprocessed source) to reproduce the problem.

Also follow the instructions in those posts:
* http://forum.doom9.org/showpost.php?p=1355911&postcount=3
* http://forum.doom9.org/showpost.php?p=1355913&postcount=4

[deets]

well in the process of moving the files to this laptop it has become apparent that its a decoding issue.... seems whatever settings are changed in very slow make my decoder fall over...

odd but at least its fixed, i was thinking it must be a PC specific issue when nakTT posted.

[LoRd_MuldeR]

well in the process of moving the files to this laptop it has become apparent that its a decoding issue.... seems whatever settings are changed in very slow make my decoder fall over...

odd but at least its fixed, i was thinking it must be a PC specific issue when nakTT posted.

The "very slow" preset will use more memory-intensive x264 settings, which means that you may run into the 2 GB per-process memory limit.

So this may be an out-of-memory problem! x264 will report if it fails to allocate memory, but if the decoder fails to allocate memory and thus fails/freezes, x264 cannot do anything about it.

As a test you may try to run the decoder in a separate process by piping the data into x264 from avs2yuv. This will exclude any interference between x264 and the decoder...

[deets]

its a playback issue, the files work fine now with the MPC internal DXVA decoder :)

[nakTT]

its a playback issue, the files work fine now with the MPC internal DXVA decoder :)
What do you mean by playback issue? Care to share? Noob here.

:thanks:

[deets]

What do you mean by playback issue? Care to share? Noob here.

:thanks:

its nothing to do with x264 as when i played the file on a different PC with a different decoder, the file plays fine.

there must be something about the very slow profile that creates a video which causes this specific decoder to halt after a second of playing

[LoRd_MuldeR]

so i have plenty of time on my hands and want to encode using "very slow". problem is, all the videos just stop after a second of encoding.
its nothing to do with x264 as when i played the file on a different PC with a different decoder, the file plays fine.

there must be something about the very slow profile that creates a video which causes this specific decoder to halt after a second of playing

So it's not x264 that stops/locks after a second of encoding, it's the player/decoder that stops after a second of playback with the file produced by x264.

If so, your initial post was kind of misleading ;)

[nakTT]

its nothing to do with x264 as when i played the file on a different PC with a different decoder, the file plays fine.

there must be something about the very slow profile that creates a video which causes this specific decoder to halt after a second of playing
I thought you said its locked-up during encoding process. Now I get the picture.

:thanks:

so i have plenty of time on my hands and want to encode using "very slow". problem is, all the videos just stop after a second of encoding.

Im encoding TV caps from a few sources, be it MPEG2 or H.264 its the same output. If i switch to the quicker presets, the files encode fine.

used lord Mulders prog which has 1373 and the new megui which has 1376. also tried cli 32bit as i normally use 64bit versions

any ideas?

[deets]

yep my mistake, can i blame the hangover :)

[nakTT]

yep my mistake, can i blame the hangover :)
No problem bro, people make mistakes.

[deets]

but ive also tried another decoder and get a similar weird issue after a second of playing it back. seems some decoders dont like the settings of very slow.

just to make it worse, i would just use the mpc filter but that doesnt handle BBC/ITV HD streams so im stuck with having to change things to view live TV and recordings

[Dark Shikari]

Decoder running out of memory? Are you nuts?

A decoder will use about 3 megabytes per refframe for a 1080p video. Even with 16 refs, that's just 48 megabytes. If you don't have 48 megabytes of RAM, it might be rather hard to encode the video in the first place...

[deets]

could it be that very slow uses more reference frames than DXVA allows? i think it says 8 in the updated megui?

[nakTT]

could it be that very slow uses more reference frames than DXVA allows? i think it says 8 in the updated megui?
8 is for B-Frame, R-Frame is 16. So far it works for me.

[henryho_hk]

720x480p60 --profile high --preset veryslow -- level 4.1 @ ATI 4850, Catalyst 9.12, XP x64 ... DXVA@MPC not working either....

But "slower" works.

[burfadel]

Well rumour is Catalyst 10.1 is out today and they have supposedly made under the hood changes. It may help to try that when it becomes available. The number change from 9.12 to 10.1 is just to coincide with the change in month and year, but it does make sense to ATI to make a driver with such change that has some useful changes instead of a bug release as its what people are expecting :)

What version of MPC you using? even in MPC-HC there are many revisions floating around the place, try the latest from www.xvidvideo.ru

You only really need the standalone version, but install the latest Directx first. As of 06 Jan 2010, its currently available here:
http://www.microsoft.com/downloads/details.aspx?FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3&displayLang=en

It can also be found by searching for directx and sorting by release date.

[Cyber-Mav]

8 bframes are dxva compliant? i though going over 3 bframes will cause playback issues for standalone players like the western digital one?

[nurbs]

8 bframes are dxva compliant? i though going over 3 bframes will cause playback issues for standalone players like the western digital one?
Works fine on my WD TV.

[burfadel]

Well looks like 07 Jan was false info for Catalyst 10.1, but funnily enough a beta 10.1 is available unofficially now for Vista & win 7 x86 and x64, version 8.700 (as opposed to Catalyst 9.12 which has version 8.681). Asus has a 8.700 for XP & XP x64 available but not for Vista/7 on their website.

[Cyber-Mav]

Works fine on my WD TV.

dang i didnt know that. i thought i had to stick to 3 bframes since thats the max the blue ray specs use and thought that going above 3 bframes would break playback on hardware such as graphics cards and standalone players.

question is would increasing the bframes from 3 to something like 6 or 9 or even 16 reduce the quality of the final video encode? i read that bframes are compressed more and are usually of lesser quality than other frames.

but then i wonder if the bitrate saved from using more B frames helps to boost overall quality for I and P frames?. bah this is confusing.

[burfadel]

A high setting for b-frames would be ineffective when using the standard b-frame decision method. It could be the case that you're using the normal b-frame decision method, and you aren't using any more than 3 b-frames anyway! The optimal b-frame decision method becomes slower the more b-frames you set due to the decision, the positive though is b-frames are used more effectively. In this case, you could select 6 b-frames, however the compatibility issue may then play a part!

To try it out, try 6 b-frames using b-adapt 2 and see what happens. If it doesn't work, you know that 3 b-frames does, and by using the newer optimal, slower (but not the default) b-adapt 2 method you can potentially make better use of b-frames. Using more b-frames for a fix sized encode will improve quality, as b-frames are very small and hence more quality can be given to the I and P frames. For a constant quality file, the resultant is a smaller file.

[nurbs]

Since Dark Shikari often posted that there is no difference with decoding 1 or decoding 16 b-frames for the decoder compatibility problems should be the exception.

[Cyber-Mav]

well i use weighted prediction for Bframes, bpyramid is set to normal and adaptive b-frames is set to 2-optimal in megui. and all my encodes are 2 pass based. was just worried about standalone player compatability for devices such as western digital and the xtreamer. i know that the pc and even my cuda capable cards can decode 16 bframes without problems, its just that im worried about standalone player compatability. most of my vids i encode are from digicam of home events and then i encode to h264 and put on a dvd and post them to family. and they are usually played back on the western digital wdtv player.

me not having a standalone player makes it difficult for me to test out encodes on such players to ensure compatability. if others could chime in with thier experience of standalone player compatability it would be great. i know the wdtv player plays back the 1920x1080 res videso i have with 9 reference frames and 3 b-frames and weighted prediction for P and B enabled. i guess im asking if anyone knows if setting Bframes to something like 16 or 12 even would still allow my vids to play back on standalone players without issues.
thanks

[deets]

anyway back on topic :) i just stick to L4.1 and i can use very slow without a hitch. guess DXVA needs the level to enforce certain settings

[creamyhorror]

i guess im asking if anyone knows if setting Bframes to something like 16 or 12 even would still allow my vids to play back on standalone players without issues.
thanks
There's no limit on bframes for the WDTV, at least. But there's no reason to go above 4-6 bframes for live-action material, and each additional bframe allowed slows down encoding.