Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mattkhan]

I have a Hauppauge Colossus 2 configured in jriver as a capture with audio routed via a zone configured for low latency audio processing. Audio from the source seems way ahead of the video. Adjusting the AV sync times appears to have no effect at all, it remains way ahead irrespective of what value (large positive or negative or anything in-between) I choose.

Any ideas how to fix?

[mattkhan]

I have reviewed various settings for the hauppauge device via the direct show filter options & verified that the card itself behaves normally via the hauppauge capture app, audio sync is rock solid in there. In contrast, in jriver it is quite random. It seems to drift into sync every now and again but is mostly just miles off.

Things I've tried that make no difference;

Switching between ROHQ and standard
removing any DSP
twiddling audio buffers
av sync correction

I've also reviewed gpu & cpu load and there are no issues, the box is not loaded at all.

Any ideas? The fact it works in the hauppauge capture app (which seems a pretty vanilla app) makes it seem pretty unambiguously a jriver issue.

[mattkhan]

Note that when using the hauppauge capture app to display video, audio is going out to windows default audio device which is then going back into my jriver WDM zone for playback.

This is the same zone that plays back the TV channel.

[mattkhan]

log output covering a start/stop of playback

I notice it includes lines like the following but I don't know if that is normal or a symptom of the problem I am reporting

Code: [Select]

0016485: 11476: Playback: CBitrateMonitor::UpdateBitrate: Accum audio bytes 0, video bytes 0, time period 1000.6953835805823019 ms, bitrate 0
0016766: 7572: Playback: COutputPluginAudioRenderer::DoRenderSample: Correcting drift by 478.487 ms
0016860: 7572: Playback: COutputPluginAudioRenderer::DoRenderSample: Correcting drift by 239.365 ms
0017156: 7572: Playback: COutputPluginAudioRenderer::DoRenderSample: Correcting drift by 107.022 ms
0017485: 11476: Playback: CBitrateMonitor::UpdateBitrate: Accum audio bytes 0, video bytes 0, time period 1000.903657222557058 ms, bitrate 0
0017641: 10548: Playback: CVideoRefreshRateThread::Thread: Using low-precision refresh monitoring
0017766: 10100: TV: CTVRecordingManager::Process: Start
0017766: 10100: TV: CTVRecordingDatabase::GetActions: returning 0 actions
0017766: 10100: TV: CTVRecordingManager::Process: Finish (0 ms)
0018000: 7572: Playback: COutputPluginAudioRenderer::DoRenderSample: Correcting drift by -254.028 ms
0018063: 7572: Playback: COutputPluginAudioRenderer::DoRenderSample: Correcting drift by -227.983 ms
0018063: 7572: Playback: COutputPluginAudioRenderer::DoRenderSample: Correcting drift by -224.124 ms
0018219: 7572: Playback: COutputPluginAudioRenderer::DoRenderSample: Correcting drift by -191.817 ms
0018485: 11476: Playback: CBitrateMonitor::UpdateBitrate: Accum audio bytes 0, video bytes 0, time period 1000.7366399714106819 ms, bitrate 0
0018938: 7572: Playback: COutputPluginAudioRenderer::DoRenderSample: Correcting drift by 205.208 ms


[Yaobing]

How about turning time-shifting on or off? 

Can you use DirectSound audio output?

[mattkhan]

The behaviour is the same whether I use time shifting or not.

What do you mean by directsound? Use a windows audio device?

[mattkhan]

same behaviour with DirectSound audio output

FWIW (probably not much) I have had this card in the machine for a while and it did used to work in jriver without any obvious issues that I recall. i don't think I've really used it since around spring 2016 though so that probably means late in the MC21 cycle.

[mattkhan]

I've pasted the filter graph in below in case this is useful

one thing I noticed is that the crossbar property page has an option "link related streams" which is always unchecked, google fails to tell me what this does and if I check it then restart playback, it goes back to unchecked.

Code: [Select]

