Doom10 Forum: Digital Video Discussion

I'll build a debug binary, but you'd also have to get a copy of GDB for it to actually get a backtrace.

> launch 'gdb binaryname'
> wait for gdb to load the symbols from the binary
> type 'run --all --your --options'
> wait for it to crash
> 'bt' for a backtrace, 'bt full' for a more detailed backtrace

edit: is that a 32bit binary or 64bit binary?

tl;dr
Depends on your use case. Also GPAC contains lots of "do not want" in its source tree.

GPAC used to be more or less in a situation where it couldn't be built well for a lulzy amount of time (all those forks that since have stopped being updated still remind us of that). Then certain people started making L-SMASH, first to make something to be implemented in x264, and later it outgrew its original priorities because x264_L-SMASH ended up basing itself on Kovensky's x264-audio, which was in the end never finished. Yes, at one point there was actually a time when adding audio encoding/muxing into x264's command line encoder seemed like a better idea than trying to fix up ffmpeg's shortcomings. Now L-SMASH is a mp4/mov/3gp demuxer/muxer library, which at least for me is currently the only thing that poses as any kind of alternative to libavformat.

Long story short: Unless GPAC is the only thing that does something you need, only look at libavformat or L-SMASH.

Also, I would like to have people understand the following things (that came up in a conversation with my friend):

