Alexander Strange added the comment:
It would be best to throw out times and proceed by interpolation from
the last good one. In a way that works, since IIRC it currently half-
does it in a way that doesn't work.
Posting the backtrace of the non monotone timestamp av_log would be
helpf
Alexander Strange added the comment:
Mine. FFmpeg doesn't do auto threads, so I normalized 0 to 1, but x264
does. We should pass through 0 untouched.
--
assignedto: -> astrange
nosy: +astrange
priority: normal -> important
status: new -> open
substatu
New submission from Alexander Strange :
SVQ3 appears to have slices, so it could be slice-threaded. However I
doubt there are any >480p files encoded in SVQ3, so it probably doesn't
matter.
--
messages: 12957
priority: normal
status: new
substatus: new
title: slice-threading
New submission from Alexander Strange :
The normal priority in the front page of roundup lists tons of license
compliance issues mixed with the actual code bugs. We want people to fix
bugs, so we should be showing actionable bugs to them. This might require
giving the license issues a
Alexander Strange added the comment:
YUVJ/YUV color issues are contrast, not gamma.
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue2049>
New submission from Alexander Strange :
The rm demuxer sets the file's timestamps as pts. These are monotone even
though the
codec uses B-frames, so they come out of decoding out of order and confuse
ffmpeg.
It should set them as dts instead.
> ffprobe -show_packets fate-suite/real
Alexander Strange added the comment:
H.264 decodes out of order, you should expect up to 16 frames delay. See
reordered_opaque for the proper way to handle this.
Also it's allowed for packets to contain one field, in which case two
fields need to be combined into one
Alexander Strange added the comment:
h264 crashes with vflip too.
dest_cb = s->current_picture.data[1] + (mb_x + mb_y * s->uvlinesize)
* 8;
points out of the picture if uvlinesize is negative.
Fixing this would complicate h264 slightly. Should codecs be required to
suppor
New submission from Alexander Strange :
http://astrange.ithinksw.net/ffmpeg/camp_mot_mbaff0_full.mp4
This file is CFR and has packet timestamps that increment by 3003. ffmpeg.c's
next_pts generation only increments by 5. This is because it uses the codec
time_base, but in this file it&
New submission from Alexander Strange :
http://astrange.ithinksw.net/ffmpeg/hrpreviews5mb.mkv
First two packets in ffprobe:
[PACKET]
codec_type=video
stream_index=0
pts=-33
pts_time=-0.033000
dts=-33
dts_time=-0.033000
duration=33
duration_time=0.033000
size=127636.00
pos=5426
flags=K
Alexander Strange added the comment:
Applied.
--
status: open -> closed
substatus: reproduced -> fixed
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue1815>
Alexander Strange added the comment:
How about:
>From 0a0ba38f87c64872be47b0a9f434a33ba0d118ee Mon Sep 17 00:00:00 2001
From: Alexander Strange
Date: Sun, 28 Mar 2010 19:07:50 -0400
Subject: [PATCH 2/2] H264: Copy h264dsp when creating new slice threads
Fixes slice multithreading (broken
Alexander Strange added the comment:
Does it crash with --disable-optimizations? Assuming that disables
optimizations in icc.
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue1802>
New submission from Alexander Strange :
Using camp_mot_mbaff0_full.264 from AVC test streams:
> ./ffmpeg_g -i camp_mot_mbaff0_full.264 -vcodec copy camp.mp4
FFmpeg version git-e156a4d, Copyright (c) 2000-2010 the FFmpeg developers
built on Mar 11 2010 00:38:48 with gcc 4.2.1 (Apple Inc. bu
Alexander Strange added the comment:
The cause of issue1801 at least is different; there are no data tracks
there, just two tracks with edit lists that give them negative starting
times. Don't know if that matters as I haven't looked at
New submission from Alexander Strange :
Sample: incoming/negative_start_time.mov
./ffmpeg_g -i ~/negative_start_time.mov
FFmpeg version SVN-r22378, Copyright (c) 2000-2010 the FFmpeg developers
built on Mar 9 2010 02:54:17 with gcc 4.2.1 (Apple Inc. build 5646) (dot 1)
configuration
Alexander Strange added the comment:
r20347 broke the file's input audio stream timestamps
(index_entries[x].duration) - instead of [0,1,2...] it's now
[0,1152,2304,...].
Reverting doesn't seem to affect this.
_
FFmpe
New submission from Alexander Strange :
In incoming/truetears-streamcopy-error.avi.
The audio timestamps seem misdetected, pkt->duration in the output is 2x what
it should be for 48khz mp3 (4320 instead of
2160/9).
> gdb --args ~/Projects/video/ffmpeg-dbg/ffmpeg_g -fdebug
Alexander Strange added the comment:
Not important anymore.
--
priority: important -> normal
_
FFmpeg issue tracker
<https://roundup.ffmpeg.org/roundup/ffmpeg/issue1238>
_
Alexander Strange added the comment:
Then it's fixed.
--
status: open -> closed
substatus: reproduced -> fixed
_
FFmpeg issue tracker
<https://roundup.ffmpeg.org/roundup/ffmpeg/issue1183>
_
Alexander Strange added the comment:
Applied and sample deleted.
Since num_reorder_frames is an advisory value, this file is easy to
support (reset num_reorder_frames on error) and to fix (clear
bitstream_restriction_flag). But since all other pps/sps errors were
made to error in r15972, I
Alexander Strange added the comment:
Fixed in r19328. I'd still like to apply the patch for -debug 1.
_
FFmpeg issue tracker
<https://roundup.ffmpeg.org/roundup/ffmpeg/issue1238>
_
Alexander Strange added the comment:
Fixed in r19328. Sample deleted.
--
status: new -> closed
substatus: new -> fixed
_
FFmpeg issue tracker
<https://roundup.ffmpeg.org/roundup/ffmpeg/issue1229>
_
Alexander Strange added the comment:
Applied with the changes and extra parens (for the gcc = vs. == warning).
I was looking at the NAL_SLICE check, which doesn't use < 0.
Sample deleted.
--
status: new -> closed
substatus: n
Alexander Strange added the comment:
Of course, but it was late and I was hoping someone else would figure it
out while I was asleep ;)
Like issue1229 and issue1238, this is caused by trash being read as various
NALs. It sees NAL_DPA and then NAL_DPC, which causes it to start decoding.
This
Alexander Strange added the comment:
That patch is just in case it still crashes for someone else; I don't mean
to submit it since it causes the file to be rejected, possibly
unnecessarily.
_
FFmpeg issue tracker
&
Alexander Strange added the comment:
svn updated and now I can't reproduce it.
The SPS is corrupted at the end and it fails reading num_reorder_frames.
decode_vui_parameters() returns -1, but this is
ignored. Respecting it causes the entire file to fail to decode, in case that'
Alexander Strange added the comment:
Fixed by the first patch for issue1228.
Attached another one to fix a further crash here when -debug 1 is used.
_
FFmpeg issue tracker
<https://roundup.ffmpeg.org/roundup/ffmpeg/issue1
Alexander Strange added the comment:
Assertion failed: (pics <= MAX_DELAYED_PIC_COUNT), function decode_frame, file
libavcodec/h264.c,
line 7896.
(gdb) bt
#0 0x91010fd6 in usleep$NOCANCEL$UNIX2003 ()
#1 0x91028685 in abort ()
#2 0x9101d3db in __assert_rtn ()
#3 0x002da869
Alexander Strange added the comment:
Another short_ref_count==long_ref_count==0 problem. Also, decode starts
without decode_slice_header ever finishing, so current_picture_ptr
isn't set
NAL parser reads a bunch of junk as NAL_IDR_SLICE (resetting the
short_ref) and then NAL_DPC (sta
Alexander Strange added the comment:
Attached patch fixes the other crash.
_
FFmpeg issue tracker
<https://roundup.ffmpeg.org/roundup/ffmpeg/issue1228>
_Index: libavcodec/
Alexander Strange added the comment:
(gdb) print h->sps.ref_frame_count
$3 = 0
_
FFmpeg issue tracker
<https://roundup.ffmpeg.org/roundup/ffmpeg/issue1228>
_
Alexander Strange added the comment:
mb_y is past mb_height on entry to decode_slice; I couldn't see how this
happened. Guard patch attached.
Now we get another crash:
> export MallocGuardEdges=1
> gdb --args ./ffmpeg_g -i issue1228.mp4 -y -an -f framecrc /dev/null
GNU gdb 6.3.
Alexander Strange added the comment:
The check
> if(nalsize <= 1 || (nalsize+buf_index > buf_size)){
overflows because nalsize is INT_MAX. Patch attached.
I don't see why this only fails with -an; maybe there's another
Alexander Strange added the comment:
Applied.
--
status: open -> closed
substatus: open -> applied
FFmpeg issue tracker
<https://roundup.ffmpeg.org/roundup/ffmpeg/issue941>
Alexander Strange added the comment:
I'd missed another add symmetry; the instruction count is now the same.
x86-64 benchmarks (32-bit is the same):
before
9356 dezicycles in put_qpel16_h_lowpass_l2, 1024 runs, 0 skips
9735 dezicycles in put_qpel16_h_lowpass_l2, 2047 runs, 1 skips
Alexander Strange added the comment:
> emu edge will be internally enabled for interlaced H264 because it
cant be decode without.
Interlacing changes emu_edge_height, but only clients setting EMU_EDGE
affects emu_edge_width. So even for interlaced, the patch usually only
added one hig
Alexander Strange added the comment:
Yes, H.264 doesn't support lowres decoding. I think it would be
complicated and not really helpful, since most time is spent in bitstream
parsing.
--
priority: normal -> wish
status: new -> open
substatus: new -> open
type: bug ->
New submission from Alexander Strange :
Sample: http://astrange.ithinksw.net/ffmpeg/streamcopy/judge.mp4
I made this file using the QuickTime H.264 encoder and mp4 muxer. It plays
perfectly in QT (using
ffh264 through Perian), but has problems with some versions of lavf-based
players.
SVN
New submission from Alexander Strange :
Sample: http://astrange.ithinksw.net/ffmpeg/streamcopy/Seira_-
_Never.flv
> ffmpeg -i Seira_-_Never.flv -acodec copy seira.mp3
FFmpeg version SVN-r18646, Copyright (c) 2000-2009 Fabrice Bellard, et
al.
configuration: --enable-gpl --cc=gcc-4.2 --
Alexander Strange added the comment:
Sorry, this took much longer to get back to than I wanted.
All the clients supporting DR1 I know of (mplayer/vlc/xine) have it
explicitly disabled for H.264, but they might fix it sometime. Although
the EMU_EDGE slowdown might not be worth it.
This uses
New submission from Alexander Strange :
http://www.h264encoder.com/ is a free application which encodes to h264
and the formats supported by x264. It does not mention any other
software or licenses, but installs h264decoder.dll, which contains lavc
and lavf linked to several GPL libraries
Alexander Strange added the comment:
This problem only affects MVs starting in the first 5 allocated bytes of
the picture, so the fastest fix is to allocate some space before the
picture. I used 16 to avoid misaligning the start, since some client/sse2
code expects that even with
Alexander Strange added the comment:
It hasn't changed and I still get the error. (r18427)
Compilers couldn't affect it, since the read happens inside asm. Your
OS probably just has something else mapped immediately before the frame
- I'm using Valgrind for OS X.
...and I
Alexander Strange added the comment:
changed to important (crash)
--
priority: normal -> important
FFmpeg issue tracker
<https://roundup.ffmpeg.org/roundup/ffmpeg/issue941>
45 matches
Mail list logo
