Opened 21 months ago

Closed 21 months ago

Last modified 19 months ago

#5892 closed defect (needs_more_info)

Show Qavg -nan when end of aac stream

Reported by: chengmo03013106 Owned by:
Priority: normal Component: avcodec
Version: unspecified Keywords: aac
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Hi, all:
I used demux mp4 which built as H264 & aac
When the program stopped, there was info "[aac@xxxxxx] Qavg -nan"
I found this info would generated by av_log() in aac_encode_end(AVCodecContext *avctx).
The code like this "av_log(avctx, AV_LOG_INFO, "Qavg: %.3f\n", s->lambda_sum / s->lambda_count);"
the problem was that the s->lambda_count was "0" and the type of it is int.
thinking of the value "0" is divided ?
is this a bug ?

Attachments (1)

nantest.mkv (376.3 KB) - added by mirh 19 months ago.

Download all attachments as: .zip

Change History (14)

comment:1 follow-up: Changed 21 months ago by cehoyos

I don't really understand your issue (do you think what is printed is wrong or unclear?) but in any case, please provide the command line that allows to reproduce the issue together with the complete, uncut console output to make this a valid ticket.

comment:2 in reply to: ↑ 1 ; follow-up: Changed 21 months ago by chengmo03013106

Replying to cehoyos:

I don't really understand your issue (do you think what is printed is wrong or unclear?) but in any case, please provide the command line that allows to reproduce the issue together with the complete, uncut console output to make this a valid ticket.

Thank you for the replying.
I am sorry for my confusing issue.
the printed is vivid that "Qavg -nan".
I meant that there is bug in libavcodec/aacenc.c, line:846 "av_log(avctx, AV_LOG_INFO, "Qavg: %.3f\n", s->lambda_sum / s->lambda_count);". s->lambda_count was 0 in some time, could "s->lambda_count" be 0 ? same as a/b, b should not be 0, is that right ?

Anyway the details I gave unclearly.
I didn't run the command "ffmpeg balabala..."
I invoked the API directly in my codes.

The backtrace show this:
(gdb) bt
#0 aac_encode_end (avctx=0x7fc68c045ac0) at libavcodec/aacenc.c:844
#1 0x0000000000b3254a in avcodec_close (avctx=0x7fc68c045ac0) at libavcodec/utils.c:2545
#2 0x000000000041238b in OutputProc::Close (this=0x273a600) at mediaproc.cpp:1162
#3 0x00000000004156a0 in ConvertdProcess::CloseClear? (this=0x273a4a0) at convertdprocess.cpp:562

at mediaproc.cpp:1162 is
avcodec_close(ofmt_ctx_->streams[i]->codec);

Is there enough for the issue ? If I should show more details about the issue, tell me
Thanks again.

comment:3 in reply to: ↑ 2 ; follow-up: Changed 21 months ago by cehoyos

  • Analyzed by developer unset
  • Component changed from undetermined to avcodec
  • Keywords crash fpe regression added
  • Priority changed from normal to important
  • Reproduced by developer unset

Replying to chengmo03013106:

Is there enough for the issue ?

I don't think so, from your original report I wasn't able to guess that you see a crash.
How can I reproduce the issue?

comment:4 in reply to: ↑ 3 Changed 21 months ago by chengmo03013106

Replying to cehoyos:

Replying to chengmo03013106:

Is there enough for the issue ?

I don't think so, from your original report I wasn't able to guess that you see a crash.
How can I reproduce the issue?

It's might be not a bug because it would not lead to crash.
Is it not the bug if the code which is not lead to crash ?
when the code run "s->lambda_sum / s->lambda_count", and "s->lambda_count" can be "0" ? the divider can be "0" ?

comment:5 Changed 21 months ago by cehoyos

How can I reproduce the issue?

comment:6 Changed 21 months ago by chengmo03013106

For the 1st,to avoid s->lambda_count = 0, thinking of s->lambda_sum*1000 / (s->lambda_count*1000 +1), the divider would not equal to 0.
For the second issue, the print show "Qavg -nan", I guess change the type of s->lambda_sum from float to double would solved the issue.

comment:7 Changed 21 months ago by cehoyos

