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

[Alexander Strange]

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.
> 
> 
>> [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?