Some MP4 files shown as "broken data" on PS3

[Twain28]

Hello everybody,

I'm posting this since I had a look around the forum, but I couldn't find an answer to the peculiar issue I'm having.
A couple of days ago, I decided to convers all my xvid AVI files to x264 MP4, to better play them on my PS3 and save a little space on my external HDD.
I'm using FFmpeg command line on windows7 x64, since I found it faster and easier to setup though a batch script.
My conversion line reads:

ffmpeg -i input.avi -c:v libx264 -preset slow -crf: 19 -c:a libvo_aacenc -b:a 148k -ac 2 output.mp4

After converting the first files, I tried them and they played all right on my PS3, so I launched conversion for all my files, and progressively started deleting the original AVI files.
Halfway, I had another check, and actually found out that some of the MP4 files I produced won't play at all on my PS3. They are listed as "broken data" on the XMB, and my PS3 refuses to play them.

I ran MediaInfo over two files, to produce log files.

The first one is of one MP4 file which DOES play all right on my PS3:

General
Complete name : G:\Movies\WorkingMovie.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 651 MiB
Duration : 1h 34mn
Overall bit rate : 964 Kbps
Writing application : Lavf55.0.100

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 1h 34mn
Bit rate : 810 Kbps
Width : 720 pixels
Height : 304 pixels
Display aspect ratio : 2.35:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.154
Stream size : 547 MiB (84%)
Writing library : x264 core 130 r2274 c832fe9
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / 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=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=19.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 1h 34mn
Bit rate mode : Constant
Bit rate : 148 Kbps
Channel count : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : 83ms
Stream size : 99.9 MiB (15%)

The second one is of an mp4 file that does NOT play on my PS3:

General
Complete name : Z:\fixit\BrokenData.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 1.16 GiB
Duration : 3h 13mn
Overall bit rate : 858 Kbps
Writing application : Lavf55.0.100

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L2.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 3h 13mn
Source duration : 26s 816ms
Bit rate : 704 Kbps
Width : 656 pixels
Height : 272 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.165
Stream size : 976 MiB (82%)
Source stream size : 976 MiB (82%)
Writing library : x264 core 130 r2274 c832fe9
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / 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=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=19.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
mdhd_Duration : 11623227

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 3h 13mn
Bit rate mode : Constant
Bit rate : 148 Kbps
Channel count : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : 83ms
Stream size : 205 MiB (17%)

Needless saying, both files play fine on my PC, with MediaPlayer Classic (I have KLCP installed).

Any clues how I might solve this strange issue?

Thank you in advance!

[poisondeathray]

You might try remuxing with mp4box

Not sure why the file that doesn't work reports "mdhd_Duration" , but the one that does work does not. It looks like you used the same ffmpeg build and libx264, presumably the same muxer.

[Twain28]

You might try remuxing with mp4box

Not sure why the file that doesn't work reports "mdhd_Duration" , but the one that does work does not. It looks like you used the same ffmpeg build and libx264, presumably the same muxer.

WOW, your suggestion worked like a charm: thank you!
I demuxed-remuxed one of the faulty MP4s using mp4box (through My mp4box GUI), and the file came back whole and perfectly playable on my PS3.
Looks like FFMpeg somehow screwed the muxing part, after converting those files.... I also noticed the new working MP4 is smaller (1MB less or so), so maybe some garbage was also getting in the way of my PS3 internal decoder....

Will report back here when I'm done fixing the other faulty files, even if I'm quite positive it will work on them as well....

[poisondeathray]

Just curious if mediainfo also reports a "mdhd_Duration" on the other problem files as well ? - or is that a "red herring" and completely unrelated ?

[Twain28]

Just curious if mediainfo also reports a "mdhd_Duration" on the other problem files as well ? - or is that a "red herring" and completely unrelated ?

Apparently it does....so it might be part of the issue.
Here's a log from another of those faulty MP4s:

