Video issues when trying to view an episode

[Cokefrevr 0]

@@Waldonnis How would i got about doing this? Is it somewhere on emby or something else? 

[Waldonnis 148]

 

@@Waldonnis How would i got about doing this? Is it somewhere on emby or something else? 

 

 

Because this is an unusual operation, it's a bit beyond what Emby would do on its own, and unfortunately, there aren't any really easy ways to go about it outside of hitting the command line and running ffmpeg directly on the affected files.  Here's the basic command line:

ffmpeg -i input.mkv -map 0 -c copy -bsf:v "hevc_metadata=sample_aspect_ratio=10/11" output.mkv

"input.mkv" and "output.mkv" are obviously things you'll need to change.  ffmpeg won't overwrite files directly (and I wouldn't recommend it anyway), so you'll be creating a new file when doing this and will have to replace the old file manually once you've verified everything works.  Probably the nicest way to do all of this is to copy each affected file to a "temporary work directory" so you can replace the original file with the output...but have a copy of the original handy in case things don't look right and you want to roll back.

 

The only other thing that you'll likely need to replace is the "10/11" value, which will probably change depending on the file.  As for what to change that value to, the easiest starting point is what the container thinks is accurate.  Easiest way to see what that value is would be to just run ffmpeg on it like below and use the SAR value that's not in brackets (bolded and underlined below for emphasis), like so:

ffmpeg -hide_banner -i input.mkv
...stuff...
Stream #0:0: Video: hevc (Main), yuv420p(tv), 704x480 [SAR 38052:3505 DAR 279048:17525], SAR 10:11 DAR 4:3, 29.97 fps, 29.97 tbr, 1k tbn, 29.97 tbc (default)

Note that this whole process will only work with HEVC files.  If you have h.264 files that have the same issue, you'd have to change hevc_metadata to h264_metadata.  Also, it's likely that you don't have ffmpeg in your system's or user's path, so you can either copy the ffmpeg binary from Emby's system directory to your work directory or just call it with the complete path to it.  I have ffmpeg in my path personally, but when I want to use Emby's version, I call it like so (my Emby install is in the default location, so I can use %APPDATA%, which points to my user account's AppData\Roaming directory):

%APPDATA%\Emby-Server\system\ffmpeg

I can probably write a quick drag-n-drop batch file to do this easily if the above is a bit more complicated than you're comfortable with.  Just let me know 

[Cokefrevr 0]

Because this is an unusual operation, it's a bit beyond what Emby would do on its own, and unfortunately, there aren't any really easy ways to go about it outside of hitting the command line and running ffmpeg directly on the affected files.  Here's the basic command line:

ffmpeg -i input.mkv -map 0 -c copy -bsf:v "hevc_metadata=sample_aspect_ratio=10/11" output.mkv

"input.mkv" and "output.mkv" are obviously things you'll need to change.  ffmpeg won't overwrite files directly (and I wouldn't recommend it anyway), so you'll be creating a new file when doing this and will have to replace the old file manually once you've verified everything works.  Probably the nicest way to do all of this is to copy each affected file to a "temporary work directory" so you can replace the original file with the output...but have a copy of the original handy in case things don't look right and you want to roll back.

 

The only other thing that you'll likely need to replace is the "10/11" value, which will probably change depending on the file.  As for what to change that value to, the easiest starting point is what the container thinks is accurate.  Easiest way to see what that value is would be to just run ffmpeg on it like below and use the SAR value that's not in brackets (bolded and underlined below for emphasis), like so:

ffmpeg -hide_banner -i input.mkv
...stuff...
Stream #0:0: Video: hevc (Main), yuv420p(tv), 704x480 [SAR 38052:3505 DAR 279048:17525], SAR 10:11 DAR 4:3, 29.97 fps, 29.97 tbr, 1k tbn, 29.97 tbc (default)

Note that this whole process will only work with HEVC files.  If you have h.264 files that have the same issue, you'd have to change hevc_metadata to h264_metadata.  Also, it's likely that you don't have ffmpeg in your system's or user's path, so you can either copy the ffmpeg binary from Emby's system directory to your work directory or just call it with the complete path to it.  I have ffmpeg in my path personally, but when I want to use Emby's version, I call it like so (my Emby install is in the default location, so I can use %APPDATA%, which points to my user account's AppData\Roaming directory):

