Any timeframe on next beta update?

Status
Not open for further replies.

SamuriHL

Member
I don't disagree with anything you just said there. I also agree that testing usually doesn't get enough attention. As a software engineer, I've resisted going into management because I KNOW I'd not be good at it. I don't have the right skillset nor do I want it. I design and write code. I'm trying to move more into design these days. In any case, I agree that when developers run things it goes just as badly as when management won't set realistic expectations. There is a balance to be had for sure. I don't know the org structure of VRD, but, for the most part I've not been dissatisfied with their communication and ability to get things done. This issue I agree is a tough one, but, you have a commitment from them to work on it and fix it as soon as their schedule allows. That's really not a bad thing.
 
25 Jan 2010: We have some dish files already, no need to post new ones at this time.

25 Jan 2010: We did quite a bit of testing with BBCHD files during the beta, but we will get on this right away and see what's going on.

02 Feb 2010: There are issues with Dish and H.264 editing. We are working on it, but it will take a few weeks as the problem is quite complex.

22 Mar 2010: It could be that Dish changed their encoding. We are about to complete a number significant improvements to the H264 cutting logic. These will be rolled out over the next 1-4 weeks.

13 Apr 2010: Also, the pixelation issue on some H.264 at cut points, is not yet ready for release. Hope to have that ready in Build 601.

23 Jul 2010: We've been planning on getting a fix put together for this for months (since say early April), but the work is extremely complex and takes tons of dedicated time. This means we need a window to focus on it. In the meantime, we've had a number of other issues and opportunities to contend with so we haven't devoted ourselves to resolving this specific problem. I think there's a time window, starting in about a week where we can re-focus on this.

They haven't been ignoring us, but apparently they haven't started working on it either.
Well version 600 came out around 4/13, that is the file date on my download. So according to your list: Jan and Feb should have been incorporated along with some or all from March.

Mike
 

HDstreamer

New member
Well version 600 came out around 4/13, that is the file date on my download. So according to your list: Jan and Feb should have been incorporated along with some or all from March.

Mike
Actually the Jan, Feb and March problems were not incorporated in build 600. There was a note about this on the 4/13 release notes, which mentioned hopes to have this fixed in build 601. Please see the reference there on the 4/13 line item you quoted. It was disappointing to hear that in April, the Jan problems were not fixed. Today, hearing that work did not begin yet is disconcerting.

On the issue of software, I have written large complex video mux and demux + stream processors like that included in VideoReDo. I can appreciate the remarks by DanR that he wants to tackle this in one swoop.

In my own work I felt the same way at times, and put some work off until I had a window to do it.

However, once I actually started doing the work, it was easier than I thought, and there really was no problem taking an extended break and diversion, and coming back to it.
 

rebel777

New member
In my own work I felt the same way at times, and put some work off until I had a window to do it.

However, once I actually started doing the work, it was easier than I thought, and there really was no problem taking an extended break and diversion, and coming back to it.
As a developer yourself you must be familiar with the phenomenon that sometimes complicated and hard stuff won't result in a flawless implementation the first round and you get stuck not able to fix the "last" bug(s). Unconsciously a kind of dyslexia for bugs (so to say) develops because you have been over the code a few hundred times too much.

Instead of further hurting your braincells it's wise then to take a break. Then later when you pick up the issue again with a new fresh look then often (if not always) the problems are solved within days if not in seconds.

If this is the case, and there are indications for that, see Dan's words, then it is only good the VRD team temporarily addresses some other issues at the moment. It's needed for the fresh new look at the complicated problem they are facing.

Of course I understand your frustration, the growing lack of harddisk space. It's why I still record in MPEG only while I have the possibility to record the same broadcast station in HD with H.264 as well.

New developments take time.

Ed
 

VideoGuy

New member
@MrVideo

The point I was trying to make is if you're having glitching at points other than at cut points is that it might be a multiplexing problem.

You don't mention where glitching occurs but it might be at high bitrate locations.
Videoredo always remuxes the entire file that is why I suggusted trying remuxing with a different muxer.

As for your other comments about me having trouble with my keyboard I don't see where this has anything to do with my suggestions.

Bob
 
Last edited:

MACKerMD

New member
Small example:

- I recorded 'Sherlock' from BBCHD. Original is FINE; no errors in the stream, no problems playing back, no artifacting, no macroblock. Play on both PVR, PC, external HD Player, etc.
Once running it through VRD4/h264, I get -HUGE- macroblockin, doesn't play on PVR, external HD player, does play on PC but with at least 10 secs of problems.

