Error when playing movie

[jgomez709 0]

Dear:

I have the following problem:

Stream mapping:
  Stream # 0: 2 -> # 0: 0 (h264 (native) -> h264 (libx264))
  Stream # 0: 0 -> # 0: 1 (ac3 (native) -> mp3 (libmp3lame))
Press [q] to stop, [?] For help
[libx264 @ 0x12e9bc0] using SAR = 302/303
[libx264 @ 0x12e9bc0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
[libx264 @ 0x12e9bc0] profile Main, level 4.1
[libx264 @ 0x12e9bc0] 264 - core 152 r2851 + 3 e9a5903 - H.264 / MPEG-4 AVC codec - Copyleft 2003-2017 - http://www.videolan.org/x264.html - options: cabac = 1 ref = 1 deblock = 1: 0: 0 analyze = 0x1: 0 me = day subme = 0 psy = 1 psy_rd = 1.00: 0.00 mixed_ref = 0 me_range = 4 chroma_me = 0 trellis = 0 8x8dct = 0 cqm = 0 deadzone = 21.11 fast_pskip = 1 chroma_qp_offset = 0 threads = 9 lookahead_threads = 1 sliced_threads = 0 nr = 0 decimate = 1 interlaced = 0 bluray_compat = 0 constrained_intra = 0 bframes = 3 b_pyramid = 2 b_adapt = 1 b_bias = 0 direct = 1 weightb = 1 open_gop = 0 weightp = 1 keyint = 250 keyint_min = 23 scenecut = 40 intra_refresh = 0 rc_lookahead = 10 rc = crf mbtree = 1 crf = 23.0 qcomp = 0.60 qpmin = 0 qpmax = 69 qpstep = 4 vbv_maxrate = 1616 vbv_bufsize = 3232 crf_max = 0.0 nal_hrd = none filler = 0 ip_ratio = 1.40 aq = 1: 1.00
frame = 122 fps = 0.0 q = 0.0 size = N / A time = -577014: 32: 22.77 bitrate = N / A speed = N / A
Too many packets buffered for output stream 0: 0.
[libx264 @ 0x12e9bc0] frame I: 3 Avg QP: 14.77 size: 5109
[libx264 @ 0x12e9bc0] frame P: 36 Avg QP: 19.41 size: 5183
[libx264 @ 0x12e9bc0] frame B: 90 Avg QP: 20.70 size: 2610
[libx264 @ 0x12e9bc0] consecutive B-frames: 3.8% 7.7% 2.3% 86.2%
[libx264 @ 0x12e9bc0] mb I I16.4: 69.1% 0.0% 30.9%
[libx264 @ 0x12e9bc0] mb P I16.4: 34.6% 0.0% 0.0% P16.4: 35.2% 0.0% 0.0% 0.0% 0.0% skip: 30.3%
[libx264 @ 0x12e9bc0] mb B I16..4: 8.5% 0.0% 0.0% B16..8: 22.2% 0.0% 0.0% direct: 7.9% skip: 61.4% L0: 35.7% L1: 42.1% BI: 22.1%
[libx264 @ 0x12e9bc0] coded y, uvDC, uvAC intra: 37.9% 51.8% 12.2% inter: 14.3% 21.8% 0.6%
[libx264 @ 0x12e9bc0] i16 v, h, dc, p: 32% 29% 15% 23%
[libx264 @ 0x12e9bc0] i4 v, h, dc, ddl, ddr, vr, hd, vl, hu: 11% 22% 14% 22% 4% 2% 4% 5% 16%
[libx264 @ 0x12e9bc0] i8c dc, h, v, p: 39% 27% 18% 17%
[libx264 @ 0x12e9bc0] Weighted P-Frames: Y: 27.8% UV: 27.8%
[libx264 @ 0x12e9bc0] kb / s: 649.49
Conversion failed!

the movie that I try to reproduce has the following metadata:

Audio
Title: Dolby Digital Spa 6 ch Default
Language: spa
Codec: AC3
Channels: 6 ch
Sampling frequency: 48000 Hz
Default: Yes
====================================================================================
Audio
Title: Eng DTS 5.1
Language: eng
Codec: DTS
Profile: DTS
Design: 5.1
Channels: 6 ch
Bit rate: 1536 kbps
Sampling frequency: 48000 Hz
Default: No

========================================================
Video
Title: 1080P H264
Codec: H264
AVC: Yes
Profile: High
Level: 41
Resolution: 1920x808
Aspect ratio: 2.40: 1
Anamorphic: No
Interlaced: No
Pictures per second: 23.9759865
Bit rate: 11035 kbps
Bit depth: 8 bit
Pixel format: yuv420p
Reference pictures: 1
NAL: 4

the problem only appears when I select the audio "TitleSpa Dolby Digital 6 ch Default", because when I select the audio "Title: Eng DTS 5.1".

I am using version "Version 3.4.1.0" of emby server in linux Ubuntu 16.04.4 LTS.

Any idea how to fix it?

Here is the link to the movie:
https://mega.nz/#F!xU0XFa4R!TOooO9CL_8JxeOLZmwrOoQ

my problem is the same as the one mentioned here: https://github.com/MediaBrowser/Emby/issues/3103

except that to me you think with several pecliculas and that I have reinstalled and cleaned twice already emby, and it is not solved.

Greetings.

[Luke 37008]

Hi there, can you please attach the emby server and ffmpeg log? you can learn how to do that here:

https://emby.media/community/index.php?/topic/739-how-to-report-a-problem/

 

Thanks.

[jgomez709 0]

 

Dear:

Attached a rar where are all the log files that were generated when trying to watch the movie.

change the extension txt by rar.

Greetings.
 

logs.txt

[Luke 37008]

This is looking to me like the server doesn't have access to read the contents of the video files. Have you checked on this?

[jgomez709 0]

Yes, I attach the image of the folder and the files, the rare thing is that it only happens with the audio in Spanish, because with the audio in English, it works perfectly.
I played the video on my PC with Windows 10, in a normal way with Spanish audio.

[Luke 37008]

Can you try a different movie? Thanks.

[jgomez709 0]

I've tried several movies, and it's with this movie that I get the problem when I select Spañol audio, the others I can see without any problem.

[Luke 37008]

Can you provide a copy of the video for testing? thanks.

[jgomez709 0]

Of course

The Secret in Their Eyes (2009):

https://mega.nz/#F!ig0jFQrC!9HjuQSG1Ly64gJ6U2vqj2w

I can see this movie without any problem

==================================================================================================== ==========

Blood Father (Blood of my Blood) (2016)

https://mega.nz/#F!RwFxkSZQ!R2fUjooCdntIEyTlwuU7RA

and with this I get the problem already located.

regards

[Luke 37008]

Thanks. The same thing happens for me where selecting the spanish track causes ffmpeg to fail. I'm not sure what the issue is. It might just not like the file.

 

@@Waldonnis can you test this one? Thanks.

[Waldonnis 148]

Ah, the dreaded "Too many packets buffered" thing.  This same thing bit me the other day while re-mixing and re-encoding some of my library's audio tracks.

 

The way around it is to use -max_muxing_queue_size and setting it to something ridiculous (I usually use 4k just to be sure; rarely have I had to go higher).  There was a bug report on ffmpeg's trac about this type of problem updated very recently and there was some debate as to whether or not it was a regression (here's the bug report).  For grins, I tested the same file against my ffmpeg build from last week had no issues, so it was probably at least tweaked since 3.4.2 (although apparently not well enough to prevent me from running into it on other files, though).

 

