headers
Baptiste Coudurier | 1 Mar 2009 01:06
Picon

Re: [PATCH] metadata conversion API

On 2/28/2009 3:30 PM, Michael Niedermayer wrote:
> On Sat, Feb 28, 2009 at 02:24:45PM -0800, Baptiste Coudurier wrote:
>> On 2/28/2009 1:43 PM, Michael Niedermayer wrote:
>>> On Sat, Feb 28, 2009 at 01:24:41PM -0800, Baptiste Coudurier wrote:
>>>> On 2/28/2009 5:57 AM, Michael Niedermayer wrote:
>>> [...]
>>>>>>> * more compatibility for apps, apps already can through 
>>>>>>> AVOptions set and get by name and enumerate fields.
>>>>>> AVOptions uses OPT_<type> isn't it ? Why don't you want to
>>>>>> apply this to AVMetadata ?
>>>>> i explained it already above:
>>>>>>> [...] This has the advantage that it can be muxed in
>>>>>>> containers that do not support storing such information.
>>>>> [...]
>>>>>>> Or how would you store these types? If they are lost on
>>>>>>> remuxing or their types are randomized then they arent
>>>>>>> particularely usefull IMHO
>>>> Well, they are useful to gather information, print metadata and 
>>>> debugging, maybe less useful for remuxing inter-container, however,
>>>> mov to mov could end in a pretty accurate way.
>>>>
>>>> Exporting all information using AVFormatContext fields will lead to
>>>> an huge struct.
>>> exporting all fields as name value pairs will consume more memory 
>>> what i mean is, an int needs 4 bytes a av_malloc() will need at least
>>> 16 byte due to alignment alone but i would not be surprised if it
>>> needs twice that to keep track of things so malloc& free work now
>>> each metadata tag contains 2 strings, if we assume both fit in the 16
>>> byte and no additional byte is needed to keep track of things then 
>>> theres 16 bytes for ther struct (2 8byte pointers on 64bit archs)
(Continue reading)

Permalink | Reply | 21 comments |
headers
Stefano Sabatini | 1 Mar 2009 01:14
Picon
Favicon

Re: [PATCH] Add documentation for -ast, -vst, -sst

On date Saturday 2009-02-28 20:49:18 +0100, Michael Niedermayer encoded:
> On Sat, Feb 28, 2009 at 12:57:02AM +0100, Stefano Sabatini wrote:
> > On date Friday 2009-02-27 17:19:30 -0500, Ronald S. Bultje encoded:
> > > Hi,
> > > 
> > > On Fri, Feb 27, 2009 at 4:18 PM, Michael Niedermayer <michaelni <at> gmx.at> wrote:
> > > > On Fri, Feb 27, 2009 at 03:26:19PM -0500, Ronald S. Bultje wrote:
> > > >> On Thu, Feb 26, 2009 at 2:43 PM, Stefano Sabatini
> > > >> <stefano.sabatini-lala <at> poste.it> wrote:
> > > >> > On date Tuesday 2009-02-24 23:50:40 +0100, Stefano Sabatini encoded:
> > > >> >> + <at> item -ast  <at> var{audio_stream_number}
> > > >> >> +Select the desired audio stream number, counting from 1.
> > > >>
> > > >> This has confused me all too often. Can we change this so it counts
> > > >> like a regular number from 0?
> > > >
> > > > yes
> > > 
> > > that piece of code is full of crap btw, <0 for subtitles is seen as
> > > "disable" but <0 for audio/video isn't. I added that also, which makes
> > > the subtitle/video/audio selection code more alike. This would also
> > > allow to remove -an/-vn at some point but that could also be done
> > > after the release.
> > > 
> > > if you think this changes too much, I'll just apply the
> > > "wanted_x_stream < 0" to "wanted_x_stream <= 0" *3 change.
> > > 
> > > Stefano, can you regen your documentation patch with this change taken
> > > into account and apply that also?
> >
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Niedermayer | 1 Mar 2009 01:28
Picon
Picon

Re: [PATCH] Fix MPEG-TS seek and frame positions in general

On Sat, Feb 28, 2009 at 10:08:46PM +0100, Ivan Schreter wrote:
> Michael Niedermayer wrote:
>> On Wed, Feb 11, 2009 at 11:10:52AM +0100, Ivan Schreter wrote:
>>   
>>> [...]
>>>     If I understand you correctly (including previous mails), you'd like 
>>> to see the following: The packet position is passed to parser function by 
>>> extending the parser context by two fields: one passing the position of 
>>> current packet to the parser (currently only buffer and size is passed) 
>>> and one returning the position of packet which contained the startcode. 
>>> The parser should take care of filling it (or not). If filled, it will be 
>>> used, if not, current (broken) last packet position can be used as 
>>> fallback, until all parsers do. Alternatively, one could extend parser 
>>> function by extra parameter with in/out position (in = current packet 
>>> pos, out = first frame packet pos). This would require change in all 
>>> parsers, though, making the patch large, OTOH making the aforementioned 
>>> fallback unnecessary (it will work so implicitly). Which one do you want?
>>>     
>>
>> av_parser_parse() takes dts & pts currently, it should also take pos and 
>> then
>> do pretty much the same with pos that it does with dts/pts
>>
>>   
> I've put together a series of patches adding exact frame position in the 
> stream.
>
> avcodec_framepos adds av_parser_parse2(), which gets also the position, 
> which is then passed to the actual parser. If the parser wants to, it can 
> store it, do whatever with it and return correct position later.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Michael Niedermayer | 1 Mar 2009 01:39
Picon
Picon

