Lagarith or x264 lossless?

[pandy]

I like what you're doing and development is a great idea. But can any hardware even decode lossless x264 streams? Last I checked , even many software decoders had issues decoding it, let alone chips that are limited to a certain profile or even DXVA. Right now, I'm not aware of any chips that can encode lossless x264 either... (other than CPU)

This is some concept how to workaround with limitation for x264 - only for desperate people willing to archive something for future (maybe better) times.

I think that lossless decoding can be done in FPGA for pro-applications - so maybe i can imagine situation that someone collecting or store some streams on HDD then decode them in a different place (time) - returning to the RGB is quite easy to implement on FPGA.

[2Bdecided]

Is a VHS capture with Lagarith TFF or BFF?

In what sense TFF or BFF - AFAIR VHS record one full FRAME (both fields) one tape with help of the drum with heads thats revolve 25 times per second (for 25fps systems).

"Because VHS is an analog system, VHS tapes represent video as a continuous stream of waves, in a manner similar to analog TV broadcasts. The waveform per scan-line can reach about 160 waves at max, and contains 525 scanlines from the top to the bottom of the screen in NTSC (480 visible). PAL variants have 625 scanlines (576 visible). In modern-day digital terminology, VHS is roughly equivalent to 333x480 pixels."

http://en.wikipedia.org/wiki/VHS

No, not at all - VHS stores a stream of individual fields - which is exactly what analogue broadcast video consists of.

In the analogue world, it's not strictly correct to say either field is first - it depends where you start looking at the stream!

However, there are standard conventions for line numbering (1-525 and 1-625), and for editing ("always" cut in the VBI near line one) which means NTSC is bottom field first, and PAL is top field first.

Almost all digital representations of such analogue video signals maintain this convention in the pairing of fields into digital frames (NTSC=BFF, PAL=TFF). As already mentioned, DV doesn't (it makes PAL BFF - either by field shifting or simply moving the content down by one single line - or originating it as BFF DV in the camera itself).

AFAIK Lagarith neither knows nor cares what the field order is. The standard AVI container doesn't flag progressive vs interlaced, tff vs bff, aspect ratio, etc etc.

MPEG has flags for some of this stuff, but (mostly) they can be wrong without affecting the stored video - i.e. you could simply ignore any wrongly-set flag on playback to get the "correct" result, without any harm at all.

Hope this helps.

Cheers,
David.

[jagabo]

The capture device (or driver) determines the field order when capturing an analog signal. It can start with a top field then add the next field, a bottom field; or it can start with a bottom field then add the next field, a top field. Two different devices capturing the same video can give different field orders.

DV devices always capture bottom field first. In my experience, most other devices capture top field first.

[jagabo]

And a note to anyone contemplating Pandy's methods of losslessly encoding RGB or YUY2 sources with x264: in the future you won't be able to simply open the resulting files in an editor. You'll have to convert them back to a standard RGB or YUY2 format before you can use them.

For example, for a 720x480 RGB source:

AviSource("stackedRGB.avi")
red=Crop(0,0,720,480)
green=Crop(720,0,720,480)
blue=Crop(1440,0,720,480)
MergeRGB(red, green, blue)

[pandy]

In what sense TFF or BFF - AFAIR VHS record one full FRAME (both fields) one tape with help of the drum with heads thats revolve 25 times per second (for 25fps systems).

No, not at all - VHS stores a stream of individual fields - which is exactly what analogue broadcast video consists of.

Sorry, my mistake - drum with heads revolve with field speed ie for PAL-like it is 50 revolutions per second. (but i put AFAIR )

BTW - I've just founded: http://www.ronaldsnoeck.com/vcr.htm nice page for VCR description

[pandy]

And a note to anyone contemplating Pandy's methods of losslessly encoding RGB or YUY2 sources with x264: in the future you won't be able to simply open the resulting files in an editor. You'll have to convert them back to a standard RGB or YUY2 format before you can use them.

But of course - I think that this is obvious - it is only dirty hack to use x264 to compress RGB losslessly and nothing else.
So it is a solution only for a real desperado .

