Framerate Limit

[Noah0504 4]

All of my media has been ripped and encoded by myself.  My videos have a variable framerate that ffprobe has issues reading.  Because of this, Emby is thinks my average framerate is 1000fps.  The real framerate value is correct, but that must not be used when comparing against the limit.

 

This means I cannot direct play these files on the Roku with default settings.  I am able to direct play them if I disable video/audio transcoding and direct streaming under my user options, but this breaks playback for live TV, so it's not an option.  However, it does prove that they can be direct played (which I was doing before with Plex).

 

Also, I'm not sure why the framerate limit is set to 30fps.  In the Roku SDK, it shows support for 60fps (https://sdkdocs.roku.com/display/sdkdoc/Audio+and+Video+Support).  On my RokuTV, I am able to direct stream OTA channels, except for the ones that are broadcast in 60fps.

 

I don't have an issue direct playing my movies and TV shows on other clients as it appears there is no framerate limit at all (none that I can see in the log files).

 

I'm pretty ignorant when it comes to all of this, so maybe there is an easy solution.  Would it be acceptable to raise the framerate limit to 60fps and use the real framerate of the video when trying to determine if it exceeds the limit?

 

 

[speechles 1921]

The framerate is already 60, in fact, it should be 61 as the upper bound. This is because some framerate uses ratio 24000/1000 which means, math time. Some ratios work out to 60.003 as the framerate. Acceptable on roku to fit within the limits, but above the 60. This is why 61. It isn't arbitrary.

 

In these instances, which is where the mistake might be being made. How do you get 1000 as a frame rate? The only thing comes to mind is ffmpeg misread a ratio. Or emby misread the ratio. Somewhere the math wasn't done.

 

@@ebr isn't the upper bound 61? Then when transcoding, I went low at 30 fps(blue neon). I don't copy the 60 fps if it doesn't play direct. But.. the official app may allow 60fps to copy. ebr will need to answer.

 

Edit: What container are these in? For some containers, there is no constant rate (aka real framerate). You can't put vfr/crf into every container. Some want one, some want the other, some don't care. Can you show the media information from the web client for that item. Curious what would make it do this. Do you have any transcode logs you could share when attempting playback? In these it should give some indicator what is wrong. Might be as easy as a flag within the header of the container is wrong. The MKV header for example. Having more information would yield more answers.

Edited September 6, 2018 by speechles

[Noah0504 4]

I didn't try the beta, maybe that's where it's 60fps?

 

I'll attach some logs below for you to look at.

 

However, here are the key points from the log when trying to play one of my movies.

MaxFramerate=30

TranscodeReasons=VideoFramerateNotSupported

How do I get a framerate of 1000?  Well, that's a good question, but I think it comes down to ffprobe.  From everything I can find, it doesn't handle variable framerates well.  Here is the ffprobe stream information for one of my movies:

Stream #0:0: Video: h264 (High), yuv420p(tv, bt709, progressive), 1424x1080 [SAR 1:1 DAR 178:135], 1k fps, 23.98 tbr, 1k tbn, 180k tbc (default)

This is found in the Emby logs:

"AverageFrameRate":1000,"RealFrameRate":23.9760246

It seems that the ffprobe output does contain the actual framerate, but Emby is assigning it to RealFrameRate and the 1k fps is being assigned to AverageFrameRate and that's what's being used when making the comparison?

 

Attached you'll find the transcode log for trying to play a movie that should otherwise direct play, a 1080i30p OTA channel that can direct stream and a 720p60p OTA channel that has to transcode because of what I think is the framerate limit.

 

EDIT: Just saw your edit to your post.  My movies and TV shows are all MKVs.  Let me know if you want the media information from the web interface.  The logs should have what you want though.

ffmpeg-transcode.txt

OTA-directsream.txt

OTA-transcode.txt

Edited September 6, 2018 by Noah0504

[speechles 1921]