• The timing_info part of the VUI contains the timescale and the timebase. This is not the frame rate (that said, the whole notion of a "frame rate" is really something that hasn't been in the MPEG formats for quite a while).
• timescale / (2 * timebase) is the maximum possible frame rate of the stream in the H.264 specification (this is field-based)
• Picture timing SEI can contain the PTS (Presentation Time Stamp) of a frame. x264 does not write this information to begin with. By taking a list of all the PTS and seeing if the difference is stable, this can be used to find the frame rate of a stream.
• The MaxFPS I just noted is actually set in Picture Timing SEI, so that as well can in a way be thought to not exist if that thing in itself doesn't exist.
  
  Quote

  n_frames specifies the value of nFrames used to compute clockTimestamp. n_frames shall be less than
  MaxFPS = Ceil( time_scale ÷ ( 2 * num_units_in_tick ) ) (D-2)
  NOTE 8 – n_frames is a frame-based counter. For field-specific timing indications, time_offset should be used to indicate a distinct clockTimestamp for each field.
• It could also be thought that if there is no HRD information in the stream, both timescale and num_units_in_tick are something that really doesn't contain much information in itself.

tl;dr
There is no spoon and just by having the timing_info in the VUI you can only set the maximum frame rate. That said, that information is used rather generously to supposedly show the "frame rate" of an elementary stream.

edit: Also I have no idea what the fact that Matroska is not an ISO/IEC standard has to do with the fact that for whatever reason the player wants an arbitrary value in the VUI in order to play content that does not have a single frame rate to begin with.

edit2: Added some extra information that was added during the discourse.

I would really appreciate it if it was the same file, just run through eac3to to make it "work" with your plastic toy. Not two separate files.

Try comparing mkvinfo output for both the matroska file you create at first, as well as the file that eac3to outputs. Matroska has per-frame timestamps which is what should get used for playback, and those should always be there (by understanding this it should be relatively obvious how dubious the notion of 'frame rate' is when dealing with Matroska). Looking at the spec, there is a DefaultDuration field and a BlockDuration fields that contain general timestamps according to the TimecodeScale. Changes to those could show some of the reasons on what the hardware playthingy of yours is failing with certain files.

Also I see in the video that eac3to says "Writing new framerate "25fps" to bitstream." I wonder what exactly that means, as I don't remember there being a "frame rate" thing in the H.264 specification. Also with VFR content it's pretty sure that if it writes a single frame rate, that is wrong, wherever it is wrting it.

As for the timescale, select the smallest common value that would let you have both 25/1 frames per second as well as 60000/1001 frames per second in there. 59.94 is non-exact.

• Originally we had no other ways to input things into x264 than raw YCbCr, raw YCbCr in y4m or avisynth input
• x264 does have some filters, but if you need to do something a la IVTC and/or hifist resize, that can't be done
• For some things, ffms2/lavf input isn't perfect (that list of things is rather specific and small)

Those are the three main reasons (in no specific order) why most things tell you to handle source decoding etc. in something else

I think what this person meant is 10bit H.264 decoding support, and I would _think_ that just an update to the libav/ffmpeg library used would let one do this (used as 8bit YCbCr internally after swscale converts the 10bit input to 8bit).

But yes, if one would like a full high bit depth workflow and the capability to output both 8bit and 10bit H.264, things get a little more intricate

People will be able to make mappings for their scripting language of choice, the API is C, and Vapoursynth itself is a C++ project using Qt and libswscale.

The pre-provided mappings will be for Python 3.x.

Probably typo of 'test'.

This topic has no content and I shall thus lock it down.

Have you compiled JM as 64bit? This might be blindingly obvious, but if you don't compile it as a 64bit binary it will fail if it tries to allocate over a certain amount of memory.

You might also see the code if the way they are allocating memory and the related variables actually can hold >32bit values. It could be a bug in there.

I'll look in the ffmpeg's doxy (but I don't find it really easy to read :-/ )

I never said it's easy to read, I just prefer the way online documentation is created on ffmpeg's site to libav's

Yes, it seems like the account this forum was hosted on indeed was compromised at least on a file system level. While it doesn't look like the attacker was in it for the private data (mostly just file-wise changes done to show spam to Google), one must always assume the worst. Thus, as per standard procedure, even though it seems as if the information was most probably not accessed illegitimately in the database, and even though all passwords on this site are hashed (and salted), if you have re-used the password you have used on this site, it is recommended that you change it as soon as possible. Also, this piece of forum software lacks the capability to force people to reset their passwords, but you should definitely do so as well.

It is not yet known if a local problem led to this, or if this was a bigger problem with the hoster's systems. I am not going to point any fingers towards anyone at this point and just try and make the current situation better.

So far:

• Full tarball backup of the compromised forum has been made for further analysis. We already know how the spam effect was done, but more has to be learned about possible points of entry and so forth.
• The forum has been completely reset file-wise. If there was any cruft that might have made intrusion easier, it sure isn't there any more.
• All uploaded avatars have been removed and disabled. Only non-local stuff can now be used. One of the possible entry points is a PHP script uploaded as a picture.
• Overall file rights have been minimized.
• Moderators' and administrators' passwords were reset, as well as everything possible in the overall forum configuration was changed.

• where I can get the hash for r2200?
• please give me for an example how to do?

'git log' is the way to get a full log that in most sane shells you can then scroll through to find what you need (works on cygwin and most probably on the custom shell in msysgit, I just added msysgit's /bin into my msys/mingw setup's PATH, which leads to getting spammed with the whole changelog at once into stdout). If you know how many commits from your current HEAD something is, you can use what Groucho2004 noted, which can also be accomplished with:
git reset --hard HEAD~NUMBERwhere, for example, in case of NUMBER being 1 you get the previous commit from the current HEAD (current state of the repository). 'Reset --hard' can also be used with a hash, naturally

(you can use the HEAD~1 with 'git checkout' as well, but that will lead you to not being on any branch any more, also you can return back to your usual track with reset --hard'ing to origin/master where origin is the remote you want to reset to, and master being the branch you want to use).

The related Doom9 thread seems to have some results here.

The trouble i think might be that patched build aint 10bit at all (wrong fork) because i get strange artifacts which are regular using low bandwidth in 8bit resolution. And now when i finally checked out resolution bit in MPC-HC/Media Info tab it also shows 8bit which is rather frustrating to acknowledge that i really saw those banding artifacts which i didnt have with Jeeb c119 encodes or w/regular c122 build 2184

Just did a quick test encode with the 64bit patched build on a random clip I had on hand ("x264-10bit ep01_terop1.avi --crf 22 --preset fast -o out_testan_crf22.mkv"). My output is properly 10bit and there seem to be no problems with it, I'm pretty sure this is a PEBKAC, so re-check your things. It should be literally impossible for a 10bit build to output 8bit H.264, the 8bit code paths should be blocked.

But, in this new build 2184 this strange fourth line show ups (which i fancy rather it's unnecessary)

It outputs the settings string. I wasn't planning on adding this feature, but Komisar's "cosmetics" patch sounded good (and it does indeed make x264 output the used crf value in more detail, which is the part I actually meant to take in), and happened to contain that. I don't like the feature, but I don't hate it either. I will probably end up editing the patch later to make it only output it in case of a certain setting being set .

Another few discrepancies are that this build reports as Core123

Code: [Select]

x264 - core 123 r2184+681M 5d72658 - H.264/MPEG-4 AVC codec - Copyleft 2003-2012 - http://www.videolan.org/x264.html - options: cabac=1

Completely normal, the commits that I cherry-picked out of the development tree are those that one-up'd that. A list of patches used for the "2184" patched builds (including cherry-picked development tree commits) can be easily seen here. I could have one-up'd the revision number for every development tree commit used, but that would've not been exactly correct, as there could be changes in both the contents as well as the arrangement of those commits, leading to a discrepancy. In the end I decided to just tend to them as "patches".