Maintaining Interlacing

[Aegwyn11]

I'm workign on trying to set something up to do a few things and am a bit lost. I want to use AVISynth and FFmpeg to do side-by-sides of two clips, then archive the output as lossless. Using various AVISynth tools (Crop, StackHorizontal), I'm able to do most of it pretty easily. My sources are 1080i and I'd like to maintain the interlacing if possible.

I can't figure out two things:
1) How to get the output of AVISynth to be flagged as interlaced (per -vf showinfo in FFmpeg)
2) How to store interlaced as something lossless that FFmpeg can encode (I've been using FFVHuff and whenever I encode something using it, the resulting file is always flagged as progressive)

[pandy]

http://avisynth.org/mediawiki/AssumeFrameBased

If codec doesn't exploit interlace/progressive relation then You need to flag video by yourself after decoding.

[Mounir]

.Avi don't have an interlaced/progressive flag and thus the decoder always assume it is progressive (default behaviour) , only if you use x264 with mbaff it'll work. Staxrip can do that

[pandy]

AVI is not a codec - some of the codec are progressive only (designed to compress only non-interlace), some are interlace/progressive (those one usually have flag for interlace/non-interlace), some are transparent (lossless) because they don't use dependencies between fields (ie it is not important if this is progressive or not).

[Guest]

AVI is not a codec - some of the codec are progressive only (designed to compress only non-interlace), some are interlace/progressive (those one usually have flag for interlace/non-interlace). Specifically, referring to the AVI spec, what is this flag you are talking about? I am not aware of any such flag in the AVI specification, nor does Avisynth support an interlaced/progressive indication [it's not the same as AssumeFrameBased()/AssumeFieldBased()].

[pandy]

Specifically, referring to the AVI spec, what is this flag you are talking about? I am not aware of any such flag in the AVI specification, nor does Avisynth support an interlaced/progressive indication [it's not the same as AssumeFrameBased()/AssumeFieldBased()].

I'm saying that AVI is NOT a codec (but container) - i assume that interlace/progressive is signaled at the video codec level not at the container level.

If video codec is designed to deal with progressive video then it is hard to expect flag for interlace,
If codec is interlace/progressive then You can expect flag for interlace/progressive.
For lossless codec flag seems to be not critical.

Question was how to encode video with keeping flag (by using correct encoder which respect progressive/interlace), how to compress interlaced with lossless codec designed for progressive without flag.

And this can be done or as a sequence separated fields or as sequence interlace frames.

Which one is better it is up to topic author, all he need to do after decoding is to restore correct sequence (and if necessary re-lace) stream.

[Guest]

I'm saying that AVI is NOT a codec (but container) - i assume that interlace/progressive is signaled at the video codec level not at the container level. Nobody is claiming that AVI is a codec. Avisynth offers no flag to specify interlaced/progressive. Therefore, the answer to the OP's first question is that it is not possible, just as Mounir pointed out.

You specifically offered AssumeFrameBased(), but it has nothing to do with interlaced/progressive indication.

[StainlessS]

The interlace flag in eg UT Video codec, allows codec to choose best method for compression
of given source, and informs decoder to decompress using same method. It is for more efficient
compression rather than as a flag to anything other than the decoder. (EDIT: I think).

[pandy]

Nobody is claiming that AVI is a codec.


? Seems that there is some missing SYNCWORD.


Avisynth offers no flag to specify interlaced/progressive. Therefore, the answer to the OP's first question is that it is not possible, just as Mounir pointed out.

You specifically offered AssumeFrameBased(), but it has nothing to do with interlaced/progressive indication.

If i read correctly Mounir mention ".Avi" - is there NEW meaning for this construction or it is just overall description for AVI container files?

Im replying that even with lost flag (from various reason) interlace structure and correct order can be keep/restored in AVISynth thanks to mentioned syntax.
Flag is different thing and it is related to internal OS structure - like for example in Windows = then perhaps ffdshow can be used with forced flag at the output.

[Guest]

I find your last post to be unintelligible and therefore impossible to properly respond to, other than to say yet again that there is no flag to be lost in the first place and that your cited Avisynth syntax has nothing to do with a progressive/interlaced indication. And now I leave it to the readers to draw their conclusions.

[Wilbert]

Perhaps you guys are referring to the misuse of AssumeFieldBased when passing the script (being field-based stuff) to x264: http://forum.doom9.org/archive/index.php/t-153965.html and http://www.videohelp.com/tools/x264-Encoder/version-history (r1540) ???

[pandy]

I find your last post to be unintelligible and therefore impossible to properly respond to, other than to say yet again that there is no flag to be lost in the first place and that your cited Avisynth syntax has nothing to do with a progressive/interlaced indication. And now I leave it to the readers to draw their conclusions.

Don't be so rude especially that i think that You talk about something different than i (thus my comment about syncing lost somewhere) - i've read once again what started this topic - i don't see any reference to .Avi mentioned by Mounir thus don't blame me about starting discussion about avi.
I don't know what mean when Mounir write ".Avi" - i think about AVI container.

i can write once again - from my perspective AVI is a container, interlace flag is signaled at codec not container level when codec support such flag (ie video codec is designed to support interlace/progressive). Signaling flag to the OS (VfW?) is a completely different story.

English is not my native thus sorry for probably not clear expressing myself - reading your reply i would say that you understand me completely wrong.

[Guest]

Wilbert is correct that AVIsynth offers meta-data that can be misused to signal progressive/interlaced. But there is no way to set that meta-data automatically from an indication from the AVI interface, because such indication DOES NOT EXIST. Sure you can manually set the AssumeFrameBased()/AssumeFieldBased() indication to misuse it as a progressive/interlaced indication (as long as you are willing to hack other tools, such as x264, FFMPEG, etc.), but how is it better than manually setting interlaced/progressive on your x264 command line?

[Aegwyn11]

So a few questions/comments based on what I'm seeing. Bear with me as I'm sure my terminology is probably off (I live in the TS world).

1) The interlaced flag seems to be carried at the elementary stream level. If I take the original files and open them in MediaInfo, change to sheet view, and select the video stream, I can see the interlaced flag. If I take that file and create an AVI with FFmpeg (using -c:v copy), I can see the same flag in the resulting AVI.

2) If AVISynth will only spew out frames flagged as progressive, thats fine and I can understand that (AVISynth spews out raw video as I understand it, and raw video is neither interlaced or progressive..its just frames of video). In that case, I just need some help forcing FFmpeg to treat them as interlaced. I tried -top 1 and -vf fieldorder=tff on the input and neither seem to do anything.

3) Do FFVHuff or FFV1 support the interlaced flag?

