ffdshow tryouts project: Discussion & Development

[jmartinr]

I also had 100% crashes with versions above 4307 (4314 crashed, I couldn't find compiled versions between these two). Looking a bit further I fiddled around with the settings and after checking and unchecking NV12 and RGB24 output color spaces all is now fine and dandy.

Maybe a problem with the retained configuration settings between versions/installations?

[ryrynz]

Haruhiko,

current ffdshow has bug in interaction with avisynth that results in often crashes on stop of MT scripts. It does not affect playback itself.


Is this something that can be looked into? I often get crashes loading the next file if the previous file hasn't played a sufficient amount before it starts to read the next one.

[DMD]

Sorry, still cannot reproduce.
I installed ffdshow_rev4323_20120213_clsid_x64.exe and imported the reg file. I run mpc-hc64 and build the graph as you posted.
I think this is exactly what you are doing. Maybe depends on hardware or device driver?
Can you reproduce the problem on another PC?
The problem is strange.
I performed the test on 2 computers with different hardware
uninstalling and reinstalling ffdshow, without importing the settings from reg file

Achieving the same result.

codec H.264/AVC = libavcodec, works regularly
codec H.264/AVC = disabled, MPCHC crashes
To resolve I had to disable MPCHC, H264/AVC (DXVA) and H264/AVC (ffmpeg)

Then, using W7, the codec by default which is inserted in the chain directshow is Microsoft DVT-DVD Video Decoder

http://img706.imageshack.us/img706/7093/screenshot001ls.png (http://imageshack.us/photo/my-images/706/screenshot001ls.png/)

[haruhiko_yamagata]

To resolve I had to disable MPCHC, H264/AVC (DXVA) and H264/AVC (ffmpeg)
Then, it's a bug of MPC-HC.

In file MPCVideoDecFilter.cpp in MPC-HC,
// We crash inside this function
// In swscale.c: Function 'simpleCopy'
// Line: 1961 - Buffer Overrun
// This might be ffmpeg fault or more likely mpchc is not reinitializing ffmpeg correctly during display change (moving mpchc window from display A to display B)
sws_scale(m_pSwsContext, m_pFrame->data, srcStride, 0, m_pAVCtx->height, dst, dstStride);
It's crashing in the code above. It seems to be a known issue.
Some versions of ffdshow are lucky and some are not. It's not a bug of ffdshow.:rolleyes:

[haruhiko_yamagata]

Here is an updated JAR that uses the H264 subtype. It does make a great improvement. However, if you try this with the previous code and clip I sent, about 13 seconds into the video you see what I refer to as the "melty" video. Where there is motion buy the images do not seem to properly update. Is there still something wrong with how I am sending video to ffdshow? Thanks.

http://dl.dropbox.com/u/37804952/dsj.jar
Thanks for the update. I can reproduce the "melt". I'll report you back if I find something.

[haruhiko_yamagata]

I also had 100% crashes with versions above 4307 (4314 crashed, I couldn't find compiled versions between these two). Looking a bit further I fiddled around with the settings and after checking and unchecking NV12 and RGB24 output color spaces all is now fine and dandy.

Maybe a problem with the retained configuration settings between versions/installations?
If the problem is not the same as DMD's, please provide all necessary information and files to reproduce.

[haruhiko_yamagata]

Haruhiko,
Is this something that can be looked into? I often get crashes loading the next file if the previous file hasn't played a sufficient amount before it starts to read the next one.
I'm not sure if I can fix it.
Would you post a bug report on SourceForge bug tracker so that we can remember it?

[Midzuki]

Yet another regression (or something):

r4326, decoder = VC-1, problem =

pixel-aspect-ratio ignored when renderer = EVR (under Windows XP)

[jmartinr]

If the problem is not the same as DMD's, please provide all necessary information and files to reproduce.

I can't reproduce anymore, sorry.

[Dstruct]

Yet another regression (or something):

r4326, decoder = VC-1, problem =

pixel-aspect-ratio ignored when renderer = EVR (under Windows XP)

Might be related to my bug report: http://forum.doom9.org/showthread.php?p=1545917#post1545917

This file gives incorrect display aspect ratio (1:1 Pixel) in WMP11 and MPC-HC via ffdshow rev4170 DXVA:

General
Format : AVI
Format/Info : Audio Video Interleave
File size : 1.29 GiB
Duration : 1h 59mn
Overall bit rate : 1 551 Kbps
Writing library : VirtualDub build 32839/release

Video
ID : 0
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : H264
Duration : 1h 59mn
Bit rate : 1 346 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.130
Stream size : 1.12 GiB (87%)

Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 1h 59mn
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 164 MiB (12%)
Alignment : Aligned on interleaves
Interleave, duration : 24 ms (0.60 video frame)
Interleave, preload duration : 504 ms


Proper display aspect ratio in Media Player Classic HC 1.5.3.3899 via internal MPC DVXA decoder!

[DMD]

Then, it's a bug of MPC-HC.

In file MPCVideoDecFilter.cpp in MPC-HC,
// We crash inside this function
// In swscale.c: Function 'simpleCopy'
// Line: 1961 - Buffer Overrun
// This might be ffmpeg fault or more likely mpchc is not reinitializing ffmpeg correctly during display change (moving mpchc window from display A to display B)
sws_scale(m_pSwsContext, m_pFrame->data, srcStride, 0, m_pAVCtx->height, dst, dstStride);
It's crashing in the code above. It seems to be a known issue.
Some versions of ffdshow are lucky and some are not. It's not a bug of ffdshow.:rolleyes:
Sometimes it is hard to find the cause of the problem depends on whether the player or ffdshow.

However, I repeat that with regression testing up to version rev4206_20111227,
all works regularly and there is no problem, then from this release onwards, the problems begin.
So I do not think that the whole responsibility be attributed to MPCHC.

greetings

[haruhiko_yamagata]

Sometimes it is hard to find the cause of the problem depends on whether the player or ffdshow.
That's why I compiled MPC-HC x64 and ascertain the cause.

However, I repeat that with regression testing up to version rev4206_20111227,
all works regularly and there is no problem, then from this release onwards, the problems begin.
So I do not think that the whole responsibility be attributed to MPCHC.

greetings
I still think it's 100% MPC-HC.

[haruhiko_yamagata]

@DMD,
In the code above, dstStride[0] is 1934. It should be 1920, because BITMAPINFOHEADER::biWidth in ffdshow's input media type is 1920. This is definitely a bug of MPC-HC.

[DMD]

Thank you for your inquiry on the issue,
at this point to point out also the question in the thread of MPCHC

THANKS

[haruhiko_yamagata]

Here is an updated JAR that uses the H264 subtype.
...
I have added some debug print. Here's the log.
frame_num increases one-by-one until it reaches 8. This is OK.
There's four slices for frame 8. Is this intended?
Next frame is frame 6. Is this correct?
I don't know how redundant pictures are managed. It may be correct and libavcodec just cannot decode such stream...
[5860] nal_unit_type 9 // AU delimitter
[5860] nal_unit_type 7 // SPS
[5860] nal_unit_type 8 // PPS
[5860] no frame! // no problem
[5860] nal_unit_type 9
[5860] nal_unit_type 6 // SEI
[5860] nal_unit_type 6
[5860] nal_unit_type 5 // IDR slice
[5860] frame_num 0
[5860] nal_unit_type 9
[5860] nal_unit_type 1 // slice of none IDR picture
[5860] frame_num 1
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 2
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 3
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 4
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 5
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 6
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 7
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 8
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 8
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 8
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 8
[5860] nal_unit_type 9
[5860] nal_unit_type 1
[5860] frame_num 6 // problematic?
[5860] Frame num gap 6 4
[5860] Increasing reorder buffer to 5

[kc7bfi]

frame_num increases one-by-one until it reaches 8. This is OK.
There's four slices for frame 8. Is this intended?
Next frame is frame 6. Is this correct?
I don't know how redundant pictures are managed. It may be correct and libavcodec just cannot decode such stream...
[/code]

Interesting. I would guess that the last frame 6 might also be a duplicate?! I'm a bit ignorant at this but is there a limit to the frame number (is it limited at 8)? It is multicast video so they might be out of order but not sure why they would be duplicated. I'll check into it further. Thanks, David

[haruhiko_yamagata]

Interesting. I would guess that the last frame 6 might also be a duplicate?! I'm a bit ignorant at this but is there a limit to the frame number (is it limited at 8)? It is multicast video so they might be out of order but not sure why they would be duplicated. I'll check into it further. Thanks, David
According to the spec,
because redundant_pic_cnt_present_flag in your PPS is zero, any duplicated slices should not exist.
Because log2_max_frame_num_minus4 in your SPS is 0, allowed frame_num is 0 to 15. This is handled correctly. No problem.

[kc7bfi]

According to the spec,
because redundant_pic_cnt_present_flag in your PPS is zero, any duplicated slices should not exist.
Because log2_max_frame_num_minus4 in your SPS is 0, allowed frame_num is 0 to 15. This is handled correctly. No problem.

Looks like the problem may be related to our PCAP replayer. I tried a live feed and it played fine but the PCAP Playback had problems. David

[andybkma]

Hi, where can I get the latest tryout builds? This page here (http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/) seems to have stopped providing the newest builds as the latest is from over 7 days ago....

[Midzuki]

2 andybkma:

r4332 @ http://xhmikosr.1f0.de/index.php?folder=ZmZkc2hvdw==

[andybkma]

2 andybkma:

r4332 @ http://xhmikosr.1f0.de/index.php?folder=ZmZkc2hvdw==

Thanks for the link. But am curious, the link you provided me with shows revision 4332 as a xhmikosr build yet here ( http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/?view=log ) it shows 4332 as a clisd2 build. Can you please explain why that is and what's the difference? Thanks much :)

[nevcairiel]

The revision (4332) is just the version from the SVN, who made the change and who builds it is unrelated.

[LigH]

Well, different people who build the software from the same source revision might use different compilers, enable or disable different compiling options, maybe include or exclude different libraries ... theoretically. In this case, there is probably very little difference.

[haruhiko_yamagata]

Yet another regression (or something):

r4326, decoder = VC-1, problem =

pixel-aspect-ratio ignored when renderer = EVR (under Windows XP)Would you send us a sample?

[Midzuki]

Would you send us a sample?

Nope :p

( just kidding :) )

http://forum.doom9.org/showthread.php?t=162221

[haruhiko_yamagata]

Nope :p

( just kidding :) )

