Jump to content

Poor quality when transcoding and time scrubbing


TopSideControl

Recommended Posts

  • 2 weeks later...

I think I found it.  The expression only works correctly if we started in the beginning of the file.  If we don't, n_forced starts as one (for the first keyframe inserted), while t (time) is likely significantly higher than n_forced*3.  For example, if we seek 30mins into a file, the time is going to be 1800secs, which is a lot higher than 3, so it's generating keyframes until n_forced*3 "catches up" such that it's greater than or equal to the time of a given frame.  The farther you seek, the longer that string of forced keyframes will be.

 

Here's an expression that should work better:

expr:if(isnan(prev_forced_t),eq(t,t),gte(t,prev_forced_t+3))

Can you replace Emby's expression with the above in your command line tests and see if it helps?

 

What it does is check to see if we've previously forced a keyframe (the isnan(prev_forced_t) part).  If not, then it checks to see if t=t, which of course it does, so it forces a keyframe.  This should happen immediately and, once we force one keyframe, prev_forced_t should contain a time from that point on.  If we did force a keyframe before, it checks to see if the current frame's timestamp is greater than or equal to the previous keyframe's timestamp plus 3 (secs) - if this is true, it'll force a keyframe and prev_forced_t will be set to that frame's time...and the process continues.

 

I really wish we had access to the exact framerate in this particular expression rather than just frame numbers and timestamps since we could be a lot more precise, but we don't.  It's also probable that we'll run into slight rounding errors with the time, since it's somewhat ham-handed approach.  I may have a way to overcome that, but I have to review ffmpeg's docs and code to see what functions are available to me.  One idea I had was to reset the timestamps after the seek and just use the original expression, but that has some side effects that might be...undesirable...so that's out.

 

I still need to verify that the expression works in all situations (seek vs. starting from the beginning) and that the output has the proper keyframe/GOP layout, so I won't recommend any changes quite yet....I just want to see if my results match up with yours.

 

@@Waldonnis are you still feeling optimistic about this? thanks.

Link to comment
Share on other sites

My own testing has gone well. I can put this into a beta release and the testers can play with it.

Link to comment
Share on other sites

Waldonnis

Yep.  I tried a few tests not long after that and couldn't think of any conditions where it would fail (usual disclaimer applies).  Worth beta testing for sure, and should actually improve transcode performance a tiny bit when seeking is involved.  The I/O impact will be lower since it won't be generating 1-frame segments, and the encoder won't be spending the extra cycles keyframing everything for several minutes of runtime.

  • Like 1
Link to comment
Share on other sites

  • 5 months later...
Rohanaj

What I'm not sure of is how the subtitle overlay is affecting the encoder and output.  Subtitle overlays often make scenes more difficult since they introduce hard edges, as well as making motion estimation harder (halo artifacts are sometimes noticed in these cases).  I don't think it shouldn't have too great an effect on the bitrate such that it greatly increases the chances that a given scene will exceed the bitrate limit (only on how hard the encoder has to work)...unless they got crazy with them and used subtitle streams for effects (I have seen this, believe it or not) or are more complex.  Those types of subtitle image uses are quite rare, though.

 

It's a puzzle, that's for sure.  If a manual transcode with the same settings seemingly differs in quality, then I'm just not sure what else to look at outside of maybe the browsers or video drivers (if acceleration is used by the browsers).  On a side note, if burning in subtitles is the only time you really need to transcode and this continues to be a problem, then it may be worth finding SRT subs for your files (or converting them yourself), since nearly everything can handle those without having to burning them in.  Unfortunately, doing so is really not an option for some languages...and some anime subs would be nigh impossible to convert, so there are cases where this wouldn't be possible (and SRT is limiting when it comes to formatting/layout).

 

At the risk of trying to revive an older thread, I've done some searching and looking through the forum for more information on the hit that picture quality takes when turning on subtitles.  It appears it's popped up a few times in the past year, but this thread appears to have the most info revolving around it, even though I know a big piece of this thread was dealing with the image quality of skipping around in time in streams.

 

Anyway, I've always extracted and done an OCR conversion to SRT for subtitles from my Bluray-source encodes since PGS doesn't encode optionally into mp4 containers, and those of course don't cause transcoding.  However, when it comes to dvd-source encodes, I've taken the route of just embedding VobSub subtitles since it's much more convenient, and with those there's a noticeable quality shift in video when turning those embedded subtitles on (which then transcodes) in Emby.  As far as overall transcoding, I haven't noticed any issues with video quality due to transcoding for other reasons, only when it comes to the embedded subtitles.

 

@@Luke, is this still an item that is being looked at from the development side, or am I possibly just being dumb and missing a server setting somewhere that would help adjust for this?  Also, if I should have posted this as a new thread, I apologize.

 

As a sidenote, does @@Waldonnis or anyone else have a suggestion on what you use to extract VobSub subtitles for OCR purposes in case I'm feeling masochistic and think about redoing tons of embedded subtitles?  The extractor I use for Bluray subtitle data doesn't pull VobSub out.

Link to comment
Share on other sites

Rohanaj

I’m sorry Luke, I think I misinterpreted your reply in this thread I found - https://emby.media/community/index.php?/topic/52559-subtitles-and-vedio-quality-problem-need-to-be-fixed/?hl=%2Bsubtitle+%2Bquality - as being related to the subtitle transcoding quality.

 

My issue seems like it’s similar to the #2 transcode quality item the original poster in that thread had, but I see now that you were referring to his #1 item at that time.

 

I’ll get you more in-depth info and logs this weekend.

Link to comment
Share on other sites

Ok yes please attach the requested info when you can. This is an old thread now so it is best to take a fresh look at it. Thanks.

Link to comment
Share on other sites

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...