STB Firewire (IEEE-1394) Support

[Naylia]

Good idea, I'll give that a shot tonight. Just for reference when I try tonight, does VLC accept file types other than transport streams?

[jvheitz]

Yes, VLC can open various file types. I suggest using ver 0.8.2 (prior versions were not as stable with live stream)

[Naylia]

Damn, I was just about to withdraw that question. I got off my lazy a** and googled for 'vlc'. Now that was rough.

[jvheitz]

Try playing the stream directly from the capture device (you will have to click refresh to see the device in VLC).
Good luck!

[spaceghost]

DFA,
Orderd that USB-UIRT today..

[Naylia]

Info from an SD capture:

Num. of picture read: 197
Stream type: MPEG-2 MP@ML VBR
Resolution: 720*480
Aspect ratio: 4:3 Generic
Framerate: 29.97
Nom. bitrate: 8500000 Bit/Sec
VBV buffer size: 112
Constrained param. flag: No
Chroma format: 4:2:0
DCT precision: 10
Pic. structure: Frame
Field topfirst: Yes
DCT type: Field
Quantscale: Nonlinear
Scan type: ZigZag
Frame type: Interlaced

Info from an HD capture:

Num. of picture read: 219
Stream type: MPEG-2 MP@HL VBR
Resolution: 1920*1080
Aspect ratio: 16:9 Generic
Framerate: 29.97
Nom. bitrate: 25000000 Bit/Sec
VBV buffer size: 488
Constrained param. flag: No
Chroma format: 4:2:0
DCT precision: 10
Pic. structure: Frame
Field topfirst: No
DCT type: Field
Quantscale: Nonlinear
Scan type: Alternate
Frame type: Interlaced
Notes:

Info for Digital SD:

Num. of picture read: 408
Stream type: MPEG-2 MP@ML VBR
Resolution: 720*480
Aspect ratio: 4:3 Generic
Framerate: 29.97
Nom. bitrate: 15000000 Bit/Sec
VBV buffer size: 112
Constrained param. flag: No
Chroma format: 4:2:0
DCT precision: 10
Pic. structure: Frame
Field topfirst: Yes
DCT type: Field
Quantscale: Nonlinear
Scan type: Alternate
Frame type: Interlaced
Notes:


So guys, anyone notice anything out of the ordinary that would cause the regular SD to run at a faster pace (both audio and video) than the digital SD and the HD?

Everything looks solid. The only real difference I noticed is in the Scan Type. HD and Digital SD use Alternate while Analog SD uses ZigZag. Anyone know anything about this?

[travisbell]

Like others have said, I would see if you have the same problem using an app like CapDVHS. Do a test recording, see if your still in chipmunk city The .mpg file CapDVHS creates isn't a true .mpg... it's a .ts so make sure to use something like PowerDVD to play it.

Also, I am wondering (on an extremely slight possibility) if some of the analog stations you are watching are really 24 fps. When switching through, the framerate is not changing so your stuck at 29.97 fps and voila, you have chipmunks. Both 24 & 29.97 are NTSC standard frame rates.

I dunno, unlikely.. but maybe possible?

Cheers,

[DFA]

Quite a lot of activity since I last looked.

Travisbell, et. al.:
I have not found any bugs with SGR and seems to have all the necessary features needed for "universal" application. The "broken" graph is normal behavior when two things are trying to access components (filters and devices) simultaneously; this is the nature of the DirectShow beast. For example, if you try to edit the graph with Graphedit while SGR (1.05) is open, even if the graph is not running, the "STB Tuner Device" and "TS Info Parser" will be shown as disconnected. Graphedit, or ANY other application, can not connect to a filter that is already participating in some other graph. Anders has provided an update that SGR will now unload the graph on a Sage "stop" command rather than just stop the graph. I am out of town and unable to try the new version but I should think would have a speed penalty.

The SGR only loads and runs the the graph. How well the graph works is dependent on filter selection and filter behavior which SGR has no influence on one way or the other.

Again, if trying to change channels directly to STB w/o Sage controlling that process, the Sage "audio rendering error" may likely occur. This is because the discontinuity in stream transition (change in video and audio PID values) that come with channel change are not masked from the graph and the recording process that should otherwise be handled with file breaks. It is the playback graph (Sage) that will balk at the recorded discontinuity. For example, note that Sage creates a new file every time you leave and return to the same channel while the same show is airing (Show-EPG_ID-Level.mpg). A new file is opened each time with the next higher increment in "Level". This is important because if Sage tried to just append to the original first file, a discontinuity would be created that would cause playback errors. Individual files are and need to be created for each stream "interuption" that occurs. Directly changing channels at the STB for an "aways on" encoder such as the Firewire link, short circuits the ending and creating file process.