http://forum.doom9.org/showthread.php?t=162221
The latest version works. clsid, did you fix it?:D

[haruhiko_yamagata]

I am making preparations for a new official release that is planned for later this month, once remaining regressions have been fixed.

Everyone please review this changelog for omissions and mistakes:
Let's go.

[Midzuki]

The latest version works. clsid, did you fix it?:D

What is your latest version? r4335 ???

FYI, r4332 is still b0rked, VC-1~wise -.-

Please upload and share your "latest" builds, then. :rolleyes:

[haruhiko_yamagata]

What is your latest version? r4335 ???

FYI, r4332 is still b0rked, VC-1~wise -.-

Please upload and share your "latest" builds, then. :rolleyes:
libavcodec works. I think you use "wmv9".

[betaking]

What is your latest version? r4335 ???

FYI, r4332 is still b0rked, VC-1~wise -.-

Please upload and share your "latest" builds, then. :rolleyes:

download my build at here
http://www.mediafire.com/?tao9vzs8ah5qodp

[Midzuki]

libavcodec works. I think you use "wmv9".

Please define what you mean by "it works".
The samples on my Skydrive folder are NOT resized to 960x540 by ffdshow when MPC-HC uses EVR.

[Midzuki]

download my build at here
http://www.mediafire.com/?tao9vzs8ah5qodp

