[PATCH] h264: Return the correct number of bytes for mid strea, extradata.
Fixes the hang with Ticket952 Signed-off-by: Michael Niedermayer <michaelni@gmx.at> --- libavcodec/h264.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/h264.c b/libavcodec/h264.c index 962b5dc..a4892ac 100644 --- a/libavcodec/h264.c +++ b/libavcodec/h264.c @@ -1125,7 +1125,7 @@ int ff_h264_decode_extradata(H264Context *h, const uint8_t *buf, int size) if(decode_nal_units(h, buf, size) < 0) return -1; } - return 0; + return size; } av_cold int ff_h264_decode_init(AVCodecContext *avctx){ @@ -1170,7 +1170,7 @@ av_cold int ff_h264_decode_init(AVCodecContext *avctx){ } if(avctx->extradata_size > 0 && avctx->extradata && - ff_h264_decode_extradata(h, avctx->extradata, avctx->extradata_size)) + ff_h264_decode_extradata(h, avctx->extradata, avctx->extradata_size)<0) return -1; if(h->sps.bitstream_restriction_flag && s->avctx->has_b_frames < h->sps.num_reorder_frames){ -- 1.7.5.4
Le decadi 10 pluviôse, an CCXX, Michael Niedermayer a écrit :
Fixes the hang with Ticket952
It fixes the hang, but the file itself still does not play. Truncating packet of size 10980 to 8667 [flv @ 0x1d1b4e0] decoding for stream 0 failed [flv @ 0x1d1b4e0] Could not find codec parameters (Video: h264) Input #0, flv, from '/tmp/black_rock_shooter_teaser-hq-truncated.flv': Metadata: audiochannels : 2 videoframerate : 30 aacaot : 2 avclevel : 31 avcprofile : 100 frameWidth : 640 frameHeight : 360 displayWidth : 640 displayHeight : 360 moovposition : 40 Duration: 00:00:35.46, start: 0.000000, bitrate: 236 kb/s Stream #0:0: Video: h264, 29.97 tbr, 1k tbn, 2k tbc Stream #0:1: Audio: aac, 44100 Hz, stereo, s16 Output #0, sdl, to '': Metadata: audiochannels : 2 videoframerate : 30 aacaot : 2 avclevel : 31 avcprofile : 100 frameWidth : 640 frameHeight : 360 displayWidth : 640 displayHeight : 360 moovposition : 40 Output file #0 does not contain any stream Furthermore, returning non-0 when ff_h264_decode_extradata seems to be incompatible with that piece of code: if(avctx->extradata_size > 0 && avctx->extradata && ff_h264_decode_extradata(h, avctx->extradata, avctx->extradata_size)) return -1; Adding the obvious "< 0" there makes the file play with the broken first frames, which is better than nothing but still not perfect. Thanks for your time. Regards, -- Nicolas George
On Sun, Jan 29, 2012 at 09:29:02PM +0100, Nicolas George wrote:
Le decadi 10 pluviôse, an CCXX, Michael Niedermayer a écrit :
Fixes the hang with Ticket952
It fixes the hang, but the file itself still does not play.
yes ive sent a second patch that fixes extradata changes with multiple threads. are you ok with me applying both, or do you see some better solution? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad
Le primidi 11 pluviôse, an CCXX, Michael Niedermayer a écrit :
yes ive sent a second patch that fixes extradata changes with multiple threads.
are you ok with me applying both, or do you see some better solution?
I am affraid I still get this: Output file #0 does not contain any stream same as before. Or maybe I did not try the correct patch: I tried with this one and: mpeg/h264: update thread context even if it is not initialized. Did I miss some? Also, do you know where I can find reference of what this extradata is about? Regards, -- Nicolas George
On Mon, Jan 30, 2012 at 11:56:07AM +0100, Nicolas George wrote:
Le primidi 11 pluviôse, an CCXX, Michael Niedermayer a écrit :
yes ive sent a second patch that fixes extradata changes with multiple threads.
are you ok with me applying both, or do you see some better solution?
I am affraid I still get this:
Output file #0 does not contain any stream
same as before. Or maybe I did not try the correct patch: I tried with this one and:
mpeg/h264: update thread context even if it is not initialized.
Did I miss some?
i get: frame= 306 fps=123 q=31.0 Lsize= 779kB time=00:00:10.26 bitrate= 621.8kbits/s video:593kB audio:160kB global headers:0kB muxing overhead 3.491434% with the 2 patches
Also, do you know where I can find reference of what this extradata is about?
its SPS & PPS, described in the H264 spec, some mpeg4/iso spec should contain the format and some flv spec might contain some information too [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There seems to be only one solution to NIH syndrom, ... a shooting squad
On Mon, Jan 30, 2012 at 07:25:19PM +0100, Michael Niedermayer wrote:
On Mon, Jan 30, 2012 at 11:56:07AM +0100, Nicolas George wrote:
Le primidi 11 pluviôse, an CCXX, Michael Niedermayer a écrit :
yes ive sent a second patch that fixes extradata changes with multiple threads.
are you ok with me applying both, or do you see some better solution?
I am affraid I still get this:
Output file #0 does not contain any stream
same as before. Or maybe I did not try the correct patch: I tried with this one and:
mpeg/h264: update thread context even if it is not initialized.
Did I miss some?
i get: frame= 306 fps=123 q=31.0 Lsize= 779kB time=00:00:10.26 bitrate= 621.8kbits/s video:593kB audio:160kB global headers:0kB muxing overhead 3.491434%
with the 2 patches
ok if i apply this patch? it fixes the return value making it match the number of consumed bytes. The strange behavior you see could be caused by a undiscovered issue in the second patch. It is no doubt more tricky code. But i ATM dont really see anything i could do here except applying and waiting for a reproduceable bug report considering it works for me [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth.
Le primidi 11 pluviôse, an CCXX, Michael Niedermayer a écrit :
i get: frame= 306 fps=123 q=31.0 Lsize= 779kB time=00:00:10.26 bitrate= 621.8kbits/s video:593kB audio:160kB global headers:0kB muxing overhead 3.491434%
with the 2 patches
I re-tried from a clean working tree (I was not under the best of circumstances to work yesterday) and it worked; I do not know how I fumbled my first test. Anyway, these two patches fix the problem for me, so go ahead since obviously you know what this is about. Thanks. Regards, -- Nicolas George
On Tue, Jan 31, 2012 at 06:43:19PM +0100, Nicolas George wrote:
Le primidi 11 pluviôse, an CCXX, Michael Niedermayer a écrit :
i get: frame= 306 fps=123 q=31.0 Lsize= 779kB time=00:00:10.26 bitrate= 621.8kbits/s video:593kB audio:160kB global headers:0kB muxing overhead 3.491434%
with the 2 patches
I re-tried from a clean working tree (I was not under the best of circumstances to work yesterday) and it worked; I do not know how I fumbled my first test.
Anyway, these two patches fix the problem for me, so go ahead since obviously you know what this is about.
thx applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus
Le duodi 12 pluviôse, an CCXX, Michael Niedermayer a écrit :
thx applied
Another sample wrom the same origin with a similar, but not identical issue, has been brought to my attention: like the one in this thread, the first few frames are gray; unlike it, there is no error message and libav fails the same way. Are you interested in seeing it? Regards, -- Nicolas George
On Mon, Feb 06, 2012 at 10:34:44AM +0100, Nicolas George wrote:
Le duodi 12 pluviôse, an CCXX, Michael Niedermayer a écrit :
thx applied
Another sample wrom the same origin with a similar, but not identical issue, has been brought to my attention: like the one in this thread, the first few frames are gray; unlike it, there is no error message and libav fails the same way.
Are you interested in seeing it?
of course [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 "Rare item" - "Common item with rare defect or maybe just a lie" "Professional" - "'Toy' made in china, not functional except as doorstop" "Experts will know" - "The seller hopes you are not an expert"
L'octidi 18 pluviôse, an CCXX, Michael Niedermayer a écrit :
Are you interested in seeing it? of course
I have attached it to the same ticket, 952. The URL is: https://ffmpeg.org/trac/ffmpeg/attachment/ticket/952/fmab-01-truncated.mp4 Regards, -- Nicolas George
On Mon, Feb 06, 2012 at 08:03:00PM +0100, Nicolas George wrote:
L'octidi 18 pluviôse, an CCXX, Michael Niedermayer a écrit :
Are you interested in seeing it? of course
I have attached it to the same ticket, 952. The URL is: https://ffmpeg.org/trac/ffmpeg/attachment/ticket/952/fmab-01-truncated.mp4
i can reproduce the gray frames but not any hang is there some decoder that does play this better (that is for example with something else than the gray frames) ? [..] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange
Michael Niedermayer <michaelni <at> gmx.at> writes:
https://ffmpeg.org/trac/ffmpeg/attachment/ticket/952/fmab-01-truncated.mp4
i can reproduce the gray frames but not any hang is there some decoder that does play this better (that is for example with something else than the gray frames) ?
The reference decoder is bitexact with FFmpeg (including the grey frames). Carl Eugen
Le nonidi 19 pluviôse, an CCXX, Michael Niedermayer a écrit :
i can reproduce the gray frames but not any hang
Same here. Sorry if my comment mislead you to think there was a hang.
is there some decoder that does play this better (that is for example with something else than the gray frames) ?
I finally managed to test with the official flash player, and it shows the gray frames too. I guess that is just the way this video was done and we can forget about it. Sorry for the wasted time. Regards, -- Nicolas George
participants (3)
-
Carl Eugen Hoyos -
Michael Niedermayer -
Nicolas George