MP4 Converts with No Video, just Audio

General Support / Questions
1

I have some MP4 files that when converted (it doesn’t matter what settings I use) produce files with only Audio and no Video. I’m converting these because ChannelsDVR FireTV Client won’t play them unless Software Decoding is enabled, and when that’s enabled, nothing else plays.

Here is the information on the input file. As luck and fortune would have it, the log files is more than 10Megs so it would upload here, so that’s awesome.

General
Complete name : C:\Users\edward\Videos\MCEBuddyVideoIN\Logan’s Run - s01e01 - Logan’s Run.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/mp41)
File size : 769 MiB
Duration : 1 h 13 min
Overall bit rate mode : Variable
Overall bit rate : 1 462 kb/s
Collection : Logan’s Run
Season : 1
Album/Performer : Logan’s Run
Part : 1
Part/Position : 1
Part/Total : 1
Track name : Logan’s Run
Track name/Position : 1
Performer : Logan’s Run
Genre : Sci-Fi & Fantasy
Description : Logan leaves the City of Domes with Jessica and they are kidnapped by a pair of robots. An android named Rem rescues them and they flee with Francis in pursuit.
Recorded date : 1977
Encoded date : UTC 1970-01-01 00:00:00
Tagged date : UTC 2009-06-29 18:37:02
Cover : Yes
Part_ID : S1E1

Video
ID : 1
Format : MPEG-4 Visual
Format profile : Simple@L1
Format settings, BVOP : No
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default (H.263)
Codec ID : mp4v-20
Duration : 1 h 13 min
Bit rate : 1 328 kb/s
Width : 640 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 30.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.144
Stream size : 699 MiB (91%)
Writing library : Lavc52.1.0
Encoded date : UTC 1970-01-01 00:00:00
Tagged date : UTC 1970-01-01 00:00:00

Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 1 h 13 min
Bit rate mode : Variable
Bit rate : 128 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 67.3 MiB (9%)
Encoded date : UTC 1970-01-01 00:00:00
Tagged date : UTC 2009-06-29 18:37:02

2

Try to zip and upload the logs. Can’t do much without looking the logs. Or try to go through them yourself an search for WARNING> or ERROR> entries to see what’s going on.

3

Logan’s Run - s01e01 - Logan’s Run.mp4-For Logan’s Run-2023-02-21T17-49-14.log.zip (3.1 MB)

5

There are a ton of these, but I don’t know how to fix it. The other way it plays fine, is if I tell ChannelsDVR Client to Transcode, so I know its possible.

2023-02-21T17:49:46 MCEBuddy.AppWrapper.FFmpegMediaInfo → Error while decoding stream #0:1: Operation not permitted
2023-02-21T17:49:46 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg4 @ 000001e737ef78c0] [IMGUTILS @ 00000084bdfff320] Picture size 0x0 is invalid
2023-02-21T17:49:46 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg4 @ 000001e737ef78c0] video_get_buffer: image parameters invalid
2023-02-21T17:49:46 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg4 @ 000001e737ef78c0] get_buffer() failed
2023-02-21T17:49:46 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg4 @ 000001e737ef78c0] thread_get_buffer() failed
2023-02-21T17:49:46 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg4 @ 000001e737ef78c0] get_buffer() failed (-22 0000000000000000)
2023-02-21T17:49:46 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg4 @ 000001e737ef7d40] Context scratch buffers could not be allocated due to unknown size.

6

Also, plays fine with the Plex client, not sure what that’s doing differently.

7

Your source video file is either corrupted or not compliant with the MPEG-4 specifications. I see errors all over when trying to process the video stream:

2023-02-21T17:49:45 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg4 @ 000001e737e6ccc0] time_increment_bits 0 is invalid in relation to the current bitstream, this is likely caused by a missing VOL header
2023-02-21T17:49:45 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg4 @ 000001e737e6ccc0] time_increment_bits set to 5 bits, based on bitstream analysis
2023-02-21T17:49:45 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg4 @ 000001e737e6ccc0] time_increment_bits 4 is invalid in relation to the current bitstream, this is likely caused by a missing VOL header
2023-02-21T17:49:45 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg4 @ 000001e737e6ccc0] time_increment_bits set to 5 bits, based on bitstream analysis
2023-02-21T17:49:45 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg4 @ 000001e737e6ccc0] looks like this file was encoded with (divx4/(old)xvid/opendivx) → forcing low_delay flag
2023-02-21T17:49:45 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg4 @ 000001e737e6ccc0] Error, header damaged or not MPEG-4 header (f_code=0)
2023-02-21T17:49:45 MCEBuddy.AppWrapper.FFmpegMediaInfo → Last message repeated 400 times
2023-02-21T17:49:45 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg4 @ 000001e737e6ccc0] Error, header damaged or not MPEG-4 header (qscale=0)
2023-02-21T17:49:45 MCEBuddy.AppWrapper.FFmpegMediaInfo → [mpeg4 @ 000001e737e6ccc0] Error, header damaged or not MPEG-4 header (f_code=0)
2023-02-21T17:49:45 MCEBuddy.AppWrapper.FFmpegMediaInfo → Last message repeated 69 times

What’s the recording source? If it’s a TV Tuner card, then either the source video stream has OTA corruption or if this started recently then you TV Tuner driver was likely updated/replaced and that is creating a non compliant video. Either way the issue lies with the source video stream.

8

I understand what you’re saying. I’m not sure of the original source. What I do know is that MCEBuddy uses FFMpeg, and I also know that ChannelsDVR uses FFMpeg to do it’s transcoding. It works with Channels, so why doesn’t it work with MCEBuddy?

9

Can’t say, could be a number of reasons. Will need an original source to analyze to see what’s going on

10

I was able to successfully convert these files with VLC. No errors and plays perfectly in Channels now.

VLC must be more forgiving than FFMpeg is with the settings being used be MCEBuddy. Also, Handbrake couldn’t deal either, for probably the same reason. These original file must have been seriously boogered up.

All of my other problem files were handled fine by MCEBuddy, thats some good news.

Thanks any way for trying to help, its greatly appreciated!!!