[rmeredit]

I don't get a lock up, but as I posted earlier, I do get the chipmunk effect at 2x. Still using RC2 as per the previous post.

[Noelix]

Ok I made some progress on this - I get the chipmunk effect still but the program does not lock up anymore.

Tried latest ForceWare drivers, and they did not like PureVideo - everything showed up in a red haze...
Reverted to an older, different version of the driver pack (93.71) and now the video shows up fine, fast forwards fine without crashing, but I still get the chipmunk sound. Going to test some more now that I see some similarities in our setups.

Update: Using ffdshow to handle the audio results in chipmunk+lockup on ff.

I think the chipmunk sound may have to do with a change in the code that inadvertently affected the way PureVideo decodes... I could test further using other video decoders but I think I'll live with the chipmunk sound now that it does not lock up the program. All that needs to be added to the code is to tell the player to mute while fast forwarding / rewinding.

[cyberon]

Same issue here, using the latest RC3.
Any ideas how to fix this?

[gregly]

Yeah, it's been over six months and two supposed "release candidates" later, and this problem doesn't even show up in the official bug lists.

I used to advocate MP to everybody I came across, but now it seems people are more concerned with adding piddly crap and new flashy skins than actually fixing bugs. Looks like it's time to jump ship and find other solutions.

[tourettes]

"chipmunk effect" <-- that depends on the codecs / audio renderer. If codec and audio renderer support 2x playback with sound on then its what you get. Currently we arent muting the audio as some people want to have that "chipmunk effect".

[cyberon]

Originally Posted by tourettes

"chipmunk effect" <-- that depends on the codecs / audio renderer. If codec and audio renderer support 2x playback with sound on then its what you get. Currently we arent muting the audio as some people want to have that "chipmunk effect".

If there are users who want the "chipmunk effect" can you add an option on configuration to disable/disable it!
Personally i find it really annoying.

[rmeredit]

Hi Tourrettes,

That's a very strange 'feature'. I don't know any other consumer playback software that has it, and can only see that it would be useful for professional video editing tools.

Does this also explain why ffwd/rwnd with TV recordings/timeshifting performs so poorly and sends my audio receiver into a spin with locking and unlocking signals?

Cheers,

Rob

PS - I've always wondered about what does or doesn't make it into Mantis. There seem to be some very old, well documented bugs with logs that just languish in the forums, while bizarre things like stop button functionality during TV playback show up. I understand that the devs can only fix those bugs that team members have the expertise and inclination to fix, and the nature of open source is such that you don't always have the number of members or skill mix that you necessarily need on a project, but surely all documented bugs should show up in Mantis? This would mean that they're properly documented somewhere, rather than being randomly scattered throughout the forums, someone may actually come across the bugs who can fix them, and for those bugs that don't get fixed, at least people stop banging on about the same bug over and over, since they know someone's already experienced it and documented it formally. This bug, and the similar one where there is poor rwnd/ffwd in TV recording playback are just two cases in point.

[tourettes]

Originally Posted by rmeredit

That's a very strange 'feature'. I don't know any other consumer playback software that has it, and can only see that it would be useful for professional video editing tools.

I have seen it on multiple devices. Also if its considered as a bug its one of the most minor bugs that there can be, so it wouldnt have any high priority in fixing.

Originally Posted by rmeredit

Does this also explain why ffwd/rwnd with TV recordings/timeshifting performs so poorly and sends my audio receiver into a spin with locking and unlocking signals?

No it doesnt. But the following fact will explain it a little bit:

Microsoft audio renderer can render only at 2x speed. When user wants to forward > 2x speed then in short we must do the following:

1) pause clip playback
2) seek a little bit
3) play for a brief moment
4) go to #1

...all are done with different delays depending on the speed

There are lot of different issues that affect the FF/REW in directshow.

- codecs
- audio renderer
- container type

Originally Posted by rmeredit

PS - I've always wondered about what does or doesn't make it into Mantis. There seem to be some very old, well documented bugs with logs that just languish in the forums, while bizarre things like stop button functionality during TV playback show up. I understand that the devs can only fix those bugs that team members have the expertise and inclination to fix, and the nature of open source is such that you don't always have the number of members or skill mix that you necessarily need on a project, but surely all documented bugs should show up in Mantis? This would mean that they're properly documented somewhere, rather than being randomly scattered throughout the forums, someone may actually come across the bugs who can fix them, and for those bugs that don't get fixed, at least people stop banging on about the same bug over and over, since they know someone's already experienced it and documented it formally. This bug, and the similar one where there is poor rwnd/ffwd in TV recording playback are just two cases in point.

Its not considered as a bug, that might be the biggest reason. Also REW/FF is really slow way to seek inside file compared to skip steps (left/right/up/down buttons).

Poor rwnd/ffwd is actually a missing feature. Microsoft has done a lot of work on that area on SBE, but TVE3 is not using it so we would have to implement some tricky code... so if anyone knows how Microsoft DVD navigator handles the >2x speed seeking he/she is more than welcome to help the team.

