H.264 Voice Sync Issue Using Monogram AAC

[ajst2duk]

Great.

Unfortunately because of a couple of oddities with the Cyberlink audio decoder (and its reliance on the Cyberlink demux), it can only be used for the playback of complete files. All other situations need another decoder, ie the monogram decoder. Unfortunately the monogram decoder has some audio/video sync issues though.

I've tried a prerelease of another decoder that can be used in live tv, timeshift and playback of recordings, and has perfect a/v sync, but unfortunately its not publically available yet, so you'll just have to make do for now with the current limitations of the monogram/cyberlink combination for now.

Sounds promising !!!!

[kylebrophy]

I've tried a prerelease of another decoder that can be used in live tv, timeshift and playback of recordings, and has perfect a/v sync, but unfortunately its not publically available yet, so you'll just have to make do for now with the current limitations of the monogram/cyberlink combination for now.

Terrific - ill wait with baited breath for this other decoder to become public. Im sure youd put out some soft of announcement when the time comes..

[sub]

Just to lower expectations on this other decoder, I found today it seems to have some problems with live preview mode. We just cant win...

It does work well for playing recordings though, including those that are still in progress.

[whurlston]

Has anyone tried the 3ivx MPEG-4 pack? The video and 2 channel audio filters are only 6.95 for personal use and the multi channel audio is 9.95.

http://store.3ivx.com/3ivxStore/index.php?id=2

There is a trial version if you click the "Download" link at the top of the page.

[sub]

I cant see any mention of HE-AAC or AAC-LATM on the feature list, but I've sent a question to them on the subject just in case...

[whurlston]

Not sure about AAC-LATM but from http://store.3ivx.com/3ivxStore/product_....php?id=19 :

The audio decoder can play Multi Channel (5.1) MPEG-4 High Efficiency and Low Complexity AAC audio encoded by Nero AAC, iTunes and others.

The components work with Windows Media Player, the QuickTime Player and any other compatible applications.

And from the support page http://www.3ivx.com/support/windows/deco...coder.html :

Audio Type
The Audio Type of the audio bitstream.

Main-AAC Main
LC-AAC Low Complexity
SSR-AAC Scalable Sample Rate
LTP-AAC Long Term Prediction
HE-AAC High Efficiency (aka SBR or aacPlus)

I'm not trying to sell you on it though... really.

[sub]

Yeah, I just that read before too. It'll be interesting to see if they reply.

I couldnt just try it. I'd need some info from them anyway, since there is no standards are around the directshow media types for these, and each decoder manufacturer seems to do it differently.

[RichardR]

Long time lurker taking the plunge and posting for the first time...

Sub
You mentioned in post 28 of this thread that the audio sync problem on playback of recordings was only fixed for the first play of a file (using PDVD8). I think I've found what the cause is.

I've been using PDVD7 and Monogram since upgrading to the current version of GB-PVR in March - with the well-documented audio sync problems on playback of H264/AAC TS recordings here in New Zealand.
This weekend I switched to PDVD8, applied the native utilities patch and tweaked the config.xml file as per the instructions in this thread.

I found that the first time a TS recorded file is played back, the audio sync is fine, because the PDVD8 video and audio codecs are used (as expected). However, on the second playback, the audio sync is out (as you said in post 28). This is because GB-PVR with the PDVD8 native utilities patch reverts to using the Monogram audio codec on the second playback.

The reason for this is that the recorded TS file is being locked (with 2 handles for some reason) during the first playback, and the locks are not being cleared after stopping playback. When starting the second playback, the logfiles show that GB-PVR thinks that the lock is due to the file being an active recording, and the code branches to a wait before resuming. However, when resuming after the wait, the logs indicate that the "UsePowerDVD8ForTS" code is not re-executed (effectively meaning that the "old" playback method and codecs get used). During second and subsequent playbacks a single lock/handle is created for the playback file, and the lock is released as expected when stopping playback (but the original 2 locks from the first playback process remain).

The 2 file locks/handles that are created during the first playback are cleared when exiting GB-PVR. After re-starting GB-PVR, the first playback will again be fine and then the file lock cycle starts over for subsequent playbacks.

I've attached logfiles showing the differences between the first and second time the same recorded file is played back. The file locking problem was proven using Unlocker Assistant and replicated on 3 separate PC's.

Regards
Richard

[sub]

The reason for this is that the recorded TS file is being locked (with 2 handles for some reason) during the first playback, and the locks are not being cleared after stopping playback.

Yes, correct. I'd got this far in my investigations, but not worked out why its happen. I have briefly look at it a couple of weeks back, but got busy with work. Its something to do with one of the directshow filters stopping the previous graph from shutting down properly, so the file is still held open.

I'm hoping to find some time again soon to take another look.

[hasso]

Could this also be the reason that when I try to delete a played .ts file that it doesn't actually show as being deleted in until I restart GB-PVR? If I try to delete an unplayed .ts file, it deletes no probs. I think someone esle in the forums had a similar problem.