Codec ID : isom
File size : 1.21 GiB
Duration : 2h 22mn
Overall bit rate : 1 220 Kbps
Writing application : Lavf55.0.100

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L2.1
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 2h 22mn
Source duration : 6mn 12s
Bit rate : 1 066 Kbps
Width : 656 pixels
Height : 272 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.249
Stream size : 1.06 GiB (87%)
Source stream size : 1.06 GiB (87%)
Writing library : x264 core 130 r2274 c832fe9
Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / 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=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=19.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
mdhd_Duration : 8533393

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 2h 22mn
Bit rate mode : Constant
Bit rate : 148 Kbps
Channel count : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Delay relative to video : 83ms
Stream size : 151 MiB (12%)

As you can see, md_hd_duration value is there as well....do you happen to know what that specific value is actually related to?

[Twain28]

Ok, now all the MP4 are back working...but their audio is now completely off-sync....bwaaa....

[poisondeathray]

I don' t know what "mdhd_Duration" indicates, but it suggests it's more than a coincidence and probably related if it's only shown on the problem files and none of the "ok" files

What is the sync issue? constant sync? or progressively worsening?

And why would only some of the files exhibit the problem ? Presumably you used everything else the same (Same ffmpeg build, same command line etc....) .

Were all the source files xvid AVI, or some other file types as well ?

[Twain28]

Seems somewhat constant...anthing automated I could try to fix it?

[poisondeathray]

If it's constant and the same ms value for each video, you can batch remux with a delay value

Is the sync issue after remuxing present on a software media player as well, or only PS3 ?

[Twain28]

Sigh....this is getting each minute more depressing....looks like I'll have to find the exact delay value first....

sync is present on both PC and PS3..looks like some seconds or more....

I was actually thinking, what if I ffmpeg the files to avi/mkv, then feed them to avimuxgui, fix the audio there, and then back to mp4?

[Twain28]

So, now here's what I'm doing (the long way around, but....still a way):
1 I converted one of the MP4 to MKV using ffmpeg;
2 I ran AviMuxGUI on the MKV, and started a tentative muxing operation: the log guessed me a "200ms" sync value;
3 I stopped the AviMuxGUI process and got back to My mp4box GUI, using which I demuxed the original MP4 file;
4 I used mkvmerge GUI to create a new MKV, with a 200ms audio sync value.

The new MKV was in sync....so I tried the same process on another MP4 file, using the same 200ms value....and that one went in sync as well....
I will repeat the operations above for all the files, checking them one by one, then I'll ffmpeg them back from MKV to MP4....and I should be finally done with it....
Will report back in one hour or so, I think....

Edit: more than two hours later, I'm done....I'll now feed the new MP4s to my PS3 and cross my fingers...

[Twain28]

One last remark: I can confirm the steps I took above perfectly solved the sync issue and produced high quality MP4, fully compatible and playable on my PS3.

That said, I think I earned a good night of sleep....

[poisondeathray]

couldn't you reduce the number of steps by using mp4box for the 200ms delay ?

[Twain28]

You're probably right, but, since the 200ms desync started when I first started usling mp4box, I tried to involve the program only for the demuxing part...
It worked, though: all the files are back in their MP4 form, in sync and, finally, fully playable on my PS3.
I think we can list both issues as "solved": many thanks for your kind assistance and suggestions, poisondeathray!

[Twain28]

Getting back to this a few months later, just for the record... the above procedure can be avoided using Avidemux:
1. load the unreadable MP4 inside Avidemux;
2. select "copy" to both Audio and Video streams;
3. select "MP4v2 Muxer" in the Output format menu;
4. save the file.

This works very well, fixes the file without any de-sync offset and is actually pretty fast. Plus, it also seems to be able to successfully pack AC3 audio streams inside an MP4 container!!

[yoda313]

Just two things that bear pointing out in this thread -

Don't delete your original files.

Consider using a wdtv media player or similar settop media player.

The wdtv and others like it play a wide wide range of video file types. That would mean most likely you would not have had to convert anything.

And as is pretty well known game consoles aren't the most forgiving when it comes to playback compatibility of video files. They have a narrower set of acceptable formats that they can play. Stray from that range and you won't be able to play them.

Or you can transcode them from your computer using tversity or playon and stream them over your network (the original files that is).

THis is generally common knowledge but thought this might be useful for the original poster and others who might read this thread.

I"m glad you found a workaround though.