Filter Graph Info (TV graph):

    Filter 'JRiver Audio Renderer'
        CLSID: {A4002F8E-510F-442C-8AD3-F9C7B23FB394}
        Host:
        Input Pin 'In'
            Connected to pin 'Output' of filter 'LAV Audio Decoder (auto-configured)'
            Major type MEDIATYPE_Audio  Sub type MEDIASUBTYPE_IEEE_FLOAT, Format type FORMAT_WaveFormatEx

    Filter 'madVR'
        CLSID: {E1A8B82A-32CE-4B0D-BE0D-AA68C772E423}
        Host: C:\Users\Matt\AppData\Roaming\J River\Media Center 23\Plugins\madvr\madVR64.ax
        Input Pin 'Input'
            Connected to pin 'Output' of filter 'LAV Video Decoder (auto-configured)'
            Major type MEDIATYPE_Video  Sub type MEDIASUBTYPE_NV12, Format type FORMAT_VideoInfo2

    Filter 'PSI Parser'
        CLSID: {40EB2203-4AD5-4DF3-B527-775D237CBF80}
        Host:
        Input Pin 'Input'
            Connected to pin 'PSI' of filter 'MPEG-2 Demultiplexer'
            Major type MEDIATYPE_MPEG2_SECTIONS  Sub type TIME_FORMAT_NONE, Format type TIME_FORMAT_NONE

    Filter 'LAV Audio Decoder (auto-configured)'
        CLSID: {E8E73B6B-4CB3-44A4-BE99-4F7BCB96E491}
        Host: C:\Users\Matt\AppData\Roaming\J River\Media Center 23\Plugins\lav64\LAVAudio.ax
        Input Pin 'Input'
            Connected to pin 'Audio Out' of filter 'MPEG-2 Demultiplexer'
            Major type MEDIATYPE_Audio  Sub type Unknown GUID Name: {000000FF-0000-0010-8000-00AA00389B71}, Format type FORMAT_WaveFormatEx
        Output Pin 'Output'
            Connected to pin 'In' of filter 'JRiver Audio Renderer'
            Major type MEDIATYPE_Audio  Sub type MEDIASUBTYPE_IEEE_FLOAT, Format type FORMAT_WaveFormatEx

    Filter 'LAV Video Decoder (auto-configured)'
        CLSID: {EE30215D-164F-4A92-A4EB-9D4C13390F9F}
        Host: C:\Users\Matt\AppData\Roaming\J River\Media Center 23\Plugins\lav64\LAVVideo.ax
        Input Pin 'Input'
            Connected to pin 'Video Out' of filter 'MPEG-2 Demultiplexer'
            Major type MEDIATYPE_Video  Sub type MEDIASUBTYPE_H264, Format type FORMAT_VideoInfo2
        Output Pin 'Output'
            Connected to pin 'Input' of filter 'madVR'
            Major type MEDIATYPE_Video  Sub type MEDIASUBTYPE_NV12, Format type FORMAT_VideoInfo2

    Filter 'MPEG-2 Demultiplexer'
        CLSID: {AFB6C280-2C41-11D3-8A60-0000F81E0E4A}
        Host: c:\windows\system32\mpg2splt.ax
        Input Pin 'MPEG-2 Stream'
            Connected to pin 'MPEG' of filter 'Hauppauge Siena Encoder'
            Major type MEDIATYPE_Stream  Sub type MEDIASUBTYPE_MPEG2_TRANSPORT, Format type FORMAT_None
        Output Pin 'Audio Out'
            Connected to pin 'Input' of filter 'LAV Audio Decoder (auto-configured)'
            Major type MEDIATYPE_Audio  Sub type Unknown GUID Name: {000000FF-0000-0010-8000-00AA00389B71}, Format type FORMAT_WaveFormatEx
        Output Pin 'PSI'
            Connected to pin 'Input' of filter 'PSI Parser'
            Major type MEDIATYPE_MPEG2_SECTIONS  Sub type TIME_FORMAT_NONE, Format type TIME_FORMAT_NONE
        Output Pin 'Video Out'
            Connected to pin 'Input' of filter 'LAV Video Decoder (auto-configured)'
            Major type MEDIATYPE_Video  Sub type MEDIASUBTYPE_H264, Format type FORMAT_VideoInfo2

    Filter 'Hauppauge Siena Encoder'
        CLSID: {17CCA71B-ECD7-11D0-B908-00A0C9223196}
        Host: c:\windows\system32\ksproxy.ax
        Input Pin '656'
            Connected to pin '656' of filter 'Hauppauge Siena Video Capture 2D2E1057EC5BFF13'
            Major type MEDIATYPE_Video  Sub type Unknown GUID Name: {32574348-005B-4504-99F8-90826C806657}, Format type FORMAT_VideoInfo
        Output Pin 'MPEG'
            Connected to pin 'MPEG-2 Stream' of filter 'MPEG-2 Demultiplexer'
            Major type MEDIATYPE_Stream  Sub type MEDIASUBTYPE_MPEG2_TRANSPORT, Format type FORMAT_None

    Filter 'Hauppauge Siena Video Capture 2D2E1057EC5BFF13'
        CLSID: {17CCA71B-ECD7-11D0-B908-00A0C9223196}
        Host: c:\windows\system32\ksproxy.ax
        Input Pin 'Analog Video In'
            Connected to pin '0: Video Decoder Out' of filter 'Hauppauge Siena Crossbar'
            Major type MEDIATYPE_AnalogVideo  Sub type MEDIASUBTYPE_None, Format type FORMAT_AnalogVideo
        Input Pin 'Analog Audio In'
            Connected to pin '1: Audio Decoder Out' of filter 'Hauppauge Siena Crossbar'
            Major type MEDIATYPE_AnalogAudio  Sub type MEDIASUBTYPE_None, Format type FORMAT_None
        Output Pin '656'
            Connected to pin '656' of filter 'Hauppauge Siena Encoder'
            Major type MEDIATYPE_Video  Sub type Unknown GUID Name: {32574348-005B-4504-99F8-90826C806657}, Format type FORMAT_VideoInfo

    Filter 'Hauppauge Siena Crossbar'
        CLSID: {71F96460-78F3-11D0-A18C-00A0C9118956}
        Host: ksxbar.ax
        Input Pin '0: Video SerialDigital In'
        Input Pin '1: Video YRYBY In'
        Input Pin '2: Video Composite In'
        Input Pin '3: Video SVideo In'
        Input Pin '4: Audio AESDigital In'
        Input Pin '5: Audio Line In'
        Input Pin '6: Audio SPDIFDigital In'
        Input Pin '7: Video YRYBY In'
        Input Pin '8: Video Composite In'
        Input Pin '9: Video SVideo In'
        Input Pin '10: Audio Line In'
        Input Pin '11: Audio AUX In'
        Input Pin '12: Audio AUX In'
        Output Pin '0: Video Decoder Out'
            Connected to pin 'Analog Video In' of filter 'Hauppauge Siena Video Capture 2D2E1057EC5BFF13'
            Major type MEDIATYPE_AnalogVideo  Sub type MEDIASUBTYPE_None, Format type FORMAT_AnalogVideo
        Output Pin '1: Audio Decoder Out'
            Connected to pin 'Analog Audio In' of filter 'Hauppauge Siena Video Capture 2D2E1057EC5BFF13'
            Major type MEDIATYPE_AnalogAudio  Sub type MEDIASUBTYPE_None, Format type FORMAT_None


