New Server - Bob & Weave

[roberto188 33]

I just moved from the version 3 to 4 windows server. It appears that the new server doesn't respect the "bobandweave" de-interlace method. The interlaced channels are only transcoding at 30 fps. Is this feature not available for the new server?

[Luke 42077]

Yea this is not implemented right now.

[roberto188 33]

I don't mean to be a thorn in the side but how is this not part of the version 4 server? It's 1 line of code to get this to work and as mentioned before, without it, live TV is essentially useless on virtually all Roku Devices. I just don't understand why features that were once part of Emby, like 60 fps encoding and NVENC presets were REMOVED when the new version of the server was rolled out. In regards to transcoding, Live TV should be the number 1 priority as any other media stored on the Emby server should be properly formatted for direct streaming anyway. Live TV comes in a variety of formats that the user cannot control, as such the transcoding development efforts should really be geared towards that. As such, the bobandweave feature really needs to be implemented. I guess i'll just stick with the version 3 server for now. Thanks. 

[Luke 42077]

It's not 1 line of code. We have rewritten all of our transcoding and this has to be looked at from scratch again.

[roberto188 33]

Fair enough. Thanks. 

[roberto188 33]

Bump. Any progress on this? Again, kinda makes watching TV nauseating if you don't have 60fps.

[Luke 42077]

Not yet, sorry.

[softworkz 5066]

I don't mean to be a thorn in the side but how is this not part of the version 4 server? It's 1 line of code to get this to work and as mentioned before, without it, live TV is essentially useless on virtually all Roku Devices. I just don't understand why features that were once part of Emby, like 60 fps encoding and NVENC presets were REMOVED when the new version of the server was rolled out. In regards to transcoding, Live TV should be the number 1 priority as any other media stored on the Emby server should be properly formatted for direct streaming anyway. Live TV comes in a variety of formats that the user cannot control, as such the transcoding development efforts should really be geared towards that. As such, the bobandweave feature really needs to be implemented. I guess i'll just stick with the version 3 server for now. Thanks. 

 

@@roberto188

 

First I should clarify that there doesn't exist a "bob and weave" deinterlacing method. This was incorrectly named in earlier Emby versions.

Instead, these are the most basic opposite deinterlacing methods:

• bobbing means to output one frame for each field by doubling (or interpolating) its lines to construct a frame (effectively also doubling the frame rate)
• weaving means to construct one frame from a pair of fields, optionally applying certain algorithms to avoid comb artifacts

So, what you are talking about is 'bobbing'.

 

The option for this had been phased out from Emby Server v3 even before the release of v4. It was no longer visible in the UI and as you already noted, it has been finally dropped in v4.

 

It has been dropped for quite a list of reasons, but here's the most general one: With v4 we have taken support for hw acceleration to a new level and in that new model, there is no room for doing frame doubling or frame rate modifications in general. As a consequence, it's unlikely that "bobbing" will be re-introduced.

 

It's incorrect to assume that bobbing is "the good method" and Emby is now left to employ some inferior deinterlacing.

 

I'd rather suspect that there's some other problem causing the bad deinterlacing results you're seeing, so it would be best if we could go over an example.

Edited November 15, 2019 by softworkz

[roberto188 33]

I appreciate the reply but this response makes live TV dead on arrival for Roku's or any other device that can't deinterlace. It's this simple, if the device can't deinterlace, like a Roku, than 30i TV stations are going to look like blurry messes forever. I guess I'll just have to stick to the old version 3 server forever to watch sports or anything else that moves.

 

Also it's simply false to say it can't be implemented for hardware accelerated encoding. NVENC and quicksync both allows field rate deinterlacing when transcoding.

 

But I appreciate the honesty in abandoning a required feature for live TV.

[softworkz 5066]

Also it's simply false to say it can't be implemented for hardware accelerated encoding. NVENC and quicksync both allows field rate deinterlacing when transcoding.

 

This is correct, but I didn't say that it can't be implemented for Nvenc and QuickSync.

 

 

We DO deintelacing - just not bobbing. If you could post an ffmpeg log from a playback situation where you are seeing inferior (or no) deinterlacing, we'll be able to a have a closer look.