Good movie, btw.  I own it as well  

[Luke 37008]

Ah, the dreaded "Too many packets buffered" thing.  This same thing bit me the other day while re-mixing and re-encoding some of my library's audio tracks.

 

The way around it is to use -max_muxing_queue_size and setting it to something ridiculous (I usually use 4k just to be sure; rarely have I had to go higher).  There was a bug report on ffmpeg's trac about this type of problem updated very recently and there was some debate as to whether or not it was a regression (here's the bug report).  For grins, I tested the same file against my ffmpeg build from last week had no issues, so it was probably at least tweaked since 3.4.2 (although apparently not well enough to prevent me from running into it on other files, though).

 

Good movie, btw.  I own it as well  

 

What are the side effects of this param though? Is there anything in ffprobe data to tell us that we should use it?

[Waldonnis 148]

What are the side effects of this param though? Is there anything in ffprobe data to tell us that we should use it?

 

Short of looking at the packet order, ffprobe probably won't show anything to indicate it.  The downside of that option is a potential increased delay in writing the output file for strange input like this file, but I doubt it would be a big deal and it should ordinarily never hit that limit with most files anyway (it's just a max value).  For files with more "normal" A/V packet interleaving, the option should have no effect as it will encounter one of each almost immediately.  There's probably a memory footprint difference, since it may allocate a larger buffer for the queue, but I haven't looked at the code.

 