[mattkhan]

I've been using the 64bit build so I installed the 32bit version and that shows the same problem.

[mattkhan]

re the settings sticking, I found https://yabb.jriver.com/interact/index.php/topic,85322.msg582991.html#msg582991 which mentions some reg entries so attaching those too

[mattkhan]

that setting doesn't stick if you go in via the "configure tuner" option either, I think it's affects behaviour when changing channels though so I guess it is not relevant to this situation

[Yaobing]

The "link related stream" probably does not matter.  It is something that the device vendor did.  Nowadays we do not even need to run that property page.  MC always sets audio and video streams at the start up time.  The crossbar properties matter only in as far as which audio and video lines are being used.  As long as you hear sound and see video images, I think it can not be wrong.

As for AV sync, there is not much tweaking available.  In MC Options for Video, there are "VideoClock" and "Hardware Acceleration".

[Yaobing]

I hooked up my old HD PVR, and found no problem in AV sync.

[mattkhan]

a mystery then

is there an hdmi capture card that is known to be reliable in MC?

[Yaobing]

I am not aware of any.

[Yaobing]

In Colossus property pages, is there anything that let you tweak video compression and see if the device is outputting the correct video (H264)?

[mojave]

A friend that uses the Colossus 2 all the time for viewing sports from his DirectTV box and he hasn't complained of any issues. He usually calls me right a way if there is a problem. I think he is still on MC22. I'll be at his house this weekend so can test it then.

