Jump to content

New Server - Bob & Weave


roberto188

Recommended Posts

roberto188

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?

Link to comment
Share on other sites

roberto188

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. 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 1 month later...

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 by softworkz
Link to comment
Share on other sites

roberto188

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.

Link to comment
Share on other sites

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 by softworkz
Link to comment
Share on other sites

roberto188

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. 

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

  • 1 month later...
roberto188

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. 

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

  • 2 years later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...