[FFmpeg-user] ProRes Quicktimes with audio not playing back reliably

Tim Nicholson nichot20 at yahoo.com
Mon Oct 29 09:02:03 CET 2012


On 27/10/12 18:18, Michael Niedermayer wrote:
> On Fri, Oct 26, 2012 at 07:30:10PM -0700, Thomas Worth wrote:
>> On Fri, Oct 26, 2012 at 7:20 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>>>> While all of the packets in this remux are even-sized, the entire
>>>> thing is out of alignment file position wise, apparently due to
>>>> something in the header winding up odd sized.. but no matter, it
>>>> seems to play.  The primary difference is that the muxing rate is
>>>> much longer than what ffmpeg generates.  For instance, ffmpeg makes:
>>>>
>>>> VaaVaaVaVaaVaVaaVaVaaVaaVaVaaVaVaaVaVaaVaaVaVaaVaVaaVaVaaVaVaaVaaVaVaaVaVaaVaVaaVaaVaVaaVaVaaVaVaaVaVaaVaaVaVaaVaVaaVaVaaVaaVaVaaVaVaaVaVaaVaaVaVaaVaVaaVaVaaVaVaaVaaVaVaaVa
>>>>
>>>> etc. while the Quicktime Pro remux (and other "real" ProRes files)
>>>> look more like:
>>>>
>>>> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaVVVVVVVVVVVVVVVaaaaaaaaaaaaaaaaaaaaaaaaVVVVVVVVVVVVVVVaaaaaaaaaaaaaaaaaaaaaaaaVVVVVVVVVVVVVVVaaaaaaaaaaaaaaaaaaaaaaaaVVVVVVVVVVVVVVV
>>>>
>>>> At this point I'm feeling confident that it's a general performance
>>>> issue with the very tight mux ffmpeg is doing, AND almost certainly
>>>> exacerbated by the odd frame lengths in most situations which helps
>>>> explain why the behavior is so erratic.
>>>>
>>>> So my next question, is there any way to tell ffmpeg to mux/re-mux
>>>> with larger runs, to see if this greatly improves the reliability of
>>>> playback, or is this hard-coded into the muxer (in which case, is
>>>
>>> see -chunk_duration and -chunk_size
>>
>> Michael, could these options be used in lieu of the asetnsamples
>> filter? In other words, could the same mux behavior be achieved only
>> by using the -chunk_duration and -chunk_size options?
> 
> no, why do you ask? is one working and the other not ?
> 

It would be good to have a way of doing it without having to resort to a
filter and the consequent re coding.
Currently if performing a stream copy of the audio whilst transcoding
the video, the original long interleave is lost and replaced by the
"tight" version. Controlling the muxer feels like a better approach in
this case.


> [...]


-- 
Tim




More information about the ffmpeg-user mailing list