VideoReDo Plus, Beta 414

[DanR]

VideoReDo Plus, Beta 414 has just been posted.

Betas can be found here: http://www.videoredo.net/beta/

To enable new Plus features, enter "beta-on" into the Enter Software Key Name field.

Release Notes
414 - Change: If convert all I-Frames to GOPs is enabled, temporal reference will be reset to zero for each I-Frame.
414 - Fix: TS output, partial audio packets at end of file. Will now dump all the audio packets.
414 - Fix: DVR-MS, better detection of AC3 streams. Previous version could miss classify them as MPEG audio.
414 - Enhance: CRID program title renaming and QSF using right mouse click. Ability to change CRID file sorts.
414 - Enhance: Major internal work on video display routines to support FUTURE handling of dimension changes.
414 - Fix: TS input files. Better checking for invalid PIDs by insuring that the PTS is within range.

[DanR]

First new beta since the release of VideoReDo Plus. Changes include:

1) Re-written TS muxer. Its still not 100% complete but it does output constant bit stream files. One user reports some video stuttering with hardware decoders which we are still looking into. There are new output mux options on the TS output stream options. You can specify the overall mux rate or let VRDP figure it out for you. The output mux rate is based on the audio bit rate and the PEAK video bit rate. The PEAK video bit rate is determined by sampling your input file at fixed intervals. You can control the number of samples taken in the options dialog. The values used in the mux rate calculation are in your log file.

2) Other TS fixes include smarter handling of program maps. And, if you can now specify specific video and audo streams in the Select Stream dialog if the program maps we find or create are totally incorrect.

3) Big new feature for people who edit DVD material and certain kinds of transport streams. On the Tools>Options>Plus there is an auto concatenate feature. When checked, VRDP will look for all files that match the numeric file suffix (i.e. VTS_01_01.vob, VTS_01_02.vob). If multiple matching files are found it will automatically piece them together and edit them as one file. It does this by creating a .VLST file which is simply the list of files to be autoconcatenated. Once a .VLST is created you can then open and edit a .VLST file as you would any standard MPEG file. Note, this works greate for CRID files from a Siemens box.

To enable this (and other upcoming Plus features), go to Help>Enter software key and type: "plusoptions-on" (no quotes), and then click on Register. This requirement will be removed in the next beta.

4) New feature for files that have changing video dimensions. QSF will now let you optionally restrict its output to a single video dimension. Click on the on the new "Filter" checkbox to bring up a selection dialog. VRD will sample your program to find the different dimensions and you can then choose from the list. You can change the number of fixed interval samples on this selection dialog.

[Harry]

3) Big new feature for people who edit DVD material and certain kinds of transport streams. On the Tools>Options>Plus there is an auto concatenate feature. When checked, VRDP will look for all files that match the numeric file suffix (i.e. VTS_01_01.vob, VTS_01_02.vob). If multiple matching files are found it will automatically piece them together and edit them as one file. It does this by creating a .VLST file which is simply the list of files to be autoconcatenated. Once a .VLST is created you can then open and edit a .VLST file as you would any standard MPEG file. Note, this works greate for CRID files from a Siemens box.


sounds awesome, Dan. is this already in build 408? i can't find a "plus" entry in the options dialog.

does this work as well with COM? i think about adapting the split script in order to save one edited dvd (eg music clips) to multiple files in one rush :) looking forward to test this.

thx 4 info.
Harry

[DanR]

Oops, sorry type: "plusoptions-on" (no quotes) into the name field of Help>Enter Software Key to enable the Plus features. Forgot to remove that check before releasing it.

Yes, it will work with COM.

[therat]

Dan, I'm still using build 401. I notice in that beta folder that there is build 407 and build 408. 407 seems a complete build yet build 408 has "Upd".

Also 407 is considerably larger than 408.

Do I need to install both or just 408?

cheers

[Anole]

I personally prefer full stand-alone versions , but Dan sometimes releases update copies.
They're nearly the same size, so he probably has some other reason.
I chose the later 408 upgrade, and will be testing that shortly.
I am -assuming- the upgrade will work on my 401, and if not.... well.... we'll see.... ;)

[phd]

You just have to install 408.

The update doesn't include all the "wizard" stuff that occurs after the install. Being that you have already installed Plus, your settings will not be affected.

[therat]

ok Thanks for the info Pat.

cheers

[Harry]

Oops, sorry type: "plusoptions-on" (no quotes) into the name field of Help>Enter Software Key to enable the Plus features. Forgot to remove that check before releasing it.

Yes, it will work with COM.

thanks for the info, works now.

is this dvd feature still preview or do you already want our beta feedback? :D

first thing that came to my mind is that automatic vlst file generation in the folder where the vob files are. would it be possible to include this into the project file or in a temp directory in the videoredo folder? reason is that i have a dvd on my harddisk and when i edit it, i don't any files to be added to the directory without my notice.