Without a USB-UIRT or some other Girder compatable emitter to control channel change so that the SGR can work as intended (contolled by Sage), YOU WILL HAVE PROBLEMS. Recording stream discontinuities in MPEG2-PS streams is death.

Naylia:
Your issue has more to do with how the STB is encoding and the current filters being used. Try TSReader Lite to analyze the streams. I did a lot of preliminary work analyzing the TS streams from the STB before even trying to build a first graph. There are other tools as well to help first identify what you are dealing with. If you would like to PM me and send a recorded clip, I will have a look at it when I return.

Dane

[travisbell]

Dane,

Anders new stop modification fixed all of my problems. I can switch channels on my STB, put it to sleep, record.. all without error. It's working quite well now.

Cheers,

[AndersNolberger]

If "seeker/fast_mux_switch=true" a switch command is sent to SGR on channel change. I don't reload the graph on that but if "seeker/fast_mux_switch=false" Sage sends a stop and a start to SGR. On the stop I free the graph and on the start I reload it. If you are going to use the new "UnloadGraphOnStop=1" make sure to have fast mux turned on to get speedy channel changes.

Another question to thoose that use SGR in Sage. When a new program begins Sage sends a switch to SGR with a new file name. Does Sage continue to play the new file as it should or does it hang/pause at the end of the old file?

The reason I ask is that I get that behaviour in my tests with BDA. One possible reason could be the way I report back the file size to Sage and I do that in the same way for SGR as for SBDAR. Since it is a filter in the graph that saves the file to disk my program does not have information about how many bytes have been written to disk. So I have to ask the file system for the size of the file. The problem is that the file system is reporting the wrong file size! It is always a bit after the actual file size and reports 0 for a long time. To compensate for that and get the playing going I actually lies to Sage and report 1000 bytes to Sage when the file system say 0. This is not very nice and something I have been aware of the whole time but I thougt I could try and I have not gotten any bug reports on this.

If anyone have information about how I could get the correct file size I would be very greatful. Perhaps there is some function in the dump filter that I could ask about how many bytes have been written? How does SageRecorder do this? Can anyone from Frey perhaps help me?

[Naylia]

Originally Posted by travisbell

Like others have said, I would see if you have the same problem using an app like CapDVHS. Do a test recording, see if your still in chipmunk city The .mpg file CapDVHS creates isn't a true .mpg... it's a .ts so make sure to use something like PowerDVD to play it.

Also, I am wondering (on an extremely slight possibility) if some of the analog stations you are watching are really 24 fps. When switching through, the framerate is not changing so your stuck at 29.97 fps and voila, you have chipmunks. Both 24 & 29.97 are NTSC standard frame rates.

I dunno, unlikely.. but maybe possible?

Cheers,

I'll try CapDVHS tonight. I tried VLC 0.8.1 last night and the picture looked miserable on all types of stations. This was the highest version number I could find for Windows. I should have taken some screen caps, but there was a lot of chaff. Some sections of the screen looked perfect while others looked all pixelated with bad information. This happend with both SD and HD when viewing in VLC.

With regards to framerate, that's exactly how it feels. That it's 24 fps and it's beinig played at 29.97. That even jibes with roughly how much faster a clip plays compared to how long I expect it to take.

Dane,

I'll try TSReaderLite also and try to dig up some more information about the streams and get in touch with you when you're back.

[jvheitz]

You can get the latest nightly build of VLC here:
http://vthr.via.ecp.fr/~videolan/build/win32/
0.8.1 did not work very well for me either, but when I grabbed the latest (at the time 1/12) that did the trick. See if you have the same problem when viewing live stream with VLC.
Then try to record with CapDVHS and view the captured stream.
That should help you narrow down the problem somewhat.

[DFA]

Naylia:

Here's a shot in the dark for you. Close SGR and start Graphedit and open the graph that SGR uses. Note the clock in the MS DeMux filter. The use of the internal DeMux clock is selectable (use or don't use). If selected, the clock dial is yellow and if not, grayed out. If currently selected, try unselecting and vise versa. If using the CL dump, you'll note that it also has a selectable internal clock. However, only one or the other of those two filters respective clocks can be active at one time. They both can be deactive.