- Multiaudio a problem ? If a german one-person util such as TS Doctor is able to output multiple audio, multiple video, teletext and dvb subs, selectable when outputting, why can't VRD ?

- Subtitles a problem when outputting ? Why can a freeware util such as ProjectX can ? Even if it was intentionally based for MPEG2 files under 6mb GOPs, it still outputs the subtitles in both SRT as SUP. Why can't VRD ?

- Why do I have to wait til vacation is 'over' before being able to return to a program that should've been fixed 'within a week' which never happened? Does Microsoft lacks their tuesday-update ? Do -they- in total{!} go on a holiday as well and post their comments from the beach ? During summer I FILM most of my content and want to EDIT them instantly for outputting them for those that were on it. I cannot wait 3 months to deliver them their holiday-summer-videos when it's stormseason outside because of Autumn ?!!

Don't go on a holidaytrip from the money you made from the people that purchased the util, but instead get better outsourced people that do their job. Invest your money on that.

It's almost pathetic to see that freeware utils are still 'forced' to be used, whereas people that buy a product that promisses things are being left-behind by freeware utils that slowly gain more trust and reliability in their outputs than VRD. I don't think that's the intention of VRD. If you want to keep customers happy and eager for new VRD-stuff, don't let them in the dark and give them some good in return.

I -at first- was very happy with the ongoing development of VRD, but it's very frustrating that as SOON as I bought it, the support lacks in a way that tells you 'you are an annoying customer, we point you to other people to shove the blame on, and we don't give you the answer you are asking for.'

A -frustrated- customer.
 

SamuriHL

Member
LOL, yea, comparing a company the size of VRD to Microsoft makes TOTAL sense. :rolleyes: I suppose they shouldn't sleep, either, until your problem is fixed? Or eat. I mean, those things take time away from fixing your issues urgently, right?
 

MrVideo

Active member
You don't mention where glitching occurs but it might be at high bitrate locations.
Videoredo always remuxes the entire file that is why I suggusted trying remuxing with a different muxer.
I'd have to go back through this thread, but I believe that I did say that my latest issue is an ABC H.264 stream was glitching before the edit point. VRD went back to the I-frame (not an IDR frame) before the edit location and re-encoded the frames from that location until the next I-frame.

The programmers at VRD will have to determine what is going wrong at those locations. The H.264 sample that they have in their hands duplicates all kinds of issues with VRDs handling of ABC H.264 video.

Obviously I can't try a new remuxer withing VRD. What I can do, when it happens again, is to have VRD output separate H.264 and AC3 streams and remux externally with tsMuxeR. That said, my money is on the actual encoding being screwed up.

As for your other comments about me having trouble with my keyboard I don't see where this has anything to do with my suggestions
It just seems that you were having a bad day typing, which isn't like you.
 

MACKerMD

New member
LOL, yea, comparing a company the size of VRD to Microsoft makes TOTAL sense. :rolleyes: I suppose they shouldn't sleep, either, until your problem is fixed? Or eat. I mean, those things take time away from fixing your issues urgently, right?
:rolleyes: I know, VRD cannot be compared like M$, sizewise, ammount of people-wise. But to see a 'stall' in release-betas for more than 3 months or any text-updates about the current progress is what's frustrating me.

Things take time... ofcourse they do. The problems that I have, are not uncommon to others that use VRD too on a daily basis (as I have since).
Temporary stepping back a little for a short (repeat: SHORT) while, makes total sense, but when that time is taking up almost 2 seasons, when reading that some issues from january are still not fixed in july, that's a strange definition of 'short'.

If they need a sandwich, I'd be happy to help them out if it would increase the effort in speeding up these issues so a lot of already-paid-customers can 'back-off' for the time being and then the focus can be totally be on new stuffs, such as the iPAD. Yes, MP4 is a high-issue, but the iPAD itself I don't care less about it at all. Just an oversized iPhone imo :D

It's just frustrating that the issues that -I- have, are similar to those that popped up in January til now and haven't been solved yet.
I don't put the blame on broadcasters, nor the dev-team, etc. I -only- point out my frustrations, because I am too eager waiting for a new beta with -some- improvements, fixes, etc. Anything but the 600 I'm using now.

I don't want to buy another application that can handle the 'pixellation' bugs, but can't edit. This is why I chose VRD, since I heard very good feedback on the MPEG2 versions before and was quite convinced, after following the beta-updates for a month orso, that the development would not stall in the weeks/months after. I guess I was wrong on that.