:goodpost: AND :thanks: :thanks: :thanks:

@ Yamagata:

with r4335, wmv9 is okay, but libavcodec is still broken.

P.S.: Take a look at the source-code of LAV Video,
I'm sure nevcairiel won't mind :) :p :D

P.P.S.: With Solveig's Matroska Splitter, ffdshow sets the wrong aspect ratio through BOTH libavcodec and the DMO decoder :confused:

[Midzuki]

Hmmm, apparently it's a matter of *output color space* :rolleyes:

The DMO decoder works correctly with YV12.

The libav VC-1 decoder works correctly with NV12 and YUY2.

Hope this helps :helpful:

[haruhiko_yamagata]

Midzuki,
For which file, what is the correct AR?
zz-mcr-nsqr.mkv 16:9
zz-mcr-sqr.mkv 4:3
zz-ms-first.mkv 16:9
zz-ms-sekond.mkv 16:9
Is this correct?

[Midzuki]

Midzuki,
For which file, what is the correct AR?
zz-mcr-nsqr.mkv 16:9
zz-mcr-sqr.mkv 4:3
zz-ms-first.mkv 16:9
zz-ms-sekond.mkv 16:9
Is this correct?

Yes, yess, yesss, and yessss. :)

[haruhiko_yamagata]

libavcodec wrapper was somewhat buggy, I have fixed at rev 4336.
After that, zz-ms-sekond.mkv is 4:3. It's the same as LAV decoder.