well, wasn't exactly the first thing. first thing was that this feature is awesome and works fast as usual :D

[robena]

3) Big new feature for people who edit DVD material and certain kinds of transport streams. On the Tools>Options>Plus there is an auto concatenate feature.
A really useful feature.

I have a suggestion to even enhance it: the Open Video dialog box could allow the selection of multiple files, and when multiple files are selected, a VLST file would be created and loaded automatically.

[murrayt]

Dan

I have tried Beta 408 and created a .TS output

It is much better than before but the audio is good for a period, then gets choppy for maybe 10 to 15 seconds, and then gets good again (only one test as yet)

DigiTv does not register it as a valid .TS in that while it plays OK the media player does not seem to think that it is playing a file (sounds odd I know) and the channel ref is not the PID of the original recording, but that is expected I guess

I am using DigiTv 3.508beta so there is no guarantee that it is not a problem from that perspective

Conversely the .TS plays OK in PowerDVD 6 which matches what I saw last time

[murrayt]

Dan

Also I like the auto concatenate feature !!

Seems to work OK. Only took me about 6 minutes to output all seven VOB's from a typical 2 and a bit hour DVD
I haven't played the result on my typical players but no errors reported in VRD so I imagine it will be fine
Nice!

[DanR]

first thing that came to my mind is that automatic vlst file generation in the folder where the vob files are. would it be possible to include this into the project file or in a temp directory in the videoredo folder? reason is that i have a dvd on my harddisk and when i edit it, i don't any files to be added to the directory without my notice. We could add an option that lets you specify a folder for the .VLST files. Any thoughts on this would be appreciated as I know everyone has different file organization setups.

have a suggestion to even enhance it: the Open Video dialog box could allow the selection of multiple files, and when multiple files are selected, a VLST file would be created and loaded automatically.Its something we did consider, but are not yet ready to implement. What you are asking for is a different kind of joiner, and while I like the idea we aren't quite ready to handle it yet. In the auto-concatenate their an implied assumption that all the files will have the same characteristics, most importantly audio codec, stream ids (PIDS for TS ), and video dimensions. There is no checking going on to insure that uniformity. We also don't insure that each file starts on a GOP as is the case with our normal joiner.

[Anonymous]

Dan,

Thanks for coming up with a solution for the Video Dimensions Changed problem. Is there a solution for the "No data found for requested programs(s)" problem in this beta? We had discussed this in this thread:

http://www.videoredo.net/msgBoard/viewtopic.php?t=1413

I just couldn't quite tell from the descriptions if there was a change that affected how far VRD looks for packets with valid data.

Thanks,

Ron

[Harry]

first thing that came to my mind is that automatic vlst file generation in the folder where the vob files are. would it be possible to include this into the project file or in a temp directory in the videoredo folder? reason is that i have a dvd on my harddisk and when i edit it, i don't any files to be added to the directory without my notice. We could add an option that lets you specify a folder for the .VLST files. Any thoughts on this would be appreciated as I know everyone has different file organization setups.

in my user point of view i don't see the purpose of the vlst file yet, especially why vrd needs to save it at all, but that could be a design issue, dunno. imo one could as well write this data into memory and when the project file is saved, into the project file.

if the vlst file is a must for an open project, i suggest to write it into a temporary directory in the vrd folder by default, or into the windows temp directory. but the last suggestion is a bit off, as it would never get deleted there.

reason for all this: i like it that vrd never modifies my source files. in the case of a dvd, it is a modification of the dvd directory if some additional files are written into the video_ts folder => hence my concerns and my request for a different directory.

[murrayt]

Dan


I'm a bit with harry on this one.

I leave my DVD directories on disk with a view to authoring back to DVD

While it is no great problem deleteing the VLST file, there is just the risk that it is forgotten

[Anonymous]

For those of us working with .ts files. The VLST file in the same directory is fine and even preferrable. However, videoredo seems to calculate the vlst file very quickly. Why not just calculate it on the fly every time and not leave a vlst file anywhere on disk.

[Anole]

Whatever DVD player software I use, it leaves a bookmark/log file whenever it plays a DVD image from the hard drive.
I discovered it when I then went to burn that folder and Nero said, "Hold on, you have a non-DVD-compliant file, there!"

So, if the file can be relocated, to the user's wishes, that'd be nice.
In practice, I'm not sure it really matters. ;)

[Paul Evans]

I regularly use Virtual Daemon MANAGER v3.46 to mount stored ISO images for viewing etc. ISO storage is convenient and quick to use. The new features for concatinating VOB files does not work unless the contituent files are first copied to a temp storage area. It is therefore time consuming and inconvenient. The ability to operate on ISO files with Virtual Deamon manager and VideoRedo would be a major plus if the VLST could be parked somewhere other than the source directory.

My vote goes for user defined directory or std VideoRedo temp directory.. it is a configuration issue not one to change regularly.

Keep the good work up...

p.s. any change of very simple sound fade in/out at edit points

