<p>I don't know about the specific format of mjpeg that you are working with, but it is certainly possible to handle interlaced video with mjpeg.  I believe the most common way is to do a jpeg per field, so you get half the vertical resolution and alternate between the odd and even fields.</p>

CC BY-SA 3.0
2014-02-28T19:02:08.873Z
2014-02-28T19:02:08.873Z
AJ Henderson
<p>I think VirtualDub will fix those headers.</p>

<p>Simply download VirtualDub from <a href="http://virtualdub.sourceforge.net/" rel="nofollow">here</a>, unzip it and drop the file into it. A popup is going to be showed telling you if you want that VirtualDub fixes it for you.</p>

CC BY-SA 3.0
2014-06-12T13:25:57.020Z
Huh? This answer doesn't tell me anything about the mjpeg internals...
isync
CC BY-SA 3.0
2014-05-15T22:42:42.110Z
2014-05-15T22:42:42.110Z
Joaquin Iurchuk
<p>I'm using mencoder/libav to capture an interlaced source to mjpeg.</p>
<p>Now, my hunch is that mjpeg is a codec that handles only full-frames, progressive video - because I assume it compresses single (full-)frames as jpeg. How would it handle the &quot;half frames&quot; of interlaced video??</p>
<p>Am I wrong? Did the mjpeg developers take that into account and figured out a way to properly keep the interlaced aspect of interlaced video when stored as mjpeg?</p>
<p>Or is my hunch correct and I am unknowingly &quot;sort of&quot; de-interlacing my material?</p>
<blockquote>
<p>To encourage answers, my thoughts on this are:</p>
<p>Ok, Motion-JPEG compresses each frame as a jpg, more or less. Right? Then, how is interlaced material handled? Let's assume it vertically merges/compresses each half-frame from the &quot;lined&quot; state into what looks like a non-interlaced image and then compresses that as a jpeg. Well, then, the (possibly heavy) smearing/blocking/blurring of normal jpeg would kick in and the lines would bleed into each other. On reassembly of the interlaced picture-stream, separating the lines again, this blur then would end up in the final re-interlaced video. Resulting in a loss of quality a native, interlaced-capable codec wouldn't have introduced... At least that's my hunch, as I don't know anything about the internal workings of mjpeg (what probably became obvious above). Prove me wrong.</p>
<p>More encouragement: eye-candy: <img src="https://i.sstatic.net/VJjb5.jpg" alt="enter image description here" /> This is a screenshot-section, from a mjpeg encoded interlaced video. And even though this image itself is again jpeg encoded (at q=85%), the &quot;bleeding&quot; of lines into each other is not that bad. Could be, jpeg resolution at average compression ratios is good enough to resolve the &quot;lines&quot;, and I am worrying about nonsense. Still, technical details anyone?</p>
</blockquote>

CC BY-SA 3.0
2013-10-16T13:25:01.797Z
Using the words "properly" and "interlaced" in one sentence is basically a contradiction in itself. The whole idea of interlaced video is nothing but a historical artifact. You should try to get to an all-progressive workflow.
leftaroundabout
CC BY-SA 3.0
2013-10-17T17:55:31.383Z
(Got the irony.) I know. And would love to. BUT: I am doing archiving here, and the source material is interlaced. Keeping the "interlaced aspect" of the material is part of authentically storing it. So my question remains: Is mjpeg fit to store interlaced video? (And deinterlacing is no option, for me.)
isync
CC BY-SA 3.0
2013-10-20T13:06:29.287Z
To refine your question: proper handling would be if the JPEG artifacts remain within an interlace field, but do not span over the interlace lines, right? Because this would be all there is to it when handling interlacing. The video codec has nothing else to do with it.
Paul Hänsch
CC BY-SA 3.0
2013-10-20T13:12:41.000Z
If you are archiving video for historical reasons, I'd recommend you use the FFV1 codec from the ffmpeg suite, which is Free Software. FFV1 is lossless therefore artifacts in interlacing is not an issue. Its output files are a little bigger than with mjpeg, though I have seen smaller results as well, depending on video material. Also there are different understandings of the mjpeg format by different vendors, FFV1 is clearly specified and since the source code is available, it can be ported to future computer platforms. Public archives in Austria, Canada and Australia are already using FFV1.
Paul Hänsch
CC BY-SA 3.0
2013-10-23T13:21:57.143Z
@paul-hansch: You summed it up well! I hope as well that mjpeg more or less treats scan-lines as singular jpeg data streams, so blurring only happens horizontally - but how would mjpeg encode that into valid single frames, as it does? So I think (fear) it doesn't care about the "lined, half-frame state".
isync
CC BY-SA 3.0
2013-10-23T13:25:07.090Z
@paul-hansch: Yes, FFV1 is great, and in one pipeline I do rely on it heavily. Yet, in another pipeline, "the quick, low datarate" one, I use mjpeg as a "mezzanine" codec and I keep asking myself if that is a poor choice...
isync
<transcoding><codec>
Does mjpeg handle interlaced video correctly?
isync
# Does mjpeg handle interlaced video correctly?