Did you try switching between ts or jtv formats? If you save the time shifted file and playback do you still have an issue?

[mattkhan]

Did you try switching between ts or jtv formats? If you save the time shifted file and playback do you still have an issue?

on an initial couple of tests (literally 2 1 min files), switching to ts and playing back the saved file plays back without any sync issue.

[mattkhan]

OK I'm now confident that

- time shifting with a ts recording format results in accurate sync
- av sync correction is actually working
- live playback does not play in sync

this is at least a functioning solution, bit annoyingly user unfriendly though

I wonder if there is any mobo config that can be tweaked?

[mattkhan]

This seems quite consistent over a few days, the recorded stream is in sync but live playback is not. Without knowing how that stream hits the disk and is then played vs how it is played live, I don't really understand how that is possible.

Any views on which component in the chain could be to blame here? I don't understand how it could be the device when the stream can be written to disk ok.

[JimH]

Antivirus?

[muzicman0]

When you watch live, you are actually watching the .jtv version of the capture, not the .ts version.  perhaps there is an issue with .jtv somehow.

[mattkhan]

Antivirus?

it is disabled

When you watch live, you are actually watching the .jtv version of the capture, not the .ts version.  perhaps there is an issue with .jtv somehow.

interesting, I'll test recording in jtv format again to check that the same thing happens there.

[JimH]

Uninstall the antivirus if possible.  It's the only way to be certain that it's not causing trouble.  Disabling sometimes doesn't work.

[mattkhan]

Uninstall the antivirus if possible.  It's the only way to be certain that it's not causing trouble.  Disabling sometimes doesn't work.