Usually, ffmpeg's muxer tries to wait and buffer packets until it sees one of each type of packet (audio and video) before starting to write the output file.  If it gets to the "default" amount of packets before seeing both types of stream packets (A/V), then it gives up and basically says it buffered too many of one type of packets without seeing the other type.  This option just increases how long (how many packets) it'll wait before giving up.  I'm not sure of what the default max value is since they don't document it overtly.

 

To give you an idea, the first audio packet from stream 0 (Spanish audio track) doesn't show up until pos.10629088 in the file, compared to 28368 for the first packet of video (stream 2).  I did try remuxing the file a few different ways including trying mkvtoolnix, but it didn't help.  This file is definitely weird anyway and it could probably be repaired or reassembled, but it would be a bit messy since you'd probably have to demux it down into elementary streams then mux them together again.

[Luke 37008]

Great, thanks for the info.

[jgomez709 0]

Ah, the dreaded "Too many packets buffered" thing.  This same thing bit me the other day while re-mixing and re-encoding some of my library's audio tracks.

 

The way around it is to use -max_muxing_queue_size and setting it to something ridiculous (I usually use 4k just to be sure; rarely have I had to go higher).  There was a bug report on ffmpeg's trac about this type of problem updated very recently and there was some debate as to whether or not it was a regression (here's the bug report).  For grins, I tested the same file against my ffmpeg build from last week had no issues, so it was probably at least tweaked since 3.4.2 (although apparently not well enough to prevent me from running into it on other files, though).

 

Good movie, btw.  I own it as well  

 

Dear:

 

this configuration that they mention, where should it be made?

[Waldonnis 148]

Dear:

 

this configuration that they mention, where should it be made?

 

That info is for Luke, as I believe a change needs to be made in the server code.  You could try a newer ffmpeg build if you're feeling adventurous, but be sure to back up the existing ffmpeg and any config files you change to do so so you can rollback if you run across other issues.

[jgomez709 0]

That info is for Luke, as I believe a change needs to be made in the server code.  You could try a newer ffmpeg build if you're feeling adventurous, but be sure to back up the existing ffmpeg and any config files you change to do so so you can rollback if you run across other issues.

ok, I'll tell you that I already test and I get the same    .

I will be attentive to see if it can be solved, since I have like 6 movies that give me the same problem.

 

Thank you.

[Luke 37008]

Yea this is a hard change to add to the server because I don't want to add that param for every single video. That means we have to first detect the failure, and then try again with the param.

 

If you want a faster resolution I would just consider re-encoding the video.

[Luke 37008]

@@jgomez709, please let us know if this helps. thanks !

[jgomez709 0]

Yea this is a hard change to add to the server because I don't want to add that param for every single video. That means we have to first detect the failure, and then try again with the param.

 

If you want a faster resolution I would just consider re-encoding the video.

ok, friends, thank you very much

 

I will be attentive to when a solution is available, because the movies do not encode me, I have a provider who gives me that.

 

one last query, with which application I can reencoder the video, I tried with the "handbrake", but I have not obtained good results, maybe because of the little experience I have in that area.

 

 

Thank you very much for your time, Regards.