Jump to content

Chapter image extraction issues


jmos1277
 Share

Recommended Posts

jmos1277
Chapter image extraction is a great feature and works on most of my MKV files.  However, I have a bunch of MKVs in my Movie library on which chapter image extraction fails.  There are a number of reasons why this might occur, including the case where some chapter markers are beyond the end (or right at the end) of a video file.  I have already fixed those in my library.

 

However, I still have other MKV files on which chapter image extraction fails and I haven’t been able to determine the root cause  (~100 MKV files).  I decided to look through the MediaBrowser server code to see what ffmpeg command is used to generate the images.  After stitching together the various pieces of the command, I ran it from the command line in both Windows 7 and OS X Mavericks.  The command I issued from the Windows command line is below:

 



C:\Program Files\ffmpeg\bin>ffmpeg.exe -ss 260 -i “\\Media\Movies\Moon (2009)\Moon (2009).mkv" -threads 0 -vframes 1 -vf "thumbnail,crop=min(iw\,ih*dar):min(ih\,iw/dar):(iw-min(iw\,iw*sar))/2:(ih - min(ih\,ih/sar))/2,scale=600:600/dar" -f image2 "C:\Users\HTPC\Desktop\tmp.jpg"


 

Oddly enough, the command works fine when I run it from the command line.  However, it still fails when run behind the scenes by MediaBrowser3 on the same video file.

 

Would it be possible for a future release of MediaBrowser3 server to log the exact command passed to ffmpeg and the output of ffmpeg for any file that fails chapter image extraction?  Currently, the log file simply reports that chapter image extraction failed (first using the i-frame method and subsequently using the standard method).  Logging ffmpegs output would really help in determining why image extraction seems to work when I run it manually, but not when MediaBrowser3 runs the command.

 

Final notes:

I am running the latest beta release of MB3.

I am running the latest version of ffmpeg [build Version: git-785dc14 (2014-01-15)]

MKV files were all generated using MakeMKV and run through mkvmerge.  ALL MKV files that have chapter image extraction issues in MediaBrowser3 seem to have been processed with mkvmerge v5.0.0 or earlier.  Of course, remember that I can successfully extract chapter images from these very same MKVs when running ffmpeg manually.

 

 

 

Link to comment
Share on other sites

i don't have any plans to change that right now. Due to the sheer number of executions logging all of that would have an impact on a process that is already slow to begin with. We could make settings to turn on logging them temporarily but I don't know when we'd be able to get to that.

 

@@Tikuf can give some insight as to why they fail sometimes. His suggestion is generally to try remuxing it with mkvmerge.

Link to comment
Share on other sites

jmos1277

i don't have any plans to change that right now. Due to the sheer number of executions logging all of that would have an impact on a process that is already slow to begin with. We could make settings to turn on logging them temporarily but I don't know when we'd be able to get to that.

 

@@Tikuf can give some insight as to why they fail sometimes. His suggestion is generally to try remuxing it with mkvmerge.

 

Thanks for the reply Luke.  All of the problem MKVs have already been remuxed with mkvmerge (v5.0.0 or earlier).  Last night, I also tried remuxing one of those again with mkvmerge (v6.5.0) but didn't seen any change in the behavior of the chapter image extraction.  Maybe I'll try again with mkvmerge v6.7.0 which was just release about two weeks ago.  I doubt that will make any difference.

 

I'm will also try re-ripping some of my MKVs to see if that fixes anything.  However, I was hoping for a solution that wouldn't require me to re-rerip 100+ MKVs -- particularly since most of my discs are boxed up and buried in storage.  

Link to comment
Share on other sites

Yea we have a two-pass image extraction process that is pretty resilient and generally one of the two will produce an image. But inevitably it's still going to fail on some files. you might want to try running from source with the debugger so that you can see the generated command line.

Link to comment
Share on other sites

jmos1277

Yea we have a two-pass image extraction process that is pretty resilient and generally one of the two will produce an image. But inevitably it's still going to fail on some files. you might want to try running from source with the debugger so that you can see the generated command line.

 

Thanks Luke .. maybe I'll try that.  It'll take me some time to get things setup for that.  I don't currently have Visual Studio installed.  If I'm going to take that route, I might as well create and compile a modified version of MB3 server that actually does report the output of the image extraction process.  I can run that in a test environment on some known-bad MKV files and see what the results looks like.  This might be enough to get the info I need to either repair the MKV files or come to the realization that maybe I do have to re-rip them.

 

If I have time tonight I'll see what I can find out.  I'll report back if I come up with anything.

  • Like 1
Link to comment
Share on other sites