%APPDATA%\Emby-Server\system\ffmpeg

I can probably write a quick drag-n-drop batch file to do this easily if the above is a bit more complicated than you're comfortable with.  Just let me know 

 

 

This sounds interesting I want to try it out but I would love a batch file just in case i fuck it up. Thanks 

[Waldonnis 148]

Hehehe, no problem.  I adapted one of my other scripts to do it, so it didn't take more than a few minutes to whip up:

@[member="Echo"] off

set ffprobe=ffprobe -hide_banner -select_streams v -show_streams -show_entries "stream=sample_aspect_ratio" -of csv %1

for /f tokens^=^2^ delims^=^, %%a IN ('%ffprobe%') DO (
	set SAR=%%a
)

set SAR=%SAR::=/%

ffmpeg -i %1 -map 0 -c copy -bsf:v "hevc_metadata=sample_aspect_ratio=%SAR%" -hide_banner -v error -stats "%~dp0%~n1.mkv"
pause

Just create a directory somewhere, copy ffmpeg and ffprobe into it, and paste the above into a new text file (I just called it fix_SAR.bat locally).  After that, you can drag and drop a video file onto the batch file and it'll create a fixed file in the script's directory.  If you want to copy the video file to the script's directory first so you have a backup, just change the ffmpeg line to this:

ffmpeg -i %1 -map 0 -c copy -bsf:v "hevc_metadata=sample_aspect_ratio=%SAR%" -hide_banner -v error -stats "%~n1-fixed.mkv"

...which will create a new file with a -fixed appended to it (e.g. input-fixed.mkv) to prevent any confusion and to ensure you're not trying to overwrite the input file (since they'll both be in the same directory).

 

The batch file is pretty basic.  First, it runs ffprobe to extract the SAR value stored in the mkv container.  It then converts ffprobe's colon-separated syntax to a fraction value (just substitutes a / for the colon).  Lastly, it runs ffmpeg to fix the file.  By default, it'll just run in a console window and won't close it until you hit a key in case you want to see if there were any errors.  You can delete the last pause line if you don't care to see the output and everything seems to be working fine (it'll just be a stats line).

 

If you run across files that are h.264 with the same issue, I could easily add a few changes to the script to auto-select the right filter depending on the codec.

Edited July 29, 2018 by Waldonnis

[Cokefrevr 0]

Hehehe, no problem.  I adapted one of my other scripts to do it, so it didn't take more than a few minutes to whip up:

@[member="Echo"] off

set ffprobe=ffprobe -hide_banner -select_streams v -show_streams -show_entries "stream=sample_aspect_ratio" -of csv %1

for /f tokens^=^2^ delims^=^, %%a IN ('%ffprobe%') DO (
	set SAR=%%a
)

set SAR=%SAR::=/%

ffmpeg -i %1 -map 0 -c copy -bsf:v "hevc_metadata=sample_aspect_ratio=%SAR%" -hide_banner -v error -stats "%~dp0%~n1.mkv"
pause

Just create a directory somewhere, copy ffmpeg and ffprobe into it, and paste the above into a new text file (I just called it fix_SAR.bat locally).  After that, you can drag and drop a video file onto the batch file and it'll create a fixed file in the script's directory.  If you want to copy the video file to the script's directory first so you have a backup, just change the ffmpeg line to this:

ffmpeg -i %1 -map 0 -c copy -bsf:v "hevc_metadata=sample_aspect_ratio=%SAR%" -hide_banner -v error -stats "%~n1-fixed.mkv"

...which will create a new file with a -fixed appended to it (e.g. input-fixed.mkv) to prevent any confusion and to ensure you're not trying to overwrite the input file (since they'll both be in the same directory).

 

