Henk Schoneveld added the comment:
Here you go.
File '360frames.264' not attached - you can download it from
https://roundup.ffmpeg.org/file1184.
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue2020>
Henk Schoneveld added the comment:
Compiled version r25825, a vcodec copy results in
frame= 360 fps= 0 q=-1.0 Lsize= 13563kB time=14.20 bitrate=7824.2kbits/s
but an encode on the same file results in
frame= 357 fps= 6 q=-1.0 Lsize=3081kB time=14.20 bitrate=1777.5kbits/s
dup=0 drop=1
Henk Schoneveld added the comment:
Mplayer shows the same blockiness with '-vc ffh264'
but NOT with '-vc ffh264vdpau', I'll do some testing with 'mencoder -vc
ffh264vdpau'
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue2033>
Henk Schoneveld added the comment:
Added a new sample
File '293frames.ts' not attached - you can download it from
https://roundup.ffmpeg.org/file1021.
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue2020>
Henk Schoneveld added the comment:
in a time-frame which is impossible at .04 per frame/aka 25fps.
> would you mind
> telling us what your problem is (instead of pasting random output that proves
> my
> point)?
My problem is that if I have 10 multi-GOP's as source with a tot
Henk Schoneveld added the comment:
Another indication:
mplayer with ffh264 vs CoreAVC decoder to YUV
-rw-r--r-- 1 mythtv users 678846608 2010-08-05 08:29 /md/ffh264.yuv
-rwxr--r-- 1 mythtv users 683512194 2010-08-05 08:43 /spvfs/CoreAVC.yuv
Henk Schoneveld added the comment:
I hereby add more 'proof'. Under windows with mencoder I'm able to use CoreAVC
as the decoder instead of ffh264. The output shows:
All the same except for the decoder, CoreAVC vs ffh264
Note the differences in size: 1219444 vs. 1112986
and t
Henk Schoneveld added the comment:
Here you go
File 'test.split.98.ts' not attached - you can download it from
https://roundup.ffmpeg.org/file1020.
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue2144>
Henk Schoneveld added the comment:
Can you explain, why it isn't a 'valid' issue ?
Or in other words when is/would it be 'valid' ?
The uncut output isn't correct ?
Does "Duration: 00:00:11.88" in combination with
"frame= 300" make sense ?
I
Henk Schoneveld added the comment:
Why don't you answer the rest of my question ?
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue2020>
Henk Schoneveld added the comment:
May I ask with what version and how you checked you got 114 frames ?
I tried with SVN-r23993, from a few days ago. Did that to an elementary stream,
muxed with my 'most-trusted' tsmuxer and got 113 frames.
frame= 113 fps= 5 q=-1.0 Lsize=1473kB
Henk Schoneveld added the comment:
the allintra.ts
File 'allintra.ts' not attached - you can download it from
https://roundup.ffmpeg.org/file1019.
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue2145>
Henk Schoneveld added the comment:
from rawvideo to rawvideo, works OK. At least as tested with mpeg2video source
to h264 destination
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue2144>
Henk Schoneveld added the comment:
When all-intra is in mkv or mp4 everything is OK. So the problem is in the
ts-container. Both the original from DVB-S and the one produced by ffmpeg and
the one produced with tsMuxeR, although from the last one the 1st 13 frames are
identical. Also the size of
Henk Schoneveld added the comment:
last one
File 'allintra.mpv' not attached - you can download it from
https://roundup.ffmpeg.org/file1017.
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue2145>
Henk Schoneveld added the comment:
files of 2nd symptom uploaded
File '300frames-fromMPV-fps-hasdoubled.h264' not attached - you can download it
from https://roundup.ffmpeg.org/file1016.
FFmpeg issue tracker
<https://round
New submission from Henk Schoneveld :
time ffmpegn -y -vframes 600 -strict 1 -i /md/workc.ts -an -vcodec mpeg2video
-sameq -intra -f mpegts "/md/result/allintra.ts"
FFmpeg version SVN-r23993, Copyright (c) 2000-2010 the FFmpeg developers
built on Jul 21 2010 12:02:11 with gcc 4.2.
New submission from Henk Schoneveld :
ffmpeg -i ../trial/test.split.98.ts -an -vcodec copy -f rawvideo
howmanyframes.h264
FFmpeg version SVN-r23993, Copyright (c) 2000-2010 the FFmpeg developers
built on Jul 21 2010 12:02:11 with gcc 4.2.2 20070909 (prerelease)
(4.2.2-0.RC.1mdv2008.0
Henk Schoneveld added the comment:
Because of the impact on all encoding shouldn't it get a
"super-important" status.
I for myself wouldn't mind. ;)
>> Which brings audio-only files to mind. Do they have a GOP-like substitute?
>
> each audio frame is its own go
Henk Schoneveld added the comment:
If my brains serve me well, all video codecs become multithreaded this way.
Which brings audio-only files to mind. Do they have a GOP-like substitute?
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue2114>
Henk Schoneveld added the comment:
If I were smart enough I would have done that directly, I issued a
feature_request, Real man provide patches ;)
>
> [...]
>
> --
> title: GOP-based multithreading(h264 encoding performance boost of 78%)
> -> GOP-base
Henk Schoneveld added the comment:
Status is needs_more_info. What additional info is needed ?
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue2114>
Henk Schoneveld added the comment:
No No only compared ffmpeg -thread 0
with
8 times ffmpeg -thread 1 on different GOP's in parallel.
> In this case, two command lines (with time and -benchmark) and output is
> missing.
>
> --
> status: new -> open
> substat
New submission from Henk Schoneveld :
At the moment -threads 0 function doesn't scale well, 8 Cores ~ 350%, so about
45% efficiency. With GOP-based encoding ~ 80% can be achieved. I've tested this
by splitting DVB-S BBC-HD 1080i source-file in 3sec segments and with the help
of
Henk Schoneveld added the comment:
Added name to nosy list
--
nosy: +belcampo
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue2020>
Henk Schoneveld added the comment:
Added my name to nosy list
--
nosy: +belcampo
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue2033>
Henk Schoneveld added the comment:
Found the solution, added filesizes of my splitted parts and used that for skip
File 'decodesNOTok-another.mpg' not attached - you can download it from
https://roundup.ffmpeg.org/file955.
FFmpeg iss
Henk Schoneveld added the comment:
skip blocks doesn't translate well to ffmpeg -ss 220 AFAIK, so it's an almost
infinite trial and error to find that same section, or other section that show
the same errors. If you have an suggestion on how to do that I'll glad
Henk Schoneveld added the comment:
I would love to give the part of the original stream if I could find the
byteposition of the problematic part. But getting out the h264 part with current
ffmpeg already fails terrible. It identifies the stream as 26.65fps. After
several minutes still no 150
Henk Schoneveld added the comment:
Excuse another time for the fuzz, I never came across this kand of subtitle
thing and didn't know how to solve that. Sorry for that.
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue2035>
Henk Schoneveld added the comment:
Sorry for all the fuzz. Matroska is still a problem, changed the title
--
title: Encoding dvb-s streams which contain dvbsubs or subtitle text streams
fail to encode to mpegts or matroska container, mp4 works -> Encoding dvb-s
streams which cont
Henk Schoneveld added the comment:
The dd'ed file /md/dvbswithsrt2mkvproblem.mpg doesn't show the problem, only the
original. I don't know what to say about this. I copied the original to
local-disk, was nfs, it worked OK and also the original/non-moved file encodes
O
New submission from Henk Schoneveld :
ffmpegn -y -ss 00:15:00 -vframes 28300 -i /md/dvbswithsrt2mkvproblem.mpg -acodec
libfaac -ab 128k -ar 48000 -ac 6 -vcodec libx264 -threads 0 -b 1672k
-deinterlace -flags +loop -coder 1 -refs 2 -deblockalpha 0 -deblockbeta 0
-partitions +parti4x4+partp8x8
New submission from Henk Schoneveld :
ffplay -loglevel debug -autoexit /spvfs/decodesNOTok.mpg
FFplay version SVN-r23733, Copyright (c) 2003-2010 the FFmpeg developers
built on Jun 23 2010 11:42:07 with gcc 4.2.3 (4.2.3-6mnb2)
configuration: --prefix=/usr --enable-libxvid --enable-gpl
Henk Schoneveld added the comment:
encoding to mpegts gives different # of frames then matroska.
A source file, a mpegts gives Duration: 00:00:19.63
Encoding this file to mpegts gives Duration: 00:00:19.64
The same file to matroska gives Duration: 00:00:19.72
mpegts ends with frame= 492
Henk Schoneveld added the comment:
Encoded duration of the source is correct, when comparing to the original,
according to ffmpeg -i
But tsMuxeR says there are 114 frames, times .04 (25fps material) should be 4.56
seconds. The duration I get from the encoded-file is 4.48 so there are 2 frames
Henk Schoneveld added the comment:
tsMuxeR says there are 114 frames, times .04 (25fps material) should be 4.56
seconds. The duration I get is 4.48 so there are 2 frames missing I guess. If I
split a ts and stitch them together again with tsMuxeR my total frames# and
duration are correct. So I
Henk Schoneveld added the comment:
Duration is correct, according to ffmpeg -i, but mediainfo says it's VFR instead
of 25fps, and mplayer interprets it as 50fps.
FFmpeg issue tracker
<https://roundup.ffmpeg.org/issue2020>
New submission from Henk Schoneveld :
I'm encoding from 1080i to 576p with SVN-r23639 and the vpre hq option, leaving
out trellis, wpredp and fastpskip.
tsMuxeR says, when demuxing it's 114-frames
ffprobe v92 says 111 frames
mplayer says 112 frames
ffmpeg encodes 113 frames
The encod
New submission from Henk Schoneveld :
Using SVN-r12574, SVN-r17923 and SVN-r20199
muxing 86240 interlaced BBC-HD frames, duration 3449.6 seconds, from raw to ts
with:
ffmpeg -i 1080i.264 -an -vcodec copy -f mpegts 1080i.ts
Durations like
Duration : 01:54:59.160
Duration
New submission from Henk Schoneveld :
FFmpeg version SVN-r20167, Copyright (c) 2000-2009 Fabrice Bellard, et al.
built on Oct 4 2009 19:49:18 with gcc 4.2.2 20070909 (prerelease)
(4.2.2-0.RC.1mdv2008.0)
configuration: --prefix=/usr --enable-libx264 --enable-libxvid --enable-gpl
--enable
Henk Schoneveld added the comment:
Doing
ffmpeg -i Mountains_cut.ts -vcodec copy -f mp4 Mountains_cutffmpeg.mp4
ends with:
[NULL @ 0x807db50]non-existing SPS 4 referenced in buffering period
[h264 @ 0x807db50]non-existing SPS 4 referenced in buffering period
[h264 @ 0x807db50]mmco: unref short
New submission from Henk Schoneveld :
FFmpeg version SVN-r20167, Copyright (c) 2000-2009 Fabrice Bellard, et al.
built on Oct 4 2009 19:49:18 with gcc 4.2.2 20070909 (prerelease)
(4.2.2-0.RC.1mdv2008.0)
configuration: --prefix=/usr --enable-libx264 --enable-libxvid --enable-gpl
--enable
Henk Schoneveld added the comment:
make a script
#Next function is to make calculations possible
c () { echo "scale=2;$*" | bc -l; }
inputfile=$1
outputpng=frame_$2.png
fps=25
sf=$2
time=$(c $fps/$sf)
ffmpeg -ss $time etc
FF
Henk Schoneveld added the comment:
Next function is to make calculations possible
c () { echo "scale=2;$*" | bc -l; }
inputfile=$1
outputpng=frame_$2.png
fps=25
sf=$2
time=$(c $fps/sf)
ffmpeg -ss $time etc
FFmpeg issue track
45 matches
Mail list logo
