[FFmpeg-devel] [FFmpeg-devel-irc] IRC log for 2010-03-28

Baptiste Coudurier baptiste.coudurier
Wed Mar 31 04:09:21 CEST 2010


On 03/30/2010 07:03 PM, Alexander Strange wrote:
>
> On Mar 30, 2010, at 9:36 PM, Michael Niedermayer wrote:
>
>> On Mon, Mar 29, 2010 at 01:00:12AM +0100, irc at mansr.com wrote:
>> [...]
>>> [05:34:16]<Dark_Shikari>  ahhhh
>>> [06:42:19]<Dark_Shikari>  mru: ok, it isn't flv
>>> [06:42:24]<Dark_Shikari>  both mp4 and flv desync due to the bitstream errors
>>> [06:42:25]<Dark_Shikari>  this is bad.
>>> [06:48:00]<Dark_Shikari>  -vsync 1 fixes it.
>>> [07:18:57]<mru>  Dark_Shikari: well, blame michael
>>> [07:19:19]<Dark_Shikari>  the vsync options seem to be impenetrable
>>> [07:19:20]<Dark_Shikari>  even code-wise
>>> [07:19:30]<kshishkov>  is no sync done when none is requested  a bad thing?
>>
>>> [07:19:40]<mru>  I've always been against that tampering with timestamps
>>
>> apparently not when i implemented disabling it in:
>> Subject: Re: [FFmpeg-devel] [PATCH] Speex parser
>> Date: Mon, 21 Sep 2009 10:12:56 +0200
>> Message-ID:<20090921081256.GI2768 at MichaelsNB>
>>
>> The only comment you had was about the spelling of fillin(g)
>
> I've had that message open for weeks meaning to comment on it, but never had the chance to test it.
> It looks like it does what I want though.
>
> Use case 1:
> The system API Perian uses to import files only accepts packet offsets into the original file.
> This means stuff that needs parsing can't be imported properly, so we have to disable the parsers during import and reassemble them when decoding instead.
>
> The worst problem here is there's no API to get original offsets - it either uses av_read_frame which reads too much unnecessary stuff or reads index_entries which is private. But that's a separate issue.
>
> Use case 2:
> I want ffprobe to read and print the AVPacket for every frame in a file for more demuxer regression testing and so we can investigate timestamp issues more easily.
> It should be able to do it with/without parsers enabled so we can control which code is actually being tested.
>
>> [07:19:48]<Dark_Shikari>  kshishkov: by default it should sync
>>
>>> [07:19:52]<mru>  kshishkov: ffmpeg by default does insane things
>>
>> which issue number on roundup is that?
>>
>>
>>> [07:19:55]<Dark_Shikari>  vsync just adjusts the method used
>>> [07:20:05]<Dark_Shikari>  the thing is: the input file is _CBR_
>>> [07:20:10]<Dark_Shikari>  it's bloody EASY
>>> [07:20:12]<mru>  -vsync is entirely undocumented
>>> [07:20:19]<kshishkov>  -async then?
>>> [07:20:27]<mru>  also undocumented
>>
>> ive improved the ehm existing documentation for vsync, iam not sure
>> what the problem, if any there is with the documentation for async
>>
>>
>>> [07:20:28]<Dark_Shikari>  async didn't fix it
>>> [07:20:41]<mru>  and the defaults are horribly broken
>>> [07:21:00]<mru>  usually you get crazy frame duplication or dropping
>>
>> dont forget that we only support 1 out of 4 h264 files thanks to ivan
>> implementing only 1 out of 4 mandatory ways to handle timestamps
>> i dont know if that is related to what you "discuss" here.

Nah it's just simple logic, when you don't understand, complain and say 
it's broken ;)

>>> [07:21:03]<kshishkov>  next thing is someone may dislike default settings for encoders used in FFmpeg. Oh wait, x264 have done that
>>> [07:21:24]<Dark_Shikari>  mru: well, Kovensky is writing audio + sync support for x264 for gsoc
>>> [07:21:32]<mru>  nice
>>> [07:21:36]<mru>  replace the shit
>>
>> why dont you fix the issues in ffmpeg if there are issues or at least
>> report them?
>> also if you want to improve transcoding, there are existing applications
>> ffmpeg isnt the only.
>> nothing that was called insane is at the level of insanity this
>> continuous reimplementation instead of fixing bugs is
>
> There are some streamcopy bugs (copying audio from flv to mp3 failing with non-monotone timestamps when mp3 can't have timestamps anyway) reported but not fixed, it might be discouraging more. Of course, I never managed to look into them myself?

The problem is not mp3 not having timestamps, the problem is flv having 
two frames using the _same_ timestamps which is obviously wrong and broken.

However I posted the fix, just set AVFMT_NOTIMESTAMPS to mp3 muxer and 
that's it.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org



More information about the ffmpeg-devel mailing list