Log in

View Full Version : x264 compressing and decompressing problems


ian8210
16th August 2005, 06:06
Hi,there!
I'm a newbee here presently working on some sort of video capturing ,real time encoding and decoding things, works just like an MSN video conversation or so, but using vfw instead (old things, but easy :)). Planning to use x264vfw as an encoder with ffdshow as the decoder.
Since x264vfw doesn't support the ICSeqCompressFrame API,which is a normal way of dealing with captured video frame stream, I used ICCompress instead. It's working fine now. But the problem is with decoding! FFdshow crashes unpredictably! I' m using ffdshow-20050803, but it just went on decoding for a while(do not exactly know the duration, sometimes crashed after 10 or more min, sometimes just broke down as soon as the decoding started, but there's one thing for sure: it crashes every time!), giving me the information:"First-chance exception in Main2.exe (LIBAVCODEC.DLL): 0xC0000005: Access Violation."(VC++ environments).I don't know what's happenning there! Does anybody here know the reason , or is anyone here doing the same thing as I am? Need help desperately!
Thanks in advance!

ian8210
16th August 2005, 06:11
Debug stops at "6FC92C88 movq mm0,mmword ptr [ecx]"

MeteorRain
16th August 2005, 07:56
x264 in avi should be avoided `cause it's dangerous, and may cause system halt or computer restart :O
i would like to suggest you turn to xvid and try.

regards

ian8210
16th August 2005, 08:23
Thanks,MeteorRain. As a matter of fact, there is no avi file created in the process. I just capture the video, encode the frame,and send it! For the receiving part, the work is just to decode the received frames and desplay it, that's all. I'm just wondering why x264 does not support ICSeqCompressFrame, as a lot of other encoders do, such as H.263,XviD......
BTW, what kind of container do u suggest,MeteorRain? Why is avi unsafe?
Thanks again!

ian8210
16th August 2005, 09:00
I'm wondering if H.264 was an "upgrade" for H.263. If so , it should be suitable for video streaming edcode. Just like H.263 in NetMeeting ..........

foxyshadis
16th August 2005, 09:18
h.264 was designed for streaming, yes; however, h.263 has been around for many years now, while h.264 only a little over a year, and software and hardware to play it is just beginning to filter into the business and consumer markets. It's not a good choice for the widest possible audience yet, unless you want to do considerable evangelism. Of course, you can always have multiple stream formats...

And a system halt sounds like something that'd happen on NT 3, not 2k/XP; as long as your system's newish and not falling apart, that should never happen.

Not that it means directshow and ffdshow will behave any better.

bond
16th August 2005, 12:27
well all i can say is that ffdshow works fine decoding x264's avc streams (except when using cqm) here in normal circumstances, eg in dshow

[)370|\|470!2
16th August 2005, 15:30
well all i can say is that ffdshow works fine decoding x264's avc streams (except when using cqm) here in normal circumstances, eg in dshow


Well, if you ain't care about quality, yes. In terms of quality, ffdshow H.264 decoding's
sux. At bitrates below 700 kbps at least. Here some samples of same video
processed in bsplayer using ffdshow-20050803 and nero NeVideo.ax ver. 3, 2, 0, 7 :

http://tinypic.com/am9pqs.jpg
(FFDSHOW)

http://tinypic.com/am9r85.jpg
(NERO)

Sharktooth
16th August 2005, 15:36
hint: turn off the ffdshow's postprocessing and try again :P

lamer_de
16th August 2005, 15:38
You sure you disabled the ffdshow postprocessing (or any other ffdhow filter for that matter)? I remember akupenguin saying that all decoders produce bit-wise identical output, so it doesn't matter which filter you use.

CU,
lamer_de

[)370|\|470!2
16th August 2005, 15:48
Rofl. True. What is this postprocessing crap good for anyway?

Doom9
16th August 2005, 16:26
What is this postprocessing crap good for anyway?It's useful for codecs that don't have built-in deblocking (e.g. ASP codecs), but totally screws up the picture in the AVC case. It's a common mistake that postprocessing is turned on for AVC when using ffdshow.. I wasn't too happy with x264 before I figured the postprocessing thing out.

[)370|\|470!2
16th August 2005, 16:52
I wasn't too happy with x264 before I figured the postprocessing thing out.

Yeah. I know exactly what you mean. But in my case i was a bit surprised with
this crappy picture with floating focus, when i was sure, that at avg. bitrate of
660 kbps 2 pass x264 should produce much more, and teh results were even worse
than of making same bitrate video with xvid. So... I tried to switch filters in graphedit
to nero dvd decoder. And immediately noticed teh huge difference in quality.
Took a few snapshots to compare... And was shocked. Now it figures, that i should've
look more deeply in ffdshow settings, but i just thought, that it's hence of low
quality decoder(ffmpeg). Glad that it isn't so, cause nevideo lacks of lots of needful
settings, like contrast/brightness/saturation etc. :thanks:

ian8210
17th August 2005, 02:17
h.264 was designed for streaming, yes; however, h.263 has been around for many years now, while h.264 only a little over a year, and software and hardware to play it is just beginning to filter into the business and consumer markets. It's not a good choice for the widest possible audience yet, unless you want to do considerable evangelism. Of course, you can always have multiple stream formats...

And a system halt sounds like something that'd happen on NT 3, not 2k/XP; as long as your system's newish and not falling apart, that should never happen.

Not that it means directshow and ffdshow will behave any better.

Using XP SP2.It's not that my system halts, it's just my program crashes. Now I'm now wondering if there is something wrong with the encoding that leads to the decoding crash.Does x264 works fine with "ICCompress"? ;) . Heared that VirtualDub works well encoding with x264.But I'm not dealing with an avi, I'm just dealing with some captured frames......... :(

ian8210
17th August 2005, 02:17
And of courese , I've turned off postprocessing...............

yokem55
17th August 2005, 05:17
Check your hardware. Run prime95 for a few hours and then make a memtest+ boot floppy and check that. It sounds like hardware errors to me....

hellfred
17th August 2005, 07:35
Using XP SP2.It's not that my system halts, it's just my program crashes. Now I'm now wondering if there is something wrong with the encoding that leads to the decoding crash.Does x264 works fine with "ICCompress"? ;) . Heared that VirtualDub works well encoding with x264.But I'm not dealing with an avi, I'm just dealing with some captured frames......... :(
Install AviSynth and feed the frames to VDub via a AviSynth script.

Hellfred

EDIT: You wanted to do in on the fly. So forget about AviSynth in this case .

ian8210
18th August 2005, 04:05
Check your hardware. Run prime95 for a few hours and then make a memtest+ boot floppy and check that. It sounds like hardware errors to me....

It happens to evey PC I've tested :( . Are you guys sure that there SHOULD be nothing wrong with ffdshow decoding ? 'Cos every time it crashes , the system indicates that something's wrong with libavcodec.dll........Maybe I' ll have to check my program ? ICDecompress is the right solution for decoding, using a specific decoder , right?
Really confused! It seems nobody here is doing the same thing as I am. I just wanna try x264 in streaming

ian8210
1st September 2005, 08:36
When I turned off b-frame features,ffdshow worked out fine!No crash anymore. Now I'm using x264vfw build 291 and ffdshow 22 Aug.Can anybody here explain why? thx!

stephanV
1st September 2005, 10:10
ffdshow needs to be able to have a frame buffer when en/de-coding b-frames...

Say you have 7 frames (1 2 3 4 5 6 7), and 2 consecutive (not adaptive) b-frames enabled. Logic predicts that the frame types (B, I, P) will be then:

1I 2B 3B 4P 5B 6B 7P

But before we get to this, we need to encode the frames so how will this go. When b-frames are enabled we need a delay equal to the amount of consecutive b-frames used, because b-frames can only be encoded if both the forward and backward reference are encoded first. This will be the output and input of the encoder

in : 1 2 3 4 5 6 7 8 9
out: - - 1I 4P 2B 3B 7P 5B 6B

If the decoder doesn't buffer frame 4 when it receives it, it doesn't know what to do with frame 2 and 3. I think that is what going worng when directly trying to decode the frames.

ian8210
2nd September 2005, 01:51
Thanks for your detailed explanation! Shall I conclude this way: b-frames features are not suitable in real-time stream situation?