Edited November 15, 2019 by softworkz

[roberto188 33]

It's not that there is NO deinterlacing being done. It is done. The issue is that 30i content sent directly to a TV via OTA signal or to a STB displays the video at 60fps, because of the STB or TVs internal deinterlacer. When I say 60fps, I mean 60 UNIQUE frames per second. When Emby transcodes 30i to 30p, you are seeing 30fps, which for fast motion like sports, looks like a smudgy smeary mess. Thus the need for BOB for interlaced content when being sent to progressive only devices like the Roku. Sounds like it won't be implemented, so I won't belabor the point. I'll check to see what the Plex guys are doing. 

[softworkz 5066]

Sure, good luck with their support..

 

You need to understand the situation as it appears to me:

• We're rarely seeing complaints about deinterlacing quality
  (most issues in this area are about whether DI is applied or not, but not about the quality when it's working)
  .
• You are probably the first and only person asking for the bobbing method after it had been removed
  (at least I haven't seen any other)
  .
• You refuse to work with us on the problem
  (most likely there is one and we need to find out what it is) 
  .
• Instead you're stomping your foot on the ground saying you want bobbing

I don't know how to respond to that.

All I can say is that my offer to work with you on this issue still stands. 

[roberto188 33]

Sorry I missed this reply. I'm not sure what information you need from me to get feature enabled. My request is pretty simple and if the answer is, we simply aren't going to do it, then that's a fine answer, but I am not refusing the help. 

Let me be as clear as possible. Field rate de-intinerlacing is REQUIRED when transcoding interlaced television into progressive format. When a TV receives an interlaced signal, it FIELD RATE DE-INTERLACES the image so that 60 UNIQUE frames are displayed to the viewer. This is why a person can watch sports in 30 frames interlaced format and it is of satisfactory quality. EMBY does NOT do field rate de-interlacing. EMBY'S transcoded interlaced TV streams are at 30 fps progressive format, which is an UNACCEPTABLE frame rate to watch any sort of sport. Here are two samples.

 

 

Make sure you select 1080p 60fps to see the 60fps sample.

 

You can clearly see that in the 30 fps video there is ALOT of blur when the camera moves or when the players move. It is nauseatingly unwatchable and the 60fps sample other looks just like real live television. 

If there is anything further you need to understand the issue, please let me know. 

[Luke 42077]

Thanks for the feedback.

[softworkz 5066]

@roberto188  - Thanks for the examples, it was very helpful to get an understanding of what you're referring to as a "bluriness mess".

 

Now, we need to categorize the impact of this in the context of all other transcoding operations.

Transcoding video always involves a tradeoff between quality, bandwidth and processing power.

The best option is always "direct play", where the original media data is passed on to the client without modification.

 

When we do transcoding, there's currently no support for frame-doubled (bob) deinterlacing. I know that we had some experimental switch for this a while ago, but it had caused quite a number of hard-to-find problems and it wasn't implemented in a consistent way (e.g. only for sw but not for any hw transcoding), also there aren't any checks in our clients about whether they're supporting frame-rates of 50 or 60 at all.

 

We're currently re-working our transcoding setups based on the feature-range that we're currently supporting.

 

Once we're done with that, we will re-visit and re-evaluate a number of special transcoding cases and I can promise at least, that yours will be one of them.

 

Thanks,

 

softworkz

[roberto188 33]

I understand. Thank you very much I appreciate it!

[Kocane 14]

Is this still not implemented?

[coffee47 3]

@softworkzSorry to reopen an old thread, but this is truly a deal breaker for many users.

Right now, I have to re-encode all live TV broadcasts in TvHeadend before sending them to Emby — which may then transcode the exact same stream again.

Jellyfin already supports this feature, even with hardware-accelerated workflows. I always thought Emby was supposed to be the best media server — especially with DVR support (which is the only reason I’m paying for Premiere at the moment) — yet six years later, there’s still no way to properly deinterlace content at double the frame rate (something every TV and set-top box does by default). This makes watching sports, like soccer, almost unbearable. And you always notice the difference between bobbed and weaved video outputs.

So yes — even if you don’t classify this as a “playback error,” it absolutely is one.
In my point of view, this can easily be implemented by just adding a few parameters into the ffmpeg-pipeline (because that's what I do in TVHeadend, both with VAAPI and NVDEC/Cuda).

BR, Coffee47

[softworkz 5066]

@coffee47- Did you check out the deinterlacing options in the new Windows app?

(because that's the forum for it)

[arrbee99 1815]

So if I may be bold enough to enquire, to deinterlace LiveTV 1080i (or whatever) do I actually need to look at his setting or should default be OK ?

[coffee47 3]

On 10/29/2025 at 1:07 AM, softworkz said:

@coffee47- Did you check out the deinterlacing options in the new Windows app?

(because that's the forum for it)

Hi, 

thanks - I haven’t looked into it yet.

Please excuse me for posting in the wrong forum; it just seemed to be the most technically informed discussion about this ongoing issue. Would you recommend to start a new thread on this topic in the General section, or could you perhaps comment on my question here?

 

Because these options do not exist (however definitely should) on the server or alternative clients like iOS/tvOS/Tizem.

 

BR coffee 

 

[softworkz 5066]

11 hours ago, coffee47 said:

Please excuse me for posting in the wrong forum; it just seemed to be the most technically informed discussion about this ongoing issue. Would you recommend to start a new thread on this topic in the General section, or could you perhaps comment on my question here?

There are two places where de-interlacing can happen: 

• At the server, when transcoding
• At the client when receiving the original video stream

That's why I didn't immediately split and move your posts.

 

11 hours ago, coffee47 said:

Because these options do not exist (however definitely should) on the server or alternative clients like iOS/tvOS/Tizem.

The options for the Windows app are specific to the Windows app and are provided by D3D11 video acceleration (backed by driver implrementations of the GPU vendors).

At the server side, we currently do not support deinterlacing with doubled-up framerate.

[coffee47 3]

8 hours ago, softworkz said:

There are two places where de-interlacing can happen: 

• At the server, when transcoding
• At the client when receiving the original video stream

That's why I didn't immediately split and move your posts.

 

The options for the Windows app are specific to the Windows app and are provided by D3D11 video acceleration (backed by driver implrementations of the GPU vendors).

At the server side, we currently do not support deinterlacing with doubled-up framerate.

Okay, thanks. I am referring to the server side deinterlacing. Is this a planned feature or should we not expect this at all any time soon?

Alternatively is there a way for us to manually change the server sided ffmpeg command pipeline?

 

[Luke 42077]

On 11/2/2025 at 8:10 AM, coffee47 said:

Okay, thanks. I am referring to the server side deinterlacing. Is this a planned feature or should we not expect this at all any time soon?

Alternatively is there a way for us to manually change the server sided ffmpeg command pipeline?

 

The diagnostics plugin has a search and replace feature that you can use for testing purposes.

[coffee47 3]

5 hours ago, Luke said:

The diagnostics plugin has a search and replace feature that you can use for testing purposes.

Hi Luke,

I already have looked into that and although it looks very promising, this way of doing it is missing the ability to search/replace two segments of text.

For bobbing (these examples were done on my QuickSync server), we'd need to replace:
-filter_complex "[0:1]vpp_qsv@f1=deinterlace=advanced[f1_out0]" to "[0:1]vpp_qsv@f1=deinterlace=bob:fps=50[f1_out0]"
which works fine. However later in the ffmpeg command, we have 
-r:v:0 25 which would also need to be changed to -r:v:0 50.

Is there any hidden syntax or am I missing out on something, because these are in seperate parts of the command and the part in the middle can change.

Alternatively, I would be happy to develop a corresponding plugin to enable all kinds of other deinterlacing options if you would provide me with the resources to do so (probably the source code of the search/replace part of the diagnostic plugin or other ways (a better way) to mess with the transcoding pipeline from a plugins perspective).

I'm very sure a lot of people in the community would appreciate a way of doing that, although not officially supported and experimental. 

 

BR, Coffee