[sphinx99]

Thanks for the posts clarifying TFF/BFF for me. Sadly I appear to be even more confused than before. It sounds like the raw video I capture from SVHS is interlaced coming into the computer and into the Lagarith encoder, but Lagarith itself doesn't know how to include information about the nature of the video stream, which means I am responsible for telling a program that uses this footage about its nature.

The problem is that I'm still not sure what to say - most programs that input video want to know (a) is it interlaced or progressive and (b) if interlaced, BFF or TFF? It sounds like if I capture VHS or SVHS or Video8 or Hi8 to disk encoded in Lagarith, I should always make sure the playback tool knows that the material is interlaced, but that I don't really need to worry about BFF or TFF and can just pick one. True/false?

[jagabo]

It sounds like the raw video I capture from SVHS is interlaced coming into the computer and into the Lagarith encoder, but Lagarith itself doesn't know how to include information about the nature of the video stream

AVI doesn't have a field order flag. Lagarith has no way of flagging field order either.

which means I am responsible for telling a program that uses this footage about its nature.

Yes.

The problem is that I'm still not sure what to say - most programs that input video want to know (a) is it interlaced or progressive and (b) if interlaced, BFF or TFF? It sounds like if I capture VHS or SVHS or Video8 or Hi8 to disk encoded in Lagarith, I should always make sure the playback tool knows that the material is interlaced, but that I don't really need to worry about BFF or TFF and can just pick one. True/false?

No, you need to tell the editor the correct field order. Determining the field order of your video is easy in VirtualDub. Open the lagarith (or other) video in VirtualDub. Add the Bob Doubler filter. Select either TFF or BFF , and Bob options. Step frame-by-frame through a section of video with motion. Watch the output window. If the motion moves smoothly from field to field you got the correct field order. If you see a two-steps-forward- one-step-back type motion, or any other backwards steps, you picked the wrong field order. The wrong field order on the left, the right field order on the right:

[danno78]

I get always TFF when a capture with capture cards regardless of codec used or name of card, even I a use DV codec. For me rule is always TFF with one exception when is DV file captured from camcoder via firewire. Another exception may be with file from DVD. These can be either TFF or BFF.

[sphinx99]

Thanks jagabo for the very helpful post and simple test. My captures are clearly TFF near as I can tell but I am going through to verify.

Is there any chance that a dropped frame (according to VirtualDub) could cause field order to switch midstream in a capture?

[jagabo]

Is there any chance that a dropped frame (according to VirtualDub) could cause field order to switch midstream in a capture?

Not really. Although I've heard talk of capture cards that might miss a field then swap between TFF and BFF. I've never seen that myself and I would think it's rare.

The obvious two-steps-forward-one-step-back cadence is for purely interlaced (60 fields per second) video. With hard telecined film you will only see two backward jumps every 10 fields when the field order is wrong. There will also be many repeated fields as there are only four different film frames in every 10 fields. When the field order is right there will be repeats on a 2:3 pattern -- AABBBCCDDD...

[2Bdecided]

Not really. Although I've heard talk of capture cards that might miss a field then swap between TFF and BFF. I've never seen that myself and I would think it's rare.

I've had it with a crappy Dazzle card.

I've also seen a couple of samples shared by others that show this from dodgy VHS and 8mm captures - sometimes it's the TBC rather than the capture card that drops the frame by one line and causes it.

Cheers,
David.

[pandy]

Not really. Although I've heard talk of capture cards that might miss a field then swap between TFF and BFF. I've never seen that myself and I would think it's rare.

Sadly it is quite common and can be observed currently many times that people that making video mixing TFF and BFF - it happen frequently even in really good European TV (in terms of technical care about quality and standards for video broadcast) like for example German ZDF (or few Dutch broadcasters).

I blame for this people the new (Youtube) generation of video engineers - they "don't feel" interlace... so be prepared to strange combination's of TFF and BFF incorrectly signaled - probably they use US software which is BFF default - Europe use TFF.