DFA

[travisbell]

Naylia:

I was encoding some of my shows to Divx earlier today and noticed that most of the shows on ABC, NBC, CBS & FOX are in fact 24 fps while everything on my movie channels is 29.970. When I was encoding, I have a preset profile to use 29.970 (I thought all HD was 29.970) and was getting wait.. you guessed it chipmunk syndrome. I am not saying how and what is affecting your system since mine and Duane's graph changes properly but it certainly sounds like an FPS problem to me.

Let us know how your recordings from CapDVHS go.

Regards,

[spaceghost]

I just tried (using capdvhs) to capture a test sample from analog channels and digital channels thru the 6412. They play fine(analog channels look horrible on Motorola's box..at least on the 6412). Noticed capdvhs shows you the framerate while it's capturing. Also noticed my cable co sends out 720x480 for the analog stations, and 528x480 for the digital. WMP lists ALL of these as 960x480, even the 720x480 files. Media player classic lists the resolution correctly.

[Naylia]

HAHA It works!!! I'm not being screwd over by my cable company!! Well unfortunately it's time for bed, but at least I'll sleep like a baby knowing that my input is good and I just need to build an appropriate graph.

I used the tonights version of VLC and was able to watch analog and digital SDTV, and HDTV. Hip Hip Hooray! Tommorrow I'll try capdvhs and TSReader to start looking at stream info.

Dane, clocking the Mux had no effect and clocking the dump made things worse. Good idea though. I'm whittling away at it and getting closer at least.

Thanks everybody!

Spaceghost - How's the quality of your input signal? Most of my analog SDTV is actually pretty decent, but I don't have a pvr card to compare to so I can't really do any comparison testing.

[spaceghost]

analog thru my PVR-250's looks better. I've read on lots of other forums about the 6412 having terrible output for the analog stations. It's true. Guess it has something to do with the way it samples it? Looks horrible both captured thru the FW and out the component video @ 1080i. Tried to have the STB output 720p, but looked worse. Better for me to have my PJ convert it.
Got another 6412 upstairs on a SD tv and it's hooked up via svideo...looks fine up there.

Hints for Capdvhs-uncheck everything except:
Convert 188 bytes
check PTS
Delete to SyncByte

Then use the Data Info tab to see what it's capturing....

[DFA]

Anders:

Relative to file size feedback, I have not experienced any issues that I could attribute to the bit of trickery employed there. After a channel change or graph start, there is a period of "rocking" (speed increase / slowing) for HD channels that takes a while to stabalize (+/- 10 secs). I suspect that this is a Mux issue and have done some work at isolating it. I mention this in case you think it could have anything to do with dynamic file size feedback to Sage.

Since the release of 1.05, I have been using SGR continuously and successfully with no issues other than mentioned above which I attribute to the graph at this point in time. I have tried 1.06 but notice no difference and expected none since working for me w/o issue anyway.

As you are aware, I have a fully implemented SGR installation which includes channel control. Version 1.06 helps those that do not have channel control. As I had mentioned to you in previous correspondence, closing and restarting SGR remedies this problem by resetting the dump filter file name to its default "null" name. Unloading/loading the graph accomplishes this in an automatic way. With version 1.05, if I disable channel control, I experience the same issues reported by others ("Audio renering error" and Sage lockups) when attempting to make channel changes direct to STB rather than through Sage as is normal and customary. However, these issues disappear once channel control by Sage / SGR is utilized and file name changes at the dump filter kicks in.

As of yet, I am not aware of any other full implementations of SGR. So not yet much information on synchronous control of dump fiter file name and STB channel change other than what I can report. I have not noticed any hang or pause at time of flle ending other than what is intended by the "TuningDelay" feature and the Sage "videoframe/network_encoding_to_playback_delay" parameter. The "Tuning Delay" feature eliminated the problem of recording the stream transition discontinutiy at the beginning of the file which would fault Sage's playback graph.

Are there any others out there that are not particapating in posting that have complete installs? If so, it would be valuable to hear feedback on your experiences.

DFA

[Naylia]

Minor hitch CapDVHS exhibits the same problem as my graph does...chipmunk syndrome. It reports the same info as above.

Bitrate 8500000
FPS 29.97
Res 720x480
Ratio 4:3

[spaceghost]

Naylia-
what program are you using to play back the captures?

So if I understand it correctly, your live feeds play back in normal time. Your captures played back off the hard drive play too fast. Right?