[rmeredit]

Originally Posted by tourettes

I have seen it on multiple devices. Also if its considered as a bug its one of the most minor bugs that there can be, so it wouldnt have any high priority in fixing.

It may be minor, but it's certainly behaviour that lots of people find 'unusual' to say the least - unusual enough that many perceive it as the software not working correctly. If it's a design feature, then perhaps it should be documented. If it is a bug, then it's certainly no more minor than things I've seen go through Mantis and then fixed (eg. the recent stop button functionality while watching live TV).

Originally Posted by tourettes

No it doesnt. But the following fact will explain it a little bit:

Microsoft audio renderer can render only at 2x speed. When user wants to forward > 2x speed then in short we must do the following:

This is exactly my point - why is the audio renderer being employed at all for ffwd/rwnd? Turn off audio, seek efficiently, and then re-enable the audio filter when 1x playback is resumed. This was the functionality under TVE2, at least under 0.2.3.

I've read all the stuff about 'efficient' seeking with skip steps earlier, but these are only useful for large, macro jumps around a file. Seeking is necessary for fine-touch movements, such as finding the end of an advertisment in a broadcast when the broadcaster doesn't use standard ad-break durations. It's standard functionality in just about any video playback application and device I've ever used (the 2x audio, I have to say, is not - while it may be common in devices you use, MP is the first application or consumer playback device I've *ever* used that features it). In fact, skip steps alone are much slower to find a specific point in a video than a combination of skip steps and seek (in essence, skip steps alone are the same as skip steps plus seeking at 1x speed, and only forward rather than backwards)

This is only my personal opinion, of course, but a properly functioning seek feature (with both ffwd/rwnd and skip steps) without any audio is far more polished and professional than a half broken seek with audio under TV playback and the general recommendation to only use skip steps because it's faster.

Originally Posted by tourettes

There are lot of different issues that affect the FF/REW in directshow.

- codecs
- audio renderer
- container type

Yes, I understand this, and have managed to get TV seek functionality almost to the point of being useful by using the PDVD8 codec for video. Why audio is in there, again, I'm baffled, but the container type (mpg versus .ts for TV) makes absolutely no difference on my machine. Everything functioned well under TVE2 with regards to playback and seeking functionality.

Originally Posted by tourettes

Its not considered as a bug, that might be the biggest reason. Also REW/FF is really slow way to seek inside file compared to skip steps (left/right/up/down buttons).

Fair enough in this regard, but, for example TV seek functionality has been a problem for a reasonable number of people under TVE3 since 0.2.3 days, based on the threads I've found, but it's never made it into Mantis. Even if it's considered a minor bug, why isn't it documented properly? And I only cite this as an example - I'm sure there are others well documented in the forums.

Originally Posted by tourettes

Poor rwnd/ffwd is actually a missing feature. Microsoft has done a lot of work on that area on SBE, but TVE3 is not using it so we would have to implement some tricky code... so if anyone knows how Microsoft DVD navigator handles the >2x speed seeking he/she is more than welcome to help the team.

Again, so why not document it as a bug so that a potential developer can have a crack at it? If it's not properly documented, the chances of it getting fixed are minimal. Even though I'm not a coder, and I've never coded in C# at all, I've poked around the code a bit myself to see if I could have a crack at it, and am completely lost. It's not for want of desiring to contribute (I do where I can - on skins for example).

There seems to be a certain amount of frustration in the non-developer MP community that comes out of a lack of transparency and documentation about what the devs are actually doing and discussing, and the trend appears to be towards less openness (no change logs in the SVN build posts for example!?) rather than more. We shouldn't have to subscribe to the dev mailing list or each do our own svn log command to be able to see what's acknowledged as a bug, what's an open problem that needs resources, versus something that's actually being worked on. The project management tools are in place, they just don't seem to be being used effectively for communication with the wider MP community - it's all left up to the forums, which aren't up to the job.

Anyway, end of rant. This wasn't intended to have a go at you or the other devs, Tourettes. I'm a big fan of the project, obviously, otherwise I wouldn't care to write this stuff or make other contributions - I'd just move on.

Cheers,

Rob.

[tourettes]

what a long post that was

Here's few points:

This is exactly my point - why is the audio renderer being employed at all for ffwd/rwnd? Turn off audio, seek efficiently, and then re-enable the audio filter when 1x playback is resumed. This was the functionality under TVE2, at least under 0.2.3.

In TVE2 it "just works" as Microsoft has done great work with the SBE engine on FF/RW fuctionality. It indexed the I-frames to allow backward seeking, mutes audio content on similar way as DVD navigator (we currently dont know how its done)...


We have internal "Smooth FF/RW for DVD & TVE3" thead, wich is evaluating FF/REW issue. It has many technical proposals, but no of those are working. So we wont be adding it to Mantis until we have at least a good prototype that might even work.

...and what comes to Mantis + someone from the public solving the "bug" that is not a trivial one, the hopes are really small. There usually arent any patches for the trivial bugs