[Guest]

1) The interlaced flag seems to be carried at the elementary stream level. Yes, some ES can signal whether the picture was encoded with field or frame structure. But this is not the same as indicating whether the content is progressive or interlaced. This is a subtle but important point. Many encoders simply use field structure for everything, and it is also common to pick the structure dynamically per picture for maximum compression, irrespective of the progressive/interlaced nature of the content.

If I take the original files and open them in MediaInfo, change to sheet view, and select the video stream, I can see the interlaced flag. If I take that file and create an AVI with FFmpeg (using -c:v copy), I can see the same flag in the resulting AVI. If you embed such an ES in an AVI container, then you can theoretically access it, though AVISynth does nothing in this regard. But again, it doesn't tell you whether the content is progressive or interlaced.

2) If AVISynth will only spew out frames flagged as progressive, thats fine and I can understand that (AVISynth spews out raw video as I understand it, and raw video is neither interlaced or progressive..its just frames of video). In that case, I just need some help forcing FFmpeg to treat them as interlaced. I tried -top 1 and -vf fieldorder=tff on the input and neither seem to do anything. I don't know about FFMPEG. Hopefully someone can help you with this.

3) Do FFVHuff or FFV1 support the interlaced flag? I believe there is no ES flag in such cases, and AVI has no flag.

[Aegwyn11]

Yes, some ES can signal whether the picture was encoded with field or frame structure. But this is not the same as indicating whether the content is progressive or interlaced. This is a subtle but important point. Many encoders simply use field structure for everything, and it is also common to pick the structure dynamically per picture for maximum compression, irrespective of the progressive/interlaced nature of the content.

So what you're saying is that there are encoders that use field encoding for progressive sequences? I've never heard of that and not quite sure how that would work.

[Guest]

So what you're saying is that there are encoders that use field encoding for progressive sequences? No, not for progressive *sequences*; for progressive *content*.

In other words, the encoder doesn't know or care if the fields are sampled from different moments of time (which is the real definition of interlaced *content*, which is what you care about).

Encoding progressive content with field structure is very common, as I said, and so is adaptive field/frame structure that ignores the content and tries only to optimize the compression.

My point is that ES flags cannot be trusted to tell you whether the *content* is interlaced. I suppose that's hard to swallow, but it's true.

[pandy]

So what you're saying is that there are encoders that use field encoding for progressive sequences? I've never heard of that and not quite sure how that would work.

He say that You can't fully trust on what is signaled at the end of chain and You can't trust (or rather decoder) for what is signaled at the ES level (i mean neuron point of view in concentrated on absolute video quality).

And yes in broadcast to make easier change (ie one fixed setup not touched for few years) - encoder is set as interlaced (and frequently this can be seen today when in Europe they broadcast video with opposite field dominance)

But anyway You must follow flag signalization for some aspects of coding (like case for chroma sample location which for many video codecs is different for interlace and for progressive).

So neuron talking about motion but also some other aspects are important (and motion seems to be quite easy to detect).

But once again - everything is dependent from codec type, and You can set manually LOST interlace/progressive in Avisynth - (only You need to know what You doing).

Flag in OS (ie passing flag from app to app is a different story).