[DanR]

My vote goes for user defined directory or std VideoRedo temp directory.. it is a configuration issue not one to change regularly.
The feature is done and will be in the next beta.

Fade in/out at edit points is in progress. Hope to have a beta available this month on it.

[laserfan]

Hello, my first post, having (rather amazingly, to me) downloaded the 408 beta and edited my MDP-130's 8.6Gb "Final Episode NYPD Blue" ATSC stream in just a matter of minutes. Great! The output (now 4.2Gb minus extra weather stream and commercial breaks) appears to be gorgeous on playback, except when I opened it again w/VRD (for grins) the first frame looked like "hash" and VRD complained I should Quickstream Fix it.

I did that, but wonder why its output, which did have some program trimmed both front-and-back as well as in the middle, should require an immediate further Fix process. I will of course do some more testing and maybe I missed something, but... Here anyway is my log, edited to get my key out of it:

***** Loading: E:\HD Transport Streams\Final Full Blue.tp.mpg


09/01/05 16:03:06 Opening file: E:\HD Transport Streams\Final Full Blue.tp.mpg, filetype is: MPEG2 TS PIDs: x11 / x14
09/01/05 16:03:06 Startup - Number of PTS checks: 8
09/01/05 16:03:06 Bumping mux rate to: 15.000 Mbps to accomodate video bit rate of: 14.492
09/01/05 16:03:07 Bumping mux rate to: 15.000 Mbps to accomodate video bit rate of: 14.492
09/01/05 16:03:07 Horizontal size of: 1920 indicates HD stream. Forcing YUV acceleration.
09/01/05 16:03:07 HDTV material detected, switching on YUV acceleration, width: 1920, height: 1080
09/01/05 16:03:07 Display open status: Using YUV with overlays.
09/01/05 16:03:07 Bumping mux rate to: 15.000 Mbps to accomodate video bit rate of: 14.492
09/01/05 16:10:26 Opening file: E:\HD Transport Streams\Final Full Blue.tp.mpg, filetype is: MPEG2 TS PIDs: x11 / x14
09/01/05 16:10:26 Startup - Number of PTS checks: 8
09/01/05 16:10:26 Bumping mux rate to: 15.000 Mbps to accomodate video bit rate of: 14.492
09/01/05 16:10:26 Program Information
File Name: E:\HD Transport Streams\Final Full Blue.tp.mpg
File Size: 8788557824 ( 8.18 GB )
Program Duration: 01:00:24.29
File Type: TS Stream
Encoding: MPEG 2
Video stream Id: 17 (x11)
Encoding Dimensions: 1920 x 1080
Display Size: 1920 x 1080
Aspect Ratio: 16/9
Frame Rate: 29.97 FPS
Bit Rate: 14.492 Mbps
VBV_Buffer: 976 KB
Profile: Main/High
Progressive: Prog or Int
Chroma: 4:2:0
Audio Format: 2.0
Audio Stream Id: AC3: 20 (x14)
Audio Bir Rate: 384 Kbps
Audio Sampling Rate: 48000 Hz

09/01/05 16:51:23

***** Loading: E:\HD Transport Streams\Final Full Blue.tp.mpg


09/01/05 16:51:23 Opening file: E:\HD Transport Streams\Final Full Blue.tp.mpg, filetype is: MPEG2 TS PIDs: x11 / x14
09/01/05 16:51:23 Startup - Number of PTS checks: 8
09/01/05 16:51:24 Bumping mux rate to: 15.000 Mbps to accomodate video bit rate of: 14.492
09/01/05 16:51:24 Bumping mux rate to: 15.000 Mbps to accomodate video bit rate of: 14.492
09/01/05 16:51:24 Horizontal size of: 1920 indicates HD stream. Forcing YUV acceleration.
09/01/05 16:51:24 HDTV material detected, switching on YUV acceleration, width: 1920, height: 1080
09/01/05 16:51:24 Display open status: Using YUV with overlays.
09/01/05 16:51:24 Bumping mux rate to: 15.000 Mbps to accomodate video bit rate of: 14.492
09/01/05 16:51:48 Bumping mux rate to: 15.000 Mbps to accomodate video bit rate of: 14.492
09/01/05 16:58:26 Output complete. Input file: E:\HD Transport Streams\Final Full Blue.tp.mpg
Output file: D:\Final Blue.vrd.mpg
Mode: Frame Accurate
-Video output packets: 2047280
-Audio output packets: 59211
-Padding output packets: 0
Video output frames: 74528
Audio output frames: 77711
Processing time (secs): 394
Processed frames/sec: 189.13
Actual Video Bitrate: 13.32 Mbps
- PTS underflow: 11

09/01/05 17:09:00

***** Loading: D:\Final Blue.vrd.mpg


