Opened 8 years ago
Closed 8 years ago
#5729 closed defect (fixed)
FLV key frame index at start may be skipped
Reported by: | snorlaxzxz | Owned by: | |
---|---|---|---|
Priority: | important | Component: | avformat |
Version: | git-master | Keywords: | flv regression |
Cc: | zhangxzheng@gmail.com | Blocked By: | |
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Summary of the bug:
keyframe in metadata will be dropped until the first video frame comes.
How to reproduce:
seek attatched file.
Attachments (1)
Change History (8)
by , 8 years ago
Attachment: | heheheh.flv added |
---|
follow-ups: 2 3 comment:1 by , 8 years ago
Keywords: | flv added; flvdec removed |
---|
follow-up: 5 comment:2 by , 8 years ago
Cc: | added |
---|---|
Summary: | Failure of seeking in FLVs → FLV key frame index at start may be skipped |
Replying to cehoyos:
Seeking works fine here for the uploaded sample.
Please provide the command line that allows to reproduce the issue together with the complete, uncut console output.
The issue was introduced since 09ae7b81ea. It may slow down seeking in online streams.
In flvdec.c 420
case AMF_DATA_TYPE_OBJECT: if ((vstream || astream) && key && ioc->seekable && !strcmp(KEYFRAMES_TAG, key) && depth == 1) if (parse_keyframes_index(s, ioc, vstream ? vstream : astream, max_pos) < 0)
If the first packet we got is object, both vstream and astream are NULL,
which may prevent keyframe index being parsed.
Eg. [meta:keyframe index]-[a]-[v]-[a]-[v]...
I have sent a patch to ML
avformat/fivdec: cached keyframes before video or audio stream was created
comment:3 by , 8 years ago
Replying to cehoyos:
Seeking works fine here for the uploaded sample.
Please provide the command line that allows to reproduce the issue together with the complete, uncut console output.
Sorry, the meta data in sample seems to be cutted. Please check it in original file.
https://drive.google.com/file/d/0B4mDLcW3R2feMjdYWk14XzduNjA/view?usp=sharing
comment:4 by , 8 years ago
Replying to snorlaxzxz:
Summary of the bug:
keyframe in metadata will be dropped until the first video frame comes.
How to reproduce:
seek attatched file.
https://drive.google.com/file/d/0B4mDLcW3R2feMjdYWk14XzduNjA/view?usp=sharing
follow-up: 6 comment:5 by , 8 years ago
Keywords: | regression added |
---|---|
Priority: | normal → important |
Replying to snorlaxzxz:
Replying to cehoyos:
Seeking works fine here for the uploaded sample.
Please provide the command line that allows to reproduce the issue together with the complete, uncut console output.
The issue was introduced since 09ae7b81ea. It may slow down seeking in online streams.
You could still elaborate on how we can reproduce the issue you see.
comment:6 by , 8 years ago
Replying to cehoyos:
Replying to snorlaxzxz:
Replying to cehoyos:
Seeking works fine here for the uploaded sample.
Please provide the command line that allows to reproduce the issue together with the complete, uncut console output.
The issue was introduced since 09ae7b81ea. It may slow down seeking in online streams.
You could still elaborate on how we can reproduce the issue you see.
The first way:
You can reproduce the issue by accessing this file from a bandwidth limited web server (like 200KB/s)
It takes tens of seconds to seek to a far position.
Another way:
Set a break point or add an av_log() in parse_keyframes_index()
in libavformat/flvdec.c
.
It will not be called in n3.1.1 but works fine in n3.0
The reason is explained above.
Seeking works fine here for the uploaded sample.
Please provide the command line that allows to reproduce the issue together with the complete, uncut console output.