Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Missing files and documentation #1

Open
sherpya opened this issue Sep 5, 2018 · 0 comments
Open

Missing files and documentation #1

sherpya opened this issue Sep 5, 2018 · 0 comments
Assignees
@sherpya
Labels
enhancement

Comments

@sherpya
Copy link
Owner

sherpya commented Sep 5, 2018

(WSC)

Your downloads of FFmpeg some years ago had FFplay, but your latest builds do not. Can I still get it from your site? FFplay html document also.

The Presets.ffmpeg directory and the 36, libx264 files are not there. How can I get them?

FFprobe html document is missing.

The FFmpeg.html documentation has nothing about video filters any more. -vf scale, crop, and pad et cetera. Where can I get the document that has this?
@sherpya sherpya self-assigned this Sep 5, 2018
sherpya pushed a commit that referenced this issue Oct 25, 2018
@tmm1
avcodec/cbs: ensure user_data is padded for GBC parsing
41ed2c3 
Fixes crash noticed in the cbs_userdata patchset.

====ERROR: AddressSanitizer: heap-buffer-overflow on address 0x609000026c89 at pc 0x00010725d37b bp 0x7ffeea04e750 sp 0x7ffeea04e748
READ of size 4 at 0x609000026c89 thread T0
    #0 0x10725d37a in ff_cbs_read_unsigned get_bits.h:274
    #1 0x1072d2767 in ff_cbs_read_a53_user_data cbs_misc_syntax_template.c:119
    FFmpeg#2 0x1078251a7 in h264_metadata_filter h264_metadata_bsf.c:595
    FFmpeg#3 0x105c1321d in output_packet ffmpeg.c:853

0x609000026c89 is located 1 bytes to the right of 8-byte region [0x609000026c80,0x609000026c88)
allocated by thread T0 here:
    #0 0x10aef08d7 in wrap_posix_memalign (libclang_rt.asan_osx_dynamic.dylib:x86_64h+0x578d7)
    #1 0x10aca95e6 in av_malloc mem.c:87
    FFmpeg#2 0x10ac545fe in av_buffer_allocz buffer.c:72
    FFmpeg#3 0x107263b27 in cbs_h264_read_nal_unit cbs_h264_syntax_template.c:722
    FFmpeg#4 0x10725b688 in cbs_read_fragment_content cbs.c:155

Signed-off-by: Aman Gupta <[email protected]>
@sherpya sherpya removed the bug label Jun 3, 2020
sherpya pushed a commit that referenced this issue Oct 24, 2021
@huww98 @mstorsjo
movenc: Get rid of frag_start
4cdab8d 
"frag_start" is redundant, and every occurance can be replaced with cluster[0].dts - start_dts

The proof of no behaviour changes: (All line number below is based on commit bff7d66)

"frag_start" is read at 4 place (with all possible call stacks):

