x264 -- during play the video gets currupted in some scenes

[vhelp]

Hi everyone

(wasn't sure where to post this)

I'm using the latest x264 cli version 1071. Great encoder imho..greater encoder. Anyway. I'm having a problem with the video becomming corrupt after a minute of playing, and it seems to corrupt at the same place(s) yes, it corrupts at multiple places. I think it may be my encoding, but I'm not sure about that.

I really want to know what causes this to occur in my videos. But, to get an idea of the corruption, you may want to see what I'm talking about first. However, in huston, we have a problem--I can't get VLC to take a snapshot of it (clipboard or file, doesn't matter to me) and I think I may not being doing it right.

I right-click on the window and click on snapshot, but there is nothing in the clipboard and no bitmap file is written anywhere. I still have the video play in PAUSE, with the corrupt frame in view.

Can someone show me how to take a shapshot and send it to the clipboard ? and then I can show you all whats going on in my x264 encoding and maybe we can figure out why its making me worry, thanks.

For now, I'll leave a blank image, below.



-vhelp 4984

[guns1inger]

Which version of VLC ? 0.9.6 happily takes snaps of mp4 files for me here.

Or you could try MPC HC instead. This will test if it is the encoding, or VLC, and if it is the encoding you can pause and use File -> Save Image

[PuzZLeR]

While you're at it with the latest pic, let me ask, did you try that exact same source/script with another encoder or codec? How about HEnc with MPEG-2, or VirtualDub with Xvid?

Unlike other tools, I've rarely ever have had a problem with corruption on any of the streams generated from x264 encodes, via CLI or any of its GUIs - x264 was always solid in this respect IMO. But when I would have one like that, I noticed it in the same places, time and again, even with other encoders/codecs.

Then I made the decision that the source stream was bad - and that could be a number of issues. (The most popular ones were either bad captures, or source from bad discs.)

If I were you, I would first test to see if it's the source first, before the encoder, to begin diagnosis on this.

[vhelp]

PuzZLeR, Don't get me wrong.. I love x264 cli, and I am not blaiming it in any way, other than that it might be either something I did wrong in the param setup (which I've been using mostly this week, with a few tweaks here and there every so often) or, the encoding got falled (spelling) when I began opening other tools. I sometimes have other things going on inside Windows XP, though somehow, I don't believe that is the problem, I dont' think. It might just be the nature of the encode and the video, uniquely. I don't know. I'm guessing at this time.

Actually, that .mp4 frame is part of a 102.2 MB encode I made from a dv source file from a gui tool I used as the front-end to x264. Most my tools I develope for personal use, case you don't know, and thats not the problem, either Anyway. As I was saying..

That frame you see is part of a series of frames that get (I can't even put a definitive term to it) garbled up like that--it usually starts out pixelating from a stalled play at that point, and then begins to cascade on the same frame into a million pixel pieces, like its bleeding pixel dust or something. Sorry, hard to explain. I wish I could throw up a sample, but not that 102.2 mb size--not on dialup. But, if I find another one like that but smaller, or if I can sneak that size onto a mem stick, I'll try and upload it somewhere when I get into work, monday. Its not easy over there because they have everything locked down tight.

Then I made the decision that the source stream was bad - and that could be a number of issues. (The most popular ones were either bad captures, or source from bad discs.)

If I were you, I would first test to see if it's the source first, before the encoder, to begin diagnosis on this.

I will consider these wise words and look into it. I just wish it wasn't a 102.2 mb size file, it's 1m:33s long. Thats a lot of encoding time for me--roughly 14.5 minutes to encode. But I may repeat the encode again, just to see if it does it again, or tweak one or two settings. Maybe I should post a crude param string--but its on the other computer, gosh. I have lots of other planned (programming) projects that I was suppose to work on, and this issue has taken all my time up. Oh well, its a learning thing, I guess. Anyway.

Thanks for your interest into my x264 wows, really appreciated.

EDITED: added corrections and addtional notes, above.

-vhelp 4987

[vhelp]

Then I made the decision that the source stream was bad - and that could be a number of issues. (The most popular ones were either bad captures, or source from bad discs.)

If I were you, I would first test to see if it's the source first, before the encoder, to begin diagnosis on this.

Ok. I've been pondering this for a while now. Actually, its part of a series of things I was theorizing about over the last several months or so.

I believe that the problem might have something to do with how I am frameservering into x264 via avisynth scripts, and it might be the functions I use in the scripts--or combination of scripts and video source, I don't now.

So far, I've found that sometimes, (though I haven't quite been able to nail it definitively) it seems to happen (the probelm occurs, that is) whenever I use the SelectEvery() function. But, I'm not sure. I think it is a combination of other avisynth functions I use. I have to do more tests. In fact, I think I will re-encode that same clip (still have it) but this time, leave out the SelectEvery() function and see if that resolves it. If it does then I will re-encode it again, and then this time, put back the function again and see if that reproduces the errors. I'll report back how this went as soon as I complete the test.

Until then..

-vhelp 4988

[Slapstick]

If you using VLC for play back then it's kind of a known problem and a simple work around for play back is go to Preferences and select all settings. Then go to input/codecs| Video Codecs | x264 and check " /skip loop filter"

[vhelp]

Thanks Slapstick. Actually, I had already came to the conclusion that it was a codec issue and that it had something to do with VLC.

When I played it (dragging video to icon) onto mplayer, it played without issues and quality was very good. No blocking or fuzzy pixels.

Same goes for when I demuxed the video into a raw h264 and opened it in DGAVCIndex. Video played without issue via F5 or F6 keys.

So, conclusion: as houstin in Texas would say, we have a "codec" problem

I did try the VLC trick, but that only provide poor video playback quality. You can't even enjoy the .mp4 encoded videos in vlc any more if you turn off "deblocking" though I had to make a slight change elsewhere for it to actually happen, else the original issue of frame corruption would occur. Actually, the corruption occurs following a pause, usually a couple of seconds, then the problem. In the pic below, the defaul was set to 'none'. I changed it 'ALL' because I thought that would solve the problem--and it did, plus the new issue of poor quality video playback. I did not include any audio in these test videos. That is an extra (though time consuming task) step that I usually perform at the very tail end of these projects.




Anyway. While I was playing around with other players, MPLAYER for instance, I was looking at the dos console output window while mplayer played the video. It was showing the following info. And I was wondering if anyone had compile a actual separate stand-alone ffh264.ax codec and used that as the decoder, for say, virtualdub.




Thanks for any input..

-vhelp 4989

[PuzZLeR]

I'm not offended whether you like x264 or not. I personally don't use it since it doesn't fit my needs, but I can see how it can be very useful otherwise. But corrupt streams are something I've never seen from it.

Glad it worked with another player. And it could indeed be VLC since there are two other similar "hiccups" I've discovered otherwise.

Whenever I edit MPEG-2 with Womble, and apply more than just cuts or joins, such as transitions or cross-fades, the stream ends up a bit garbled during playback with VLC at those points.

Whenever I edit DivX/Xvid with VirtualDub using Smart Rendering, there are weird aspect ratio shifts during those points during playback with VLC.

Both seem to have problems because VLC detects a "seam" where there were edits made, and no other player has problems with them. Known bug or intelligence? Nevertheless, the problem is always corrected when I remux the streams (or even if I need to re-encode them).

So I can suggest maybe remuxing the streams (either into MP4 or MKV, not raw) and replay them with VLC as such, or my original solution of trying that exact same source with other encoders/codecs to see what happens.