Re: [PATCH] Add documentation for -ast, -vst, -sst

On Sun, Mar 01, 2009 at 01:14:05AM +0100, Stefano Sabatini wrote:
> On date Saturday 2009-02-28 20:49:18 +0100, Michael Niedermayer encoded:
> > On Sat, Feb 28, 2009 at 12:57:02AM +0100, Stefano Sabatini wrote:
> > > On date Friday 2009-02-27 17:19:30 -0500, Ronald S. Bultje encoded:
> > > > Hi,
> > > > 
> > > > On Fri, Feb 27, 2009 at 4:18 PM, Michael Niedermayer <michaelni <at> gmx.at> wrote:
> > > > > On Fri, Feb 27, 2009 at 03:26:19PM -0500, Ronald S. Bultje wrote:
> > > > >> On Thu, Feb 26, 2009 at 2:43 PM, Stefano Sabatini
> > > > >> <stefano.sabatini-lala <at> poste.it> wrote:
> > > > >> > On date Tuesday 2009-02-24 23:50:40 +0100, Stefano Sabatini encoded:
> > > > >> >> + <at> item -ast  <at> var{audio_stream_number}
> > > > >> >> +Select the desired audio stream number, counting from 1.
> > > > >>
> > > > >> This has confused me all too often. Can we change this so it counts
> > > > >> like a regular number from 0?
> > > > >
> > > > > yes
> > > > 
> > > > that piece of code is full of crap btw, <0 for subtitles is seen as
> > > > "disable" but <0 for audio/video isn't. I added that also, which makes
> > > > the subtitle/video/audio selection code more alike. This would also
> > > > allow to remove -an/-vn at some point but that could also be done
> > > > after the release.
> > > > 
> > > > if you think this changes too much, I'll just apply the
> > > > "wanted_x_stream < 0" to "wanted_x_stream <= 0" *3 change.
> > > > 
> > > > Stefano, can you regen your documentation patch with this change taken
> > > > into account and apply that also?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alex Converse | 1 Mar 2009 01:50
Picon
Gravatar

Re: [PATCH] Make AAC internal API marginally more consistent

On Fri, Feb 27, 2009 at 8:40 PM, Robert Swain <robert.swain <at> gmail.com> wrote:
> 2009/2/28 Alex Converse <alex.converse <at> gmail.com>:
>> This makes the internal AAC internal API a little more consistent. It
>> is needed by my upcoming patch to fix channel mapping issues with the
>> default channel configurations (issue800).
>
> OK.
>
> Regards,
> Rob
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel <at> mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>

Applied
Permalink | Reply | 0 comments |
headers
Justin Ruggles | 1 Mar 2009 03:08
Picon
Gravatar

Re: [PATCH] read header in FLAC demuxer

Justin Ruggles wrote:
> Michael Niedermayer wrote:
>> On Mon, Feb 02, 2009 at 09:00:05PM -0500, Justin Ruggles wrote:
>>> I'm open to suggestions or other samples to test.
>> what you tested sounds good
>> in addition you could test if -acodec copy to containers supporting flac
>> result in identical files
> 
> Good idea. I'll test some, then submit the new patch.

Now that the FLAC muxer has changed, this patch is somewhat simpler.  It
still disallows the header to be passed to the decoder with frame data,
but that is not needed by any of our demuxers after this patch.  One
thing I'm unsure of is whether or not to bump the lavc minor version
since the FLAC decoder behavior will change.

As for "-acodec copy", the only thing that will change is that remuxing
from raw FLAC to wav or avi will put the STREAMINFO in WAVEFORMATEX like
it should instead of in the data.  Remuxing raw FLAC to other containers
is still broken because we don't have a FLAC parser.

And I know I maintain both of these files now, but this is a large piece
of code that I think should pass review before I commit it.

Thanks,
Justin
Attachment (flac_read_header_12.diff): text/x-diff, 8 KiB
(Continue reading)






Permalink
| Reply
| 8 comments  
| 



  

  

  





headers


Justin Ruggles
 | 
1 Mar 2009 03:14






Picon

Gravatar





Re: [PATCH] read header in FLAC demuxer