That does not mean I have no faith in the further development of VRD, nor its staff and people that work for VRD.

And speaking of sleep, I -suffer- from DSPS (go google) meaning I am awake most of the time and have developed plenty of videorelated things in the past. In the ancient ages of mpeg-1 and mpeg-2 on a freeware basis with plenty of happy people that used it and still do if needed. Even without the proper hours of sleep a day, we'd still managed to get things done, focussed on it and kept working on issues, til they were fixed and done, before skipping to the next option that we had planned.

*cough* .. sandwich? coffee ? tea ? ... anyone?
 

MrVideo

Active member
- I recorded 'Sherlock' from BBCHD. Original is FINE; no errors in the stream, no problems playing back, no artifacting, no macroblock. Play on both PVR, PC, external HD Player, etc.
Once running it through VRD4/h264, I get -HUGE- macroblockin, doesn't play on PVR, external HD player, does play on PC but with at least 10 secs of problems.
I'd love to have a sample to test. PM for details.

- Multiaudio a problem ? If a german one-person util such as TS Doctor is able to output multiple audio, multiple video, teletext and dvb subs, selectable when outputting, why can't VRD?
As I understand it, the way the they initially designed the audio handling never took into account working with multiple audio streams. That said, keep in mind that using these types of streams and NOT editing them is a lot easier task. When editing, a lot more stuff has to be kept track of.

FYI, there are no spaces between the last word of a sentence and a question mark. :D
 

SamuriHL

Member
:rolleyes: I know, VRD cannot be compared like M$, sizewise, ammount of people-wise. But to see a 'stall' in release-betas for more than 3 months or any text-updates about the current progress is what's frustrating me.

Things take time... ofcourse they do. The problems that I have, are not uncommon to others that use VRD too on a daily basis (as I have since).
Temporary stepping back a little for a short (repeat: SHORT) while, makes total sense, but when that time is taking up almost 2 seasons, when reading that some issues from january are still not fixed in july, that's a strange definition of 'short'.

If they need a sandwich, I'd be happy to help them out if it would increase the effort in speeding up these issues so a lot of already-paid-customers can 'back-off' for the time being and then the focus can be totally be on new stuffs, such as the iPAD. Yes, MP4 is a high-issue, but the iPAD itself I don't care less about it at all. Just an oversized iPhone imo :D

It's just frustrating that the issues that -I- have, are similar to those that popped up in January til now and haven't been solved yet.
I don't put the blame on broadcasters, nor the dev-team, etc. I -only- point out my frustrations, because I am too eager waiting for a new beta with -some- improvements, fixes, etc. Anything but the 600 I'm using now.

I don't want to buy another application that can handle the 'pixellation' bugs, but can't edit. This is why I chose VRD, since I heard very good feedback on the MPEG2 versions before and was quite convinced, after following the beta-updates for a month orso, that the development would not stall in the weeks/months after. I guess I was wrong on that.

That does not mean I have no faith in the further development of VRD, nor its staff and people that work for VRD.

And speaking of sleep, I -suffer- from DSPS (go google) meaning I am awake most of the time and have developed plenty of videorelated things in the past. In the ancient ages of mpeg-1 and mpeg-2 on a freeware basis with plenty of happy people that used it and still do if needed. Even without the proper hours of sleep a day, we'd still managed to get things done, focussed on it and kept working on issues, til they were fixed and done, before skipping to the next option that we had planned.

*cough* .. sandwich? coffee ? tea ? ... anyone?
Believe me, I DO understand the frustration. I get it completely. And I'm *DEFINITELY NOT* trying to minimize anyone's problems with VRD at all. It's very clear there are issues and they are not fixed. My point is simply that if they know the issues and have said they'll fix them, hounding them on when it's going to be fixed isn't going to get anywhere. At all. It's NOT going to make them work faster. It's not going to get the problems resolved any faster. Expressing frustration is one thing, and I get that, but, expecting that it's going to have any affect whatsoever on the development of VRD is somewhat delusional. It's like herding cats. :)

I have a question for all those who are dissatisfied. And it's a serious question that I really want you to think about. VRD works extremely well for some people. That's a fact. VRD does NOT work well for others. Also a fact. So my question to all those who it doesn't work for....would it have been better for VRD to delay even further the release of h.264 support until it's "perfect", or does the fact that it works for a lot of people justification enough for releasing it as is now, with the understanding that it is, after all, a beta? Even with all the issues. Because quite frankly, they could have delayed it another year and made it perfect before publicly releasing it, but, then a lot of people would be missing out on what does currently work. Maybe something to consider anyway.
 