Usually h264 is encoded in crf. Then inside an mkv would be crf. But you put vrf inside the mkv, and it isn't an mpeg4 part2 or mpeg4 at all. It's an h264.

 

 

So what I believe happens is ffprobe is going.. okay.. lets do what we normally do and confusing the cfr with vfr. Since normally a constant rate factor is used with h264 it isn't expecting variable. Is it just on the roku this is the issue? What is the MKV header look like in that file? You can see it with MKVToolNix.

 

Edit: Now as to why the upper bound is 30fps. This should always be 61.. yet somehow.. &MaxFramerate=30 .. yeah.. that is a problem.. @@ebr *ring* *ring* :0)

 

-- side note: --

If you "Force Direct" and play that file with the Emby Blue Neon Night app does it play direct? If yes, the file is indeed good to go on the roku and If so, it could be possible to have the server assume seeing "1000" or "1001" in the framerate field that ffprobe misread the framerate constant vs variable then have it react by telling ffprobe how to read the file and that it is constant versus variable. Not sure if ffprobe allows you to tell it the framerate method. @@Luke would know better

Edited September 6, 2018 by speechles

[Noah0504 4]

Yes, so far, Roku is the only device I'm having issues with.

 

Here's the header for a movie:

+ EBML head
|+ EBML version: 1
|+ EBML read version: 1
|+ EBML maximum ID length: 4
|+ EBML maximum size length: 8
|+ Doc type: matroska
|+ Doc type version: 4
|+ Doc type read version: 2
+ Segment, size 2312507794
|+ Seek head
| + Seek entry
|  + Seek ID: 0x15 0x49 0xa9 0x66 (KaxInfo)
|  + Seek position: 229
| + Seek entry
|  + Seek ID: 0x16 0x54 0xae 0x6b (KaxTracks)
|  + Seek position: 363
| + Seek entry
|  + Seek ID: 0x12 0x54 0xc3 0x67 (KaxTags)
|  + Seek position: 614
| + Seek entry
|  + Seek ID: 0x10 0x43 0xa7 0x70 (KaxChapters)
|  + Seek position: 2312420775
| + Seek entry
|  + Seek ID: 0x1c 0x53 0xbb 0x6b (KaxCues)
|  + Seek position: 2312422482
|+ EbmlVoid (size: 130)
|+ Segment information
| + Timecode scale: 1000000
| + Title: Alice in Wonderland
| + Multiplexing application: Lavf57.56.101
| + Writing application: HandBrake 0.10.5 2017031700
| + Segment UID: 0xab 0xe4 0x6e 0x17 0x83 0xc8 0xc4 0xa2 0x1e 0x5a 0x91 0xe7 0x13 0xf0 0x27 0x5f
| + Date: Mon Mar 12 02:45:14 2018 UTC
| + Duration: 4516.182s (01:15:16.182)
|+ Segment tracks
| + A track
|  + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
|  + Track UID: 1
|  + Lacing flag: 0
|  + Language: und
|  + Codec ID: V_MPEG4/ISO/AVC
|  + Track type: video
|  + Default duration: 1.000ms (1000.000 frames/fields per second for a video track)
|  + Video track
|   + Pixel width: 1424
|   + Pixel height: 1080
|  + CodecPrivate, length 47 (h.264 profile: High @L4.1)
| + A track
|  + Track number: 2 (track ID for mkvmerge & mkvextract: 1)
|  + Track UID: 2
|  + Lacing flag: 0
|  + Name: Surround
|  + Language: eng
|  + Codec ID: A_DTS
|  + Track type: audio
|  + Audio track
|   + Channels: 6
|   + Sampling frequency: 48000
| + A track
|  + Track number: 3 (track ID for mkvmerge & mkvextract: 2)
|  + Track UID: 3
|  + Lacing flag: 0
|  + Language: eng
|  + Default flag: 0
|  + Codec ID: S_HDMV/PGS
|  + Track type: subtitles
|+ Tags
| + Tag
|  + Targets
|  + Simple
|   + Name: ENCODER
|   + String: Lavf57.56.101
| + Tag
|  + Targets
|   + TrackUID: 1
|  + Simple
|   + Name: DURATION
|   + String: 01:15:16.137000000
| + Tag
|  + Targets
|   + TrackUID: 2
|  + Simple
|   + Name: DURATION
|   + String: 01:15:16.182000000
| + Tag
|  + Targets
|   + TrackUID: 3
|  + Simple
|   + Name: DURATION
|   + String: 01:15:08.295000000
|+ Cluster