The batch file is pretty basic.  First, it runs ffprobe to extract the SAR value stored in the mkv container.  It then converts ffprobe's colon-separated syntax to a fraction value (just substitutes a / for the colon).  Lastly, it runs ffmpeg to fix the file.  By default, it'll just run in a console window and won't close it until you hit a key in case you want to see if there were any errors.  You can delete the last pause line if you don't care to see the output and everything seems to be working fine (it'll just be a stats line).

 

If you run across files that are h.264 with the same issue, I could easily add a few changes to the script to auto-select the right filter depending on the code

 

I did as you said and both methods produce a one second file. I ran the first scrip and asked if i overwrite the file, since i made a copy i said y,  then i received this error:

 

[matroska,webm @ 000002604944a580] Read error

 

so this is only happening to the file i provided. Not sure why it seems it can only read the first second of the file. 

Edited July 29, 2018 by Cokefrevr

[Waldonnis 148]

I did as you said and both methods produce a one second file. I ran the first scrip and asked if i overwrite the file, since i made a copy i said y,  then i received this error:

 

[matroska,webm @ 000002604944a580] Read error

 

so this is only happening to the file i provided. Not sure why it seems it can only read the first second of the file. 

 

Hmm, may be something wrong with the original file.  You can try a remux (basically just a copy operation) and see if that works by popping open a command prompt and running this command:

ffmpeg -i input.mkv -map 0 -c copy -hide_banner output.mkv

If that doesn't error out, you can try lobbing the resulting output at the script to see if it works (remuxing might repair any problems in the mkv container...or it might not; it can be fickle).  If it does error out, I'd need to see the file to check if I can figure out if there's something I can recommend for fixing it.

 

If this is happening with every file, it may be an issue with the ffmpeg version Emby's shipping with (not a big deal, since this operation isn't something Emby would do).  Worst case, I can steer you to another ffmpeg version to try for this, but I'm still suspecting an issue with the file(s) for now rather than ffmpeg.

[Cokefrevr 0]

Hmm, may be something wrong with the original file.  You can try a remux (basically just a copy operation) and see if that works by popping open a command prompt and running this command:

ffmpeg -i input.mkv -map 0 -c copy -hide_banner output.mkv

If that doesn't error out, you can try lobbing the resulting output at the script to see if it works (remuxing might repair any problems in the mkv container...or it might not; it can be fickle).  If it does error out, I'd need to see the file to check if I can figure out if there's something I can recommend for fixing it.

 

If this is happening with every file, it may be an issue with the ffmpeg version Emby's shipping with (not a big deal, since this operation isn't something Emby would do).  Worst case, I can steer you to another ffmpeg version to try for this, but I'm still suspecting an issue with the file(s) for now rather than ffmpeg.

Thanks that fixed it. After running it through the bat file i came out great and the file is playing as it should. 

[Waldonnis 148]

Thanks that fixed it. After running it through the bat file i came out great and the file is playing as it should. 

 

Sweet!  Glad I could help.  I've seen files that had various container-stored values that were different than what was in the video stream itself, but nothing quite like this (those aspect ratios were crazy).  It was an interesting case, and one I'm filing away in my "broken stuff" samples for further exploration when I get time.  I'd love to see if I can figure out what Roku's internal limitations actually are so I can report it or at least recommend some checks/warnings for Emby.

[Cokefrevr 0]

Sweet!  Glad I could help.  I've seen files that had various container-stored values that were different than what was in the video stream itself, but nothing quite like this (those aspect ratios were crazy).  It was an interesting case, and one I'm filing away in my "broken stuff" samples for further exploration when I get time.  I'd love to see if I can figure out what Roku's internal limitations actually are so I can report it or at least recommend some checks/warnings for Emby.

 

Thanks for t he help and glad i provided an interesting case for tinkering later. 

[Waldonnis 148]

Thanks for t he help and glad i provided an interesting case for tinkering later. 

 

Indeed.  Gives me something to do when I don't want to do other stuff 

 

@@Luke

So far, I haven't found a way to coax ffprobe into revealing this type of disparity which is mildly irritating.  It's definitely decoding the video's SPS, so the info is there internally, but trying to get it to show the SAR in the bitstream's SPS in an easy-to-parse way and as part of the ffprobe results is confounding me.  This may just be a case where only trace_headers or a bitstream analyser would do the job (or parsing the hex in the packets), none of which is worth doing during a normal probe operation, IMO.  Worst case, I suppose looking at the single-line stream overview from ffmpeg/ffprobe could work (the "Input #" stream info spit out under the banner when just running ffmpeg -i on a file), but it's messy.

 

On the plus side, at least if this happens again, the script above should help people that want to fix the videos and it's easy to adapt to h.264 if needed.  This should be a rare occurrence, though, so it may not be something that needs to be accounted for in the server's probe process.

[Luke 37007]

Interesting, thanks for the info.