09/01/05 17:09:00 Bumping mux rate to: 15.000 Mbps to accomodate video bit rate of: 14.492
09/01/05 17:09:01 Bumping mux rate to: 15.000 Mbps to accomodate video bit rate of: 14.492
09/01/05 17:09:01 Horizontal size of: 1920 indicates HD stream. Forcing YUV acceleration.
09/01/05 17:09:01 HDTV material detected, switching on YUV acceleration, width: 1920, height: 1080
09/01/05 17:09:01 Display open status: Using YUV with overlays.
09/01/05 17:09:02 Bumping mux rate to: 15.000 Mbps to accomodate video bit rate of: 14.492
09/01/05 17:09:18 Delay while seeking to: 00:00:00.00
09/01/05 17:09:34 Delay while seeking to: 00:18:51.12
09/01/05 17:09:40 Delay while seeking to: 00:23:49.25
09/01/05 17:10:08 Opening: D:\Final Blue.vrd.mpg in QuickStream Fix Mode.
09/01/05 17:10:08 Opening: D:\Final Blue.vrd.mpg in QuickStream Fix Mode.
09/01/05 17:10:08 Bumping mux rate to: 15.000 Mbps to accomodate video bit rate of: 14.492
09/01/05 17:16:34 Output complete. Input file: D:\Final Blue.vrd.mpg
Output file: E:\Final Blue.vrd.fix.mpg
Mode: Frame Accurate
-Video output packets: 2047257
-Audio output packets: 59209
-Padding output packets: 0
Video output frames: 74527
Audio output frames: 77711
Processing time (secs): 380
Processed frames/sec: 195.70
Actual Video Bitrate: 13.32 Mbps
- PTS underflow: 11

09/01/05 17:16:48 Delay while seeking to: 00:25:09.12
09/01/05 17:16:56

***** Loading: E:\Final Blue.vrd.fix.mpg


09/01/05 17:16:57 Bumping mux rate to: 15.000 Mbps to accomodate video bit rate of: 14.492
09/01/05 17:16:57 Bumping mux rate to: 15.000 Mbps to accomodate video bit rate of: 14.492
09/01/05 17:16:57 Horizontal size of: 1920 indicates HD stream. Forcing YUV acceleration.
09/01/05 17:16:57 HDTV material detected, switching on YUV acceleration, width: 1920, height: 1080
09/01/05 17:16:57 Display open status: Using YUV with overlays.
09/01/05 17:16:58 Bumping mux rate to: 15.000 Mbps to accomodate video bit rate of: 14.492
09/01/05 17:17:11 Delay while seeking to: 00:21:15.19
09/01/05 17:17:18 Delay while seeking to: 00:23:49.24
09/01/05 17:17:26 Delay while seeking to: 00:23:02.17

[DanR]

This should not happen. The output should be perfect and there should no pixelation on the first except if that frame was corrupt on the source file. Can you try again, perhaps creating a small output file to see if its something we did.

Now, the delay while seeking is most likely a result of the fact that this is HD material and the internal timeout value of 5 seconds may not be enough. You can up this value by going to the Help>Enter>Software key and typing: "seektimeout=xx" (no quotes) where xx=number of seconds to timeout when trying to dos a seek.

The user Litz, who frequents this board, has more experience with this than I do so he may be able to give up an optimal setting for the seektimeout.

[Anonymous]

Thanks Dan. Tonight I played the first file (i.e. BEFORE the quickstream fix was applied) and it played absolutely perfectly from the first frame to the last. I don't know what VRD+ didn't like about opening it, but it did a superb job especially by comparison to the other tools I tried, which were supposed to do "error correction" but in the end introduced big-time (visually very noticeable) pixelation & glitches (these were HDTV2MPEG2, ProjectX, and mpeg2repair).

I will do much more testing, but for tonight I am deliriously happy w/VRD! Thanks again...

[laserfan]

Oops your board let me post w/o logging-in. Of course I'm the "Guest" of the previous post.

I wanted to add that I played-back the edited MDP-130 file NOT on the MDP-130 PC, but rather on my Pinnacle ShowCenter SC200 media player, as served by another PC over 100baseT ethernet. That worked great. Did not try playing the file from the 130 though, which I understand from others can be problematic.

I can only say to that, that the file I edited and which played nicely on the SC200 did NOT play without worse visual glitches on the 130. I don't know what that's about, that the card that capped the stream has trouble playing it back? But it must be I'd guess a PC issue somewhere...

[DanR]

We know about the problem playing back files on the MyHD 130 and are still looking at what it will take to address that.

[litz]

This should not happen. The output should be perfect and there should no pixelation on the first except if that frame was corrupt on the source file. Can you try again, perhaps creating a small output file to see if its something we did.

Now, the delay while seeking is most likely a result of the fact that this is HD material and the internal timeout value of 5 seconds may not be enough. You can up this value by going to the Help>Enter>Software key and typing: "seektimeout=xx" (no quotes) where xx=number of seconds to timeout when trying to dos a seek.