If you cannot explain how I can reproduce the issue, please provide the complete gdb output (not just an excerpt) including backtrace, disassembly and register dump.

comment:8 Changed 21 months ago by chengmo03013106

It will not lead to crash actually.
That's why I call it as an issue.
Anyway, the information as follow.
backtrace --------------------
Breakpoint 1, aac_encode_end (avctx=0x7f0b70258c00) at libavcodec/aacenc.c:844
844 AACEncContext *s = avctx->priv_data;
(gdb) n
846 av_log(avctx, AV_LOG_INFO, "Qavg: %.3f\n", s->lambda_sum / s->lambda_count);
(gdb) p s->lambda_count
$2 = 0 I meat this value should be 0, because it 's divider.
(gdb) bt
#0 aac_encode_end (avctx=0x7f0b70258c00) at libavcodec/aacenc.c:848
#1 0x0000000000b324ca in avcodec_close (avctx=0x7f0b70258c00) at libavcodec/utils.c:2545

After line 846 run ,the out put :
[aac @ 0x7f0b70258c00] Qavg: -nan

disassemble ----------------------------
Dump of assembler code for function aac_encode_end:

0x0000000000e125b8 <+0>: push %rbp
0x0000000000e125b9 <+1>: mov %rsp,%rbp
0x0000000000e125bc <+4>: sub $0x20,%rsp
0x0000000000e125c0 <+8>: mov %rdi,-0x18(%rbp)
0x0000000000e125c4 <+12>: mov -0x18(%rbp),%rax
0x0000000000e125c8 <+16>: mov 0x48(%rax),%rax
0x0000000000e125cc <+20>: mov %rax,-0x8(%rbp)
0x0000000000e125d0 <+24>: mov -0x8(%rbp),%rax
0x0000000000e125d4 <+28>: movss 0x968c(%rax),%xmm1
0x0000000000e125dc <+36>: mov -0x8(%rbp),%rax
0x0000000000e125e0 <+40>: mov 0x9690(%rax),%eax
0x0000000000e125e6 <+46>: cvtsi2ss %eax,%xmm0
0x0000000000e125ea <+50>: movaps %xmm1,%xmm2
0x0000000000e125ed <+53>: divss %xmm0,%xmm2
0x0000000000e125f1 <+57>: movaps %xmm2,%xmm0
0x0000000000e125f4 <+60>: unpcklps %xmm0,%xmm0
0x0000000000e125f7 <+63>: cvtps2pd %xmm0,%xmm0
0x0000000000e125fa <+66>: mov -0x18(%rbp),%rax
0x0000000000e125fe <+70>: mov $0x139ce75,%edx
0x0000000000e12603 <+75>: mov $0x20,%esi
0x0000000000e12608 <+80>: mov %rax,%rdi
0x0000000000e1260b <+83>: mov $0x1,%eax
0x0000000000e12610 <+88>: callq 0xfb9bc5 <av_log>

=> 0x0000000000e12615 <+93>: mov -0x8(%rbp),%rax

0x0000000000e12619 <+97>: add $0x50,%rax
0x0000000000e1261d <+101>: mov %rax,%rdi
0x0000000000e12620 <+104>: callq 0x952ecf <ff_mdct_end>
0x0000000000e12625 <+109>: mov -0x8(%rbp),%rax
0x0000000000e12629 <+113>: add $0xb8,%rax
0x0000000000e1262f <+119>: mov %rax,%rdi
0x0000000000e12632 <+122>: callq 0x952ecf <ff_mdct_end>
0x0000000000e12637 <+127>: mov -0x8(%rbp),%rax
0x0000000000e1263b <+131>: add $0x9618,%rax
0x0000000000e12641 <+137>: mov %rax,%rdi
0x0000000000e12644 <+140>: callq 0xf44b10 <ff_psy_end>
0x0000000000e12649 <+145>: mov -0x8(%rbp),%rax
0x0000000000e1264d <+149>: add $0x280,%rax
0x0000000000e12653 <+155>: mov %rax,%rdi
0x0000000000e12656 <+158>: callq 0x94f76f <ff_lpc_end>
0x0000000000e1265b <+163>: mov -0x8(%rbp),%rax
0x0000000000e1265f <+167>: mov 0x9668(%rax),%rax
0x0000000000e12666 <+174>: test %rax,%rax
0x0000000000e12669 <+177>: je 0xe1267e <aac_encode_end+198>
0x0000000000e1266b <+179>: mov -0x8(%rbp),%rax
0x0000000000e1266f <+183>: mov 0x9668(%rax),%rax
0x0000000000e12676 <+190>: mov %rax,%rdi
0x0000000000e12679 <+193>: callq 0xf44de2 <ff_psy_preprocess_end>
0x0000000000e1267e <+198>: mov -0x8(%rbp),%rax
0x0000000000e12682 <+202>: add $0x8a840,%rax
0x0000000000e12688 <+208>: mov %rax,%rdi
0x0000000000e1268b <+211>: callq 0xfbca0e <av_freep>
0x0000000000e12690 <+216>: mov -0x8(%rbp),%rax
0x0000000000e12694 <+220>: add $0x9610,%rax
0x0000000000e1269a <+226>: mov %rax,%rdi
0x0000000000e1269d <+229>: callq 0xfbca0e <av_freep>
0x0000000000e126a2 <+234>: mov -0x8(%rbp),%rax

---Type <return> to continue, or q <return> to quit---

0x0000000000e126a6 <+238>: add $0x120,%rax
0x0000000000e126ac <+244>: mov %rax,%rdi
0x0000000000e126af <+247>: callq 0xfbca0e <av_freep>
0x0000000000e126b4 <+252>: mov -0x8(%rbp),%rax
0x0000000000e126b8 <+256>: add $0x9698,%rax
0x0000000000e126be <+262>: mov %rax,%rdi
0x0000000000e126c1 <+265>: callq 0xe6fc3e <ff_af_queue_close>
0x0000000000e126c6 <+270>: mov $0x0,%eax
0x0000000000e126cb <+275>: leaveq
0x0000000000e126cc <+276>: retq

register info -------------------
rax 0x0 0
rbx 0x3056b00 50686720
rcx 0x3c37adb53d 258632168765
rdx 0xc 12
rsi 0x0 0
rdi 0x7f0b7dbfcd80 139687331089792
rbp 0x7f0b7dbfd340 0x7f0b7dbfd340
rsp 0x7f0b7dbfd320 0x7f0b7dbfd320
r8 0x7f0b7dbfe700 139687331096320
r9 0x7f0b7dbfc594 139687331087764
r10 0x0 0
r11 0x0 0
r12 0x3c3841c360 258641871712
r13 0x7f0b7dbfe9c0 139687331097024
r14 0x4 4
r15 0x7 7
rip 0xe12615 0xe12615 <aac_encode_end+93>
eflags 0x202 [ IF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0

Last edited 21 months ago by chengmo03013106 (previous) (diff)

comment:9 follow-up: Changed 21 months ago by cehoyos

So there is no bug?

comment:10 in reply to: ↑ 9 Changed 21 months ago by chengmo03013106

Replying to cehoyos:

So there is no bug?

yep~
I am newbie here, so it's shouldn't report here if it was not a bug which lead to crashed ?

comment:11 Changed 21 months ago by cehoyos

  • Keywords crash fpe regression removed
  • Priority changed from important to normal
  • Resolution set to needs_more_info
  • Status changed from new to closed

Every bug should be reported on this bug tracker (or the user mailing list).
Unfortunately, I don't understand what bug you want to report and iirc, you did not explain how I can reproduce the issue you see. The fact alone that -nan is printed (as an information) does not seem like a bug to me but feel free to reopen if you can explain how I can reproduce the issue.

comment:12 Changed 20 months ago by dr_pardee

I know this is closed but I came across something similar today. My guess is that chengmo03013106 stream's index wasn't specified so that ffmpeg (av_find_best_stream) wasn't able to pick the "best" stream for each type.

Changed 19 months ago by mirh

comment:13 Changed 19 months ago by mirh

I.. Think you should be able to reproduce this awkward issue with the above sample.
I use:

ffmpeg -i nantest.mkv -f rtsp abc.mkv

EDIT: for some reason shared builds simply quit the process instead, as if I hadn't specified any outfile

Last edited 19 months ago by mirh (previous) (diff)
Note: See TracTickets for help on using tickets.