@@jmos1277 check in the webclient and see where the chapter extraction fails (it is listed as a failure even if one image fails) . Grab the chapter time of the last image shown and try to seek past that point with ffmpeg (using the command you have above) -ss XXX  where XXX is equal to the the number of seconds. If there is an error ffmpeg should report it in the cmd window.

Link to comment
Share on other sites

jmos1277

Yea we have a two-pass image extraction process that is pretty resilient and generally one of the two will produce an image. But inevitably it's still going to fail on some files. you might want to try running from source with the debugger so that you can see the generated command line.

 

 
Ok, so I spent the better part of last night installing Windows 7 in a VM, installing Visual Studio 2012, and digging into the MediaBrowser source.  What I really wanted was simply to see the stderr output of ffmpeg for the MKV files on which chapter image extraction failed.  The theory, of course, was that the stderr output would tell me what went wrong during the extraction process.  I played around for a while, logging different things, including the output of ffmpeg.
 
Eventually, I discovered the problem and it had nothing to do with ffmpeg not working as intended. Instead, I noticed that ffmpeg didn’t always run to completion.  The process that is forked off to run ffmpeg is given a 10 second timeout.  It SEEMS like this should be plenty of time ... and it is in most cases.  However, there seem to be some MKVs on which extracting an image takes more than 10 seconds and the ffmpeg process is terminated before it has a chance to complete.
 
This perfectly explains the behavior that I was seeing (i.e. ffmpeg image extraction works fine from the command line but not from MediaBrowser3).  Obviously, this is because when I run ffmpeg from the command line it is not given any time limit.  It simply runs until it’s done.
 
Anyway, I modified the default timeout value in the StartAndWaitForProcess method in MediaBrowser.Server.Implementations/MediaEncoder/MediaEncoder.cs.  
I upped it from 10000 ms to 30000 ms, recompiled and ran it on my test library.  
private bool StartAndWaitForProcess(Process process, int timeout = 30000)
 
This seems to have fixed ALL of my remaining chapter image extraction issues.  A 30 second timeout value seems long.  However, this is simply a timeout value, not necessarily the actual time that it will take to extract images from a video file.  In most cases, the ffmpeg process will complete and exit in much less time so this shouldn’t really affect the time it takes to generate chapter images for an entire library (unless a library has a lot of bad video files).
 
Is upping the default timeout value from 10 seconds to 30 seconds something that can make it into a future release?  It’s only a single character that needs to be modified and I don’t really see this modification as having any major adverse consequences.
Edited by jmos1277
Link to comment
Share on other sites

That's when it works. The flip side is sometimes it fails and just stalls, and then people complain that their library scan is taking forever. I might be willing to go to 12. We'll see.

Link to comment
Share on other sites

jmos1277

That's when it works. The flip side is sometimes it fails and just stalls, and then people complain that their library scan is taking forever. I might be willing to go to 12. We'll see.

 

20?   :unsure:

Communicating with a NAS can slow things down a bit.

Link to comment
Share on other sites

jmos1277

Ok, I take it back.  There was one other change that I made to the MediaEncoder.cs file, in addition to upping the timeout value.  

 

I also modified the format of the -ss argument that is sent to ffmpeg.  

ffmpeg can accept a value for the -ss argument in either seconds, or in a 00:00:00.000 format. 

I modified the -ss argument to use the 00:00:00.000 format by changing a single line in the ExtractImageInternal method.

I simply used the offset.ToString() to provide ffmpeg with the time format instead of seconds (see below)

if (offset.HasValue)
{
    // jmos - old code to generate the time sent to ffmpeg
    // args = string.Format("-ss {0} ", Convert.ToInt32(offset.Value.TotalSeconds)).ToString(UsCulture) + args;
    args = string.Format("-ss {0} ", offset.ToString()) + args;
}

I didn't think this change had much impact until I attempted to roll it back.  As soon as I rolled it back, I started having problems again.  

Overall, I would say the code for this portion of MediaBrowser seems pretty solid.  Any changes needed to fix chapter image extraction seem to be required to make up for shortcomings in ffmpeg.

 

I plan to do a little more testing to see how things pan out from here.  

Link to comment
Share on other sites

jmos1277

I've been playing with ffmpeg a bit more this evening and found it to be quite finicky.

Interestingly, I found that ffmpeg will actually produce a different output image depending on the loglevel that is provided at the command line.  That's the -v option.  When I run ffmpeg from the command line (not from within MB3) setting the verbosity to 'quiet' causes image extraction to fail on some mpeg2 encoded MKVs.  

Running ffmpeg again, but changing the verbosity from 'quiet' to 'debug' allows image extraction to succeed.  All other command line options were left unchanged.

 

I need to dig into ffmpeg a bit more to figure out what's going on there.  For now, it seems that there is more to my chapter image extraction issues than simply the timeout issue.

  • Like 1
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
 Share

×
×
  • Create New...