PS3 problem playing get_iplayer h.264 videos
dinkypumpkin at gmail.com
Sat Dec 31 12:02:01 EST 2011
On 29/12/2011 16:15, Jon Davies wrote:
> which convinces me that the problem is in ffmpeg, and isn't really
> anything to do with get_iplayer. Interestingly ffprobe reports a
> 48khz sample rate for both broken and working files, whereas the PS3
> reports 48khz for the broken ones, and 24khz for the working ones.
> Next step is to see if the latest builds of ffmpeg and/or libav still
> exhibit this behaviour.
That still seems to be the case with ffmpeg 0.9, though I've encountered
this problem in a different context (no PS3 here). I used Elgato
Turbo.264 HD to encode video for an Apple TV 1, and it was also foxed by
the audio sample rate in the headers of files remuxed by ffmpeg. The
result was trashed audio in the output files. I could work around the
problem by remuxing with mp4box and then running Turbo.264, but I
generally chose to drive the Turbo.264 encoding via QuickTime 7 in order
to preserve metadata tags.
The 0.5 branch of ffmpeg is the only version that takes the audio sample
rate from the FLV metadata. That bit of code was subsequently removed
in 0.6 and later branches, but I was never energetic enough to track
down the problem with whatever replaced it. AFAICT, the FLV metadata is
written correctly by rtmpdump, and any QuickTime-based tool (or ffmpeg
itself) has no problem converting the remuxed MP4 file, regardless of
what is in the header.
A bit of esoterica here. The audio sample rate is written in two places
in the MP4 header (media header and sample table descriptor for audio
track). I noticed a slight difference in the results depending on how I
employed mp4box. If I used the simple version:
mp4box -add broken.mp4 -new fixed.mp4
only one of the audio sample rate values (in sample table descriptor)
was changed in the output file header. The mp4info utility (from
libmp4v2) reported 48 kHz, though the file was still usable with
Turbo.264. However, if I fully disassembled the tracks and reassembled
a new file, e.g.:
mp4box -raw 1 broken.mp4 -out broken.h264
mp4box -raw 2 broken.mp4 -out broken.aac
mp4box -add broken.h264 -add broken.aac -new fixed.mp4
both audio sample rate values were changed and mp4info reported 24 kHz.
I doubt it makes any difference, but if one method doesn't work for a
particular application, perhaps the other will.
More information about the get_iplayer