The user Litz, who frequents this board, has more experience with this than I do so he may be able to give up an optimal setting for the seektimeout.

This happens when editting video stored on a DVD or a network drive ... it can also happen if you're editting on a remote desktop (due to refresh delays across the network link) ...

Default is 5 seconds, I think ... try 10 or 15 ... you don't want it TOO long, or you may get tricked into thinking the program crashed ...

As for the MyHD, you should not have pixelisation issues on the output .ts ... there's an issue with *field order* on some 1080i material, however ... you'll see a stuttering on movement (pan shots, etc). It's not in the mpeg2, however; if you demux and remux the elementals it goes away.

Dan's working on this, though ... once that's fixed we should be completely golden on .ts output w/the new muxer.

Make sure you check the new ts output options pane; if the autoseek doesn't pick a good bitrate for your muxing you may need to set a static bitrate to avoid underflow.

- litz

[Anonymous]

Sorry, but... WHERE would I change seektimeout?? The dialog for registration??? Pls clarify..

[DanR]

Yes, the dialog for registration. Enter seektimeout=10 into the name field and click on Register Key. If it turns out this will be a commonly changed field we will add it to one of the standard options dialogs.

[laserfan]

Thanks Dan & Litz; I entered seektimeout=8 and it "took". A little later I thought to try opening the VRD+ edited file, the one that yesterday caused VRD to say "needs fixing" and today it opens w/o complaint. I can only think the seektimeout change might have had something to do with it.

I dunno, my 3.2GHz P4 & drives are plenty fast--dunno why the change might be needed, or why it might have helped, or maybe it was a complete coincidence... :?

[Anole]

Change it back and test again.
Inquiring minds want to know. ;)

[Anonymous]

Well, duh. OK, I did it, and of course it opened without error this time, even at 5000ms. No hash, just pure playback pleasure.

Sorry, I know what I saw the 1st time, but I can't explain this. Must be that PEBCAK error again. :oops:

I'm gonna leave it at 5 sec and play some more tonight. Didn't realize I had a hundred gigs or so of HD on my HTPC that I can try next, including especially "The Green Mile", 27Gb w/commercials of course. :shock:

[DanR]

I dunno, my 3.2GHz P4 & drives are plenty fast--dunno why the change might be needed, or why it might have helped, or maybe it was a complete coincidenceNot sure either. Most of our testing is with SD material which is much smaller and faster for testing. We will moving more of our testing over to HD though to insure that "little thing" like those don't ruin the VideoReDo experience.

[litz]

[quote]I dunno, my 3.2GHz P4 & drives are plenty fast--dunno why the change might be needed, or why it might have helped, or maybe it was a complete coincidenceNot sure either. Most of our testing is with SD material which is much smaller and faster for testing. We will moving more of our testing over to HD though to insure that "little thing" like those don't ruin the VideoReDo experience.[/quote

At this point, VRD is pretty bulletproof for HDTV ... the only real glitch remaining is the field order issue that seems to affect VLC, MyHD, and Roku playback.

And even at that, it's not really noticeable unless you have fast motion or panning ...

Once Dan gets that knocked off the list, things should be pretty well set.

- litz

[DanR]

Beta Build 410 has been posted.

See reelase notes for details, but main stuff is:

1) New TS muxer and TS output options. There were lots of changes and this is BETA SOFTWARE. If you are relying on VideoReDo to output TS files, don't delete your originals until you verify the edit results.

2) Ability to specify VLST folder.

3) Preserve closed GOP flags.

4) New COM functions for scene markers manipulation.

[Anonymous]

version 410 when loaded over my licensed/registered copy of 408 required me to reload my license key. I got a popup dialog box that send something about my old key not being valid for this version.

but then when I reloaded the key from my license email. All was well.

[DanR]

Which version was previously installed? Pat is checking this out right now.

[phd]

I checked V410 on my test machine and all is OK.

If anyone else has this issue, please let us know.

[Anonymous]

Which version was previously installed? Pat is checking this out right now.

v408 was loaded previosly. Although I had at one time typed in the "plusoptions-on" string into the license field.

[murrayt]

phd

I have downloaded .410 and have previously enabled plusoptions and tsoutput. The install was fine and no problems with the licence key

[zaphod7501]

Nobody has mentioned it but this version seems to have smoothed out the playback of edited transport streams for the MyHD (MDP130) cards, at least after a few simple tests. Maybe I can finally edit the Battlestar Galactica MiniSeries that has been taking up 16Gb of disk space. I noticed that leaving null packets in increases (unexpected) the original file size while removing them decreases (expected) the file size. Both ways seem to play back smoothly. Still a lot more testing to do, but preliminary results are good.

[litz]

Nobody has mentioned it but this version seems to have smoothed out the playback of edited transport streams for the MyHD (MDP130) cards, at least after a few simple tests. Maybe I can finally edit the Battlestar Galactica MiniSeries that has been taking up 16Gb of disk space. I noticed that leaving null packets in increases (unexpected) the original file size while removing them decreases (expected) the file size. Both ways seem to play back smoothly. Still a lot more testing to do, but preliminary results are good.

