ffdshow tryouts project: Discussion & Development

[kc7bfi]

In h264.c, prior to calling ff_h264_decode_seq_parameter_set, the bit_length is set as


bit_length = !dst_length ? 0
: (8 * dst_length -
decode_rbsp_trailing(h, ptr + dst_length - 1));


but in h264_parser.c, bit_length is passes as just


init_get_bits(&h->s.gb, ptr, 8*dst_length);


Is this correct? Or should 8*dst_length be replace with a similar calculation as in h264.c?

What I am seeing is a bunch of the following errors in DebugView that seem to be caused by the use of 8*dst_length not the adjusted length as used in h264.c:


[5652] Current profile doesn't provide more RBSP data in PPS, skipping


David

[nevcairiel]

You should submit these questions to the developers of ffmpeg or libav, ffdshows just uses the avcodec decoding library, the authors of that code are not part of ffdshow.

[ryrynz]

To anyone using Avisynth and ffdshow, I found that XhmikosR's ffdshow builds caused the player (most times) to freeze up as it attempted to play a new file after or during playback.
Switching to XvidVideo.ru's ICL11 builds or CLSID's MSVC2010 builds fixed this, this has been a bit of a long standing issue for me (I've nearly always used XhmikosR's builds) which I just put down to general MT instability.

[hello_hello]

Not sure if this is the right place to be asking......

I've noticed at times when ffdshow (rev 4475) is decoding AC3 audio there can be a considerable volume reduction (say relative to using MPC-HC's internal decoder) so when it happened today I did a little investigating. Seems some AC3 audio with dialog normalization is the cause (removing it with eac3to fixes the problem), but only with some AC3 audio, and only when liba52 is selected as the AC3 decoder (which I think is the default). Playing the occasional AC3 audio containing dialog normalization (-27db according to eac3to) I can switch between liba52 and libavcodec and hear a substantial volume reduction while using the former, but some/most of the time switching decoders makes no difference even though eac3to still reports the audio as having dialog normalization (-27db).

I tried a file containing "problem" AC3 using smplayer as it lets you choose the audio decoder, and with liba52 decoding there was no volume reduction compared to using FFmpeg AC3 and the volume was the same as when using libavcodec with ffdshow.

So while the easy solution is to switch to libavcodec I'm just wondering if dialog normalization should always be ignored by ffdshow or whether it's never ignored and I'm missing the obvious or I've found a bug etc. I can upload a sample if need be.

Thanks.

[nevcairiel]

There is really no advantage to liba52 anymore, so before any big things are done to make it ignore the dialnorm, it should just be replaced for good by avcodec. :)

[oddball]

I have the frame drops/stuttering issue when jitter correction is enabled. This occurs not only on DTS though. It happens on stereo AAC etc. Disabling it fixes it. I have tried various versions of ffdshow right up to the latest build. I am using the latest LAV filters and splitter and MPC-HC and outputting using latest MadVR. If I switch to LAV audio decoder I get no frame drops. Same if I disable jitter correction in ffdshow.

From what others have said it was a DTS issue but this occurs on ANY audio not just DTS. My display is synced at 23,976FPS on an Nvidia GTX560Ti outputting HDMI to the HDTV and SPDIF for audio (old amp). BTW the frame drops and stuttering always occurs at the same places. The files are perfect (No corruption).

Any ideas?

[leeperry]

To anyone using Avisynth and ffdshow, I found that XhmikosR's ffdshow builds caused the player (most times) to freeze up as it attempted to play a new file after or during playback.
Switching to XvidVideo.ru's ICL11 builds or CLSID's MSVC2010 builds fixed this
yep, PotPlayer freezes at shutdown with his ICL12 builds on my system, the xvideo ICL12 builds are fine....too bad they're not updated very frequently.

[ryrynz]

Forgot to make that clear, yes XhmikosR's ICL12 builds. I'll pass it on to him next time I swing by IRC, unless someone else wishes to do so.. I wonder what the cause is?

[cyberbeing]

madVR crash when activating FFDShow's resize filter during playback with horizontal size set to 4096.This looks like a bug in ffdshow to me. Basically ffdshow is sending a buffer which is too small to actually contain a frame in the size it says it's sending.
Low priority since it only crashes madVR and there is no point in resizing to 4K at present, but I guess FFDShow uses too small of a buffer when the resize filter is first activated. It only crashes madVR when the resize filter is activated in the middle of playback, no crash in madVR occurs if the resize filter is already activated before playback begins.

