Running on QNAP with ARM

[dinkypumpkin]

On 29/03/2012 15:04, Tom Finch wrote:
> Unfortunately, though it seems to have compiled fine and is working
> for video remuxing, it hasn't fixed the radio error, which fails at
> the second ffmpeg pass ("Invalid non monotonically increasing dts").
> Evidently, this may be related to an old problem
> (http://lists.infradead.org/pipermail/get_iplayer/2011-May/001504.html)
> that surfaced with live recordings, due to a partially corrupted
> download.
>
> As before, the 'partial' file still seems to play fine in my usual
> players, but I'll have a look into it further, unless anyone knows of
> any good solutions.

It's strange that this doesn't happen on the first pass remux from FLV 
-> AAC.  If the timestamps are screwy in the FLV audio, it seems like 
ffmpeg should throw an error message on the first pass.  However, I've 
never been able to generate this error with flashaac downloads in 
get_iplayer, though I've seen this problem with FLV files from other 
sources (e.g., VLC).  The only solution  I've found - such as it is - is 
to transcode with ffmpeg and the libfaac codec.  I know that isn't much 
help if you haven't built FFmpeg with libfaac support.  I don't think 
there is any way to get around this particular problem unless and until 
FFmpeg provides some mechanism to skip backwards timestamps. 
get_iplayer will always need to use --resume with rtmpdump for 
downloads, so there is always the possibility of timestamp problems.

It may well be that the two-pass mechanism isn't needed any longer, 
though that wouldn't necessarily guarantee against "Invalid non 
monotonically increasing dts" errors in FFmpeg.  I can no longer 
duplicate the problem the two-pass mechanism was implemented to work 
around (bogus duration in MP4 header), even with the FFmpeg 0.8 build 
used with the get_iplayer Windows installer.  FFmpeg (now at v 0.10.2) 
has moved on quite a bit in the last year since get_iplayer was altered 
to deal with the Great AAC Kerfuffle, so perhaps whatever MP4 encoding 
glitch caused the problem may have disappeared.  Shevek (if you're out 
there): the two-pass thing was your contribution - what are you seeing 
now with current version of FFmpeg?