Just to clarify - the null packets switch simply selects whether or not null packets are included in the output .ts. Whether they were in the original .ts is irrelevent; Videoredo is remuxing the output from the video/audio elementals; so any input nulls are already tossed.

- litz

[DanR]

I noticed that leaving null packets in increases (unexpected) the original file size while removing them decreases (expected) the file sizeThe null packet issue is an interesting one. All broadcast transport streams probably have some null packets in them to preserve their constant bit rate. Another way to think of it, is that transport streams are a "push medium". Once a signal starts broadcasting you can't start or stop it. If there isn't enough information i.e. video, to fill a time slot then null packets are inserted to even out the bandwidth.

When a signals is broadcast there are often multiple programs in a strream, but only one set of null packets for the entire stream. So, when your card starts recording a single stream to disk there's really no need to store the null packets since they only apply to the entire muxed stream in the aggregate, not to a specific program.

Here's a quick way to determine if there are null packets in your source files. Download and run TSReaderLite (its free). Load your file into the program and look at the packets display. If you see packets with PID 0x1FFF, those are the nulls packets. If you don't see any then they weren't saved to disk.

[laserfan]

I am only a new user of the MyHD MDP-130, but I believe that the software version I'm using always records everything in the broadcast i.e. multiple video, audio, null packets, whatever. I also think that the newest version of the software allows you to select a specific program stream to record.

I only bring this up because I THINK that there could be different results w/different MDP-120/130 users depending on the sw version they are using. Hopefully someone here knows this more concretely than I and can concur/refute as needed. If I'm right, then we MyHD users prolly oughta add software version to our sig...

[litz]

I am only a new user of the MyHD MDP-130, but I believe that the software version I'm using always records everything in the broadcast i.e. multiple video, audio, null packets, whatever. I also think that the newest version of the software allows you to select a specific program stream to record.

I only bring this up because I THINK that there could be different results w/different MDP-120/130 users depending on the sw version they are using. Hopefully someone here knows this more concretely than I and can concur/refute as needed. If I'm right, then we MyHD users prolly oughta add software version to our sig...

With the MDP-120, it only records OTA broadcasts ... and OTA almost always contains null packets. The -130, when recording OTA, behaves the same way. When the -130 is recording QAM off cable, however, it rarely will record nulls, because the cable companies strip them to save bandwidth on their QAM channels.

- litz

[octavian]

I am only a new user of the MyHD MDP-130, but I believe that the software version I'm using always records everything in the broadcast i.e. multiple video, audio, null packets, whatever. I also think that the newest version of the software allows you to select a specific program stream to record.

I only bring this up because I THINK that there could be different results w/different MDP-120/130 users depending on the sw version they are using. Hopefully someone here knows this more concretely than I and can concur/refute as needed. If I'm right, then we MyHD users prolly oughta add software version to our sig...

The last version (1.65.1) of the MyHD software allowed you to record the entire stream for a channel or just the subchannel, which stripped out all other packets including NULL packets. They mainly did this because recording the entire stream with QAM (38.4Mbs) eats about 17GB/hr of hard drive space. The consequence of stripping out all packets but the subchannel you are watching is that it becomes variable, and this breaks time related functions (time status, FF, REW) when playing back on the MPD cards. The good thing about recording just the substream is that the file size is smaller since you are throwing away unecessary information.

The latest version (1.66.0) of the MyHD software tries to make a compromise. You can now record just a subchannel and the software will add just enough NULL packets to make it a CBR (constant bit rate) stream. This fixes time related functions and shrinks the file size.

So here are my questions about the new VRD stream processor:

1. If I load a TS file that is just a subchannel with no other packets, and VRD adds NULL packets, will the output file be 19.2Mbs again?

2. If I load one of the newer TS files that MyHD software generates (subchannel with just enough NULL packets to make it CBR), will VRD add more NULL packets (19.2Mbs) when it saves the edited file?

I would like to keep the file size small a possible.

octavian

[DanR]

VRD doesn't care whether NULL packets are present or absent in the input file. We demux everything down to elem. streams anyway.

Now, when we remux back to TS, you can specify the bit rate (19.2) or let VRD figure it out automatically. Manual is better because we tend to be conservative and may create a larger file. So if the file is 19.2Mbps to begin with we will not add more NULL packets. Now, the exact packet counts may be different because of the way we pack packets vs. the way the original broadcaster did. For example, the broadcaster may choose not to start each video frame in its own packet like VideoReDo does.

You can also choose to omit NULL pakcets, but then the file won't be pure CBR.

[litz]

I am only a new user of the MyHD MDP-130, but I believe that the software version I'm using always records everything in the broadcast i.e. multiple video, audio, null packets, whatever. I also think that the newest version of the software allows you to select a specific program stream to record.

