[FFmpeg-devel] [PATCH]Support muxing more qcelp samples in mov
Paul B Mahol
onemda at gmail.com
Sun Jun 9 23:16:35 CEST 2013
On 6/9/13, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> Paul B Mahol <onemda <at> gmail.com> writes:
>> On 6/9/13, Carl Eugen Hoyos <cehoyos <at> ag.or.at> wrote:
>> > Paul B Mahol <onemda <at> gmail.com> writes:
>> >> I already said that adding subframe capability to decoder
>> >> looks to be best way to solve issue(s).
>> > Could you explain how this could fix the muxer issue?
>> > I honestly don't understand.
>> I don't know what patch actually really solves
> I originally wrote that the patch fixes "muxing of qcelp
> in mov and playback with QuickTime" meaning that with
> the patch all qcelp files remuxed to mov play fine with
> QuickTime which does not work without the patch, if
> that was really unclear without additional explanation
> I am sorry but note that you told me to test this, so
> I assumed you knew (or at least expected) this to be
By muxing you mean muxing from mov to mov or?
>> and why solution in patch is actually prefered.
> As said, because I cannot implement another solution
> and I doubt anybody else will work on this corner-
> case (to use an euphemism).
>> Could you confirm that this patch does not increases
>> packets size for non 4 rate packets.
> Of course it increases the packet size (that is the
> single thing this patch does), but note that it will
> either not increase the overall file size (if input
> was mov) or only compared to files that simply do
> not play at all (for qclp input).
I don't care for single byte increase, but 4 to 35 does matter.
>> Is patch actually tested with files with non-4
>> rates packet?
> I know that I sent an untested patch last week (I
> actually tested it but it appears I found the single
> case where it worked when I tested) and I am sorry
> about it, but I typically test everything that I
> (The patch has no effect on 4 rate, so one could
> argue I only tested it on non-4 rate files, but
> I also verified that 4 rate files still work with
> Carl Eugen
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel