[MPlayer-dev-eng] [Test Patch] flac files not showing bitrates, throwing off timing in statusline etc.
SciFi
sci-fi at hush.ai
Mon Jul 23 07:15:14 CEST 2007
I have a test patch ready, it's for ad_ffmpeg.c .
The main discussion for this problem is on the -user list.
I'll continue this over onto the -devel list now.
If the patch doesn't look good below, I'll have to open a bugreport to do a
proper file attachment etc.
===cut-here===
Index: libmpcodecs/ad_ffmpeg.c
===================================================================
--- libmpcodecs/ad_ffmpeg.c (revision 23844)
+++ libmpcodecs/ad_ffmpeg.c (working copy)
@@ -109,18 +109,34 @@
x=decode_audio(sh_audio,sh_audio->a_buffer,1,sh_audio->a_buffer_size);
if(x>0) sh_audio->a_buffer_len=x;
- sh_audio->channels=lavc_context->channels;
- sh_audio->samplerate=lavc_context->sample_rate;
- sh_audio->i_bps=lavc_context->bit_rate/8;
+ if (!sh_audio->channels){ // don't destroy a possibly good channels
value (fLaC's)
+ sh_audio->channels=lavc_context->channels;
+ mp_msg(MSGT_DECAUDIO,MSGL_V,"[ad_ffmpeg.c:113] INFO:
sh_audio->channels=lavc_context->channels = %d\n",sh_audio->channels);
+ }
+ if (!sh_audio->samplerate){ // don't destroy a possibly good
samplerate value (fLaC's)
+ sh_audio->samplerate=lavc_context->sample_rate;
+ mp_msg(MSGT_DECAUDIO,MSGL_V,"[ad_ffmpeg.c:117] INFO:
sh_audio->samplerate=lavc_context->sample_rate =
%d\n",sh_audio->samplerate);
+ }
+ if (!sh_audio->i_bps){ // don't destroy a possibly good i_bps value
(fLaC's)
+ sh_audio->i_bps=lavc_context->bit_rate/8;
+ mp_msg(MSGT_DECAUDIO,MSGL_V,"[ad_ffmpeg.c:121] INFO:
sh_audio->i_bps=lavc_context->bit_rate/8 = %d\n",sh_audio->i_bps);
+ }
if(sh_audio->wf){
// If the decoder uses the wrong number of channels all is lost anyway.
// sh_audio->channels=sh_audio->wf->nChannels;
- if (sh_audio->wf->nSamplesPerSec)
- sh_audio->samplerate=sh_audio->wf->nSamplesPerSec;
- if (sh_audio->wf->nAvgBytesPerSec)
- sh_audio->i_bps=sh_audio->wf->nAvgBytesPerSec;
+ if (!sh_audio->samplerate && sh_audio->wf->nSamplesPerSec){ //
don't destroy a possibly good samplerate value (fLaC's)
+ sh_audio->samplerate=sh_audio->wf->nSamplesPerSec;
+ mp_msg(MSGT_DECAUDIO,MSGL_V,"[ad_ffmpeg.c:128] INFO:
sh_audio->samplerate=sh_audio->wf->nSamplesPerSec =
%d\n",sh_audio->samplerate);
+ }
+ if (!sh_audio->i_bps && sh_audio->wf->nAvgBytesPerSec){ //
don't destroy a possibly good i_bps value (fLaC's)
+ sh_audio->i_bps=sh_audio->wf->nAvgBytesPerSec;
+ mp_msg(MSGT_DECAUDIO,MSGL_V,"[ad_ffmpeg.c:132] INFO:
sh_audio->i_bps=sh_audio->wf->nAvgBytesPerSec = %d\n",sh_audio->i_bps);
+ }
}
- sh_audio->samplesize=2;
+ if (!sh_audio->samplesize){ // don't destroy a possibly good
samplesize value (fLaC's)
+ sh_audio->samplesize=2;
+ mp_msg(MSGT_DECAUDIO,MSGL_V,"[ad_ffmpeg.c:137] INFO:
sh_audio->samplesize=2 = %d\n",sh_audio->samplesize);
+ }
return 1;
}
===cut-here===
This is a test patch, probably not ready for actual commit.
The idea is to see whether ad_ffmpeg is computing wrong values for
these parms on behalf of any, some, or all audio formats. We know
it's definitely not correct for fLaC's. But already mplayer.c has
correct values for fLaC's, so we don't want ad_ffmpeg to wipe them
out with incorrect ones. My evidence of this is already posted on
the -user maillist. Of course, lots more testing of this patch is
needed for other formats, please, some of which I don't have a way
to test for now.
A good side benefit from this is that fLaC's are able to skip both
directions (arrow keys) and 'seeks' are all more accurate now with
this patch on. Yes it still steps inside a header once in a while
tho, but with my own testing here it happens much much less often,
and with much less disaster (hardly audible glitches).
Now we need to get "gapless playing" working better for fLaC's. :)
Thanks for any help on this.
More information about the MPlayer-dev-eng
mailing list