I only bring this up because I THINK that there could be different results w/different MDP-120/130 users depending on the sw version they are using. Hopefully someone here knows this more concretely than I and can concur/refute as needed. If I'm right, then we MyHD users prolly oughta add software version to our sig...

The last version (1.65.1) of the MyHD software allowed you to record the entire stream for a channel or just the subchannel, which stripped out all other packets including NULL packets. They mainly did this because recording the entire stream with QAM (38.4Mbs) eats about 17GB/hr of hard drive space. The consequence of stripping out all packets but the subchannel you are watching is that it becomes variable, and this breaks time related functions (time status, FF, REW) when playing back on the MPD cards. The good thing about recording just the substream is that the file size is smaller since you are throwing away unecessary information.

The latest version (1.66.0) of the MyHD software tries to make a compromise. You can now record just a subchannel and the software will add just enough NULL packets to make it a CBR (constant bit rate) stream. This fixes time related functions and shrinks the file size.

So here are my questions about the new VRD stream processor:

1. If I load a TS file that is just a subchannel with no other packets, and VRD adds NULL packets, will the output file be 19.2Mbs again?

2. If I load one of the newer TS files that MyHD software generates (subchannel with just enough NULL packets to make it CBR), will VRD add more NULL packets (19.2Mbs) when it saves the edited file?

I would like to keep the file size small a possible.

octavian

The answer is ... kinda.

VRD is going to stuff null packets if the "nulls" switch is set, regardless of the presence or absence in the source file ... in other words, VRD simply doesn't care if they're there or not.

What WILL happen, is it will pad out your remuxed file to match either the scanned max bitrate, or the manually entered CBR bitrate. If you select the scanned max bitrate, it will scan the file, try to determine a max bitrate, then mux to THAT bitrate (which becomes the new header bitrate) and add nulls as appropriate.

If you set a manual CBR bitrate (ie: 19.2mb/s), it will add appropriate nulls to padd out to THAT bitrate, and it becomes your new header bitrate.

Note : you can CHANGE the header bitrate this way. You can also set the bitrate in the OUTPUT options as well, which operates on the mpeg2 video stream *prior* to muxing, and this changes the header bitrate as well (it will affect the "scan" function.

So --- long story short ... if you want ATSC standard, set the CBR value of 19.2 and output away. VRD will fill in the nulls as needed and you're all set.

- litz

[Barbar]

Dan,

can confirm beta 410 has fixed open GOP issue with DVDLab Pro.


Many tks

Barbar

[laserfan]

So --- long story short ... if you want ATSC standard, set the CBR value of 19.2 and output away. VRD will fill in the nulls as needed and you're all set.
I dunno if I follow all of this, but it is disturbing to me, as I've been using an earlier version of the MyHD software and VRD has worked great with it, with no-muss, no-fuss other than having to select the stream I want out of it:

1. Select program streams out of multi-program ATSC recording of 19.2Mbps

2. Edit-and-save using VRD resulting in mpg file around 14Mbps

3. Play on ShowCenter SC200 perfectly and experience extreme joy

What concerns me is this "null-packet padding" especially as I'm TOLD that the SC200 (Sigma EM8620 chip) should not handle bitrates >15Mbps. I actually have played my original 19.2 files with it fine.

Anyway I'm worried that if I upgrade MyHD to 1.66 and VRD to 410, life gets more complicated? Guess I should stop wringing my hands and try it. But for the moment I only have 19.2 files to use for testing.

[DanR]

What WILL happen, is it will pad out your remuxed file to match either the scanned max bitrate, or the manually entered CBR bitrate. If you select the scanned max bitrate, it will scan the file, try to determine a max bitrate, then mux to THAT bitrate (which becomes the new header bitrate) and add nulls as appropriate

Litz, a correction to your statement. We don't change the max bit rate in the MPEG header unless you specifically request it with the options button in the File Save dialog.

[Anonymous]

If I save my video project to .mpg, do I automatically delete the null packets in the original .ts stream? Or does the omit null packets checkmark make any difference when saving to mpg program stream format?

[DanR]

We store .mpg files as variables rate files. There are no null packets.

We do introduce some padding at:

1) End of each frame, but only is the "Start Frame in a new packet" on Tools>Options>Stream.

2) We always start each new GOP in its own packet, so that can result in small (<1%) amount of padding.

[DanR]

Beta Build 412 has just been posted:

New support for crid file processing. To enable auto-concatenate and CRID processing:

1) Enter "beta-on" (no quotes) into the name field of Help>Enter Software Key.

2) This will enable the new Tools>Plus Options dialog where you can setup auto concatenate and CRID processing.

Other minor changes as well as some COM functions for Harry who will probably be releasing some new add-on tools.

[DanR]

Build 414 has been posted.

CRID users: You can rename or QSF a CRID by right clicking on the program name. List can be sorted by name or record date by clicking on column headers. Click again and it will sort in decesnding order.