mov_write_packet
  ...
  mov_flush_fragment
    mov_write_moof_tag
      mov_write_moof_tag_internal
        mov_write_traf_tag
          mov_write_tfxd_tag (#1)
          mov_write_tfdt_tag (FFmpeg#2)
      mov_add_tfra_entries (FFmpeg#3)
      mov_write_sidx_tags
        mov_write_sidx_tag (FFmpeg#4)

mov_write_trailer
  mov_auto_flush_fragment
    mov_flush_fragment
      ... (#1 FFmpeg#2 FFmpeg#3 FFmpeg#4)
  mov_write_sidx_tags
    mov_write_sidx_tag (FFmpeg#4)
  shift_data
    compute_sidx_size
      get_sidx_size
        mov_write_sidx_tags
          mov_write_sidx_tag (FFmpeg#4)

All read happens in "mov_write_trailer" and "mov_write_moof_tag". So we need to prove no behaviour change in these two
functions.

Condition 1: for every track that have "trk->entry == 0", trk->frag_start == trk->track_duration.

Condition 2: for every track that have "trk->entry > 0", trk->frag_start == trk->cluster[0].dts - trk->start_dts.

Definition 1: "Before flush" means just before the invocation of "mov_flush_fragment", except for the auto-flush case in
"mov_write_single_packet", which means before L5934.

Lemma 1: If Condition 1 & 2 is true before flush, Condition 1 & 2 is still true after "mov_flush_fragment" returns.

    Proof:
    No update to the tracks that have "trk->entry == 0" before flushing, so we only consider tracks that have "trk->entry > 0":

    Case 1: !moov_written and moov will be written in this iteration
        trk->entry = 0                                                                    L5366
        trk->frag_start == trk->cluster[0].dts - trk->start_dts                           Lemma condition
        trk->frag_start += trk->start_dts + trk->track_duration - trk->cluster[0].dts;    L5363
        So trk->entry == 0 && trk->frag_start == trk->track_duration
    Case 2: !moov_written and moov will NOT be written in this iteration
        nothing changed
    Case 3: moov_written
        trk->entry = 0                                                                    L5445
        trk->frag_start == trk->cluster[0].dts - trk->start_dts                           Lemma condition
        trk->frag_start += trk->start_dts + trk->track_duration - trk->cluster[0].dts;    L5444
        So trk->entry == 0 && trk->frag_start == trk->track_duration

    Note that trk->track_duration may be updated for the tracks that have "trk->entry > 0" (mov_write_moov_tag will
    update track_duration of "tmcd" track, but it must have 1 entry). But in all case, trk->frag_start is also updated
    to consider the new value.

Lemma 2: If Condition 1 & 2 is true before "ff_mov_write_packet" invocation, Condition 1 & 2 is still true after it returns.

    Proof:
    Only the track corresponding to the pkt is updated, and no update to relevant variables if trk->entry > 0 before invocation.
    So we only need to prove "trk->frag_start == trk->cluster[0].dts - trk->start_dts" after trk->entry increase from 0 to 1.

    Case 1: trk->start_dts == AV_NOPTS_VALUE
        Case 1.1: trk->frag_discont && use_editlist
            trk->cluster[0].dts = pkt->dts        at L5741
            trk->frag_start = pkt->pts            at L5785
            trk->start_dts = pkt->dts - pkt->pts  at L5786
            So trk->frag_start == trk->cluster[0].dts - trk->start_dts
        Case 1.2: trk->frag_discont && !use_editlist
            trk->cluster[0].dts = pkt->dts        at L5741
            trk->frag_start = pkt->dts            at L5790
            trk->start_dts = 0                    at L5791
            So trk->frag_start == trk->cluster[0].dts - trk->start_dts
        Case 1.3: !trk->frag_discont
            trk->cluster[0].dts = pkt->dts        at L5741
            trk->frag_start = 0                   init
            trk->start_dts = pkt->dts             at L5779
            So trk->frag_start == trk->cluster[0].dts - trk->start_dts
    Case 2: trk->start_dts != AV_NOPTS_VALUE
        Case 2.1: trk->frag_discont
            trk->cluster[0].dts = pkt->dts                at L5741
            trk->frag_start = pkt->dts - trk->start_dts   at L5763
            So trk->frag_start == trk->cluster[0].dts - trk->start_dts
        Case 2.2: !trk->frag_discont
            trk->cluster[0].dts = trk->start_dts + trk->track_duration  at L5749
            trk->track_duration == trk->frag_start                      Lemma condition
            So trk->frag_start == trk->cluster[0].dts - trk->start_dts

Lemma 3: Condition 1 & 2 is true in all case before and after "ff_mov_write_packet" invocation, before flush and after
         "mov_flush_fragment" returns.

    Proof: All updates to relevant variable happen either in "ff_mov_write_packet", or during flush. And Condition 1 & 2
           is true initially. So with lemma 1 & 2, we can prove this use induction.

Noticed that all read of "frag_start" only happen in "trk->entry > 0" branch. Now we need to prove Condition 2 is true
before each read.

Because no update to variables relevant to Condition 2 between "before flush" and "mov_write_moof_tag" invocation, we
can conclude Condition 2 is true before every invocation of "mov_write_moof_tag". No behaviour change in
"mov_write_moof_tag" is proved.

In "mov_write_trailer", No update to relevant variables after the last flush and before the invocation of
"mov_write_sidx_tag". So no behaviour change to "mov_write_trailer" is proved.

Q.E.D.

Signed-off-by: Hu Weiwen <[email protected]>
Signed-off-by: Martin Storsjö <[email protected]>
sherpya pushed a commit that referenced this issue Dec 30, 2021
@Yuyang14 @michaelni
libswresample/swresamplec: Err num(negative-size) was used as a funct…
ac2b34a 
…ion parameter

If memory allocation fails, ERROR(ENOMEM) '-12' will be returned.
When resample() is done first, the negative size param would cause buffer-overflow and SEGV in swri_rematrix().
When swri_rematrix() is run first, resample() would not cause an error but Err num as a wrong parameter passing.
Err num should be returned immediately. And remove an unneeded term from an assert.

coredump info:
    #0 0x499517 in posix_memalign (/home/r1/ffmpeg/ffmpeg_4.4.1+0x499517)
    #1 0x6c1f0b4 in av_malloc /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavutil/mem.c:86:9
    FFmpeg#2 0x6c208fe in av_mallocz /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavutil/mem.c:239:17
    FFmpeg#3 0x6c207ad in av_mallocz_array /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavutil/mem.c:195:12
    FFmpeg#4 0x654b2e5 in swri_realloc_audio /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libswresample/swresample.c:418:14
    FFmpeg#5 0x654f9a1 in swr_convert_internal /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libswresample/swresample.c:601:17
    FFmpeg#6 0x654d2c0 in swr_convert /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libswresample/swresample.c:766:19
    FFmpeg#7 0x186cf56 in flush_frame /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/af_aresample.c:251:13
    FFmpeg#8 0x186a454 in request_frame /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/af_aresample.c:288:20
    FFmpeg#9 0x787d9c in ff_request_frame_to_filter /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfilter.c:459:15
    FFmpeg#10 0x7877f1 in forward_status_change /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfilter.c:1257:19
    FFmpeg#11 0x77ed7e in ff_filter_activate_default /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfilter.c:1288:20
    FFmpeg#12 0x77e4e1 in ff_filter_activate /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfilter.c:1441:11
    FFmpeg#13 0x793b3f in ff_filter_graph_run_once /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfiltergraph.c:1403:12
    FFmpeg#14 0x7a7bee in get_frame_internal /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/buffersink.c:131:19
    FFmpeg#15 0x7a7287 in av_buffersink_get_frame_flags /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/buffersink.c:142:12
    FFmpeg#16 0x792888 in avfilter_graph_request_oldest /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/libavfilter/avfiltergraph.c:1356:17
    FFmpeg#17 0x5d07df in transcode_from_filter /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/fftools/ffmpeg.c:4639:11
    FFmpeg#18 0x59e557 in transcode_step /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/fftools/ffmpeg.c:4729:20
    FFmpeg#19 0x593970 in transcode /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/fftools/ffmpeg.c:4805:15
    FFmpeg#20 0x58f7a4 in main /home/r1/ffmpeg/ffmpeg-4.4.1/build/src/fftools/ffmpeg.c:5010:9
    FFmpeg#21 0x7f6fd2dee0b2 in __libc_start_main /build/glibc-eX1tMB/glibc-2.31/csu/../csu/libc-start.c:308:16

SUMMARY: AddressSanitizer: negative-size-param (/home/r1/ffmpeg/ffmpeg_4.4.1+0x497e67) in __asan_memcpy

Reported-by: TOTE Robot <[email protected]>
Signed-off-by: Michael Niedermayer <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sherpya sherpya

Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@sherpya