[ney2x]

Is ffdshow reached its final stage or end of life? The last nightly build is rev4487 (http://xhmikosr.1f0.de/_old/ffdshow/) and that revision is freezing if using Avisynth, whatever build I used.

[ryrynz]

Haruhiko isn't developing ffdshow ATM, he may return. To fix your Avisynth issues I recommend just running an earlier build, there's really not much reason to be running the latest as the changes have been minor. Personally I'm using Xvidvideo's 4479 release without issues.

[naoan]

Avisynth also works fine with 4486 clsid build.

[wanezhiling]

I think so, LAV is the successor.

[ryrynz]

Definitely, I hope Haruhiko or someone else can port over / clean up some of the code to LAV or a LAV fork.

[naoan]

Definitely, I hope Haruhiko or someone else can port over / clean up some of the code to LAV or a LAV fork.

I thought nevcairiel doesn't intend to make LAV into a post processor.

[ryrynz]

He's not against it someone adding it, he's thought about going through the ffdshow code but it's not very tidy and it would be a lot of work.
I think Haruhiko's time would be better spent adding this similar functionality to LAV rather than continuing on ffdshow.

[kc7bfi]

I have a video that runs fine for a while then starts showing multiple cases of the error "Non-key discontinuity - wait for keyframe" in the debug viewer. Any ideas what this error means or shat might cause it?
Thanks, David

[kc7bfi]

I have a video that runs fine for a while then starts showing multiple cases of the error "Non-key discontinuity - wait for keyframe" in the debug viewer. Any ideas what this error means or shat might cause it?
Thanks, David

I forgot to mention that my encoder is sending video at 20fps and when this condition appears it looks like ffdshow is reporting around 3fps.
Thanks, David

[LigH]

The more details we know about the technical properties of this video, the better; furthermore, your request is a little confusing, ffdshow is a decoder, so what encoder are you referring to – is ffdshow used as decoder in an AviSynth script with DirectShowSource()?

"Non-key" frames (inter-frames, e.g. delta-frames in lossless AVIs, P- or B-frames in MPEG-like or similar complex video) are frames which depend on previously decoded keyframes (intra-frames = I-frames in MPEG-like video) and contain only differences to this buffered keyframe.

A "discontinuity" means probably that frames appear in an unexpected order, causing the decoder getting confused if it would be able to output correctly decoded video, so it waits for the next keyframe to continue decoding from a "safe place", to avoid crappy video output and probably even decoding errors, up to a possibly crash. Discontinuities are often a sign for corrupted video. This happens sometimes in video from "unsafe download sources" ... (I don't want to say it more specific). But there are more possible reasons, e.g. carelessly joined cut clips without overhauled timestamps.

[kc7bfi]

so what encoder are you referring

The video is coming from a live Axis 241S encoder. Sorry to be unclear. Does ffdshow set this flag or is it set by some source filter prior to making it into the ffdshow DirectShow filter?

[movmasty]

Anyone is aware of this?

Since i installed 4486_20120825_clsid Vdub keeps crashing with most(not all)vids when compressing in HuffyUV,
This doesnt happen when using the standalone HuffyUV codec.

An out-of-bounds memory access (access violation) occurred in module 'ffmpeg'...
...reading address FFFFFFFF...
...while compressing frame 0 from 07070050 to 01e5afb8 using codec "ffdshow Video Codec" (w32videocodecpack.cpp:787)...
...while running thread "Processing" (thread.cpp:179).


The bug is present, as i tested, (since)in build 4453_20120521

And is NOT present (until)in build 4052_20111120.
But dont know among these two.
My OS on this pc is XP sp2

Also, is optimal to fast recompress into xvid or h264 when the source is in YUY2 and not in YV12?

[clsid]

Since 4453, does that mean 4447 was still OK?
http://sourceforge.net/projects/ffdshow-tryout/files/SVN%20builds%20by%20clsid/generic%20builds/

[movmasty]

Since 4453, does that mean 4447 was still OK?
http://sourceforge.net/projects/ffdshow-tryout/files/SVN%20builds%20by%20clsid/generic%20builds/
4454 has the bug
4052 doesnt
i tested those, both versions are before of a size change.
i dont know the point in between when it appear, and cant test all the builds,
since 4052 is 19 months newer than 3356 that i used before, im happy for now.

_______________________________
http://www.videohelp.com/tools/ffdshow/old-versions#download

[romulous]

I think this may be a bug.

1. Using Zoom Player as the media player, open Zoom, change the subtitle renderer to FFDSHOW.

2. Find a test file that has IDX + SUB subtitles.

3. Have all three files (video file + IDX + SUB) in the same folder, all with the same filename.

4. Open the video file with Zoom Player.

5. Now, if you check the Stream Selection menu, you will see three entries: the IDX file, the SUB file, and 'Disabled'.

6. That's it - no subtitles are shown, even if you cycle through the entries.

This is with ffdshow 1.2.4453 (I assume this is rev 4453), which is the latest available via Zoom Player's Install Center.

[Snowknight26]

Please add ccc.exe to the default list of programs that ffdshow shouldn't be used in.

[LigH]

The Catalyst Control Center?

[ryrynz]

Yup that's what he means.

[THX-UltraII]

I m going to use a Avisynth script called FineSharp. So I will need ffdshow RAW video 'all supported'. But I m already using LAV Video decoder.

It is important to tell the exact 'chain' I m using now:

- Media Player Classic with madVR as output renderer with output setting in madVR PC Levels (0-255).

- using LAV video decoder with all the 'Output Formats' checked and 'RGB Output Levels' set to 'Untouched (as input)'

- HDMI Color Space Input of my display device: RGB

- HDMI Dynamic Range Input of my display device: 0-255




ffdshow has quite some output settings. First one is the Primary Output Color Space. I can select Auto, YUV (YV12/YUY2/NV12) or RGB here. What do you think I have to choose here when I don t want ffdshow to do a extra video conversion?

Next there are the boxes that can be checked:
4:2:0 YUV YV12 8-bit
4:2:0 YUV NV12 8-bit
4:2:0 YUV P010 10-bit
4:2:0 YUV P016 16-bit
4:2:2 YUV YUY2 8-bit
4:2:2 YUV YUVY 8-bit
4:2:2 YUV P210 10-bit
4:2:2 YUV P216 16-bit
4:4:4 YUV AYUV 8-bit
4:4:4 YUV Y416 16-bit
RGB32 8-bit
RGB24 8-bit

Next there s the setting Set interlaced flag in output media type which is checked by default. Should I leave this checked? More information about this settings:
- Sends interlacing related information obtained from the input stream or ffdshow's internal decoders to the next filter.
- Some filters (like video renderers) will use this information to deinterlace the video if necessary.
- This is just for informing the downstream filters - the actual result will depend purely on the implementation of these filters.
- DVDs may be flagged as interlaced, but in most cases they were originally film (progressive) and just soft telecined. For such video, it is recommended to disable this setting.

And there also the TAB in ffdshow called RGB Conversion which has quite a few settings:
- YCbCr specification:
I can choose 'Auto', 'ITU-R BT.601' or 'BT.709' here. Which one should I use?

- High quality YV12 to RGB conversion:
This checkbox will instruct ffdshow to use a high quality conversion method. The conversion is done in 11-bit or higher and its performance can be improved significantly with multi-core CPUs. This feature requires a SSE2-capable CPU at the minimum.

Should I check this box?

- Dithering:
Dithering is an option to maintain the source's full visual quality when doing YCbCr → RGB conversion. Without dithering, RGB conversion can result in added banding. With “High quality YV12 to RGB conversion” enabled, ffdshow calculates in 11-bit or higher. If this option is checked, the result is dithered otherwise rounded to 8-bit. This increases RGB conversion's CPU usage by about 6%.

Should I check this box?

- Input Levels:
Auto
Standard (Y: 16-235, CbCr: 16-240)
Full Range (Y: 0-255, CbCr: 1-255)

Which one should I use?

- Output Levels:
RGB 0-255
RGB 16-235


How do I config ffdshow when looking at the chain I m using already and when I want ffdshow to do NO VIDEO CONVERSION at all so it does not become an extra 'chain'?

thxz!

[kc7bfi]

I have a Pelco camera that does not play with the latest ffdshow version. I seem to have narrowed it down to an issue in the h264.c file in the ff_h264_decode_nal function. The following function is defined:

#define STARTCODE_TEST \
if (i + 2 < length && src[i + 1] == 0 && src[i + 2] <= 3) { \
if (src[i + 2] != 3) { \
/* startcode, so we must be past the end */ \
length = i; \
} \
break; \
}

However, it seems to me that the start code will either end with a 1 or a 3. When I change this function to the following then my video plays.

#define STARTCODE_TEST \
if (i + 2 < length && src[i + 1] == 0 && (src[i + 2] == 1 || src[i + 2] == 3)) { \
if (src[i + 2] != 3) { \
/* startcode, so we must be past the end */ \
length = i; \
} \
break; \
}

Does this make since?
Here is the patch file.

Index: ffmpeg/libavcodec/h264.c
===================================================================
--- ffmpeg/libavcodec/h264.c (revision 4489)
+++ ffmpeg/libavcodec/h264.c (working copy)
@@ -178,7 +178,7 @@
length--;

#define STARTCODE_TEST \
- if (i + 2 < length && src[i + 1] == 0 && src[i + 2] <= 3) { \
+ if (i + 2 < length && src[i + 1] == 0 && (src[i + 2] == 1 || src[i + 2] == 3)) { \
if (src[i + 2] != 3) { \
/* startcode, so we must be past the end */ \
length = i; \

[nevcairiel]

ffdshow just uses these decoding libraries, no-one from this project wrote the code, maintains the code, or even knows the code properly.
You should direct your questions at the ffmpeg mailing list, or the ffmpeg trac.

[movmasty]

Anyone is aware of this?
Since i installed 4486_20120825_clsid Vdub keeps crashing with most(not all)vids when compressing in HuffyUV,
This doesnt happen when using the standalone HuffyUV codec.
An out-of-bounds memory access (access violation) occurred in module 'ffmpeg'...
...reading address FFFFFFFF...
...while compressing frame 0 from 07070050 to 01e5afb8 using codec "ffdshow Video Codec" (w32videocodecpack.cpp:787)...
...while running thread "Processing" (thread.cpp:179).
The bug is present, as i tested, (since)in build 4453_20120521

And is NOT present (until)in build 4052_20111120.
But dont know among these two.
My OS on this pc is XP sp2

Also, is optimal to fast recompress into xvid or h264 when the source is in YUY2 and not in YV12?
Since i installed 4052_20111120 sometime my system crashes when starting mpclassic
so i went back to version 20100410....

[clsid]

You should not use such ancient versions. Either use the official HuffYUV codec or narrow down the problem to a specific version by finding the last working version. That is your only chance of getting this fixed, because there are no developers available that want to spend a of of time debugging this problem. In fact, there are not really any developers available at all.

You can find lots of versions here:
http://sourceforge.net/projects/ffdshow-tryout/files/SVN%20builds%20by%20clsid/generic%20builds/

Reduce the start of the problem to a small range of versions, and I will take a stab at fixing it.

[turbojet]

Is it possible to detect the screen resolution of the display the video is played on for setting up profiles of extended displays? I can only get the main display's resolution now.

[Px]

From looking at source code it seems that described in this article mistakes - http://www.viva64.com/en/b/0161/ didn't fixed yet, developers didn't get message from article's author or ignore it?

[nevcairiel]

From looking at source code it seems that described in this article mistakes - http://www.viva64.com/en/b/0161/ didn't fixed yet, developers didn't get message from article's author or ignore it?

There is noone working on ffdshow that would understand these problems =p

I have always wondered about the various "problems" people reported with code mis-compiling in ffdshow, but i never bothered to look at it - i just blindly assumed the code was just bad. :)

[clsid]

Haruhiko must have overlooked those typos in his code. I have committed a fix.

[mark0077]

guys, I'm using mpc-hc, lav splitter and decoders, along with madVR. I use ffdshow raw decoder to load up avisynth scripts. However I notice one issue. ffdshow seems to convert yv12 input, to nv12 output, even though I have all of the output checkboxes enabled. I consider this an unnecessary conversion (even though its lossless). Is this a mistake in the ffdshow logic? For the moment I have changed my "Primary output color space: " to "YV12" instead of default.

I'm using clsid's 32bit ffdshow rev 4489

[nevcairiel]

NV12 is preferred over YV12 because of better renderer/hardware support.

[romulous]

Possible bug report for PGS subtitles. When playing a MKV containing PGS/zLib type subtitles and using FFDShow, Zoom Player crashes either when first subs are shown or when forwarding to a point with subs. Blight (Zoom's dev) believes it is a bug in ffdshow, not Zoom.

Sample provided by the user who reported the issue (200MB):
https://dl.dropbox.com/u/105555957/PGS-zLib-crash.mkv

Zoom will play the file fine, the crash is at about the 01:18 mark, when the subtitles kick in.

[clsid]

Use xy-VSFilter (DirectVobSub) instead.

ffdshow is dead.

[wanezhiling]

Dead, right.

It marks the end of an era.:)

[romulous]

@clsid - Thanks, I sort of guessed that would be the response, but I didn't think there was any harm in reporting it just in case there was still some life left in ffdshow.

@wanezhiling: Indeed, it does mark the end of an era.

[hmpt]

mark it。.. 。.. 。

[ryrynz]

It's as dead as it's ever been in the last year or two. Haruhiko may still return to fix a few things.. but that's all that's going to happen IMO.
I would think his time would be better spent providing similar functionality for LAV Filters.

[jmac698]

Wow, I'm out of date but that's news to me. What should I install to serve/play files now?

[oddball]

It's so disappointing there is no subtitle renderer as nice looking as the one built into MPC-HC. Ideally I would love my subtitles rendered at desktop res. However the subtitle renderer in MPC-HC is seriously bugged for anything but basic subs. Any subs with special characteristics like those .ssa subs found in some anime is bugged/broken. ffdshow does a fairly decent job of rendering subs. DirectVobSub is best but the quality of the rendered fonts is way below that of MPC-HC. There is no option to change the resolution that I know of. Also you lose the quick disabling of subs using the keyboard command in MPC-HC.

I wish DirectVobSub had high definition rendering options.

[madshi]

@oddball, xy-vsfilter + madVR will soon offer a high-quality replacement for the MPC-HC internal subtitle renderer.

[LigH]

@ jmac698:

Well, it's not like the older ffdshow builds don't work anymore at all... you can continue using them where they are useful. The last build I found was rev. 4494 by clsid on SourceForge (http://sourceforge.net/projects/ffdshow-tryout/files/SVN%20builds%20by%20clsid/); XhmikosR (http://xhmikosr.1f0.de/_old/ffdshow/) stopped a bit earlier with build 4488.

If there is a bug which prevents you from using ffdshow for s apecific format, use LAV Filters (http://code.google.com/p/lavfilters/) instead.

[oddball]

@oddball, xy-vsfilter + madVR will soon offer a high-quality replacement for the MPC-HC internal subtitle renderer.

I 'quivver' with antici....




















....pation.
:thanks:

[kc7bfi]

I am having a problem with video quality for a specific H.264 live encoder. My program reads UDP video and buffers then video to send it to the ffdshow DirectShow filters. If I buffer 500ms of video everything works fine. Otherwise I get poor video quality. I also get the following logs from ffmeg:


[8288] slice:1 T mb:0 P fix pps:0 frame:23 poc:65582/2147483647/65582 ref:1/1 qp:24 loop:1:0:0 weight:0
[8288] slice:1 B mb:0 P fix pps:0 frame:23 poc:65582/65583/65582 ref:1/1 qp:24 loop:1:0:0 weight:0
[8288] slice:1 T mb:0 P fix pps:0 frame:24 poc:65584/2147483647/65584 ref:1/1 qp:24 loop:1:0:0 weight:0
[8288] slice:1 T mb:0 P fix pps:0 frame:24 poc:65584/2147483647/65584 ref:1/1 qp:24 loop:1:0:0 weight:0
[8288] mmco: unref short failure
[8288] mmco: unref short failure


What is interesting is it appears that the last two frames appear to be duplicated (same frame number, same from/to/current poc).

My basic questions is, what happens when the ffdshow filter finds an empty buffer on input? I am assuming that samples are "pulled" by the ffdshow filter. I have tried to find this in the code but cannot seem to fine where it is.

I hope this is understandable... David