VideoGuy

New member
MACKerMD I think I read that BBCHD might be using MBAFF encoding for their files.

These type files might be causing encoding and multiplexing problems for Videoreo.

I have had problems with these type of streams in the past.

From wikipedia :

Macroblock-adaptive frame-field (MBAFF) coding, using a macroblock pair structure for pictures coded as frames, allowing 16×16 macroblocks in field mode (compared with MPEG-2, where field mode processing in a picture that is coded as a frame results in the processing of 16×8 half-macroblocks).

They look like interlaced frames but are a combination of frame and field encoding as far as I understand it.

Bob
 

pendragon

Member
I have a question for all those who are dissatisfied. And it's a serious question that I really want you to think about. VRD works extremely well for some people. That's a fact. VRD does NOT work well for others. Also a fact. So my question to all those who it doesn't work for....would it have been better for VRD to delay even further the release of h.264 support until it's "perfect", or does the fact that it works for a lot of people justification enough for releasing it as is now, with the understanding that it is, after all, a beta?
I doubt anyone knows what fraction of users can edit H.264 properly with VRD, even the company itself. It could be 1%, it could be 99%. I have a fair number of different sources of H.264 streams, and until I tried a new one yesterday, none of them could be edited glitch-free by VRD. Thus your hypothetical question is difficult to address from the 'common good' perspective. My sample says we are still not to the alpha stage.

There is the old adage of "never time to do it right, always time to do it over". I see comments made here by others who apparently subscribe to this philosophy. They whack some code out and then start squashing bugs and design errors until it works. The resulting code is often ugly and difficult to maintain. Adding new and unanticipated features generally requires a lot of legwork. VRD is sending out all the usual clues and hints this is their development strategy, if one can call it that.

I would have preferred VRD to start with the H.264 specs and to design code to support it, instead of only to work with specific examples. And I really mean design with tough technical reviews, not the traditional crybaby stuff. If you don't have motivated devil's advocates, these reviews quickly degenerate into love feasts and are ultimately abandoned as being useless. However if they are done effectively and followed with equally brutal testing, the difference in results can be dramatic. Less development time, smaller maintenance effort, easier future upgrades, happier customers.

I expect alpha code to be demonstration-grade for customers. The first beta should be a serious attempt at a release candidate.
 
Last edited:

SamuriHL

Member
Yes, I'm a believer in 99.9% is design. :) Designing it properly leads to smoother coding and easier maintenance. I don't disagree at all. But not everyone subscribes to that methodology. You also have to remember that they're using 3rd party code, as well, so I'm sure that plays a factor here in getting things fixed. I'm not trying to shift blame or any of that, simply that it's a reality that they use 3rd party code that could be contributing to the issue. They may need to work with them to find a solution. We simply don't know. That's why I mentioned originally the LOTS of stuff goes on behind the scenes that we aren't privy to idea. It's not an excuse and it doesn't make it ok. I'm not suggesting it does. There's just a reality that needs to be faced that all the complaining, expressing of opinions, etc isn't going to change anything. That's just the way it is.
 

pendragon

Member
As a customer this drama unfolded at a glacial pace. I don't recall how long the alpha period lasted, but they've been in beta for at least seven months with the primary release feature still functioning only partially at best. I find it incredible they are adding new features instead of getting the basics to work.

If we were a flock of sheep and let this pass unnoticed, I guarantee the next time around would be even worse. It's important for customers to voice their frustrations or companies, managers and developers become complacent. If I were VRD, I'd rather take the heat for a screw-up than be abandoned. While nothing physical has yet resulted from the complaining, I wonder if anything would have been done without it.

It's also important that potential customers be aware this is not a feature-ready product. I do applaud VRD for letting people try the software out before purchasing it, but from random comments I've come across, the poor performance on H.264 with the trial copy is chasing some away.
 
Chesse n rice people, you whiners are nothing but broken records, keep saying the same crap over and over.:mad::mad: All this banter is off topic from the thread. Just clam up and wait for the release. If you can not wait then leave and find another product that suits your needs. There are plenty of other editing applications out there.

Pat please close this thread, it does not serve a purpose anymore.

Mike
 

bits

New member
So why is VRD the lone developer?

Much has been said but I think a fundimental question has not been addressed; why is VRD the lone developer of this type of h264 editing software? Why don't they have any real competition? Answer that with facts, first hand knowledge and intelligence, and that will in large part explain the current situation and help reset expectations.
 
Status
Not open for further replies.
Top Bottom