The DMO wrapper depends on the container SAR. All (Haali, MPC, LAV) works fine for me. I don't know Solveig's.

[betaking]

To Midzuk download last build 4336 at here
http://www.mediafire.com/?s2x2nf9he71fs1c
PS:thanks haruhiko_yamagata fix it!

[Midzuki]

libavcodec wrapper was somewhat buggy, I have fixed at rev 4336.

Does that mean the *EVR++color~space* "feature" :rolleyes: :) has been fixed? :confused:

The DMO wrapper depends on the container SAR.

I wasn't aware of that, :thanks: for the important info.

All (Haali, MPC, LAV) works fine for me. I don't know Solveig's.

http://forum.doom9.org/showthread.php?t=154055&page=14

[Midzuki]

To Midzuki download last build 4336 at here
http://www.mediafire.com/?s2x2nf9he71fs1c
PS:thanks haruhiko_yamagata fix it!

Many big THANKS :thanks: again.

[Midzuki]

Does that mean the *EVR++color~space* "feature" :rolleyes: :) has been fixed? :confused:

Seemingly improbable. :rolleyes:

[haruhiko_yamagata]

Hmmm, apparently it's a matter of *output color space* :rolleyes:

Seemingly improbable. I can't reproduce.
EDIT
Check the settings of MPC-HC in vies->video frame. Make sure the video renderer is not broken.
Can you reproduce the problem on another PC?

[Midzuki]

EDIT
Check the settings of MPC-HC in vies->video frame.

No, thanks. :)

Make sure the video renderer is not broken.

How would I do that ??? :confused:

P.S.: Also, why both MPCVideoDec.ax and LAV Video apparently have no issues with EVR under Windows XP ?????

[haruhiko_yamagata]

Then please tell me the fully detailed way to reproduce. Please try it on another PC so that you can explain what is needed to reproduce.

[Midzuki]

WTF --- just for seeing "what happens" :rolleyes: ,

I un-ticked the checkbox
Set interlaced flag in output media type
and voilà, finally the libavcodec's VC-1 decoder stopped trolling :p

[haruhiko_yamagata]

I un-ticked the checkbox
Set interlaced flag in output media type
and voilà, finally the libavcodec's VC-1 decoder stopped trolling :p
Then it's a bug in your video driver. My nvidia 7900GS works fine. Thanks for the report anyway.

Please report the bug to the maker of your video driver. It would help many people.

[haruhiko_yamagata]

Here's a build (http://ffdshow-tryout.sourceforge.net/doom9/ffdshow_rev4345_20120228_branch.exe) from the parser branch. It uses AVCodecParser and parses access units for H.264 and MPEG-1 and 2.
It was easier than I expected. I think the branch can be merged before next release.
Some broken frames at the start of MPEG-2 playback has gone away.

Additionally it can decode H.264 stream erroneously flagged MPEG-2　(just a harmless prank). libavcodec must be used for MPEG-2 for the trick to work.

[Midzuki]

Then it's a bug in your video driver. My nvidia 7900GS works fine. Thanks for the report anyway.

Again, many :thanks: for the constant attention. :)

Please report the bug to the maker of your video driver. It would help many people.

Unnecessary. I'm pretty sure they will say to me,

"Go buy an up-to-date computer and an up-to-date video card!"

And this time they will be right =^.^=

[nevcairiel]

How can it be a video driver bug if the problem only occurs with ffdshow, and not with other decoders? :confused:
LAV Video will also set interlaced flags in the output type, yet AR still works.

[haruhiko_yamagata]

How can it be a video driver bug if the problem only occurs with ffdshow, and not with other decoders? :confused:
LAV Video will also set interlaced flags in the output type, yet AR still works.
ffdshow also works here. Is ffdshow failing for you?
I don't know if Midzuki has tested the same output color space with LAV.

[Midzuki]

...
I don't know if Midzuki has tested the same output color space with LAV.

Midzuki :uglylol:s http://forum.videohelp.com/attachments/2671-1279232225/uglylol.gif himself. :p :D

Yes you are right,
if I set LAV Video to "Force Deinterlacing" and limit the output color space to "YV12",

then LAV Video behaves as badly as ffdshow :scared:

Time for a major hardware upgrade definitely, no one will want to write new drivers for obsolete video cards :o