Caution on renames. It will overwrite the existing CRID. Be careful until you test this completely. Backup your CRID files first.

DVR-MS: Better detection of AC3 stream.

TS output: Final Audio packets / frames were not being flushed from our internal transport muxer buffer. Sequence header bit rate now different from bit rate used at encoding.

[wwjd]

What is CRID?

[DanR]

The Siemens M740 AV DVB-T receiver / DVR saves transport streams in a somewhat strange format. Each program has a CRID file which contains the meta data (program names, record time, etc) and a pointer to filenames that contain the actual program audio and video. CRID files are named like: 0001E3FAC083_110955420010022.crid.

The VRD CRID processing reads the contents of the CRIDS and lets the user open the program by program title rather than an indecipherable filename.

[wwjd]

Dan,

Thanks!

[the_tom]

Beta version 414 will not even open transport files captured by MyHD (MIT MDP-130 board, s/w versions 1.65 or 1.66). Depending on how I try to open it, I either get a message box immediately "Unable to open video file xxx.tp", or the mouse pointer changes to an hourglass but nothing else happens.

So, I can't tell you if there is any change in the playback problem with this h/w...

[zaphod7501]

I've had no problems with MyHD files -- unless I have the auto-combine feature turned on -- and I have several recordings from the same day -- on different channels. VRD will try and combine them all when creating the VLST but hangs up because they can all be at different formats (720p, 1080i, 480i). Your problem could also be related to the specific station you are editing.

If you are trying to edit "on-demand" QAM channels you need to capture ALL subchannels or else you will be trying to open a file that changes characteristics in the middle unless you were real lucky. Even MyHD can crash if you are recording a single subchannel and it switches programs during the recording.

I do have one particular QAM64 channel that has one subchannel that nothing but the MyHD can open, but I've been waiting to mention it since it is 1 subchannel on 1 QAM64 channel and I was far more interested in the UHD solution.

[DanR]

If you are trying to edit "on-demand" QAM channels you need to capture ALL subchannels or else you will be trying to open a file that changes characteristics in the middle unless you were real luckyYou might want to try the QSF filter option on this channel. It should be able to flter out the PIDs and video dimensions changes quite nicely.

[jpasarela]

Same problem here opening MPD-130 transport streams with both 413 and the 414 beta. I just get the "Unable to open video file xxx.tp" dialog. The auto combine feature makes no difference either way. I'm using the 1.66 MPD-130 drivers.

[DanR]

You can either run QuickStream Fix and see if that makes a difference, or,
use Trim and Copy to create a small clip of the original and upload to our FTP site: ftp://upload:upload@videoredo.net

If you do upload, please put the file into its own folder and send us an email at support@videoredo.com letting us know that the file is there.

[jpasarela]

QuickStream Fix says its not an MPEG program stream, so I did the trim and copy and uploaded it to the FTP server. Email sent.

[DanR]

Can you try enabling the "Ignore TS program maps" on the Tools>Options>Screen page? That lets us open this file.

We are still searching why the file didn't open with the proper program map mode.

[the_tom]

I've had no problems with MyHD files ...

If you are trying to edit "on-demand" QAM channels you need to capture ALL subchannels ...




I see that perhaps I was not clear or not complete. I have had no problems opening with VRD, MyHD HD transport files captured from cable QAM single sub-channels, with the prouction version of VRD, but the beta 414 will not even open them - even the very same file that I just processed with the poduction version. IMO this makes it quite clear that the VRD beta is broken, and my message was/is to report that.

OTOH, with the production version of VRD, after I cut out commercials and save to a new file (mpeg mixed program streams or transport stream) and playback through the MyHD, the playback is jittery - just enough to be irritating and clearly damaged in comparison to the original. I had hope that the MyHD v1.66, which says it now captures constant bit rate even on single sub-channel captures, might impact this - but it does not as far as I can see.

I have tried two of the recent beta versions of VRD, hoping that changes and/or new options would benefit, but neither one can even open the files - even the very same files that I have just processed with the production version.


[Dan, I hope I am making this clear now - the current series of VideoRedo Beta versions are broken in that they will not even open MyHD capture files that the production version has no problem with!]

[DanR]

Which production version are you using? There was nothing recent that we know of should cause this, but once we know which version worked we can do a code comparison to find out what changed.

Also, did you try using enabling the Ignore Program Maps on the Tools>Options>Stream Page?

Also, is there a specific channel that exhibits this problem?

[DanR]

This particular thread is getting out of hand. It was always intended to be devoted to our announcements with discussions processed in other threads. So from now on, we will restrict this thread to Beta Annoucements. Please post your questions and issues in other topics within the beta forum.

Thanks for the cooperation.

[DanR]

Build 416 has been posted. Please see new topic for release info. This message is posted for those who are being notified by email when a post is made to this thread.

Make sure you put a "watch this thread" on the new 416 thread as well.