Justin Ruggles wrote:
> Justin Ruggles wrote:
>> Michael Niedermayer wrote:
>>> On Mon, Feb 02, 2009 at 09:00:05PM -0500, Justin Ruggles wrote:
>>>> I'm open to suggestions or other samples to test.
>>> what you tested sounds good
>>> in addition you could test if -acodec copy to containers supporting flac
>>> result in identical files
>> Good idea. I'll test some, then submit the new patch.
> 
> Now that the FLAC muxer has changed, this patch is somewhat simpler.  It
> still disallows the header to be passed to the decoder with frame data,
> but that is not needed by any of our demuxers after this patch.  One
> thing I'm unsure of is whether or not to bump the lavc minor version
> since the FLAC decoder behavior will change.
> 
> As for "-acodec copy", the only thing that will change is that remuxing
> from raw FLAC to wav or avi will put the STREAMINFO in WAVEFORMATEX like
> it should instead of in the data.  Remuxing raw FLAC to other containers
> is still broken because we don't have a FLAC parser.
> 
> And I know I maintain both of these files now, but this is a large piece
> of code that I think should pass review before I commit it.

oops... forgot to add oggparsevorbis.o dependency to Makefile.

New patch attached.

-Justin


(Continue reading)






Permalink
| Reply
| 1 comment  
| 



  

  

  





headers


Justin Ruggles
 | 
1 Mar 2009 03:17






Picon

Gravatar





Re: [PATCH] read header in FLAC demuxer


Justin Ruggles wrote:
> Justin Ruggles wrote:
>> Justin Ruggles wrote:
>>> Michael Niedermayer wrote:
>>>> On Mon, Feb 02, 2009 at 09:00:05PM -0500, Justin Ruggles wrote:
>>>>> I'm open to suggestions or other samples to test.
>>>> what you tested sounds good
>>>> in addition you could test if -acodec copy to containers supporting flac
>>>> result in identical files
>>> Good idea. I'll test some, then submit the new patch.
>> Now that the FLAC muxer has changed, this patch is somewhat simpler.  It
>> still disallows the header to be passed to the decoder with frame data,
>> but that is not needed by any of our demuxers after this patch.  One
>> thing I'm unsure of is whether or not to bump the lavc minor version
>> since the FLAC decoder behavior will change.
>>
>> As for "-acodec copy", the only thing that will change is that remuxing
>> from raw FLAC to wav or avi will put the STREAMINFO in WAVEFORMATEX like
>> it should instead of in the data.  Remuxing raw FLAC to other containers
>> is still broken because we don't have a FLAC parser.
>>
>> And I know I maintain both of these files now, but this is a large piece
>> of code that I think should pass review before I commit it.
> 
> oops... forgot to add oggparsevorbis.o dependency to Makefile.
> 
> New patch attached.

dangit! I need more cola. I forgot to update the lavc Makefile as well.


(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Michael Niedermayer
 | 
1 Mar 2009 04:23






Picon

Picon





[PATCH] Estimate has_b_frames over	try_decode_frame() /	av_find_stream_info()


Hi

patch below estimates h264 has_b_frames aka decoder delay by decoding
frames in av_find_stream_info()
I do not intent to apply this, the correct solution is to improve the
parser to estimate has_b_frames without decoding ...

Index: utils.c
===================================================================
--- utils.c	(revision 17672)
+++ utils.c	(working copy)
 <at>  <at>  -1844,6 +1844,12  <at>  <at> 
 #endif
 }

+/*we need to find has_b_frames approximatly, the parser is not yet able to do it*/
+static int has_decode_delay_been_guessed(AVCodecContext *enc)
+{
+    return enc->codec_id != CODEC_ID_H264 || enc->frame_number >= 4 + enc->has_b_frames;
+}
+
 static int has_codec_parameters(AVCodecContext *enc)
 {
     int val;
 <at>  <at>  -1881,7 +1887,7  <at>  <at> 
         return ret;
   }

-  if(!has_codec_parameters(st->codec)){
+  if(!has_codec_parameters(st->codec) || !has_decode_delay_been_guessed(st->codec)){

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Michael Niedermayer
 | 
1 Mar 2009 05:11






Picon

Picon





Re: [PATCH] read header in FLAC demuxer


On Sat, Feb 28, 2009 at 09:08:18PM -0500, Justin Ruggles wrote:
> Justin Ruggles wrote:
> > Michael Niedermayer wrote:
> >> On Mon, Feb 02, 2009 at 09:00:05PM -0500, Justin Ruggles wrote:
> >>> I'm open to suggestions or other samples to test.
> >> what you tested sounds good
> >> in addition you could test if -acodec copy to containers supporting flac
> >> result in identical files
> > 
> > Good idea. I'll test some, then submit the new patch.
> 
> Now that the FLAC muxer has changed, this patch is somewhat simpler.  It
> still disallows the header to be passed to the decoder with frame data,
> but that is not needed by any of our demuxers after this patch.  One
> thing I'm unsure of is whether or not to bump the lavc minor version
> since the FLAC decoder behavior will change.
> 

> As for "-acodec copy", the only thing that will change is that remuxing
> from raw FLAC to wav or avi will put the STREAMINFO in WAVEFORMATEX like
> it should instead of in the data.  Remuxing raw FLAC to other containers
> is still broken because we don't have a FLAC parser.

will flac in avi files from "old" ffmpeg still work with new?

[...]
--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.

(Continue reading)






Permalink
| Reply
| 5 comments  
| 



  

  

  

  


  





    



Gmane