Also, for what it's worth, mediainfo can determine the correct framerate, but oddly says it's constant (technically it never changes as it is the same as the source):

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.1
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 5 frames
Codec ID                                 : V_MPEG4/ISO/AVC
Duration                                 : 1 h 15 min
Bit rate                                 : 2 506 kb/s
Width                                    : 1 424 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 4:3
Frame rate mode                          : Constant
Frame rate                               : 24.000 FPS

[speechles 1921]

Default duration: 1.000ms (1000.000 frames/fields per second for a video track)

 

So the header is where the 1000 fps comes from. You can use MKVToolNix to fix this. Then the real framerate is derived from actually parsing the file ffprobe style. So it isn't that its variable at all nor the ratio being parsed wrong. It is that the header is somewhat wonky. Someone actually put 1000 in there. Easy fix to apply takes less than a second.

 

@@Luke it is possible to fix this issue in the server and still work with defective headers in the mkv, at least in regard to framerate. Anytime you see a "1000" or "1001" as average framerate disregard and use the real framerate in the logic which prefers average over real. When average is clearly wonky, use real framerate instead.

Edited September 6, 2018 by speechles

[Noah0504 4]

Default duration: 1.000ms (1000.000 frames/fields per second for a video track)

 

So the header is where the 1000 fps comes from. You can use MKVToolNix to fix this. Then the real framerate is derived from actually parsing the file ffprobe style. So it isn't that its variable at all nor the ratio being parsed wrong. It is that the header is somewhat wonky. Someone actually put 1000 in there. Easy fix to apply takes less than a second.

 

What exactly am I changing the duration to?  It's "1000000" (nano seconds) right now.

[speechles 1921]

--default-duration TID:x

Forces the default duration of a given track to the specified value. Also modifies the track's timestamps to match the default duration. The argument x must be postfixed with 's', 'ms', 'us', 'ns', 'fps', 'p' or 'i' to specify the default duration in seconds, milliseconds, microseconds, nanoseconds, 'frames per second', 'progressive frames per second' or 'interlaced frames per second' respectively. The number x itself can be a floating point number or a fraction.

If the default duration is not forced then mkvmerge will try to derive the track's default duration from the container and/or the encoded bitstream for certain track types, e.g. AVC/h.264 or MPEG-2.

This option can also be used to change the FPS of video tracks without having to use an external timestamp file.

 

You can use the MKVToolNix GUI app and change the default duration. Once you import it the file click on the left panel the mpeg4 stream. Now click on the right panel where it says general options you can scroll down to default duration. The safest way to do this use FPS if you are integer, 24, 30, 50, or the ratio's should work as well if you are fractional, 29.97, 23.96.

 

Edited September 6, 2018 by speechles

[Noah0504 4]

Huh, maybe my version is a little dated?

Default duration: Number of nanoseconds (not scaled) per frame.

EDIT: Nevermind!  I was trying to edit the header...  Thanks for the picture.

 

And it worked.  I think I'm still going to hang-tight for just a little bit before I automate this for my entire collection.  Ha.

Edited September 6, 2018 by Noah0504

[Noah0504 4]

Well, now that I know a of potential fix on my end for my personal collection, it still appears that the Roku app (including the beta) isn't allowing for 60fps.