It is windows defender on win8.1 and it is disabled as much as it is possible to disable it (as far as I know , you can't uninstall it)

[JimH]

The wiki has a topic on Windows Defender.

[mattkhan]

The wiki has a topic on Windows Defender.

When I say I have disabled windows defender, those instructions are what I refer to.

I have also tried disabling the anti malware service, makes no difference.

[mattkhan]

as far as I can see, changing the recording format doesn't make any difference as a timeshifted viewing is saved as jtv regardless. In any case, jtv does seem to be working ok so this issue only affects live playback.

Logically this seems to suggest the underlying device & stream are working ok, because it can be captured to disk and played back ok, but rendering that stream on the fly is a problem for jriver for some reason.

[mattkhan]

I only just realised that the card is categorised as an analogue card by jriver so this means I found the option to default it to time shifting to work around the problem.

[mojave]

As a followup, I tested last weekend on my friends Colossus 2. I couldn't find any issue with sync. He always has time shifting turned on (jtv) and I never tested with it off.

[JimH]

Thanks for testing.

[mattkhan]

I've returned to this topic with a different capture card and live playback seems quite unstable. Does av sync correction actually work with live playback? It is either that jriver is quite unstable with live playback or the sync options are doing nothing (either using the MCC command or by stopping, changing the value and starting again).

I'm pretty sure the card is fine as I tried it in VLC and MPC-BE and both seem quite happy with live playback & audio is looped back into jriver via the wdm driver with no obvious issues. I can also use the keyboard shortcuts available in those players to adjust sync and can see it move accordingly. This makes me fairly confident it's a problem in jriver's capture card handling.

[mattkhan]

I've spent far too long on this but I'm now fairly confident that a negative value for av sync is not supported with live playback of a capture device. Is this correct?

If so, my options are either use timeshifting (if it works) or another video player. The former adds way too much latency to be useful with an external device (due to remote control lag) so unfortunately I will have to use another player for this task.

FWIW I've tried 3 other players (vlc, potplayer, mpc-be) and each one requires a different offset for the audio but each one is able to handle it fairly easily, each one can delay the video and each one has a keyboard shortcut for small sync adjustments that operate live, i.e. no stream restart required, with a visual indicator in the OSD, i.e. so you know where you are. JRiver is markedly more user unfriendly in this situation.

[JimH]

Can you suggest keyboard shortcuts that are commonly used?

[mattkhan]

Can you suggest keyboard shortcuts that are commonly used?

Sure. VLC uses J and K for -/+ and uses 50ms steps. mpc-be uses +/- and does 10ms steps. Potplayer uses angle brackets and 5ms steps. Potplayer also has shift+/ to reset it to default settings.

Is there any chance of allowing live playback to buffer enough to support video delay?

[Yaobing]

This is not an easy problem to solve.  Perhaps adding a buffer would be the way to go, but that could just create a latency issue.  When not running in time-shifting mode, we just play whatever comes to the renders from the MPEG-2 demultiplexer filter.  If the audio falls behind, our method of synchronization would not work because you can not speed up audio when there is no new data coming fast enough.

[mattkhan]

This is not an easy problem to solve.  Perhaps adding a buffer would be the way to go, but that could just create a latency issue.  When not running in time-shifting mode, we just play whatever comes to the renders from the MPEG-2 demultiplexer filter.  If the audio falls behind, our method of synchronization would not work because you can not speed up audio when there is no new data coming fast enough.

IMV all the evidence says this issue is jriver specific. I say this because this stream is handled by other video players without any problem. Each one needs a small delay (~120ms) added to the video though the signal path is different in those cases as the audio is routed out of the player and into the jriver wdm driver, this is additional audio latency that jriver itself should not experience.

I don't have a way to measure WDM driver latency though to verify this (need to be able to clone a windows audio output)

[Yaobing]

What I was saying was that there was nothing we added that would cause the sync issue, other than attempting to make correction in Audio renderer.  When we do not make such corrections, all we are doing is to run DirectShow graph of the WDM devices.  When we do attempt to make corrections, we are limited to what audio data is available.  That was why I said we may need to add a buffer, which would increase latency.

[Yaobing]

I played with video capture a bit today and found that you can achieve the best A/V sync by reducing audio buffering to the minimum possible value.  In my case of using DirectSound as my output device, I pulled the Buffering slider all the way to the right.

That makes sense because we send video directly from video decoder to the video renderer without any delay, we should do the same with audio.

[mattkhan]

Thanks for looking into this. I thought jriver accounted for internal latency? I realise it is not strictly internal but it is still configuration applied in jriver (or it is if you referring to the buffer settings I think you are referring to).

FWIW I dug into the VLC options a bit, it defaults to a 300ms cache by the looks of it. I can't find any detail on MPC-BE and their commit log appears to be in Russian so no chance of me decoding that one

If there is ever any point in me running some sort of debug build in order to get more information on what is going on then I am obviously happy to do so.

[mattkhan]

I tried minimising audio device buffers and it didn't help at all.

I've settled on using mpc-be for this now but it's by no means ideal. Some observations on behaviour that I thought might point to the source of the problem;

- the offset between audio and video changes slightly each time you start playback, it hit on something almost in sync once but sadly this was not repeatable
- jriver is absolutely rock solid at reliably locking onto sound and video every single time you open the device, this is good! the audio is never in sync though so it's unusable
- mpc-be is really flaky at starting up, you generally get 5-10s of <1fps frame rate with perfect audio before it settles down, once it settles down then the av sync is completely reliable

so basically it seems like

mpc-be opens the device, faffs around a bit before it can deliver a reliable stream but is then consistently usable
jriver opens the device and just starts playing straightaway without getting the av streams in sync first

I realise you say jriver just plays what it gets but I'm afraid that statement simply does not reconcile with the behaviour I see, if there was a problem with the underlying device then there is no way mpc-be could reliably play this back in sync every single time. I would be extremely grateful/happy if this problem were solved!

[Yaobing]

There is something amiss in VideoClock which I can not explain.  You can turn off VideoClock.