Justin Ruggles justin.rugg...@gmail.com added the comment:
I have a working patch for the AC-3 encoder. The decoder is next. I also have a
question waiting on some sort of answer on ffmpeg-devel regarding the
avcodec_guess_channel_layout() function.
--
nosy: +jbr
status: new - open
Justin Ruggles justin.rugg...@gmail.com added the comment:
It looks like Baptiste's patch got an ok from Michael. Not sure why it was
never applied...
--
nosy: +jbr
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https
Justin Ruggles justin.rugg...@gmail.com added the comment:
I don't get any errors with the sample you provided. I am using
libspeex1.2beta4 from Ubuntu. The output does sound a little odd, but it sounds
the same when I use speexdec.
So regarding the error messages... which version of libspeex
Justin Ruggles justin.rugg...@gmail.com added the comment:
(adding myself to nosy list)
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/roundup/ffmpeg/issue884
Justin Ruggles justin.rugg...@gmail.com added the comment:
I assume you mean 5.1 downmixed to 2.0 is softer than its accompanying 2.0
track. This is normal behavior. It is mentioned in the A/52 spec in section
7.8.2 Downmixing Into Two Channels. All mixing coefficients must be scaled down
Justin Ruggles justin.rugg...@gmail.com added the comment:
confirmed. I have tried to fix this before, with much frustration, but was not
successful. I won't give up yet though.
--
assignedto: - jbr
nosy: +jbr
status: new - open
substatus: new - reproduced
Justin Ruggles justin.rugg...@gmail.com added the comment:
closing this issue. will only reopen if a convincing argument is given
that the AC3 decoder is doing something wrong.
--
status: new - closed
_
FFmpeg issue tracker iss
Justin Ruggles justin.rugg...@gmail.com added the comment:
Could you check to see if the dialogue normalization changes between programs?
FFmpeg does not apply any dialogue level attenuation.
Arbitrarily scaling by 3 is completely wrong though. If the difference you're
hearing could indeed
Justin Ruggles justin.rugg...@gmail.com added the comment:
As far as dialogue normalization, it should only reduce, not increase, the
output level. So what I'm wondering is if your stereo samples have a
significantly higher dialnorm value (and thus should have volume reduced) than
your 5.1
Justin Ruggles justin.rugg...@gmail.com added the comment:
I'm sorry, but I'm still unable to reproduce. Maybe someone else can.
Check the md5sum of the decoded wav file to see if it matches mine.
./ffmpeg -i ~/Desktop/noah-2sec-1600.spx noah.wav
FFmpeg version SVN-r19182, Copyright (c) 2000
Justin Ruggles justin.rugg...@gmail.com added the comment:
verified with r19266
change status
--
substatus: open - reproduced
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/roundup/ffmpeg/issue1026
_
Justin Ruggles justin.rugg...@gmail.com added the comment:
IIRC, Michael has said before that it might be an acceptable solution for the
decoder to export the source dialogue level. Then the output could be scaled at
the user level if the user specifies a target dialogue level
Justin Ruggles justin.rugg...@gmail.com added the comment:
Do you have SWF samples with Speex? Full Speex support in FLV is not far off I
hope, but I don't know how it is used in SWF.
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https
Justin Ruggles justin.rugg...@gmail.com added the comment:
add myself to nosy list
--
nosy: +jbr
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/roundup/ffmpeg/issue1301
_
Justin Ruggles justin.rugg...@gmail.com added the comment:
It seems the libvorbis wrapper is written to only support mono or stereo, but it
doesn't fail otherwise. It needs to be fixed to either support multi-channel
input or fail when the input is not mono or stereo.
Changing title since
Justin Ruggles justin.rugg...@gmail.com added the comment:
Yes, your 2nd patch fixes the issue for me. Attaching it here for historical
purposes.
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/roundup/ffmpeg
Justin Ruggles justin.rugg...@gmail.com added the comment:
this is a valid feature request. change status to open/open.
--
status: new - open
substatus: new - open
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https
Justin Ruggles justin.rugg...@gmail.com added the comment:
Patch attached to allow multichannel input to the libvorbis encoder. Assigning
the issue to myself since there is no libvorbis.c maintainer.
--
assignedto: - jbr
topic: +avcodec
Justin Ruggles justin.rugg...@gmail.com added the comment:
We do not support Alias Wavefront files. With the addition of the low probe
score warning message, I would consider this issue fixed.
--
status: new - closed
substatus: new - fixed
Justin Ruggles justin.rugg...@gmail.com added the comment:
Benjamin Larsson wrote:
Benjamin Larsson ba...@ludd.ltu.se added the comment:
Justin Ruggles wrote:
Justin Ruggles justin.rugg...@gmail.com added the comment:
The file is broken. The AC-3 spec very clearly states that there must
Justin Ruggles justin.rugg...@gmail.com added the comment:
I think this is done now for the decoders listed here.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/roundup/ffmpeg/issue773
Justin Ruggles justin.rugg...@gmail.com added the comment:
Applied the patch in r20110.
--
status: open - closed
substatus: analyzed - fixed
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/roundup/ffmpeg
Justin Ruggles justin.rugg...@gmail.com added the comment:
The decoders mentioned in this bug report have all been fixed. Closing the
issue.
--
status: open - closed
substatus: reproduced - fixed
FFmpeg issue tracker iss
Justin Ruggles justin.rugg...@gmail.com added the comment:
The issue is that the SSND chunk does not have to be the last chunk in the AIFF
file, but the AIFF demuxer reads audio data until the end of the file. The
attached patch determines the audio data size so that aiff_read_packet() does
Justin Ruggles justin.rugg...@gmail.com added the comment:
change title. update topic list.
--
title: MP3 from AIF puts noise to the end of the file - AIFF demuxer puts
noise to the end of the file
topic: +avformat
_
FFmpeg issue
Justin Ruggles justin.rugg...@gmail.com added the comment:
trying to replace the file with new file...
--
nosy: -jbr
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/roundup/ffmpeg/issue1455
Justin Ruggles justin.rugg...@gmail.com added the comment:
Baptiste Coudurier wrote:
Baptiste Coudurier baptiste.coudur...@gmail.com added the comment:
On 10/11/09 1:02 PM, Justin Ruggles wrote:
Justin Rugglesjustin.rugg...@gmail.com added the comment:
trying to replace the file
Justin Ruggles justin.rugg...@gmail.com added the comment:
fixed in r20219.
--
status: open - closed
substatus: analyzed - fixed
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/roundup/ffmpeg/issue1455
_
Justin Ruggles justin.rugg...@gmail.com added the comment:
duplicate of Issue1150
though this issue focuses more on lavf rather than just ffplay.
--
assignedto: - jbr
nosy: +jbr
status: new - open
substatus: new - duplicate
topic: +avformat
Justin Ruggles justin.rugg...@gmail.com added the comment:
I couldn't find the actual bulletin, but I did find the Dolby press release[1]
that describes it, and it seems to be saying that for DVB, using RF Mode on the
receiver will make the loudness of (E)AC-3 closer to that of MP2.
The spec
Justin Ruggles justin.rugg...@gmail.com added the comment:
I have noticed the same thing. The rate control for aacenc just seems
strange. I can't quite figure it out. It should either be intuitive or
it should be documented.
Also, when bit_rate is high the encoder will hang or crash. I'll
Justin Ruggles justin.rugg...@gmail.com added the comment:
This is the same issue as 1150.
A FLAC parser should fix the pts and also allow generic seeking.
--
assignedto: - jbr
dependson: +FFplay can't seek *.flac file
nosy: +jbr
status: new - open
substatus: new - open
superseder
Justin Ruggles justin.rugg...@gmail.com added the comment:
It is libfaac. Try the faac commandline encoder and see what you get.
faac -b 192 test.wav -o test.aac
Freeware Advanced Audio Coder
FAAC 1.26.1 (Aug 16 2008) UNSTABLE
Average bitrate: 152 kbps
Quantization quality: 100
Bandwidth
Justin Ruggles justin.rugg...@gmail.com added the comment:
Setting avctx-channels for each frame decode fixes the issue. That is
what the AC-3 decoder does. In this case, ffmpeg still reports it as 5.0
due to the container, but it is changed to 5.1 by the decoder and decodes
properly
Justin Ruggles justin.rugg...@gmail.com added the comment:
I don't think anything is wrong here. You're getting weird audio output
because you're using --sign=unsigned. In unsigned audio, 0 is full
negative amplitude.
flac -d foo.flac -o foo_flac.wav
ffmpeg -i foo.flac foo_lavc.wav
cmp
Justin Ruggles justin.rugg...@gmail.com added the comment:
Deiz wrote:
Deiz ffm...@pwnly.com added the comment:
I didn't realize --unsigned was what was causing the output issue (As it turns
out, that's dmix mixing the 0 dB sample with other output.) but that's not the
underlying issue
Justin Ruggles justin.rugg...@gmail.com added the comment:
needs more info. as Carl said, please supply complete output of the ffmpeg
command that leads to this failure.
--
substatus: - needs_more_info
_
FFmpeg issue tracker iss
Justin Ruggles justin.rugg...@gmail.com added the comment:
Well, it's hard to tell anything without a sample. Can you at least
attach the foo.ana file output from flac -a foo.flac and the output of
metaflac --list foo.flac?
_
FFmpeg issue
Justin Ruggles justin.rugg...@gmail.com added the comment:
That foo.ana file indicates that your source is all silence. So I
recreated the file and could not reproduce any issues with ffmpeg or
ffplay from SVN.
Update to latest SVN and see if you can reproduce any issues with ffmpeg
Justin Ruggles justin.rugg...@gmail.com added the comment:
there is already an open issue about flac seeking.
closing this issue.
--
status: open - closed
substatus: open - invalid
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
Justin Ruggles justin.rugg...@gmail.com added the comment:
Vitor wrote:
New submission from Vitor vitor1...@gmail.com:
Webiste at http://www.jetaudio.com, no source code offer.
Binary at http://dn2.cowon.com/JetAudioInc/jetAudio/JAD8002_BASIC.exe .
Moreover it looks like they hacked
Justin Ruggles justin.rugg...@gmail.com added the comment:
This is intended behavior. The only time it actually returns an error is
when there is a frame sync loss. Partial or invalid frames will trigger
error concealment, which repeats the last known good block until the next
valid frame
Justin Ruggles justin.rugg...@gmail.com added the comment:
Yes, it would be welcome. Reopening as a feature request.
--
priority: normal - minor
status: closed - open
substatus: invalid - open
type: bug - feature_request
_
FFmpeg
Justin Ruggles justin.rugg...@gmail.com added the comment:
This seems to me to be a feature request to add support for writing of
VorbisComment metadata.
--
topic: +avformat
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https
Justin Ruggles justin.rugg...@gmail.com added the comment:
change type
--
type: bug - feature_request
_
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/roundup/ffmpeg/issue1720
_
Justin Ruggles justin.rugg...@gmail.com added the comment:
USE_HIGHPRECISION went away in r16594 in favor of using
CONFIG_MPEGAUDIO_HP directly. Part of the issue you mentioned was fixed,
in that other files that include mpegaudio.h no longer need an extra
definition, only mpegaudioenc.c
Justin Ruggles justin.rugg...@gmail.com added the comment:
That is not exactly true. I have been able to generate files that play
with the acm codec that are not 32kbps.
ffmpeg -i test.wav -acodec g726 -ac 1 -ab 128k -ar 32000 test_g726.wav
mplayer -ac g726 test_g726.wav
But FFmpeg can
Justin Ruggles justin.rugg...@gmail.com added the comment:
The data needs to be run through the AC-3 parser to get the required codec
parameters. Patch attached.
--
topic: +avformat
FFmpeg issue tracker iss...@roundup.ffmpeg.org
Justin Ruggles justin.rugg...@gmail.com added the comment:
So what happens is that when the stream changes to stereo, the decoder
will start outputting stereo. The audio seems correct though. But
since the output format is wav, it expects everything to be the same
channel layout. So when
Justin Ruggles justin.rugg...@gmail.com added the comment:
So right now the application can know that the number of channels changes
because avctx-channels changes. But I guess it wouldn't hurt to log a
warning in the decoder when the number of channels changes and the decoder
goes from
Justin Ruggles justin.rugg...@gmail.com added the comment:
Joakim Plate wrote:
Joakim Plate elu...@ecce.se added the comment:
I think what he meant was it returns frame_size even if the supplied
amount of data was less than that. Atleast going by the check he added in
our codebase
Justin Ruggles justin.rugg...@gmail.com added the comment:
I patched this within the last couple weeks for the ALS encoder that
Thilo and I are working on. I just haven't had a chance to submit it
for review.
FFmpeg issue tracker iss
Justin Ruggles justin.rugg...@gmail.com added the comment:
I'm not sure how to create a patch for an old git commit... so I'll post the URL
here.
http://github.com/justinruggles/FFmpeg-alsenc/commit/011c17464f89b188c01627b9c177af665d65b159
Justin Ruggles justin.rugg...@gmail.com added the comment:
Fixed in r23570. The FLAC encoder still won't encode large frames, but at
least it won't crash anymore.
--
status: open - closed
substatus: reproduced - fixed
FFmpeg issue
Justin Ruggles justin.rugg...@gmail.com added the comment:
Carl Eugen Hoyos wrote:
New submission from Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at:
Both dependent substream eac3 samples on incoming (blu-ray_eac3 and
Dependent_substream_decoding_sample.m2ts) are auto-detected
Justin Ruggles justin.rugg...@gmail.com added the comment:
Baptiste Coudurier wrote:
Baptiste Coudurier baptiste.coudur...@gmail.com added the comment:
On 7/5/10 1:20 AM, Carl Eugen Hoyos wrote:
Carl Eugen Hoyosceho...@rainbow.studorg.tuwien.ac.at added the comment:
[mpegts @ 0x11bf470
Justin Ruggles justin.rugg...@gmail.com added the comment:
fixed in r24103
--
status: open - closed
substatus: open - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2022
Justin Ruggles justin.rugg...@gmail.com added the comment:
Carl Eugen Hoyos wrote:
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment:
Secondary E-AC-3 stream works fine (transf.ts in samples).
Where is transf.ts? It's not listed in allsamples.txt.
--
title
Justin Ruggles justin.rugg...@gmail.com added the comment:
Justin Ruggles wrote:
Justin Ruggles justin.rugg...@gmail.com added the comment:
Carl Eugen Hoyos wrote:
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment:
Secondary E-AC-3 stream works fine (transf.ts
Justin Ruggles justin.rugg...@gmail.com added the comment:
This should be fixable for FLAC once the FLAC parser makes it to SVN. The
packet duration will be set by the demuxer. Then ffmpeg.c could be
modified to allocate enough memory based on sample format, sample rate,
channels
Justin Ruggles justin.rugg...@gmail.com added the comment:
Sample moved to samples/A-codecs/lossless/als
trying to keep it organized.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2387
Justin Ruggles justin.rugg...@gmail.com added the comment:
Well, the solution I had in mind back in July isn't the best solution. This
will be fixed after the audio decoders use get/release_buffer(). Which is
something I have been working
Justin Ruggles justin.rugg...@gmail.com added the comment:
The example code is wrong. I verified that ffmpeg.c now gets raw FLAC packets
with correct sizes and pts since the FLAC parser was added.
--
status: open - closed
substatus: open - fixed
Justin Ruggles justin.rugg...@gmail.com added the comment:
The heart of the issue seems to be that voc_get_packet() changes the codec_id
when reading each packet based on input stream data. If a file is damaged, a
random value will most likely make it CODEC_ID_NONE since there are only 8 valid
Justin Ruggles justin.rugg...@gmail.com added the comment:
change status
--
substatus: open - analyzed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2502
Justin Ruggles justin.rugg...@gmail.com added the comment:
On 01/17/2011 03:19 PM, ami_stuff wrote:
New submission from ami_stuff ami_st...@o2.pl:
the latest voc modification broken decoding of
http://samples.mplayerhq.hu/voc/pcm_s16_2/nem.voc
Author: cehoyos
Date: Tue Jan 11
Justin Ruggles justin.rugg...@gmail.com added the comment:
Fixed in 1360f07
--
status: open - closed
substatus: reproduced - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2505
Justin Ruggles justin.rugg...@gmail.com added the comment:
fixed in 8ca8e82
--
status: open - closed
substatus: reproduced - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2560
Justin Ruggles justin.rugg...@gmail.com added the comment:
Changing this to a feature request.
It might be useful to have a per-muxer AVOption for the mp3 muxer to write (or
not write) different versions of ID3 tags.
--
priority: important - wish
status: new - open
substatus: new - open
Justin Ruggles justin.rugg...@gmail.com added the comment:
file size samples
original92160008 23039991
ffmpeg libfaac 92147756 23036928
ffmpeg aacenc 92160044 2304
faac92164140 23041024
What the FFmpeg native AAC encoder does seems to be pretty sensible
Justin Ruggles justin.rugg...@gmail.com added the comment:
changing to feature request.
implementation of heavy compression is needed, as well as exporting of dialogue
level.
--
substatus: needs_changes - open
topic: +avcodec
type: patch - feature_request
Justin Ruggles justin.rugg...@gmail.com added the comment:
fixed in git 243f8241dbf4a451e1197661ccd387c519ae3349
--
status: open - closed
substatus: reproduced - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https
Justin Ruggles justin.rugg...@gmail.com added the comment:
not an issue
--
status: new - closed
substatus: new - invalid
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2580
Justin Ruggles justin.rugg...@gmail.com added the comment:
patch sent to ffmpeg-devel
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2475
New submission from Justin Ruggles justin.rugg...@gmail.com:
copy/paste of attached SoundFragmentsAfterSeeking.txt:
Hi, while trying to use FFmpeg libs as a developer I found the following:
When decoding sound from some compressed audio formats (namely i tested some mp4
files with aac audio
Justin Ruggles justin.rugg...@gmail.com added the comment:
Should this issue be closed now that ffprobe is in FFmpeg?
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue442
Justin Ruggles justin.rugg...@gmail.com added the comment:
It's not clear what HoboZero wants to do by that commandline, but the mail
referred to is regarding mixing multiple mono streams into a single multichannel
stream. That seems like a valid feature request and probably a good candidate
Justin Ruggles justin.rugg...@gmail.com added the comment:
Our wtv demuxer isn't handling something correctly. There seem to be 2 streams
with the same stream id of 267. The first is AC-3, and it uses a stream2 GUID.
The second is MP2, and it uses a stream GUID. The 2nd seems
Justin Ruggles justin.rugg...@gmail.com added the comment:
It seems that the mp2 and ac3 are interleaved in the same stream, with each
packet having an mp2 frame concatenated with an ac3 frame. Our demuxer skips
the ac3 frames. The data for ac3 is using stream id 266, but that is not
detected
Justin Ruggles justin.rugg...@gmail.com added the comment:
I mean... they're not interleaved in the same stream. they have 2 separate
stream id's (266 267) but the setup is not detecting the AC3 as a separate
stream id. they're both detected as 267 and the mp2 info overrides the ac3 info
Justin Ruggles justin.rugg...@gmail.com added the comment:
I have a fix. I'll send it to ffmpeg-devel after a bit more testing.
Basically, stream2_guid chunks can initialize new streams as well. Existing
demuxer only parses stream2_guid info if the stream already exists but no data
has been
Justin Ruggles justin.rugg...@gmail.com added the comment:
Out of the 3 samples streams (this one + 2 in mphq samples), all of them have
extra streams using other stream ids that are skipped because they're
initialized with stream2_guid, not stream_guid. But this is the only sample of
the 3
Justin Ruggles justin.rugg...@gmail.com added the comment:
Actually the stereo mp2 stream seems to be descriptive audio for the visually
impaired, while the ac3 stream is the main program.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https
Justin Ruggles justin.rugg...@gmail.com added the comment:
Many of the audio encoders do not check sample format explicitly. Instead they
have a list of supported sample formats. The application is supposed to check
AVCodecContext-codec-sample_fmts.
--
status: new - closed
substatus
Justin Ruggles justin.rugg...@gmail.com added the comment:
fixed by Peter Ross in e4f85b849913794395bb03dfc09546cd41b10882
--
status: open - closed
substatus: analyzed - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https
Justin Ruggles justin.rugg...@gmail.com added the comment:
Please don't change to important until the issue is verified opened.
--
priority: important - normal
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org
Justin Ruggles justin.rugg...@gmail.com added the comment:
missing necessary information.
please see http://www.ffmpeg.org/bugreports.html
--
substatus: new - needs_more_info
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https
Justin Ruggles justin.rugg...@gmail.com added the comment:
I don't consider this a bug. It seems like a completely valid warning to
me, and pretty obvious since it prints out the configure string for each
library that doesn't match the configure string of the ffmpeg program.
In the example
Justin Ruggles justin.rugg...@gmail.com added the comment:
Missing required information for a bug report.
Please see http://www.ffmpeg.org/bugreports.html
The video plays fine for me with current ffplay.
--
substatus: new - needs_more_info
Justin Ruggles justin.rugg...@gmail.com added the comment:
confirmed that this issue exists.
it's not a demuxer/decoder problem since transcoding to ffv1/nut works
just fine with this sample. probably an issue with ffmpeg, libx264
wrapper, or mp4 muxer.
--
status: new - open
substatus
Justin Ruggles justin.rugg...@gmail.com added the comment:
changing priority to normal. needs more info and/or reproducing to
determine what the cause of the problem is.
--
priority: important - normal
status: new - open
substatus: new - needs_more_info
Justin Ruggles justin.rugg...@gmail.com added the comment:
feature requests are not priority:important except maybe in some extreme
circumstances. maybe we can add a topic tag for bounty?
--
priority: important - minor
FFmpeg issue
Justin Ruggles justin.rugg...@gmail.com added the comment:
Thanks for the bug report.
Can you please provide a sample of the Apple-generated file before and
after passing it through ffmpeg with -acodec copy? That will allow us to
compare the mp4 structures to see where the problem might
Justin Ruggles justin.rugg...@gmail.com added the comment:
Changing priority back to normal until verified.
--
priority: critical - normal
topic: -git
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2635
Justin Ruggles justin.rugg...@gmail.com added the comment:
unlike in libavcodec and libavutil, runtime cpu detection for libswscale
is optional. maybe this should be changed to at least default to 'on'
instead of 'off' to avoid unwanted surprises like this.
--
status: new - open
Justin Ruggles justin.rugg...@gmail.com added the comment:
All I can confirm is that it does work fine with vlc and ffplay. Maybe
there is something about the mkv files that mpc-hc (or whatever mkv
demuxer is being used with it) doesn't like for some reason.
--
status: new - open
Justin Ruggles justin.rugg...@gmail.com added the comment:
attached: mkvinfo of file generated by ffmpeg
File 'ffmkv.txt' not attached - you can download it from
https://roundup.ffmpeg.org/file1358.
FFmpeg issue tracker iss...@roundup.ffmpeg.org
Justin Ruggles justin.rugg...@gmail.com added the comment:
attached: mkvinfo of file produced by mkvmerge
File 'mkvmerge.txt' not attached - you can download it from
https://roundup.ffmpeg.org/file1359.
FFmpeg issue tracker iss
Justin Ruggles justin.rugg...@gmail.com added the comment:
working on a fix. thanks for the bug report.
broken build is priority:important
--
assignedto: - jbr
nosy: +jbr
priority: normal - important
status: new - open
substatus: new - analyzed
topic: +avcodec, build system
Justin Ruggles justin.rugg...@gmail.com added the comment:
all except bytes 8 to 11 seem to be the same for every frame.
01 10 00 00 00 00 00 00 XX XX XX XX 00 14 22 06
bytes 8 to 11 could be some sort of timestamp.
first two frames are 00 00 00 00
subsequent frames increment by FF C0
any
1 - 100 of 112 matches
Mail list logo