Jump to content


Photo

1200 Minute Conversion Error


  • Please log in to reply
23 replies to this topic

#1 Bigmack3000 OFFLINE  

Bigmack3000

    Advanced Member

  • Members
  • 101 posts
  • Local time: 09:37 AM

Posted 01 December 2019 - 04:08 PM

Every now and then when I convert a file, Emby makes the final file 1200 minutes long.  I can cut off the excess and the file is then fine, but it's an odd problem to run into.



#2 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 142515 posts
  • Local time: 12:37 PM

Posted 01 December 2019 - 04:19 PM

Hi there, what is the length of the source? What kind of source file?



#3 Bigmack3000 OFFLINE  

Bigmack3000

    Advanced Member

  • Members
  • 101 posts
  • Local time: 09:37 AM

Posted 01 December 2019 - 04:31 PM

Various lengths. from 20 minute shorts to 3 hour films.  They are mkv rips of blurays and/or dvds.  It seems to be random too.  I could convert a season of a show, and two thirds of the episodes are fine but then the other 3rd have this problem. 

 

But it's also seems to just be the timecode that's incorrect.  There's nothing actually playable after the end of the film's normal runtime.  



#4 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 142515 posts
  • Local time: 12:37 PM

Posted 01 December 2019 - 04:38 PM

How are you determining that its' 1200 minutes?



#5 Bigmack3000 OFFLINE  

Bigmack3000

    Advanced Member

  • Members
  • 101 posts
  • Local time: 09:37 AM

Posted 01 December 2019 - 04:43 PM

5de4255e4ed99_ScreenShot20191201at34014P

 

It shows up with that length when opened in VLC.  But if I scroll past the normal runtime, the file closes.  Which makes me think there's no actual data added, just the wrong length being put in the file conversion.  But every time it happens, it's the same wrong length.

 

Also, I don't know why the screenshot uploaded like that, but the actual video looks fine after the conversion.  It's just the length.


Edited by Bigmack3000, 01 December 2019 - 04:44 PM.


#6 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 142515 posts
  • Local time: 12:37 PM

Posted 01 December 2019 - 04:50 PM

What length does the new file show in Emby?



#7 Bigmack3000 OFFLINE  

Bigmack3000

    Advanced Member

  • Members
  • 101 posts
  • Local time: 09:37 AM

Posted 01 December 2019 - 04:59 PM

5de4296833a63_ScreenShot20191201at35745P

 

Same length.  

 

The uploaded looks odd, but again that part looks fine on my computer.



#8 Bigmack3000 OFFLINE  

Bigmack3000

    Advanced Member

  • Members
  • 101 posts
  • Local time: 09:37 AM

Posted 01 December 2019 - 08:42 PM

I'm not positive, but as I go through all the ones that have this happen, It seems to be far more common in files that had subtitles auto burned in during conversion.



#9 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 142515 posts
  • Local time: 12:37 PM

Posted 02 December 2019 - 01:34 PM

Can you provide a source file for testing? Thanks.



#10 Bigmack3000 OFFLINE  

Bigmack3000

    Advanced Member

  • Members
  • 101 posts
  • Local time: 09:37 AM

Posted 02 December 2019 - 03:29 PM

Sure, but how would I do this?



#11 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 142515 posts
  • Local time: 12:37 PM

Posted 02 December 2019 - 04:22 PM

dropbox or google drive would be great. before you do that, can you provide an ffmpeg conversion log in case we might be able to spot something there? thanks.



#12 Bigmack3000 OFFLINE  

Bigmack3000

    Advanced Member

  • Members
  • 101 posts
  • Local time: 09:37 AM

Posted 03 December 2019 - 01:04 AM

Ok, I attempted the file again and got the same error.  Attached is the log for that conversion.

Attached Files



#13 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 142515 posts
  • Local time: 12:37 PM

Posted 03 December 2019 - 01:59 AM

So just to confirm, you haven't yet seen this when not burning in subtitles, right?



#14 Bigmack3000 OFFLINE  

Bigmack3000

    Advanced Member

  • Members
  • 101 posts
  • Local time: 09:37 AM

Posted 03 December 2019 - 02:05 AM

I don't believe so, but I have about 5 converting tonight that shouldn't have subtitles burned in.  I'll check them when they're done.



#15 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 142515 posts
  • Local time: 12:37 PM

Posted 03 December 2019 - 02:14 AM

Ok thanks. I was actually just able to reproduce this on an input file with pgs subtitles.



#16 Bigmack3000 OFFLINE  

Bigmack3000

    Advanced Member

  • Members
  • 101 posts
  • Local time: 09:37 AM

Posted 03 December 2019 - 09:15 PM

You think the type of subtitle is the problem?  

 

Also, none of the conversions last night or today had burned in subtitles and none had the error either.



#17 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 142515 posts
  • Local time: 12:37 PM

Posted 03 December 2019 - 09:24 PM

We're looking into it. Thanks.

#18 Bigmack3000 OFFLINE  

Bigmack3000

    Advanced Member

  • Members
  • 101 posts
  • Local time: 09:37 AM

Posted 05 December 2019 - 06:29 PM

Would it be possible to just make burning in subtitles optional?



#19 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 142515 posts
  • Local time: 12:37 PM

Posted 05 December 2019 - 10:01 PM

Yes more subtitle conversion options are planned for the future. Thanks.

#20 softworkz OFFLINE  

softworkz

    Advanced Member

  • Developers
  • 1894 posts
  • Local time: 06:37 PM

Posted 06 December 2019 - 04:02 AM

You think the type of subtitle is the problem?  

 

Also, none of the conversions last night or today had burned in subtitles and none had the error either.

 

So, here's what's happening:

 

5dea076068139_subtitle_burn_in_issue0png

 

 

Sometimes (or maybe even always in case of PGS subs), the subtitle frames not have valid values for start_display_time and end_display_time

 

Like above:  4294967295 is just the maximum for 32 bit uint, but ffmpeg seems to interpret that value.

 

That is no problem as long as there's another subtitle frame following which indicates the end of the previous one (that next one might even be empty just to invalidate the previous one).

 

But when it comes to the very last subtitle graphic the end_display time is considered to be a frame event. Ffmpeg considers the 4294967295 to be valid and "waits" for that to happen. Meanwhile. the video main has ended as well, but by default configuration, the overlay filter repeats a stream's image when it has reached its end.

 

And that causes one additional frame to be added to the output file with an insanely high timestamp value:

 

 

5dea0a8e67c2e_subtitle_burn_in_issue.png

 

That one additional frame is in turn causing the high and incorrect container duration.

 

This is fixed in the upcoming beta (4.4.0.1)


Edited by softworkz, 06 December 2019 - 04:17 AM.

  • Bigmack3000 likes this




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users