(Asked by: username_0 on 2013-10-13)

I'm using mencoder/libav to capture an interlaced source to mjpeg.

Now, my hunch is that mjpeg is a codec that handles only full-frames, progressive video - because I assume it compresses single (full-)frames as jpeg. How would it handle the "half frames" of interlaced video??

Am I wrong? Did the mjpeg developers take that into account and figured out a way to properly keep the interlaced aspect of interlaced video when stored as mjpeg?

Or is my hunch correct and I am unknowingly "sort of" de-interlacing my material?

> To encourage answers, my thoughts on this are:
>
> Ok, Motion-JPEG compresses each frame as a jpg, more or less. Right? Then, how is interlaced material handled? Let's assume it vertically merges/compresses each half-frame from the "lined" state into what looks like a non-interlaced image and then compresses that as a jpeg. Well, then, the (possibly heavy) smearing/blocking/blurring of normal jpeg would kick in and the lines would bleed into each other. On reassembly of the interlaced picture-stream, separating the lines again, this blur then would end up in the final re-interlaced video. Resulting in a loss of quality a native, interlaced-capable codec wouldn't have introduced... At least that's my hunch, as I don't know anything about the internal workings of mjpeg (what probably became obvious above). Prove me wrong.
>
> More encouragement: eye-candy: ![enter image description here](https://i.sstatic.net/VJjb5.jpg) This is a screenshot-section, from a mjpeg encoded interlaced video. And even though this image itself is again jpeg encoded (at q=85%), the "bleeding" of lines into each other is not that bad. Could be, jpeg resolution at average compression ratios is good enough to resolve the "lines", and I am worrying about nonsense. Still, technical details anyone?

**Tags:** transcoding, codec

> **Comments:**
> **username_1**: Using the words "properly" and "interlaced" in one sentence is basically a contradiction in itself. The whole idea of interlaced video is nothing but a historical artifact. You should try to get to an all-progressive workflow.  
> **username_0**: (Got the irony.) I know. And would love to. BUT: I am doing archiving here, and the source material is interlaced. Keeping the "interlaced aspect" of the material is part of authentically storing it. So my question remains: Is mjpeg fit to store interlaced video? (And deinterlacing is no option, for me.)  
> **username_2**: To refine your question: proper handling would be if the JPEG artifacts remain within an interlace field, but do not span over the interlace lines, right? Because this would be all there is to it when handling interlacing. The video codec has nothing else to do with it.  
> **username_2**: If you are archiving video for historical reasons, I'd recommend you use the FFV1 codec from the ffmpeg suite, which is Free Software. FFV1 is lossless therefore artifacts in interlacing is not an issue. Its output files are a little bigger than with mjpeg, though I have seen smaller results as well, depending on video material. Also there are different understandings of the mjpeg format by different vendors, FFV1 is clearly specified and since the source code is available, it can be ported to future computer platforms. Public archives in Austria, Canada and Australia are already using FFV1.  
> **username_0**: @paul-hansch: You summed it up well! I hope as well that mjpeg more or less treats scan-lines as singular jpeg data streams, so blurring only happens horizontally - but how would mjpeg encode that into valid single frames, as it does? So I think (fear) it doesn't care about the "lined, half-frame state".  
> **username_0**: @paul-hansch: Yes, FFV1 is great, and in one pipeline I do rely on it heavily. Yet, in another pipeline, "the quick, low datarate" one, I use mjpeg as a "mezzanine" codec and I keep asking myself if that is a poor choice...  

---

## 2 answers

### Answer by username_3 on 2014-02-28. Score: 2

I don't know about the specific format of mjpeg that you are working with, but it is certainly possible to handle interlaced video with mjpeg. I believe the most common way is to do a jpeg per field, so you get half the vertical resolution and alternate between the odd and even fields.


---

### Answer by username_4 on 2014-05-15. Score: 0

I think VirtualDub will fix those headers.

Simply download VirtualDub from [here](http://virtualdub.sourceforge.net/), unzip it and drop the file into it. A popup is going to be showed telling you if you want that VirtualDub fixes it for you.

> **Comments:**
> **username_0**: Huh? This answer doesn't tell me anything about the mjpeg internals...  

---

